diff for duplicates of <87a7u0tn0i.fsf@xmission.com> diff --git a/a/1.txt b/N1/1.txt index ce0dff2..4ee5e61 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -26,51 +26,3 @@ clear_siginfo everywhere] > tries to fill in more than si_value is already broken. In fact, it > might even be worth enforcing that in rt_sigqueueinfo(), just to see > if anybody plays any games.. - - -From my earlier looking I think this is all doable except detecting -if - -> On x86-64, without the pointless padding, the size of 'struct siginfo' -> inside the kernel would be 48 bytes. That's quite a big difference for -> something that is often allocated on the kernel stack. - -From my earlier looking I can say that I know of no case where signals -are injected into the kernel that we need more bytes than the kernel -currently provides. - -The two cases I know of are signal reinjection for checkpoint/restart -or something that just uses pid, uid and ptr. Generally that is -enough. - -If we just truncate siginfo to everything except the pad bytes in the -kernel there should be no problems. What I don't see how to do is to -limit the size of struct siginfo the kernel accepts in a forward -compatible way. Something that would fail if for some reason you used -more siginfo bytes. - -Looking at userspace. glibc always memsets siginfo_t to 0. -Criu just uses whatever it captured with PTRACE_PEEKSIGINFO, -and criu uses unitialized memory for the target of PTRACE_PEEKSIGINFO. - -If we truncate siginfo in the kernel then we check for a known si_code -in which case we are safe to truncate siginfo. If the si_code is -unknown then we should check to see if the extra bytes are 0. That -should work with everything. Plus it is a natural point to test to -see if userspace is using signals that the kernel does not currently -support. - -I will put that in my queue. - -> So I'm certainly willing to make those kinds of changes, but let's -> make them real *improvements* now, ok? Wasn't that the point of all -> the cleanups in the end? - -Definitely. With the strace test case causing people to talk about -regressions I was just looking to see if it would make sense to do -something minimal for -rc2 so reduce concerns about regressions. - -Now I am going to focus on getting what I can ready for the next merge -window. - -Eric diff --git a/a/content_digest b/N1/content_digest index 711a7bd..e832b23 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -52,54 +52,6 @@ "> function doesn't copy any more than that either, so any user that\n" "> tries to fill in more than si_value is already broken. In fact, it\n" "> might even be worth enforcing that in rt_sigqueueinfo(), just to see\n" - "> if anybody plays any games..\n" - "\n" - "\n" - "From my earlier looking I think this is all doable except detecting\n" - "if\n" - "\n" - "> On x86-64, without the pointless padding, the size of 'struct siginfo'\n" - "> inside the kernel would be 48 bytes. That's quite a big difference for\n" - "> something that is often allocated on the kernel stack.\n" - "\n" - "From my earlier looking I can say that I know of no case where signals\n" - "are injected into the kernel that we need more bytes than the kernel\n" - "currently provides.\n" - "\n" - "The two cases I know of are signal reinjection for checkpoint/restart\n" - "or something that just uses pid, uid and ptr. Generally that is\n" - "enough.\n" - "\n" - "If we just truncate siginfo to everything except the pad bytes in the\n" - "kernel there should be no problems. What I don't see how to do is to\n" - "limit the size of struct siginfo the kernel accepts in a forward\n" - "compatible way. Something that would fail if for some reason you used\n" - "more siginfo bytes.\n" - "\n" - "Looking at userspace. glibc always memsets siginfo_t to 0.\n" - "Criu just uses whatever it captured with PTRACE_PEEKSIGINFO,\n" - "and criu uses unitialized memory for the target of PTRACE_PEEKSIGINFO.\n" - "\n" - "If we truncate siginfo in the kernel then we check for a known si_code\n" - "in which case we are safe to truncate siginfo. If the si_code is\n" - "unknown then we should check to see if the extra bytes are 0. That\n" - "should work with everything. Plus it is a natural point to test to\n" - "see if userspace is using signals that the kernel does not currently\n" - "support.\n" - "\n" - "I will put that in my queue.\n" - "\n" - "> So I'm certainly willing to make those kinds of changes, but let's\n" - "> make them real *improvements* now, ok? Wasn't that the point of all\n" - "> the cleanups in the end?\n" - "\n" - "Definitely. With the strace test case causing people to talk about\n" - "regressions I was just looking to see if it would make sense to do\n" - "something minimal for -rc2 so reduce concerns about regressions.\n" - "\n" - "Now I am going to focus on getting what I can ready for the next merge\n" - "window.\n" - "\n" - Eric + > if anybody plays any games.. -4bdfc73648f981dc073a1c35bcac753085642582cff9c6f337f06d0c62e37d1d +506ea98d68da79833280b70df107b2b3d6e77dcbe78934b261d95d9187db6665
diff --git a/a/1.txt b/N2/1.txt index ce0dff2..27da3f9 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -28,14 +28,14 @@ clear_siginfo everywhere] > if anybody plays any games.. -From my earlier looking I think this is all doable except detecting +>From my earlier looking I think this is all doable except detecting if > On x86-64, without the pointless padding, the size of 'struct siginfo' > inside the kernel would be 48 bytes. That's quite a big difference for > something that is often allocated on the kernel stack. -From my earlier looking I can say that I know of no case where signals +>From my earlier looking I can say that I know of no case where signals are injected into the kernel that we need more bytes than the kernel currently provides. diff --git a/a/content_digest b/N2/content_digest index 711a7bd..5aeca2f 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -55,14 +55,14 @@ "> if anybody plays any games..\n" "\n" "\n" - "From my earlier looking I think this is all doable except detecting\n" + ">From my earlier looking I think this is all doable except detecting\n" "if\n" "\n" "> On x86-64, without the pointless padding, the size of 'struct siginfo'\n" "> inside the kernel would be 48 bytes. That's quite a big difference for\n" "> something that is often allocated on the kernel stack.\n" "\n" - "From my earlier looking I can say that I know of no case where signals\n" + ">From my earlier looking I can say that I know of no case where signals\n" "are injected into the kernel that we need more bytes than the kernel\n" "currently provides.\n" "\n" @@ -102,4 +102,4 @@ "\n" Eric -4bdfc73648f981dc073a1c35bcac753085642582cff9c6f337f06d0c62e37d1d +d79327ed1bac3b3640459eb2fc073d5fc86cee0a5d1a12a5c191b49b103cf650
diff --git a/a/content_digest b/N3/content_digest index 711a7bd..70f38b4 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -13,7 +13,7 @@ "ref\0CA+55aFw1gmfFH1o+oWMo4TnU5hEczAOiY1g=eMxqYZmy9JqDYw@mail.gmail.com\0" "From\0ebiederm@xmission.com (Eric W. Biederman)\0" "Subject\0Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER\0" - "Date\0Wed, 18 Apr 2018 12:58:21 -0500\0" + "Date\0Wed, 18 Apr 2018 17:58:21 +0000\0" "To\0Linus Torvalds <torvalds@linux-foundation.org>\0" "Cc\0Dave Martin <Dave.Martin@arm.com>" Linux Kernel Mailing List <linux-kernel@vger.kernel.org> @@ -102,4 +102,4 @@ "\n" Eric -4bdfc73648f981dc073a1c35bcac753085642582cff9c6f337f06d0c62e37d1d +998a2b3af0145071463247cf34da5b298c3d8502bc37a33d83ce1f128d9c3b2d
diff --git a/a/1.txt b/N4/1.txt index ce0dff2..27da3f9 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -28,14 +28,14 @@ clear_siginfo everywhere] > if anybody plays any games.. -From my earlier looking I think this is all doable except detecting +>From my earlier looking I think this is all doable except detecting if > On x86-64, without the pointless padding, the size of 'struct siginfo' > inside the kernel would be 48 bytes. That's quite a big difference for > something that is often allocated on the kernel stack. -From my earlier looking I can say that I know of no case where signals +>From my earlier looking I can say that I know of no case where signals are injected into the kernel that we need more bytes than the kernel currently provides. diff --git a/a/content_digest b/N4/content_digest index 711a7bd..578a2b4 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -12,17 +12,9 @@ "ref\087604sa2fu.fsf_-_@xmission.com\0" "ref\0CA+55aFw1gmfFH1o+oWMo4TnU5hEczAOiY1g=eMxqYZmy9JqDYw@mail.gmail.com\0" "From\0ebiederm@xmission.com (Eric W. Biederman)\0" - "Subject\0Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER\0" + "Subject\0[RFC PATCH 0/3] Dealing with the aliases of SI_USER\0" "Date\0Wed, 18 Apr 2018 12:58:21 -0500\0" - "To\0Linus Torvalds <torvalds@linux-foundation.org>\0" - "Cc\0Dave Martin <Dave.Martin@arm.com>" - Linux Kernel Mailing List <linux-kernel@vger.kernel.org> - Dmitry V. Levin <ldv@altlinux.org> - sparclinux <sparclinux@vger.kernel.org> - ppc-dev <linuxppc-dev@lists.ozlabs.org> - linux-arm-kernel <linux-arm-kernel@lists.infradead.org> - Russell King - ARM Linux <linux@armlinux.org.uk> - " linux-arch <linux-arch@vger.kernel.org>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Linus Torvalds <torvalds@linux-foundation.org> writes:\n" @@ -55,14 +47,14 @@ "> if anybody plays any games..\n" "\n" "\n" - "From my earlier looking I think this is all doable except detecting\n" + ">From my earlier looking I think this is all doable except detecting\n" "if\n" "\n" "> On x86-64, without the pointless padding, the size of 'struct siginfo'\n" "> inside the kernel would be 48 bytes. That's quite a big difference for\n" "> something that is often allocated on the kernel stack.\n" "\n" - "From my earlier looking I can say that I know of no case where signals\n" + ">From my earlier looking I can say that I know of no case where signals\n" "are injected into the kernel that we need more bytes than the kernel\n" "currently provides.\n" "\n" @@ -102,4 +94,4 @@ "\n" Eric -4bdfc73648f981dc073a1c35bcac753085642582cff9c6f337f06d0c62e37d1d +9e6893c2a94680512ec07aadea34989e94b36b49c4a70994f671820a0b19f0a3
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.