Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp104148rdb; Mon, 4 Dec 2023 23:02:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IGIuo/im5/Tn6rQwh+i3nj6yxWc/4dniYWplOhDQPbRMr3g2FA2g2P22cuGh69CxiZmJPJl X-Received: by 2002:aa7:9889:0:b0:6ce:696f:d0f5 with SMTP id r9-20020aa79889000000b006ce696fd0f5mr550577pfl.31.1701759732425; Mon, 04 Dec 2023 23:02:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701759732; cv=none; d=google.com; s=arc-20160816; b=QWwQPZ0j6a4HsOZwNfce4f057z7CfEVFyVn+lGVZNT08bKILhyqXJlFaKvK/mw04YA plHTFiWQnHt/GtWQsTzS3O8CdcSakIGMVkY71n0pdT7jNUrxTOLGDbW+8Jv9OiAiY8G7 8cthPvsfOhZX7Iqeu0mdY4pcVxb1fuN1Ic/W21feWkj9/rNS4ClyCcGdx1L7fOwo4HuZ QdX8aSdrjAYWT0qdqJNvv95dHo1f5Sg2JVN5lGxjCueLutpjH078cb314Ff9WuWw2byh 3oXFXotiXy8crK07nqIVhqKAI8s5HNFVQOPgYD/clb8Lb1VzCANkNKIsy3G14X2MwS8Y deXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=0WHU/5DxAV5pvSXplC2cxt/UjGS3r4Zdun9PgLyN7QY=; fh=PbLBVLlHShwp+DvKEuWJf7ohA3qxCX5SRX3Xq9LeDoE=; b=Kp5vWmJfKmWyvpMYm+R3QfZns0uPTmYMoa+gaRNCONSujGhajEZWmVn49iZy/Wrbxz 7BAKOzkwUi9+EpGBgVKeGjZy1xet9nnwaSw2HlS4I/jWkPztW34Rz044B0lpQEKI8YJp 0JjfM836iNiPhelZ5x+fGz//KdIAB4itIHXAbjA+mXJiOTtLsMnQXcppQvh3W/HySlYy hIdzBmVcmPrrvwdOLUL81LIblk+9w1kEJOQQ+agj07lGstPyds2wgcWoDBGNqdTiZCeg y+5+SkwS6Dbl7yqGvaxLmYONVDFf9OsHGtclyGhl44JmV8sClvwBiw6rXbSkph+tFIX+ w7cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=xkuupgjn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=fromorbit.com Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id y185-20020a6364c2000000b005c660acad7asi5079910pgb.4.2023.12.04.23.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 23:02:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=xkuupgjn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=fromorbit.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id A64E68048C0D; Mon, 4 Dec 2023 23:02:09 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344525AbjLEHBy (ORCPT + 99 others); Tue, 5 Dec 2023 02:01:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231860AbjLEHBw (ORCPT ); Tue, 5 Dec 2023 02:01:52 -0500 Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 042CE11F for ; Mon, 4 Dec 2023 23:01:58 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3b845ba9ba9so3352641b6e.3 for ; Mon, 04 Dec 2023 23:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1701759717; x=1702364517; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0WHU/5DxAV5pvSXplC2cxt/UjGS3r4Zdun9PgLyN7QY=; b=xkuupgjne468/xDrloQG3j70wdp/YRLRTn6Lhl7XN7iec2+FtWsavNmvWimHh34NsS 0p+1vo1JW4qv5wLLLaW9Eda3phiFM1MxucExFILcs+QnDf1N1JrZgKM16ZRnWTcJVTaw h1z6IQpm61yaPALqyhiaCro0HMijsK6M2JbN6Infm9u3Xd64Fg/Vb8lhIyIO4esOH6Xq XTSzklRMUcGOCrV0JeKShYcrGVzHQJlqCLVP2cDnXofGiWufgJJVMROGR1VAIbVbSbe3 hRJJgk6T4likZuD9PWppoLtSsnZWrotkXJoFyINfI4+kwHZdUjGhp5DHayyAsYPuLu3n Uypg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701759717; x=1702364517; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0WHU/5DxAV5pvSXplC2cxt/UjGS3r4Zdun9PgLyN7QY=; b=d1KFzhbIafFqAWAaT3ZtzUwMAka4Wxp6WaiIjmTO8j/MrCN8Xb84goPVeUhxVAl4sR X1DPXozQFeytD7ovnFXZ8A7GhN+kG035QXVAU+EwSzBRpc7NKm1++1OhRcuKhGrfyOud S+VwtoDcmubH9Mp5lRuGTVtfYUE+h4oMmmu4efJGAI9uxnwEkysfZIy+f/P6X3rv8ZCd MUpmIx0fyHRtlkWAxRXql/lqCBet3is+o0IIpO8x/megrSuiEaRKUU5wIZBlEgOv8FQZ PJy9Aq8/Zw8ZFmjUCbciZNbroMl7kFeE+49ytVMwPep8YCu+jRKofNeIQJfUZ6O+zEAS VAwQ== X-Gm-Message-State: AOJu0Yz/s2HhKioRabmAmZ8IoJE93dnYBc+WdWzYqySWnCk/6HiQcKys G6/YU2boZYMFrKW1LWfzA3c2hA== X-Received: by 2002:a05:6871:4318:b0:1fb:75c:3fea with SMTP id lu24-20020a056871431800b001fb075c3feamr6891719oab.74.1701759715826; Mon, 04 Dec 2023 23:01:55 -0800 (PST) Received: from dread.disaster.area (pa49-180-125-5.pa.nsw.optusnet.com.au. [49.180.125.5]) by smtp.gmail.com with ESMTPSA id v4-20020a634644000000b0058901200bbbsm8671692pgk.40.2023.12.04.23.01.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 23:01:55 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rAPRJ-0044q7-0q; Tue, 05 Dec 2023 18:01:53 +1100 Date: Tue, 5 Dec 2023 18:01:53 +1100 From: Dave Chinner To: Kees Cook Cc: "Guilherme G. Piccoli" , Tony Luck , linux-hardening@vger.kernel.org, Christian Brauner , "Peter Zijlstra (Intel)" , Al Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 2/5] pstore: inode: Convert mutex usage to guard(mutex) Message-ID: References: <20231202211535.work.571-kees@kernel.org> <20231202212217.243710-2-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231202212217.243710-2-keescook@chromium.org> X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 04 Dec 2023 23:02:09 -0800 (PST) On Sat, Dec 02, 2023 at 01:22:12PM -0800, Kees Cook wrote: > Replace open-coded mutex handling with cleanup.h guard(mutex) and > scoped_guard(mutex, ...). > > Cc: "Guilherme G. Piccoli" > Cc: Tony Luck > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Kees Cook > --- > fs/pstore/inode.c | 76 +++++++++++++++++++---------------------------- > 1 file changed, 31 insertions(+), 45 deletions(-) This doesn't really feel like an improvement. WE've gone from clearly defined lock/unlock pairings to macro wrapped code that hides scoping from the reader. I'm going to have to to continually remind myself that this weird looking code doesn't actually leak locks just because it returns from a function with a lock held. That's 20 years of logic design and pattern matching practice I'm going to have to break, and I feel that's going to make it harder for me to maintain and review code sanely as a result. > diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c > index 20f3452c8196..0d89e0014b6f 100644 > --- a/fs/pstore/inode.c > +++ b/fs/pstore/inode.c > @@ -180,25 +180,21 @@ static int pstore_unlink(struct inode *dir, struct dentry *dentry) > { > struct pstore_private *p = d_inode(dentry)->i_private; > struct pstore_record *record = p->record; > - int rc = 0; > > if (!record->psi->erase) > return -EPERM; > > /* Make sure we can't race while removing this file. */ > - mutex_lock(&records_list_lock); > - if (!list_empty(&p->list)) > - list_del_init(&p->list); > - else > - rc = -ENOENT; > - p->dentry = NULL; > - mutex_unlock(&records_list_lock); > - if (rc) > - return rc; > - > - mutex_lock(&record->psi->read_mutex); > - record->psi->erase(record); > - mutex_unlock(&record->psi->read_mutex); > + scoped_guard(mutex, &records_list_lock) { > + if (!list_empty(&p->list)) > + list_del_init(&p->list); > + else > + return -ENOENT; > + p->dentry = NULL; > + } > + > + scoped_guard(mutex, &record->psi->read_mutex) > + record->psi->erase(record); And now we combine the new-fangled shiny with a mechanical change that lacks critical thinking about the logic of the code. Why drop the mutex only to have to pick it back up again when the scoping handles the error case automatically? i.e.: scoped_guard(mutex, &records_list_lock) { if (!list_empty(&p->list)) list_del_init(&p->list); else return -ENOENT; p->dentry = NULL; record->psi->erase(record); } Not a fan of the required indenting just for critical sections; this will be somewhat nasty when multiple locks need to be take. > @@ -317,19 +310,19 @@ int pstore_put_backend_records(struct pstore_info *psi) > if (!root) > return 0; > > - mutex_lock(&records_list_lock); > - list_for_each_entry_safe(pos, tmp, &records_list, list) { > - if (pos->record->psi == psi) { > - list_del_init(&pos->list); > - rc = simple_unlink(d_inode(root), pos->dentry); > - if (WARN_ON(rc)) > - break; > - d_drop(pos->dentry); > - dput(pos->dentry); > - pos->dentry = NULL; > + scoped_guard(mutex, &records_list_lock) { > + list_for_each_entry_safe(pos, tmp, &records_list, list) { > + if (pos->record->psi == psi) { > + list_del_init(&pos->list); > + rc = simple_unlink(d_inode(root), pos->dentry); > + if (WARN_ON(rc)) > + break; > + d_drop(pos->dentry); > + dput(pos->dentry); > + pos->dentry = NULL; > + } > } > } > - mutex_unlock(&records_list_lock); This doesn't even save a line of code - there's no actual scoping needed here because there is no return from within the loop. But with a scoped guard we have to add an extra layer of indentation. Not a fan of that, either. > @@ -449,9 +439,8 @@ static int pstore_fill_super(struct super_block *sb, void *data, int silent) > if (!sb->s_root) > return -ENOMEM; > > - mutex_lock(&pstore_sb_lock); > - pstore_sb = sb; > - mutex_unlock(&pstore_sb_lock); > + scoped_guard(mutex, &pstore_sb_lock) > + pstore_sb = sb; > > pstore_get_records(0); > > @@ -466,17 +455,14 @@ static struct dentry *pstore_mount(struct file_system_type *fs_type, > > static void pstore_kill_sb(struct super_block *sb) > { > - mutex_lock(&pstore_sb_lock); > + guard(mutex)(&pstore_sb_lock); > WARN_ON(pstore_sb && pstore_sb != sb); > > kill_litter_super(sb); > pstore_sb = NULL; > > - mutex_lock(&records_list_lock); > + guard(mutex)(&records_list_lock); > INIT_LIST_HEAD(&records_list); > - mutex_unlock(&records_list_lock); > - > - mutex_unlock(&pstore_sb_lock); > } And this worries me, because guard() makes it harder to see where locks are nested and the scope they apply to. At least with lock/unlock pairs the scope of the critical sections and the nestings are obvious. So, yeah, i see that there is a bit less code with these fancy new macros, but I don't think it's made the code is easier to read and maintain at all. Just my 2c worth... -Dave. -- Dave Chinner david@fromorbit.com