Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5492593imm; Tue, 21 Aug 2018 12:40:38 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwzX6qYPweKx+FWVmMYS15QrP+w+fAAzAec2bu/KmhDCGatU1rC2nU/yTkbH3/wp/OIrQn4 X-Received: by 2002:a17:902:82c9:: with SMTP id u9-v6mr13670692plz.138.1534880438633; Tue, 21 Aug 2018 12:40:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534880438; cv=none; d=google.com; s=arc-20160816; b=vmf9Z/J+k/wVEil3Crtg9s13CXeBXE8ly6pkBFsPb8TPlZGSMi3Xby8Gk7bco3avOo 5rIcKOAKZtiHc/gfTs5xsKLQp9l1D0+c7u8zvOogNmPaehGpCUhQWZYn/D3Uz02UAw0g 7RIDLiuTqLxkdKZQsjJ41ekJNScNCPZI2NH5I3sGLmPQyxU/GHS549sBFsZ1K19a5g4x 9fKFrHXHmeuz0z2oOah6p0KwevMLd546erpTlJpUlpwPq+ACJ4Ygwp8TCfZDYo2huPsj HeBdcr9LLp5/U1ktVWSF7x+jO3YTmsXkP9Upy0LGie1Mk8PtEizFBCYtS3I96VWnnMJQ hkSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=NXBWClG3JsHHXwdOnKBHtenuVqe/4sz2Fuxi9sdQgWM=; b=qytfr/DCu2EcGyDNPUFLY5MY7qks473Xf1OsOxrHh7XSEskJkPJIc6T9pmQftuwTqb keiOb/zE8VR8fxBxShcI5MXcq09D6vk/oGT3VRscts3fu8PwpQLg9uKQAK/8urW1mygH pjtpiTvXbzEFFOl1YtqV72im6VnMVR0xd2UZGaHuLOAJiMLnv/fQeoeISPWmrxW6ZBOD OZ/cNL2PrDd+MkAThgZKXtznL1dIl2aJGD+0UEm6U5aPTwYZMa5JmYq0oCmQxENAfPBQ HOZPhKU2mnM96pqts1aGpVjPLCKZpJW0f8XfkTxmfr8f8n8ncohTlgmY7tGs3wQT+xSF lwxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f28-v6si14341919pfh.33.2018.08.21.12.40.17; Tue, 21 Aug 2018 12:40:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727590AbeHUW6k (ORCPT + 99 others); Tue, 21 Aug 2018 18:58:40 -0400 Received: from nautica.notk.org ([91.121.71.147]:44896 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726814AbeHUW6k (ORCPT ); Tue, 21 Aug 2018 18:58:40 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id C79A2C009; Tue, 21 Aug 2018 21:37:10 +0200 (CEST) Date: Tue, 21 Aug 2018 21:36:55 +0200 From: Dominique Martinet To: Doron Roberts-Kedes Cc: Tom Herbert , Dave Watson , "David S. Miller" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] strparser: remove any offset before parsing messages Message-ID: <20180821193655.GA15354@nautica> References: <1533854411-28184-1-git-send-email-asmadeus@codewreck.org> <1534855906-22870-1-git-send-email-asmadeus@codewreck.org> <20180821145321.GA44710@doronrk-mbp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180821145321.GA44710@doronrk-mbp> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Doron Roberts-Kedes wrote on Tue, Aug 21, 2018: > There are a few issues with this patch. First, it seems like you're > trying to fix bugs in users of strparser by changing an implementation > detail of strparser. Yes, that's why I have been writing since the original discussion that I do not like this fix, but as I said in the other thread and v0 of this patch I do not know how to tell the bpf function to start with an offset in the skb in e.g. kcm_parse_func_strparser I could add the pull in that function, but that feels a bit wrong on a separation level to me. > Second, this implementation change can add malloc's and copies where > there were none before. Yes I agree this is more than suboptimal for tls, I've also said that. > If strparser users do not handle non-zero offset properly, then that > doesn't motivate changing the implementation of strparser to copy > around data to accomodate those buggy users. > > Why not submit a patch that handles offset properly in the code you > pointed out? One of the solutions I had suggested was adding a flag at strparser setup time to only do that pull for users which cannot handle offset, but nobody seemed interested two weeks ago. I can still do that. That's still suboptimal, but I don't have any better idea. To properly fix the users, I'd really need help with how bpf works to even know if passing an offset would be possible in the first place, as I do not see how at this time. Thanks, -- Dominique Martinet