All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avadhut Naik <avadhut.naik@amd.com>
To: <linux-acpi@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>
Cc: <rafael@kernel.org>, <gregkh@linuxfoundation.org>,
	<lenb@kernel.org>, <james.morse@arm.com>, <tony.luck@intel.com>,
	<bp@alien8.de>, <linux-kernel@vger.kernel.org>,
	<alexey.kardashevskiy@amd.com>, <yazen.ghannam@amd.com>,
	<avadnaik@amd.com>
Subject: [PATCH v6 3/4] platform/chrome: cros_ec_debugfs: Fix permissions for panicinfo
Date: Thu, 16 Nov 2023 16:47:24 -0600	[thread overview]
Message-ID: <20231116224725.3695952-4-avadhut.naik@amd.com> (raw)
In-Reply-To: <20231116224725.3695952-1-avadhut.naik@amd.com>

From: Avadhut Naik <Avadhut.Naik@amd.com>

The debugfs_create_blob() function has been used to create read-only binary
blobs in debugfs. The function filters out permissions, other than S_IRUSR,
S_IRGRP and S_IROTH, provided while creating the blobs.

The very behavior though is being changed through previous patch in the
series (fs: debugfs: Add write functionality to debugfs blobs) which makes
the binary blobs writable by owners. Thus, all permissions provided while
creating the blobs, except S_IRUSR,S_IWUSR, S_IRGRP, S_IROTH, will be
filtered by debugfs_create_blob().

As such, rectify the permissions of panicinfo file since the S_IFREG flag
was anyways being filtered out by debugfs_create_blob(). Moreover, the
very flag will always be set be set for the panicinfo file through
__debugfs_create_file().

Signed-off-by: Avadhut Naik <Avadhut.Naik@amd.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
 drivers/platform/chrome/cros_ec_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/chrome/cros_ec_debugfs.c b/drivers/platform/chrome/cros_ec_debugfs.c
index 091fdc154d79..6bf6f0e7b597 100644
--- a/drivers/platform/chrome/cros_ec_debugfs.c
+++ b/drivers/platform/chrome/cros_ec_debugfs.c
@@ -454,7 +454,7 @@ static int cros_ec_create_panicinfo(struct cros_ec_debugfs *debug_info)
 	debug_info->panicinfo_blob.data = data;
 	debug_info->panicinfo_blob.size = ret;
 
-	debugfs_create_blob("panicinfo", S_IFREG | 0444, debug_info->dir,
+	debugfs_create_blob("panicinfo", 0444, debug_info->dir,
 			    &debug_info->panicinfo_blob);
 
 	return 0;
-- 
2.34.1


  parent reply	other threads:[~2023-11-16 22:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-16 22:47 [PATCH v6 0/4] Add support for Vendor Defined Error Types in Einj Module Avadhut Naik
2023-11-16 22:47 ` [PATCH v6 1/4] ACPI: APEI: EINJ: Refactor available_error_type_show() Avadhut Naik
2023-11-16 22:55   ` Luck, Tony
2023-11-16 22:47 ` [PATCH v6 2/4] fs: debugfs: Add write functionality to debugfs blobs Avadhut Naik
2023-11-16 22:47 ` Avadhut Naik [this message]
2023-11-16 22:47 ` [PATCH v6 4/4] ACPI: APEI: EINJ: Add support for vendor defined error types Avadhut Naik
2023-11-21 20:12 ` [PATCH v6 0/4] Add support for Vendor Defined Error Types in Einj Module Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231116224725.3695952-4-avadhut.naik@amd.com \
    --to=avadhut.naik@amd.com \
    --cc=alexey.kardashevskiy@amd.com \
    --cc=avadnaik@amd.com \
    --cc=bp@alien8.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.morse@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=yazen.ghannam@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.