From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f171.google.com (mail-dy1-f171.google.com [74.125.82.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C590261B8D for ; Wed, 18 Feb 2026 01:10:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771377039; cv=none; b=dcDeNRIo1zeaOT2enaw6eL5V2RRQwVkNWQO+EyU5Xkxh6wBsmPizvA+V99IdtT71p+qffiBDnSMeeSvwjhH61gZEdWjdtgohV4CdpNcR1FQgDvzrAgNnjpg4UAoLk4OSHYckgvSV8eJpsz6sBXW34pk6WylXsKxNyDO6lVoi86w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771377039; c=relaxed/simple; bh=AgxuI5ccrgLWNJbs+jIpzeLqmqALpfjDDErTO+AEH3c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IIzm2bVhNSEMM6rzhaN4ygitqHyf4h6LS5+0HEJTRj9/maocb9sDuw/zh7xA5T+OY3Py4OvRMDvYMrGB/DZNZhvQYKYK7dKhwLq+zVuod4DEB2wQno1Up2dsYygh+83VtZGC7O8pp2vwCboIpWz1vVD1PjVZMTytT5XWC1tDDhM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=S57BOpYP; arc=none smtp.client-ip=74.125.82.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S57BOpYP" Received: by mail-dy1-f171.google.com with SMTP id 5a478bee46e88-2baa098ffc6so4080083eec.0 for ; Tue, 17 Feb 2026 17:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771377038; x=1771981838; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=HaLulxvPHYvGz4Xb3W5g68oYo3k4BkyuzN9QRj/2IQU=; b=S57BOpYPm0CYPfJUMrmqLY1kcCSc7WYJBAop5QJIuLiZz846mf7VpCSRqPxFE+JA6R tSxXyi6JpMa5goFgUMZ8FMrfoHjPMK+Q+uB5hDqqlnnNzUstYxmTCSDsoJQFLdAa39fU Ikw+AxCtPl6xmJrWT1ii5nrxAk9pBZFtTwfn+MZ3hCRL4sAFGGZYx3NmnOsqz1y6GrSv D4Phch/zQMzwAL6K23YXU3NgGKSyo+N2wBgynuPBWAF6ZKc1wjLqiTOiqHBhNdqpj7wI HM05qCfdzAGj5AxeTlW+NbNQRTci9OGxAH6Wt96lFpG1oiBTMf05mGSCYynYW0PSZ7s0 ZV5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771377038; x=1771981838; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HaLulxvPHYvGz4Xb3W5g68oYo3k4BkyuzN9QRj/2IQU=; b=gTYvA6yRE4zxTHEt6Hhx4CmYUlPBgftQqK0x+NoYhOBpJ/EP1W8p3bwUUbqcMifjEV weg0iotqFf66Kc4dmb0pJjLPSC9t0GK5SubHlweby5sEqQiI4+MOQcbdIqPgqsRomkka OD1Qy2nUjnTXBja0e6TSz9yhrO20wExBaGV1yr/J421fvQXQGpQf90GO92G8q+/lR6tH QUTgXLdf2ojGdKPGVoe4Uw7o95RuyiwpCwN7YmIKMlyz1Z0EFKUXjsYBsVNRxMaIiVKJ nk5hGSyBQpAYk6jRxuwzxAcSsD2aYgLY16SVEd124pf5HAGGt28j2aJkJX4G/e1GsHP0 LJGw== X-Forwarded-Encrypted: i=1; AJvYcCWw9rryLEgQ4JSAM9puheVDumZwFJSGng98C2MkLC+bh2kyL9XN4P3fmj1wbQkn1O8EIje2A2Hf2lk7xbw=@vger.kernel.org X-Gm-Message-State: AOJu0Ywj3iDRnLw667901r1AWOMjej1AWFHFPsLpgbRQBaz9wsbLA6ET el49W7qQ8/ta8Q29SAit+FPOcRfGsxr+9lm8t29C0fXHzGt3CMgiHYHhQC8A X-Gm-Gg: AZuq6aKZjn6cIkf4joUTcoy5QhokfllGOH4v+ReXqQ/go7xB4Xpm57gXBWc4GY+Lkk7 C2TWyb4EAKyfi2KKlO5IMCZZqufk5ALGza/fc207AviD3sSaRgJHXa4/1rjaGnLBViHmAzn1wRW o+tTazvNlaW58OGq+3c0uawrmTNIqQHJqhZexOfzCD1i4Vj0PIJy1TA98+2MElKhO6bmu9R20Ha YFj8KhZOG4L3D1vpqFBUmR19mrJ4VZfXFtZmKpPxx9sFbQY4vJYe6Xxh7gediYtpC3hb45zFPzA axb5fm+NDyhoN8yyJzowQ1dpNvGl8k9pBdLhhyCuhLYaYQl8NnGTkjJ1mELDzuZ5ia4RghoheCY CGFTsYuFtnrzSHQjOnYNh71ShdTxAVhUiVX/GMMzvlootJXzF2CsUeWfnwEYRvw1Fl0NrOtWJqP KXYQmFox9NBxBT3/sq7oboKBjg5cOFuSkdoZd6Fft5hNVBohfDPC90t1LJFh/JlLgHyrnsbltag LL1OxvAt8absxBmZg== X-Received: by 2002:a05:693c:2c93:b0:2ba:99cf:e191 with SMTP id 5a478bee46e88-2baba0df2c6mr5760451eec.23.1771377037432; Tue, 17 Feb 2026 17:10:37 -0800 (PST) Received: from localhost (c-76-102-12-149.hsd1.ca.comcast.net. [76.102.12.149]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2bacb658fc4sm18751848eec.22.2026.02.17.17.10.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Feb 2026 17:10:36 -0800 (PST) Date: Tue, 17 Feb 2026 17:10:36 -0800 From: Stanislav Fomichev To: Jiayuan Chen Cc: netdev@vger.kernel.org, Jiayuan Chen , syzbot+2b3391f44313b3983e91@syzkaller.appspotmail.com, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Sabrina Dubroca , Stanislav Fomichev , Kuniyuki Iwashima , Samiullah Khawaja , Ahmed Zaki , Alexander Lobakin , Willem de Bruijn , linux-kernel@vger.kernel.org Subject: Re: [PATCH net v1] net: defer __dev_set_promiscuity() to avoid sleeping in atomic context Message-ID: References: <20260214033859.43857-1-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260214033859.43857-1-jiayuan.chen@linux.dev> On 02/14, Jiayuan Chen wrote: > From: Jiayuan Chen > > __dev_set_rx_mode() is called with addr_list_lock (spinlock) held from > many places in dev_addr_lists.c. When a device lacks IFF_UNICAST_FLT, > __dev_set_rx_mode() calls __dev_set_promiscuity() which propagates > through dev_change_rx_flags -> ndo_change_rx_flags -> dev_set_promiscuity > on lower devices. Since commit 78cd408356fe ("net: add missing instance > lock to dev_set_promiscuity"), dev_set_promiscuity() acquires the netdev > instance lock (mutex) via netdev_lock_ops(). This leads to a > "sleeping function called from invalid context" / "Invalid wait context" > bug when the lower device has request_ops_lock or queue_mgmt_ops set. > > The call chain is: > > dev_uc_add(bridge0) # e.g. from macsec_dev_open > netif_addr_lock_bh(bridge0) # <- spinlock, BH disabled > __dev_set_rx_mode(bridge0) # bridge has no IFF_UNICAST_FLT > __dev_set_promiscuity(bridge0) > ndo_change_rx_flags(bridge0) > br_manage_promisc -> dev_set_promiscuity(team0) > ndo_change_rx_flags(team0) > team_change_rx_flags -> dev_set_promiscuity(dummy0) > netdev_lock_ops(dummy0) # <- mutex! dummy has > # request_ops_lock=true > > This is not limited to bridge/team/dummy. Any combination of stacking > devices (bridge, bond, macvlan, vlan, macsec, team, dsa, netvsc) over > devices with instance lock (dummy, mlx5, bnxt, gve) can trigger this. > > Fix this by deferring __dev_set_promiscuity() to after the spinlock is > released: > > 1. Change __dev_set_rx_mode() to return a promiscuity increment value > (+1, 0, -1) instead of calling __dev_set_promiscuity() directly. > The uc_promisc flag is still updated under the lock for correctness. > > 2. Change dev_set_rx_mode() to call __dev_set_promiscuity() after > releasing addr_list_lock, based on the returned increment. > > 3. Change all callers in dev_addr_lists.c to release their spinlock > first, then call dev_set_rx_mode() which handles both the rx mode > update and the deferred promiscuity change safely. [..] > Reproducer: > > ip link add dummy0 type dummy > ip link add team0 type team > ip link set dummy0 master team0 > ip link set team0 up > ip link add bridge0 type bridge vlan_filtering 1 > ip link set bridge0 up > ip link set team0 master bridge0 > ip link add macsec0 link bridge0 type macsec > ip link set macsec0 up # triggers the bug Can you add it as a selftest under selftests/drivers/net/team/?