On Mon 2015-06-15 21:14:29, Oleg Nesterov wrote:
> Ah, understand. You think that we need to take ->siglock in advance
> to avoid the race with SIGCONT?
exactly
> No, we don't. Let me show you the code I suggested again:
>
> void kthread_do_signal_stop(void)
> {
> spin_
Hi Petr,
On 06/15, Petr Mladek wrote:
>
> I am sorry for the late reply. I wanted to think more before answering
> all the mails.
Don't worry I am always late ;)
> On Mon 2015-06-08 23:13:36, Oleg Nesterov wrote:
> > >
> > > Hmm, the helper would have a strange semantic. You need to take
> > > s
Hi Oleg,
I am sorry for the late reply. I wanted to think more before answering
all the mails.
On Mon 2015-06-08 23:13:36, Oleg Nesterov wrote:
> I do not. Contrary, I think this needs more code in the likely case.
> Anyway, this API won't have too many users, so I don't even this this
> is that
Hello, Jiri.
On Tue, Jun 09, 2015 at 02:15:24PM +0200, Jiri Kosina wrote:
> To me, the ultimate goal (*) is to make it possible for kthread to be able
> to decide whether it wants "some kind of default behavior" (however that'd
> be defined), or "ignore all", or "just handle this set of signals
On Tue, 9 Jun 2015, Tejun Heo wrote:
> While I agree that it'd be great to consolidate the existing kthread
> signal users, I feel quite uncomfortable with doing full-fledged
> signal handling for kthreads which try to mimic the userland behavior.
> Most of the default behaviors don't make sense f
Hello, Petr.
On Fri, Jun 05, 2015 at 05:01:05PM +0200, Petr Mladek wrote:
> Several kthreads already handle signals some way. They do so
> in different ways, search for allow_signal().
>
> This patch allows to handle the signals in a more uniform way using
> kthread_do_signal().
>
> The main que
Let me first repeat that I agree that everything is subjective ;)
On 06/08, Petr Mladek wrote:
>
> To be honest, this patch set does _not_ make any big change.
But to me it does because (again, imo) it adds the a) unnecessary
and b) wrong interface.
But yes, yes, I agree that most (all?) of kthr
On Sat 2015-06-06 23:58:16, Oleg Nesterov wrote:
> On 06/05, Petr Mladek wrote:
> >
> > The main question is how much it should follow POSIX and the signal
> > handling of user space processes. On one hand, we want to be as close
> > as possible.
>
> Why? Let the kthread decide what it should if i
On 06/05, Petr Mladek wrote:
>
> The main question is how much it should follow POSIX and the signal
> handling of user space processes. On one hand, we want to be as close
> as possible.
Why? Let the kthread decide what it should if it gets, say, SIGSTOP.
> Finally, kthread_do_signal() is called
Several kthreads already handle signals some way. They do so
in different ways, search for allow_signal().
This patch allows to handle the signals in a more uniform way using
kthread_do_signal().
The main question is how much it should follow POSIX and the signal
handling of user space processes.
10 matches
Mail list logo
