Received: by 2002:a05:7412:f690:b0:e2:908c:2ebd with SMTP id ej16csp1031893rdb; Fri, 20 Oct 2023 06:46:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG5tg7I3WX9sXj2YILvmotIvxlZ0xgWbuJLA7SDoHaw4t/QbMXw7RFzMDjASNB3HXdKbh5/ X-Received: by 2002:a17:903:280b:b0:1ca:86b:7ed3 with SMTP id kp11-20020a170903280b00b001ca086b7ed3mr1546804plb.40.1697809565686; Fri, 20 Oct 2023 06:46:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697809565; cv=none; d=google.com; s=arc-20160816; b=1FaLJt4WskGo1fadx6V6P5J89rBr4bRa2dstcOcB+x9zYzrVJfoys4/zRpF0rgV9b4 E7NprwC4gBm3mYdtivYOdzQuo+sEcs5Cf+RS51P+Ha+xCdjGw+L4lSASILscGGx5YF4P nE1FihyOj6npGLs3yC7YhatkUVHOgVEyuYK4QAokuD1vMsGNcKRWFk2ZnVd/7QU3gPnC gukA4xHp1Yupo1wmLZMAJ9nM8zjb85IQF7twV+xL2d9yXolCCWcPfu9CZb+vpWJ3C3nu GdMNjE9J/f7384TN7y88YM9r+KwJwNdPw7wRImNDl4f95pphPYFeAu6A7M+qnAtW4mbR uSEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=XQitUfufBc4bgthK7wiCC1Z/fartvsGRq9x6W1VI+Us=; fh=dNoIFLqAY4rWwjCWkzjNkgcdA/GCTOjphMnrli7MeLc=; b=Ili6LvTfIRHpoNtySG9MCGYuFDORW/JMNAkgKJHmLjduno21aefh1s8SVkcWVdxKjB eNNkqKrDehBSasOA1fNpeahSqEf+3Ny+6G8BzNBAqwaN0sWCSHkuWlo7f4kG21xAVsYv d7aU+XhZNRHeRjDdtA4DKmLffD47sCAh16I9z520A69g1ZGBih/bUSQvimLn8pcjQkRX PQ6fr8eobHzu3cTNSpldfWRUAk4JGdqQ8snnTMiE7g9Na8cQrUUPPC78WcwFfYLLJr+/ NX5M6mG+rUBUM6QIGh501rM9HywxTGWO7eh4CVqWKEOZcibWwFI/rhrYSE73H9YnXP2y 6LcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id y6-20020a170902ed4600b001bc02b730f3si1684790plb.242.2023.10.20.06.46.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 06:46:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 4ACBC8303B3A; Fri, 20 Oct 2023 06:46:03 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377466AbjJTNpz (ORCPT + 99 others); Fri, 20 Oct 2023 09:45:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377372AbjJTNpx (ORCPT ); Fri, 20 Oct 2023 09:45:53 -0400 Received: from us-smtp-delivery-44.mimecast.com (us-smtp-delivery-44.mimecast.com [205.139.111.44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C387E1BF for ; Fri, 20 Oct 2023 06:45:50 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-692-GTqKNN5rMLCOyLdXtv-uwQ-1; Fri, 20 Oct 2023 09:45:34 -0400 X-MC-Unique: GTqKNN5rMLCOyLdXtv-uwQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 97F11102020A; Fri, 20 Oct 2023 13:45:29 +0000 (UTC) Received: from hog (unknown [10.39.192.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DEF032026D4C; Fri, 20 Oct 2023 13:45:27 +0000 (UTC) Date: Fri, 20 Oct 2023 15:45:26 +0200 From: Sabrina Dubroca To: "Radu Pirea (NXP OSS)" Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk, richardcochran@gmail.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, sebastian.tobuschat@oss.nxp.com Subject: Re: [PATCH net-next v7 3/7] net: macsec: revert the MAC address if mdo_upd_secy fails Message-ID: References: <20231019120209.290480-1-radu-nicolae.pirea@oss.nxp.com> <20231019120209.290480-4-radu-nicolae.pirea@oss.nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20231019120209.290480-4-radu-nicolae.pirea@oss.nxp.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Fri, 20 Oct 2023 06:46:03 -0700 (PDT) 2023-10-19, 15:02:05 +0300, Radu Pirea (NXP OSS) wrote: > /* If h/w offloading is available, propagate to the device */ > - if (macsec_is_offloaded(macsec)) { > + if (offloaded) { > const struct macsec_ops *ops; > struct macsec_context ctx; > > ops = macsec_get_ops(macsec, &ctx); > - if (ops) { > - ctx.secy = &macsec->secy; > - macsec_offload(ops->mdo_upd_secy, &ctx); > + if (!ops) { > + err = -EINVAL; For consistency with other places where macsec_get_ops fails, this should probably be -EOPNOTSUPP. I'm not opposed to this change, but I'm not sure how it's related to the missing rollback issue. Can you explain that a bit? > + goto restore_old_addr; > } > + > + ctx.secy = &macsec->secy; > + err = macsec_offload(ops->mdo_upd_secy, &ctx); > + if (err) > + goto restore_old_addr; > } > > return 0; > + > +restore_old_addr: > + if (dev->flags & IFF_UP) { > + int err; [This bit confused me quite a bit, seeing the declaration and the "return err" out of this block] > + err = macsec_dev_uc_update(dev, old_addr); > + if (err) > + return err; If we can avoid it, we should try to have a rollback path without any possible failures, otherwise we'll leave things in a broken state (in this case, telling the user that the MAC address change failed, but leaving the new address set on the macsec device). Paolo suggested to postpone the dev_uc_del until after the offload code, so we'd end up with something like this [completely untested]: if (dev->flags & IFF_UP) { err = dev_uc_add(real_dev, addr->sa_data); if (err < 0) return err; } ether_addr_copy(old_addr, dev->dev_addr); eth_hw_addr_set(dev, addr->sa_data); /* If h/w offloading is available, propagate to the device */ if (macsec_is_offloaded(macsec)) { // ... } if (dev->flags & IFF_UP) dev_uc_del(real_dev, old_addr); return 0; restore_old_addr: if (dev->flags & IFF_UP) dev_uc_del(real_dev, addr->sa_data); eth_hw_addr_set(dev, old_addr); return err; Install both UC addresses, then remove the one we don't need. -- Sabrina