[EMAIL PROTECTED] (H. Peter Anvin) wrote on 02.12.00 in
<90cs2v$6u6$[EMAIL PROTECTED]>:
> Again, that's wrong even when you replace /dev/random with something
> else. After all, you could be getting EINTR at any time, too, or get
> interrupted by a signal in the middle (in which case you'd get
> This is standard stuff... You are really pissing into the wind here ;)
Guess I am. Still isn't an explaination why I see a lot of broken code out
there regarding this issue.
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Igmar Palsenberg wrote:
> > This is standard stuff... You are really pissing into the wind here ;)
>
> Guess I am. Still isn't an explaination why I see a lot of broken code out
> there regarding this issue.
>
> Igmar
Broken code due to broken programmers.
-d
begin:vcard
n:Ford;Dav
On Sun, 3 Dec 2000, Igmar Palsenberg wrote:
> > Any programmer who has evolved sufficiently from a scriptie should take
> > necessary precautions to check how much data was transferred. Those who
> > don't..well, there is still tomorrow.
> >
> > There is no reason to add any additional documenta
> Well, that's the Unix interface you. I you don't like it, why don't you
> become a Windows programmer and try your hand at the Win32 interface? :-)
>
> Seriously, doing something different for /dev/random compared to all
> other read(2) calls is a bad idea; it will get people confused. The
> > Making /dev/random block if the amount requirements aren't met makes sense
> > to me. If I request x bytes of random stuff, and get less, I probably
> > reread /dev/random. If it's entropy pool is exhausted it makes sense to be
> > to block.
>
> This is the job of the program accessing /dev/
> > I know. Still leaves lot's of people that assume that reading /dev/random
> > will return data, or will block.
> >
> > I've seen lots of programs that will assume that if we request x bytes
> > from /dev/random it will return x bytes.
>
> I find this really humorous honestly. I see a lot of
Alexander Viro wrote:
>
> Erm... Not that ignoring the return values was a bright idea, but the
> lack of reliable ordered datagram protocol in IP family is not a good
> thing. It can be implemented over TCP, but it's a big overkill. IL is a
> nice thing to have...
Pet peeve? There are about fi
H. Peter Anvin writes:
>> Yeah, people write annoying little wrapper functions that
>> bounce right back into the kernel until the job gets done.
>> This is slow, it adds both source and object bloat, and it
>> is a source of extra bugs. What a lovely API, eh?
>>
>> The fix: write_write_write_dam
Followup to: <[EMAIL PROTECTED]>
By author:Igmar Palsenberg <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Hmm.. Some came to mind :
>
> Making /dev/random block if the amount requirements aren't met makes sense
> to me. If I request x bytes of random stuff, and get less, I probably
Followup to: <[EMAIL PROTECTED]>
By author:"Albert D. Cahalan" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Yeah, people write annoying little wrapper functions that
> bounce right back into the kernel until the job gets done.
> This is slow, it adds both source and object bloat, a
Followup to: <[EMAIL PROTECTED]>
By author:Igmar Palsenberg <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > For a blocking fd, read(2) has always blocked until some data is
> > available. There has never been a guarantee, for any driver, that
> > a read(2) will return the full amou
Followup to: <[EMAIL PROTECTED]>
By author:Igmar Palsenberg <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > Indeed, you are correct. Is vpnd broken then, for assuming
> > that it can gather the required randomness in one read?
>
> Yep. It assumes that if the required randommness nu
Date: Sat, 2 Dec 2000 18:34:44 -0500 (EST)
From: Alexander Viro <[EMAIL PROTECTED]>
Erm... Not that ignoring the return values was a bright idea, but the
lack of reliable ordered datagram protocol in IP family is not a good
thing. It can be implemented over TCP, but it's a big over
On Sat, 2 Dec 2000, Theodore Y. Ts'o wrote:
> particularly people who writing network programs. The number of people
> who assume that they can get an entire (variable-length) RPC packet by
> doing a single read() call astounds me. TCP doesn't provide message
> boundaries, never did and never
From: "Albert D. Cahalan" <[EMAIL PROTECTED]>
Date:Sat, 2 Dec 2000 17:00:32 -0500 (EST)
> Any programmer who has evolved sufficiently from a scriptie
> should take necessary precautions to check how much data was
> transferred. Those who don't..well, there is still tomorro
David Ford writes:
> Igmar Palsenberg wrote:
>> I've seen lots of programs that will assume that if we request x bytes
>> from /dev/random it will return x bytes.
>
> I find this really humorous honestly. I see a lot of people
> assuming that if you write N bytes or read N bytes that you will
>
> Making /dev/random block if the amount requirements aren't met makes sense
> to me. If I request x bytes of random stuff, and get less, I probably
> reread /dev/random. If it's entropy pool is exhausted it makes sense to be
> to block.
This is the job of the program accessing /dev/random. Open
Igmar Palsenberg wrote:
> > For a blocking fd, read(2) has always blocked until some data is
> > available. There has never been a guarantee, for any driver, that
> > a read(2) will return the full amount of bytes requested.
>
> I know. Still leaves lot's of people that assume that reading /dev/
> "totally block"?
>
> For a blocking fd, read(2) has always blocked until some data is
> available. There has never been a guarantee, for any driver, that
> a read(2) will return the full amount of bytes requested.
Hmm.. Some came to mind :
Making /dev/random block if the amount requirements
> For a blocking fd, read(2) has always blocked until some data is
> available. There has never been a guarantee, for any driver, that
> a read(2) will return the full amount of bytes requested.
I know. Still leaves lot's of people that assume that reading /dev/random
will return data, or will
On Sat, 2 Dec 2000, Igmar Palsenberg wrote:
> > Indeed, you are correct. Is vpnd broken then, for assuming
> > that it can gather the required randomness in one read?
>
> Yep. It assumes that if the required randommness numbers aren't met a read
> to /dev/random will block.
>
> And it's not the
> Indeed, you are correct. Is vpnd broken then, for assuming
> that it can gather the required randomness in one read?
Yep. It assumes that if the required randommness numbers aren't met a read
to /dev/random will block.
And it's not the only program that assumes this : I also did.
/dev/rand
On 1 Dec 2000, H. Peter Anvin wrote:
> > open("/dev/random", O_RDONLY) = 3
> > read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29
> > close(3)= 0
> >
> > Have the semantics of the device changed, or is vpnd doing
> > something w
On Fri, 1 Dec 2000 [EMAIL PROTECTED] wrote:
> > open("/dev/random", O_RDONLY) = 3
> > read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29
> > close(3)= 0
> I've seen that happen with kernel version 2.2.16!
Indeed, you are corre
Followup to: <[EMAIL PROTECTED]>
By author:Matthew Kirkwood <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Hi,
>
> It looks like the random driver in 2.4test will return a
> short read, rather than blocking. This is breaking vpnd
> (http://sunsite.dk/vpnd/) which breaks with "failed
I've seen that happen with kernel version 2.2.16!
> Hi,
>
> It looks like the random driver in 2.4test will return a
> short read, rather than blocking. This is breaking vpnd
> (http://sunsite.dk/vpnd/) which breaks with "failed to
> gather random data" or similar.
>
> Here's a sample strace:
Hi,
It looks like the random driver in 2.4test will return a
short read, rather than blocking. This is breaking vpnd
(http://sunsite.dk/vpnd/) which breaks with "failed to
gather random data" or similar.
Here's a sample strace:
open("/dev/random", O_RDONLY) = 3
read(3, "q\321Nu\204\2
28 matches
Mail list logo
