From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (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 755FC36A022 for ; Mon, 3 Aug 2026 09:44:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785750301; cv=none; b=H9pluMc29OMYzdoxYLHCun6h1b5oeqPvlO8bsiDK0w4/nXC1+iHFiIl8CR9Ky804XMilfQ2J+Ghvhg8LlulyrEiVpJg8msBYxIPsWlE5S1efuJHpHisAFzIx4PlF9wYM6HLzvTqzedEsYdbSbkf5piWAQ1Y6+8m5LdBxG7bZPcQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785750301; c=relaxed/simple; bh=MKQ1bcx9ZD2AQlgywAp0pOBhw+lOZ2APmx9MRvtiUjU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oLugmRxedqbHcKPjlQo72LyuZiGO2m/va3fuNaK87eyzKakF57Kwo2FzScDuouPXEdAeF8Bkj/a1lilHurYl+x974IfYKUcFbnAMvTRGRiJC6e2gm+ZjOOCZwZPDkwSmNN6sEzkQZhliDjP2HvwV3NSr7PdhemoGmms0jlIyQiM= 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=HZq75ZPC; arc=none smtp.client-ip=209.85.210.169 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="HZq75ZPC" Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-84e84a6c4bfso2681088b3a.1 for ; Mon, 03 Aug 2026 02:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785750299; x=1786355099; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=MKQ1bcx9ZD2AQlgywAp0pOBhw+lOZ2APmx9MRvtiUjU=; b=HZq75ZPCDF8o8qqAA7UwTt4v0eTEAq6zx6/OGEHrVr0vn7uI1CoPRIGwk7yzmpmAnU vxBX+mlNV+6qLUTAu83MHpaJhuUC6LR/+2Z7cmG6IDwkJYnAx07xrpnzlq9ZwjcOUH7J 5TmlEkZnW1ct5VqRgCC6rTDcggAoyo6kXnYdgBaDpQmOItRLA46W/CfHvGJyTY1o9aH2 2VxOH5/SxEfwYXX/1/ofdGNT2u3dIN+5ZdS32X2jl04332H68Pn9aGGdlLMbzdwftBxG jRTNeHHvQd/K/zAX8ZZ/Oowrx94Uy0h8Ij88KQWC9O+jvvMyZaDJhkyHNZ+V+hxADIeu 0x2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785750299; x=1786355099; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=MKQ1bcx9ZD2AQlgywAp0pOBhw+lOZ2APmx9MRvtiUjU=; b=lcNnsoYYoc3o0hQZvGjKfcxk2Gh+SKRzooCBfrexykNcFJLtP7/UD+CcvBk6gs9B52 8QmolHNRTpvu1AaTZtsY+zzCCGlcCJAr0irTr2qvGsJBrif8fiN2rhmUW5KlFkYn+N3L lpAYOw4UH3/XAREGHlFDEBgWH76/Ts9uIu+7vtQhoO9Ub0i5RUhW6Wv5sV33B7pcLyFu DGnUDghfXZQFM0ZdBD/I5msL/gdG+c+4rmeBmET5iBFunXJ8/6IvINcxPMdfOW+O+M7i dgAeT7yOeV2z4Q35bOvCLInYVP9rSaaLzGsKoZXWDKk1Z2xjxWf3qNtIuh0WI4KOETnX miAQ== X-Forwarded-Encrypted: i=1; AHgh+RrI90+HB8mibit9ydEE733sPCsH4htwFXWg6m+zJ3Rs9LtiV5KPQEkMjSzUjzyUkggxvjAvov0pT8im9UY=@vger.kernel.org X-Gm-Message-State: AOJu0YyWtd90y81xRydZRL0cnvMpFMTSaltcfQBIyA5oM+M8OPT5UlZj WzSrSAiVKscztCWsh57a0Q2iyCN5uvX6HHhS7kPwkX9RvrpmMgAQyU41 X-Gm-Gg: AR+sD13udlz0YOJkB0rAMOUuv2mZSY7ZFmDxJnPoxFoYpFEaCdBk8Sd5HvGvuuNnkOw mF7rq6Tpf4vDGE83nVfs7dV4In/1OvkerJtFrudr1staexi0OzEuE3JDmnhVLz46hqdAiEQkSx3 FryYTEcr+FYK0VffSYUaiZv3Gix1aL6hknC9JB6+QEZ1/Wz8aDjAItCrimzdRt3eTOzCqHax90j KyipoHykiEyBM/hlya22YribPlC6dWWPNfkVHGMzwT2oqYdH6hqv2aUwzGkdsUmuZ9JIbNibs5T 1XFcLUDsFKhQz7iVJTuU9VRWYWAj0x8RBVyHuahZRZ9mZKhMkf2ijzcM9TNitqcdpzZ8CsbcvzA 0sa5hnzT5gCKyPeIlq9iTi/7qc/B5TJbyRejBXr3sld7ajZPuY6aOchoaSP+qLwCYLF7kM263AP x5D42MsZD1kxDFq6rFw1DkuyujSeSg3YK67gN+rDXmf5ubDsIhVvP5dCqVtTKDfG2DIgiZw0oKk 1mSguTvVsx6clgXPf3QqFK8y8ALe/4g1J771Slzhn7zgmC2OKh+ X-Received: by 2002:a05:6a00:22d1:b0:848:7bbd:2851 with SMTP id d2e1a72fcca58-84ed74bdcf0mr9830488b3a.29.1785750298661; Mon, 03 Aug 2026 02:44:58 -0700 (PDT) Received: from secrnd-cstp.tailb7f510.ts.net ([125.131.91.97]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84edc29f312sm3380567b3a.33.2026.08.03.02.44.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 02:44:58 -0700 (PDT) From: Sanghyun Park To: Andrii Nakryiko Cc: Sanghyun Park , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Sun Jian , Puranjay Mohan , Ihor Solodrai , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+cdd6c0925e12b0af60cc@syzkaller.appspotmail.com, sashiko-bot@kernel.org Subject: Re: [PATCH bpf-next v2] bpf: Fix mmap_lock leak in irq_work path Date: Mon, 3 Aug 2026 18:44:34 +0900 Message-ID: <20260803094434.2763945-2-sanghyun.park.cnu@gmail.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > maybe we should make bpf_mmap_unlock_get_irq_work() return `struct > mmap_unlock_irq_work *` which would be ERR_PTR(), and return > ERR_PTR(-EBUSY) if (active || irq_work_is_busy) (see below)? I'd > probably call it bpf_mmap_unlock_guard_get(), though. And then we will > have bpf_mmap_unlock_guard_put() (instead of > bpf_mmap_unlock_put_irq_work) with the same logic. Yes, I think this would make the code a bit more straightforward. > we drop active to zero here, but irq_work_is_busy() can still return > true, I think we do need to check both Yes, BUSY can still be set after active is cleared. However, since the work can be queued again while the callback is still running, I thought active alone was enough. I also tested it in a widened window, and didn't see a lock leak. But I may be missing something. Could requeueing the work here cause a problem, or is this mainly to keep the original -EBUSY behavior?