On Fri 15-11-24 10:30:22, Josef Bacik wrote: > From: Amir Goldstein <amir73il@xxxxxxxxx> > > Generate FS_PRE_ACCESS event before truncate, without sb_writers held. > > Move the security hooks also before sb_start_write() to conform with > other security hooks (e.g. in write, fallocate). > > The event will have a range info of the page surrounding the new size > to provide an opportunity to fill the conetnt at the end of file before > truncating to non-page aligned size. > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> I was thinking about this. One small issue is that similarly as the filesystems may do RMW of tail page during truncate, they will do RMW of head & tail pages on hole punch or zero range so we should have some strategically sprinkled fsnotify_truncate_perm() calls there as well. That's easy enough to fix. But there's another problem which I'm more worried about: If we have a file 64k large, user punches 12k..20k and then does read for 0..64k, then how does HSM daemon in userspace know what data to fill in? When we'll have modify pre-content event, daemon can watch it and since punch will send modify for 12k-20k, the daemon knows the local (empty) page cache is the source of truth. But without modify event this is just a recipe for data corruption AFAICT. So it seems the current setting with access pre-content event has only chance to work reliably in read-only mode? So we should probably refuse writeable open if file is being watched for pre-content events and similarly refuse truncate? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
