lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <60a148d7c63510cbf31f3517dcb097c77d4ecd7c.camel@ozlabs.org>
Date:   Fri, 02 Jul 2021 09:19:27 +0800
From:   Jeremy Kerr <jk@...abs.org>
To:     Jason Wang <wangborong@...rlc.com>
Cc:     arnd@...db.de, mpe@...erman.id.au, benh@...nel.crashing.org,
        paulus@...ba.org, linuxppc-dev@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] sched: Use BUG_ON

Hi Jason,

> The BUG_ON macro simplifies the if condition followed by BUG, so that
> we can use BUG_ON instead of if condition followed by BUG.

[...]

> -       if (spu_acquire(ctx))
> -               BUG();  /* a kernel thread never has signals pending */
> +       /* a kernel thread never has signals pending */
> +       BUG_ON(spu_acquire(ctx));

I'm not convinced that this is an improvement; you've combined the
acquire and the BUG into a single statement, and now it's no longer
clear what the comment applies to.

If you really wanted to use BUG_ON, something like this would be more
clear:

	rc = spu_acquire(ctx);
	/* a kernel thread never has signals pending */
	BUG_ON(rc);

but we don't have a suitable rc variable handy, so we'd need one of
those declared too. You could avoid that with:

	if (spu_acquire(ctx))
		BUG_ON(1); /* a kernel thread never has signals pending */

but wait: no need for the constant there, so this would be better:

	if (spu_acquire(ctx))
		BUG(); /* a kernel thread never has signals pending */

wait, what are we doing again?

To me, this is a bit of shuffling code around, for no real benefit.

Regards,


Jeremy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ