diff for duplicates of <87h904xc26.fsf@xmission.com> diff --git a/a/1.txt b/N1/1.txt index e900c03..fb32f9d 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -48,7 +48,7 @@ __must_check bool refcount_add_not_zero(unsigned int i, refcount_t *r) Why in the world do you succeed when you the value saturates???? ->From a code perspective that is bizarre. The code already has to handle +From a code perspective that is bizarre. The code already has to handle the case when the counter does not increment. So since we already have to have that code to handle the failure to diff --git a/a/content_digest b/N1/content_digest index 9c4deb0..16e6f7e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,7 +3,7 @@ "ref\0CAGXu5jKNChaVdfbM171FYkvY1hUMXG6cp-=WAdXBP0eTOO5RAA@mail.gmail.com\0" "ref\020170529083903.GA17735@infradead.org\0" "From\0ebiederm@xmission.com (Eric W. Biederman)\0" - "Subject\0[kernel-hardening] Re: [PATCH 0/3] ipc subsystem refcounter conversions\0" + "Subject\0Re: [PATCH 0/3] ipc subsystem refcounter conversions\0" "Date\0Mon, 29 May 2017 04:11:13 -0500\0" "To\0Christoph Hellwig <hch@infradead.org>\0" "Cc\0Kees Cook <keescook@chromium.org>" @@ -25,8 +25,7 @@ David S. Miller <davem@davemloft.net> Rik van Riel <riel@redhat.com> linux-arch <linux-arch@vger.kernel.org> - kernel-hardening@lists.openwall.com <kernel-hardening@lists.openwall.com> - " LKML <linux-kernel@vger.kernel.org>\0" + " kernel-hardening@lists.openwall.com\0" "\00:1\0" "b\0" "Christoph Hellwig <hch@infradead.org> writes:\n" @@ -79,7 +78,7 @@ "\n" "Why in the world do you succeed when you the value saturates????\n" "\n" - ">From a code perspective that is bizarre. The code already has to handle\n" + "From a code perspective that is bizarre. The code already has to handle\n" "the case when the counter does not increment.\n" "\n" "So since we already have to have that code to handle the failure to\n" @@ -102,4 +101,4 @@ "\n" Eric -c20c561a327ed3cdbc7ca35afdefdedf9acceff2ca0edd19f24a34caf75fc0ff +16f53742dc6de77556731ee59771cd905bab65b05905b52ff58a0157f08ec1e7
diff --git a/a/1.txt b/N2/1.txt index e900c03..c9310b1 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -47,26 +47,3 @@ __must_check bool refcount_add_not_zero(unsigned int i, refcount_t *r) } Why in the world do you succeed when you the value saturates???? - ->From a code perspective that is bizarre. The code already has to handle -the case when the counter does not increment. - -So since we already have to have that code to handle the failure to -increment I think it would make much more sense if the counters did not -only saturate but report failure when the counter can not increment. - -Right now I am inclined to NACK refcount_t conversions because their -semantics don't make sense. Which would seem to make the code less -correct by introducing bizarre corner cases instead of letting the code -use the it's existing handling of the failure to increment or decrement -the counter. - -Fixing the return value would move refcount_t into the realm of -something that is desirable because it has bettern semantics and -is more useful just on a day to day correctness point of view. Even -ignoring the security implications. - -I suspect that would also make it easier for refcount_t implementations -to produce efficient code. - -Eric diff --git a/a/content_digest b/N2/content_digest index 9c4deb0..155865a 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -3,7 +3,7 @@ "ref\0CAGXu5jKNChaVdfbM171FYkvY1hUMXG6cp-=WAdXBP0eTOO5RAA@mail.gmail.com\0" "ref\020170529083903.GA17735@infradead.org\0" "From\0ebiederm@xmission.com (Eric W. Biederman)\0" - "Subject\0[kernel-hardening] Re: [PATCH 0/3] ipc subsystem refcounter conversions\0" + "Subject\0Re: [PATCH 0/3] ipc subsystem refcounter conversions\0" "Date\0Mon, 29 May 2017 04:11:13 -0500\0" "To\0Christoph Hellwig <hch@infradead.org>\0" "Cc\0Kees Cook <keescook@chromium.org>" @@ -77,29 +77,6 @@ " return true;\n" "}\n" "\n" - "Why in the world do you succeed when you the value saturates????\n" - "\n" - ">From a code perspective that is bizarre. The code already has to handle\n" - "the case when the counter does not increment.\n" - "\n" - "So since we already have to have that code to handle the failure to\n" - "increment I think it would make much more sense if the counters did not\n" - "only saturate but report failure when the counter can not increment.\n" - "\n" - "Right now I am inclined to NACK refcount_t conversions because their\n" - "semantics don't make sense. Which would seem to make the code less\n" - "correct by introducing bizarre corner cases instead of letting the code\n" - "use the it's existing handling of the failure to increment or decrement\n" - "the counter.\n" - "\n" - "Fixing the return value would move refcount_t into the realm of\n" - "something that is desirable because it has bettern semantics and\n" - "is more useful just on a day to day correctness point of view. Even\n" - "ignoring the security implications.\n" - "\n" - "I suspect that would also make it easier for refcount_t implementations\n" - "to produce efficient code.\n" - "\n" - Eric + Why in the world do you succeed when you the value saturates???? -c20c561a327ed3cdbc7ca35afdefdedf9acceff2ca0edd19f24a34caf75fc0ff +63fa9964bf1a5f753a61b8ed35dfb35e44e214e3bd0661b22a64ecd97952544b
diff --git a/a/content_digest b/N3/content_digest index 9c4deb0..db4219e 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -3,7 +3,7 @@ "ref\0CAGXu5jKNChaVdfbM171FYkvY1hUMXG6cp-=WAdXBP0eTOO5RAA@mail.gmail.com\0" "ref\020170529083903.GA17735@infradead.org\0" "From\0ebiederm@xmission.com (Eric W. Biederman)\0" - "Subject\0[kernel-hardening] Re: [PATCH 0/3] ipc subsystem refcounter conversions\0" + "Subject\0Re: [PATCH 0/3] ipc subsystem refcounter conversions\0" "Date\0Mon, 29 May 2017 04:11:13 -0500\0" "To\0Christoph Hellwig <hch@infradead.org>\0" "Cc\0Kees Cook <keescook@chromium.org>" @@ -17,15 +17,15 @@ arozansk@redhat.com Davidlohr Bueso <dave@stgolabs.net> Manfred Spraul <manfred@colorfullife.com> - axboe@kernel.dk <axboe@kernel.dk> + " axboe\\@kernel.dk <axboe@kernel.dk>" James Bottomley <James.Bottomley@hansenpartnership.com> - x86@kernel.org <x86@kernel.org> + " x86\\@kernel.org <x86@kernel.org>" Ingo Molnar <mingo@kernel.org> Arnd Bergmann <arnd@arndb.de> David S. Miller <davem@davemloft.net> Rik van Riel <riel@redhat.com> linux-arch <linux-arch@vger.kernel.org> - kernel-hardening@lists.openwall.com <kernel-hardening@lists.openwall.com> + " kernel-hardening\\@lists.openwall.com <kernel-hardening@lists.openwall.com>" " LKML <linux-kernel@vger.kernel.org>\0" "\00:1\0" "b\0" @@ -102,4 +102,4 @@ "\n" Eric -c20c561a327ed3cdbc7ca35afdefdedf9acceff2ca0edd19f24a34caf75fc0ff +726809e07c0f0000c4e16d997cecba3ad8f30c6d79a421c0365e9cd8a49140b7
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.