Patchwork [2/2] man/send(2): document a long standing bug that can cause spurious EPERM errors

login
register
mail settings
Submitter Fernando Luis Vazquez Cao
Date March 19, 2013, 6:52 a.m.
Message ID <1363675960.4767.10.camel@nexus>
Download mbox | patch
Permalink /patch/228923/
State Not Applicable
Headers show

Comments

Fernando Luis Vazquez Cao - March 19, 2013, 6:52 a.m.
Subject: [PATCH 2/2] man/send(2): document a long standing bug that can cause spurious EPERM errors

This bug has been known since early 2009 (the latest) and  discussed in
netdev before:

http://marc.info/?l=linux-netdev&w=2&r=1&s=Possible+race+condition+in+conntracking+&q=b

It seems that a proper fix would be non trivial, so document the bug
in the meantime.

Reported-by: Hirotaka Sasaki <sasaki.hirotaka@lab.ntt.co.jp>
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
---



--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - March 19, 2013, 10:12 a.m.
On Tue, Mar 19, 2013 at 03:52:40PM +0900, Fernando Luis Vázquez Cao wrote:
> Subject: [PATCH 2/2] man/send(2): document a long standing bug that can cause spurious EPERM errors
> 
> This bug has been known since early 2009 (the latest) and  discussed in
> netdev before:
> 
> http://marc.info/?l=linux-netdev&w=2&r=1&s=Possible+race+condition+in+conntracking+&q=b
> 
> It seems that a proper fix would be non trivial, so document the bug
> in the meantime.
>
> Reported-by: Hirotaka Sasaki <sasaki.hirotaka@lab.ntt.co.jp>
> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> ---
> 
> diff -urNp man-pages-3.50-orig/man2/send.2 man-pages-3.50/man2/send.2
> --- man-pages-3.50-orig/man2/send.2	2013-03-19 15:18:03.784306647 +0900
> +++ man-pages-3.50/man2/send.2	2013-03-19 15:30:40.788060426 +0900
> @@ -420,6 +420,11 @@ Linux may return
>  .B EPIPE
>  instead of
>  .BR ENOTCONN .
> +
> +Linux may return spurious
> +.B EPERM
> +errors when netfilter's conntrack module is loaded and two or more
> +UDP packets belonging to the same connection are processed in parallel.

The Connection tracking system may drop packets for different reasons
under rare circunstances, not only in this case.

I'd prefer if you only apply patch 1/2.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Fernando Luis Vazquez Cao - March 21, 2013, 5:07 a.m.
On 2013/03/19 19:12, Pablo Neira Ayuso wrote:
> On Tue, Mar 19, 2013 at 03:52:40PM +0900, Fernando Luis Vázquez Cao wrote:
>> Subject: [PATCH 2/2] man/send(2): document a long standing bug that can cause spurious EPERM errors
>>
>> This bug has been known since early 2009 (the latest) and  discussed in
>> netdev before:
>>
>> http://marc.info/?l=linux-netdev&w=2&r=1&s=Possible+race+condition+in+conntracking+&q=b
>>
>> It seems that a proper fix would be non trivial, so document the bug
>> in the meantime.
>>
>> Reported-by: Hirotaka Sasaki <sasaki.hirotaka@lab.ntt.co.jp>
>> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
>> ---
>>
>> diff -urNp man-pages-3.50-orig/man2/send.2 man-pages-3.50/man2/send.2
>> --- man-pages-3.50-orig/man2/send.2	2013-03-19 15:18:03.784306647 +0900
>> +++ man-pages-3.50/man2/send.2	2013-03-19 15:30:40.788060426 +0900
>> @@ -420,6 +420,11 @@ Linux may return
>>   .B EPIPE
>>   instead of
>>   .BR ENOTCONN .
>> +
>> +Linux may return spurious
>> +.B EPERM
>> +errors when netfilter's conntrack module is loaded and two or more
>> +UDP packets belonging to the same connection are processed in parallel.
> The Connection tracking system may drop packets for different reasons
> under rare circunstances, not only in this case.
> I'd prefer if you only apply patch 1/2.

I'd agree with you if we *silently* dropped packets in such
situations, but unfortunately that's not the case.

The problem is that sometimes we end up returning spurious EPERM
errors to user space. Applications may (and many actually do)
interpret EPERM as "an attempt was made to perform an operation
limited to processes with appropriate privileges or to the owner of a
file or other resource" and just bail out after seeing the first
EPERM; after all, if its cause is system policy-related there is no
point in retrying. Spurious EPERM errors would break such (perfectly
compliant) applications, so the least we can do is document them
properly.

Thanks,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff -urNp man-pages-3.50-orig/man2/send.2 man-pages-3.50/man2/send.2
--- man-pages-3.50-orig/man2/send.2	2013-03-19 15:18:03.784306647 +0900
+++ man-pages-3.50/man2/send.2	2013-03-19 15:30:40.788060426 +0900
@@ -420,6 +420,11 @@  Linux may return
 .B EPIPE
 instead of
 .BR ENOTCONN .
+
+Linux may return spurious
+.B EPERM
+errors when netfilter's conntrack module is loaded and two or more
+UDP packets belonging to the same connection are processed in parallel.
 .SH EXAMPLE
 An example of the use of
 .BR sendto ()