[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVxU8FpsBraEa6Ni2Edd2kbtWkzVetMUGe+_jJt6d_8zA@mail.gmail.com>
Date: Tue, 3 May 2016 09:13:53 -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 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.
Powered by blists - more mailing lists