Received: by 2002:a05:7412:6592:b0:d7:7d3a:4fe2 with SMTP id m18csp1579795rdg; Sat, 12 Aug 2023 07:09:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGz//FJ3kxa32rZTzXLtHcwVLGWMfMNrcqMQ94NkYw2xQhRo2C8kZ0sxNCKZiS91AiBLFej X-Received: by 2002:a17:90a:f3ca:b0:268:de26:b794 with SMTP id ha10-20020a17090af3ca00b00268de26b794mr2560865pjb.40.1691849369471; Sat, 12 Aug 2023 07:09:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691849369; cv=none; d=google.com; s=arc-20160816; b=gZ9Ides5G8Ef0e6QS47HBQw/f/c5jBvfANpu8Lgbhwqr/Hp8BZ+Ga2G+KxdNtEXj28 0q2rjdKQCHKs+ZQOhCnoKLHqQDlqnLymDhAONo5yqg/xp7WQhHqr5SaQXfYtYMez5VA8 /Wm5GAHptZFMvNv/OuFcAAp1jbPO9pSmficUG89MMYi7u5wEVGgmUVak/5Y9zHkamRy0 TeLHBxICR32YqJmGY40tzKwDLKu/QzUlwEXwdyPtxJyxF7NjWIgYYcLQ5xVjMOVNvlK/ oG16aLxZEJKC62fOr2/tK1nCHnYvc6Qo+jRBrpAVhk9fAYvjdkt7XNBtWJsMHhhCYJ9V 8mmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:mime-version:date :message-id:dkim-signature; bh=Fqt2wJEWejkebi/tcaNK7bvi1K+XrjfQTFtxczBBY+Q=; fh=eWWij1sEDHNJXuIMKH6FsZ7Lrks3d/EwiMjB3SAfihg=; b=I+l5FWUbaHOIP0byeUnU1eQV9BC9p/FpTmsFzPsItGu9bWtMJy5irJcZG7qlzUBu6u yFOKLmKQW/evgSkwIpOdQ93k2z8ZA5QYJoXN0ZKSyx+IhemCUt207mdcr+bZxhcpA9Ov RaeREX4DQlLJlmhWJpAeD97KO2tKHJGV1pCVVToGciBeRF+W3oGcciU/PI0jPzNMgCU8 tNqEzE0xPK67yEfSbcuibQhr6QtaJNcnWw0pA+TegoyZTnXH3WqO1SxpA3aGK4MFSBI6 8Pgezjt6jPt7j0cCgBykrODQQlNitG463FhmOUiS/G9CtUy/FR4Kn6f0WU8hYszPS8FV el/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jAiS+JBe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o3-20020a17090a9f8300b0025690b76c95si4929100pjp.10.2023.08.12.07.09.16; Sat, 12 Aug 2023 07:09:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jAiS+JBe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232786AbjHLNZ0 (ORCPT + 99 others); Sat, 12 Aug 2023 09:25:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229555AbjHLNZY (ORCPT ); Sat, 12 Aug 2023 09:25:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D41C312D; Sat, 12 Aug 2023 06:25:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6A515616C0; Sat, 12 Aug 2023 13:25:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A5EEC433C8; Sat, 12 Aug 2023 13:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691846726; bh=acH4iXVTyH8arS/ZaHuARQxhgHeP/BeIYrb55TADdkU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=jAiS+JBekZTpk11e3gPdsoJbBUwLcAk1BW7fhTrlvoEpXh1oHTasqLgyWGfcZPSzz 4/ibQ9r78l0t5JL+dg6qjHC3AzfI/Md+HLbZVAkEyHIn8MKPtfdb+DLqIIZwr30hZp cG+easCVHSQevriIlAyaxuy5/S3A/ww2WWJ5593CgthT3siQLb3Cxz+xPzaUwXZ1Fo brm+K7/WXhcp2THjIIXfHj5b8Q4mtzIe1ae67QJ5gbUppBdUYakj8BHhkoAlDo51s1 buIH8ZeLnl+FPQe+VWTCEKaRx5fKCspy1uALEsuSEImjrjNAeJ9UiYUgJnW9Tu8RTp f28LAOd2evR2w== Message-ID: <7c045f1e-4d20-b798-bd74-8e8b9d8ea7e6@kernel.org> Date: Sat, 12 Aug 2023 16:25:21 +0300 MIME-Version: 1.0 Subject: Re: [PATCH v3 1/3] debugfs: Add write support to debugfs_create_str() Content-Language: en-US To: Greg KH , Mike Tipton Cc: rafael@kernel.org, corbet@lwn.net, linux-pm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, quic_okukatla@quicinc.com, quic_viveka@quicinc.com, peterz@infradead.org, quic_pkondeti@quicinc.com References: <20230807142914.12480-1-quic_mdtipton@quicinc.com> <20230807142914.12480-2-quic_mdtipton@quicinc.com> <2023081203-happier-mutable-e4f0@gregkh> From: Georgi Djakov In-Reply-To: <2023081203-happier-mutable-e4f0@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, Thanks for the comments! On 12.08.23 13:40, Greg KH wrote: > On Mon, Aug 07, 2023 at 07:29:12AM -0700, Mike Tipton wrote: >> Currently, debugfs_create_str() only supports reading strings from >> debugfs. Add support for writing them as well. >> >> Based on original implementation by Peter Zijlstra [0]. Write support >> was present in the initial patch version, but dropped in v2 due to lack >> of users. We have a user now, so reintroduce it. >> >> [0] https://lore.kernel.org/all/YF3Hv5zXb%2F6lauzs@hirez.programming.kicks-ass.net/ >> >> Signed-off-by: Mike Tipton >> --- >> fs/debugfs/file.c | 48 +++++++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 46 insertions(+), 2 deletions(-) >> >> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c >> index b7711888dd17..87b3753aa4b1 100644 >> --- a/fs/debugfs/file.c >> +++ b/fs/debugfs/file.c >> @@ -904,8 +904,52 @@ EXPORT_SYMBOL_GPL(debugfs_create_str); >> static ssize_t debugfs_write_file_str(struct file *file, const char __user *user_buf, >> size_t count, loff_t *ppos) >> { >> - /* This is really only for read-only strings */ >> - return -EINVAL; >> + struct dentry *dentry = F_DENTRY(file); >> + char *old, *new = NULL; >> + int pos = *ppos; >> + int r; >> + >> + r = debugfs_file_get(dentry); >> + if (unlikely(r)) >> + return r; >> + >> + old = *(char **)file->private_data; >> + >> + /* only allow strict concatenation */ >> + r = -EINVAL; >> + if (pos && pos != strlen(old)) >> + goto error; >> + >> + r = -E2BIG; >> + if (pos + count + 1 > PAGE_SIZE) >> + goto error; >> + >> + r = -ENOMEM; >> + new = kmalloc(pos + count + 1, GFP_KERNEL); >> + if (!new) >> + goto error; >> + >> + if (pos) >> + memcpy(new, old, pos); >> + >> + r = -EFAULT; >> + if (copy_from_user(new + pos, user_buf, count)) >> + goto error; >> + >> + new[pos + count] = '\0'; >> + strim(new); >> + >> + rcu_assign_pointer(*(char **)file->private_data, new); >> + synchronize_rcu(); >> + kfree(old); >> + >> + debugfs_file_put(dentry); >> + return count; >> + >> +error: >> + kfree(new); >> + debugfs_file_put(dentry); >> + return r; >> } > > So you just added write support for ALL debugfs files that use the > string interface, what did you just allow to break? Not really. According to the existing code, the write support for strings is enabled only when the file is created with +w permissions. For read-only files, we use fops_str_ro, which is the case for all existing string files: $ git grep -w debugfs_create_str | egrep -v "fs/debugfs/file.c|include/linux/debugfs.h" drivers/firmware/arm_scmi/driver.c: debugfs_create_str("instance_name", 0400, top_dentry, drivers/firmware/arm_scmi/driver.c: debugfs_create_str("type", 0400, trans, (char **)&dbg->type); drivers/opp/debugfs.c: debugfs_create_str("of_name", S_IRUGO, d, (char **)&opp->of_name); For fops_str_ro, the .write function is not implemented, so nothing should break? > I recommend just using your own debugfs file function instead, as this > could cause bad problems, right? Agree, and that should be exactly what this patch does. > Are you sure that all string calls can > handle the variable be freed underneath it like this call will allow to > happen? Looks fine, at least for this patch-set. Thanks, Georgi