From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 400AC481230 for ; Mon, 18 May 2026 16:43:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779122634; cv=none; b=HkDtJIVq483jzeuf1BUy6+CY0Sp0vko4FUrChCtlos6Kux0W7WOpoj6o73YDqjmJmpdSE5u88N/hTMHqfyLzzaE4oIUOpBf8zu2ULWl0R9pM20qSQw5iJTpIzWU+OEJ+KPUTAD/hwgr5sNukI2EFBQGsASFWQYT5jUUo42gtW/0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779122634; c=relaxed/simple; bh=BpUI463qOnTFoISKFwnX5ZskGYYCjuOqBstCVOJYwzo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BlS+7WEYSq7VB/Pz7Do7RWFW017ijxSXnG8fzetgDSgwalL1HzN9SeBPyMNv5/zht0ij6Xf3U5Em4pxDN2G5ArQepQh7KVsQuX+WRCodr6is65ybYS8TrlAbhCA0aL1giYyuDZjsjVuKdWjo5Q7Pw3iIbke1YzJOh6XpvuxGvAk= 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=mvmf7r/x; arc=none smtp.client-ip=209.85.128.42 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="mvmf7r/x" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-488e1a8ac40so26029335e9.2 for ; Mon, 18 May 2026 09:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779122632; x=1779727432; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nSt4x+poU4p8LXWInMRteFG4LHeESzIi5up8Mh8FuBw=; b=mvmf7r/x520z5NgL8xzttmjVN+4ykUt1SmWW+qx1bCMorE7BAPy/iL6Ga3mdn/kDzI iMJNOESvQcqHiEo6M5kSrD2ybVgyEDiHFEcXoB9k9fTIOp8t0scfSeaxDbWYcLAp+sbE 27sblqv9jVvRWUpMMRTj/JnyB9ALpvkOdKrLw8uWR5PUWBfF8ncsTidgkjHYXsvRlTGM Jf7Dao4nxENp8anZ8EOiU8b7/HMCpAm0hc/fnEbwFo5NpSoO+DIBT5l4gl2ntRIJ5AWP /+D/y7kx29+SkbTvwaCB7LXe+NtvE1WJsGzxGwVQgcQe2vOCWVqDRnvBLpPMnQ8E3wEk 6XdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779122632; x=1779727432; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nSt4x+poU4p8LXWInMRteFG4LHeESzIi5up8Mh8FuBw=; b=CPnCiDat9P+BmUVu8aYr8IvKMNRKfvT0oU1idl9efzcdbepvd/g3+JQcf6oD9FYBcx JZJoj4WPoIs/RTtM9ZTomabiZ3k0J5BI3XxSmq0dEC7seqMKqTS+Du4ZFip6lkgRyz2I 9E505s5NoUn7t7it6CG7sxtrc1y6oYhlpUTSgV6XoEyfeI+emOGAfxb42glHAZtGl3Ne XXE2segT7IC/i5svksEGU5ZFxD4tC0DwxOLs53UT7CUcrA/ea0edUo80mvL94DIyMCdg qyQDicBZT5rDDOkJ1rATMF815PANNwimCCJZQqMdLa6deXD/MXJo+lxS9o2hpWcXgYDR 1OXQ== X-Forwarded-Encrypted: i=1; AFNElJ8oTfCO8ceSQkZ81hOrNkvnpdZ+SljYmgKYw/YHMshU7WJ/qjhosxSbPk24+Z1Gz0gHDC6CWPPafKlXW+Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yy43qkxcWZbzySn7LeildJXCzXl5PtBNhQQUoCj/4qN1zJ3/wvk 8oibJViWpKbxhIsoaqFU2KyECOvatqRijy7Otp4o0l7FJxV1vtkCxiC/ X-Gm-Gg: Acq92OEAw0mdwJp4qZqeZ9T98uOnPpGfRLPaE/tfTsRro+1MH9zoZOdePz6TkAJH8Sm xTy9i8LKGktvsB7+Qgt10HiPa7NGRc+aZcxJzcHnK7rDumzEbXVeNMGbxQ6WfFzxIDju+ReCG82 2QFgBODBVmQHTslT7mp6GKfehqGfGBTWgvVeCegw9JLvoWlIAxJWfLx6SYTNZdyQ/w0d/h/Yu0y NUMz3T0FvmbjQj57rqzPzncOBR+gbGAK5pDF+QHye/PXdQbJsXChVYSOr0uoBEW2AKpzXqJTlQS 03JaXYugUAAP3Yxvb7b5ayXkqFVLjqeuGbNPFTRr1nfwZdcGgEqhm1McbAhXjGESbIDWaLOTq2j WMGtgZqK7IeBJUDHIfjcpY174AlzPmpiTTUq0UP71rTF6y+zPxRV78HbzMQfKYAWu1GhCUIklsu 1fx74eEK1PQ1mzm4kiTmEVOwNTM9FZhBf/KF8Dq4uBv7pRsYKQ8y+17rnjJJaMzHVYl2vdCRs= X-Received: by 2002:a05:600c:8b0d:b0:48f:e230:2a26 with SMTP id 5b1f17b1804b1-48fe6631679mr255364615e9.33.1779122631321; Mon, 18 May 2026 09:43:51 -0700 (PDT) Received: from ?IPV6:2a03:83e0:1126:4:1178:9251:cb12:6150? ([2620:10d:c092:500::5:5e25]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fe4dac000sm272950585e9.0.2026.05.18.09.43.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2026 09:43:50 -0700 (PDT) Message-ID: <261a47f4-a92b-4a61-86ca-c1de362be105@gmail.com> Date: Mon, 18 May 2026 17:43:50 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH bpf-next 2/5] bpf: Fix concurrent regression in map_create() To: Leon Hwang , bpf@vger.kernel.org Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Kumar Kartikeya Dwivedi , Shuah Khan , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kernel-patches-bot@fb.com References: <20260518145446.6794-1-leon.hwang@linux.dev> <20260518145446.6794-3-leon.hwang@linux.dev> Content-Language: en-US From: Mykyta Yatsenko In-Reply-To: <20260518145446.6794-3-leon.hwang@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/18/26 3:54 PM, Leon Hwang wrote: > Because there is time gap between bpf_map_new_fd() and close_fd(), a > concurrent thread is able to close the new fd and opens a new, unrelated > file with the exact same fd number. Thereafter, this close_fd() might > inadvertently close the unrelated file. > > To avoid such regression, drop close_fd() and override err when failed to > create map and failed to finalize the log. > > In other word, when succeed in creating map but fail to finalize log, > users will get the map fd instead of the finalization error. > > Fixes: 49f9b2b2a18c ("bpf: Add syscall common attributes support for map_create") > Signed-off-by: Leon Hwang > --- > kernel/bpf/syscall.c | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > index 83de8fb9b9aa..322865a88b3a 100644 > --- a/kernel/bpf/syscall.c > +++ b/kernel/bpf/syscall.c > @@ -1647,11 +1647,18 @@ static int map_create(union bpf_attr *attr, bpfptr_t uattr, struct bpf_common_at > > /* preserve original error even if log finalization is successful */ > ret = bpf_log_attr_finalize(&attr_log, log); > - if (ret) { > - if (err >= 0) > - close_fd(err); > + if (ret && err < 0) > + /* > + * Failed to finalize the log. > + * Should not close_fd(err) here. Since the bpf_map_new_fd() nit: you can't close_fd(err) here, because err < 0? The comment overall appears to explain why we are making this change right now, rather than why this works this way. If map_crate() failed with error code and then log finalization failed, do we really want to override error code? It sounds like map_create error is more important. > + * has published the map fd, if a concurrent thread closes the > + * fd, then opens new, unrelated file that receives the exact > + * same fd number, close_fd(err) might inadvertently close the > + * unrelated file. > + * As a trade-off, override the err only when failed to finalize > + * the log and failed to create map. > + */ > err = ret; > - } > > kfree(log); > return err;