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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 243F3C77B60 for ; Fri, 28 Apr 2023 21:19:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 885716B0072; Fri, 28 Apr 2023 17:19:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 835186B0074; Fri, 28 Apr 2023 17:19:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FC826B0075; Fri, 28 Apr 2023 17:19:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 607436B0072 for ; Fri, 28 Apr 2023 17:19:11 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 305541A02E0 for ; Fri, 28 Apr 2023 21:19:11 +0000 (UTC) X-FDA: 80732065302.09.0B8BEB6 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf01.hostedemail.com (Postfix) with ESMTP id 1AC904001A for ; Fri, 28 Apr 2023 21:19:08 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=GqN4m+5o; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682716749; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=61ueAZnI+VUsri6o/4rA392h46Og1UAC3oGSqW4xW/E=; b=SpJKVqUMwjbCT948Kdaytc+oa6QwCb6r6BScW7ifQqSpeLSnYILu0W+INQ+z88kHYCLTW1 43InqCCkbnq13zs90CtmM3LMxqy5orwmQSllx36UZ2eHgsouoBLQDZmYGr+vtYt41o3RDI AQ3+uYH0NFOmT6YiizIIOyWKENf/2Pg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=GqN4m+5o; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682716749; a=rsa-sha256; cv=none; b=bGUKLDorp/tevaU+YBj8q57V1O5mx++022jicgTSbIRwGshz6TbKjjwy3bT+6KqKkGLeK6 3vFKpsbfcm9zQpSxW/faSXXkuLcsR57C74fxcw/eLB2eu4N1/8VFWoMbihI4b2POSMoKSc OkDBdOqk10j9LXFkcUA6F38oaGZvFR8= Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-94eff00bcdaso50144266b.1 for ; Fri, 28 Apr 2023 14:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1682716747; x=1685308747; 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=61ueAZnI+VUsri6o/4rA392h46Og1UAC3oGSqW4xW/E=; b=GqN4m+5oDpAvN0PtaOsqULNsTSUSenPjy/O2JJIWrG1stZeQNQLkuJbbnUkn6/ef6I fEQ+TmDjjQCjzlCG0CSfMC8MPnUfzacTyvSvop4gjuciyB+S3hpEXPGGC6n1hQjbcW+J xMTIp/zt/bGRAk76AZSamtjwgm1xlqCNi+7AU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682716747; x=1685308747; 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=61ueAZnI+VUsri6o/4rA392h46Og1UAC3oGSqW4xW/E=; b=PfDl2xjVM33maTxm2aHEnkDoIhsa8slFMnjxxMZwqGADVTasXkZglrnMRWiGZvBpSI YE9LanNdewqj0YRCqFHKD/RDheVL3Z2WRrajqyd7iWJwAXuyx4l7LNsOrT4WHdfMrRc6 XjIErRWsy4H5T0D1qIGAw4cinIJpghTiFnoCWmbJZMwBNNYYgB6hHaowQ2FSPIJqnrAX 9cW+O+OIAUEVwIiRo+jen3fKJHYWObM1QKZ31II54YkrpOf5JXhONlJvRLkdokknCXG9 HnfTWzIp5U3Y6E90KTs6SSvDFJ6eDZ9jFHNy3Rsu5s+6V/01K8/W6d43uy04NyMvXqgu 2E5w== X-Gm-Message-State: AC+VfDz1H326YgctvLqnKQ3KeYl0EgDMbPsjnI+BLGAP2lYFtoqi2KeO PZAuevFYJbG7hWNW9JkKEDDsyq1jnwHDVvc+TYb/Lg== X-Google-Smtp-Source: ACHHUZ4Wv39kGZ1csYg7lYtMwsJkPQykzRVT25BJ2DOG6FQw7oKWkXmuxkiWeFiyFBwUO3t6hvZ1FQ== X-Received: by 2002:a17:907:8687:b0:94a:5819:5a2b with SMTP id qa7-20020a170907868700b0094a58195a2bmr6214606ejc.33.1682716747125; Fri, 28 Apr 2023 14:19:07 -0700 (PDT) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com. [209.85.208.43]) by smtp.gmail.com with ESMTPSA id qf19-20020a1709077f1300b0094ef923a6ccsm11591474ejc.219.2023.04.28.14.19.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Apr 2023 14:19:06 -0700 (PDT) Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5067736607fso318125a12.0 for ; Fri, 28 Apr 2023 14:19:06 -0700 (PDT) X-Received: by 2002:a05:6402:114c:b0:508:4808:b62b with SMTP id g12-20020a056402114c00b005084808b62bmr180566edw.22.1682716745923; Fri, 28 Apr 2023 14:19:05 -0700 (PDT) MIME-Version: 1.0 References: <20230425041838.GA150312@mit.edu> In-Reply-To: From: Linus Torvalds Date: Fri, 28 Apr 2023 14:18:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] ext4 changes for the 6.4 merge window To: Nick Desaulniers Cc: "Theodore Ts'o" , Nathan Chancellor , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Kees Cook Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1AC904001A X-Stat-Signature: yppksfuutiau8cy6h1doek9tpirbgakh X-HE-Tag: 1682716748-469005 X-HE-Meta: U2FsdGVkX187hmVRRxbR5D4HjZ1SnMQkIa5iu6uVK0sZTxAOYQ/k293yNaJyK1RteyEVKIyT2XVn1GR29+yrtcO/ZId8kGYNZ5nInfcYhGTpK8PzExESbKeUalRo1DI8EWyU73jGsgnQbIu1NYUH/sxtxO8p8q+EIG0Ma/REselVM6FNa/FarG3hpj8eUmwo5fP9ateNoW22kD1ew0XjTMBu7hqOOWWoSiff0mdemQmMjG14IkFwhGBZPebaHwx8djvH3SriGzKZNNu34IYxif0I6UcM1hvNUTkCTX7/j+F5GWw9M20pcO7EZbLSlAcQaVBln0dDwNRp88hMQFHWWaZ4Y3ea+XRQHFn7YLDXA8s+Yny4bkUhCiOXFfQSBPhCP+ISCTIgky1JFSS8dAsZWW7z/1qeZU61o/VJsD/JfQ46xRMBLSQNEUr/CR+JCUJFh16y68r2fSGQHoKd3j4ZAUqTLokmrI8SSmCyngDTKWonILlSKZGwd6fyKeio83DFdkmLSvwRLslLjrjdLY0dJ5PB9BgIj34i7bSkujaG21XqUy9fxEzpYcznO4kIsZPFx+b1Pr3aXZe+A+5d/5do5eMaQrA66718UKPAcCs3xdb+uxKLe8nKFdEfxoIcCqoKS/znWFiztPlT86OgUO8IHkuzO0GkMBIKTP754Jd2gfIEkNeMqlIzYEblzxaelroTVPZ2khcr08F7zNB85rz6M/U/gR3+Id4xyFttvGau4qDw1YoQ3YBX1YByxHrE0uabWW17i1oagygQxeXk4JgTXTEfQAo+Nzqv0hNXZRTLR9cIm6xwxkNlHNMNBuJDMOHXGtmOheqMOGiO7DTNXGCs1zZvSipxPa86GaGpmUMz7QvXeTMjniSxQtzkW32nEwJcLwdREHeX/VCWjYRwzziAUMKADodjnUl78IdaFO0pLRHUvP0KvZfyVWXoUjJRUncWofmQkJVCqycwzpZbwqW plVxP6zw UaYtozFx6A6yLC6fy9SLRRaqiB5HWFU9P2wVF1062mk99X08XXvYB88h+hkx7hOlRzzlgGLC5jvH+fTk7zdmIvtu84RMDHe5M+peyrxXpH1gfzPVjjxE8U/1ngy30j5gVJ3N4DfW5vJWcARxruSUFeXbsXu59Ejxxaq2ckF7ocoVJUE3VXJb4cWB5UT06C71JC7zTyIclNtSdaSejLZrBBdadx+JB56VqQ3oAuHab+rlYlQA2DBpaqLXtTRMqCa6e7MQjxW3TwIPtRS3CsAYFaJn/8+K80ibfdOUWoMCkMkElAl3ZY0HHHFfBz8IBqk+QDeL6CMpqKidJKXX0zsu0SiAWpnyxanCwvUY6XFOz/A3zTqsUDcZcvXpzoD3rTHA8O6m03yqS84+X4XqEH6Si/0EmamDlMS8rvBBms2N4sS9VpeXNyYJDDaMtvLHjHOHQdNfT/Qn+/dGoBgboQFLtvL0OyrmxtU78JKtRXJDf68a87plRLivNUhcML878gp0R31KJhgKrOrcExa4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 28, 2023 at 2:03=E2=80=AFPM Nick Desaulniers wrote: > > > > > void *bar(void) { > > #if CONFIG_XYZ > > if (somecondition) return NULL; > > #endif > > return foo(); } > > > > and the caller really *should* check for NULL - it's just that the > > compiler never saw that case. > > I think having a return value be conditionally _Nonnull is "garbage > in; garbage out." No, no, you misunderstand. "foo()" is the one that is unconditionally _Nonnull. It never returns NULL. But *bar()* is not. There's no _Nonnull about 'bar()'. Never was, never wil= l be. We are *not* looking to statically mark everything that never returns NULL as _Nonnull. Only some core helper functions. If "bar()" is a complicated function that can under some circumstances return NULL, then it's clearly not _Nonnull. It does not matter one whit that maybe in some simplified config, bar() might never return NULL. That simply does *not* make it _Nonnull. But my point is that for a *compiler*, this is not actually easy at all. Because a compiler might inline 'bar()' entirely (it's a trivial function that only calls 'foo()', after all, so it *should* be inlined. But now that 'bar()' has been inlined into some other call-site, that *other* call site will have a test for "is the result NULL?" And that other call site *should* have that test. Because it didn't call "foo()", it called "bar()". But with the inlining, the compiler will likely see just the call to foo(), and I suspect your patch would make it then complain about how the result is tested for NULL. So it would need to have that special logic of "only warn if the test is at the same level". > Thinking more about this, I really think _Nonnull should behave like a > qualifier (const, restrict, volatile). So the above example would be: > > void * _Nonnull ptr =3D foo(); > if (!ptr) // warning: tautology That would solve the problem, yes. But I suspect it would be very inconvenient for users. In particular, it would have made it totally pointless for the issue at hand: finding *existing* users of __filemap_get_folio() (that used to return NULL for errors), and finding the cases where the NULL check still exists now that it's no longer the right thign to do. So I think it would largely defeat the use-case. It would only warn for cases that have already been annotated. So to be useful, I think it would have to be a "does automagically the right thing" kind of feature. Linus