All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Kohei Tarumizu <tarumizu.kohei@fujitsu.com>
Cc: catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	x86@kernel.org, hpa@zytor.com, rafael@kernel.org,
	mchehab+huawei@kernel.org, eugenis@google.com,
	tony.luck@intel.com, pcc@google.com, peterz@infradead.org,
	marcos@orca.pet, conor.dooley@microchip.com,
	nicolas.ferre@microchip.com, marcan@marcan.st,
	linus.walleij@linaro.org, arnd@arndb.de,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 6/8] x86: Add hardware prefetch control support for x86
Date: Wed, 18 May 2022 08:43:14 +0200	[thread overview]
Message-ID: <YoSVglItX1PhveEP@kroah.com> (raw)
In-Reply-To: <20220518063032.2377351-7-tarumizu.kohei@fujitsu.com>

On Wed, May 18, 2022 at 03:30:30PM +0900, Kohei Tarumizu wrote:
> +/*
> + * Returns the cpu number of the cpu_device(/sys/devices/system/cpu/cpuX)
> + * in the ancestor directory of prefetch_control.
> + *
> + * When initializing this driver, it is verified that the cache directory exists
> + * under cpuX device. Therefore, the third level up from prefetch_control is
> + * cpuX device as shown below.
> + *
> + * /sys/devices/system/cpu/cpuX/cache/indexX/prefetch_control
> + */
> +static inline unsigned int pfctl_dev_get_cpu(struct device *pfctl_dev)
> +{
> +	return pfctl_dev->parent->parent->parent->id;

As much fun as it is to see a function like this, that is not ok, and
never guaranteed to keep working, sorry.  Please find the device
properly, never assume a specific driver model topology as they are
guaranteed to break over time and never supposed to be static like this.



> +}
> +
> +static ssize_t
> +pfctl_show(struct device *pfctl_dev, struct device_attribute *attr, char *buf)
> +{
> +	unsigned int cpu = pfctl_dev_get_cpu(pfctl_dev);
> +	struct x86_pfctl_attr *xa;
> +	u64 val;
> +
> +	xa = container_of(attr, struct x86_pfctl_attr, attr);
> +
> +	rdmsrl_on_cpu(cpu, MSR_MISC_FEATURE_CONTROL, &val);
> +	return sysfs_emit(buf, "%d\n", val & xa->mask ? 0 : 1);
> +}
> +
> +struct write_info {
> +	u64 mask;
> +	bool enable;
> +};
> +
> +/*
> + * wrmsrl() in this patch is only done inside of an interrupt-disabled region
> + * to avoid a conflict of write access from other drivers,
> + */
> +static void pfctl_write(void *info)
> +{
> +	struct write_info *winfo = info;
> +	u64 reg;
> +
> +	reg = 0;
> +	rdmsrl(MSR_MISC_FEATURE_CONTROL, reg);
> +
> +	if (winfo->enable)
> +		reg &= ~winfo->mask;
> +	else
> +		reg |= winfo->mask;
> +
> +	wrmsrl(MSR_MISC_FEATURE_CONTROL, reg);
> +}
> +
> +/*
> + * MSR_MISC_FEATURE_CONTROL has "core" scope, so define the lock to avoid a
> + * conflict of write access from different logical processors in the same core.
> + */
> +static DEFINE_MUTEX(pfctl_mutex);
> +
> +static ssize_t
> +pfctl_store(struct device *pfctl_dev, struct device_attribute *attr,
> +	    const char *buf, size_t size)
> +{
> +	unsigned int cpu = pfctl_dev_get_cpu(pfctl_dev);
> +	struct x86_pfctl_attr *xa;
> +	struct write_info info;
> +
> +	xa = container_of(attr, struct x86_pfctl_attr, attr);
> +	info.mask = xa->mask;
> +
> +	if (strtobool(buf, &info.enable) < 0)
> +		return -EINVAL;
> +
> +	mutex_lock(&pfctl_mutex);
> +	smp_call_function_single(cpu, pfctl_write, &info, true);
> +	mutex_unlock(&pfctl_mutex);
> +
> +	return size;
> +}
> +
> +#define PFCTL_ATTR(_name, _level, _bit)					\
> +	struct x86_pfctl_attr attr_l##_level##_##_name = {		\
> +		.attr = __ATTR(_name, 0600, pfctl_show, pfctl_store),	\
> +		.mask = BIT_ULL(_bit), }
> +
> +static PFCTL_ATTR(hardware_prefetcher_enable,			1, 2);
> +static PFCTL_ATTR(hardware_prefetcher_enable,			2, 0);
> +static PFCTL_ATTR(ip_prefetcher_enable,				1, 3);
> +static PFCTL_ATTR(adjacent_cache_line_prefetcher_enable,	2, 1);
> +
> +static struct device_attribute *l1_attrs[] __ro_after_init = {

How do you know attributes are to be marked read only after init?  Do
other parts of the kernel do that?  I don't think the driver core
guarantees that at all.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Kohei Tarumizu <tarumizu.kohei@fujitsu.com>
Cc: rafael@kernel.org, peterz@infradead.org, catalin.marinas@arm.com,
	linus.walleij@linaro.org, dave.hansen@linux.intel.com,
	conor.dooley@microchip.com, hpa@zytor.com, will@kernel.org,
	mchehab+huawei@kernel.org, x86@kernel.org, mingo@redhat.com,
	eugenis@google.com, arnd@arndb.de, bp@alien8.de,
	tglx@linutronix.de, pcc@google.com,
	linux-arm-kernel@lists.infradead.org, marcos@orca.pet,
	tony.luck@intel.com, marcan@marcan.st,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 6/8] x86: Add hardware prefetch control support for x86
Date: Wed, 18 May 2022 08:43:14 +0200	[thread overview]
Message-ID: <YoSVglItX1PhveEP@kroah.com> (raw)
In-Reply-To: <20220518063032.2377351-7-tarumizu.kohei@fujitsu.com>

On Wed, May 18, 2022 at 03:30:30PM +0900, Kohei Tarumizu wrote:
> +/*
> + * Returns the cpu number of the cpu_device(/sys/devices/system/cpu/cpuX)
> + * in the ancestor directory of prefetch_control.
> + *
> + * When initializing this driver, it is verified that the cache directory exists
> + * under cpuX device. Therefore, the third level up from prefetch_control is
> + * cpuX device as shown below.
> + *
> + * /sys/devices/system/cpu/cpuX/cache/indexX/prefetch_control
> + */
> +static inline unsigned int pfctl_dev_get_cpu(struct device *pfctl_dev)
> +{
> +	return pfctl_dev->parent->parent->parent->id;

As much fun as it is to see a function like this, that is not ok, and
never guaranteed to keep working, sorry.  Please find the device
properly, never assume a specific driver model topology as they are
guaranteed to break over time and never supposed to be static like this.



> +}
> +
> +static ssize_t
> +pfctl_show(struct device *pfctl_dev, struct device_attribute *attr, char *buf)
> +{
> +	unsigned int cpu = pfctl_dev_get_cpu(pfctl_dev);
> +	struct x86_pfctl_attr *xa;
> +	u64 val;
> +
> +	xa = container_of(attr, struct x86_pfctl_attr, attr);
> +
> +	rdmsrl_on_cpu(cpu, MSR_MISC_FEATURE_CONTROL, &val);
> +	return sysfs_emit(buf, "%d\n", val & xa->mask ? 0 : 1);
> +}
> +
> +struct write_info {
> +	u64 mask;
> +	bool enable;
> +};
> +
> +/*
> + * wrmsrl() in this patch is only done inside of an interrupt-disabled region
> + * to avoid a conflict of write access from other drivers,
> + */
> +static void pfctl_write(void *info)
> +{
> +	struct write_info *winfo = info;
> +	u64 reg;
> +
> +	reg = 0;
> +	rdmsrl(MSR_MISC_FEATURE_CONTROL, reg);
> +
> +	if (winfo->enable)
> +		reg &= ~winfo->mask;
> +	else
> +		reg |= winfo->mask;
> +
> +	wrmsrl(MSR_MISC_FEATURE_CONTROL, reg);
> +}
> +
> +/*
> + * MSR_MISC_FEATURE_CONTROL has "core" scope, so define the lock to avoid a
> + * conflict of write access from different logical processors in the same core.
> + */
> +static DEFINE_MUTEX(pfctl_mutex);
> +
> +static ssize_t
> +pfctl_store(struct device *pfctl_dev, struct device_attribute *attr,
> +	    const char *buf, size_t size)
> +{
> +	unsigned int cpu = pfctl_dev_get_cpu(pfctl_dev);
> +	struct x86_pfctl_attr *xa;
> +	struct write_info info;
> +
> +	xa = container_of(attr, struct x86_pfctl_attr, attr);
> +	info.mask = xa->mask;
> +
> +	if (strtobool(buf, &info.enable) < 0)
> +		return -EINVAL;
> +
> +	mutex_lock(&pfctl_mutex);
> +	smp_call_function_single(cpu, pfctl_write, &info, true);
> +	mutex_unlock(&pfctl_mutex);
> +
> +	return size;
> +}
> +
> +#define PFCTL_ATTR(_name, _level, _bit)					\
> +	struct x86_pfctl_attr attr_l##_level##_##_name = {		\
> +		.attr = __ATTR(_name, 0600, pfctl_show, pfctl_store),	\
> +		.mask = BIT_ULL(_bit), }
> +
> +static PFCTL_ATTR(hardware_prefetcher_enable,			1, 2);
> +static PFCTL_ATTR(hardware_prefetcher_enable,			2, 0);
> +static PFCTL_ATTR(ip_prefetcher_enable,				1, 3);
> +static PFCTL_ATTR(adjacent_cache_line_prefetcher_enable,	2, 1);
> +
> +static struct device_attribute *l1_attrs[] __ro_after_init = {

How do you know attributes are to be marked read only after init?  Do
other parts of the kernel do that?  I don't think the driver core
guarantees that at all.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-05-18  6:43 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-18  6:30 [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and x86 Kohei Tarumizu
2022-05-18  6:30 ` Kohei Tarumizu
2022-05-18  6:30 ` [PATCH v4 1/8] drivers: base: Add hardware prefetch control core driver Kohei Tarumizu
2022-05-18  6:30   ` Kohei Tarumizu
2022-05-18  7:09   ` Greg KH
2022-05-18  7:09     ` Greg KH
2022-05-18 12:38     ` tarumizu.kohei
2022-05-18 12:38       ` tarumizu.kohei
2022-05-18  6:30 ` [PATCH v4 2/8] drivers: base: Add Kconfig/Makefile to build " Kohei Tarumizu
2022-05-18  6:30   ` Kohei Tarumizu
2022-05-18  7:04   ` Greg KH
2022-05-18  7:04     ` Greg KH
2022-05-20  6:42     ` tarumizu.kohei
2022-05-20  6:42       ` tarumizu.kohei
2022-05-18  6:30 ` [PATCH v4 3/8] soc: fujitsu: Add hardware prefetch control support for A64FX Kohei Tarumizu
2022-05-18  6:30   ` Kohei Tarumizu
2022-05-18  7:10   ` Greg KH
2022-05-18  7:10     ` Greg KH
2022-05-20  7:06     ` tarumizu.kohei
2022-05-20  7:06       ` tarumizu.kohei
2022-05-18  6:30 ` [PATCH v4 4/8] soc: fujitsu: Add Kconfig/Makefile to build hardware prefetch control driver Kohei Tarumizu
2022-05-18  6:30   ` Kohei Tarumizu
2022-05-18  6:30 ` [PATCH v4 5/8] arm64: Create cache sysfs directory without ACPI PPTT for hardware prefetch control Kohei Tarumizu
2022-05-18  6:30   ` Kohei Tarumizu
2022-05-18  7:09   ` Greg KH
2022-05-18  7:09     ` Greg KH
2022-05-20  7:00     ` tarumizu.kohei
2022-05-20  7:00       ` tarumizu.kohei
2022-05-18  6:30 ` [PATCH v4 6/8] x86: Add hardware prefetch control support for x86 Kohei Tarumizu
2022-05-18  6:30   ` Kohei Tarumizu
2022-05-18  6:43   ` Greg KH [this message]
2022-05-18  6:43     ` Greg KH
2022-05-20  6:30     ` tarumizu.kohei
2022-05-20  6:30       ` tarumizu.kohei
2022-05-18  6:44   ` Greg KH
2022-05-18  6:44     ` Greg KH
2022-05-20  6:40     ` tarumizu.kohei
2022-05-20  6:40       ` tarumizu.kohei
2022-05-18  6:30 ` [PATCH v4 7/8] x86: Add Kconfig/Makefile to build hardware prefetch control driver Kohei Tarumizu
2022-05-18  6:30   ` Kohei Tarumizu
2022-05-18  6:43   ` Greg KH
2022-05-18  6:43     ` Greg KH
2022-05-20  6:35     ` tarumizu.kohei
2022-05-20  6:35       ` tarumizu.kohei
2022-05-18  6:30 ` [PATCH v4 8/8] docs: ABI: Add sysfs documentation interface of " Kohei Tarumizu
2022-05-18  6:30   ` Kohei Tarumizu
2022-05-19  8:29 ` [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and x86 Hector Martin
2022-05-19  8:29   ` Hector Martin
2022-05-20  8:31   ` tarumizu.kohei
2022-05-20  8:31     ` tarumizu.kohei

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=YoSVglItX1PhveEP@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=conor.dooley@microchip.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=eugenis@google.com \
    --cc=hpa@zytor.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=marcos@orca.pet \
    --cc=mchehab+huawei@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=pcc@google.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=tarumizu.kohei@fujitsu.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /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.