All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Chris Metcalf <cmetcalf@tilera.com>
Cc: Matt Fleming <matt@console-pimps.org>, Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Matt Fleming <matt.fleming@linux.intel.com>
Subject: [PATCH 0/1] tile: do_hardwall_trap: do not play with task->sighand
Date: Tue, 26 Apr 2011 22:36:44 +0200	[thread overview]
Message-ID: <20110426203644.GA10177@redhat.com> (raw)
In-Reply-To: <4DB17CDE.3050603@tilera.com>

On 04/22, Chris Metcalf wrote:
>
> On 4/21/2011 9:03 PM, Oleg Nesterov wrote:
> > Hmm. It turns out, I can't make the patch because I do not understand
> > what this code tries to do.
> >
> > hardwall_activate() adds the thread to hardwall_list, but do_hardwall_trap()
> > sends the signal to the whole process. I know nothing about arch/tile and
> > probably this is correct, but could you confirm this?
>
> Yes, the intended behavior is to send the signal to the process, as a way
> of indicating the OS's displeasure with sending a malformed packet on the
> user network.  But I think sending it to the specific thread is reasonable
> too; I don't have a strong preference in this design.
>
> > Note that SIGILL can be delivered to another thread in the thread-group, is
> > it correct?
> >
> > Also. Is it supposed that SIGILL can have a hanlder or can be blocked, or
> > it should always kill the whole thread group?
>
> A handler would be reasonable for the process.

OK. In this case the thread-specific SIGILL makes more sense afaics.

> > I think we need the patch below, assuming that SIGILL should be sent to
> > the single thread and it is fine to have a handler for SIGILL.
>
> Thanks; I appreciate the additional code review in any case.  I'll look at
> the ramifications of the change in more detail when I return from vacation
> late next week.

Great. I am sending the same patch + the changelog.

Please do not forget, I know _nothing_ about arch/tile, and of course the
patch was not tested.

Oleg.


  reply	other threads:[~2011-04-26 20:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 19:21 [RFC][PATCH 0/5] Improve signal delivery scalability Matt Fleming
2011-04-05 19:21 ` [RFC][PATCH 1/5] signals: Always place SIGCONT and SIGSTOP on 'shared_pending' Matt Fleming
2011-04-05 20:19   ` Oleg Nesterov
2011-04-05 20:50     ` Matt Fleming
2011-04-06 12:57       ` Oleg Nesterov
2011-04-06 13:09         ` Tejun Heo
2011-04-06 13:30           ` Matt Fleming
2011-04-06 13:15         ` Matt Fleming
2011-04-11 18:50           ` Oleg Nesterov
2011-04-11 19:24             ` Matt Fleming
2011-04-05 19:21 ` [RFC][PATCH 2/5] signals: Introduce per-thread siglock and action rwlock Matt Fleming
2011-04-13 19:42   ` Oleg Nesterov
2011-04-14 10:34     ` Matt Fleming
2011-04-14 19:00       ` Oleg Nesterov
2011-04-16 13:08         ` Matt Fleming
2011-04-18 16:45           ` Oleg Nesterov
2011-04-21 19:03             ` arch/tile/kernel/hardwall.c:do_hardwall_trap unsafe/wrong usage of ->sighand Oleg Nesterov
2011-04-22 13:04               ` Chris Metcalf
2011-04-26 20:36                 ` Oleg Nesterov [this message]
2011-04-26 20:37                   ` [PATCH 1/1] tile: do_hardwall_trap: do not play with task->sighand Oleg Nesterov
2011-05-02 22:42                     ` Chris Metcalf
2011-04-26  9:46             ` [RFC][PATCH 2/5] signals: Introduce per-thread siglock and action rwlock Matt Fleming
2011-04-05 19:21 ` [RFC][PATCH 3/5] ia64: Catch up with new sighand action spinlock Matt Fleming
2011-04-05 19:21 ` [RFC][PATCH 4/5] signals: Introduce __dequeue_private_signal helper function Matt Fleming
2011-04-05 19:21 ` [RFC][PATCH 5/5] signals: Don't hold shared siglock across signal delivery Matt Fleming
2011-04-13 20:12   ` Oleg Nesterov
2011-04-14 10:57     ` Matt Fleming
2011-04-14 19:20       ` Oleg Nesterov
2011-04-16 13:27         ` Matt Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110426203644.GA10177@redhat.com \
    --to=oleg@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=cmetcalf@tilera.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@linux.intel.com \
    --cc=matt@console-pimps.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.