[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YhlBUCi9O30szf6l@sol.localdomain>
Date: Fri, 25 Feb 2022 12:51:28 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Theodore Ts'o <tytso@....edu>
Cc: Lee Jones <lee.jones@...aro.org>, linux-ext4@...r.kernel.org,
Christoph Hellwig <hch@....de>,
Dave Chinner <dchinner@...hat.com>,
Goldwyn Rodrigues <rgoldwyn@...e.com>,
"Darrick J . Wong" <darrick.wong@...cle.com>,
Bob Peterson <rpeterso@...hat.com>,
Damien Le Moal <damien.lemoal@....com>,
Andreas Gruenbacher <agruenba@...hat.com>,
Ritesh Harjani <riteshh@...ux.ibm.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Johannes Thumshirn <jth@...nel.org>, linux-xfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, cluster-devel@...hat.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH -v2] ext4: don't BUG if kernel subsystems dirty pages
without asking ext4 first
On Fri, Feb 25, 2022 at 02:24:35PM -0500, Theodore Ts'o wrote:
> [un]pin_user_pages_remote is dirtying pages without properly warning
> the file system in advance (or faulting in the file data if the page
> is not yet in the page cache). This was noted by Jan Kara in 2018[1]
> and more recently has resulted in bug reports by Syzbot in various
> Android kernels[2].
>
> This is technically a bug in the mm/gup.c codepath, but arguably ext4
> is fragile in that a buggy get_user_pages() implementation causes ext4
> to crash, where as other file systems are not crashing (although in
> some cases the user data will be lost since gup code is not properly
> informing the file system to potentially allocate blocks or reserve
> space when writing into a sparse portion of file). I suspect in real
> life it is rare that people are using RDMA into file-backed memory,
> which is why no one has complained to ext4 developers except fuzzing
> programs.
>
> So instead of crashing with a BUG, issue a warning (since there may be
> potential data loss) and just mark the page as clean to avoid
> unprivileged denial of service attacks until the problem can be
> properly fixed. More discussion and background can be found in the
> thread starting at [2].
>
> [1] https://www.spinics.net/lists/linux-mm/msg142700.html
Can you use a lore link
(https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz/T/#u)?
> + /*
> + * Should never happen but for buggy code in
> + * other subsystemsa that call
subsystemsa => subsystems
> + * set_page_dirty() without properly warning
> + * the file system first. See [1] for more
> + * information.
> + *
> + * [1] https://www.spinics.net/lists/linux-mm/msg142700.html
Likewise, lore link here.
- Eric
Powered by blists - more mailing lists