linux-kernel - RE: SELECT() returns 1 But FIONREAD says (Input/output error)

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]

Message-ID: <MDEHLPKNGKAHNMBLJOLKCENHEDAC.davids@webmaster.com>
Date:	Thu, 31 May 2007 18:01:31 -0700
From:	"David Schwartz" <davids@...master.com>
To:	<linux-kernel@...r.kernel.org>
Subject: RE: SELECT() returns 1 But FIONREAD says (Input/output error)

> i am using the GARMIN_GPS/usb driver to read a gps receiver.
> In testing the ability of my software to recover from various errors, I
> try this: unplug the gps/USB cable from the usb hub.
>
> Interestingly enough the thread spins.
> the SELECT() waits for something to happen, and I get one channel that
> something interesting happened.
> Then i try to find out how many chars are in the read buff via FIONREAD.
> That call errors out with an i/o error.
>
> Needless to day, the code resets the SELECT parameters, and SELECT is
> called again. It again says that something interesting has happened on
> that ( i/o errored ) channel. And we now repeat the  FIONREAD.
>
> In this case what, will reset the "something interesting has happened"
> report from the SELECT call? Will it ever be reset in this case?

Nope. An errored connection is always ready for read/write -- there is
nothing to wait for as far as the kernel is concerned. Your code keeps
asking the kernel if something interesting has happened, the kernel keeps
telling it yes, and it refuses to do anything about it.

At minimum, a detection of an error condition that could be persistent
should be followed by a delay. A detection of an error condition that has in
fact persisted and was previously detected should *never* be followed by an
immediate return to 'select'.

You need to *handle* the I/O error. Backoff might be one way, sleeping for
an increasing amount of time after each fatal error, subject to some limit.

And why are you calling FIONREAD? Just 'read' the data -- you're going to
have to eventually anyway.

DS

-
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/