[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20231125-kurhotel-zuwege-10cce62a50fd@brauner>
Date: Sat, 25 Nov 2023 15:04:24 +0100
From: Christian Brauner <brauner@...nel.org>
To: Omar Sandoval <osandov@...ndov.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Omar Sandoval <osandov@...com>,
David Howells <dhowells@...hat.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] vfs fixes
On Sat, Nov 25, 2023 at 05:28:49AM -0800, Omar Sandoval wrote:
> On Sat, Nov 25, 2023 at 02:10:52PM +0100, Christian Brauner wrote:
> > On Fri, Nov 24, 2023 at 10:25:15AM -0800, Linus Torvalds wrote:
> > > On Fri, 24 Nov 2023 at 02:28, Christian Brauner <brauner@...nel.org> wrote:
> > > >
> > > > * Fix a bug introduced with the iov_iter rework from last cycle.
> > > >
> > > > This broke /proc/kcore by copying too much and without the correct
> > > > offset.
> > >
> > > Ugh. I think the whole /proc/kcore vmalloc handling is just COMPLETELY broken.
> >
> > Ugh, I didn't even look at that closely because the fix was obviously
> > correct for that helper alone. Let's try and just return zeroed memory
> > like you suggested in your last mail before we bother fixing any of
> > this.
> >
> > Long-term plan, it'd be nice to just get distros to start turning
> > /proc/kcore off. Maybe I underestimate legitimate users but this
> > requires CAP_SYS_RAW_IO so it really can only be useful to pretty
> > privileged stuff anyway.
>
> drgn needs /proc/kcore for debugging the live kernel, which is a very
> important use case for lots of our users. And it does in fact read from
> KCORE_VMALLOC segments, which is why I found and fixed this bug. I'm
> happy to clean up this code, although it's a holiday weekend here so I
> won't get to it immediately of course. But please don't rip this out.
Ugh, I see. I just grepped through the drgn repo. I didn't realize that
you were actively using it and not just testing it. If this is actively
used then we won't break you ofc.
And yeah, if you would fix it that would be great. Given that you're the
main active user who happens to have kernel experience you might even
want to be made responsible for this file in the future. ;)
Powered by blists - more mailing lists