linux-kernel - Re: [PATCH] fix pktcdvd breakage from commit e105b8bfc769b0545b6f0f395179d1e43cbee822

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: <20081130132118.GY28946@ZenIV.linux.org.uk>
Date:	Sun, 30 Nov 2008 13:21:18 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>, gregkh@...e.de,
	petero2@...ia.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fix pktcdvd breakage from commit
	e105b8bfc769b0545b6f0f395179d1e43cbee822

On Sun, Nov 30, 2008 at 01:41:29PM +0100, Kay Sievers wrote:

> I posted a fix for that weeks ago. But the pktcdvd maintainer stated,
> that the char device nodes are not used for anything. So the whole use
> of dev_t should be removed entirely. They just blindly claim the same
> char dev_t the block devices use, and conflict with char devices from
> other subsystems. Patching out the /sys/dev/class links fixes the
> oops, but the underlying fundamental breakage will still exist.
> 
> Original mail here states:
> "Maybe, but that character device would not be used for anything,
> besides creating sub-directories in /sys/class/pktcdvd. The driver
> implements a block device, not a character device."

_What_ character device nodes?  The only thing that dev_t value used to
be used for was giving contents for a text file - ..../dev in sysfs directory.  
With introduction of /sys/dev/char the damn thing got confused for
character device number *by* *device_create()*.  That's all.

There are no character device nodes at all.  Driver doesn't claim them.
Not in that call of device_create(), not anywhere else.  sysfs doesn't
create them (or any other device nodes).  If you mknod such thing as
char device and try to open it, the kernel won't go anywhere near this driver,
whether there'd been other drivers or not. 

So what kind of fundamental breakage are you talking about?  All I can see
here is a bogus entry added to bogu^Wmisguided^W /sys/dev/char, which leads
to WARN_ON() in case if somebody had char device with device number numerically
equal to that of our block device and to silent crapping into /sys/dev/char
if no such char device had been there already.
--
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/