On 2018-12-25, Lai Jiangshan wrote:
> On Tue, Dec 25, 2018 at 1:32 PM Lai Jiangshan
> wrote:
> >
> > Is it possible to avoid adding any syscall?
> >
> > Since holding /proc/pid/reg_file can also hold the pid.
> > With this guarantee, /proc/pid/uuid (universally unique identifier ) can be
> > intr
On Tue, Dec 25, 2018 at 1:32 PM Lai Jiangshan
wrote:
>
> Is it possible to avoid adding any syscall?
>
> Since holding /proc/pid/reg_file can also hold the pid.
> With this guarantee, /proc/pid/uuid (universally unique identifier ) can be
> introduced to identify tasks, the kernel generates
> a uu
Is it possible to avoid adding any syscall?
Since holding /proc/pid/reg_file can also hold the pid.
With this guarantee, /proc/pid/uuid (universally unique identifier ) can be
introduced to identify tasks, the kernel generates
a uuid for every task when created.
save_pid_uuid_pair_for_later_kill(
On December 7, 2018 7:56:44 AM GMT+13:00, Florian Weimer
wrote:
>* Andy Lutomirski:
>
>>> I suppose that's fine. Or alternatively, when thread group support
>is
>>> added, introduce a flag that applications have to use to enable it,
>so
>>> that they can probe for support by checking support for
* Andy Lutomirski:
>> I suppose that's fine. Or alternatively, when thread group support is
>> added, introduce a flag that applications have to use to enable it, so
>> that they can probe for support by checking support for the flag.
>>
>> I wouldn't be opposed to a new system call like this eit
> On Dec 4, 2018, at 4:55 AM, Florian Weimer wrote:
>
> * Christian Brauner:
>
>>> On Mon, Dec 03, 2018 at 05:57:51PM +0100, Florian Weimer wrote:
>>> * Christian Brauner:
>>>
Ok, I finally have access to source code again. Scratch what I said above!
I looked at the code and tested it. I
On Tue, Dec 04, 2018 at 01:55:10PM +0100, Florian Weimer wrote:
> * Christian Brauner:
>
> > On Mon, Dec 03, 2018 at 05:57:51PM +0100, Florian Weimer wrote:
> >> * Christian Brauner:
> >>
> >> > Ok, I finally have access to source code again. Scratch what I said
> >> > above!
> >> > I looked at
* Christian Brauner:
> On Mon, Dec 03, 2018 at 05:57:51PM +0100, Florian Weimer wrote:
>> * Christian Brauner:
>>
>> > Ok, I finally have access to source code again. Scratch what I said above!
>> > I looked at the code and tested it. If the process has exited but not
>> > yet waited upon aka is
On 2018-12-03, Christian Brauner wrote:
> > > As I pointed out in another mail my I is to make this work by using
> > > file descriptors for /proc//task/. I don't want this in the
> > > initial patchset though. I prefer to slowly add those features once
> > > we have gotten the basic functionali
On Mon, Dec 03, 2018 at 05:57:51PM +0100, Florian Weimer wrote:
> * Christian Brauner:
>
> > Ok, I finally have access to source code again. Scratch what I said above!
> > I looked at the code and tested it. If the process has exited but not
> > yet waited upon aka is a zombie procfd_send_signal()
* Christian Brauner:
> Ok, I finally have access to source code again. Scratch what I said above!
> I looked at the code and tested it. If the process has exited but not
> yet waited upon aka is a zombie procfd_send_signal() will return 0. This
> is identical to kill(2) behavior. It should've been
On Sat, Dec 01, 2018 at 12:52:24PM +1300, Christian Brauner wrote:
> On November 30, 2018 1:28:15 AM GMT+13:00, Florian Weimer
> wrote:
> >Disclaimer: I'm looking at this patch because Christian requested it.
> >I'm not a kernel developer.
>
> Given all your expertise this really doesn't matter.
On Sat, Dec 01, 2018 at 09:28:47AM -0600, 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, siginfo_t *uinfo)
> {
> #ifdef CONFIG_COMPAT
> if (in_compat_syscall)
>
On Sat, Dec 1, 2018 at 4:07 PM Eric W. Biederman wrote:
>
> 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_a
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, siginfo_t *uinfo)
>> {
>> #ifdef CONFIG_COMPAT
>>
On December 2, 2018 4:52:37 AM GMT+13:00, Andy Lutomirski
wrote:
>
>
>> 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, siginf
> 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, siginfo_t *uinfo)
> {
> #ifdef CONFIG_COMPAT
>if (in_compat_syscall)
>
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
retu
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
>> > > wrote:
>> > >
>> > > It looks like we already have
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 having
On Sat, Dec 1, 2018 at 9:51 AM Arnd Bergmann wrote:
> On Sat, Dec 1, 2018 at 12:54 AM Andy Lutomirski wrote:
> > On Fri, Nov 30, 2018 at 2:10 PM Arnd Bergmann wrote:
> > > On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski wrote:
> > > > On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote:
> > >
On December 1, 2018 9:51:18 PM GMT+13:00, Arnd Bergmann wrote:
>On Sat, Dec 1, 2018 at 12:54 AM Andy Lutomirski
>wrote:
>> On Fri, Nov 30, 2018 at 2:10 PM Arnd Bergmann wrote:
>> > On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski
>wrote:
>> > > On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann
>wro
On Sat, Dec 1, 2018 at 12:54 AM Andy Lutomirski wrote:
> On Fri, Nov 30, 2018 at 2:10 PM Arnd Bergmann wrote:
> > On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski wrote:
> > > On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote:
> > > > siginfo_t as it is now still has a number of other downside
On November 30, 2018 10:40:49 AM GMT+13:00, Arnd Bergmann wrote:
>On Thu, Nov 29, 2018 at 10:35 PM Christian Brauner
> wrote:
>> On Thu, Nov 29, 2018 at 10:02:13PM +0100, Arnd Bergmann wrote:
>> > On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski
> wrote:
>> >
>> > Is the current procfd_signal() pro
On December 1, 2018 12:46:22 PM GMT+13:00, Andy Lutomirski
wrote:
>On Fri, Nov 30, 2018 at 3:40 PM Christian Brauner
> wrote:
>>
>> On December 1, 2018 12:12:53 PM GMT+13:00, Arnd Bergmann
> wrote:
>> >On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione
>
>> >wrote:
>> >> On Fri, Nov 30, 2018 at 2:
On Fri, Nov 30, 2018 at 2:10 PM Arnd Bergmann wrote:
>
> On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski wrote:
> >
> > 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 ha
On November 30, 2018 1:28:15 AM GMT+13:00, Florian Weimer
wrote:
>Disclaimer: I'm looking at this patch because Christian requested it.
>I'm not a kernel developer.
Given all your expertise this really doesn't matter. :)
You're the one having to deal with this
in glibc after all.
Thanks for doin
On Fri, Nov 30, 2018 at 3:40 PM Christian Brauner wrote:
>
> On December 1, 2018 12:12:53 PM GMT+13:00, Arnd Bergmann
> wrote:
> >On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione
> >wrote:
> >> On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner
> > wrote:
> >> > On December 1, 2018 11:09:58 AM
On December 1, 2018 12:12:53 PM GMT+13:00, Arnd Bergmann wrote:
>On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione
>wrote:
>> On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner
> wrote:
>> > On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann
> wrote:
>> >
>> > One humble point I would like t
On Sat, Dec 1, 2018 at 12:12 AM Arnd Bergmann wrote:
>
> On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione wrote:
> > On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner
> > wrote:
> > > On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann
> > > wrote:
> > >
> > > One humble point I would l
On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione wrote:
> On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner
> wrote:
> > On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann
> > wrote:
> >
> > One humble point I would like to make is that what I care about most is a
> > sensible way forw
On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner wrote:
>
> On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann
> wrote:
> >On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski
> >wrote:
> >>
> >> On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote:
> >> > siginfo_t as it is now still has a n
On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann wrote:
>On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski
>wrote:
>>
>> 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
On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski wrote:
>
> 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). H
On December 1, 2018 5:35:45 AM GMT+13:00, Andy Lutomirski
wrote:
>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 cou
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 having
> a single syscall entry point
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
> > > wrote:
> > >
> > > It looks like we already have a 'struct signalfd_siginfo' that i
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 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:
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:
>> >>
On 2018-11-29, Arnd Bergmann wrote:
> waitid() probably remains on my plate anyway, and I hope understand
> where we're at with it.
Having a way to wait on a processfd is something we'll eventually need,
though the semantics of zombies might get a little bit hairy. I propose
we work through that
On Thu, Nov 29, 2018 at 10:35 PM Christian Brauner wrote:
> On Thu, Nov 29, 2018 at 10:02:13PM +0100, Arnd Bergmann wrote:
> > On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski wrote:
> >
> > Is the current procfd_signal() proposal (under whichever name) sufficient
> > to correctly implement both s
On Thu, Nov 29, 2018 at 10:02:13PM +0100, Arnd Bergmann wrote:
> 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
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:
> On November 30, 2018 5:54:18
> 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:
>>>
On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
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:
> >
> > On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
> > wrote:
> > >
> > >
> > >> On Nov 29, 2018, at 4:28 AM, Florian Weimer
> > >wrote:
> > >>
> > >>
On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner wrote:
>
> On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
> wrote:
> >
> >
> >> On Nov 29, 2018, at 4:28 AM, Florian Weimer
> >wrote:
> >>
> >> Disclaimer: I'm looking at this patch because Christian requested it.
> >> I'm not a ker
On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
wrote:
>
>
>> On Nov 29, 2018, at 4:28 AM, Florian Weimer
>wrote:
>>
>> Disclaimer: I'm looking at this patch because Christian requested it.
>> I'm not a kernel developer.
>>
>> * Christian Brauner:
>>
>>> diff --git a/arch/x86/entry
> On Nov 29, 2018, at 4:28 AM, Florian Weimer wrote:
>
> Disclaimer: I'm looking at this patch because Christian requested it.
> I'm not a kernel developer.
>
> * Christian Brauner:
>
>> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
>> b/arch/x86/entry/syscalls/syscall_32.tbl
>> index
Disclaimer: I'm looking at this patch because Christian requested it.
I'm not a kernel developer.
* Christian Brauner:
> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
> b/arch/x86/entry/syscalls/syscall_32.tbl
> index 3cf7b533b3d1..3f27ffd8ae87 100644
> --- a/arch/x86/entry/syscalls/syscal
On Tue, Nov 20, 2018 at 11:54 AM Christian Brauner wrote:
> ---
> arch/x86/entry/syscalls/syscall_32.tbl | 1 +
> arch/x86/entry/syscalls/syscall_64.tbl | 2 +
> fs/proc/base.c | 11 ++-
> fs/proc/internal.h | 5 -
> include/linux/proc_fs.h
On 2018-11-20, Christian Brauner wrote:
> The kill() syscall operates on process identifiers. After a process has
> exited its pid can be reused by another process. If a caller sends a signal
> to a reused pid it will end up signaling the wrong process. This issue has
> often surfaced and there ha
On Tue, Nov 20, 2018 at 11:51:23AM +0100, Christian Brauner wrote:
> The kill() syscall operates on process identifiers. After a process has
> exited its pid can be reused by another process. If a caller sends a signal
> to a reused pid it will end up signaling the wrong process. This issue has
> o
The kill() syscall operates on process identifiers. After a process has
exited its pid can be reused by another process. If a caller sends a signal
to a reused pid it will end up signaling the wrong process. This issue has
often surfaced and there has been a push [1] to address this problem.
This
53 matches
Mail list logo
