Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4859433rwb; Mon, 21 Nov 2022 12:57:55 -0800 (PST) X-Google-Smtp-Source: AA0mqf4ks0SJa+PYGeGc/4zPWWzaYWAy1oYHae50gN/CkCQw0Nf/beuSozujI0LS+wXCbSkSoKoq X-Received: by 2002:a05:6402:1f87:b0:468:7df:c38c with SMTP id c7-20020a0564021f8700b0046807dfc38cmr17980763edc.150.1669064274972; Mon, 21 Nov 2022 12:57:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669064274; cv=none; d=google.com; s=arc-20160816; b=bEc/0z30/5cHqS65tjhBAIfH6sWMGtG7c6lq3Nm8zTBgtTOUiy2m0BcVp04fIRfr0W fAXnLe/me+ucTJhI3i4bTXms2M5L8HrpVIJq7TK5Fa65uEqUZRU52eSV5E+u4uSGYZVl S5FN15NzNrUUWctOXAwOJiwguqjxvvuq6gjC6MXHwUMfG4nEr5Yat+3HUJoC5SvP7Ux8 DdBy6p5aK8eesT0QZdQQeiIVluvKqwNbwlYE3uHD0IB3DgPi7SK0mS4RpnLld5VEYeiM FgWuhQN6UuRjxZn4hJHcoiBwJen2fLEBOOLNbyB7+V0Dc4Hdr1vyyWz8KQAfI/L6Rx6n UEag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=eWLdJJDPEqVULc2oQdrml30Pa4z33QzeUxbdXRKXWHo=; b=whHYCXGcN1wBVbzR8+sLr7HSGLmohHwl1kNhuqD14Nk2BfvBc3zZuy68hesfCrK1rT y4ebqf+7sNg7UMzIO2XXt8qWLxEV1hdJsTgAQ1/bpF9BUYijCjuAzKoXL7foJFKiOr3A G0g/qFIuFlU5wQpdPEZzpshX/Donk42IpRwdjICdmDxDGQpv/0OtiH+/vX5KF9eAPNTq rv+0QR+Vx6shlIvCdB+Dv1SDKybEfv2DfbM3ovGdRfUYAtIO6uAERsUtEz4JsIyZPe/z dz7m22co1cQ2Tow5/JVA5+F1E/VoOBJ5AysgJYeznpnGGqyXDxcKhBDofSdNCIoXA0eR JE5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=G5hsHwuI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qk30-20020a1709077f9e00b0078da5f6ed9esi6824563ejc.779.2022.11.21.12.57.21; Mon, 21 Nov 2022 12:57:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=G5hsHwuI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231664AbiKUTvJ (ORCPT + 91 others); Mon, 21 Nov 2022 14:51:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231654AbiKUTvD (ORCPT ); Mon, 21 Nov 2022 14:51:03 -0500 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 897B5D539E; Mon, 21 Nov 2022 11:51:02 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id n21so30927926ejb.9; Mon, 21 Nov 2022 11:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eWLdJJDPEqVULc2oQdrml30Pa4z33QzeUxbdXRKXWHo=; b=G5hsHwuInQCfQ+JbnGoJ7f7lcIqikXLI78JMoJiw7+DCPUUSZmW8c8MQxyke9z515B ywBlAWDW+YMrzizHnZEX17JVIJiGu1qJ3a9u377dwuEhxdXtQP1y30awITZcqz7bxq1o WKFrNIIjbGjRpjZckSoEayAlh08d3AwvNlZI+yTUzCMUt1G9O9w+9G+sqIDuBhat2t3g mfM5HcpaXeqASYwtUlG2goN6ZOV6zQ26DI/pF12jzKSp8K4vjjP+9qq+26fxfKpp8T9L L8gCwFrzYQG8dNAv+WgTeYFTuhcriZM2oWADtPxDeY+Tc3JygdHIt5S0eMDnQu9R7wW8 6/wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eWLdJJDPEqVULc2oQdrml30Pa4z33QzeUxbdXRKXWHo=; b=gXzLkeolycCFbkyJ98NARrHMboLZ1qFGzNPLC8MzuD1WU3ir1fXlByhZJFlxdP6Yqb RXLTQdwyCrqQz29iFzI0WK3mdmZKPJvuJyQv1RfobN9XZ4C58VK5wmtPvSKMN53mJMv8 +4aAeYmHncQ4Qeo0APRd/+W+azsnZNH0PBLjwSriM6xZEWW54MTXWTFO4vwHwISlFrNA B1rigHtNkmcC7OglWNHjQkCh3Ce/0nLy3xrce7pkzbqzAIM92BH+nMHB88xZMAy3Ay1w 6sT6q3GjrXcwo7vSaa3A1pimFy9PPXQaljbKjRT/Xi4zcdk8C7C7KatU5TlVCJPcUJ5Z nHvA== X-Gm-Message-State: ANoB5pkmPXLZAbfQimB6Dv20kmOalXVBhcExEZ6IZ+K7UGr7H/LpelQx /B1PTF/3ocg+Ki3oKlnsoCd2EQW3NV541vu12LU= X-Received: by 2002:a17:906:2ac3:b0:7ad:f2f9:2b49 with SMTP id m3-20020a1709062ac300b007adf2f92b49mr5700043eje.94.1669060260708; Mon, 21 Nov 2022 11:51:00 -0800 (PST) MIME-Version: 1.0 References: <20221114134720.1057939-1-xukuohai@huawei.com> <20221114134720.1057939-2-xukuohai@huawei.com> In-Reply-To: From: Alexei Starovoitov Date: Mon, 21 Nov 2022 11:50:49 -0800 Message-ID: Subject: Re: [PATCH bpf 1/2] bpf: Do not copy spin lock field from user in bpf_selem_alloc To: Xu Kuohai Cc: bpf , LKML , "open list:KERNEL SELFTEST FRAMEWORK" , Martin KaFai Lau , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Kumar Kartikeya Dwivedi , Mykola Lysenko , Shuah Khan Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 21, 2022 at 3:30 AM Xu Kuohai wrote: > > On 11/16/2022 4:07 PM, Xu Kuohai wrote: > > On 11/16/2022 1:27 PM, Alexei Starovoitov wrote: > >> On Mon, Nov 14, 2022 at 5:31 AM Xu Kuohai wrote: > >>> > >>> bpf_selem_alloc function is used by inode_storage, sk_storage and > >>> task_storage maps to set map value, for these map types, there may > >>> be a spin lock in the map value, so if we use memcpy to copy the whole > >>> map value from user, the spin lock field may be initialized incorrectly. > >>> > >>> Since the spin lock field is zeroed by kzalloc, call copy_map_value > >>> instead of memcpy to skip copying the spin lock field to fix it. > >>> > >>> Fixes: 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage") > >> > >> The tag is wrong. When local storage was introduced it was not > >> possible to use spin_locks there. > >> Pls resubmit. > >> . > > > > No, spin_lock was introduced by d83525ca62cf ("bpf: introduce bpf_spin_lock"), > > before 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage"). > > > > To confirm this, I built a kernel image on comit 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage") > > and run test case posted in patch 2, a softlockup was triggered. Then I picked > > this patch and tried again, nothing failed. > > Hello, am I right? Or could you please give the correct fix-tag? Thanks. I see. I was under the impression that bpf_spin_lock was enabled in the local storage later. Ok. Applied as-is.