On Sat, 2007-06-23 at 16:05 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote:
> > Wasn't it you that bitched (just a few days ago) because multiple
> > threads
> > could not use the same signalfd and they (by your initial thought) had
> > to
> > creat
On 06/22, Linus Torvalds wrote:
>
> On Sat, 23 Jun 2007, Benjamin Herrenschmidt wrote:
> >
> > >
> > > It does exactly so, please note this chunk
> > >
> > > @@ -330,7 +339,7 @@ asmlinkage long sys_signalfd(int ufd, si
> > >
> > > init_waitqueue_head(&ctx->wqh);
> > >
On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote:
> Wasn't it you that bitched (just a few days ago) because multiple
> threads
> could not use the same signalfd and they (by your initial thought) had
> to
> create one per thread?
He said multiple process and you say multiple threads...
On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote:
> On Fri, 22 Jun 2007, Nicholas Miell wrote:
>
> > You could just get rid of the process/sighand/whatever reference
> > entirely and just make reads on a signalfd always dequeue signals for
> > the current thread.
>
> Duh?! ...
>
> > You'd
On Fri, 22 Jun 2007, Nicholas Miell wrote:
> You could just get rid of the process/sighand/whatever reference
> entirely and just make reads on a signalfd always dequeue signals for
> the current thread.
Duh?! ...
> You'd lose the ability to pass signalfds around to other processes, but
> I'm n
On Sat, 2007-06-23 at 09:19 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2007-06-23 at 09:16 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2007-06-22 at 15:47 -0700, Linus Torvalds wrote:
> > > Quite frankly, it strikes me that if we want to do this, then we
> > > shouldn't
> > > save the _p
On Sat, 2007-06-23 at 09:16 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-22 at 15:47 -0700, Linus Torvalds wrote:
> > Quite frankly, it strikes me that if we want to do this, then we shouldn't
> > save the _process_ information at all, we should save the "sighand"
> > instead.
> >
> >
On Fri, 2007-06-22 at 15:47 -0700, Linus Torvalds wrote:
> Quite frankly, it strikes me that if we want to do this, then we shouldn't
> save the _process_ information at all, we should save the "sighand"
> instead.
>
> So either we save the process info, or we save the sighand, but saving the
>
On Fri, 22 Jun 2007, Linus Torvalds wrote:
> Quite frankly, it strikes me that if we want to do this, then we shouldn't
> save the _process_ information at all, we should save the "sighand"
> instead.
>
> So either we save the process info, or we save the sighand, but saving the
> "group_leade
On Sat, 23 Jun 2007, Benjamin Herrenschmidt wrote:
>
> >
> > It does exactly so, please note this chunk
> >
> > @@ -330,7 +339,7 @@ asmlinkage long sys_signalfd(int ufd, si
> >
> > init_waitqueue_head(&ctx->wqh);
> > ctx->sigmask = sigmask;
> > -
>
> It does exactly so, please note this chunk
>
> @@ -330,7 +339,7 @@ asmlinkage long sys_signalfd(int ufd, si
>
> init_waitqueue_head(&ctx->wqh);
> ctx->sigmask = sigmask;
> - ctx->tsk = current;
> + ctx->tsk = current->group_le
On 06/22, Benjamin Herrenschmidt wrote:
>
> That is, it -does- make sense to be able to create a signal singalfd in
> a process and have N threads reading from it and getting either shared
> signals or their local private signals.
Great.
> I just don't like the actual implementation of it by cha
> OK. But in that case I think we should go further, and make signalfd
> "per process", not "per thread", see
>
> http://marc.info/?l=linux-kernel&m=118241815219430
>
> Every thread gets its own local signals plus shared ones.
>
> (I promise, this is the last piece of spam from me on this
On 06/22, Benjamin Herrenschmidt wrote:
>
> Yeah well... I wanted to have the least surprise path... that is,
> without my patch, signalfd will "sometimes" steal the SIGSEGV depending
> on who races to the lock first, thus causing the target thread to
> re-execute the faulting instruction and takin
On Fri, 22 Jun 2007, Benjamin Herrenschmidt wrote:
>
> Yeah well... I wanted to have the least surprise path... that is,
> without my patch, signalfd will "sometimes" steal the SIGSEGV depending
> on who races to the lock first
Oh, absolutely. I thought we all agreed that Ben's patch was the ri
On Thu, 2007-06-21 at 22:58 +0400, Oleg Nesterov wrote:
>
> > No "stealing". No signalfd, no *nothing*. Just normal signal
> behaviour.
>
> _Another_ thread could steal SIGSEGV via read(signalfd) without Ben's patch.
> This is what Ben and Davide are worried about. I think we should not worry,
>
On 06/21, Linus Torvalds wrote:
>
> On Thu, 21 Jun 2007, Oleg Nesterov wrote:
> >
> > Yes, the target thread is the one that caused the SIGSEGV, it sends the
> > signal
> > to itself. entry.S:ret_from_exception should notice this signal and
> > _dequeue_
> > it, no? This signal could be stealed
On Thu, 21 Jun 2007, Oleg Nesterov wrote:
>
> Yes, the target thread is the one that caused the SIGSEGV, it sends the signal
> to itself. entry.S:ret_from_exception should notice this signal and _dequeue_
> it, no? This signal could be stealed by signal(SIG_IGN) which runs after it
> was deliver
On 06/21, Linus Torvalds wrote:
>
> On Thu, 21 Jun 2007, Oleg Nesterov wrote:
> >
> > Yes, force_sig() unblocks and un-ignores the signal. However, unlike
> > group-wide
> > signals, thread-specific signals do not convert themselves to SIGKILL on
> > delivery.
> > The target thread should dequeu
On Thu, 21 Jun 2007, Oleg Nesterov wrote:
>
> Yes, force_sig() unblocks and un-ignores the signal. However, unlike
> group-wide
> signals, thread-specific signals do not convert themselves to SIGKILL on
> delivery.
> The target thread should dequeue SIGSEGV and then it calls do_group_exit().
On 06/20, Linus Torvalds wrote:
>
> On Wed, 20 Jun 2007, Oleg Nesterov wrote:
> >
> > Also, suppose that some thread does
> >
> > for (;;)
> > signal(SIGSEGV, SIG_IGN);
> >
> > Now we have the same situation. do_sigaction() can steal SIGSEGV from
> > another thread.
>
> Actuall
On Wed, 20 Jun 2007, Oleg Nesterov wrote:
>
> Also, suppose that some thread does
>
> for (;;)
> signal(SIGSEGV, SIG_IGN);
>
> Now we have the same situation. do_sigaction() can steal SIGSEGV from
> another thread.
Actually, that shouldn't be possible.
See "force_sig_info
On Wed, 20 Jun 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-06-19 at 19:15 -0700, Davide Libenzi wrote:
>
> > Ok, why instead don't we go for something like the attached patch?
> > We exclude sync signals from signalfd, but we don't limit signalfd to
> > shared signals. Ie, we should be ab
On 06/20, Benjamin Herrenschmidt wrote:
>
> On Tue, 2007-06-19 at 18:06 +0400, Oleg Nesterov wrote:
> > On 06/19, Benjamin Herrenschmidt wrote:
> > >
> > > On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote:
> > >
> > > > The commited &q
On Tue, 2007-06-19 at 19:15 -0700, Davide Libenzi wrote:
> Ok, why instead don't we go for something like the attached patch?
> We exclude sync signals from signalfd, but we don't limit signalfd to
> shared signals. Ie, we should be able to fetch a signal sent with
> sys_tkill() to threads diffe
On Wed, 20 Jun 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-06-19 at 16:49 -0700, Davide Libenzi wrote:
>
> > Actually, I think signalfd is fine as is, with Ben's patch applied.
> > Signalfd should only fetch shared signals, not specific ones (in any
> > case).
>
> The only advantage of
On Tue, 2007-06-19 at 16:49 -0700, Davide Libenzi wrote:
> Actually, I think signalfd is fine as is, with Ben's patch applied.
> Signalfd should only fetch shared signals, not specific ones (in any
> case).
The only advantage of that additional patch is that it will allow any
thread to fetch it
On Tue, 19 Jun 2007, Oleg Nesterov wrote:
> The commited "Fix signalfd interaction with thread-private signals"
> (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> this.
>
> We can do something like
>
> int signalfd_dequeue_sign
On Tue, 2007-06-19 at 18:06 +0400, Oleg Nesterov wrote:
> On 06/19, Benjamin Herrenschmidt wrote:
> >
> > On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote:
> >
> > > The commited "Fix signalfd interaction with thread-private signals"
> > >
On Wed, 20 Jun 2007, Oleg Nesterov wrote:
> Well, I think the kernel doesn't make any assumptions on that. It can't
> guarantee the signal will be actually dequeued, to begin with.
>
> (That said, I probably missed something, in that case I'd like to be
> educated. This is the real reason why I
On 06/19, Davide Libenzi wrote:
>
> On Tue, 19 Jun 2007, Oleg Nesterov wrote:
>
> > On 06/19, Benjamin Herrenschmidt wrote:
> > >
> > > On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote:
> > >
> > > > The commited "Fix signal
On 06/19, Davide Libenzi wrote:
>
> On Tue, 19 Jun 2007, Oleg Nesterov wrote:
>
> > The commited "Fix signalfd interaction with thread-private signals"
> > (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> > this.
> >
On Tue, 19 Jun 2007, Oleg Nesterov wrote:
> On 06/19, Benjamin Herrenschmidt wrote:
> >
> > On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote:
> >
> > > The commited "Fix signalfd interaction with thread-private signals"
> > > (commit
On Tue, 19 Jun 2007, Oleg Nesterov wrote:
> The commited "Fix signalfd interaction with thread-private signals"
> (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> this.
>
> We can do something like
>
> int signalfd_dequeue_sign
On 06/19, Benjamin Herrenschmidt wrote:
>
> On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote:
>
> > The commited "Fix signalfd interaction with thread-private signals"
> > (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> >
On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote:
> The commited "Fix signalfd interaction with thread-private signals"
> (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> this.
Indeed, if you want what Davide described, you need to also change
or the process shared ones
> (tsk->signal->shared_pending). This will be the behaviour once Ben's
patch
> is applied.
The commited "Fix signalfd interaction with thread-private signals"
(commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't
37 matches
Mail list logo
