Re: [PATCH v2 0/4] Report overlayfs file ids with fanotify

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 13, 2023 at 3:03 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> Miklos,
>
> This is the second part of the work to support fanotify reporting of
> events with file ids on overlayfs.  The fanotify_event_info_fid struct
> reported with fanotify events has an object file handle and an fsid,
> so fanotify requires that filesystems can encode file handles and have
> a non-zero f_fsid.
>
> The first part [1] that was merged to v6.5-rc1, relaxed the fanotify
> requirements for filesystems to support reporting events with fid to
> require only the ->encode_fh() export operation.
>
> Patch 1 changes overlayfs export_operations to meet the new requirements
> with the default overlay configurations (i.e. no need for nfs_export=on),
> thus, allowing an fanotify watch with FAN_REPORT_FID on overlayfs.
> There are LTS tests [2] for fanotify(FAN_REPORT_FID) + overlayfs.
>
> Patches 2-4 are not strcitly needed to support reporting fanotify events
> with fid, because overlayfs already reports a non-zero f_fsid, it's just
> not a unique fsid.  So before allowing to report events with overlayfs
> fids, I wanted to fix overlayfs fsid to be more unique.
>
> I wanted to implement a persistent and unique fsid for overlayfs.
> I wanted it to be the default behavior, but needed to avoid breaking
> applications that rely on an existing overlayfs fsid to persist.
> I came up with a solution that is described in patch 4 (uuid=auto) that
> meets all the requirement above.
> There is an xfstest to test the persistent-unique fsid feature [3].
>
> This patch set has been in overlayfs-next for soaking since v6.5-rc1.
> If you have any reservations that we will not be able to resolve in time
> for 6.6, especially regarding the on-disk format and backward compat,
> we could also merge only patch 1 and leave the fsid patches for later.
>

Hi Miklos,

Any comments on this series (which is currently on overlayfs-next)?

Please let me know if you want me to take care of the 6.6 PR or
if you intend to prepare it yourself.

Other candidates for 6.6 include:
- ovl lock re-ordering
https://lore.kernel.org/linux-unionfs/20230720153731.420290-1-amir73il@xxxxxxxxx/
- CONFIG_OVERLAY_FS_DEBUG
https://lore.kernel.org/linux-unionfs/20230521082813.17025-1-andrea.righi@xxxxxxxxxxxxx/

Thanks,
Amir.

>
> [1] https://lore.kernel.org/linux-fsdevel/20230425130105.2606684-1-amir73il@xxxxxxxxx/
> [2] https://github.com/amir73il/ltp/commits/ovl_encode_fid
> [3] https://github.com/amir73il/xfstests/commits/ovl_fsid
>
>
> Amir Goldstein (4):
>   ovl: support encoding non-decodable file handles
>   ovl: add support for unique fsid per instance
>   ovl: store persistent uuid/fsid with uuid=on
>   ovl: auto generate uuid for new overlay filesystems
>
>  Documentation/filesystems/overlayfs.rst | 25 ++++++++++
>  fs/overlayfs/copy_up.c                  |  2 +-
>  fs/overlayfs/export.c                   | 26 ++++++++---
>  fs/overlayfs/inode.c                    |  2 +-
>  fs/overlayfs/namei.c                    |  5 +-
>  fs/overlayfs/overlayfs.h                | 22 +++++++++
>  fs/overlayfs/ovl_entry.h                |  3 +-
>  fs/overlayfs/params.c                   | 31 +++++++++++--
>  fs/overlayfs/super.c                    | 29 ++++++++++--
>  fs/overlayfs/util.c                     | 61 +++++++++++++++++++++++++
>  10 files changed, 186 insertions(+), 20 deletions(-)
>
> --
> 2.34.1
>




[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux