read through and everything looks like a good spelling
correction, and on top of that this looks safe as it just comments being
changed?
How were you thinking of getting this merged?
Do we have a misc maintainer? If the individual maintainers need to
merge this than this patch should probably get split
Christian Brauner writes:
> On Wed, Aug 19, 2020 at 08:32:59AM -0500, Eric W. Biederman wrote:
>> Matthew Wilcox writes:
>>
>> > On Wed, Aug 19, 2020 at 10:45:56AM +0200, Christian Brauner wrote:
>> >> On Wed, Aug 19, 2020 at 09:43:40AM +0200, pet...@infrade
Matthew Wilcox writes:
> On Wed, Aug 19, 2020 at 10:45:56AM +0200, Christian Brauner wrote:
>> On Wed, Aug 19, 2020 at 09:43:40AM +0200, pet...@infradead.org wrote:
>> > On Tue, Aug 18, 2020 at 06:44:47PM +0100, Matthew Wilcox wrote:
>> > > On Tue, Aug 18, 2020 at 07:34:00PM +0200, Christian
are working with the community instead of trying asking the rest of
us to support something you won't share.
Nacked-by: Eric W. Biederman ebied...@xmission.com
--- linux.orig/kernel/signal.c
+++ linux/kernel/signal.c
@@ -1419,7 +1419,7 @@ out_unlock:
rcu_read_unlock();
return ret
Jason Wessel jason.wes...@windriver.com writes:
Eric W. Biederman wrote:
Jason Wessel jason.wes...@windriver.com writes:
This patch contains the hooks and instrumentation into kernel which
live outside the kernel/debug directory, which the kdb core
will call to run commands like lsmod
Pete/Piet Delaney [EMAIL PROTECTED] writes:
Jason Wessel wrote:
Shouldn't crash, kdump and kgdb take into consideration a
shift in the kernel so that gdb works normally?
Seems that having the kgdb stub knowledgeable of a shift
in the kernel might be easy to compensate for. Perhaps
just
Derek Atkins [EMAIL PROTECTED] writes:
Well, gdb agrees with System.map, so I'm sure that gdb itself is
okay. It's certainly possible that that the kgdb stub is weird,
but /proc/kallsyms doesn't match System.map, and THAT'S what's
confusing me most of all.
Ok. So we must have a relocatable
