From: Greg Kroah-Hartman <email@example.com> To: Al Viro <firstname.lastname@example.org> Cc: Kees Cook <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Michal Hocko <email@example.com>, Alexey Dobriyan <firstname.lastname@example.org>, Lee Duncan <email@example.com>, Chris Leech <firstname.lastname@example.org>, Adam Nichols <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v2] seq_file: Unconditionally use vmalloc for buffer Date: Tue, 16 Mar 2021 13:55:53 +0100 [thread overview] Message-ID: <YFCq2TeHAl1s8/TX@kroah.com> (raw) In-Reply-To: <YFCn4ERBMGoqxvUU@zeniv-ca.linux.org.uk> On Tue, Mar 16, 2021 at 12:43:12PM +0000, Al Viro wrote: > On Tue, Mar 16, 2021 at 08:24:50AM +0100, Greg Kroah-Hartman wrote: > > > > Completely agreed. seq_get_buf() should be totally ripped out. > > > Unfortunately, this is going to be a long road because of sysfs's ATTR > > > stuff, there are something like 5000 callers, and the entire API was > > > designed to avoid refactoring all those callers from > > > sysfs_kf_seq_show(). > > > > What is wrong with the sysfs ATTR stuff? That should make it so that we > > do not have to change any caller for any specific change like this, why > > can't sysfs or kernfs handle it automatically? > > Hard to tell, since that would require _finding_ the sodding ->show() > instances first. Good luck with that, seeing that most of those appear > to come from templates-done-with-cpp... Sure, auditing all of this is a pain, but the numbers that take a string are low if someone wants to do that and convert them all to sysfs_emit() today. > AFAICS, Kees wants to protect against ->show() instances stomping beyond > the page size. What I don't get is what do you get from using seq_file > if you insist on doing raw access to the buffer rather than using > seq_printf() and friends. What's the point? I don't understand as I didn't switch kernfs to this api at all anyway, as it seems to have come from the original sysfs code moving to kernfs way back in 2013 with the work that Tejun did. So I can't remember any of that... thanks, greg k-h
next prev parent reply other threads:[~2021-03-16 12:57 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-15 17:48 Kees Cook 2021-03-15 18:33 ` Al Viro 2021-03-15 20:43 ` Kees Cook 2021-03-16 7:24 ` Greg Kroah-Hartman 2021-03-16 12:43 ` Al Viro 2021-03-16 12:55 ` Greg Kroah-Hartman [this message] 2021-03-16 13:01 ` Michal Hocko 2021-03-16 19:18 ` Kees Cook 2021-03-17 10:44 ` Greg Kroah-Hartman 2021-03-16 8:31 ` Michal Hocko 2021-03-16 19:08 ` Kees Cook 2021-03-17 12:08 ` Michal Hocko 2021-03-17 13:34 ` Greg Kroah-Hartman 2021-03-17 14:44 ` Michal Hocko 2021-03-17 14:56 ` Greg Kroah-Hartman 2021-03-17 15:20 ` Michal Hocko 2021-03-17 15:38 ` Greg Kroah-Hartman 2021-03-17 15:48 ` Michal Hocko 2021-03-17 21:30 ` Kees Cook 2021-03-18 8:07 ` Greg Kroah-Hartman 2021-03-18 15:51 ` Kees Cook 2021-03-18 17:56 ` Greg Kroah-Hartman 2021-03-19 14:07 ` [seq_file] 5fd6060e50: stress-ng.eventfd.ops_per_sec -49.1% regression kernel test robot 2021-03-19 19:31 ` Kees Cook
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=YFCq2TeHAl1s8/TX@kroah.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2] seq_file: Unconditionally use vmalloc for buffer' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).