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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CB2E2C433F5 for ; Fri, 8 Apr 2022 23:55:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:References:Message-Id:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ybBdxzfCdglg2QoNPbYHXgRYAQqnpAAo5tVFtaOLnZs=; b=ma+DXJFdhdR4/S rk5H+K9+b4gxD9e1tvishmlhcxh33rj++nFrkm1cJ/jNUqb385on06y7JY7dBZJx7bsIgmw+CW269 B1IUT1ZiO/P5Rtgx90+LryYNbP0B/ll0S0b3wzHdkBCi1VeOSahuqzhpF6c6IpLKD7vD8IPJoBEQy 3ztRObxY+dj9eG1aoo2AinpQL8itxRHAuGkHn1udxVGZFARxNqlls4CZ2Tufb7wW3fEu6H9WoEZrW 5yqeoSVMd6uUdZU1o+RnT/a4k/Khf0MrIm+FDhpOCXGmxbzvZtbFWXk4Z0JTys5hXRXg9dS6MosZC Jb7cQvQQ+IGhSuDv0PDw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncyQp-001VjR-G3; Fri, 08 Apr 2022 23:54:23 +0000 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncyQl-001Vii-GE for linux-arm-kernel@lists.infradead.org; Fri, 08 Apr 2022 23:54:21 +0000 Received: by mail-wm1-x32e.google.com with SMTP id h16so6503854wmd.0 for ; Fri, 08 Apr 2022 16:54:18 -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=Da8jxptMWvJKwTv2ackMcddECW6ahDnncCnxasvF2Q7QYE3OHnMqVDHo1cD2c/nIQ1 HgLlNGJ+HslgWqHqe/aP+jqoa8TuA5uKxO0jLv3cm8zBd2tauAYqlDNpVDuOz0JXW+Xg VAyA4s44j8EUFiIpJqaTYpWmnjGFDs8mpr/PXBHLtvrVuM79tKjMZNIDnec2QH1mlGyG SUkDBLgTzkJCR18p5uIc8sEeN0E6Kv6wwcRrUNzKjkjQOOXnBcrldBmeCvJfPTH74mmX hU1xES+YnfIds7jz02egd4cFj2FooUdSSUFI4sOooAsXqXkg9sAEebHK6NrFlCQ4DQ4j u0QQ== X-Gm-Message-State: AOAM533utbKnmX0Ksj/15Ycpi4VgBTFmJHSCTfAEK8aeyuyWXd8ved3I ILWWvOcJPonUSs6QZjZy07Q= 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) 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." 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) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220408_165419_606273_98B57189 X-CRM114-Status: GOOD ( 45.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Vladimir, > On 8. Apr 2022, at 13:41, Vladimir Oltean wrote: > > Hello Jakob, > > 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]. >> >> 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. >> >> Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] >> Signed-off-by: Jakob Koschel >> --- >> drivers/net/dsa/sja1105/sja1105_vl.c | 14 +++++++++----- >> 1 file changed, 9 insertions(+), 5 deletions(-) >> >> 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 = NULL, *iter; >> >> - list_for_each_entry(p, &gating_cfg->entries, list) { >> - if (p->interval == e->interval) { >> + list_for_each_entry(iter, &gating_cfg->entries, list) { >> + if (iter->interval == e->interval) { >> NL_SET_ERR_MSG_MOD(extack, >> "Gate conflict"); >> rc = -EBUSY; >> goto err; >> } >> >> - if (e->interval < p->interval) >> + if (e->interval < iter->interval) { >> + p = 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); >> } >> >> gating_cfg->num_entries++; >> -- >> 2.25.1 >> > > 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. > > -----------------------------[ cut here ]----------------------------- > From 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() > > 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". > > 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. > > 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. > > 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. > > 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(). > > Signed-off-by: Vladimir Oltean > --- > drivers/net/dsa/sja1105/sja1105_vl.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > 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; > > - list_for_each_entry(p, &gating_cfg->entries, list) { > + p = list_entry(pos, struct sja1105_gate_entry, list); > if (p->interval == 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. > } > > gating_cfg->num_entries++; > -----------------------------[ cut here ]----------------------------- [1] https://lore.kernel.org/linux-kernel/20220407102900.3086255-12-jakobkoschel@gmail.com/ Jakob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel