Hello!
> + if (softirq_active(smp_processor_id()) & softirq_mask(smp_processor_id())) {
> + do_softirq();
> + return 0;
BTW you may delete do_softirq()... schedule() will call this.
> + *
> + * Isn't this identical to default_idle with the 'no-hlt' boot
> + * option
Hello!
> packet in the queue. No other conditions i found. But i need repeatedly test
> the top packet in the queue.
>
> How to accomplish it?
Look into sch_tbf.c for example. Hint: timer.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hello!
> empty, except for occasional ACKs. The utilization of the channel is about 4%.
1. tcpdump is required.
2. exact vesion of used kernel is required too.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
Hello!
> But with a huge overhead. I'd prefer to call it directly from within the
> idle functions, the overhead of schedule is IMHO too high.
+ if (current->need_resched) {
+ return 0;
+ }
+ if (softirq_active(smp_processor_id()) & softi
Hello!
> Btw, you don't schedule the ksoftirqd thread if do_softirq() returns
> from the 'if(in_interrupt())' check.
ksoftirqd will not be switched to before the first schedule
or ret form syscall, when softirqs will be processed in any case.
So, wake up in this case would be mistake.
> I assu
Hello!
> In brief: a stale state of the tcp send queue was observed for 2.2.17
> while send-q counter and connection window sizes are not zero:
I think I pinned down this. The patch is appended.
> diagnostic, I'll try to get it. In any case, I plan to run something through
> this connecti
Hello!
>mtu 382 + keepalive yes -> loss
>mtu 382 + keepalive no -> ok
Well, I ignored this because it looked as full sense. Sorry. 8)
> such a picture? If the answer is "yes", I am almost satisfied. :-)
No, the answer is strict "no". Until keepalive is triggered the first
time, it ca
Hello!
> > If my guess is right, you can easily put this socket to funny state
> > just catting a large file and kill -STOP'ing ssh. ssh will close window,
> > but sshd will not send zero probes.
>
> [1] I have checked your statement on 2 different machines, running 2.2.17.
> No confirmation.
Hello!
> At last, I tried several MTUs on 3d computer, running "right" 2.2.17, and
> could not find conditions, under which any loss of ACKs can be detected.
8)8)8)
ppp also inclined to the mss/mtu bug, it allocates too large buffers
and never breaks them. The difference between kernels looks
Hello!
> In my experiments linux simply sets mss=mtu-40 at the start of ethernet
> connections. I do not know why, but belive it's ok. How the version of
> kernel and configuration options can affect mss later?
You can figure out this yourself. In fact you measured this.
With mss=1460 the pr
Hello!
> If your model does not cover such situation, pls, take it in mind. :)
Taken.
Is the machine UP? The only other known dubious place is smp specific...
BTW if that cursed socket is still alive, try to make the experiment
with filling window on it. It must stuck, or my theory is complet
Hello!
> 1. for tp_frame_size, I dont want to truncate any data on ethernet, I
> need 1514 bytes, is this the best way to do it and not waste space?
To select small snapsize (obtained from later experiments),
to set PACKET_COPY_THRESH to read larger packets via recvmsg().
> 2. what is tp_block_
Hello!
> Im my case P-MTU discovery
Sorry, I lied. Not pmtu discovery but exaclty opposite effect
is important here: collapsing of small frames to larger ones.
Each such merge results in loss of 1 "sack" in 2.2.
> I only wrote that it was active when got stuck. It may be idle before -
> I do
Hello!
> Kernel 2.4.x apparently disregards my ppp options MTU setting of 552
> and sets mss=536 (=> MTU=576).
Yes, default configuration is not allowed to advertise mss<536.
The limit is controlled via /proc/sys/net/ipv4/route/min_adv_mss,
you can change it to 256.
Default of 536 is sadistic (
Hello!
> Please cite an exact RFC reference.
No need to cite RFC, this is plain sillogism.
A. Datagram protocols do not work with mtus not allowing to send
512 byte frames (even DNS).
B. Accoutning, classification, resource reervation does not work on
fragmented packets.
-> IP suite is n
Hello!
> Maybe someone want to say me what does it mean and how serious it is?
It means that debugging messages are still not disabled in 2.4.x 8)
> Any fixes?
These ones can be ignored.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hello!
> I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
Please, Alan, distinguish two things: "works" and "works, until
I ask X". The second is equal to "does not".
512 is maximal message size, which is transmitted without troubles,
hardwired to almost all the datag
Hello!
> Unfortunately, it seems to be very buggy. Here are two buggy scenarios.
--- ../vger3-010210/linux/net/ipv4/tcp.cSat Feb 10 23:16:51 2001
+++ linux/net/ipv4/tcp.cSat Feb 17 23:27:43 2001
@@ -691,6 +691,8 @@
set_current_state(TASK_INTERRUPTIBLE);
+
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 observe
that sendfile() is even not interrupted by signals. 8)
Hello!
> Yes. The 5.6.7.8 machine is connected to the Internet via a Linksys
> "router" that is also performing masquerade.
>
> I will be very angry if this turns out to be the culprit.
I am afraid it is. It corrupts packets preserving their checksum.
Look:
> Trace taken from 1.2.3.4 machi
Hello!
> So the actual timeout would be 2 * SO_SNDTIMEO.
It will timeout if write of some page blocks for SO_SNDTIMEO.
If transmission of any page never takes more than SO_SNDTIMEO it never
times out.
You can think about sendfile() as subroutine doing:
for (;;) {
read(4
Hello!
> .. unless that page was partially written, in which case a short write
> count is returned (rather than a timeout error), and the loop goes around
> again.
sendfile() does not return on partial write and tries to push more
until error. On fast link it most likely succeeds, so that it is
Hello!
> Message size != MTU.
Alan, you misunderstand _sense_ of the problem.
Fragmentation does _not_ work on poor internet more. At all.
Look at original report. It failed _only_ because his intemediate
node failed to forward fragmented packets.
Alexey
-
To unsubscribe from this list: send t
Hello!
> Wouldn't it be simpler to just fix the bugs
There are no bugs.
There is phylosophical discussion about current state of internet
communications.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
Hello!
> This smells bad. Datagram protocol send sizes are only limited by
> socket buffer size, nothing more. Fragmentation makes it work.
The thread was started from the observation that fragmented frames
do _not_ pass through router. See? 8)
Path mtu discovery exists exactly to help to sol
Hello!
> Please cite an exact RFC reference.
Imagine, I found this reference yet. This is rfc1191, of course. 8)
in the MSS option. The MSS option should be 40 octets less than the
size of the largest datagram the host is able to reassemble (MMS_R,
as defined in [1]); in many cases, t
Hello!
> You are right - our sendfile() implementation is broken. I have fixed it
Thank you!
> Investigation shows that the Linux network layer is behaving oddly. It
> seems that we are writing 4096 bytes to a socket. This proceeds in 4096
> byte chunks until the send buffer on the socket is f
Hello!
> We are implementing an IP stack.
Alan, please, tell me what is wrong. And we will repair this.
The implementation follows RFCs and even relaxes their requirements
in the cases, when they are far from reality.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
Hello!
> of errors a bit but I'm not sure I fully understand the implications of
> doing so.
Until these numbers do not exceed total amount of RAM, this is exactly
the action required in this case.
Dumps, which you sent to me, show nothing pathological. Actually,
they are made in some period of
Hello!
> OK! I actually expected 2.4 to be somewhat selftuning.
Defaults for these numbers (X,Y,Z) are very conservative.
> Interesting you say that, I looked at the logs and I see over 5000 sockets
> used, does'nt look peaceful to me. But you are absolutely right about the
> orphans. The erro
Hello!
> > Yes its a SHOULD in RFC1122, but in any normal environment pretty much a
> > must and I know of no stack significantly violating it.
>
> I didn't know there was such a thing as a normal environment :)
Jokes apart, such "normal" environments are rare today.
>From tcpdumps it is clear
Hello!
> Feb 23 12:42:30 rcc2 kernel: Warning: kfree_skb passed an skb still on a list (from
>c01f58dc).
BTW, that's didactic example of bug which results in similar behaviour.
Alexey
> From: [EMAIL PROTECTED] (Andrew Morton)
> Subject: Re: Failed assertion
> Date: 27 Feb 2001 04:15:01 +0300
Hello!
> > 3) Enforce correct usage of it in all the networking :-)
>
> ,) -- the tricky part.
No tricks, IP[v6] is already enforced to be clever; all the rest are free
to do this, if they desire. And btw, driver need not to parse anything,
but its internal stuff and even aligning eth II header
Hello!
> netstat on isdn-gw shows the following:
>
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp72868 0 isdn-gw.piltdown.a:1023 pilt-gw.piltdown.at:ssh ESTABLISHED
plus
> select(4, [3], [3], NULL, NULL) = 2 (in [3], out [3])
> Ma
Hello!
> I've seen hanging rsync over ssh more than once, while sending much data
> from an x86 running Linux (late 2.3.x) to Sparc/Solaris2.5.1
I remember this your report. However, recent news force to suspect
that the reason was in Solaris yet. Actually, if you send tcpdump of
failed session,
Hello!
> I'll see if I can strace it from the start until it hangs tomorrow.
Please...
Also, try to make binary tcpdump.
> I was running at one point a 2.4.0-test kernel, but I didn't see these
Yes, it did not result in full stall. Lost wakeups were recovered
f.e. by any keyboard activity. 8
Hello!
> They know that iMimic's polymix performance on Linux 2.2.* is half what it is on
> BSD.
What is "iMimic's polymix"? I am almost sure, it is simply buggy
and was not _debugged_ under linux.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Hello!
> I've also reported
The report by Scott Laird is sane unlike your one.
It can be explained by bug rather than only by poltergeist. 8)
> Thanks for confirming that 2.2.15pre13 is not the cause.
Russel, you are warned that kernels<2.2.17 and rsync is an incompatible
combination.
Alexey
Hello!
> same means its not the same bug?
It is the same, I think.
> If you still insist that it is purely a 2.2.15pre13 bug
I never said this. I said that your strace is _wrong_, how can I be
sure that tcpdump is not wrong too? You could understand this. 8)
> together to put 2.2.18 on this
Hello!
> this kernel was compiled with GCC 2.95.2,
This is a hint.
Could you make the following things:
1. to disassemble tcp_poll() (the easiest way is to gdb vmlinux, to
say x/i tcp_poll and to hold enter pressed long enough, copying screen
to file) and to send the result to me.
2. to
Hello!
> The manual specifies the following flag to be returned by the
> kernel
> > #define POLLHUP 0x0010/* Hung up */
>
> Hanging up is ambiguous. Does it mean that the client is dead,
> that he closed his end of the socket, or that he shut down one or
> both directions of the data flo
Hello!
> memory". Rsync is writing on a socket which is set non-blocking and
> the write is apparently returning ENOMEM.
This must not happen with stock 2.4.0. TCP never returns ENOMEM.
Please, investigate.
But application should be ready to get this error yet.
> >From the point of view of t
Hello!
> Recently I tried 2.2.17, this kernel was up for about a month, before
> there was a kernel oops. The syslog messages are:
This is caused by illegal setting of /proc/sys/net/ipv4/ip_local_port_range
with kernels before 2.2.18.
Do not touch this value or change it to something reasonable
Hello!
> I'm all for TCP_CORK but it has the disavantage of two syscalls for doing the
MSG_MORE was invented to allow to collapse this to 0 of syscalls. 8)
> A new ioctl on the socket should be able to do that (and ioctl looks ligther
> than a setsockopt, ok ignoring actually the VFS is grabbi
Hello!
> Doing PUSH from setsockopt(TCP_CORK) looked obviously wrong because it isn't
> setting any socket state,
? 8)
> and also because the SIOCPUSH has nothing specific
> with TCP_CORK, as said it can be useful also to flush the last fragment of data
> pending in the send queue without havi
Hello!
> So if I understand all this correctly...
>
> The difference in ACK generation
CORK does not affect receive direction and, hence, ACK geneartion.
The problem is that TCP does not know, when full request is received
and it must ack instantly at connection start and after some idle
peri
Hello!
> Ingo, you should realize
Ingo did not try to argue. I do not too.
This is right, no doubts.
> Mantra: "everything is a stream of bytes". Repeat until enlightened.
... but devil invented record marks and pushes, seduced mankind
and we was evicted from the paradise. 8)
Alexey
-
To un
Hello!
> I thought setsockopt is meant to set an option in the socket,
It is not.
setsockopt() is simply a bit more clever extension to ioctl(),
which is adapted (in bsd style though) to understand layering
and has an explicit length to data.
It is prefered for all the operations on sockets,
a
Hello!
> the business about the last 1100ish bytes of a 4096 byte send being
> delayed by nagle only implies that the stack's implementation of nagle
> was broken and interpreting it on a per-segment rather than a per-send
> basis.
+
> software, or the host TCP stack. otherwise, the persistent c
Hello!
> It's about direct i/o from/to pages,
Yes. Formally, there are no problems to send to tcp directly from io space.
But could someone explain me one thing. Does bus-mastering
from io really work? And if it does, is it enough fast?
At least, looking at my book on pci, I do not understand
Hello!
> The "uncork" won't push the last skb on the wire if there is not acknowledged
> data in the write_queue and the payload of the last skb in the write_queue
> isn't large MSS. This because the `uncork' will only re-evaluate the
> write_queue in function of the _nagle_ algorithm, quite corr
Hello!
> My argument applies to 2.4. The uncork _won't_ push on the wire the last
> not mss-sized fragment until it's the last one in the write queue even once
> cwnd and receiver window allows that. I think
Look at the code again. You misread it.
> wouldn't be setting nonalge unconditionally
Hello!
> is there really
> much value in the second request flowing to the server before the first
> byte of the reply has hit?
Yes, of course, it has lots of sense: f.e. all the icons, referenced
parent page are batched to single well-coales
Hello!
> Actually, as long as there is no "struct page" there _are_ problems.
> This is why the NUMA stuff was brought up - it would require that there
> be a mem_map for the PCI pages.. (to do ref-counting etc).
I see.
Is this strong "no-no-no"? What is obstacle to allow "struct page"
to sit o
Hello!
> semantics of snd_sml), maybe it makes the difference but then I don't see how.
It makes. One small packet is allowed to fly, not depending on packets_out.
This is idea of Minshall.
"Classic" Nagle also does not prohibit this, but it is difficult
to formulate it in terms of presegmented
Hello!
> > write(10*MSS)
> > write(1)
> > write(1)
...
> As far as I can tell, the second "write(1)" will always merge with the
> first one
This would be true, if Andrea wrote not exactly 10*MSS,
but 10*MSS+1 or just write().
In some exceptional situations (sort of writi
Hello!
> So this mean if I do:
Yes. It is cost, which we have to pay. Look into Minshall's draft,
by the way (draft-minshall-nagle-*), it discusses pros and contras.
Much saner behaviour wrt latency (and perfect clarity) overweights
a bit worse coalescing.
Alexey
-
To unsubscribe from this li
Hello!
> "struct page" tricks, some macros etc WILL NOT WORK. In particular, we do
> not currently have a good "page_to_bus/phys()" function. That means that
> anybody trying to do DMA to this page is currently screwed, simply because
> he has no good way of getting the physical address.
We alre
Hello!
> So now the question is: when does this new nagle algorithm delay packets in the
> write queue? It _must_ do something, otherwise TCP_NODELAY would obviously be a
> noop.
It allows _one_ incomplete segment to fly. Minshall and BSD behave absolutely
similarly in all the curcumstances exce
Hello!
> - netif_stop_queue() was called in post softnet mode when entering
> start_xmit() which was unnecessary. Now it is only set when the
> queue is full.
Jes, it is not necessary since linux-2.0 or so...
All the difference with softnet is that you need not _test_ tbusy
on entry. That's
Hello!
> > request_module has the same effect as running suid. dev_load() can
> > take the interface name and pass it to modprobe unchanged and modprobe
> > does not verify its input, it trusts root/kernel.
>
> Then dev_load is being called the wrong way. In older kernels we explicitly
> only d
Hello!
> Only the caller knows if the data is tainted. Thus only the caller can decide
Sorry? What data? What to decide?
Device name of &|&|&|&|&|& is absolutely legal, nicely loking name.
dev.c _wants_ to load such device and it is problem of kmod,
if it is not able to make this.
It is the fi
Hello!
> > It means that test for CAP_SYS_MODULE is illegal, moving pure policy
> > issue to improper place.
>
> Definitely not so
>
> What matters is whether the user is requesting a module or the kernel is
> choosing to load a module. In the former case where the user can influence the
> mod
Hello!
> This IS the magical security device.
Jail maybe is. Chroot is not. It is even not clear, why you remembered
about jail here. Chroot does not imprison anyone.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Hello!
> Well, because lots of people seem to THINK that chroot imprisons
> someone. And "jail" actually does
Also many of people work to add to linux jail-like functionality,
which is expected to be real security tool unlike bsd jail.
I think from the same source where you read about jail
Hello!
> Alexey! Even someone understood all this already, look
> to include/net/sock.h SOCK_SLEEP_{PRE,POST} macros :-)
>
> I will compose a patch to fix all this.
O! But who was this wiseman? 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Hello!
>- it will nearly never allow concurrent accesses (seems to be what was
> intented when it was written)
Never, to be more exact. Concurrent accesses are allowed only with rtnetlink.
In 2.4 it is always exclusive, because shared access turned out to
be mostly useless.
>- it
Hello!
> The probability of just exactly the zero packet hitting you is very small.
... long laughter ...
Andi, I see you are not very strong in methematics. 8)
Timestamp is not a random number, so that probability of PAWS failure
does not depend on restricting it at all. The only thing which c
Hello!
> NetBSD ignores 0 timestamps. Although that's a hack it is IMHO a reasonable one and
> Linux should probably do it too. Even when the 0 is generated legitimately by
>wrapping
> counters it is probably not a big problem to lose timestamps for such few packets.
Sorry, ignoring some value
Hello!
> > A while back I reported the lost need_resched flag bug ( it happens if
> > need_resched is set right before switch_to() is called). Later on a one-line
> > fix is added to __schedule_tail().
> >
> > current->need_resched |= prev->need_resched;
> >
> > I looked at the latest
Hello!
> What am I doing wrong?
You change parameters without investigating why failure happened.
This approach cannot succeed, of course.
> problem? Is there any way I can get runtime information from the kernel on
> things like amount of socket memory used and amount available?
cat /proc/
Hello!
> I think wake_up_process() is called in interrupt routine quite often and it
> will set need_resched flag (through reschedule_idle()). ???
It sets _right_ flag cpu_curr(this_cpu)->need_resched, rather than
current->need_resched.
> happening. Ether some new code takes care of it. Or
Hello!
> And then it becomes obvious that count is not needed, it is always 1
> or 0; ie. only threads waiting on same fd in same struct files_struct
> must be woken. My patch
The patch is wrong, Paul. It does work with poll(), but it is plain luck.
If poll() were more optimal, it would fail a
Hello!
> tried to grep gcc but my gcc knowledge is too low to reverse engeneer the
> implement semantics of the "memory" clobber fast
Just hint. I remember the time when "memory" clobber option
was _absent_ in gcc. And we managed to compile kernel with such gcc. 8)
To all that I understand, "asm
Hello!
> - Could there be some kind of handling for such packets (meaning TCP packets
> reaching at an unused port with ACK bit set - with no previous SYN etc packet)
> to avoid such DoS attacks? Is the same happening to newer kernels? If yes,
> should we just eat it and shut up (because th
Hello!
> installed RH6.2 with Linux kernel 2.2.16 on my Dell laptop (P3-500,
> 256MB RAM). One thing that I found is the networking performance
> between this Linux box and all my Solaris 7 based servers are very very
> slow.
Make tcpdump before all.
> least 1000K/s, normally 3000k/s.
Somet
Hello!
> Well, now GCC does CSE across "asm" and will eliminate memory loads,
> even though it may not move them! I suspect it always did CSE across
> "asm" and we just never got hit by the bug.
dummy_lock trick is equivalent to "memory" clobber.
So that there is no real bug.
Alexey
-
To unsu
Hello!
> I believe that the DoS is that the path through the kernel turns out to be
> long and that a lot of these packets will bring a machine to its knees.
It is not longer than path for any other kind of packet.
In the reported case it is much shorter. 8)
Apparently, you try to remind about
Hello!
> > I guess Alexey point is that the current compiler doesn't notice that.
Rather I proposed explanation, why missing barrier does not
have any effect. 8)8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Plea
Hello!
> Well, it looks like you're getting hit with stream.c or raped.c and what
> I'm passing on is just what I picked up from a CERT guy at Usenix. He
> claimed that stream.c worked by exploiting a long path through the kernel
He just said a crap. All the discussion around stream.c is banal
Hello!
> I guess I´d also need to call lock_sock() from sendmsg(). And before
> calling x25_kick from socket input path, I´d need to verify that
> sk->lock.users is zero. If sk->lock.users was !=0, I´d need some atomic
> variable anyway in order to defer the kick.
In input path you have a packe
Hello!
> Yes, I see. I did not realize before that the lock_sock and the
> sk->backlog framework are not two independent things. They really
> seem to be designed for team work only. Did I get this right?
Yes.
Actually, in 2.4 lock_sock() is also semaphore and in some cases
(f.e. for stateless
Hello!
> timer events where the protocol specs require immediate reaction and
> which need to change socket state. For such events, it might not
> be obvious how to defer them when sk->lock.users != 0.
After some thinking, you will understand that "timer" and "immediate"
are incompatible.
TCP
Hello!
> But I realized another problem X.25 related SMP problem -- this time
> related to input. The protocol design assumes that the transmission
> path preserves the packet ordering. It seems that with 2.4.0 SMP, the ordering
> of the packets when received from the wire is not necessarily the
Hello!
> Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
> address. The correct behavior should be a return code of -1 with errno
> set to EADDRNOTAVAIL.
You can bind to any address, it is your right. You will not able
to receive on or to send from such socket until add
Hello!
> I'll keep looking.
Is it easy to reproduce? If so, try to make tcpdump, which
covers one of these messages.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Hello!
> Well, there were quite a few TCP bugs fixed after 2.2.14.
Seems, it is that bug, which you have seen talking from
(sorry, I cannot pronounce this host name publically 8)) to amber.
ACK, following FIN was considered as illegal data.
We have fixed it both in 2.2 and 2.3.
Alexey
-
To un
Hello!
> I'll keep trying though.
Please, try... It is very important issue.
No open-sources OSes (including NT4) can produce this illegal pattern.
The rest are derived from them. So that I have to assume that
it is some unknown bug at our side.
Alexey
-
To unsubscribe from this list: send the
Hello!
> The SYN/ACK handshake appears to go well, and telnet reports a connection
> (the daemon doesn't, no data has been sent). However, Linux keeps sending
> SYNs, which keep getting ACKed. I'm not sure if this is desired behavior. It
> appears to be a side effect of the TCP_DEFER_ACCEPT timeo
Hello!
> Connection established, and I send no data
But why did you set DEFER_ACCEPT then? 8)
I explained when it can be used.
> packet. Why would we lose the connection?
Not enter "quit", wait until connection will timeout.
(It is not very soon normally). And look what happens.
Hint: the p
Hello!
> Ok, this surely is incorrect. However, sending spurious SYNACK packets
> doesn't seem like the way to solve this problem.
They are _not_ spurious. Connection did not enter ESTABLISHED state.
If it entered this state, we would have no rights to timeout.
It should be closed with FIN etc.
Hello!
> Does kernel 2.4.0-testX(latest) still have this behavior?
Why not to test and to report yet? 8)
It is not supposed to have this behaviour.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
Hello!
> On Tue, Oct 31, 2000 at 08:55:13PM +, Alan Cox wrote:
> > What about the fact anyone can crash a box using ioctls on net
> > devices and waiting for an unload - was this fixed ?
What do you mean?
If I understood you correclty, this has been fixed in early 2.3
and never reap
Hello!
> It is not safe, just not worse than 2.2.
Andi.. 8)
That issue, which was meant here, it is 100% safe.
I start to suspect you did not look into this code since 2.2.
I acn assume that nothing has changed in ISDN,
in other drivers big changes happened. 8)
Alexey
-
To unsubscribe fro
Hello!
> that does hardware register access without protecting against interrupts
> or checking if the interface is up.
This issue is not that issue. It is separate issue and in fact
it is private problem of driver and its author, what is safe,
what is not safe.
F.e. I see no cathastrophe even
Hello!
> > Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
> > what BSD does: re-start the interrupted call?
>
> This is crap. Returning EINTR is necessary for many applications.
Just reminder: this "crap" is default behaviour of Linux nowadays. 8)8)
Alexey
-
To unsu
Hello!
> de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is
> duplicated now in tulip driver.
Luckily, my old Multia died. 8)
Jeff, tulip did not work with genuine Digital cards.
de4x5 was faulty (link state machine was broken, it has lost
link after some events on wire) but it
Hello!
> > Luckily, my old Multia died. 8)
> >
> > Jeff, tulip did not work with genuine Digital cards.
>
> I'm pretty sure I fixed that. Tested it on my Multia in fact :) (and
> my AS200 too)
>
> The fix should be in 2.2.17 tulip.c, as well as 2.4.x...
Then sed -e 's/Luckily/What a pity/'
Hello!
> if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE))
> == 0)
> BUG();
The Puzzle... 8) It is truly impossible.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
Hello!
> No, that code is correct, provided (current->state == TASK_RUNNING)
> on entry. If it isn't, there's a race window which can cause
> lost wakeups. As a check you could add:
>
> if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0)
> BUG();
Though
1 - 100 of 165 matches
Mail list logo
