[ Upstream commit 3b84adf460381169c085e4bc09e7b57e9e16db0a ]

An overflow can occur in a situation where src.centiseconds
takes the value of 255. This situation is unlikely, but there
is no validation check anywere in the code.

Found by Linux Verification Center (linuxtesting.org) with Svace.

Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Signed-off-by: Jan Kara <jack@suse.cz>
Message-Id: <20240327132755.13945-1-r.smirnov@omp.ru>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit db6754090a4f99c67e05ae6b87343ba6e013531f ]

Use the folio APIs throughout this function.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Fixes: 1eeceaec794e ("udf: Convert udf_expand_file_adinicb() to avoid kmap_atomic()")
Signed-off-by: Jan Kara <jack@suse.cz>
Message-Id: <20240417150416.752929-4-willy@infradead.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

The SLAB_MEM_SPREAD flag is already a no-op after removal of SLAB
allocator and in [1] it was fully deprecated. Remove its usage so we can
delete it from slab. No functional change.

Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/all/20240223-slab-cleanup-flags-v2-1-02f1753e8303@suse.cz/
Message-Id: <20240224135229.830356-1-chengming.zhou@linux.dev>

Convert the UDF filesystem to the new mount API.

UDF is slightly unique in that it always preserves prior mount
options across a remount, so that's handled by udf_init_options().

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Message-Id: <fcb3faf3-e2df-450c-b37a-11000c274585@redhat.com>

There's no reason to treat novers specially, convert it
to a flag in uopt->flags like other flag options.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Message-Id: <b5d53492-b99a-4b3c-82c0-581df9a9e384@redhat.com>

udf_load_logicalvolint() loads logical volume integrity descriptors.
Since there can be multiple blocks with LVIDs, we verify the contents of
only the last (prevailing) LVID found. However if we fail to load the
last LVID (either due to IO error or because it's checksum fails to
match), we never perform the verification of validity of the LVID we are
going to use. If such LVID contains invalid data, we can hit
out-of-bounds access or similar issues. Fix the problem by verifying
each LVID we are potentially going to accept.

Reported-by: Robert Morris <rtm@csail.mit.edu>
Signed-off-by: Jan Kara <jack@suse.cz>

udf_expand_file_adinicb() is called under inode->i_rwsem and
mapping->invalidate_lock. i_rwsem is safe wrt fs reclaim,
invalidate_lock on this inode is safe as well (we hold inode reference
so reclaim will not touch it, furthermore even lockdep should not
complain as invalidate_lock is acquired from udf_evict_inode() only when
truncating inode which should not happen from fs reclaim).

Signed-off-by: Jan Kara <jack@suse.cz>

udf_load_pvoldesc() is called only during mount when it is safe to
enter fs reclaim (we hold only s_umount semaphore). Change GFP_NOFS to
GFP_KERNEL allocation.

Signed-off-by: Jan Kara <jack@suse.cz>

The GFP_NOFS allocation in udf_symlink() is called only under
inode->i_rwsem and UDF_I(inode)->i_data_sem. The first is safe wrt
reclaim, the second should be as well but allocating unde this lock is
actually unnecessary. Move the allocation from under i_data_sem and
change it to GFP_KERNEL.

Signed-off-by: Jan Kara <jack@suse.cz>

Directory iteration code was using GFP_NOFS allocations in two places.
However the code is called only under inode->i_rwsem which is generally
safe wrt reclaim. So we can do the allocations with GFP_KERNEL instead.

Signed-off-by: Jan Kara <jack@suse.cz>