linux-kernel - Re: slow open() calls and o

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

Message-ID: <e7ca40f70706040720k48aae8efg7a4997ce1d6f2450@mail.gmail.com>
Date:	Mon, 4 Jun 2007 10:20:00 -0400
From:	"Aaron Wiebe" <epiphani@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: slow open() calls and o_nonblock

Replying to David Schwartz here.. (David, good to hear from you again
- haven't seen you around since the irc days :))

David Schwartz wrote:
>
> There is no way you can re-try the request. The open must either succeed or
> not return a handle. It is not like a 'read' operation that has an "I didn't
> do anything, and you can retry this request" option.
>
> If 'open' returns a file handle, you can't retry it (since it must succeed
> in order to do that, failure must not return a handle). If you 'open'
> doesn't return a file handle, you can't retry it (because, without a handle,
> there is no way to associate a future request with this one, if it creates a
> file, the file must not be created if you don't call 'open' again).

I understand, but this is exactly the situation that I'm complaining
about.  There is no functionality to provide a nonblocking open - no
ability to come back around and retry a given open call.

> You need either threads or a working asynchronous system call interface.
> Short of that, you need your own NFS client code.

This is exactly my point - there is no asynchronous system call to do
this work, to my knowledge.  I will likely fix this in my own code
using threads, but I see using threads in this case as working around
that lack of systems interface.  Threads, imho, should be limited to
cases where I'm using them to distribute load across multiple
processors, not because the kernel interfaces for IO cannot support
nonblocking calls.

I'm speaking to my ideal world view - but any application I write
should not have to wait for the kernel if I don't want it to.   I
should be able to submit my request, and come back to it later as I so
decide.

(And I did actually consider writing my own NFS client for about 5 minutes.)

Thanks for the response!
-Aaron
-
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/