On Tue, 6 Nov 2014 21:01:00
"Jesper" wrote:
>There is several issues with your submission. I'll take care of
resubmitting a patch in your name (so you will get credit in the git log).
>
>If you care to know, issues are:
>1. you are not sending to the appropriate mailing lists, 2. patch is as
On Tue, 4 Nov 2014 09:48:32 +0800
"billbonaparte" wrote:
> (sorry to send this e-mail again, last mail is rejected by server due to
> non-acceptable content)
There is several issues with your submission. I'll take care of
resubmitting a patch in your name (so you will get credit in the git
On Tue, 6 Nov 2014 21:01:00
Jesper brou...@redhat.com wrote:
There is several issues with your submission. I'll take care of
resubmitting a patch in your name (so you will get credit in the git log).
If you care to know, issues are:
1. you are not sending to the appropriate mailing lists, 2.
On Tue, 4 Nov 2014 09:48:32 +0800
billbonaparte programme...@gmail.com wrote:
(sorry to send this e-mail again, last mail is rejected by server due to
non-acceptable content)
There is several issues with your submission. I'll take care of
resubmitting a patch in your name (so you will get
(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
(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.
On Tue, 28 Oct 2014 11:37:31 +0800 "billbonaparte"
wrote:
> Hi, all:
> sorry for sending this mail again, the last mail doesn't show text
> clearly.
This one also mangles the text, so I cannot follow the race you are
describing. I'll try to reconstruct...
> In function
billbonaparte wrote:
> 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
billbonaparte programme...@gmail.com wrote:
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.
On Tue, 28 Oct 2014 11:37:31 +0800 billbonaparte programme...@gmail.com
wrote:
Hi, all:
sorry for sending this mail again, the last mail doesn't show text
clearly.
This one also mangles the text, so I cannot follow the race you are
describing. I'll try to reconstruct...
In function
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
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.
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.
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
14 matches
Mail list logo
