[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160122202007.GG2262@uranus>
Date: Fri, 22 Jan 2016 23:20:07 +0300
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Christian Borntraeger <borntraeger@...ibm.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
Quentin Casasnovas <quentin.casasnovas@...cle.com>,
Vegard Nossum <vegard.nossum@...cle.com>,
Andrew Morton <akpm@...uxfoundation.org>,
Willy Tarreau <w@....eu>,
Andy Lutomirski <luto@...capital.net>,
Kees Cook <keescook@...gle.com>,
Vladimir Davydov <vdavydov@...tuozzo.com>,
Konstantin Khlebnikov <koct9i@...il.com>,
Pavel Emelyanov <xemul@...tuozzo.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH RFC] mm: Rework virtual memory accounting
On Fri, Jan 22, 2016 at 08:42:11PM +0100, Christian Borntraeger wrote:
> On 12/28/2015 11:22 PM, Linus Torvalds wrote:
> > On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> >> Really sorry for delays. Konstantin, I slightly updated the
> >> changelog (to point where problem came from). Linus are you
> >> fine with accounting not only anonymous memory in VmData?
> >
> > The patch looks ok to me. I guess if somebody relies on old behavior
> > we may have to tweak it a bit, but on the whole this looks sane and
> > I'd be happy to merge it in the 4.5 merge window (and maybe even have
> > it marked for stable if it works out)
> >
>
> Just want to mention that this patch breaks older versions of valgrind
> (including the current release)
> https://bugs.kde.org/show_bug.cgi?id=357833
> It is fixed in trunk (and even triggered some good cleanups, so the valgrind
> developers do NOT want it to get reverted). Rawhide already has the valgrind
> fix, others might not, so if we consider this for stable, things might break
> here and there, but in general this looks like a good cleanup.
>
> Christian
Thanks a huge for the report, Christian. I think this won't go for stable
for now, lets see if there are other tools which do the same trick setting
up zero to rlimit data. If indeed this would make more problems than solve
it, we might need to find a way for backward compatibility.
Powered by blists - more mailing lists