summaryrefslogtreecommitdiffstats
path: root/fs/udf
Commit message (Collapse)AuthorAgeFilesLines
...
| * | udf: Do not call udf_block_map() on ICB filesJan Kara2023-01-261-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently udf_symlink_filler() called udf_block_map() even on files which have data stored inside the ICB. This is invalid as we cannot map blocks for such files (although so far the error got silently ignored). The call happened because we could not call block mapping function once we've acquired i_data_sem and determined whether the file has data stored in the ICB. For symlinks the situation is luckily simple as they get never modified so file type never changes once it is set. Hence we can check the file type even without i_data_sem. Just drop the i_data_sem locking and move block mapping to where it is needed. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Use udf_bread() in udf_load_vat()Jan Kara2023-01-261-5/+8
| | | | | | | | | | | | | | | | | | | | | Use udf_bread() instead of mapping and loadign buffer head manually in udf_load_vat(). Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Use udf_bread() in udf_get_pblock_virt15()Jan Kara2023-01-261-3/+2
| | | | | | | | | | | | | | | | | | | | | Use udf_bread() instead of mapping and reading buffer head manually in udf_get_pblock_virt15(). Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Factor out block mapping into udf_map_block()Jan Kara2023-01-262-22/+49
| | | | | | | | | | | | | | | | | | | | | | | | Create new block mapping function udf_map_block() that takes new udf_map_rq structure describing mapping request. We will convert other places to use this function for block mapping. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Move incrementing of goal block directly into inode_getblk()Jan Kara2023-01-261-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | inode_getblk() sets goal block for the next allocation to the currently allocated block. This is obviously one less than what the goal block should be which we fixup in udf_get_block(). Just set the right goal block directly in inode_getblk(). Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Drop VARCONV supportJan Kara2023-01-269-84/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UDF was supporting a strange mode where the media was containing 7 blocks of unknown data for every 32 blocks of the filesystem. I have yet to see the media that would need such conversion (maybe it comes from packet writing times) and the conversions have been inconsistent in the code. In particular any write will write to a wrong block and corrupt the media. This is an indication and no user actually needs this so let's just drop the support instead of trying to fix it. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Unify types in anchor block detectionJan Kara2023-01-263-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When detecting last recorded block and from it derived anchor block position, we were mixing unsigned long, u32, and sector_t types. Since udf supports only 32-bit block numbers this is harmless but sometimes makes things awkward. Convert everything to udf_pblk_t and also handle the situation when block device size would not fit into udf_pblk_t. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Fix directory iteration for longer tail extentsJan Kara2023-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | When directory's last extent has more that one block and its length is not multiple of a block side, the code wrongly decided to move to the next extent instead of processing the last partial block. This led to directory corruption. Fix the rounding issue. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Propagate errors from udf_advance_blk()Jan Kara2023-01-261-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | When we spot directory corruption when trying to load next directory extent, we didn't propagate the error up properly, leading to possibly indefinite looping on corrupted directories. Fix the problem by propagating the error properly. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Zero udf name paddingJan Kara2023-01-261-1/+7
| | | | | | | | | | | | | | | | | | Padding of name in the directory entry needs to be zeroed out. Fix it. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: remove redundant variable netypeColin Ian King2023-01-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The variable netype is assigned a value that is never read, the assignment is redundant the variable can be removed. Message-Id: <20230105134925.45599-1-colin.i.king@gmail.com> Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Detect system inodes linked into directory hierarchyJan Kara2023-01-091-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When UDF filesystem is corrupted, hidden system inodes can be linked into directory hierarchy which is an avenue for further serious corruption of the filesystem and kernel confusion as noticed by syzbot fuzzed images. Refuse to access system inodes linked into directory hierarchy and vice versa. CC: stable@vger.kernel.org Reported-by: syzbot+38695a20b8addcbc1084@syzkaller.appspotmail.com Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Preserve link count of system filesJan Kara2023-01-093-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | System files in UDF filesystem have link count 0. To not confuse VFS we fudge the link count to be 1 when reading such inodes however we forget to restore the link count of 0 when writing such inodes. Fix that. CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Do not update file length for failed writes to inline filesJan Kara2023-01-091-14/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When write to inline file fails (or happens only partly), we still updated length of inline data as if the whole write succeeded. Fix the update of length of inline data to happen only if the write succeeds. Reported-by: syzbot+0937935b993956ba28ab@syzkaller.appspotmail.com CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Fix spelling mistake "lenght" -> "length"Colin Ian King2023-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | There is a spelling mistake in a udf_err message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20221230231452.5821-1-colin.i.king@gmail.com>
| * | udf: Keep i_lenExtents consistent with the total length of extentsJan Kara2023-01-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | When rounding the last extent to blocksize in inode_getblk() we forgot to update also i_lenExtents to match the new extent length. This inconsistency can later confuse some assertion checks. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Move setting of i_lenExtents into udf_do_extend_file()Jan Kara2023-01-091-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When expanding file for a write into a hole, we were not updating total length of inode's extents properly. Move the update of i_lenExtents into udf_do_extend_file() so that both expanding of file by truncate and expanding of file by writing beyond EOF properly update the length of extents. As a bonus, we also correctly update the length of extents when only part of extents can be written. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Allocate name buffer in directory iterator on heapJan Kara2023-01-092-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we allocate name buffer in directory iterators (struct udf_fileident_iter) on stack. These structures are relatively large (some 360 bytes on 64-bit architectures). For udf_rename() which needs to keep three of these structures in parallel the stack usage becomes rather heavy - 1536 bytes in total. Allocate the name buffer in the iterator from heap to avoid excessive stack usage. Link: https://lore.kernel.org/all/202212200558.lK9x1KW0-lkp@intel.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Handle error when adding extent to a fileJan Kara2023-01-091-14/+27
| | | | | | | | | | | | | | | | | | | | | When adding extent to a file fails, so far we've silently squelshed the error. Make sure to propagate it up properly. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Handle error when adding extent to symlinkJan Kara2023-01-091-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | When adding extent describing symlink data fails, make sure to handle the error properly, propagate it up and free the already allocated block. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Handle error when expanding directoryJan Kara2023-01-091-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | When there is an error when adding extent to the directory to expand it, make sure to propagate the error up properly. This is not expected to happen currently but let's make the code more futureproof. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Do not bother merging very long extentsJan Kara2023-01-091-17/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When merging very long extents we try to push as much length as possible to the first extent. However this is unnecessarily complicated and not really worth the trouble. Furthermore there was a bug in the logic resulting in corrupting extents in the file as syzbot reproducer shows. So just don't bother with the merging of extents that are too long together. CC: stable@vger.kernel.org Reported-by: syzbot+60f291a24acecb3c2bd5@syzkaller.appspotmail.com Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Truncate added extents on failed expansionJan Kara2023-01-091-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | When a file expansion failed because we didn't have enough space for indirect extents make sure we truncate extents created so far so that we don't leave extents beyond EOF. CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Remove old directory iteration codeJan Kara2023-01-093-705/+0
| | | | | | | | | | | | | | | | | | Remove old directory iteration code that is now unused. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_rename() to new directory iteration codeJan Kara2023-01-091-87/+78
| | | | | | | | | | | | | | | | | | | | | | | | Convert udf_rename() to use new directory iteration code. Reported-by: syzbot+0eaad3590d65102b9391@syzkaller.appspotmail.com Reported-by: syzbot+b7fc73213bc2361ab650@syzkaller.appspotmail.com Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_link() to new directory iteration codeJan Kara2023-01-091-14/+8
| | | | | | | | | | | | | | | | | | | | | Convert udf_link() to use new directory iteration code for adding entry into the directory. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_mkdir() to new directory iteration codeJan Kara2023-01-091-27/+21
| | | | | | | | | | | | | | | | | | Convert udf_mkdir() to new directory iteration code. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_add_nondir() to new directory iterationJan Kara2023-01-091-11/+8
| | | | | | | | | | | | | | | | | | Convert udf_add_nondir() to new directory iteration code. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Implement adding of dir entries using new iteration codeJan Kara2023-01-093-0/+169
| | | | | | | | | | | | | | | | | | | | | Implement function udf_fiiter_add_entry() adding new directory entries using new directory iteration code. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_unlink() to new directory iteration codeJan Kara2023-01-091-23/+10
| | | | | | | | | | | | | | | | | | Convert udf_unlink() to new directory iteration code. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_rmdir() to new directory iteration codeJan Kara2023-01-091-21/+11
| | | | | | | | | | | | | | | | | | Convert udf_rmdir() to use new directory iteration code. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Provide function to mark entry as deleted using new directory iteration ↵Jan Kara2023-01-091-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | code Provide function udf_fiiter_delete_entry() to mark directory entry as deleted using new directory iteration code. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert empty_dir() to new directory iteration codeJan Kara2023-01-091-59/+9
| | | | | | | | | | | | | | | | | | Convert empty_dir() to new directory iteration code. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_get_parent() to new directory iteration codeJan Kara2023-01-091-9/+7
| | | | | | | | | | | | | | | | | | Convert udf_get_parent() to use udf_fiiter_find_entry(). Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_lookup() to use new directory iteration codeJan Kara2023-01-091-11/+8
| | | | | | | | | | | | | | | | | | | | | Convert udf_lookup() to use udf_fiiter_find_entry() for looking up directory entries. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Implement searching for directory entry using new iteration codeJan Kara2023-01-091-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | Implement searching for directory entry - udf_fiiter_find_entry() - using new directory iteration code. Reported-by: syzbot+69c9fdccc6dd08961d34@syzkaller.appspotmail.com Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Move udf_expand_dir_adinicb() to its callsiteJan Kara2023-01-093-84/+82
| | | | | | | | | | | | | | | | | | | | | | | | There is just one caller of udf_expand_dir_adinicb(). Move the function to its caller into namei.c as it is more about directory handling than anything else anyway. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_expand_dir_adinicb() to new directory iterationJan Kara2023-01-091-37/+29
| | | | | | | | | | | | | | | | | | Convert udf_expand_dir_adinicb() to new directory iteration code. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Convert udf_readdir() to new directory iterationJan Kara2023-01-091-121/+27
| | | | | | | | | | | | | | | | | | Convert udf_readdir() to new directory iteration functions. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: New directory iteration codeJan Kara2023-01-092-0/+418
| | | | | | | | | | | | | | | | | | | | | | | | Add new support code for iterating directory entries. The code is also more carefully verifying validity of on-disk directory entries to avoid crashes on malicious media. Signed-off-by: Jan Kara <jack@suse.cz>
| * | udf: Define EFSCORRUPTED error codeJan Kara2023-01-091-0/+2
| |/ | | | | | | | | | | | | Similarly to other filesystems define EFSCORRUPTED error code for reporting internal filesystem corruption. Signed-off-by: Jan Kara <jack@suse.cz>
* | Merge tag 'fs.idmapped.v6.3' of ↵Linus Torvalds2023-02-204-12/+12
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping Pull vfs idmapping updates from Christian Brauner: - Last cycle we introduced the dedicated struct mnt_idmap type for mount idmapping and the required infrastucture in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). As promised in last cycle's pull request message this converts everything to rely on struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevant on the mount level. Especially for non-vfs developers without detailed knowledge in this area this was a potential source for bugs. This finishes the conversion. Instead of passing the plain namespace around this updates all places that currently take a pointer to a mnt_userns with a pointer to struct mnt_idmap. Now that the conversion is done all helpers down to the really low-level helpers only accept a struct mnt_idmap argument instead of two namespace arguments. Conflating mount and other idmappings will now cause the compiler to complain loudly thus eliminating the possibility of any bugs. This makes it impossible for filesystem developers to mix up mount and filesystem idmappings as they are two distinct types and require distinct helpers that cannot be used interchangeably. Everything associated with struct mnt_idmap is moved into a single separate file. With that change no code can poke around in struct mnt_idmap. It can only be interacted with through dedicated helpers. That means all filesystems are and all of the vfs is completely oblivious to the actual implementation of idmappings. We are now also able to extend struct mnt_idmap as we see fit. For example, we can decouple it completely from namespaces for users that don't require or don't want to use them at all. We can also extend the concept of idmappings so we can cover filesystem specific requirements. In combination with the vfs{g,u}id_t work we finished in v6.2 this makes this feature substantially more robust and thus difficult to implement wrong by a given filesystem and also protects the vfs. - Enable idmapped mounts for tmpfs and fulfill a longstanding request. A long-standing request from users had been to make it possible to create idmapped mounts for tmpfs. For example, to share the host's tmpfs mount between multiple sandboxes. This is a prerequisite for some advanced Kubernetes cases. Systemd also has a range of use-cases to increase service isolation. And there are more users of this. However, with all of the other work going on this was way down on the priority list but luckily someone other than ourselves picked this up. As usual the patch is tiny as all the infrastructure work had been done multiple kernel releases ago. In addition to all the tests that we already have I requested that Rodrigo add a dedicated tmpfs testsuite for idmapped mounts to xfstests. It is to be included into xfstests during the v6.3 development cycle. This should add a slew of additional tests. * tag 'fs.idmapped.v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping: (26 commits) shmem: support idmapped mounts for tmpfs fs: move mnt_idmap fs: port vfs{g,u}id helpers to mnt_idmap fs: port fs{g,u}id helpers to mnt_idmap fs: port i_{g,u}id_into_vfs{g,u}id() to mnt_idmap fs: port i_{g,u}id_{needs_}update() to mnt_idmap quota: port to mnt_idmap fs: port privilege checking helpers to mnt_idmap fs: port inode_owner_or_capable() to mnt_idmap fs: port inode_init_owner() to mnt_idmap fs: port acl to mnt_idmap fs: port xattr to mnt_idmap fs: port ->permission() to pass mnt_idmap fs: port ->fileattr_set() to pass mnt_idmap fs: port ->set_acl() to pass mnt_idmap fs: port ->get_acl() to pass mnt_idmap fs: port ->tmpfile() to pass mnt_idmap fs: port ->rename() to pass mnt_idmap fs: port ->mknod() to pass mnt_idmap fs: port ->mkdir() to pass mnt_idmap ...
| * fs: port inode_init_owner() to mnt_idmapChristian Brauner2023-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
| * fs: port ->tmpfile() to pass mnt_idmapChristian Brauner2023-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
| * fs: port ->rename() to pass mnt_idmapChristian Brauner2023-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
| * fs: port ->mknod() to pass mnt_idmapChristian Brauner2023-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
| * fs: port ->mkdir() to pass mnt_idmapChristian Brauner2023-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
| * fs: port ->symlink() to pass mnt_idmapChristian Brauner2023-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
| * fs: port ->create() to pass mnt_idmapChristian Brauner2023-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
| * fs: port ->getattr() to pass mnt_idmapChristian Brauner2023-01-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-31 04:16:43 +0000