rsen
Acked-by: Linus Torvalds
Reviewed-by: Christian Brauner
Fixes: f149b3155744 ("signal: Never allocate siginfo for SIGKILL or SIGSTOP")
Fixes: 6dfc88977e42 ("[PATCH] shared thread signals")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by
Linus Torvalds writes:
> On Tue, Feb 5, 2019 at 2:41 AM Eric W. Biederman
> wrote:
>>
>> I think the simpler change to just do:
>
> Ack. Changelog and sign-off?
Apologies I got distracted by processes ignoring SIGKILL.
I will write this up and send it out in the morning.
Eric
ebied...@xmission.com (Eric W. Biederman) writes:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> Thomas Gleixner writes:
>>
>>> On Mon, 4 Feb 2019, Dmitry Vyukov wrote:
>>>
>>>> On Mon, Feb 4, 2019 at 10:27 AM Thomas Gleixner wrote:
ebied...@xmission.com (Eric W. Biederman) writes:
> Thomas Gleixner writes:
>
>> On Mon, 4 Feb 2019, Dmitry Vyukov wrote:
>>
>>> On Mon, Feb 4, 2019 at 10:27 AM Thomas Gleixner wrote:
>>> >
>>> > On Fri, 1 Feb 2019, Dmitry Vyukov wrote:
>>
Thomas Gleixner writes:
> On Mon, 4 Feb 2019, Dmitry Vyukov wrote:
>
>> On Mon, Feb 4, 2019 at 10:27 AM Thomas Gleixner wrote:
>> >
>> > On Fri, 1 Feb 2019, Dmitry Vyukov wrote:
>> >
>> > > On Fri, Feb 1, 2019 at 5:48 PM Dmitry Vyukov wrote:
>> > > >
>> > > > Hello,
>> > > >
>> > > > The
;> anymore.
>> Since it's believed[1] there are no other userspace things depending on
>> the
>> old behavior, this removes the behavioral check in the selftest, since
>> it's
>> more a "extra" sanity check (which turns out, maybe, not to ha
Karel Zak writes:
> On Tue, Jan 29, 2019 at 03:44:22PM -0600, Eric W. Biederman wrote:
>> so I am proposing we change this in the new mount api.
>
> Well, this forces me to ask what the new API is? :-)
>
> It seems that David uses fsconfig() and fsinfo() to set and get
>
David Howells writes:
> Karel Zak wrote:
>
>> It seems more elegant is to ask for Nth option as expected by fsinfo().
>
> More elegant yes, but there's an issue with atomiticity[*]. I'm in the
> process of switching to something that returns you a single buffer with all
> the options in, but
David Howells writes:
> You need to rebase on linus/master. A bunch of your patches are obsoleted by
> Al's security changes there.
Before anything is merged definitely.
Al dealt with mount options from the LSMs in a slightly different way
than I did. At a practical level Als version of the
ebied...@xmission.com (Eric W. Biederman) writes:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> Casey Schaufler writes:
>>> Are you taking the LSM specific mount options into account?
>>
>> In the design yes, and I allow setting them. It appears in
ebied...@xmission.com (Eric W. Biederman) writes:
> Casey Schaufler writes:
>> Are you taking the LSM specific mount options into account?
>
> In the design yes, and I allow setting them. It appears in the code
> to retrieve the mount options I forgot to call securi
Casey Schaufler writes:
> On 1/29/2019 1:44 PM, Eric W. Biederman wrote:
>> All,
>>
>> With the existing mount API it is possible to mount a filesystem
>> like:
>>
>> mount -t ext4 /dev/sda1 -o user_xattr /some/path
>> mount -t ext4 /dev/sda1 -o nous
All,
With the existing mount API it is possible to mount a filesystem
like:
mount -t ext4 /dev/sda1 -o user_xattr /some/path
mount -t ext4 /dev/sda1 -o nouser_xattr /some/other/path
And have both mount commands succeed and have two mounts of the same
filesystem. If the mounter is not
"Robert O'Callahan" writes:
> This commit refactored the implementation of TIOCGPTPEER, moving "case
> TIOCGPTPEER" from pty_unix98_ioctl() to tty_ioctl().
> pty_unix98_ioctl() is called by pty_unix98_compat_ioctl(), so before
> the commit, TIOCGPTPEER worked for 32-bit userspace. Unfortunately
zzoru writes:
> I think that it is exactly same to:
> https://groups.google.com/forum/#!searchin/linux.kernel/cleanup_net$20is$20slow%7Csort:date/linux.kernel/IMJ9OzonDSI/QH86oy1PAQAJ
> Already, patch was maded, but maybe he forgot to push it.
That patch was made to address speed, and lifetime
Dmitry Vyukov writes:
> This looks superciliously similar to:
> https://groups.google.com/d/msg/syzkaller-bugs/nFeC8-UG1gg/B6GFaZFrFQAJ
>
> The crux: for the last ~half a year low memory conditions randomly
> corrupt kernel memory with stack overflows.
Does enabling virtually mapped stacks
Eric Biggers writes:
> Hi Eric,
>
> The following commit, which went into v4.20, introduced undefined behavior
> when
> sys_rt_sigqueueinfo() is called with sig=0:
Ouch. Good catch.
It looks like the fix is just to do:
diff --git a/include/linux/signal.h b/include/linux/signal.h
index
network
> * namespace should be
> shut down.
> */
> + refcount_t passive; /* To decided when the
> network
> +
zzoru writes:
> net/core: BUG in copy_net_ns() (net_namespace.c)
I don't understand this failure report at all.
I don't see the connection to copy_net_ns(). And I don't see how the
suggested patch short of covering up a memory stomp could possibly make
a difference.
What am I missing?
>
Al Viro writes:
> mount API prereqs. Mostly that's LSM mount options cleanups.
> One trivial conflict in security/selinux/hooks.c, resolved by taking
> the variant from this branch - the method has been split, leaving
> only the part that used to be conditional upon "it's not an internal
Trond Myklebust writes:
> On Thu, 2019-01-03 at 15:53 +1100, NeilBrown wrote:
>> On Wed, Jan 02 2019, Linus Torvalds wrote:
>>
>> > On Wed, Jan 2, 2019 at 2:42 PM Schumaker, Anna
>> > wrote:
>> > > We also were unable to track down a maintainer for Neil Brown's
>> > > changes to
>> > > the
Al Viro writes:
> On Mon, Nov 12, 2018 at 08:54:39PM +, Al Viro wrote:
>> On Sun, Nov 11, 2018 at 08:07:20PM -0600, Eric W. Biederman wrote:
>> > Steven Whitehouse writes:
>>
>> > > Can you share some details of what this NULL dereference is? D
("pid: replace pid bitmap implementation with IDR API")
>
Acked-by: "Eric W. Biederman"
> diff --git a/kernel/pid.c b/kernel/pid.c
> index b2f6c506035da..75264e0d1e71d 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -233,8 +233,11 @@ struct
Oleg Nesterov writes:
> On 12/06, Eric W. Biederman wrote:
>>
>> The challenge is that we could be delivering this to a zombie signal
>> group leader.
>
> ...
>
>> Sigh it is probably time that I dig in and figure out how to avoid that
>> case whic
Kees Cook writes:
> On Thu, Dec 6, 2018 at 1:11 PM Eric W. Biederman
> wrote:
>>
>> Tycho Andersen writes:
>>
>> > On Thu, Dec 06, 2018 at 10:48:39AM -0800, Linus Torvalds wrote:
>> >> On Thu, Dec 6, 2018 at 6:40 AM Eric W. Biederman
>>
Kees Cook writes:
> On Thu, Dec 6, 2018 at 1:11 PM Eric W. Biederman
> wrote:
>>
>> Tycho Andersen writes:
>>
>> > On Thu, Dec 06, 2018 at 10:48:39AM -0800, Linus Torvalds wrote:
>> >> On Thu, Dec 6, 2018 at 6:40 AM Eric W. Biederman
>>
Daniel Colascione writes:
> On Thu, Dec 6, 2018 at 12:29 PM Eric W. Biederman
> wrote:
>> Christian Brauner writes:
>>
>> > [1]: You cannot replicate certain aspects of kill *yet*. We have
>> > established this before. If we want process group support late
Daniel Colascione writes:
> On Thu, Dec 6, 2018 at 12:29 PM Eric W. Biederman
> wrote:
>> Christian Brauner writes:
>>
>> > [1]: You cannot replicate certain aspects of kill *yet*. We have
>> > established this before. If we want process group support late
s parameter or is the width of the
target depending on the flags.
That is fundamental to how the system call and it's extensions work.
That is fundamental to my review.
Until that is decided.
Nacked-by: "Eric W. Biederman"
There are a lot of fundamental maintenance issues and you
s parameter or is the width of the
target depending on the flags.
That is fundamental to how the system call and it's extensions work.
That is fundamental to my review.
Until that is decided.
Nacked-by: "Eric W. Biederman"
There are a lot of fundamental maintenance issues and you
Tycho Andersen writes:
> On Thu, Dec 06, 2018 at 10:48:39AM -0800, Linus Torvalds wrote:
>> On Thu, Dec 6, 2018 at 6:40 AM Eric W. Biederman
>> wrote:
>> >
>> > We have in the past had ptrace users that weren't just about debugging
>> > so I
Tycho Andersen writes:
> On Thu, Dec 06, 2018 at 10:48:39AM -0800, Linus Torvalds wrote:
>> On Thu, Dec 6, 2018 at 6:40 AM Eric W. Biederman
>> wrote:
>> >
>> > We have in the past had ptrace users that weren't just about debugging
>> > so I
Christian Brauner writes:
> On Thu, Dec 06, 2018 at 01:17:24PM -0600, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
>> >>Christian Brauner writes:
>> >&g
Christian Brauner writes:
> On Thu, Dec 06, 2018 at 01:17:24PM -0600, Eric W. Biederman wrote:
>> Christian Brauner writes:
>>
>> > On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
>> >>Christian Brauner writes:
>> >&g
Christian Brauner writes:
> On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
>>Christian Brauner writes:
>>
>>> The kill() syscall operates on process identifiers (pid). After a
>>process
>>> has exited its pid can be reused by another process. If a caller
>>sends a
>>>
Christian Brauner writes:
> On December 7, 2018 4:01:19 AM GMT+13:00, ebied...@xmission.com wrote:
>>Christian Brauner writes:
>>
>>> The kill() syscall operates on process identifiers (pid). After a
>>process
>>> has exited its pid can be reused by another process. If a caller
>>sends a
>>>
Daniel Colascione writes:
> On Thu, Dec 6, 2018 at 7:02 AM Eric W. Biederman
> wrote:
>>
>> Christian Brauner writes:
>>
>> > The kill() syscall operates on process identifiers (pid). After a process
>> > has exited its pid can be reused by anothe
Daniel Colascione writes:
> On Thu, Dec 6, 2018 at 7:02 AM Eric W. Biederman
> wrote:
>>
>> Christian Brauner writes:
>>
>> > The kill() syscall operates on process identifiers (pid). After a process
>> > has exited its pid can be reused by anothe
ml/20181121213946.ga10...@mail.hallyn.com/
> [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6...@brauner.io/
> [7]:
> https://lore.kernel.org/lkml/36323361-90bd-41af-ab5b-ee0d7ba02...@amacapital.net/
> [8]: https://lore.kernel.org/lkml/87tvjxp8pc@xmission.com/
> [9]: h
ml/20181121213946.ga10...@mail.hallyn.com/
> [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6...@brauner.io/
> [7]:
> https://lore.kernel.org/lkml/36323361-90bd-41af-ab5b-ee0d7ba02...@amacapital.net/
> [8]: https://lore.kernel.org/lkml/87tvjxp8pc@xmission.com/
> [9]: h
Kees Cook writes:
> On Sat, Dec 1, 2018 at 7:04 AM Eric W. Biederman
> wrote:
>>
>> Kees Cook writes:
>>
>> > On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman
>> > wrote:
>> >>
>> >> Kees Cook writes:
>&g
Kees Cook writes:
> On Sat, Dec 1, 2018 at 7:04 AM Eric W. Biederman
> wrote:
>>
>> Kees Cook writes:
>>
>> > On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman
>> > wrote:
>> >>
>> >> Kees Cook writes:
>&g
Florian Weimer writes:
> * Eric W. Biederman:
>
>> Floriam are you seeing a problem with this behavior or the way Christian
>> was describing it?
>
> My hope is that you could use taskfd_send_signal one day to send a
> signal to a process which you *known* (based
Florian Weimer writes:
> * Eric W. Biederman:
>
>> Floriam are you seeing a problem with this behavior or the way Christian
>> was describing it?
>
> My hope is that you could use taskfd_send_signal one day to send a
> signal to a process which you *known* (based
Florian Weimer writes:
> * Jürg Billeter:
>
>> On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
>>> * Christian Brauner:
>>>
>>> > /* zombies */
>>> > Zombies can be signaled just as any other process. No special error will
>>> > be
>>> > reported since a zombie state is an unreliable
Florian Weimer writes:
> * Jürg Billeter:
>
>> On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
>>> * Christian Brauner:
>>>
>>> > /* zombies */
>>> > Zombies can be signaled just as any other process. No special error will
>>> > be
>>> > reported since a zombie state is an unreliable
@brauner.io/
> [4]: https://lore.kernel.org/lkml/20181203180224.fkvw4kajtbvru...@brauner.io/
> [5]: https://lore.kernel.org/lkml/20181121213946.ga10...@mail.hallyn.com/
> [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6...@brauner.io/
> [7]:
> https://lore.kernel.or
@brauner.io/
> [4]: https://lore.kernel.org/lkml/20181203180224.fkvw4kajtbvru...@brauner.io/
> [5]: https://lore.kernel.org/lkml/20181121213946.ga10...@mail.hallyn.com/
> [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6...@brauner.io/
> [7]:
> https://lore.kernel.or
@brauner.io/
> [4]: https://lore.kernel.org/lkml/20181203180224.fkvw4kajtbvru...@brauner.io/
> [5]: https://lore.kernel.org/lkml/20181121213946.ga10...@mail.hallyn.com/
> [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6...@brauner.io/
> [7]:
> https://lore.kernel.or
@brauner.io/
> [4]: https://lore.kernel.org/lkml/20181203180224.fkvw4kajtbvru...@brauner.io/
> [5]: https://lore.kernel.org/lkml/20181121213946.ga10...@mail.hallyn.com/
> [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6...@brauner.io/
> [7]:
> https://lore.kernel.or
Andy Lutomirski writes:
>> On Dec 1, 2018, at 7:28 AM, Eric W. Biederman wrote:
>>
>>
>> It just occurs to me that the simple way to implement
>> procfd_sigqueueinfo info is like:
>>
>> int copy_siginfo_from_user_any(kernel_siginfo_t *info, sigi
Andy Lutomirski writes:
>> On Dec 1, 2018, at 7:28 AM, Eric W. Biederman wrote:
>>
>>
>> It just occurs to me that the simple way to implement
>> procfd_sigqueueinfo info is like:
>>
>> int copy_siginfo_from_user_any(kernel_siginfo_t *info, sigi
It just occurs to me that the simple way to implement
procfd_sigqueueinfo info is like:
int copy_siginfo_from_user_any(kernel_siginfo_t *info, siginfo_t *uinfo)
{
#ifdef CONFIG_COMPAT
if (in_compat_syscall)
return copy_siginfo_from_user32(info, uinfo);
#endif
It just occurs to me that the simple way to implement
procfd_sigqueueinfo info is like:
int copy_siginfo_from_user_any(kernel_siginfo_t *info, siginfo_t *uinfo)
{
#ifdef CONFIG_COMPAT
if (in_compat_syscall)
return copy_siginfo_from_user32(info, uinfo);
#endif
Kees Cook writes:
> On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman
> wrote:
>>
>> Kees Cook writes:
>>
>> > On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook wrote:
>> >> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote:
>> >>> On
Kees Cook writes:
> On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman
> wrote:
>>
>> Kees Cook writes:
>>
>> > On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook wrote:
>> >> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote:
>> >>> On
Arnd Bergmann writes:
> On Fri, Nov 30, 2018 at 7:56 AM Christian Brauner
> wrote:
>> On Thu, Nov 29, 2018 at 11:13:57PM -0600, Eric W. Biederman wrote:
>> > Arnd Bergmann writes:
>> > > On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski
>> > >
Arnd Bergmann writes:
> On Fri, Nov 30, 2018 at 7:56 AM Christian Brauner
> wrote:
>> On Thu, Nov 29, 2018 at 11:13:57PM -0600, Eric W. Biederman wrote:
>> > Arnd Bergmann writes:
>> > > On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski
>> > >
Radoslaw Burny writes:
> On Tue, Nov 27, 2018 at 6:29 AM Eric W. Biederman
> wrote:
>
> Luis Chamberlain writes:
>
> > On Mon, Nov 26, 2018 at 06:26:07PM +0100, Radoslaw Burny wrote:
> >> Due to a recent commit (d151ddc00498 - fs: Update i_[ug]id_(read|writ
Radoslaw Burny writes:
> On Tue, Nov 27, 2018 at 6:29 AM Eric W. Biederman
> wrote:
>
> Luis Chamberlain writes:
>
> > On Mon, Nov 26, 2018 at 06:26:07PM +0100, Radoslaw Burny wrote:
> >> Due to a recent commit (d151ddc00498 - fs: Update i_[ug]id_(read|writ
Andy Lutomirski writes:
> On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote:
>> siginfo_t as it is now still has a number of other downsides, and Andy in
>> particular didn't like the idea of having three new variants on x86
>> (depending on how you count). His alternative suggestion of
Andy Lutomirski writes:
> On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote:
>> siginfo_t as it is now still has a number of other downsides, and Andy in
>> particular didn't like the idea of having three new variants on x86
>> (depending on how you count). His alternative suggestion of
"gre...@linuxfoundation.org" writes:
> Adding Eric as he touched this code last :)
>
> On Thu, Nov 29, 2018 at 07:25:48PM +, Jan Glauber wrote:
>> On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
>> > I spent some more time looking at this today...
>> >
>> > On Fri, Nov 23, 2018
"gre...@linuxfoundation.org" writes:
> Adding Eric as he touched this code last :)
>
> On Thu, Nov 29, 2018 at 07:25:48PM +, Jan Glauber wrote:
>> On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
>> > I spent some more time looking at this today...
>> >
>> > On Fri, Nov 23, 2018
Luis Chamberlain writes:
> On Mon, Nov 26, 2018 at 11:29:40PM -0600, Eric W. Biederman wrote:
>> Luis Chamberlain writes:
>> > Thanks for the description of how to run into the issue described but
>> > is there also a practical use case today where this is happen
Luis Chamberlain writes:
> On Mon, Nov 26, 2018 at 11:29:40PM -0600, Eric W. Biederman wrote:
>> Luis Chamberlain writes:
>> > Thanks for the description of how to run into the issue described but
>> > is there also a practical use case today where this is happen
Arnd Bergmann writes:
> On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote:
>> > On Nov 29, 2018, at 11:55 AM, Christian Brauner
>> > wrote:
>> >> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
>> >>> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner
>> >>> wrote:
>>
Arnd Bergmann writes:
> On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote:
>> > On Nov 29, 2018, at 11:55 AM, Christian Brauner
>> > wrote:
>> >> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
>> >>> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner
>> >>> wrote:
>>
Oleg Nesterov writes:
> On 11/27, Jürg Billeter wrote:
>>
>> @@ -704,6 +713,9 @@ static void exit_notify(struct task_struct *tsk, int
>> group_dead)
>> struct task_struct *p, *n;
>> LIST_HEAD(dead);
>>
>> +if (group_dead && tsk->signal->kill_descendants_on_exit)
>> +
Oleg Nesterov writes:
> On 11/27, Jürg Billeter wrote:
>>
>> @@ -704,6 +713,9 @@ static void exit_notify(struct task_struct *tsk, int
>> group_dead)
>> struct task_struct *p, *n;
>> LIST_HEAD(dead);
>>
>> +if (group_dead && tsk->signal->kill_descendants_on_exit)
>> +
; info._sifields._kill.si_pid (0)
>>> global.syscall_restart: Test failed at step #22
>>
>> This fails every time for me -- is it still racey for you?
>>
>> I'm attempting a bisect, hoping it doesn't _become_ racey for me. ;)
>
> This bisect to here for me:
>
; info._sifields._kill.si_pid (0)
>>> global.syscall_restart: Test failed at step #22
>>
>> This fails every time for me -- is it still racey for you?
>>
>> I'm attempting a bisect, hoping it doesn't _become_ racey for me. ;)
>
> This bisect to here for me:
>
syzbot writes:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:e195ca6cb6f2 Merge branch 'for-linus' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10d3e6a340
> kernel config:
syzbot writes:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:e195ca6cb6f2 Merge branch 'for-linus' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10d3e6a340
> kernel config:
_gid that is
correct in the general case. That default value is not corect for
sysctl, because proc is weird. As the sysctl permission check in
test_perm are all against GLOBAL_ROOT_UID and GLOBAL_ROOT_GID we did not
notice that i_uid and i_gid were being set wrong.
So all this patch does
_gid that is
correct in the general case. That default value is not corect for
sysctl, because proc is weird. As the sysctl permission check in
test_perm are all against GLOBAL_ROOT_UID and GLOBAL_ROOT_GID we did not
notice that i_uid and i_gid were being set wrong.
So all this patch does
Daniel Colascione writes:
> On Mon, Nov 19, 2018 at 1:37 PM Christian Brauner
> wrote:
>>
>> On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
>> > On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
>> > wrote:
>> > > That can be done without a loop by comparing the level
Daniel Colascione writes:
> On Mon, Nov 19, 2018 at 1:37 PM Christian Brauner
> wrote:
>>
>> On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
>> > On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
>> > wrote:
>> > > That can be done without a loop by comparing the level
Christian Brauner writes:
> On Mon, Nov 19, 2018 at 07:59:24AM -0800, Daniel Colascione wrote:
>> You never addressed my comment on the previous patch about your use of
>
> Sorry, that thread exploded so quickly that I might have missed it.
>
>> private_data here. Why can't you use the struct
Christian Brauner writes:
> On Mon, Nov 19, 2018 at 07:59:24AM -0800, Daniel Colascione wrote:
>> You never addressed my comment on the previous patch about your use of
>
> Sorry, that thread exploded so quickly that I might have missed it.
>
>> private_data here. Why can't you use the struct
Dmitry Safonov <0x7f454...@gmail.com> writes:
>
> So, I just wanted to gently remind about procfs with netlink socket[1].
> It seems to me that whenever you receive() pid information, you
> can request some uniq 64(?) bit number and kill the process using it.
> Whenever uniqueness of 64-bit number
Dmitry Safonov <0x7f454...@gmail.com> writes:
>
> So, I just wanted to gently remind about procfs with netlink socket[1].
> It seems to me that whenever you receive() pid information, you
> can request some uniq 64(?) bit number and kill the process using it.
> Whenever uniqueness of 64-bit number
Daniel Colascione writes:
> On Sun, Nov 18, 2018 at 9:13 AM, Andy Lutomirski wrote:
>> On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione wrote:
>>>
>>> On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote:
>>> > On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione
>>> > wrote:
>>> >>
>>> >>
Daniel Colascione writes:
> On Sun, Nov 18, 2018 at 9:13 AM, Andy Lutomirski wrote:
>> On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione wrote:
>>>
>>> On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote:
>>> > On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione
>>> > wrote:
>>> >>
>>> >>
Tycho Andersen writes:
> On Mon, Nov 12, 2018 at 12:30:25PM -0600, Eric W. Biederman wrote:
>> Tycho Andersen writes:
>>
>> > Hi Oleg,
>> >
>> > I've been running some tests on my seccomp series, and in one of the
>>
Tycho Andersen writes:
> On Mon, Nov 12, 2018 at 12:30:25PM -0600, Eric W. Biederman wrote:
>> Tycho Andersen writes:
>>
>> > Hi Oleg,
>> >
>> > I've been running some tests on my seccomp series, and in one of the
>>
Tycho Andersen writes:
> Hi Oleg,
>
> I've been running some tests on my seccomp series, and in one of the
> tests on v4.20-rc2, I noticed,
>
> [ RUN ] global.syscall_restart
> seccomp_bpf.c:2784:global.syscall_restart:Expected getpid() (1492) ==
> info._sifields._kill.si_pid (0)
>
Tycho Andersen writes:
> Hi Oleg,
>
> I've been running some tests on my seccomp series, and in one of the
> tests on v4.20-rc2, I noticed,
>
> [ RUN ] global.syscall_restart
> seccomp_bpf.c:2784:global.syscall_restart:Expected getpid() (1492) ==
> info._sifields._kill.si_pid (0)
>
Linus,
Please pull the for-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
for-linus
HEAD: 1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00 mnt: fix __detach_mounts
infinite loop
Benjamin Coddington noticed an unkillable busy loop in
Linus,
Please pull the for-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
for-linus
HEAD: 1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00 mnt: fix __detach_mounts
infinite loop
Benjamin Coddington noticed an unkillable busy loop in
Steven Whitehouse writes:
> Hi,
>
>
> On 31/10/18 15:38, Eric W. Biederman wrote:
>> Al Viro writes:
>>
>>> mount API series from David Howells. Last cycle's objections
>>> had been of the "I'd do it differently" variety and wi
Steven Whitehouse writes:
> Hi,
>
>
> On 31/10/18 15:38, Eric W. Biederman wrote:
>> Al Viro writes:
>>
>>> mount API series from David Howells. Last cycle's objections
>>> had been of the "I'd do it differently" variety and wi
David Laight writes:
> From: Daniel Colascione
>> Sent: 31 October 2018 19:33
> ...
>> You can't do it today with kill. The idea that keeping a open file
>> descriptor to a /proc/pid or a file within it prevents PID reuse is
>> widespread, but incorrect.
>
> Is there a real good reason why that
David Laight writes:
> From: Daniel Colascione
>> Sent: 31 October 2018 19:33
> ...
>> You can't do it today with kill. The idea that keeping a open file
>> descriptor to a /proc/pid or a file within it prevents PID reuse is
>> widespread, but incorrect.
>
> Is there a real good reason why that
correct I have spot tested these
changes as well and in my testing the fixes are working.
I have let these changes sit on my branch for a few days as well and
none of the automated testing has found any problems either.
Eric W. Biederman (3):
mount: Retest MNT_LOCKED in do_umount
mount
correct I have spot tested these
changes as well and in my testing the fixes are working.
I have let these changes sit on my branch for a few days as well and
none of the automated testing has found any problems either.
Eric W. Biederman (3):
mount: Retest MNT_LOCKED in do_umount
mount
Rian Quinn writes:
> I apologize upfront if this is the wrong place to post this, pretty new to
> this.
>
> We are working on the Bareflank Hypervisor (www.bareflank.org), and we
> are passing through the INIT/SIPI process (similar to how a VMX
> rootkit from EFI might boot the OS) and we
Rian Quinn writes:
> I apologize upfront if this is the wrong place to post this, pretty new to
> this.
>
> We are working on the Bareflank Hypervisor (www.bareflank.org), and we
> are passing through the INIT/SIPI process (similar to how a VMX
> rootkit from EFI might boot the OS) and we
Laurent Vivier writes:
> On 01/11/2018 04:51, Jann Horn wrote:
>> On Thu, Nov 1, 2018 at 3:59 AM James Bottomley
>> wrote:
>>>
>>> On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote:
Hi,
Any comment on this last version?
Any chance to be merged?
>>>
>>> I've got a
Laurent Vivier writes:
> On 01/11/2018 04:51, Jann Horn wrote:
>> On Thu, Nov 1, 2018 at 3:59 AM James Bottomley
>> wrote:
>>>
>>> On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote:
Hi,
Any comment on this last version?
Any chance to be merged?
>>>
>>> I've got a
701 - 800 of 10702 matches
Mail list logo
