Message ID | 20231202212217.243710-5-keescook@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp1960398vqy; Sat, 2 Dec 2023 13:22:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IHMH7pZ+dIS1fF9CEOx3P7SmvLeGwIQhKgAfQ7I063yzjUvyepbFBiD/pHTVLVWKNofIcjn X-Received: by 2002:a05:6a20:7492:b0:189:c46d:9790 with SMTP id p18-20020a056a20749200b00189c46d9790mr2486635pzd.30.1701552169624; Sat, 02 Dec 2023 13:22:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701552169; cv=none; d=google.com; s=arc-20160816; b=Yk0PIeilsRJOJsjDZSw0MCxaaYez2ICqwmVpJpp+MUvRZcEpTzRoQkUk7EyAKJiBr9 JpQApJA7O95uESRfDn6YLP6t3+XYL9809s35UxREO5mgjmmFVg/eahfVihcvb1MZ3619 8W+NQTX0kuqEYdmC3+NtmwsAT4E02aAgl+HIUx44B1KryPcL2ZExRLO/Qxrq4QSlAjdH 2okMjoxRLyWtB0Nn6DilS0H0bK5YeeMGIrcWA4o2cK1bIVOwUQS6XxHxRruenHKx/fKy VErwTt5Xwc5YAH9O0tp6lvPZ9GIT7g1KVreQ5LYkpmYGT8q1/YuaFzK2cOBngEVZFcIJ Pozg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=kr8v5ioi9yhGCNoI15AUxdx1ZJerS/H1pXIO2zt31RE=; fh=xnUE171Vllx0fx6ipOnwMghUt6fK18sSaxZfCDNQyQ4=; b=Mm7Fk6g0GnWxv/G93IkFge7PFeZpNxcohHERjj+14ZGpd5sOKX2fi54YlO5On6Q13I uv5viaH8oBGazmxH33gM8MHhcOzExiylgdug9zXOHnWRAPu2RZ2EtOmYbXAAq1IV7Im0 tcW64Ib6Fy4sY3eFAwVGtM9l4ybwwMmY/vv5Vje4CFqiAIIU34KzrgHNC/4QXmyngI43 K7kacrZtOEFJZ0y/PNd+ihU33nxWuhizJvbD4BHCqGojvuSL7HnOGDGqgI/V7VNVPF6t 5Xc+jwzEaD/GvJH8+2PbM60kCoRDmhPLZEs99Wbl1E6G4pQKE5EutT/bTZUibmdsZp6i TZtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=HqKQgTMB; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id y15-20020a63fa0f000000b005c663b4fcc5si1167692pgh.458.2023.12.02.13.22.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 13:22:49 -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=@chromium.org header.s=google header.b=HqKQgTMB; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id B0D79806500D; Sat, 2 Dec 2023 13:22:45 -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 S232430AbjLBVW3 (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Sat, 2 Dec 2023 16:22:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbjLBVWT (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 2 Dec 2023 16:22:19 -0500 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 323A5196 for <linux-kernel@vger.kernel.org>; Sat, 2 Dec 2023 13:22:25 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1d0538d9bbcso15662195ad.3 for <linux-kernel@vger.kernel.org>; Sat, 02 Dec 2023 13:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1701552144; x=1702156944; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kr8v5ioi9yhGCNoI15AUxdx1ZJerS/H1pXIO2zt31RE=; b=HqKQgTMBVxs/PT2XUTy4QRahXlfSOpb+2P7T6oLQzKCBFsyL7sId4K0GghvgK21Uv5 H5hmnBcZgSJAEkhxmg+UmVxXMrgpE0bVBwDomQhPXq2/gEX0wmzoCY5h0EdL4M5urKgz uNQvfiQYtnror4SJNB7CNjTQ9HpIyDwmvJ07A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701552144; x=1702156944; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kr8v5ioi9yhGCNoI15AUxdx1ZJerS/H1pXIO2zt31RE=; b=BrHE/YOsaG1NFZi75qH80lZoAZi7czM1aO1aAfiErbNUYMhTO9Ukg4bDaQbLNV896H liFmzLcAduJvCWmeGjLQLx3vJdsLHe15y0Qu7CmhONagN7f+ZnDxm1jbGy0nee+QyK3a QspSm4t+ZoETfPmFe4WIfpY9ld99fouNNILbIIOMQFPYF+GEcVblvT4ModxM4h97BYbN 5ZYSlT34j/bYDl8HKgnU+NkX3j9du04wSCpwHhQ68OfTdZ/lOZcwek/7EajfClRhNpqr ac942qIFuUY0VN7etcDzLWhucwYdVbtJZF/BVDJpPqy2gNq8tBuWXig52ZrgZQDsVVf6 vheA== X-Gm-Message-State: AOJu0YyFMrnLz68LSLr8tDNi65d5qeJ6mWtek9nMfTTnMzLbwmSVqwop 2W0XFa7+S3Gc3LJBCZn1hwdAZA== X-Received: by 2002:a17:903:22c5:b0:1d0:6ffd:e2c7 with SMTP id y5-20020a17090322c500b001d06ffde2c7mr2044102plg.97.1701552144686; Sat, 02 Dec 2023 13:22:24 -0800 (PST) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id m10-20020a170902db0a00b001cfb971edf2sm5607037plx.13.2023.12.02.13.22.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 13:22:23 -0800 (PST) From: Kees Cook <keescook@chromium.org> To: "Guilherme G. Piccoli" <gpiccoli@igalia.com> Cc: Kees Cook <keescook@chromium.org>, Tony Luck <tony.luck@intel.com>, linux-hardening@vger.kernel.org, Christian Brauner <brauner@kernel.org>, "Peter Zijlstra (Intel)" <peterz@infradead.org>, Al Viro <viro@zeniv.linux.org.uk>, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [PATCH 5/5] pstore: inode: Use cleanup.h for struct pstore_private Date: Sat, 2 Dec 2023 13:22:15 -0800 Message-Id: <20231202212217.243710-5-keescook@chromium.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231202211535.work.571-kees@kernel.org> References: <20231202211535.work.571-kees@kernel.org> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1987; i=keescook@chromium.org; h=from:subject; bh=2VOJhxKhawry4zB5INkZO9i8H3FTFJSHkB6X8kUlVPU=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBla6AGDW8hXonEKigawraWf7F2wiPHsStg+E08f Sxgn4os0kCJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCZWugBgAKCRCJcvTf3G3A JhTDEACNiMPD3b67gn9zNW4/ju9hFrGMsJjSQ7KEHIZH8TvkblvRnwZFbrVAPlbHrhqyzPnosiv RrgJmNPJReV/CWU6tQkLFnyPFYc9GKeS0lBBFOcMLGu/XDM9G/Sjv+ZeYTyfyOW6IeluJIuMPBf EJyjm2w/tlZMPldQNw5gwettLVjEjThBz1y/LgIQwtWWgiUzfLyYeApXA1LCey9bZ2OkCUchwgW 0BKcL2Puv1CtHOHwZ/FQ/MyqA2ADGyA4mrpGl7d4toQk4uECTTsv+qOtu/6wKASvbYy4QIJmLWE xkeWVRWohYcqWeUg9DoahE3IcWnA0ry6NNlMLpUtEmhx+U7CqpYXT5ejREJ3h1deBf8Gwivt1de UoDxTsF8u5rZwsrK6livq2nG+q45XPK+SCG6CzZ+bCU4FxSdppDD9d7KyQr1p2YWc8KqZvCSIdK UCZepXh6abHECZC7ZgiPujvwxB3UBFpStBlAeWso5EUm800a0CUyB6/poJiZyAUd6O7/Hh2GOds jnhPwrkBxp+1gXEEjY4QOy+zay5bdrkNrVQ6ZsF5UwBRGPUx0o+WG6TKpWWoILlQ4mJ1YeZMgj3 6c0WQUcvUTwxxJtuLLMynSwKn6uBKeMJRkc+EY51mYXZ4kw+4CricAYkzOAVyvaeCuKucDZCiFH Ngx7gfISAw/fzgA== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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: <linux-kernel.vger.kernel.org> 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]); Sat, 02 Dec 2023 13:22:45 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784206768130110014 X-GMAIL-MSGID: 1784206768130110014 |
Series |
pstore: Initial use of cleanup.h
|
|
Commit Message
Kees Cook
Dec. 2, 2023, 9:22 p.m. UTC
Simplify error path when "private" needs to be freed.
Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
fs/pstore/inode.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
Comments
On Sat, Dec 02, 2023 at 01:22:15PM -0800, Kees Cook wrote: > static void *pstore_ftrace_seq_start(struct seq_file *s, loff_t *pos) > { > @@ -338,9 +339,8 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) > { > struct dentry *dentry; > struct inode *inode __free(iput) = NULL; > - int rc = 0; > char name[PSTORE_NAMELEN]; > - struct pstore_private *private, *pos; > + struct pstore_private *private __free(pstore_private) = NULL, *pos; > size_t size = record->size + record->ecc_notice_size; > > if (WARN_ON(!inode_is_locked(d_inode(root)))) > @@ -356,7 +356,6 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) > return -EEXIST; > } > > - rc = -ENOMEM; > inode = pstore_get_inode(root->d_sb); > if (!inode) > return -ENOMEM; > @@ -373,7 +372,7 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) > > dentry = d_alloc_name(root, name); > if (!dentry) > - goto fail_private; > + return -ENOMEM; > > private->dentry = dentry; > private->record = record; > @@ -386,13 +385,9 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) > > d_add(dentry, no_free_ptr(inode)); > > - list_add(&private->list, &records_list); > + list_add(&(no_free_ptr(private))->list, &records_list); That's really brittle. It critically depends upon having no failure exits past the assignment to ->i_private; once you've done that, you have transferred the ownership of that thing to the inode (look at your ->evict_inode()). But you can't say inode->i_private = no_free_ptr(private); since you are using private past that point.
On Sat, Dec 02, 2023 at 10:27:06PM +0000, Al Viro wrote: > On Sat, Dec 02, 2023 at 01:22:15PM -0800, Kees Cook wrote: > > > static void *pstore_ftrace_seq_start(struct seq_file *s, loff_t *pos) > > { > > @@ -338,9 +339,8 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) > > { > > struct dentry *dentry; > > struct inode *inode __free(iput) = NULL; > > - int rc = 0; > > char name[PSTORE_NAMELEN]; > > - struct pstore_private *private, *pos; > > + struct pstore_private *private __free(pstore_private) = NULL, *pos; > > size_t size = record->size + record->ecc_notice_size; > > > > if (WARN_ON(!inode_is_locked(d_inode(root)))) > > @@ -356,7 +356,6 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) > > return -EEXIST; > > } > > > > - rc = -ENOMEM; > > inode = pstore_get_inode(root->d_sb); > > if (!inode) > > return -ENOMEM; > > @@ -373,7 +372,7 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) > > > > dentry = d_alloc_name(root, name); > > if (!dentry) > > - goto fail_private; > > + return -ENOMEM; > > > > private->dentry = dentry; > > private->record = record; > > @@ -386,13 +385,9 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) > > > > d_add(dentry, no_free_ptr(inode)); > > > > - list_add(&private->list, &records_list); > > + list_add(&(no_free_ptr(private))->list, &records_list); > > That's really brittle. It critically depends upon having no failure > exits past the assignment to ->i_private; once you've done that, > you have transferred the ownership of that thing to the inode > (look at your ->evict_inode()). I guess so, but it was already that way, and it isn't assignment to i_private until everything else is "done", apart from adding to the dentry and the pstore internal list. > But you can't say > inode->i_private = no_free_ptr(private); > since you are using private past that point. True. How about this reordering: if (record->time.tv_sec) inode_set_mtime_to_ts(inode, inode_set_ctime_to_ts(inode, record->time)); list_add(&private->list, &records_list); inode->i_private = no_free_ptr(private); d_add(dentry, no_free_ptr(inode)); But none of this gets into how you'd like to see the iput handled. If you'd prefer, I can just define a pstore_iput handler and you don't have to look at it at all. :) -Kees
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c index 20a88e34ea7c..7d49f0c70dff 100644 --- a/fs/pstore/inode.c +++ b/fs/pstore/inode.c @@ -61,6 +61,7 @@ static void free_pstore_private(struct pstore_private *private) } kfree(private); } +DEFINE_FREE(pstore_private, struct pstore_private *, free_pstore_private(_T)); static void *pstore_ftrace_seq_start(struct seq_file *s, loff_t *pos) { @@ -338,9 +339,8 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) { struct dentry *dentry; struct inode *inode __free(iput) = NULL; - int rc = 0; char name[PSTORE_NAMELEN]; - struct pstore_private *private, *pos; + struct pstore_private *private __free(pstore_private) = NULL, *pos; size_t size = record->size + record->ecc_notice_size; if (WARN_ON(!inode_is_locked(d_inode(root)))) @@ -356,7 +356,6 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) return -EEXIST; } - rc = -ENOMEM; inode = pstore_get_inode(root->d_sb); if (!inode) return -ENOMEM; @@ -373,7 +372,7 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) dentry = d_alloc_name(root, name); if (!dentry) - goto fail_private; + return -ENOMEM; private->dentry = dentry; private->record = record; @@ -386,13 +385,9 @@ int pstore_mkfile(struct dentry *root, struct pstore_record *record) d_add(dentry, no_free_ptr(inode)); - list_add(&private->list, &records_list); + list_add(&(no_free_ptr(private))->list, &records_list); return 0; - -fail_private: - free_pstore_private(private); - return rc; } /*