linux-kernel - RE: [PATCH v2] Add the values related to buddy system for filtering free pages.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <D1EE06D5773FD14B8B7BE95DA4B3A74443203BCA@G4W3231.americas.hpqcorp.net>
Date:	Fri, 8 Feb 2013 14:59:10 +0000
From:	"Mitchell, Lisa (MCLinux in Fort Collins)" <lisa.mitchell@...com>
To:	Atsushi Kumagai <kumagai-atsushi@....nes.nec.co.jp>
CC:	"vgoyal@...hat.com" <vgoyal@...hat.com>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"d.hatayama@...fujitsu.com" <d.hatayama@...fujitsu.com>,
	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"cpw@....com" <cpw@....com>
Subject: RE: [PATCH v2] Add the values related to buddy system for filtering
 free pages.

Thanks, that's good news, and thanks for the commit ID, that was the thing I was having trouble finding.

-----Original Message-----
From: Atsushi Kumagai [mailto:kumagai-atsushi@....nes.nec.co.jp] 
Sent: Thursday, February 07, 2013 7:45 PM
To: Mitchell, Lisa (MCLinux in Fort Collins)
Cc: vgoyal@...hat.com; kexec@...ts.infradead.org; linux-kernel@...r.kernel.org; linux-mm@...ck.org; d.hatayama@...fujitsu.com; ebiederm@...ssion.com; akpm@...ux-foundation.org; cpw@....com
Subject: Re: [PATCH v2] Add the values related to buddy system for filtering free pages.

Hello Lisa,

On Thu, 07 Feb 2013 05:29:11 -0700
Lisa Mitchell <lisa.mitchell@...com> wrote:

> > > > Also, I have one question. Can we always think of 1st and 2nd 
> > > > kernels are same?
> > > 
> > > Not at all.  Distros frequently implement it with the same kernel 
> > > in both role but it should be possible to use an old crusty stable 
> > > kernel as the 2nd kernel.
> > > 
> > > > If I understand correctly, kexec/kdump can use the 2nd kernel 
> > > > different from the 1st's. So, differnet kernels need to do the 
> > > > same thing as makedumpfile does. If assuming two are same, problem is mush simplified.
> > > 
> > > As a developer it becomes attractive to use a known stable kernel 
> > > to capture the crash dump even as I experiment with a brand new kernel.
> > 
> > To allow to use the 2nd kernel different from the 1st's, I think we 
> > have to take care of each kernel version with the logic included in 
> > makedumpfile for them. That's to say, makedumpfile goes on as before.
> > 
> > 
> > Thanks
> > Atsushi Kumagai
> 
> 
> Atsushi and Vivek:  
> 
> I'm trying to get the status of whether the patch submitted in
> https://lkml.org/lkml/2012/11/21/90  is going to be accepted upstream
> and get in some version of the Linux 3.8 kernel.   I'm replying to the
> last email thread above on kexec_lists and lkml.org  that I could find 
> about this patch.
> 
> I was counting on this kernel patch to improve performance of 
> makedumpfilev1.5.1, so at least it wouldn't be a regression in
> performance over makedumpfile v1.4.   It was listed as recommended in
> the makedumpfilev1.5.1 release posting:
> http://lists.infradead.org/pipermail/kexec/2012-December/007460.html
> 
> 
> All the conversations in the thread since this patch was committed 
> seem to voice some reservations now, and reference other fixes being 
> tried to improve performance.
> 
> Does that mean you are abandoning getting this patch accepted 
> upstream, in favor of pursuing other alternatives?

No, this patch has been merged into -next, we should just wait for it to be merged into linus tree.

  http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=0c63e90dd1c7b35ae2ea9475ba67cf68d8801a26

What interests us now is improvement for interfaces of /proc/vmcore, it's not alternative but another idea which can be consistent with this patch.


Thanks
Atsushi Kumagai

> 
> I had hoped this patch would be okay to get accepted upstream, and 
> then other improvements could be built on top of it.
> 
> Is that not the case?   
> 
> Or has further review concluded now that this change is a bad idea due 
> to adding dependence of this new makedumpfile feature on some deep 
> kernel memory internals?
> 
> Thanks,
> 
> Lisa Mitchell
> 
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/