linux-kernel - Re: pktcdvd -> sysfs warning with 2.6.27

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:	Tue, 14 Oct 2008 07:27:07 +0200
From:	Peter Osterlund <petero2@...ia.com>
To:	Greg KH <greg@...ah.com>
Cc:	Nix <nix@...eri.org.uk>, linux-kernel@...r.kernel.org,
	a.zummo@...ertech.it
Subject: Re: pktcdvd -> sysfs warning with 2.6.27

Greg KH <greg@...ah.com> writes:

> On Mon, Oct 13, 2008 at 10:28:13PM +0100, Nix wrote:
>> On 12 Oct 2008, Greg KH uttered the following:
>> > Perhaps some other kernel code is registering with that same major/minor
>> > number, making it already present in sysfs.  Where does that sysfs file
>> > link to before you load your driver?
>> 
>> Exactly so. This is probably *not* a regression after all: the only
>> change I made to my 2.6.27 config (weeks before actually rebooting, so I
>> forgot) was to build in the CMOS RTC driver, in a hopeless attempt to
>> make hrtimers work on this old hardware (I knew it was hopeless but
>> tried anyway). (Unsurprisingly it didn't work:
>> <http://www.ussg.iu.edu/hypermail/linux/kernel/0810.1/1033.html> worked,
>> thank *you* Jeff, I have glitch-free pulseaudio and microsecond sleeps
>> and several of my programs are happier!)
>> 
>> And, looky here, a smoking gun:
>> 
>> hades:~# ls -l /sys/dev/char/254:0 /dev/rtc*
>> lrwxrwxrwx 1 root root 0 2008-10-13 22:16 /sys/dev/char/254:0 -> ../../devices/platform/rtc_cmos/rtc/rtc0
>> hades:~# ls -l 
>> lrwxrwxrwx 1 root root      4 2008-10-13 21:57 /dev/rtc -> rtc0
>> crw-r--r-- 1 root root 254, 0 2008-10-13 21:57 /dev/rtc0
>> 
>> hades:~# pktsetup cdrw /dev/cdrw
>> hades:~# ls -l /dev/pktcdvd/
>> total 0
>> brw-r----- 1 root root  254,  0 2008-10-13 22:23 cdrw
>> crw-r--r-- 1 root root   10, 63 2008-10-13 21:57 control
>> brw-rw---- 1 root cdrom 254,  0 2008-10-13 22:23 pktcdvd0
>> 
>> Am I right in assuming that this sort of isn't going to work? :)
>
> Yes, you are right :)

I don't think so. One is a character device and the other is a block
device. Block devices didn't use to collide with character devices.
Has that changed recently?

>> Major 254 is listed as LOCAL/EXPERIMENTAL USE in devices.txt. I don't
>> consider either pktcdvd or the rtc drivers as LOCAL/EXPERIMENTAL: the
>> former in particular has been in the kernel for years.
>
> Both of those should get "real" majors assigned to them.  It's not ok to
> randomly go grabbing major:minor numbers like this for code that is in
> mainline.

It's not about random grabbing. It's about getting a dynamically
assigned number. The pktcdvd driver once had static numbers, but at
the time when the driver was merged into the mainline kernel, dynamic
numbers were considered better. Therefore I changed the driver to use
dynamic numbers.

-- 
Peter Osterlund - petero2@...ia.com
http://web.telia.com/~u89404340
--
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/