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: <BANLkTim1iVEU_+Y2CE90Qd3+LaVch2MVOg@mail.gmail.com>
Date:	Wed, 18 May 2011 16:21:10 -0700
From:	David Decotigny <decot@...gle.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Joe Perches <joe@...ches.com>,
	Szymon Janc <szymon@...c.net.pl>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel-net-upstream@...gle.com
Subject: Re: [PATCH 1/2] forcedeth: make module parameters readable in /sys/module

Hi Stephen,

On Wed, May 18, 2011 at 3:03 PM, Stephen Hemminger
<shemminger@...tta.com> wrote:
> Although this makes more info for developer, it also means more
> stuff in sysfs taking more memory and not providing any real value

Right. I'll drop this patch for now.

I do agree that this creates unnecessary pressure on some systems. But
on other systems, it is useful to know how all the loaded modules were
actually configured to track down something weird.

Regarding /sys/modules/X/parameters, the only knobs I know of are
CONFIG_SYSFS and the last argument to module_param(). If this is
correct, then it seems tricky to accommodate for both use cases above
without being crude (eg. disable sysfs, edit/sed the sources to change
last argument of module_param() macro, ...). Please correct me if I am
wrong. But if I am not, how about having a new knob allowing to
precisely control the presence/absence of /sys/module (another
CONFIG_*)? That way, the last argument to module_param() can be
interpreted as the permission when /sys/module is supported, and would
be ignored otherwise: module authors could gradually change their
perm=S_IRUGO and family without caring much about memory footprint.
And both use cases above could be supported without having to disable
sysfs altogether or change the sources.

I would be happy to work on this if it makes any sense.

Regards,
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ