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, 30 Nov 2008 14:25:43 +0100
From:	"Kay Sievers" <kay.sievers@...y.org>
To:	"Al Viro" <viro@...iv.linux.org.uk>
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 14:21, Al Viro <viro@...iv.linux.org.uk> wrote:
> 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

Pktcdvd creates char _and_ block device nodes at the same time, while
the char nodes are not allocated, but created and conflict in
/sys/dev/ with properly allocated ones from other subsystems. Your
patch just papers over this bug.

Kay
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ