CHROMIUM: qcusbnet: fix devqmi_close() races.

CHROMIUM: qcusbnet: fix devqmi_close() races.

Originally, devqmi_close() was attached to the flush hook (instead of the
release hook), meaning it would be called whenever a userspace task called
close() (instead of just when the last ref to the file was dropped), which
necessitated the task-list-walking song and dance. Instead, add a new ioctl
which userspace can use to tear down the QMI connection and remove the refcount
check stuff.

This fixes a whole raft of nasty races in devqmi_close().

Note that it is not required that userspace use the ioctl; if it doesn't
(because, for example, it crashes), we'll still clean up any dangling QMI
contexts at release time.

BUG=chromium-os:10360
TEST=Adhoc
Reproducing the bug this fixes (see 10360) is almost impossible. :(

Change-Id: Ic64f64d89757f2ad95d2df9e8da04ddda3209bda
Signed-off-by: Elly Jones <ellyjones@chromium.org>;
Signed-off-by: Jason Glasgow <jglasgow@chromium.org>;
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>;

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=4b00239

[Jason Glasgow, 2011-03-15 17:20:06]

LGTM after discussion, but requires kernel expert review too.

[Mandeep Singh Baines, 2011-03-15 20:56:31]

Nice cleanup. A few questions about the ioctl.

http://codereview.chromium.org/6694028/diff/3001/drivers/net/usb/gobi/qmidevi...
File drivers/net/usb/gobi/qmidevice.c (right):

http://codereview.chromium.org/6694028/diff/3001/drivers/net/usb/gobi/qmidevi...
drivers/net/usb/gobi/qmidevice.c:1022: */
I've read the comment but I'm still not getting the Use Case for this ioctl. Why
do you need kernel support to remove all refs? Can't you just send a signal to
any processes blocked on read. What is the requirement leading to this ioctl.

[Mandeep Singh Baines, 2011-03-15 21:47:44]

Discussed over chat.

LGTM