From: Thomas Gleixner <tglx@linutronix.de>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Dave Hansen <dave.hansen@intel.com>
Cc: Borislav Petkov <bp@suse.de>,
"Chang S. Bae" <chang.seok.bae@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] core/urgent for v5.16-rc6
Date: Mon, 10 Jan 2022 20:01:09 +0100 [thread overview]
Message-ID: <87ilurqutm.ffs@tglx> (raw)
In-Reply-To: <CAHk-=wgC3Q4+3Dc4FhQ6WopwZxoMMVxaA2TSJm-CH1CQ4hQWfw@mail.gmail.com>
On Mon, Dec 20 2021 at 08:25, Linus Torvalds wrote:
> On Mon, Dec 20, 2021 at 8:20 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Whatever. I don't care that much, but this all smells like you just
>> dug your own hole for very questionable causes, and instead of a
>> "don't do that then" this all is doubling down on a bad idea.
>
> It further looks like it's really only the sas_ss_size that is
> checked, so if people wan tto have a lock, make it clear that's the
> only thing that the lock is about.
>
> So the actual "do I even need to lock" condition should likely just be
>
> if (ss_size < t->sas_ss_size)
> .. don't bother locking ..
>
> but as mentioned, I don't really see much of a point in being so
> careful even about the growing case.
>
> If somebody is changing xstate features concurrently with another
> thread setting up their altstack, they can keep both pieces.
In principle I agree, but the whole signal stack business is a nightmare
and the way how a program ends up using some xfeature is hideous at
best.
An application does not necessarily know about it at all because the
usage is hidden in random library code. So there is a chance to run into
concurrency issues for real.
Let me grab your (Dave's) patch and rework the whole thing into
something sensible. I had a patch around which replaced sighand lock
with an explicit lock for that purpose. Let me dig that out and polish
it all up.
Thanks,
tglx
next prev parent reply other threads:[~2022-01-10 19:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-19 13:40 [GIT PULL] core/urgent for v5.16-rc6 Borislav Petkov
2021-12-19 20:14 ` Linus Torvalds
2021-12-19 20:16 ` Linus Torvalds
2021-12-20 5:25 ` Dave Hansen
2021-12-20 16:20 ` Linus Torvalds
2021-12-20 16:25 ` Linus Torvalds
2022-01-10 19:01 ` Thomas Gleixner [this message]
2021-12-19 20:34 ` pr-tracker-bot
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=87ilurqutm.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bp@suse.de \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).