he netlink message header is still included, so the user can guess from
the sequence number what is the message that has triggered the
acknowledgment.
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Christophe Ricard
---
include/uapi/linux/netlink.h | 1 +
net/netlink/af_netlink.
ed in netlink_unicast_kernel
in NETLINK_CB(skb).sk.
This information now prevent me to look up the socket for every ack.
Best Regards
Christophe
Christophe Ricard (1):
netlink: add NETLINK_CAP_ACK socket option
include/uapi/linux/netlink.h | 1 +
net/netlink/af_netlink.c | 27 -
he netlink message header is still included, so the user can guess from
the sequence number what is the message that has triggered the
acknowledgment.
Cc: sta...@vger.kernel.org
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Christophe Ricard
---
include/uapi/linux/netlink.h | 1 +
n
y ack.
Also i believe it could be good to make it reach stable as it is somehow a bug
fix.
Do you have any other comment ?
Best Regards
Christophe
Christophe Ricard (1):
netlink: add NETLINK_CAP_ACK socket option
include/uapi/linux/netlink.h | 1 +
net/netlink/af_netlink.c
Also i believe it could be good to make it reach stable as it is somehow a bug
fix.
What do you think ?
Best Regards
Christophe
Christophe Ricard (1):
netlink: add NETLINK_CAP_ACK socket option
include/uapi/linux/netlink.h | 1 +
net/netlink/af_netlink.c
he netlink message header is still included, so the user can guess from
the sequence number what is the message that has triggered the
acknowledgment.
Cc: sta...@vger.kernel.org
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Christophe Ricard
---
include/uapi/linux/netlink.h | 1 +
n
Miller wrote:
From: Pablo Neira Ayuso
Date: Mon, 24 Aug 2015 20:56:37 +0200
On Mon, Aug 24, 2015 at 10:08:22AM +0200, Christophe Ricard wrote:
Hi Scott,
I think i understand the potential limitation of my solution.
I saw something was proposed by Jiri Benc who pushed an additional flag to
tell
ernel.
I liked the netlink message cap approach.
Do you have any update ?
Do you think a netlink message cap in netlink_ack in case of an error is an
acceptable approach ?
Best Regards
Christophe
Christophe Ricard (1):
netlink: netlink_ack send a capped message in case of error
net/netlin
Currently, ACK in case of error contains a full copy of the originating
message. This can cause lost ACKs with large netlink messages, especially
after commit c05cdb1b864f ("netlink: allow large data transfers from
user-space").
Send back a capped message instead.
Signed-off-by: