linux-kernel - Re: [PATCH] parport/ppdev: fix registration of sysctl entries

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]

Date:	Sun, 6 Jul 2008 09:11:26 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Marcin Slusarz <marcin.slusarz@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Frans Pop <elendil@...net.nl>
Subject: Re: [PATCH] parport/ppdev: fix registration of sysctl entries

On Sat, Jul 05, 2008 at 11:49:26PM -0700, Eric W. Biederman wrote:
> So our choices appear to be.
> - Change the name in sysctl so each parport device always has a unique name.
> - Only allow one opener of ppdev for a given port.

Can't do - it's a legitimate use of ppdev (several userland programs
multiplexing the sucker).

> - Take the approach of the initial patch and export to sysctl when we claim
>   the port and unexport when we release the port.

You do realize that we need exclusion around that lazy registration in
any case?  sysctl is not the only problem there...

> - Give up and simply don't register with sysctl for ppdev.
> 
> I did a quick google search and I could not find any hits (except for
> this bug report on devices/ppdev) so I am inclined just to special
> case ppdev and not even bother registering with sysctl.  I did not
> see any other fields that would have problems with a duplicate name.
> 
> The only other backwards compatible and viable approach appears
> to be registering ppdev parport devices when they are claimed.
> 
> The only reason we would be able to change the name without breakage
> is if no one uses the /proc interface in which case I don't see a
> point in continuing to provide it for ppdev.

Not quite.  /proc/sys/.../timeslice is a generically documented way to
tune the damn thing when we have several things on the same port.  Note
that while one of those might be in userland, the rest might be in kernel
and very different.  In this case the parameter is both relevant *and*
currently usable.

Frankly, I'd go for IDR and rename in cases when we have additional openers.
_And_ add a mutex around delayed allocation - that's a separate problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/