Re: Is there an recommended way to refer to bitkeepr commits?

[Eric W. Biederman]

Thomas Gleixner <tglx@xxxxxxxxxxxxx> writes:

> On Fri, 12 May 2017, Michael Ellerman wrote:
>>   Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] linux-2.5.66-signal-cleanup.patch")
>> 
>> In your tree that is c3c107051660 ("[PATCH] linux-2.5.66-signal-cleanup.patch"),
>> but you don't have the 3e8e57a1JvR25MkFRNzoz85l2Gzccg revision recorded
>> anywhere that I can see.
>
> That's correct. I did not include the BK revisions when I imported the
> commits into the history git. I did not see any reason to do so. I still
> have no idea what the value would have been or why anyone wants to
> reference them at all.

Thomas your import seems to be significantly better than the one I got
my hands on years ago.

I just know that if were to do something similar today we would really
want to preserve the existing git sha1 hashes somewhere because we
refer to commits everywhere in the code.  So I was imagining that
bitkeeper would be similar.  Especially since the copy of the bitkeeper
import into git had appened to each commit a BKrev which I presume
tacked back to the original source.

If everyone who had imported the bitkeepr tree had done that it would
not have mattered which bitkeeper import you were using they would all
share a common identifier for commits.  With that absent the robustness
we have to allow looking things up in an alternate tree lies solely
with the one line patch description.

Compare the quotes lines above with what I have below.  Every tree
appears to have a different identifier.

Below is what I wound up doing, and have queued for the next merge
window.  Comments?

Eric


From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Date: Tue, 9 May 2017 19:54:27 -0500
Subject: [PATCH] signal: Do not perform permission checks when sending pdeath_signal

This fixes and old old regression.  When Roland switched from
sending pdeath_signal with send_sig() to send_group_sig_info
it gained a permission check, and started taking the tasklist
lock.  Roland earlier fixed the double taking of the tasklist
lock in 3f2a0d1df938 ("[PATCH] fix pdeath_signal SMP locking")
but pdeath_signal still performs an unnecessary permission
check.

Ordinarily I would be hesitant at fixing an ancient regression but
a permission check for our parent sending to us is almost never
likely to fail (so it is unlikely anyone has noticed), and it
is stupid.  It makes absolutely no sense to see if our
parent has permission to send us a signal we requested be
sent to us.

As this is more permisssive there is no chance anything will break.
The information of if our parent is living is available elsewhere
getppid, tkill, and proc with no special permissions so this should
not be an information leak.

See https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/
for the bitkeeper era history that I refer to.

Fixes: da334d91ff70 ("[PATCH] linux-2.5.66-signal-cleanup.patch")
Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
---
 kernel/exit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index e126ebf2400c..6cf1f52faf5c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -693,8 +693,8 @@ static void forget_original_parent(struct task_struct *father,
 			if (likely(!t->ptrace))
 				t->parent = t->real_parent;
 			if (t->pdeath_signal)
-				group_send_sig_info(t->pdeath_signal,
-						    SEND_SIG_NOINFO, t);
+				do_send_sig_info(t->pdeath_signal,
+						 SEND_SIG_NOINFO, t, true);
 		}
 		/*
 		 * If this is a threaded reparent there is no need to
-- 
2.10.1