From: Theodore Ts'o <tytso@mit.edu>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Jin Qian <jinqian@android.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jeff Layton <jlayton@poochiereds.net>,
"J. Bruce Fields" <bfields@fieldses.org>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jin Qian <jinqian@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCHv2 1/1] ext4: don't put symlink in pagecache into highmem
Date: Tue, 6 Feb 2018 21:16:17 -0500 [thread overview]
Message-ID: <20180207021617.GD1977@thunk.org> (raw)
In-Reply-To: <20180206233809.GA159960@gmail.com>
On Tue, Feb 06, 2018 at 03:38:09PM -0800, Eric Biggers wrote:
> I don't think backporting this change for other filesystems is particularly
> important, since if I understand correctly, the reasons that Al made the change
> originally were:
>
> - to allow following symlinks in RCU mode, but that's not implemented in old
> kernels
Yup.
> - to prevent a process from using up all kmaps and deadlocking the system, which
> I'm not sure is a real problem (someone would need to try to put together a
> reproducer), but if so it would probably just be a local device of service.
.. and *that's* only a problem on 32-bit systems. And aside from
Android, it's unclear to me how much we need to support 32-bit systems
on upstream LTS kernels. I suppose there might be Rasperry PI's which
are 32-bits and which might want to use btrfs. Personally I'm not
sure we should care all that much, but others who care more about LTS
kernels and 32-bit systems might have a different opinion.
> Also if we actually backported the full commit there are follow-on fixes such as
> e8ecde25f5e that would be needed as well but might be missed.
Good point.
- Ted
prev parent reply other threads:[~2018-02-07 2:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-06 19:09 [PATCHv2 1/1] ext4: don't put symlink in pagecache into highmem Jin Qian
2018-02-06 20:39 ` Greg KH
2018-02-06 23:11 ` Theodore Ts'o
2018-02-06 23:38 ` Eric Biggers
2018-02-06 23:56 ` Jin Qian
2018-02-07 2:16 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180207021617.GD1977@thunk.org \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=bfields@fieldses.org \
--cc=ebiggers3@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jinqian@android.com \
--cc=jinqian@google.com \
--cc=jlayton@poochiereds.net \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.