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 15373CCA47C for ; Mon, 4 Jul 2022 13:44:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A94616B0073; Mon, 4 Jul 2022 09:44:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A43BE6B0074; Mon, 4 Jul 2022 09:44:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90C6D6B0075; Mon, 4 Jul 2022 09:44:55 -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 821696B0073 for ; Mon, 4 Jul 2022 09:44:55 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 55DB7120732 for ; Mon, 4 Jul 2022 13:44:55 +0000 (UTC) X-FDA: 79649538150.23.E966CE2 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf04.hostedemail.com (Postfix) with ESMTP id B6C0540003 for ; Mon, 4 Jul 2022 13:44:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=L6wSaDv21i8IBXuOCFtPFoc5AHwc9orKajt9IjPXWew=; b=nQ/NIdPXtNBa1KvneVnc6Ud5sy AWLprlY/lSUgAqO/wXcXY7jfFsKYSz3fHXyccL9RtCWjtEfSm/s389xh5h+jkRKIi1FdiCXhliL0f 8sz0JSaY9hIoeOYx+y5zBxWytVcq9KL7lCgnnw9faFOMcHEwPXGsB/i5Nty53v4nQ/imEIX8YU+K8 1st3oS9326bC1Q/y4IN6KDj9ND8o2Dcrclvc9TRD+Yf0/Y2NjQ2J6VpfAeIVwIEEKtKUGP/FJiDmR LxPuicJhlwu/sL0iqNdztvcSN2PT86QPnT85mshLE0+o7ec+5Xb83LQmN8e7I+IlqHyY67Q7B1jfs bmA/A14g==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.95 #2 (Red Hat Linux)) id 1o8MMq-0081dA-Ie; Mon, 04 Jul 2022 13:44:00 +0000 Date: Mon, 4 Jul 2022 14:44:00 +0100 From: Al Viro To: Alexander Potapenko Cc: Linus Torvalds , Alexei Starovoitov , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Mark Rutland , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev , Linux-MM , linux-arch , Linux Kernel Mailing List , Evgenii Stepanov , Nathan Chancellor , Nick Desaulniers , Segher Boessenkool , Vitaly Buka , linux-toolchains Subject: Re: [PATCH v4 43/45] namei: initialize parameters passed to step_into() Message-ID: References: <20220701142310.2188015-1-glider@google.com> <20220701142310.2188015-44-glider@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656942295; a=rsa-sha256; cv=none; b=YUhSgZpJXMP16EA0k3ifMqE/oaHSHlfvBQFSyOqmftAaf356eJ2tgSbeuCDeU27lpsS1iE +FHX8SP0Fr0B4bld1toJjWnd3F5mN4rwOggxla5G0aodophiKusQLkHfNfgtfPdeA/C7+/ 6OlgvnRp/JBtt1eLWsdXCmQRJDyL6OE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b="nQ/NIdPX"; spf=none (imf04.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656942295; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=L6wSaDv21i8IBXuOCFtPFoc5AHwc9orKajt9IjPXWew=; b=DlOEryOGA/Eoq4lL/YHzkc/zgEPd/s3RBgKKqSnNJM0tmy/rZboxNQpuB+LHviXbeNp1dp iCq3A+/FecQz+6r/tgsSuX1Jtn1M6aGixvMv1MH63d2FSgP9NE+q6I61a6nm28i0v6tsPX L7h7G6SUOCXfqK2a87SEJiDz7GbqnVE= X-Stat-Signature: g8j94ous5wnsf9inmh1m59mehohraobb X-Rspamd-Queue-Id: B6C0540003 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b="nQ/NIdPX"; spf=none (imf04.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1656942291-162528 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 Mon, Jul 04, 2022 at 10:20:53AM +0200, Alexander Potapenko wrote: > What makes you think they are false positives? Is the scenario I > described above: > > """ > In particular, if the call to lookup_fast() in walk_component() > returns NULL, and lookup_slow() returns a valid dentry, then the > `seq` and `inode` will remain uninitialized until the call to > step_into() > """ > > impossible? Suppose step_into() has been called in non-RCU mode. The first thing it does is int err = handle_mounts(nd, dentry, &path, &seq); if (err < 0) return ERR_PTR(err); And handle_mounts() in non-RCU mode is path->mnt = nd->path.mnt; path->dentry = dentry; if (nd->flags & LOOKUP_RCU) { [unreachable code] } [code not touching seqp] if (unlikely(ret)) { [code not touching seqp] } else { *seqp = 0; /* out of RCU mode, so the value doesn't matter */ } return ret; In other words, the value seq argument of step_into() used to have ends up being never fetched and, in case step_into() gets past that if (err < 0) that value is replaced with zero before any further accesses. So it's a false positive; yes, strictly speaking compiler is allowd to do anything whatsoever if it manages to prove that the value is uninitialized. Realistically, though, especially since unsigned int is not allowed any trapping representations... If you want an test stripped of VFS specifics, consider this: int g(int n, _Bool flag) { if (!flag) n = 0; return n + 1; } int f(int n, _Bool flag) { int x; if (flag) x = n + 2; return g(x, flag); } Do your tools trigger on it?