[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALCETrV8BDqTpSisPLH=QYuEi0cSzZEX3gf9gO++Y3ioK3BzaQ@mail.gmail.com>
Date: Tue, 3 May 2016 09:44:39 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Peter Zijlstra <peterz@...radead.org>,
"Amanieu d'Antras" <amanieu@...il.com>,
Vladimir Davydov <vdavydov@...allels.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirski <luto@...capital.net>,
Ingo Molnar <mingo@...nel.org>,
Pavel Emelyanov <xemul@...allels.com>,
Shuah Khan <shuahkh@....samsung.com>,
Sasha Levin <sasha.levin@...cle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Richard Weinberger <richard@....at>,
Brian Gerst <brgerst@...il.com>,
Borislav Petkov <bp@...en8.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
Stas Sergeev <stsp@...t.ru>, Al Viro <viro@...iv.linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>,
Oleg Nesterov <oleg@...hat.com>
Cc: "linux-tip-commits@...r.kernel.org"
<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:core/signals] signals/sigaltstack: Prepare to add new SS_xxx flags
On Tue, May 3, 2016 at 9:13 AM, Andy Lutomirski <luto@...capital.net> wrote:
> On Tue, May 3, 2016 at 12:50 AM, tip-bot for Stas Sergeev
> <tipbot@...or.com> wrote:
>> Commit-ID: 407bc16ad1769f5cb8ad9555611cb198187ef4cd
>> Gitweb: http://git.kernel.org/tip/407bc16ad1769f5cb8ad9555611cb198187ef4cd
>> Author: Stas Sergeev <stsp@...t.ru>
>> AuthorDate: Thu, 14 Apr 2016 23:20:03 +0300
>> Committer: Ingo Molnar <mingo@...nel.org>
>> CommitDate: Tue, 3 May 2016 08:37:59 +0200
>>
>> signals/sigaltstack: Prepare to add new SS_xxx flags
>>
>> This patch adds SS_FLAG_BITS - the mask that splits sigaltstack
>> mode values and bit-flags. Since there is no bit-flags yet, the
>> mask is defined to 0. The flags are added by subsequent patches.
>> With every new flag, the mask should have the appropriate bit cleared.
>>
>> This makes sure if some flag is tried on a kernel that doesn't
>> support it, the -EINVAL error will be returned, because such a
>> flag will be treated as an invalid mode rather than the bit-flag.
>>
>> That way the existence of the particular features can be probed
>> at run-time.
>>
>> This change was suggested by Andy Lutomirski:
>>
>> https://lkml.org/lkml/2016/3/6/158
>
> LGTM.
Correction: does not LGTM. In a sensible design, sigaltstack would
report flags back to the caller. I will send a fix.
--Andy
Powered by blists - more mailing lists