WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
into another.
Signed-off-by: Igor Stoppa <[email protected]>
Acked-by: Kees Cook <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
kernel/seccomp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index fd023ac24e10..5a2a9af4663e 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -195,7 +195,7 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
READ_ONCE(current->seccomp.filter);
/* Ensure unexpected behavior doesn't result in failing open. */
- if (unlikely(WARN_ON(f == NULL)))
+ if (WARN_ON(f == NULL))
return SECCOMP_RET_KILL_PROCESS;
if (!sd) {
@@ -297,7 +297,7 @@ static inline pid_t seccomp_can_sync_threads(void)
/* Return the first thread that cannot be synchronized. */
failed = task_pid_vnr(thread);
/* If the pid cannot be resolved, then return -ESRCH */
- if (unlikely(WARN_ON(failed == 0)))
+ if (WARN_ON(failed == 0))
failed = -ESRCH;
return failed;
}
--
2.17.1
On Wed, Sep 5, 2018 at 1:34 PM, Igor Stoppa <[email protected]> wrote:
> WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
> into another.
>
> Signed-off-by: Igor Stoppa <[email protected]>
> Acked-by: Kees Cook <[email protected]>
Should I take this, or is it part of your series going somewhere else?
-Kees
> Cc: [email protected]
> Cc: [email protected]
> ---
> kernel/seccomp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index fd023ac24e10..5a2a9af4663e 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -195,7 +195,7 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
> READ_ONCE(current->seccomp.filter);
>
> /* Ensure unexpected behavior doesn't result in failing open. */
> - if (unlikely(WARN_ON(f == NULL)))
> + if (WARN_ON(f == NULL))
> return SECCOMP_RET_KILL_PROCESS;
>
> if (!sd) {
> @@ -297,7 +297,7 @@ static inline pid_t seccomp_can_sync_threads(void)
> /* Return the first thread that cannot be synchronized. */
> failed = task_pid_vnr(thread);
> /* If the pid cannot be resolved, then return -ESRCH */
> - if (unlikely(WARN_ON(failed == 0)))
> + if (WARN_ON(failed == 0))
> failed = -ESRCH;
> return failed;
> }
> --
> 2.17.1
>
--
Kees Cook
Pixel Security
On 06/09/18 01:23, Kees Cook wrote:
> Should I take this, or is it part of your series going somewhere else?
It turned out it doesn't really work to have a generic series against 20
trees :-/
I'm submitting them individually to each subsystem.
So this one is just for security.
--
thanks, igor
On Wed, Sep 5, 2018 at 3:49 PM, Igor Stoppa <[email protected]> wrote:
>
>
> On 06/09/18 01:23, Kees Cook wrote:
>
>> Should I take this, or is it part of your series going somewhere else?
>
>
> It turned out it doesn't really work to have a generic series against 20
> trees :-/
I know that pain very well!
> I'm submitting them individually to each subsystem.
> So this one is just for security.
Sounds good.
James, can you take this directly, or would you prefer a pull request from me?
-Kees
--
Kees Cook
Pixel Security
On Wed, 5 Sep 2018, Kees Cook wrote:
> On Wed, Sep 5, 2018 at 3:49 PM, Igor Stoppa <[email protected]> wrote:
> >
> >
> > On 06/09/18 01:23, Kees Cook wrote:
> >
> >> Should I take this, or is it part of your series going somewhere else?
> >
> >
> > It turned out it doesn't really work to have a generic series against 20
> > trees :-/
>
> I know that pain very well!
>
> > I'm submitting them individually to each subsystem.
> > So this one is just for security.
>
> Sounds good.
>
> James, can you take this directly, or would you prefer a pull request from me?
I'll take it with your ack.
--
James Morris
<[email protected]>
On Wed, Sep 5, 2018 at 5:08 PM, James Morris <[email protected]> wrote:
> On Wed, 5 Sep 2018, Kees Cook wrote:
>
>> On Wed, Sep 5, 2018 at 3:49 PM, Igor Stoppa <[email protected]> wrote:
>> >
>> >
>> > On 06/09/18 01:23, Kees Cook wrote:
>> >
>> >> Should I take this, or is it part of your series going somewhere else?
>> >
>> >
>> > It turned out it doesn't really work to have a generic series against 20
>> > trees :-/
>>
>> I know that pain very well!
>>
>> > I'm submitting them individually to each subsystem.
>> > So this one is just for security.
>>
>> Sounds good.
>>
>> James, can you take this directly, or would you prefer a pull request from me?
>
> I'll take it with your ack.
Already included! :) (This was a v2, split from a separate series, so
Igor already included my Ack from the other thread.)
But, for completeness:
Acked-by: Kees Cook <[email protected]>
-Kees
--
Kees Cook
Pixel Security
On Wed, 5 Sep 2018, Igor Stoppa wrote:
> WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
> into another.
>
> Signed-off-by: Igor Stoppa <[email protected]>
> Acked-by: Kees Cook <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general
and next-testing.
Thanks!
--
James Morris
<[email protected]>