From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 906F9C6FA99 for ; Sat, 4 Mar 2023 23:53:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229662AbjCDXxF (ORCPT ); Sat, 4 Mar 2023 18:53:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229653AbjCDXxC (ORCPT ); Sat, 4 Mar 2023 18:53:02 -0500 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82324D302 for ; Sat, 4 Mar 2023 15:53:00 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id ay14so20782055edb.11 for ; Sat, 04 Mar 2023 15:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1677973977; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MElKyCAEjKYln0Oxdnu5/kmS5Su22bI0nBFZvKG/ppQ=; b=ZlN04JLpuXtpTEZpiRm5Xbl39yBXWMkWGL1gjrmf7l2CsXs/fiLOpG/rnrjoiQfZU9 LiGo3mlKapi96NO11zvw/TrxdWEt2Bzqq8B7wDyD57Kib2hZ970aXjo+lumAVq6ZDUM/ we4CwP2nVHdPEYGyAYp4e0XRAGIRl3nf2Hz5Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677973977; h=content-transfer-encoding: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=MElKyCAEjKYln0Oxdnu5/kmS5Su22bI0nBFZvKG/ppQ=; b=2MqNdaYwNHDVyFQyGlCCtG61Gy+j09bovNyz0yWgY0u2gpi4CbtYpQowWezf2Ggy/3 hFGL3wmeb0Wetmd5qEjpGVyrH/+mpIHCpFt7ADaRJQJy2fcJht+qfsm3XsXrMNCmRRRf m/shsGnjKNByLlQIPQPrp2UcN/4FemDf+6HMLv14UzW3z/nNCsViaCrSxSZ87e4V2owW l9O5qrIQs/OE4Mm/DbOVgfuEX0NwkCv8N+5qcph3kvl5wlgK9eybuZzxrqL1YnfegGjv NlpfAOyH6CC8nVEp9HZydc2ZUCzAAF5VHF5Zd9CrPniHaWY8U0DocIMlsitZkSfY0vbU T+dQ== X-Gm-Message-State: AO0yUKUiwOU3Bs5hGDsl8AR7OCmrH2fJca8m6MTg1mGJbImN3JwWUtzk MndF0aTxbCy1I5+GtLKQf6JaGge7ASb60eqwmrA+Ow== X-Google-Smtp-Source: AK7set+A0MqLMTtk6BQ9GULZvzueJhaLztVSfLopn9CUg8tKjjrvYFAR5lQ3QfDyAaey0+hpUS3hrw== X-Received: by 2002:a17:906:794e:b0:8df:e176:4837 with SMTP id l14-20020a170906794e00b008dfe1764837mr7517039ejo.19.1677973977544; Sat, 04 Mar 2023 15:52:57 -0800 (PST) Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com. [209.85.208.44]) by smtp.gmail.com with ESMTPSA id y9-20020a1709064b0900b008b176df2899sm2528638eju.160.2023.03.04.15.52.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Mar 2023 15:52:56 -0800 (PST) Received: by mail-ed1-f44.google.com with SMTP id cy23so24334836edb.12 for ; Sat, 04 Mar 2023 15:52:56 -0800 (PST) X-Received: by 2002:a50:8711:0:b0:4bb:d098:2138 with SMTP id i17-20020a508711000000b004bbd0982138mr3409593edb.5.1677973976346; Sat, 04 Mar 2023 15:52:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Sat, 4 Mar 2023 15:52:39 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible To: Yury Norov Cc: Mateusz Guzik , Alexander Potapenko , Al Viro , Kees Cook , Eric Biggers , Christian Brauner , serge@hallyn.com, paul@paul-moore.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 4, 2023 at 3:08=E2=80=AFPM Linus Torvalds wrote: > > Well, this particular patch at least boots for me for my normal > config. Not that I've run any extensive tests, but I'm writing this > email while running this patch, so .. Hmm. I enabled the KUNIT tests, and used an odd CONFIG_NR_CPUS to test this a bit more. So in my situation, I have 64 threads, and so nr_cpu_ids is 64, and CONFIG_NR_CPUS is 150. Then one cpumask KUNIT test fails with # test_cpumask_weight: EXPECTATION FAILED at lib/cpumask_kunit.c:70 Expected ((unsigned int)150) =3D=3D cpumask_weight(&mask_= all), but ((unsigned int)150) =3D=3D 150 (0x96) cpumask_weight(&mask_all) =3D=3D 64 (0x40) &mask_all contains CPUs 0-63 but I think that's actually a KUNIT test bug. The KUNIT test there is KUNIT_EXPECT_EQ_MSG(test, nr_cpumask_bits, cpumask_weight(&mask_all), MASK_MSG(&mask_all)); and it should *not* expect the cpumask weight to be nr_cpumask_bits, it should expect it to be nr_cpu_ids. That only matters now that nr_cpumask_bits isn't the same as nr_cpu_ids./ Anyway, I still think that patch of mine is fine, and I think this test failure only ends up being about the test, not the patch. Linus