From: Oleg Nesterov <oleg@redhat.com>
To: kernel test robot <lkp@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kusaram Devineni <kusaram@devineni.in>,
oe-kbuild-all@lists.linux.dev,
Linux Memory Management List <linux-mm@kvack.org>,
Jens Axboe <axboe@kernel.dk>, Kees Cook <kees@kernel.org>,
linux-kernel@vger.kernel.org, io-uring@vger.kernel.org
Subject: Re: [PATCH] signalfd: don't dequeue the forced fatal signals
Date: Tue, 7 Apr 2026 23:22:04 +0200 [thread overview]
Message-ID: <adV1fCyvANv4h2dH@redhat.com> (raw)
In-Reply-To: <202604080450.mkKRp9Mk-lkp@intel.com>
On 04/08, kernel test robot wrote:
>
> kernel test robot noticed the following build warnings:
...
> sparse warnings: (new ones prefixed by >>)
> >> fs/signalfd.c:53:40: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct k_sigaction *k @@ got struct k_sigaction [noderef] __rcu * @@
...
> vim +53 fs/signalfd.c
>
> 50
> 51 static void mk_sigmask(struct signalfd_ctx *ctx, sigset_t *sigmask)
> 52 {
> > 53 struct k_sigaction *k = current->sighand->action;
I am going to ignore this new warning...
Yes, task_struct->sighand is __rcu. Not sure this annotation makes a lot of sense.
In any case. current->sighand is always stable. Plus task->sighand is stable under siglock.
We have a lot of (correct) non-rcu deferences of ->sighand.
I think that only lock_task_sighand() needs rcu_dereference(tsk->sighand).
Say, __exit_signal() does
sighand = rcu_dereference_check(tsk->sighand,
lockdep_tasklist_lock_is_held());
To me this just adds the unnecessary noise. I do not want to add another precedent.
Oleg.
prev parent reply other threads:[~2026-04-07 21:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-05 16:09 [PATCH] signalfd: don't dequeue the forced fatal signals Oleg Nesterov
2026-04-06 4:39 ` Kees Cook
2026-04-06 13:32 ` Oleg Nesterov
2026-04-06 13:37 ` [PATCH v2] " Oleg Nesterov
2026-04-07 20:10 ` [PATCH] " kernel test robot
2026-04-07 21:22 ` Oleg Nesterov [this message]
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=adV1fCyvANv4h2dH@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=kees@kernel.org \
--cc=kusaram@devineni.in \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
/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.