[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o99y72gi.fsf@xmission.com>
Date: Thu, 06 Dec 2018 15:46:53 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Christian Brauner <christian@...uner.io>
Cc: linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
luto@...nel.org, arnd@...db.de, serge@...lyn.com, jannh@...gle.com,
akpm@...ux-foundation.org, oleg@...hat.com, cyphar@...har.com,
viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
dancol@...gle.com, timmurray@...gle.com, linux-man@...r.kernel.org,
keescook@...omium.org, fweimer@...hat.com, tglx@...utronix.de,
x86@...nel.org
Subject: Re: [PATCH v4] signal: add taskfd_send_signal() syscall
Christian Brauner <christian@...uner.io> writes:
>> Your intention is to add the thread case to support pthreads once the
>> process case is sorted out. So this is something that needs to be made
>> clear. Did I miss how you plan to handle threads?
>
> Yeah, maybe you missed it in the commit message [2] which is based on a
> discussion with Andy [3] and Arnd [4]:
Looking at your references I haven't missed it. You are not deciding
anything as of yet to keep it simple. Except you are returning
EOPNOTSUPP. You are very much intending to do something.
Decide. Do you use the flags 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" <ebiederm@...ssion.com>
There are a lot of fundamental maintenance issues and you can very easily
get them wrong if you are not clear on the job of the file descriptor
and the job of the flags argument.
I want don't want new crap that we have to abandon that has a nasty set
of bugs because no one wanted to think through the system call all of
the way and understand the corner cases.
Eric
Powered by blists - more mailing lists