linux-kernel - Out of tree serial tty driver?

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>] [day] [month] [year] [list]
Date:	Tue, 23 Apr 2013 14:38:42 -0400
From:	Mark Hounschell <markh@...pro.net>
To:	linux-kernel@...r.kernel.org
CC:	Mark Hounschell <dmarkh@....rr.com>
Subject: Out of tree serial tty driver?

I've been maintaining a couple of Digi International serial port card 
(XP and AP) drivers for years now because, well, they just won't do it 
anymore. In any case, I'm moving from a 3.4.x kernel, that works just 
fine, to a 3.8.8 kernel, that does not. I have code that does something 
like this:

	tty_set_operations(&SerialDriver, &SerialOps);
	tty_register_driver(&SerialDriver);
	maxminor = NumBoards * 64;
	for (i = 0; i < maxminor; i++)
		tty_register_device(&SerialDriver, i, NULL);

The first call to tty_register_device barfs:

[   76.528626] BUG: unable to handle kernel NULL pointer dereference at 
   (null)
[   76.528628] IP: [<c02fa460>] cdev_init+0x30/0x90
[   76.528632] *pde = 00000000
[   76.528634] Oops: 0002 [#1] PREEMPT SMP
[   76.528636] Modules linked in: kvm snd_hda_codec_realtek 
snd_hda_intel snd_hda_codec snd_hwdep snd_pcm nvidia(PO) osst snd_seq 
dgdm(O+) snd_timer snd_seq_device eprm(O) st sr_mod sg synclink_gt snd 
crc32c_intel aesni_intel ablk_helper cryptd lrw gpiohsd(O) k10temp 
lcrsmem(O) hdlc aes_i586 3c59x firewire_ohci pcspkr xts gf128mul mxm_wmi 
shpchp soundcore i2c_piix4 firewire_core snd_page_alloc crc_itu_t cdrom 
wmi pci_hotplug r8169 fam15h_power microcode rtom(O) button edd autofs4 
ext4 jbd2 crc16 xhci_hcd scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua 
scsi_dh_rdac scsi_dh ata_generic pata_atiixp aic7xxx aic79xx 
scsi_transport_spi
[   76.528661] Pid: 393, comm: systemd-udevd Tainted: P           O 
3.8.8-lcrs #8 Gigabyte Technology Co., Ltd. GA-990FXA-UD5/GA-990FXA-UD5
[   76.528662] EIP: 0060:[<c02fa460>] EFLAGS: 00010246 CPU: 4
[   76.528664] EIP is at cdev_init+0x30/0x90
[   76.528665] EAX: 00000000 EBX: 00000000 ECX: 0000000f EDX: 0000003c
[   76.528667] ESI: c06d38c0 EDI: 00000000 EBP: ed449d0c ESP: ed449d00
[   76.528668]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   76.528669] CR0: 8005003b CR2: f72f9920 CR3: 2ebc8000 CR4: 000407d0
[   76.528670] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[   76.528672] DR6: ffff0ff0 DR7: 00000400
[   76.528673] Process systemd-udevd (pid: 393, ti=ed448000 
task=ee753240 task.ti=ed448000)
[   76.528674] Stack:
[   76.528675]  fb396220 00000000 04600000 ed449d30 c04780a6 c0826710 
0000003c 00000000
[   76.528678]  00000000 fb396220 00000000 04600000 ed449dac c0478d52 
00000001 ed449d60
[   76.528681]  00000000 00000002 00000000 04600000 00000730 ed449d60 
00000000 00000000
[   76.528684] Call Trace:
[   76.528688]  [<c04780a6>] tty_cdev_add+0x56/0x80
[   76.528690]  [<c0478d52>] tty_register_device_attr+0x192/0x220
[   76.528693]  [<c02fa96d>] ? register_chrdev_region+0x4d/0xa0
[   76.528695]  [<c0478dfa>] tty_register_device+0x1a/0x20
[   76.528702]  [<fb37e701>] dgdm_tty_init+0x601/0x660 [dgdm]
[   76.528707]  [<fb375818>] init_module+0x2008/0x22f0 [dgdm]
[   76.528711]  [<c069d843>] ? notifier_call_chain+0x43/0x60
[   76.528716]  [<fb373810>] ? dgdm_boardread+0x430/0x430 [dgdm]
[   76.528718]  [<c0201222>] do_one_initcall+0x112/0x160
[   76.528721]  [<c0252707>] ? __blocking_notifier_call_chain+0x47/0x60
[   76.528723]  [<c02849d8>] load_module+0x1c58/0x2280
[   76.528729]  [<c028508d>] sys_init_module+0x8d/0xf0
[   76.528734]  [<c069ad1d>] syscall_call+0x7/0xb
[   76.528735] Code: 0c a8 01 89 5d f4 89 c3 89 75 f8 89 d6 ba 3c 00 00 
00 89 7d fc 89 c7 75 52 f7 c7 02 00 00 00 75 5a 89 d1 31 c0 c1 e9 02 f6 
c2 02 <f3> ab 74 08 66 c7 07 00 00 83 c7 02 83 e2 01 74 03 c6 07 00 8d
[   76.528753] EIP: [<c02fa460>] cdev_init+0x30/0x90 SS:ESP 0068:ed449d00
[   76.528756] CR2: 0000000000000000
[   76.528758] ---[ end trace 99a84df60dc687d6 ]---


I've put a printk in tty_io.c that shows the NULL pointer in 
driver->cdevs, that I assume. is what is causing it to barf. The first 4 
below are from Synclink-GT driver. The last is mine.

tty_cdev_add: Entered. driver = 0xeebd9900 driver->cdevs = 0xe678b800 
index = 0 name = ttySLG0
tty_cdev_add: Entered. driver = 0xeebd9900 driver->cdevs = 0xe678b800 
index = 1 name = ttySLG1
tty_cdev_add: Entered. driver = 0xeebd9900 driver->cdevs = 0xe678b800 
index = 2 name = ttySLG2
tty_cdev_add: Entered. driver = 0xeebd9900 driver->cdevs = 0xe678b800 
index = 3 name = ttySLG3
tty_cdev_add: Entered. driver = 0xf6d723a0 driver->cdevs = 0x00000000 
index = 0 name = tty_dgdm_G0

Was it expected that the tty changes from 3.4 to 3.8 would cause out of 
kernel drivers to fail? I've tried adding cdev_alloc and cdev_init but 
things seem to get much worse when I do.

I do maintain all of our GPL kernel drivers but do NOT consider my self 
very knowledgeable in the area of the kernel.  Any tips or pointers 
would be appreciated.

Thanks in advance
Mark
--
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/