From: Ingo Molnar <mingo@kernel.org>
To: Christoph Lameter <cl@linux.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Al Viro <viro@ZenIV.linux.org.uk>,
Vince Weaver <vincent.weaver@maine.edu>,
linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
trinity@vger.kernel.org, akpm@linux-foundation.org,
torvalds@linux-foundation.org, roland@kernel.org,
infinipath@qlogic.com, linux-mm@kvack.org,
linux-rdma@vger.kernel.org, Or Gerlitz <or.gerlitz@gmail.com>,
Hugh Dickins <hughd@google.com>
Subject: [regression] Re: [RFC][PATCH] mm: Fix RLIMIT_MEMLOCK
Date: Wed, 29 May 2013 09:58:45 +0200 [thread overview]
Message-ID: <20130529075845.GA24506@gmail.com> (raw)
In-Reply-To: <0000013eec0006ee-0f8caf7b-cc94-4f54-ae38-0ca6623b7841-000000@email.amazonses.com>
* Christoph Lameter <cl@linux.com> wrote:
> On Mon, 27 May 2013, Peter Zijlstra wrote:
>
> > Before your patch pinned was included in locked and thus RLIMIT_MEMLOCK
> > had a single resource counter. After your patch RLIMIT_MEMLOCK is
> > applied separately to both -- more or less.
>
> Before the patch the count was doubled since a single page was counted
> twice: Once because it was mlocked (marked with PG_mlock) and then again
> because it was also pinned (the refcount was increased). Two different
> things.
Christoph, why are you *STILL* arguing??
You caused a *regression* in a userspace ABI plain and simple, and a
security relevant one. Furtermore you modified kernel/events/core.c yet
you never even Cc:-ed the parties involved ...
All your excuses, obfuscation and attempts to redefine the universe to
your liking won't change reality: it worked before, it does not now. Take
responsibility for your action for christ's sake and move forward towards
a resolution , okay?
When can we expect a fix from you for the breakage you caused? Or at least
a word that acknowledges that you broke a user ABI carelessly?
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Christoph Lameter <cl@linux.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Al Viro <viro@ZenIV.linux.org.uk>,
Vince Weaver <vincent.weaver@maine.edu>,
linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
trinity@vger.kernel.org, akpm@linux-foundation.org,
torvalds@linux-foundation.org, roland@kernel.org,
infinipath@qlogic.com, linux-mm@kvack.org,
linux-rdma@vger.kernel.org, Or Gerlitz <or.gerlitz@gmail.com>,
Hugh Dickins <hughd@google.com>
Subject: [regression] Re: [RFC][PATCH] mm: Fix RLIMIT_MEMLOCK
Date: Wed, 29 May 2013 09:58:45 +0200 [thread overview]
Message-ID: <20130529075845.GA24506@gmail.com> (raw)
In-Reply-To: <0000013eec0006ee-0f8caf7b-cc94-4f54-ae38-0ca6623b7841-000000@email.amazonses.com>
* Christoph Lameter <cl@linux.com> wrote:
> On Mon, 27 May 2013, Peter Zijlstra wrote:
>
> > Before your patch pinned was included in locked and thus RLIMIT_MEMLOCK
> > had a single resource counter. After your patch RLIMIT_MEMLOCK is
> > applied separately to both -- more or less.
>
> Before the patch the count was doubled since a single page was counted
> twice: Once because it was mlocked (marked with PG_mlock) and then again
> because it was also pinned (the refcount was increased). Two different
> things.
Christoph, why are you *STILL* arguing??
You caused a *regression* in a userspace ABI plain and simple, and a
security relevant one. Furtermore you modified kernel/events/core.c yet
you never even Cc:-ed the parties involved ...
All your excuses, obfuscation and attempts to redefine the universe to
your liking won't change reality: it worked before, it does not now. Take
responsibility for your action for christ's sake and move forward towards
a resolution , okay?
When can we expect a fix from you for the breakage you caused? Or at least
a word that acknowledges that you broke a user ABI carelessly?
Thanks,
Ingo
next prev parent reply other threads:[~2013-05-29 7:58 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-22 19:35 OOPS in perf_mmap_close() Vince Weaver
2013-05-22 19:35 ` Vince Weaver
2013-05-22 23:56 ` Vince Weaver
2013-05-23 3:48 ` Vince Weaver
2013-05-23 4:48 ` Al Viro
2013-05-23 10:41 ` Peter Zijlstra
2013-05-23 14:09 ` Christoph Lameter
2013-05-23 15:24 ` Peter Zijlstra
2013-05-23 16:12 ` Christoph Lameter
2013-05-23 16:39 ` Peter Zijlstra
2013-05-23 17:59 ` Christoph Lameter
2013-05-23 19:24 ` Peter Zijlstra
2013-05-24 14:01 ` [RFC][PATCH] mm: Fix RLIMIT_MEMLOCK Peter Zijlstra
2013-05-24 14:01 ` Peter Zijlstra
2013-05-24 15:40 ` Christoph Lameter
2013-05-24 15:40 ` Christoph Lameter
2013-05-26 1:11 ` KOSAKI Motohiro
2013-05-26 1:11 ` KOSAKI Motohiro
2013-05-28 16:19 ` Christoph Lameter
2013-05-28 16:19 ` Christoph Lameter
2013-05-27 6:48 ` Peter Zijlstra
2013-05-27 6:48 ` Peter Zijlstra
2013-05-28 16:37 ` Christoph Lameter
2013-05-28 16:37 ` Christoph Lameter
2013-05-29 7:58 ` Ingo Molnar [this message]
2013-05-29 7:58 ` [regression] " Ingo Molnar
2013-05-29 19:53 ` KOSAKI Motohiro
2013-05-29 19:53 ` KOSAKI Motohiro
2013-05-30 6:32 ` Ingo Molnar
2013-05-30 6:32 ` Ingo Molnar
2013-05-30 20:42 ` KOSAKI Motohiro
2013-05-30 20:42 ` KOSAKI Motohiro
2013-05-31 9:27 ` Ingo Molnar
2013-05-31 9:27 ` Ingo Molnar
2013-05-30 18:30 ` Peter Zijlstra
2013-05-30 18:30 ` Peter Zijlstra
2013-05-30 19:59 ` Pekka Enberg
2013-05-30 19:59 ` Pekka Enberg
2013-05-30 21:00 ` KOSAKI Motohiro
2013-05-30 21:00 ` KOSAKI Motohiro
2013-05-23 12:52 ` OOPS in perf_mmap_close() Peter Zijlstra
2013-05-23 14:10 ` Vince Weaver
2013-05-23 15:26 ` Peter Zijlstra
2013-05-23 15:47 ` Vince Weaver
2013-05-23 23:40 ` Vince Weaver
2013-05-24 9:21 ` Peter Zijlstra
2013-05-28 8:55 ` Peter Zijlstra
2013-05-28 13:29 ` [tip:perf/urgent] perf: Fix perf mmap bugs tip-bot for Peter Zijlstra
2013-06-04 8:44 ` Peter Zijlstra
2013-06-05 11:55 ` Peter Zijlstra
2013-06-19 18:38 ` [tip:perf/core] perf: Fix mmap() accounting hole tip-bot for Peter Zijlstra
2013-05-28 16:19 ` OOPS in perf_mmap_close() Vince Weaver
2013-05-28 18:22 ` Vince Weaver
2013-05-29 7:44 ` Peter Zijlstra
2013-05-29 13:17 ` Vince Weaver
2013-05-29 19:18 ` Vince Weaver
2013-05-30 7:25 ` Peter Zijlstra
2013-05-30 12:51 ` Vince Weaver
2013-05-31 15:46 ` Peter Zijlstra
2013-06-03 13:26 ` Peter Zijlstra
2013-06-03 17:18 ` Peter Zijlstra
2013-06-03 19:25 ` Peter Zijlstra
2013-06-05 15:54 ` Vince Weaver
2013-06-05 16:54 ` Peter Zijlstra
2013-05-29 8:07 ` Ingo Molnar
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=20130529075845.GA24506@gmail.com \
--to=mingo@kernel.org \
--cc=acme@ghostprotocols.net \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=hughd@google.com \
--cc=infinipath@qlogic.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=or.gerlitz@gmail.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=roland@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=trinity@vger.kernel.org \
--cc=vincent.weaver@maine.edu \
--cc=viro@ZenIV.linux.org.uk \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.