From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH 0/3] Updates to segmentation-offloads.txt Date: Wed, 14 Feb 2018 14:54:47 -0500 (EST) Message-ID: <20180214.145447.509783691173905296.davem@davemloft.net> References: <20180214070533.28377-1-dja@axtens.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org To: dja@axtens.net Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:58020 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030255AbeBNTyt (ORCPT ); Wed, 14 Feb 2018 14:54:49 -0500 In-Reply-To: <20180214070533.28377-1-dja@axtens.net> Sender: netdev-owner@vger.kernel.org List-ID: From: Daniel Axtens Date: Wed, 14 Feb 2018 18:05:30 +1100 > I've been trying to wrap my head around GSO for a while now. This is a > set of small changes to the docs that would probably have been helpful > when I was starting out. > > I realise that GSO_DODGY is still a notable omission - I'm hesitant to > write too much on it just yet as I don't understand it well and I > think it's in the process of changing. Series applied, thanks for doing this. Generally speaking, the "dodgy" attributes mean that the packet came from an "untrusted" source such as a virtualization guest or similar. When set, it tells us that we cannot trust the GSO attributes of the packet nor the geometry of the SKB. For example, a malicious guest could sent us a TCP packet, yet set SCTP GSO attributes. It largely means that we have to perform extra verifications and sanity checking that would not be necessary for in-kernel generated GSO packets which we could assume are properly formed. Thanks.