Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp748552ybx; Fri, 1 Nov 2019 10:34:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqxryHTEfOtN/NwcG54CQU7seRxHfaPrN5VMHzAX/PlF4POd8LaYRrs4/kMydDtru+ogvqxy X-Received: by 2002:aa7:c582:: with SMTP id g2mr13908808edq.25.1572629681742; Fri, 01 Nov 2019 10:34:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572629681; cv=none; d=google.com; s=arc-20160816; b=HUFh/pqf7UZLmM7Rj8EFAFiYb/G4ZBARchmxbEyXvB2vhI9UKWOV2hOzZyFXKAkYb+ GleqnntrB9q2uVXQEjpEkLV4Q6DrC/3cUkAb5JJJixx06cDevIFfNrFBYnRQgyKkhhU5 REBdhwQK9tsLbveSBMrVvj8inwdNCn+dUvyRBzEU6LUCEbi6D5gbNNUoO2GErDj2PkIq GayGdc/AwgDx7APYV6Dx/yMPql2BSIeeobQ0HHdGDIvqEjBEcilNezZpgPfARna5EENK KPkJgFXK9XNZR092F22V4G1BzAMYZQRSA/+RkWPbnA1nIteeLYh5GejEKrhcwUU5z3xa wumg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=vdJS5wHCvpSQMFm2jdDQ61c5eY7rBNbjJW+8uyG0GRg=; b=WtHse2/rQ2Z7+YM4/1fIEzH2nEu04JAFVrL5NlOxZMHy1JfIxKcNmkC5zpLCNhK9TC a1xoSLFg77j1fiTnGo9EE6GEEou9Mbgb4mySBcjrWhIxcwdQyT5oHJZlU48BQUzCK7ot hWZOrA8IATB704vM0vOvhowrcnLbx/u99E5itfKAtA0ds9rjZRKptALzCWd4BycN9FQ1 lJSPm+iCLgTRmUE1uSP5+CP7yXD2kE3TMzYhgUzK5gtzDB+ZIfZJcj87E3/RgMbJCv+V QLIGSdjVk246LtxwVU82eX0ANMnMQo5nKFqkZ8nrn0g4JqDQ9QqAGPej/+K+ZGD9y+du 5AYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@netronome-com.20150623.gappssmtp.com header.s=20150623 header.b=OYhrNrhu; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-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 w57si830789eda.78.2019.11.01.10.34.08; Fri, 01 Nov 2019 10:34:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@netronome-com.20150623.gappssmtp.com header.s=20150623 header.b=OYhrNrhu; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726866AbfKARWy (ORCPT + 99 others); Fri, 1 Nov 2019 13:22:54 -0400 Received: from mail-lf1-f66.google.com ([209.85.167.66]:38404 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727600AbfKARWy (ORCPT ); Fri, 1 Nov 2019 13:22:54 -0400 Received: by mail-lf1-f66.google.com with SMTP id q28so7769486lfa.5 for ; Fri, 01 Nov 2019 10:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=vdJS5wHCvpSQMFm2jdDQ61c5eY7rBNbjJW+8uyG0GRg=; b=OYhrNrhuXsL/quLsVKXrps3cBpJHq+KilIJjfscIIvLeZFpDBdSoX5Q5sPW6eptPNi i+9NTi0uzAsUEkZpX166hI0jqCIMfUC1/Dethrk7AQ4MffqSak83kdWTTcyrvjA23iLf VHfL8XeJ2hsrhaKJfEQDlO5doohJw1DsFhJwSgSSs1/H3Mp7e0ORiq8fT8zQBT6jBvOL ZLP2Rk3odmj1W6ChZQ8tPGvlT7D7ouKOMjBygRdn+r/7EJVGBofXm4i/np/bNknJA+Ph nj4G7+4aUuYtW6CtSVVT/O2NcowP9Ar4uo8F24ar5BTxuWkeviBzEzcmiqXyUqZScnTl tK2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=vdJS5wHCvpSQMFm2jdDQ61c5eY7rBNbjJW+8uyG0GRg=; b=L4pAK6ck4AZSYWhjrVgKIo2Lf2uYExkvVXo2uX3x4xyVt6wTxH/pTp5Wj//ToFBq/+ oxCTYZu4joWJyiouHMmaLXt5MYgYxFCkLBCsDzg9McJQNMNVYwE4MOs49c3kiYdEJYGg ha0VMErCsOck8sEJhQM+QUNSNt+R/V9LP8WVdf4uEBObtvUFfPaA4o8C2fQWira0SJ1t yPnHCEvkZMBKzFF+3YE2+klxbRUf4mGixYLmKC169FP1q1UWjATbBEYPjzAomx9QVgKS HYvW6eOUsje/HQDO3FQDEUS8QLLwyyggTfFPTbfAbSgr2SorKv2Qot7uCOkD/DscGH6w olAA== X-Gm-Message-State: APjAAAXnwwEB4fEwap7l55FigIaGV0ZpUwk4uPfNxNjL+1rizznl2o1z 3lXvRGxt1I/JFi/x1vboRSBdVg== X-Received: by 2002:a19:5e53:: with SMTP id z19mr7553066lfi.111.1572628969408; Fri, 01 Nov 2019 10:22:49 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id q15sm2780830lfb.84.2019.11.01.10.22.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Nov 2019 10:22:49 -0700 (PDT) Date: Fri, 1 Nov 2019 10:22:38 -0700 From: Jakub Kicinski To: John Fastabend Cc: davem@davemloft.net, netdev@vger.kernel.org, oss-drivers@netronome.com, borisp@mellanox.com, aviadye@mellanox.com, daniel@iogearbox.net, syzbot+f8495bff23a879a6d0bd@syzkaller.appspotmail.com, syzbot+6f50c99e8f6194bf363f@syzkaller.appspotmail.com, Eric Biggers , herbert@gondor.apana.org.au, glider@google.com, linux-crypto@vger.kernel.org Subject: Re: [oss-drivers] Re: [PATCH net] net/tls: fix sk_msg trim on fallback to copy mode Message-ID: <20191101102238.7f56cb84@cakuba.netronome.com> In-Reply-To: <5dbc48ac3a8cc_e4e2b12b10265b8a1@john-XPS-13-9370.notmuch> References: <20191030160542.30295-1-jakub.kicinski@netronome.com> <5dbb5ac1c208d_4c722b0ec06125c0cc@john-XPS-13-9370.notmuch> <20191031152444.773c183b@cakuba.netronome.com> <5dbbb83d61d0c_46342ae580f765bc78@john-XPS-13-9370.notmuch> <20191031215444.68a12dfe@cakuba.netronome.com> <5dbc48ac3a8cc_e4e2b12b10265b8a1@john-XPS-13-9370.notmuch> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, 01 Nov 2019 08:01:00 -0700, John Fastabend wrote: > Jakub Kicinski wrote: > > I will look in depth tomorrow as well, the full/empty cases are a > > little tricky to fold into general logic. > > > > I came up with this before I got distracted Halloweening :) > > Same here. Looking at the two cases from above. > > if (msg->sg.start < msg->sg.end && > i < msg->sg.curr) { // i <= msg->sg.curr > msg->sg.curr = i; > msg->sg.copybreak = msg->sg.data[i].length; > } > > If we happen to trim the entire msg so size=0 then i==start > which should mean i < msg->sg.curr unless msg->sg.curr = msg->sg.start > so we should just use <=. In the second case. > > else if (msg->sg.end < msg->sg.start && > (i < msg->sg.curr || i > msg->sg.start)) { // i <= msg->sg.curr > msg->sg.curr = i; > msg->sg.copybreak = msg->sg.data[i].length; > } > > If we trim the entire message here i == sg.start again. And same > thing use <= and we should catch case sg.tart = sg.curr. > > In the full case we didn't trim anything so we shouldn't do any > manipulating of curr or copybreak. Hm, don't we need to potentially move the copybreak back a little? That's why I added this: if (msg->sg.curr == i && msg->sg.copybreak > msg->sg.data[i].length) msg->sg.copybreak = msg->sg.data[i].length; To make sure that if we trimmed "a little bit" of the last SG but didn't actually consume it the copybreak doesn't point after the length. But perhaps that's not needed since sk_msg_memcopy_from_iter() special cases the copybreak > length, anyway? > > diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h > > index e4b3fb4bb77c..ce7055259877 100644 > > --- a/include/linux/skmsg.h > > +++ b/include/linux/skmsg.h > > @@ -139,6 +139,11 @@ static inline void sk_msg_apply_bytes(struct sk_psock *psock, u32 bytes) > > } > > } > > > > +static inline u32 sk_msg_iter_dist(u32 start, u32 end) > > +{ > > + return end >= start ? end - start : end + (MAX_MSG_FRAGS - start); > > +} > > + > > #define sk_msg_iter_var_prev(var) \ > > do { \ > > if (var == 0) \ > > @@ -198,9 +203,7 @@ static inline u32 sk_msg_elem_used(const struct sk_msg *msg) > > if (sk_msg_full(msg)) > > return MAX_MSG_FRAGS; > > > > - return msg->sg.end >= msg->sg.start ? > > - msg->sg.end - msg->sg.start : > > - msg->sg.end + (MAX_MSG_FRAGS - msg->sg.start); > > + return sk_msg_iter_dist(msg->sg.start, msg->sg.end); > > } > > > > static inline struct scatterlist *sk_msg_elem(struct sk_msg *msg, int which) > > diff --git a/net/core/skmsg.c b/net/core/skmsg.c > > index cf390e0aa73d..f6b4a70bafa9 100644 > > --- a/net/core/skmsg.c > > +++ b/net/core/skmsg.c > > @@ -270,18 +270,26 @@ void sk_msg_trim(struct sock *sk, struct sk_msg *msg, int len) > > > > msg->sg.data[i].length -= trim; > > sk_mem_uncharge(sk, trim); > > + if (msg->sg.curr == i && msg->sg.copybreak > msg->sg.data[i].length) > > + msg->sg.copybreak = msg->sg.data[i].length; > > out: > > + sk_msg_iter_var_next(i); > > + msg->sg.end = i; > > + > > /* If we trim data before curr pointer update copybreak and current > > * so that any future copy operations start at new copy location. > > * However trimed data that has not yet been used in a copy op > > * does not require an update. > > */ > > - if (msg->sg.curr >= i) { > > + if (!msg->sg.size) { > > I do think its a bit nicer if we don't special case the size = 0 case. If > we get here and i != start then we would have extra bytes in the sg > items between the items (i, end) and nonzero size. If i == start then the > we sg.size = 0. I don't think there are any other cases. On an empty message i ended up before start, so we'd have to take the wrapping into account, no? I couldn't come up with a way to handle that, and the full case cleanly :S Perhaps there are some constraints on the geometry that simplify it. > > + msg->sg.curr = 0; Ugh, this should say msg->sg.start, not 0. > > + msg->sg.copybreak = 0; > > + } else if (sk_msg_iter_dist(msg->sg.start, msg->sg.curr) > > > + sk_msg_iter_dist(msg->sg.end, msg->sg.curr)) { > > + sk_msg_iter_var_prev(i); > > I suspect with small update to dist logic the special case could also > be dropped here. But I have a preference for my example above at the > moment. Just getting coffee now so will think on it though. Oka, I like the dist thing, I thought that's where you were going in your first email :) I need to do some more admin, and then I'll probably write a unit test for this code (use space version).. So we can test either patch with it. > FWIW I've not compiled my example. > > > msg->sg.curr = i; > > msg->sg.copybreak = msg->sg.data[i].length; > > } > > - sk_msg_iter_var_next(i); > > - msg->sg.end = i; > > } > > EXPORT_SYMBOL_GPL(sk_msg_trim);