netdev - Re: [RFC] netlink: netlink_ack send a capped message in case of error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Aug 2015 21:19:21 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	pablo@...filter.org
Cc:	christophe.ricard@...il.com, sfeldma@...il.com, jbenc@...hat.com,
	sameo@...ux.intel.com, netdev@...r.kernel.org,
	christophe-h.ricard@...com
Subject: Re: [RFC] netlink: netlink_ack send a capped message in case of
 error

From: Pablo Neira Ayuso <pablo@...filter.org>
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 if the payload can be ignored in case of an error.
>> http://patchwork.ozlabs.org/patch/290976/
>> 
>> Do you think this one is acceptable ? I am not sure to understand David
>> last comment.
> 
> I think David suggests something like the (completely untested)
> attached patch.

Yes, echo'ing the entire message back in an ACK is really pointless.

Especially since if the user really is interested in noticing ACKs
it can very easily keep the original request around and match on
sequence number, as Pablo's patch's commit message suggests.

We're stuck with the current behavior by default, but we can add the
new ACK feature to deal with the issue in the long term.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html