lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 4 Jun 2019 10:00:43 +0200 From: Jan Kara <jack@...e.cz> To: Amir Goldstein <amir73il@...il.com> Cc: Jan Kara <jack@...e.cz>, Ext4 <linux-ext4@...r.kernel.org>, Ted Tso <tytso@....edu>, Linux MM <linux-mm@...ck.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, stable <stable@...r.kernel.org>, Miklos Szeredi <miklos@...redi.hu> Subject: Re: [PATCH 1/2] mm: Add readahead file operation On Mon 03-06-19 19:16:59, Amir Goldstein wrote: > On Mon, Jun 3, 2019 at 4:22 PM Jan Kara <jack@...e.cz> wrote: > > > > Some filesystems need to acquire locks before pages are read into page > > cache to protect from races with hole punching. The lock generally > > cannot be acquired within readpage as it ranks above page lock so we are > > left with acquiring the lock within filesystem's ->read_iter > > implementation for normal reads and ->fault implementation during page > > faults. That however does not cover all paths how pages can be > > instantiated within page cache - namely explicitely requested readahead. > > Add new ->readahead file operation which filesystem can use for this. > > > > CC: stable@...r.kernel.org # Needed by following ext4 fix > > Signed-off-by: Jan Kara <jack@...e.cz> > > --- > > include/linux/fs.h | 5 +++++ > > include/linux/mm.h | 3 --- > > mm/fadvise.c | 12 +----------- > > mm/madvise.c | 3 ++- > > mm/readahead.c | 26 ++++++++++++++++++++++++-- > > 5 files changed, 32 insertions(+), 17 deletions(-) > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index f7fdfe93e25d..9968abcd06ea 100644 > > --- a/include/linux/fs.h > > +++ b/include/linux/fs.h > > @@ -1828,6 +1828,7 @@ struct file_operations { > > struct file *file_out, loff_t pos_out, > > loff_t len, unsigned int remap_flags); > > int (*fadvise)(struct file *, loff_t, loff_t, int); > > + int (*readahead)(struct file *, loff_t, loff_t); > > The new method is redundant, because it is a subset of fadvise. > When overlayfs needed to implement both methods, Miklos > suggested that we unite them into one, hence: > 3d8f7615319b vfs: implement readahead(2) using POSIX_FADV_WILLNEED Yes, I've noticed this. > So you can accomplish the ext4 fix without the new method. > All you need extra is implementing madvise_willneed() with vfs_fadvise(). Ah, that's an interesting idea. I'll try that out. It will require some dance in madvise() to drop mmap_sem but we already do that for madvise_free() so I can just duplicate that. Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists