netdev - Re: r8169: is the work queue is initialized at wrong place?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 19 Jul 2013 11:23:46 +0200
From:	Peter Wu <lekensteyn@...il.com>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	netdev@...r.kernel.org,
	Realtek linux nic maintainers <nic_swsd@...ltek.com>
Subject: Re: r8169: is the work queue is initialized at wrong place?

On Friday 19 July 2013 08:10:17 Francois Romieu wrote:
> Peter Wu <lekensteyn@...il.com> :
> > On Thursday 18 July 2013 23:53:43 Francois Romieu wrote:
> [...]
> 
> > > (or cancel_work_sync in rtl8169_close to reduce the scope)
> > 
> > Will this also work with multiple adapters? I currently have an on-board
> > chip using the r8169 driver and a separate PCI card.
> 
> As stated by David, yes.
Thanks for confirming.

> > > I do not see how the current code could hurt but it's really ugly.
> > 
> > When I googled for the warning, I found some hint about something not
> > being
> > initialized. From that I guessed that rtl_open is never called when the
> > network interface is not brought up (which seems to match the
> > documentation of struct net_device_ops[1]).
> 
> You guessed right. Please note that the relevant struct is zeroed during
> initialization (see net/core/dev.c::alloc_netdev_mqs). While it's true
> that the struct is not initialized for use by the device, cancel_work_sync
> will cope with it (bail out thanks to a 0 bitflag).
> 
> You can ignore the warning and proceed with the driver as-is.
Well, the driver appears to work, but due to this I also miss future lockdep 
warnings until I reboot.

> I'll fix it anyway. It's too ugly to be kept as is.
> 
> Side-note: if you can publish your eeprom reading code, it would be
> interesting to know how it differs from what has already been tried
> in the past.
I will certainly do this. Right not I am leveraging the existing 93cx6 driver 
in the kernel. I am having difficulties with making the reads reliable though, 
only after writing at least once to the EEPROM (which is logged as timeout, 
although the word is written), I am able to read it. Otherwise, I will only 
read 00s. This is on an external RTL8169SB Gbe PCI card (on the chip itself, I 
can read RTL8169SC though). (bought for 10$ on Ebay :P).

Initially, this chip could not detect a link (it reported itself with PCI 
VID:PID 10ec:8129), probably due to a bad driver that overwrote part of the 
EEPROM (maybe this one[1]?). After writing the EEPROM signature (29 81) (and 
making the card load from EEPROM by writing 0x40 to register 0x50)), the card 
MAC version does not get recognized and is detected as generic "RTL8169" 
(unbind/bind). After a reboot, the card got detected "properly" 
RTL8169sb/8110sb ("properly", because I really see "RTL8169SC" on the 
chip...).

On another onboard RTL8111E chip, I only read FFs. I haven't tried writing to 
that one as it is working perfectly.

Regards,
Peter

 [1]: http://www.gossamer-threads.com/lists/linux/kernel/990061
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html