netdev - open sockets preventing unregister_netdevice from completing in linux-next (next-20120724)

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-next>] [day] [month] [year] [list]

Message-ID: <87boj4hs3k.fsf@nemi.mork.no>
Date:	Wed, 25 Jul 2012 15:45:35 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	netdev@...r.kernel.org
Subject: open sockets preventing unregister_netdevice from completing in linux-next (next-20120724)

I am currently researching several power management regressions in
linux-next as of next-20120724, spread over the PCI, USB and net
subsystems. This one I believe belongs to the net subsystem, although I
definitely may be wrong, mixing these together.

My test case is:

- open a ssh connection over a USB network device (qmi_wwan - which is why
  I am looking at this, but I really don't think it's the driver this time)
- suspend laptop with netdev and ssh connection up
- attempt to resume

The USB device will be gone on resume because it is power cycled, so the
drivers need to clean up, to let the device be rediscovered and bound
again.  But this does not happen anymore in linux-next as long as some
socket is open.  Instead we have these messages:

 Jul 25 15:13:11 nemi kernel: [ 7704.560306] unregister_netdevice: waiting for wwan0 to become free. Usage count = 1
 Jul 25 15:13:21 nemi kernel: [ 7714.800308] unregister_netdevice: waiting for wwan0 to become free. Usage count = 1
 Jul 25 15:13:31 nemi kernel: [ 7725.040316] unregister_netdevice: waiting for wwan0 to become free. Usage count = 1

There are quite a few problems with the system in this state.  Any write
to the power/control associated with that USB device will hang,
presumably because the USB device does not exist anymore.  This will
also make new attempts to suspend fail.  And the USB device is of course
not functional.  The driver has not yet had a chance to clean up any of
the other devices associated with the dead USB device (wwan1,
/dev/cdc-wdm0 and /dev/cdc-wdm1), so these ghost devices will appear as
non- functional.  And new devices cannot be registered until the
previous USB device is deleted and a new one created.

Killing the ssh session let the unregister_netdevice continue and
everything will be cleaned up and go back to normal.

This is a regression compared to 3.5, where unregister_netdevice would
succeed regardless of any open sockets. Or maybe the sockets were
auto-reaped?  I don't know the inner details - just observing the
results.

The test case above is quite normal operational mode for me.  I often
leave open sessions while suspending (because I intend to continue using
them after resuming).  And I always forget that this won't work for the
USB modem case.  I don't really care either.  I expect the netdev to be
removed, routes deleted and any sockets referencing either should just
die or live on as zombies or whatever.  The important part is that they
should not prevent deletion of a netdev when e.g. the physical device is
gone. That's the way things used to work.

Bjørn
--
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