Re: netfilter: nf_conntrack: there maybe a bug in __nf_conntrack_confirm, when it race against get_next_corpse

(sorry to send this e-mail again, last mail is rejected by server due to non-acceptable content) Florian Westphal [mailto:f...@strlen.de] wrote: >Correct. This is broken since the central spin lock removal, since >nf_conntrack_lock no longer protects both get_next_corpse and >conntrack_confirm.

netfilter: nf_conntrack: there maybe a bug in __nf_conntrack_confirm, when it race against get_next_corpse

Hi, all: sorry for sending this mail again, the last mail doesn't show text clearly. In function __nf_conntrack_confirm, we check the conntrack if it was alreay dead, before insert it into hash-table. we do this because if we insert an already 'dead' hash, it will block fu

netfilter: nf_conntrack: there maybe a bug in __nf_conntrack_confirm, when it race against get_next_corpse

Hi, all: In function __nf_conntrack_confirm, we check the conntrack if it was alreay dead, before insert it into hash-table. we do this because if we insert an already 'dead' hash, it will block further use of that particular connection. but we don't do that right. let

netfilter: NAT: do the optimization for getting curr_tuple in function nf_nat_setup_info

Hi all: In function nf_nat_setup_info, we need to get the current tuple which is supposed to send to destination. If we haven't done any NAT (SNAT or DNAT) for the tuple, then the current tuple is equal to original tuple, otherwise, we should get current tuple by invoking nf_ct_inv