| 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
| ||
|
Message-Id: <1252430825.7145.55.camel@calx> Date: Tue, 08 Sep 2009 12:27:05 -0500 From: Matt Mackall <mpm@...enic.com> To: DDD <Dongdong.deng@...driver.com> Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org Subject: Re: [PATCH 1/1] netpoll: fix race between skb_queue_len and skb_dequeue On Tue, 2009-09-08 at 15:49 +0800, DDD wrote: > This race will break the messages order. > > Sequence of events in the problem case: > > Assume there is one skb "A" in skb_queue and the next action of > netpoll_send_skb() is: sending out "B" skb. > The right order of messages should be: send A first, then send B. > > But as following orders, it will send B first, then send A. I would say no, the order of messages A and B queued on different CPUs is undefined. The only issue is that we can queue a message A on CPU0, then causally trigger a message on CPU1 B that arrives first. But bear in mind that the message A >>may never arrive<< because the message is about a lockup that kills processing of delayed work. Generally speaking, queueing should be a last ditch effort. We should instead aim to deliver all messages immediately, even if they might be out of order. Because out of order is better than not arriving at all. -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists