On Thu, 17 May 2001, Alan Cox wrote:
> > The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> > Since the other end is clearly gone, I would expect some sort of error
> > condition. Indeed, FreeBSD gives ECONNRESET.
>
> Since its a datagram socket Im not convinced thats a
Hi,
I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
behaviour, which gives the behaviour I would expect.
The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
Since the other end is clearly gone, I would expect some sort of error
condition. Indeed,
Resend (no response first time)
-- Forwarded message --
Date: Wed, 24 Jan 2001 21:09:09 + (GMT)
From: Chris Evans <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: 2.2, 2.4 bug in sock_no_fcntl()/F_SETOWN?
Hi,
Looking at the code for sock_no
On Thu, 17 May 2001, Alan Cox wrote:
> 2.4.4-ac10
[...]
> - now 2.4.5pre vm seems sane dump other vmscan
> experiments
Has anyone benched 2.4.5pre3 vs 2.4.4 vs. ?
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
On Wed, 9 May 2001, Alan Cox wrote:
> > significant problems with lockmeter. csum_partial_copy_generic was the
> > highest % in profile, at 4.34%. I'll see if we can get some space on
>
> Are you using Antons optimisations to samba to use sendfile ?
And you might like to try 2.4.4 (I saw 2.4.
On Wed, 18 Apr 2001, Russell King wrote:
> > Now, providing the malicious user passes a low user space pointer (e.g.
> > just above 0), the kernel's virtual address space wrap check will not
> > trigger because ~0 + ~2Gb does not exceed 4G. And the result is the user
> > being able to read kerne
On Wed, 18 Apr 2001, David Schleef wrote:
> On Tue, Apr 17, 2001 at 09:39:15PM -0700, Dawson Engler wrote:
> > Hi All,
> >
> > at the suggestion of Chris ([EMAIL PROTECTED]) I wrote a simple
> > checker to warn when the length parameter to copy_*_user was (1) an
> > integer and (2) not checked <
Hi Dawson,
Excellent project.
Can I suggest that you check for signedness issues? A typical signature of
a signedness problem is:
int i = get_from_userspace_somehow();
/* Sanity check i */
if (i > MAX_LEN_FOR_I)
goto bad_bad_out;
/* Bug here!! i can be negative! */
I suspect you find a lot
[cc: security-audit, because it's interesting :-)]
On Sun, 18 Mar 2001, Topi Miettinen wrote:
> (Please cc: me, I'm not subscribed.)
>
> Using the magical prctl() call it's possible to run daemons as non-root
> while still possessing some capabilities. For full support, patched kernel
> with ex
On Tue, 13 Mar 2001, Manfred Spraul wrote:
> * bugfixes for get_pid(). This is the longest part of the patch, but
> it's only necessary if you have more than 10.000 threads running. If you
> have enough memory: launch a forkbomb. If ~ 32760 thread are running the
> kernel enters an endless loop
On Thu, 1 Mar 2001, Rik van Riel wrote:
> True. I think we want something in-between our ideas...
^^^
> a while. This should make it possible for the disk reads to
^^
Oh dear.. not more "vm design by waving hands in the air". Come on people,
improve the vm by car
On Wed, 21 Feb 2001, Rik van Riel wrote:
> I'm really interested in things which make Linux 2.4 break
> performance-wise since I'd like to have them fixed before the
> distributions start shipping 2.4 as default.
Hi Rik,
With kernel 2.4.1, I found that caching is way too aggressive. I was
runn
On Mon, 19 Feb 2001 [EMAIL PROTECTED] wrote:
> Wakeup does not happen until _enough_ (1/3 of snbuf) of space in sndbuf
> is released, otherwise you will overschedule. So, as soon as
> write() goes to sleep, it will sleep waiting until 1/3 is released.
Of course. Thank you.
> If it is interrupt
On Mon, 19 Feb 2001, Chris Evans wrote:
> > BTW, if you have enough fast network, you probably can observe
> > that sendfile() is even not interrupted by signals. 8) But this
> > is possible to fix at least. BTW the same fix will repair SO_*TIMEO
> > partially, i.e.
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
>
> None of the options apply to sendfile(). It is not socket level
> operation. You have to use alarm for it.
>
> BTW, if you have enough fast network, you probably can obs
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > So the actual timeout would be 2 * SO_SNDTIMEO.
>
> It will timeout if write of some page blocks for SO_SNDTIMEO.
.. unless that page was partially written, in which case a short write
count is returned (rather than a timeout error), a
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
>
> None of the options apply to sendfile(). It is not socket level
> operation. You have to use alarm for it.
Hi Alexey,
Actually sendfile() _does_ timeout using SO_SNDTI
Hi,
By the way - I tested SO_RCVLOWAT, another 2.4 addition. Good news this
time - seems to work fine.
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-i
Hi Alexey,
This patch fixes my simple read()/write() tests, nice one. The behaviour
also now matches BSD (someone kindly donated me a FreeBSD shell for
testing).
Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
- Connect an AF_INET, SOCK_STREAM socket to a local listening socket.
Alexey,
Damn you are quick! :) Testing immediately
Cheers
Chris
On Sat, 17 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > Unfortunately, it seems to be very buggy. Here are two buggy scenarios.
>
>
> --- ../vger3-010210/linux/net/ipv4/tcp.c Sat Feb 10 23:16:51 2001
> +++ linux/net/ipv4
Hi,
I was glad to see Linux gain SO_SNDTIMEO in kernel 2.4. It is a very use
feature which can avoid complexity and pain in userspace programs.
Unfortunately, it seems to be very buggy. Here are two buggy scenarios.
1)
Create a socketpair(), PF_UNIX, SOCK_STREAM.
Set a 5 second SO_SNDTIMEO on
Hi,
I notice the entities in the subject line have appeared in Linux 2.4.
What is their functional specification? I guess they trigger if no bytes
are received/send within a consecutive period. How does the app get the
error? -EPIPE for a blocking read/write? If so, does SIGPIPE
get raised? Or
On Sun, 11 Feb 2001, Andi Kleen wrote:
> On Sun, Feb 11, 2001 at 08:41:04PM +0000, Chris Evans wrote:
> >
> > [cc: Andi]
>
> Missing context..
[...]
> What do you exactly think is wrong?
man socket(7) says that setting SO_LINGER on a socket will make shutdown()
a
[cc: Andi]
On Sun, 11 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > I'm not seeing shutdown(2) block on a TCP socket. This is Linux kernel
> > 2.2.16 (RH7.0). Is this a kernel bug, a documentation bug,
>
> Man page is wrong.
Yes, man socket(7) seems to be wrong.
I don't have access to a ge
Hi,
>From socket(7):
SO_LINGER
...
When enabled, a close(2) or shutdown(2) will not
return until all queued messages for the socket
have been successfully sent or the linger timeout
has been reached.
I'm not seeing shutdow
On Fri, 2 Feb 2001, Marcelo Tosatti wrote:
>
> Linus,
>
> There is a significative amount of people who use sard's additional block
> layer statistics (I'm one of them). It would be nice to have it in the
> official free.
Definitely.
Cheers
Chris
-
To unsubscribe from this list: send the line
[cc: davem because of the severity]
On Thu, 1 Feb 2001, Malcolm Beattie wrote:
> rid of the hang. So it looks as though some combination of
> shutdown(2) and SIGABRT is at fault. After the hang the kernel-side
Nope - I've nailed it to a _really_ simple test case. It looks like a
read() on a sh
On Thu, 1 Feb 2001, Malcolm Beattie wrote:
> Mapping the addresses from whichever ScrollLock combination produced
> the task list to symbols produces the call trace
> do_exit <- do_signal <- tcp_destroy_sock <- inet_ioctl <- signal_return
>
> The inet_ioctl is odd there--vsftpd doesn't explicit
On Thu, 1 Feb 2001, Malcolm Beattie wrote:
> Chris Evans writes:
> > I've just managed to reproduce this personally on 2.4.0. I've had a report
> > that 2.4.1 is also affected. Both myself and the other person who
> > reproduced this have SMP i686 machines, w
Hi,
I've just managed to reproduce this personally on 2.4.0. I've had a report
that 2.4.1 is also affected. Both myself and the other person who
reproduced this have SMP i686 machines, which may or may not be relevant.
To reproduce, all you need to do is get my vsftpd ftp server:
ftp://ferret.l
On Mon, 29 Jan 2001 [EMAIL PROTECTED] wrote:
> Thanks to both Jens and Chris - this provides the information I need to
> obtain our busy rate
> It's unfortunate that the kernel needs to be patched to provide this
> information - hopefully it will become part of the kernel soon.
>
> I had a respo
On Mon, 29 Jan 2001 [EMAIL PROTECTED] wrote:
> All,
>
> I work for a company that develops a systems and performance management
> product for Unix (as well as PC and TANDEM) called PROGNOSIS. Currently we
> support AIX, HP, Solaris, UnixWare, IRIX, and Linux.
>
> I've hit a bit of a wall trying
Hi,
Looking at the code for sock_no_fcntl() in net/core.c, I cannot specify
"0" as a value for F_SETOWN, unless I'm the superuser. I believe this to
be a bug, it stops de-registering an interest in SIGURG signals. Let me
know if you want a patch.
Cheers
Chris
-
To unsubscribe from this list: s
On Tue, 9 Jan 2001, Ingo Molnar wrote:
> This is one of the busiest and most complex block-IO Linux systems i've
> ever seen, this is why i quoted it - the talk was about block-IO
> performance, and Stephen said that our block IO sucks. It used to suck,
> but in 2.4, with the right patch from Je
Hi,
I ran some 2.2 vs. 2.4 benchmarks, particularly in the area of file i/o,
using bonnie++.
The machine is a SMP 128Mb PII-350 with a udma2 drive capable of some
20Mb/sec+. Kernels involved are 2.4.0, and the default RH7.0 kernel
(2.2.16 plus more patches than you can shake a stick at).
Not g
On Fri, 5 Jan 2001, Chris Mason wrote:
> > Could someone create one single patch for the 2.4.0 ?
> >
> I put all the code into CVS, and Yura is making the official patch now.
Since 2.4.0 final should fix a few i/o performance issues (particuarly
under heavy write loads), a quick few ext2 vs. re
On Thu, 4 Jan 2001, Alan Cox wrote:
> > On Thu, Jan 04, 2001 at 02:59:49PM -0200, Rik van Riel wrote:
> > > Unfortunately you seem to ignore my arguments, so lets
> > I've not ignored them, as said they were either obviously wrong of offtopic.
>
> Would the two of you ajourn this debate to alt.f
On Sat, 30 Dec 2000, Linus Torvalds wrote:
> On Sat, 30 Dec 2000, Steven Cole wrote:
> >
> > It looks like 2.4.0-test13-pre7 is a clear winner when running dbench 48
> > on my somewhat slow test machine (450 Mhz P-III, 192MB, IDE).
>
> This is almost certainly purely due to changing (some would
On Tue, 14 Nov 2000, Jakub Jelinek wrote:
> > Rather than add sanity checking to modprobe, it would be a lot easier
> > and safer from a security audit point of view to have the kernel call
> > /sbin/kmodprobe instead of /sbin/modprobe. Then kmodprobe can sanitise
> > all the data and exec the r
On Mon, 13 Nov 2000, Torsten Duwe wrote:
> > "Francis" == Francis Galiegue <[EMAIL PROTECTED]> writes:
>
> >> + if ((*p & 0xdf) >= 'a' && (*p & 0xdf) <= 'z') continue;
>
> Francis> Just in case... Some modules have uppercase letters too :)
>
> That's what the &0xdf is intended for
On Mon, 30 Oct 2000, Andrea Arcangeli wrote:
> functionality that needs high performance completly in kernel? People
> may need to write high performance network code for custom protocols,
> this way they will end creating kernel modules with system-crashing
> bugs, memory leaks and kernel buffe
On Mon, 23 Oct 2000, Jeff Garzik wrote:
> First test was with 2.4.0-test10-pre3.
> Next four tests were with 2.4.0-test10-pre4.
> Final four tests were with 2.2.18-pre17.
>
> All are 'virgin' kernels, without any patches.
[...]
I'll take the liberty of highlighting some big changes, v2.2 vs v
On Sat, 21 Oct 2000, Bill Wendling wrote:
> } > bdflush is broken in current kernels. I posted to linux-mm about this,
> } > but Rik et al haven't shown any interest. I normally see bursts of
> } > up to around 40K cs/second when doing writes; I hacked a little
> } > premption counter into t
On Wed, 11 Oct 2000, Alan Cox wrote:
> > > have the rules for testing if the driver/host/device register and report
> > > that all signals are valid and stable.
> >
> > Yes, I had some "interesting" modifications to a lot of my /usr when I
> > tried to activate UDMA4 under RH7.0 (I don't believ
Hi,
Here's a very strange (and repeatable) result. Affects 2.2.x + raw device
patches (i.e. RH7.0). Also had a similar effect on 2.4.0test9!
The problem is best described with a little sequence. After using raw i/o
facilities, streamed block device reads from the same underlying device
exhibit
Hi,
Finally got round to checking out 2.4.0test9.
Unfortunately, 2.4.0test9 exhibits poor streaming i/o performance when
under a bit of memory pressure.
The test is this: boot with mem=32M, log onto GNOME and start xmms playing
a big .wav ripped from a CD (this requires 100-200k read i/o per s
On Wed, 11 Oct 2000, Alan Cox wrote:
> The 2.2 kernel we ship doesnt have the ide patches either so Im not suprised
> it got upset 8)
Ah yes you're correct. I saw the patch in the kernel SRPM but didn't look
far enough to see:
...
# IDE patch provides UDMA66 support, but is known to corrupt fi
On Wed, 11 Oct 2000, Alan Cox wrote:
> > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>
> Bad CRC is a cable error. That could be misconfiguration but could also be
> crap cables
It went away when I enabled PIIX4 support
On Tue, 10 Oct 2000, Andre Hedrick wrote:
> Also set this option "CONFIG_IDEDMA_IVB" because you are in the
> transistion period of drive manufacturing.
Turned that on, applied the patch. BTW, your patch seems to make the
"Speed warnings" failure _more_ likely??
Still refuses to activate UDMA3
On Tue, 10 Oct 2000, Andre Hedrick wrote:
> Basically you have drive that caught in the word93 rules change.
>
> However, the error you got were real and the kernel did properly respeed
> the drive to one step slower. The problem above prevented you from going
> from ATA66 to ATA44, thus you f
Hi,
Finally got around to trying out 2.4.0test9. I'm going to do some VM
performance comparisons (incidentally because VM should be a carefully
measured science not random cool idea of the day which we have seen too
much of recently).
Unfortunately, I can't start fair tests yet because UDMA3 re
On Wed, 4 Oct 2000, Rik van Riel wrote:
> Handling out-of-memory in a clean and predictable way is the
> next thing on the feature list. I'll add it RSN (I'm reasonably
> sure now that the current VM features are stable ... time for
> OOM handling).
Stable is good. But before moving on, wouldn'
On Fri, 15 Sep 2000, Matthias Andree wrote:
> BUG DESCRIPTION:
> (This is for IPv4, someone would have to check IPv6 as well).
> The socket flag O_NONBLOCK is _NOT_ properly inherited through an
> accept(2) call, in spite of what socket(7) documents. This is a bug.
> accept(2) must copy
On Wed, 13 Sep 2000, Matthew Kirkwood wrote:
> [0] Insert obligatory "why oh why" on Linus' not
> taking SCT's sar/iostat patches.
Indeed. It's a shame because 2.4 is gaining a relatively complete
"Enterprise checklist". It's a further shame because it's a non-intrusive
patch.
Yes, detaill
On Tue, 12 Sep 2000, Alan Cox wrote:
> > Now, I see people trying to introduce the concept of elapsed time into
> > that fix, which smells strongly of hack. How will this hack be cobbled
>
> Actually my brain says that elapsed time based scheduling is the right
> thing to do. It certainly works
On Tue, 12 Sep 2000, Hans Reiser wrote:
> I really think Rik has it right here. In particular, an MP3 player
> needs to be able to say, I have X milliseconds of buffer so make my
> worst case latency X milliseconds. The number of requests is the
> wrong metric, because the time required per re
On Tue, 12 Sep 2000, Rik van Riel wrote:
> On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> > On Tue, 12 Sep 2000, Rik van Riel wrote:
> >
> > >Uhmmm, isn't the elevator about request /latency/ ?
> >
> > Yes, but definitely not absolute "time" latency.
> >
> > How do you get a 1msec latency for
On Mon, 4 Sep 2000, Alan Cox wrote:
> > Is it required that the O_NONBLOCK flag be copied from a listening
> > socket to an accepted socket? Dan Bernstein believes this is a bug.
>
> My posix 1003.1g draft leaves it undefined. It is possible that
> SuS clarifies this. Unless he can cite a SuS
On Fri, 1 Sep 2000, Rik van Riel wrote:
> On Fri, 1 Sep 2000, Tigran Aivazian wrote:
>
> > Any of you tried copying a 2G file in the same (ext2)
> > filesystem? It starts swapping like mad and generally behaves
> > indecently, despite the huge 1024M of RAM it has.
>
> http://www.surriel.com/pa
On Thu, 31 Aug 2000, Matthew Kirkwood wrote:
> On Thu, 31 Aug 2000, Andi Kleen wrote:
>
> > > > Clearly? How do MTRR changes relate to rawio ?
> > >
> > > RAWIO is about hardware level access not Stephens O_DIRECT stuff
> >
> > So why is /proc/kcore access SYS_RAWIO then ?
>
> I kind of overl
On Thu, 31 Aug 2000, Tigran Aivazian wrote:
> Actually, microcode driver checks CAP_SYS_RAWIO only on open() so it would
> allow access to the receiver of fd even he has no CAP_SYS_RAWIO
> privilege. Hmmm, maybe I should put it back into write() method, as Linus
> (or someone else) did at some p
61 matches
Mail list logo
