From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D604C433F5 for ; Fri, 8 Apr 2022 23:54:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240108AbiDHX42 (ORCPT ); Fri, 8 Apr 2022 19:56:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230205AbiDHX40 (ORCPT ); Fri, 8 Apr 2022 19:56:26 -0400 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 178FDE21; Fri, 8 Apr 2022 16:54:19 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id p189so6473245wmp.3; Fri, 08 Apr 2022 16:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n5UPNQEDai1gUFUdN9sucmKpzqqEUym2Bv+35OpgTmc=; b=pG1F0MrmF0MxsheTCnU5KlnL7Fq3an1SzIoDIJWlvZTcNPwAejlsTxkr/aITjxttuN 4t9qOz+HWVuW9mjRCjV1vM02Lp8cdd8MquH/W9I+QdExZFr0zL5FS2Nb0kvl0UlWCFVK NgbMRkfNJM8aq4eRSV2Ai4D/koQFTxUsZyeBDHnWTq2iI4ygMQjDD0DiM26d3Eg9r9fy whdlpXipwUciya55rwa+AMb/cR0AFXTNn9znvHshZnrvO2q7Hhgb3ypRlYjgYvC2QDHR tvaZ+Czt68GGIRMZ42zUl+nz0t57NIJTSXJjhID/BEsFgMymPAqNrdXgUaadY0zKbhfr 5DQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n5UPNQEDai1gUFUdN9sucmKpzqqEUym2Bv+35OpgTmc=; b=wqZVqkg+tRgqcKqW6VxL7qebjlw7bN7VSILHHzoDAWT6JOSyWCmG1Pfqrue6F84e9d Wf930uH4I2jPtvkZQJUblyLYEqCw+Xri8PNmcUkH6UFwdrYGQgFxechZyo1H0lWb9MZJ cObdGTL8Cwh7JvWxUv8hSI5cvXv8/N3aGEXim+i1NTpyQbVzOOmPTs8Qe0bn7ILXVrEW sPXh34yb5lyYa7IjTxnEAINAIOg1KcQ3xZXX0LgAvXjwGjAJ6PNapOs6b7uwXmpxk0oh PuVW7N8W/azJooFUKzhPcpg1nMcpYVu3BitjzQUBX6cipi4/3aZgwwoOxTW2UlYlG8Mh WIhw== X-Gm-Message-State: AOAM532b3NbAxxexktrI8/feHraKLsEeKv6NfixZdYb1KirBdoHORkiy kB3AC05Mor4I6F0l8ACvTtU= X-Google-Smtp-Source: ABdhPJzYPe2XZp3HIcQrurMuTy8KVeKXLKzzK2Euy2m/YilBtUjHiW3sSWpaiPkVrXseuI50+m05lg== X-Received: by 2002:a05:600c:190e:b0:38c:b1ea:f4ac with SMTP id j14-20020a05600c190e00b0038cb1eaf4acmr18783624wmq.70.1649462057538; Fri, 08 Apr 2022 16:54:17 -0700 (PDT) Received: from smtpclient.apple ([185.238.38.242]) by smtp.gmail.com with ESMTPSA id p16-20020a5d6390000000b00203ffebddf3sm26542577wru.99.2022.04.08.16.54.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Apr 2022 16:54:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: [PATCH net-next 02/15] net: dsa: sja1105: Remove usage of iterator for list_add() after loop From: Jakob Koschel In-Reply-To: <20220408114120.tvf2lxvhfqbnrlml@skbuf> Date: Sat, 9 Apr 2022 01:54:13 +0200 Cc: "David S. Miller" , Jakub Kicinski , Paolo Abeni , Andrew Lunn , Vivien Didelot , Florian Fainelli , Lars Povlsen , Steen Hegelund , UNGLinuxDriver@microchip.com, Ariel Elior , Manish Chopra , Edward Cree , Martin Habets , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Jiri Pirko , Casper Andersson , Bjarni Jonasson , Colin Ian King , Michael Walle , Christophe JAILLET , Arnd Bergmann , Eric Dumazet , Di Zhu , Xu Wang , Netdev , LKML , Linux ARM , linuxppc-dev , Mike Rapoport , Brian Johannesmeyer , Cristiano Giuffrida , "Bos, H.J." Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220407102900.3086255-1-jakobkoschel@gmail.com> <20220407102900.3086255-3-jakobkoschel@gmail.com> <20220408114120.tvf2lxvhfqbnrlml@skbuf> To: Vladimir Oltean X-Mailer: Apple Mail (2.3696.80.82.1.1) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Vladimir, > On 8. Apr 2022, at 13:41, Vladimir Oltean wrote: >=20 > Hello Jakob, >=20 > On Thu, Apr 07, 2022 at 12:28:47PM +0200, Jakob Koschel wrote: >> In preparation to limit the scope of a list iterator to the list >> traversal loop, use a dedicated pointer to point to the found element = [1]. >>=20 >> Before, the code implicitly used the head when no element was found >> when using &pos->list. Since the new variable is only set if an >> element was found, the list_add() is performed within the loop >> and only done after the loop if it is done on the list head directly. >>=20 >> Link: = https://lore.kernel.org/all/CAHk-=3DwgRr_D8CB-D9Kg-c=3DEHreAsk5SqXPwr9Y7k9= sA6cWXJ6w@mail.gmail.com/ [1] >> Signed-off-by: Jakob Koschel >> --- >> drivers/net/dsa/sja1105/sja1105_vl.c | 14 +++++++++----- >> 1 file changed, 9 insertions(+), 5 deletions(-) >>=20 >> diff --git a/drivers/net/dsa/sja1105/sja1105_vl.c = b/drivers/net/dsa/sja1105/sja1105_vl.c >> index b7e95d60a6e4..cfcae4d19eef 100644 >> --- a/drivers/net/dsa/sja1105/sja1105_vl.c >> +++ b/drivers/net/dsa/sja1105/sja1105_vl.c >> @@ -27,20 +27,24 @@ static int sja1105_insert_gate_entry(struct = sja1105_gating_config *gating_cfg, >> if (list_empty(&gating_cfg->entries)) { >> list_add(&e->list, &gating_cfg->entries); >> } else { >> - struct sja1105_gate_entry *p; >> + struct sja1105_gate_entry *p =3D NULL, *iter; >>=20 >> - list_for_each_entry(p, &gating_cfg->entries, list) { >> - if (p->interval =3D=3D e->interval) { >> + list_for_each_entry(iter, &gating_cfg->entries, list) { >> + if (iter->interval =3D=3D e->interval) { >> NL_SET_ERR_MSG_MOD(extack, >> "Gate conflict"); >> rc =3D -EBUSY; >> goto err; >> } >>=20 >> - if (e->interval < p->interval) >> + if (e->interval < iter->interval) { >> + p =3D iter; >> + list_add(&e->list, iter->list.prev); >> break; >> + } >> } >> - list_add(&e->list, p->list.prev); >> + if (!p) >> + list_add(&e->list, gating_cfg->entries.prev); >> } >>=20 >> gating_cfg->num_entries++; >> --=20 >> 2.25.1 >>=20 >=20 > I apologize in advance if I've misinterpreted the end goal of your = patch. > I do have a vague suspicion I understand what you're trying to = achieve, > and in that case, would you mind using this patch instead of yours? I think you are very much spot on! > I think it still preserves the intention of the code in a clean = manner. >=20 > -----------------------------[ cut here ]----------------------------- > =46rom 7aed740750d1bc3bff6e85fd33298f5905bb4e01 Mon Sep 17 00:00:00 = 2001 > From: Vladimir Oltean > Date: Fri, 8 Apr 2022 13:55:14 +0300 > Subject: [PATCH] net: dsa: sja1105: avoid use of type-confused pointer = in > sja1105_insert_gate_entry() >=20 > It appears that list_for_each_entry() leaks a type-confused pointer = when > the iteration loop ends with no early break, since "*p" will no longer > point to a "struct sja1105_gate_entry", but rather to some memory in > front of "gating_cfg->entries". >=20 > This isn't actually a problem here, because if the element we insert = has > the highest interval, therefore we never exit the loop early, = "p->list" > (which is all that we use outside the loop) will in fact point to > "gating_cfg->entries" even though "p" itself is invalid. >=20 > Nonetheless, there are preparations to increase the safety of > list_for_each_entry() by making it impossible to use the encapsulating > structure of the iterator element outside the loop. So something needs > to change here before those preparations go in, even though this > constitutes legitimate use. >=20 > Make it clear that we are not dereferencing members of the = encapsulating > "struct sja1105_gate_entry" outside the loop, by using the regular > list_for_each() iterator, and dereferencing the struct = sja1105_gate_entry > only within the loop. >=20 > With list_for_each(), the iterator element at the end of the loop does > have a sane value in all cases, and we can just use that as the "head" > argument of list_add(). >=20 > Signed-off-by: Vladimir Oltean > --- > drivers/net/dsa/sja1105/sja1105_vl.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) >=20 > diff --git a/drivers/net/dsa/sja1105/sja1105_vl.c = b/drivers/net/dsa/sja1105/sja1105_vl.c > index c0e45b393fde..fe93c80fe5ef 100644 > --- a/drivers/net/dsa/sja1105/sja1105_vl.c > +++ b/drivers/net/dsa/sja1105/sja1105_vl.c > @@ -27,9 +27,15 @@ static int sja1105_insert_gate_entry(struct = sja1105_gating_config *gating_cfg, > if (list_empty(&gating_cfg->entries)) { > list_add(&e->list, &gating_cfg->entries); > } else { > - struct sja1105_gate_entry *p; > + struct list_head *pos; > + > + /* We cannot safely use list_for_each_entry() > + * because we dereference "pos" after the loop > + */ > + list_for_each(pos, &gating_cfg->entries) { > + struct sja1105_gate_entry *p; >=20 > - list_for_each_entry(p, &gating_cfg->entries, list) { > + p =3D list_entry(pos, struct sja1105_gate_entry, = list); > if (p->interval =3D=3D e->interval) { > NL_SET_ERR_MSG_MOD(extack, > "Gate conflict"); > @@ -40,7 +46,7 @@ static int sja1105_insert_gate_entry(struct = sja1105_gating_config *gating_cfg, > if (e->interval < p->interval) > break; > } > - list_add(&e->list, p->list.prev); > + list_add(&e->list, pos->prev); I was actually considering doing it this way before but wasn't sure if = this would be preferred. I've done something like this in [1] and it does turn out quite well. I'll integrate this in the v2 series. Thanks for the suggestion. > } >=20 > gating_cfg->num_entries++; > -----------------------------[ cut here ]----------------------------- [1] = https://lore.kernel.org/linux-kernel/20220407102900.3086255-12-jakobkosche= l@gmail.com/ Jakob=