-- Contact Mr David Green for a sum pay out of 1,230,310 GBP. Provide Your Name: Address: Age: Sex: Occupation:Email:cgnlcg2009@9.cn)for Verification immediately. --

We are contacting you in regards to an unusual activity that was identified in your Mailbox. As a result, access to your mailbox has been limited. Youare required verify your mailbox by providing the following information before your mailbox will be reactivated;Verify your mailbox details IT Service Mail to: uk.upgradedept99@gmail.com<uk.upgradedept99@gmail.com> Username: Password: Retype password: Please verify your mailbox otherwise due to security reasons we may have to ...

This patchset fixies the race within the poll_wait call and the receive callbacks, by adding memory barrier. - 1/2 includes the actual fix - 2/2 includes optimization for the x86 arch It is discussed and described in the following discussions: http://lkml.org/lkml/2009/6/18/124 http://lkml.org/lkml/2009/6/25/188 http://lkml.org/lkml/2009/6/29/216 Patchset is made on top of Linus'es tree 7c5371c403abb29f01bc6cff6c5096abdf2dc524 . Booted on x86_64. wbr, jirka --- arch/x86/include/a...

Two small stylistic comments, please make this an inline function: static inline void smp_mb__after_lock(void) { } #define smp_mb__after_lock ditto. Ingo --

Hmm, why do we even care when read_lock should just die? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

+1 :) Do you mean using a spinlock instead or what ? Also, how many arches are able to have a true __read_lock() (or __spin_lock() if that matters), without acquire semantic ? --

Are you guys sure you are in agreement about what you all mean by "acquire semantics"? Clearly, any correct __read_lock() implementation must enforce ordering with respect to the most recent __write_unlock(), but this does not necesarily imply all possible definitions of "acquire semantics". Thanx, Paul --

This was following existing implementations of various smp_mb__??? helpers : # grep -4 smp_mb__before_clear_bit include/asm-generic/bitops.h /* * clear_bit may not imply a memory barrier */ #ifndef smp_mb__before_clear_bit #define smp_mb__before_clear_bit() smp_mb() #define smp_mb__after_clear_bit() smp_mb() #endif --

ok, could I include it in the 2/2 or you prefer separate patch? jirka --

how about this.. and similar change for smp_mb__before_clear_bit in a separate patch diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index b7e5db8..4e77853 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -302,4 +302,8 @@ static inline void __raw_write_unlock(raw_rwlock_t *rw) #define _raw_read_relax(lock) cpu_relax() #define _raw_write_relax(lock) cpu_relax() +/* The {read|write|spin}_lock() on x86 are full memory ba...

oops, thanks --

The SCTP pushed the skb data above the sctp chunk header, so the check of pskb_may_pull(skb, xprth + 4 - skb->data) in _decode_session4() will never return 0 because xprth + 4 - skb->data < 0, the ports decode of sctp will always fail. Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> --- net/ipv4/xfrm4_policy.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c index 60d918c..0071ee6 100644 --- a/net/ipv4...

The SCTP pushed the skb above the sctp chunk header, so the check of pskb_may_pull(skb, nh + offset + 1 - skb->data) in _decode_session6() will never return 0 and the ports decode of sctp will always fail. (nh + offset + 1 - skb->data < 0) Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> --- net/ipv6/xfrm6_policy.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c index b4b16a4..3a3c677 100644 --- a/n...

Ok. I finally see the light. I bisected the issue down to eea08f32adb3f97553d49a4f79a119833036000a : timers: Logic to move non pinned timers Disabling timer migration like provided in the earlier commit stops the issue from occuring. That it is related to timers is sensible in the light of my findings, that I could trigger the issue only when using delay in netem - that is the codepath using qdisc_watchdog... Andres --

Thanks. It allowed me to go through some of my remaining paperwork ;-) Does anybody of you have an idea where the problem actually resides? qdisc_watchdog_schedule looks innocent enough for my uneducated eyes - and the patch/infrastructure from Arun goes over my head... I will happily test some ideas/patches. Aside from that - is the whole PSCHED_TICKS2NS/PSCHED_NS2TICKS conversion business purely backward compatibility? Andres --

From: Jarek Poplawski <jarkao2@gmail.com> Well, if you look at that commit the bisect pointed to Jarek, it is a change which starts causing a situation which never happened before. Namely, timers added on one cpu can be migrated and fire on another. So this could be exposing races in the networking that technically always existed. --

I have no ideas how/if the timers are actually broken or if the problem does reside somewhere else and is just made visible by the timer changes. I haven't seen any problems - just curious ;-) Andres --

Wondering - can the wrappers be moved from CPP land to C land by turning them into inlines? (i havent checked all usages so there might be some surprises, but by and large it ought to be possible.) Ingo --

Regarding this scenario, from what I can see - realtime curves will cause discrepancy between virtual times of all leaf classes. Excess bandwidth is small and LS will be unable to compensate for these differences - so the virtual time will drift apart with passing time. But - if any of the classes becomes passive briefly, next time it becomes active, HFSC updates virtual time using mean of max and min virtual time of its sibling classes. Considering that vts are always different in this exam...

actually I see the 2/2 would be better :) jirka --

thanks, jirka --

Sorry, I dont get it. You are referring to softirqs, while I speak of hardware (NIC) interrupts, that can be masked for ever. With your patch : CPU0 CPU1 napi_complete(); /* please note there is no smp_wmb() in __napi_complete() after clear_bit(NAPI_STATE_SCHED, &n->state); (It's implied on x86 because of lock prefix) */ writel(np->irqmask, base + NvRegIrqMask) writel(0, base + NvRegIrqMask); ...

From: Ayaz Abdulla <AAbdulla@nvidia.com> It has nothing to do with "coherency". Re-read Eric's emails, the race can happen on x86 quite trivially. --

Sorry, catching up with emails (hmm, maybe I should stop doing that and read some new emails :) This just turns a wide-open race into a less likely one (that's why it appears to fix the problem). The crux of the issue is that __tun_get(tfile) != NULL has nothing to do with whether the device has been unregistered. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Ke...

Not so. unregister_netdevice rollback_registered tun_net_unit __tun_detach. Further we need rtnl_lock around __tun_detach. --