From: Davidlohr Bueso <dbueso@suse.de>
To: Varad Gautam <varad.gautam@suse.com>
Cc: linux-kernel@vger.kernel.org,
Matthias von Faber <matthias.vonfaber@aox-tech.de>,
Christian Brauner <christian.brauner@ubuntu.com>,
Oleg Nesterov <oleg@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Manfred Spraul <manfred@colorfullife.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] ipc/mqueue: Avoid relying on a stack reference past its expiry
Date: Wed, 05 May 2021 08:11:56 -0700 [thread overview]
Message-ID: <6fbcb0fa502e7574f87213fc29877ed8@suse.de> (raw)
In-Reply-To: <fe1b29a0-af09-e270-de52-09bacac35d86@suse.com>
On 2021-05-05 00:49, Varad Gautam wrote:
> The race here really is about the lifetime of __pipelined_op's `this`
> argument only
> being guaranteed for some duration of the call (ie, until someone sets
> ->state = STATE_READY). It is not about when wake_q addition happens,
> as long as it is
> being fed a valid task_struct.
Again, it's all about ensuring that the READY_STATE is set last, the
blocked
task has no business returning in the first place, making both races
(exit and
the one reported here) similar by ending up using bogus memory.
...
> I considered that initially, but given that the race isn't connected
> with wakeup, I
> preferred the current approach which makes this fact explicit by
> showing what's
> valid/invalid during __pipelined_op.
I understand your point, but this is why I updated the ordering
comments. Furthermore
there is no reason to decouple the task's refcount with the wake_q_add
operation, it
just makes the code weird and harder to follow.
Thanks,
Davidlohr
next prev parent reply other threads:[~2021-05-05 15:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-04 15:55 Varad Gautam
2021-05-04 21:53 ` Davidlohr Bueso
2021-05-05 7:49 ` Varad Gautam
2021-05-05 15:11 ` Davidlohr Bueso [this message]
2021-05-05 15:36 ` Varad Gautam
2021-05-05 16:24 ` Davidlohr Bueso
2021-05-05 17:09 ` Davidlohr Bueso
2021-05-08 17:21 ` Manfred Spraul
2021-05-08 17:12 ` Manfred Spraul
2021-05-10 10:38 ` Varad Gautam
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=6fbcb0fa502e7574f87213fc29877ed8@suse.de \
--to=dbueso@suse.de \
--cc=akpm@linux-foundation.org \
--cc=christian.brauner@ubuntu.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=matthias.vonfaber@aox-tech.de \
--cc=oleg@redhat.com \
--cc=varad.gautam@suse.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®