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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160802143537.GT15995@brightrain.aerifal.cx>
Date:	Tue, 2 Aug 2016 10:35:37 -0400
From:	Rich Felker <dalias@...c.org>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Baole Ni <baolex.ni@...el.com>, cmetcalf@...lanox.com,
	schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
	linux-kernel@...r.kernel.org, viresh.kumar@...aro.org,
	chuansheng.liu@...el.com
Subject: Re: [PATCH 0029/1285] Replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 02:16:17PM +0200, Greg KH wrote:
> On Tue, Aug 02, 2016 at 06:35:37PM +0800, Baole Ni wrote:
> > I find that the developers often just specified the numeric value
> > when calling a macro which is defined with a parameter for access permission.
> > As we know, these numeric value for access permission have had the corresponding macro,
> > and that using macro can improve the robustness and readability of the code,
> > thus, I suggest replacing the numeric parameter with the macro.
> > 
> > Signed-off-by: Chuansheng Liu <chuansheng.liu@...el.com>
> > Signed-off-by: Baole Ni <baolex.ni@...el.com>
> > ---
> >  arch/tile/kernel/sysfs.c | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c
> > index 825867c..cef3937 100644
> > --- a/arch/tile/kernel/sysfs.c
> > +++ b/arch/tile/kernel/sysfs.c
> > @@ -38,7 +38,7 @@ static ssize_t chip_width_show(struct device *dev,
> >  {
> >  	return sprintf(page, "%u\n", smp_width);
> >  }
> > -static DEVICE_ATTR(chip_width, 0444, chip_width_show, NULL);
> > +static DEVICE_ATTR(chip_width, S_IRUSR | S_IRGRP | S_IROTH, chip_width_show, NULL);
> 
> You do know about S_IRUGO, right?  Why not use that?
> 
> Same goes for your other replacements, use the correct #define, not a
> mix of values | together.
> 
> And you are sending hundreds of patches with the same identical subject
> line, that's not ok, you need to make it unique for every patch.
> Usually that is done with the subsystem and driver name, see examples of
> this in the kernel changelogs.
> 
> Please fix up and try again, in a much smaller series, before trying to
> do this across the whole kernel tree.
> 
> good luck!

While I won't object to the parts I'm maintainer for if there's a
general consensus this is an improvement, I don't think it's an
improvement, even with S_IRUGO. It's a significant decrease in
readability. Everybody who works on this code knows immediately and
intuitively what 0444 means. I have to actually stop and think about
what S_IRUGO means.

>From my perspective, these macros were a mistake from a time when
standardization efforts wrongly thought of file permission mode values
as "not a public interface". POSIX since corrected that (in the 2008
edition, from what I can tell); the specific values everybody expects
are mandated.

Rich

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ