Dmitry Vyukov writes:
> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> wrote:
>> Dmitry Vyukov writes:
>>
>>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
>>> wrote:
>>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>&
Dmitry Vyukov writes:
> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> wrote:
>> Dmitry Vyukov writes:
>>
>>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
>>> wrote:
>>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>&
Steve French writes:
> On Thu, Aug 16, 2018 at 2:56 AM Eric W. Biederman
> wrote:
>>
>> David Howells writes:
>>
>> > Having just re-ported NFS on top of the new mount API stuff, I find that I
>> > don't really like the idea of superblocks being
Steve French writes:
> On Thu, Aug 16, 2018 at 2:56 AM Eric W. Biederman
> wrote:
>>
>> David Howells writes:
>>
>> > Having just re-ported NFS on top of the new mount API stuff, I find that I
>> > don't really like the idea of superblocks being
me to notify,
> also he has been testing this oneliner patch. I'm out
> of sources at the moment but I think Andrew will help
> to test if needed.
I noticed a similar report from syzbot yesterday and I applied the patch
below. Can you verify it fixes your issue?
Eric
>From 84fe4cc09abc1
me to notify,
> also he has been testing this oneliner patch. I'm out
> of sources at the moment but I think Andrew will help
> to test if needed.
I noticed a similar report from syzbot yesterday and I applied the patch
below. Can you verify it fixes your issue?
Eric
>From 84fe4cc09abc1
David Howells writes:
> Having just re-ported NFS on top of the new mount API stuff, I find that I
> don't really like the idea of superblocks being separated by communication
> parameters - especially when it might seem reasonable to be able to adjust
> those parameters.
>
> Does it make sense
David Howells writes:
> Having just re-ported NFS on top of the new mount API stuff, I find that I
> don't really like the idea of superblocks being separated by communication
> parameters - especially when it might seem reasonable to be able to adjust
> those parameters.
>
> Does it make sense
.
Fixes: 019191342fec ("signal: Use PIDTYPE_TGID to clearly store where file
signals will be sent")
Reported-by: syzkaller-b...@googlegroups.com
Signed-off-by: "Eric W. Biederman"
---
fs/fcntl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/
.
Fixes: 019191342fec ("signal: Use PIDTYPE_TGID to clearly store where file
signals will be sent")
Reported-by: syzkaller-b...@googlegroups.com
Signed-off-by: "Eric W. Biederman"
---
fs/fcntl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/
Dmitry Vyukov writes:
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> wrote:
>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>>> syzbot has found a reproducer for the following crash on:
>>>
>>> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
>>> git
Dmitry Vyukov writes:
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> wrote:
>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>>> syzbot has found a reproducer for the following crash on:
>>>
>>> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
>>> git
writes:
> ebied...@xmission.com writes
>> Subject: [PATCH v6 6/6] signal: Don't restart fork when signals come in.
>>
>> Wen Yang and majiang
>> report that a periodic signal received during fork can cause fork to
>> continually restart preventing an application from making progress.
>>
>>
writes:
> ebied...@xmission.com writes
>> Subject: [PATCH v6 6/6] signal: Don't restart fork when signals come in.
>>
>> Wen Yang and majiang
>> report that a periodic signal received during fork can cause fork to
>> continually restart preventing an application from making progress.
>>
>>
/show_bug.cgi?id=200447
Reported-by: Wen Yang and
Reported-by: majiang
Fixes: 4a2c7a7837da ("[PATCH] make fork() atomic wrt pgrp/session signals")
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8 +++
init/init_task.c |
/show_bug.cgi?id=200447
Reported-by: Wen Yang and
Reported-by: majiang
Fixes: 4a2c7a7837da ("[PATCH] make fork() atomic wrt pgrp/session signals")
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8 +++
init/init_task.c |
writes:
> EricW.Biederman wrote:
>> Add a function calculate_sigpending to test to see if any signals are
>> pending for a new task immediately following fork. Signals have to
>> happen either before or after fork. Today our practice is to push
>> all of the signals to before the fork, but that
writes:
> EricW.Biederman wrote:
>> Add a function calculate_sigpending to test to see if any signals are
>> pending for a new task immediately following fork. Signals have to
>> happen either before or after fork. Today our practice is to push
>> all of the signals to before the fork, but that
Linus Torvalds writes:
> On Wed, Aug 8, 2018 at 11:57 PM Eric W. Biederman
> wrote:
>>
>> The code was being overly pesimistic.
>
> Pessimistic.
>> + if (type > PIDTYPE_TGID) {
>> + struct multiprocess_signals *delayed;
>>
Linus Torvalds writes:
> On Wed, Aug 8, 2018 at 11:57 PM Eric W. Biederman
> wrote:
>>
>> The code was being overly pesimistic.
>
> Pessimistic.
>> + if (type > PIDTYPE_TGID) {
>> + struct multiprocess_signals *delayed;
>>
David Howells writes:
> Eric W. Biederman wrote:
>
>> First let me thank you for adding both FSCONFIG_CMD_CREATE and
>> FSCONFIG_CMD_RECONFIGURE. Unfortunately the implementation is currently
>> broken. So this patch gets my:
>>
>> This is brok
David Howells writes:
> Eric W. Biederman wrote:
>
>> First let me thank you for adding both FSCONFIG_CMD_CREATE and
>> FSCONFIG_CMD_RECONFIGURE. Unfortunately the implementation is currently
>> broken. So this patch gets my:
>>
>> This is brok
The code in calculate_sigpending will now handle this so
it is just redundant and possibly a little confusing
to continue setting TIF_SIGPENDING in ptrace_init_task.
Suggested-by: Oleg Nesterov
Signed-off-by: "Eric W. Biederman"
---
include/linux/ptrace.h | 2 --
1 file changed, 2
The code in calculate_sigpending will now handle this so
it is just redundant and possibly a little confusing
to continue setting TIF_SIGPENDING in ptrace_init_task.
Suggested-by: Oleg Nesterov
Signed-off-by: "Eric W. Biederman"
---
include/linux/ptrace.h | 2 --
1 file changed, 2
the new task is discoverable.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 1 +
kernel/sched/core.c | 2 ++
kernel/signal.c | 11 +++
3 files changed, 14 insertions(+)
diff --git a/include/linux/sched/signal.h b/include/l
ads,
the call to task_join_group_stop and do_signal_stop. But the change
is trivial and it is one less thing to worry about when reading
the code.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 2 ++
kernel/fork.c| 27 +++---
will be lost.
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index b9c54318a292..22d4cdb9a7ca 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1928,6 +1928,12 @@ static __latent_entropy struct t
and
Reported-by: majiang
Fixes: 4a2c7a7837da ("[PATCH] make fork() atomic wrt pgrp/session signals")
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8 +++
init/init_task.c | 1 +
kernel/fork.c| 43 +---
the new task is discoverable.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 1 +
kernel/sched/core.c | 2 ++
kernel/signal.c | 11 +++
3 files changed, 14 insertions(+)
diff --git a/include/linux/sched/signal.h b/include/l
ads,
the call to task_join_group_stop and do_signal_stop. But the change
is trivial and it is one less thing to worry about when reading
the code.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 2 ++
kernel/fork.c| 27 +++---
will be lost.
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index b9c54318a292..22d4cdb9a7ca 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1928,6 +1928,12 @@ static __latent_entropy struct t
and
Reported-by: majiang
Fixes: 4a2c7a7837da ("[PATCH] make fork() atomic wrt pgrp/session signals")
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8 +++
init/init_task.c | 1 +
kernel/fork.c| 43 +---
processes within them.
Move this test up before the signal restart just in case signals are
also pending. Fatal conditions should take presedence over restarts.
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --gi
processes within them.
Move this test up before the signal restart just in case signals are
also pending. Fatal conditions should take presedence over restarts.
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --gi
be pending at a time. Looking at it from
first principles dropping one of SIGTSTP SIGTTIN SIGTTOU or SIGCONT
before calling it's handler feels wrong. I checked and it is our
historical behavior, so I won't even thinking of introducing different
behavior at this point.
Eric W. Biederman (6):
fork
be pending at a time. Looking at it from
first principles dropping one of SIGTSTP SIGTTIN SIGTTOU or SIGCONT
before calling it's handler feels wrong. I checked and it is our
historical behavior, so I won't even thinking of introducing different
behavior at this point.
Eric W. Biederman (6):
fork
Oleg Nesterov writes:
> On 07/26, Eric W. Biederman wrote:
>>
>> Are the earlier patches looking ok to you?
>
> I obviously like 1-15.
>
> "[PATCH 16/20] fork: Move and describe why the code examines PIDNS_ADDING"
> is "interesting". I mean it
Oleg Nesterov writes:
> On 07/26, Eric W. Biederman wrote:
>>
>> Are the earlier patches looking ok to you?
>
> I obviously like 1-15.
>
> "[PATCH 16/20] fork: Move and describe why the code examines PIDNS_ADDING"
> is "interesting". I mean it
Stephen Rothwell writes:
> Hi all,
>
> On Wed, 20 Jun 2018 12:39:05 +1000 Stephen Rothwell
> wrote:
>
> Are there any comments on this resolution. I just had to do it all
> again due to slight changes in the vfs tree. What are you guys going
> to tell Linus when he comes to merge this?
Stephen Rothwell writes:
> Hi all,
>
> On Wed, 20 Jun 2018 12:39:05 +1000 Stephen Rothwell
> wrote:
>
> Are there any comments on this resolution. I just had to do it all
> again due to slight changes in the vfs tree. What are you guys going
> to tell Linus when he comes to merge this?
you want isn't in the
state you expect.
Until this security issue is fixed this entire patchset has my:
Nacked-by: "Eric W. Biederman"
> +/*
> + * Perform an action on a context.
> + */
> +static int vfs_fsconfig_action(struct fs_context *fc, enum fsconfig_command
you want isn't in the
state you expect.
Until this security issue is fixed this entire patchset has my:
Nacked-by: "Eric W. Biederman"
> +/*
> + * Perform an action on a context.
> + */
> +static int vfs_fsconfig_action(struct fs_context *fc, enum fsconfig_command
Jürg Billeter writes:
> On Wed, 2018-08-01 at 16:19 +0200, Oleg Nesterov wrote:
>> On 07/31, Jürg Billeter wrote:
>> >
>> > > Could you explain your use-case? Why a shell wants to use
>> > > CLONE_NEWPID?
>> >
>> > To guarantee that there won't be any runaway processes, i.e., ensure
>> > that
Jürg Billeter writes:
> On Wed, 2018-08-01 at 16:19 +0200, Oleg Nesterov wrote:
>> On 07/31, Jürg Billeter wrote:
>> >
>> > > Could you explain your use-case? Why a shell wants to use
>> > > CLONE_NEWPID?
>> >
>> > To guarantee that there won't be any runaway processes, i.e., ensure
>> > that
David Laight writes:
> From: Eric W. Biederman
>> Sent: 25 July 2018 18:38
> ...
>> >> Further unless I misread something you are increasing the number of
>> >> timers to 3 per namespace. If I create create a thousand network
>> >> namespaces
David Laight writes:
> From: Eric W. Biederman
>> Sent: 25 July 2018 18:38
> ...
>> >> Further unless I misread something you are increasing the number of
>> >> timers to 3 per namespace. If I create create a thousand network
>> >> namespaces
Oleg Nesterov writes:
> On 07/23, Eric W. Biederman wrote:
>>
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -1988,6 +1988,7 @@ static __latent_entropy struct task_struct
>> *copy_process(
>>
Oleg Nesterov writes:
> On 07/23, Eric W. Biederman wrote:
>>
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -1988,6 +1988,7 @@ static __latent_entropy struct task_struct
>> *copy_process(
>>
Oleg Nesterov writes:
> On 07/24, Eric W. Biederman wrote:
>>
>> @@ -1979,6 +1983,8 @@ static __latent_entropy struct task_struct
>> *copy_process(
>> attach_pid(p, PIDTYPE_TGID);
>> attach_pid(p, PIDTYPE_PGID);
>
Oleg Nesterov writes:
> On 07/24, Eric W. Biederman wrote:
>>
>> @@ -1979,6 +1983,8 @@ static __latent_entropy struct task_struct
>> *copy_process(
>> attach_pid(p, PIDTYPE_TGID);
>> attach_pid(p, PIDTYPE_PGID);
>
David Ahern writes:
> On 7/25/18 11:38 AM, Eric W. Biederman wrote:
>>
>> Absolutely NOT. Global thresholds are exactly correct given the fact
>> you are running on a single kernel.
>>
>> Memory is not free (Even though we are swimming in enough of i
David Ahern writes:
> On 7/25/18 11:38 AM, Eric W. Biederman wrote:
>>
>> Absolutely NOT. Global thresholds are exactly correct given the fact
>> you are running on a single kernel.
>>
>> Memory is not free (Even though we are swimming in enough of i
David Ahern writes:
> On 7/25/18 6:33 AM, Eric W. Biederman wrote:
>> Cong Wang writes:
>>
>>> On Tue, Jul 24, 2018 at 8:14 AM David Ahern wrote:
>>>>
>>>> On 7/19/18 11:12 AM, Cong Wang wrote:
>>>>> On Thu, Jul 19, 2018 at 9:16 A
David Ahern writes:
> On 7/25/18 6:33 AM, Eric W. Biederman wrote:
>> Cong Wang writes:
>>
>>> On Tue, Jul 24, 2018 at 8:14 AM David Ahern wrote:
>>>>
>>>> On 7/19/18 11:12 AM, Cong Wang wrote:
>>>>> On Thu, Jul 19, 2018 at 9:16 A
Oleg Nesterov writes:
> On 07/23, Eric W. Biederman wrote:
>>
>> signal: Add calculate_sigpending()
>> fork: Have new threads join on-going signal group stops
>> signal: Don't restart fork when signals come in.
>
> Oh, I need to re-read th
Oleg Nesterov writes:
> On 07/23, Eric W. Biederman wrote:
>>
>> signal: Add calculate_sigpending()
>> fork: Have new threads join on-going signal group stops
>> signal: Don't restart fork when signals come in.
>
> Oh, I need to re-read th
Cong Wang writes:
> On Tue, Jul 24, 2018 at 8:14 AM David Ahern wrote:
>>
>> On 7/19/18 11:12 AM, Cong Wang wrote:
>> > On Thu, Jul 19, 2018 at 9:16 AM David Ahern wrote:
>> >>
>> >> Chatting with Nikolay about this and he brought up a good corollary - ip
>> >> fragmentation. It really is a
Cong Wang writes:
> On Tue, Jul 24, 2018 at 8:14 AM David Ahern wrote:
>>
>> On 7/19/18 11:12 AM, Cong Wang wrote:
>> > On Thu, Jul 19, 2018 at 9:16 AM David Ahern wrote:
>> >>
>> >> Chatting with Nikolay about this and he brought up a good corollary - ip
>> >> fragmentation. It really is a
tomic wrt pgrp/session signals")
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8 +++
kernel/fork.c| 43 ++--
kernel/signal.c | 9
3 files changed, 44 insertions(+), 16 deletions(-)
tomic wrt pgrp/session signals")
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8 +++
kernel/fork.c| 43 ++--
kernel/signal.c | 9
3 files changed, 44 insertions(+), 16 deletions(-)
Linus Torvalds writes:
> On Tue, Jul 24, 2018 at 1:40 PM Eric W. Biederman
> wrote:
>>
>> + if (signal_pending(current)) {
>> + retval = restart_syscall();
>> + goto fork_out;
>> + }
>
> Oh, the previous vers
Linus Torvalds writes:
> On Tue, Jul 24, 2018 at 1:40 PM Eric W. Biederman
> wrote:
>>
>> + if (signal_pending(current)) {
>> + retval = restart_syscall();
>> + goto fork_out;
>> + }
>
> Oh, the previous vers
t;)
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8 +++
kernel/fork.c| 44 +++-
kernel/signal.c | 9
3 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/include/linux/sche
t;)
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8 +++
kernel/fork.c| 44 +++-
kernel/signal.c | 9
3 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/include/linux/sche
Linus Torvalds writes:
> On Tue, Jul 24, 2018 at 10:58 AM Eric W. Biederman
> wrote:
>>
>> Yes you are quite right. Easy enough to fix, but it definitely needs
>> to be fixed.
>>
>> I will respin.
>
> Would you mind trying a slightly differe
Linus Torvalds writes:
> On Tue, Jul 24, 2018 at 10:58 AM Eric W. Biederman
> wrote:
>>
>> Yes you are quite right. Easy enough to fix, but it definitely needs
>> to be fixed.
>>
>> I will respin.
>
> Would you mind trying a slightly differe
Linus Torvalds writes:
> This is completely broken.
>
> On Mon, Jul 23, 2018 at 8:27 PM Eric W. Biederman
> wrote:
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 6c358846a8b8..6ee5822f0085 100644
>> --- a/kernel/fork.c
>> +++ b/kern
Linus Torvalds writes:
> This is completely broken.
>
> On Mon, Jul 23, 2018 at 8:27 PM Eric W. Biederman
> wrote:
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 6c358846a8b8..6ee5822f0085 100644
>> --- a/kernel/fork.c
>> +++ b/kern
in jobctl and
set TIF_SIGPENDING to ensure the new task takes the slow path to userspace.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 2 ++
kernel/fork.c| 27 +++
kernel/signal.c | 14 ++
3 fil
This is the bottom and by pushing this down it simplifies the callers
and otherwise leaves things as is. This is in preparation for allowing
fork to implement better handling of signals set to groups of processes.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 8 --
This information is already available in the callers and by pushing it
down it makes the code a little clearer, and allows implementing
better handling of signales set to a group of processes in fork.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 12 ++--
1 file
This information is already available in the callers and by pushing it
down it makes the code a little clearer, and allows better group
signal behavior in fork.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
processes within them.
Move this test up before the signal restart just in case signals are
also pending. Fatal conditions should take presedence over restarts.
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --gi
in jobctl and
set TIF_SIGPENDING to ensure the new task takes the slow path to userspace.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 2 ++
kernel/fork.c| 27 +++
kernel/signal.c | 14 ++
3 fil
This is the bottom and by pushing this down it simplifies the callers
and otherwise leaves things as is. This is in preparation for allowing
fork to implement better handling of signals set to groups of processes.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 8 --
This information is already available in the callers and by pushing it
down it makes the code a little clearer, and allows implementing
better handling of signales set to a group of processes in fork.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 12 ++--
1 file
This information is already available in the callers and by pushing it
down it makes the code a little clearer, and allows better group
signal behavior in fork.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
processes within them.
Move this test up before the signal restart just in case signals are
also pending. Fatal conditions should take presedence over restarts.
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --gi
This information is already present and using it directly simplifies the logic
of the code.
Signed-off-by: "Eric W. Biederman"
---
fs/fcntl.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 1523588fd759..5d
This information is already present and using it directly simplifies the logic
of the code.
Signed-off-by: "Eric W. Biederman"
---
fs/fcntl.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 1523588fd759..5d
not dealt with. They won't cause any problems.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200447
Reported-by: Wen Yang and
Reported-by: majiang
Fixes: 4a2c7a7837da ("[PATCH] make fork() atomic wrt pgrp/session signals")
Signed-off-by: "Eric W. Biederman"
---
not dealt with. They won't cause any problems.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200447
Reported-by: Wen Yang and
Reported-by: majiang
Fixes: 4a2c7a7837da ("[PATCH] make fork() atomic wrt pgrp/session signals")
Signed-off-by: "Eric W. Biederman"
---
This passes the information we already have at the call sight into
do_send_sig_info. Ultimately allowing for better handling of signals
sent to a group of processes during fork.
Signed-off-by: "Eric W. Biederman"
---
drivers/tty/sysrq.c| 2 +-
fs/fcntl.c | 6 +++--
TIF_SIGPENDING for the kernel
live patching as it uses a separate thread flag as well. But at this
point it seems safer to copy recalc_sigpending and get the kernel live
patching folks to sort out their story later.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/sig
will be lost.
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index b9c54318a292..22d4cdb9a7ca 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1928,6 +1928,12 @@ static __latent_entropy struct t
This passes the information we already have at the call sight into
do_send_sig_info. Ultimately allowing for better handling of signals
sent to a group of processes during fork.
Signed-off-by: "Eric W. Biederman"
---
drivers/tty/sysrq.c| 2 +-
fs/fcntl.c | 6 +++--
TIF_SIGPENDING for the kernel
live patching as it uses a separate thread flag as well. But at this
point it seems safer to copy recalc_sigpending and get the kernel live
patching folks to sort out their story later.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/sig
will be lost.
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index b9c54318a292..22d4cdb9a7ca 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1928,6 +1928,12 @@ static __latent_entropy struct t
d of the current thread group.
This has the net effect of making the code a little clearer, and
making it obvious that posix timers never look up a process by a the
pid of a thread.
Signed-off-by: "Eric W. Biederman"
---
kernel/time/posix-timers.c | 8 +---
1 file changed, 5 insertio
PIDTYPE_PID
for tgid lookup also be used to avoid taking the tasklist lock.
Suggested-by: Oleg Nesterov
Signed-off-by: "Eric W. Biederman"
---
drivers/net/tun.c | 2 +-
drivers/tty/tty_io.c| 2 +-
fs/fcntl.c | 54 ++---
d of the current thread group.
This has the net effect of making the code a little clearer, and
making it obvious that posix timers never look up a process by a the
pid of a thread.
Signed-off-by: "Eric W. Biederman"
---
kernel/time/posix-timers.c | 8 +---
1 file changed, 5 insertio
PIDTYPE_PID
for tgid lookup also be used to avoid taking the tasklist lock.
Suggested-by: Oleg Nesterov
Signed-off-by: "Eric W. Biederman"
---
drivers/net/tun.c | 2 +-
drivers/tty/tty_io.c| 2 +-
fs/fcntl.c | 54 ++---
to address that.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 2 +-
kernel/signal.c | 14 +-
kernel/time/posix-timers.c | 13 -
3 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/include/linux/sched/signal.h b
in the code.
Signed-off-by: "Eric W. Biederman"
---
arch/ia64/kernel/asm-offsets.c | 2 +-
arch/ia64/kernel/fsys.S | 4 ++--
arch/s390/kernel/perf_cpum_sf.c | 2 +-
fs/exec.c | 1 +
include/linux/pid.h | 3 +--
include/linux/sched.h
This passes the information we already have at the call sight
into group_send_sig_info. Ultimatelly allowing for to better handle
signals sent to a group of processes.
Signed-off-by: "Eric W. Biederman"
---
include/linux/signal.h | 4 +++-
kernel/exit.c | 3 ++-
kerne
to address that.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 2 +-
kernel/signal.c | 14 +-
kernel/time/posix-timers.c | 13 -
3 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/include/linux/sched/signal.h b
in the code.
Signed-off-by: "Eric W. Biederman"
---
arch/ia64/kernel/asm-offsets.c | 2 +-
arch/ia64/kernel/fsys.S | 4 ++--
arch/s390/kernel/perf_cpum_sf.c | 2 +-
fs/exec.c | 1 +
include/linux/pid.h | 3 +--
include/linux/sched.h
This passes the information we already have at the call sight
into group_send_sig_info. Ultimatelly allowing for to better handle
signals sent to a group of processes.
Signed-off-by: "Eric W. Biederman"
---
include/linux/signal.h | 4 +++-
kernel/exit.c | 3 ++-
kerne
This is cheap and no cost so we might as well.
Signed-off-by: "Eric W. Biederman"
---
init/init_task.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/init/init_task.c b/init/init_task.c
index 74f60baa2799..7914ffb8dc73 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -
The function is general and inline so there is no need
to hide it inside of exit.c
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched/signal.h | 8
kernel/exit.c| 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/l
1101 - 1200 of 10702 matches
Mail list logo
