lkml.org 
[lkml]   [2014]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC][PATCH] af_key: return error when meet errors on sendmsg() syscall
From
From: Xufeng Zhang <xufeng.zhang@windriver.com>
Date: Fri, 9 May 2014 13:47:35 +0800

> Current implementation for pfkey_sendmsg() always return success
> no matter whether or not error happens during this syscall,
> this is incompatible with the general send()/sendmsg() API:
> man send
> RETURN VALUE
> On success, these calls return the number of characters sent.
> On error, -1 is returned, and errno is set appropriately.
>
> One side effect this problem introduces is that we can't determine
> when to resend the message when the previous send() fails because
> it was interrupted by signals.
> We detect such a problem when racoon is sending SADBADD message to
> add SAD entry in the kernel, but sometimes kernel is responding with
> "Interrupted system call"(-EINTR) error.
>
> Check the send implementation of strongswan, it has below logic:
> pfkey_send_socket()
> {
> ...
> while (TRUE)
> {
> len = send(socket, in, in_len, 0);
>
> if (len != in_len)
> {
> case EINTR:
> /* interrupted, try again */
> continue;
> ...
> }
> }
> ...
> }
> So it makes sense to return errors for send() syscall.
>
> Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>

I disagree.

If pfkey_error() is successful, the error will be reported in the AF_KEY
message that is broadcast, there is no reason for sendmsg to return an
error. The message was sucessfully sent, there was no problem with it's
passage into the AF_KEY layer.

Like netlink, operational responses come in packets, not error codes.

However, if pfkey_error() fails, we must do pass back the original
error code because it's a last ditch effort to prevent information
from being lost.

That's why 'err' must be preserved when pfkey_error() returns zero.


\
 
 \ /
  Last update: 2014-05-12 08:01    [W:0.042 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site