[RESEND PATCH v5 4/4] docs: ABI: sysfs-bus-nvdimm: Document sysfs event format entries for nvdimm pmu
Details are added for the event, cpumask and format attributes in the ABI documentation. Signed-off-by: Kajol Jain --- Documentation/ABI/testing/sysfs-bus-nvdimm | 35 ++ 1 file changed, 35 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm index bff84a16812a..64004d5e4840 100644 --- a/Documentation/ABI/testing/sysfs-bus-nvdimm +++ b/Documentation/ABI/testing/sysfs-bus-nvdimm @@ -6,3 +6,38 @@ Description: The libnvdimm sub-system implements a common sysfs interface for platform nvdimm resources. See Documentation/driver-api/nvdimm/. + +What: /sys/bus/event_source/devices/nmemX/format +Date: September 2021 +KernelVersion: 5.16 +Contact:Kajol Jain +Description: (RO) Attribute group to describe the magic bits + that go into perf_event_attr.config for a particular pmu. + (See ABI/testing/sysfs-bus-event_source-devices-format). + + Each attribute under this group defines a bit range of the + perf_event_attr.config. Supported attribute is listed + below:: + event = "config:0-4" - event ID + + For example:: + ctl_res_cnt = "event=0x1" + +What: /sys/bus/event_source/devices/nmemX/events +Date: September 2021 +KernelVersion: 5.16 +Contact:Kajol Jain +Description: (RO) Attribute group to describe performance monitoring events +for the nvdimm memory device. Each attribute in this group +describes a single performance monitoring event supported by +this nvdimm pmu. The name of the file is the name of the event. +(See ABI/testing/sysfs-bus-event_source-devices-events). A +listing of the events supported by a given nvdimm provider type +can be found in Documentation/driver-api/nvdimm/$provider. + +What: /sys/bus/event_source/devices/nmemX/cpumask +Date: September 2021 +KernelVersion: 5.16 +Contact:Kajol Jain +Description: (RO) This sysfs file exposes the cpumask which is designated to + to retrieve nvdimm pmu event counter data. -- 2.26.2
[RESEND PATCH v5 3/4] powerpc/papr_scm: Add perf interface support
Performance monitoring support for papr-scm nvdimm devices
via perf interface is added which includes addition of pmu
functions like add/del/read/event_init for nvdimm_pmu struture.
A new parameter 'priv' in added to the pdev_archdata structure to save
nvdimm_pmu device pointer, to handle the unregistering of pmu device.
papr_scm_pmu_register function populates the nvdimm_pmu structure
with name, capabilities, cpumask along with event handling
functions. Finally the populated nvdimm_pmu structure is passed to
register the pmu device. Event handling functions internally uses
hcall to get events and counter data.
Result in power9 machine with 2 nvdimm device:
Ex: List all event by perf list
command:# perf list nmem
nmem0/cache_rh_cnt/[Kernel PMU event]
nmem0/cache_wh_cnt/[Kernel PMU event]
nmem0/cri_res_util/[Kernel PMU event]
nmem0/ctl_res_cnt/ [Kernel PMU event]
nmem0/ctl_res_tm/ [Kernel PMU event]
nmem0/fast_w_cnt/ [Kernel PMU event]
nmem0/host_l_cnt/ [Kernel PMU event]
nmem0/host_l_dur/ [Kernel PMU event]
nmem0/host_s_cnt/ [Kernel PMU event]
nmem0/host_s_dur/ [Kernel PMU event]
nmem0/med_r_cnt/ [Kernel PMU event]
nmem0/med_r_dur/ [Kernel PMU event]
nmem0/med_w_cnt/ [Kernel PMU event]
nmem0/med_w_dur/ [Kernel PMU event]
nmem0/mem_life/[Kernel PMU event]
nmem0/poweron_secs/[Kernel PMU event]
...
nmem1/mem_life/[Kernel PMU event]
nmem1/poweron_secs/[Kernel PMU event]
Signed-off-by: Kajol Jain
---
arch/powerpc/include/asm/device.h | 5 +
arch/powerpc/platforms/pseries/papr_scm.c | 225 ++
2 files changed, 230 insertions(+)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 219559d65864..47ed639f3b8f 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -48,6 +48,11 @@ struct dev_archdata {
struct pdev_archdata {
u64 dma_mask;
+ /*
+* Pointer to nvdimm_pmu structure, to handle the unregistering
+* of pmu device
+*/
+ void *priv;
};
#endif /* _ASM_POWERPC_DEVICE_H */
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
b/arch/powerpc/platforms/pseries/papr_scm.c
index f48e87ac89c9..bdf2620db461 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#define BIND_ANY_ADDR (~0ul)
@@ -68,6 +69,8 @@
#define PAPR_SCM_PERF_STATS_EYECATCHER __stringify(SCMSTATS)
#define PAPR_SCM_PERF_STATS_VERSION 0x1
+#define to_nvdimm_pmu(_pmu)container_of(_pmu, struct nvdimm_pmu, pmu)
+
/* Struct holding a single performance metric */
struct papr_scm_perf_stat {
u8 stat_id[8];
@@ -120,6 +123,9 @@ struct papr_scm_priv {
/* length of the stat buffer as expected by phyp */
size_t stat_buffer_len;
+
+/* array to have event_code and stat_id mappings */
+ char **nvdimm_events_map;
};
static int papr_scm_pmem_flush(struct nd_region *nd_region,
@@ -340,6 +346,218 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv
*p,
return 0;
}
+static int papr_scm_pmu_get_value(struct perf_event *event, struct device
*dev, u64 *count)
+{
+ struct papr_scm_perf_stat *stat;
+ struct papr_scm_perf_stats *stats;
+ struct papr_scm_priv *p = (struct papr_scm_priv *)dev->driver_data;
+ int rc, size;
+
+ /* Allocate request buffer enough to hold single performance stat */
+ size = sizeof(struct papr_scm_perf_stats) +
+ sizeof(struct papr_scm_perf_stat);
+
+ if (!p || !p->nvdimm_events_map)
+ return -EINVAL;
+
+ stats = kzalloc(size, GFP_KERNEL);
+ if (!stats)
+ return -ENOMEM;
+
+ stat = >scm_statistic[0];
+ memcpy(>stat_id,
+ p->nvdimm_events_map[event->attr.config],
+ sizeof(stat->stat_id));
+ stat->stat_val = 0;
+
+ rc = drc_pmem_query_stats(p, stats, 1);
+ if (rc < 0) {
+ kfree(stats);
+ return rc;
+ }
+
+ *count = be64_to_cpu(stat->stat_val);
+ kfree(stats);
+ return 0;
+}
+
+static int papr_scm_pmu_event_init(struct perf_event *event)
+{
+ struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
+ struct papr_scm_priv *p;
+
+ if (!nd_pmu)
+ return
[RESEND PATCH v5 2/4] drivers/nvdimm: Add perf interface to expose nvdimm performance stats
A common interface is added to get performance stats reporting
support for nvdimm devices. Added interface defines supported
event list, config fields for the event attributes and their
corresponding bit values which are exported via sysfs.
Interface also added support for pmu register/unregister functions,
cpu hotplug feature along with macros for handling events addition
via sysfs. It adds attribute groups for format, cpumask and events
to the pmu structure.
User could use the standard perf tool to access perf events exposed
via nvdimm pmu.
Signed-off-by: Kajol Jain
[Make hotplug function static as reported by kernel test rorbot]
Reported-by: kernel test robot
---
drivers/nvdimm/Makefile | 1 +
drivers/nvdimm/nd_perf.c | 328 +++
include/linux/nd.h | 21 +++
3 files changed, 350 insertions(+)
create mode 100644 drivers/nvdimm/nd_perf.c
diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile
index 29203f3d3069..25dba6095612 100644
--- a/drivers/nvdimm/Makefile
+++ b/drivers/nvdimm/Makefile
@@ -18,6 +18,7 @@ nd_e820-y := e820.o
libnvdimm-y := core.o
libnvdimm-y += bus.o
libnvdimm-y += dimm_devs.o
+libnvdimm-y += nd_perf.o
libnvdimm-y += dimm.o
libnvdimm-y += region_devs.o
libnvdimm-y += region.o
diff --git a/drivers/nvdimm/nd_perf.c b/drivers/nvdimm/nd_perf.c
new file mode 100644
index ..314415894acf
--- /dev/null
+++ b/drivers/nvdimm/nd_perf.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * nd_perf.c: NVDIMM Device Performance Monitoring Unit support
+ *
+ * Perf interface to expose nvdimm performance stats.
+ *
+ * Copyright (C) 2021 IBM Corporation
+ */
+
+#define pr_fmt(fmt) "nvdimm_pmu: " fmt
+
+#include
+
+#define EVENT(_name, _code) enum{_name = _code}
+
+/*
+ * NVDIMM Events codes.
+ */
+
+/* Controller Reset Count */
+EVENT(CTL_RES_CNT, 0x1);
+/* Controller Reset Elapsed Time */
+EVENT(CTL_RES_TM, 0x2);
+/* Power-on Seconds */
+EVENT(POWERON_SECS,0x3);
+/* Life Remaining */
+EVENT(MEM_LIFE,0x4);
+/* Critical Resource Utilization */
+EVENT(CRI_RES_UTIL,0x5);
+/* Host Load Count */
+EVENT(HOST_L_CNT, 0x6);
+/* Host Store Count */
+EVENT(HOST_S_CNT, 0x7);
+/* Host Store Duration */
+EVENT(HOST_S_DUR, 0x8);
+/* Host Load Duration */
+EVENT(HOST_L_DUR, 0x9);
+/* Media Read Count */
+EVENT(MED_R_CNT, 0xa);
+/* Media Write Count */
+EVENT(MED_W_CNT, 0xb);
+/* Media Read Duration */
+EVENT(MED_R_DUR, 0xc);
+/* Media Write Duration */
+EVENT(MED_W_DUR, 0xd);
+/* Cache Read Hit Count */
+EVENT(CACHE_RH_CNT,0xe);
+/* Cache Write Hit Count */
+EVENT(CACHE_WH_CNT,0xf);
+/* Fast Write Count */
+EVENT(FAST_W_CNT, 0x10);
+
+NVDIMM_EVENT_ATTR(ctl_res_cnt, CTL_RES_CNT);
+NVDIMM_EVENT_ATTR(ctl_res_tm, CTL_RES_TM);
+NVDIMM_EVENT_ATTR(poweron_secs,POWERON_SECS);
+NVDIMM_EVENT_ATTR(mem_life,MEM_LIFE);
+NVDIMM_EVENT_ATTR(cri_res_util,CRI_RES_UTIL);
+NVDIMM_EVENT_ATTR(host_l_cnt, HOST_L_CNT);
+NVDIMM_EVENT_ATTR(host_s_cnt, HOST_S_CNT);
+NVDIMM_EVENT_ATTR(host_s_dur, HOST_S_DUR);
+NVDIMM_EVENT_ATTR(host_l_dur, HOST_L_DUR);
+NVDIMM_EVENT_ATTR(med_r_cnt, MED_R_CNT);
+NVDIMM_EVENT_ATTR(med_w_cnt, MED_W_CNT);
+NVDIMM_EVENT_ATTR(med_r_dur, MED_R_DUR);
+NVDIMM_EVENT_ATTR(med_w_dur, MED_W_DUR);
+NVDIMM_EVENT_ATTR(cache_rh_cnt,CACHE_RH_CNT);
+NVDIMM_EVENT_ATTR(cache_wh_cnt,CACHE_WH_CNT);
+NVDIMM_EVENT_ATTR(fast_w_cnt, FAST_W_CNT);
+
+static struct attribute *nvdimm_events_attr[] = {
+ NVDIMM_EVENT_PTR(CTL_RES_CNT),
+ NVDIMM_EVENT_PTR(CTL_RES_TM),
+ NVDIMM_EVENT_PTR(POWERON_SECS),
+ NVDIMM_EVENT_PTR(MEM_LIFE),
+ NVDIMM_EVENT_PTR(CRI_RES_UTIL),
+ NVDIMM_EVENT_PTR(HOST_L_CNT),
+ NVDIMM_EVENT_PTR(HOST_S_CNT),
+ NVDIMM_EVENT_PTR(HOST_S_DUR),
+ NVDIMM_EVENT_PTR(HOST_L_DUR),
+ NVDIMM_EVENT_PTR(MED_R_CNT),
+ NVDIMM_EVENT_PTR(MED_W_CNT),
+ NVDIMM_EVENT_PTR(MED_R_DUR),
+ NVDIMM_EVENT_PTR(MED_W_DUR),
+ NVDIMM_EVENT_PTR(CACHE_RH_CNT),
+ NVDIMM_EVENT_PTR(CACHE_WH_CNT),
+ NVDIMM_EVENT_PTR(FAST_W_CNT),
+ NULL
+};
+
+static struct attribute_group nvdimm_pmu_events_group = {
+ .name = "events",
+ .attrs = nvdimm_events_attr,
+};
+
+PMU_FORMAT_ATTR(event, "config:0-4");
+
+static struct attribute *nvdimm_pmu_format_attr[] = {
+ _attr_event.attr,
+ NULL,
+};
+
+static struct attribute_group nvdimm_pmu_format_group = {
+ .name = "format",
+ .attrs = nvdimm_pmu_format_attr,
+};
+
+ssize_t nvdimm_events_sysfs_show(struct device *dev,
+struct device_attribute *attr, char *page)
+{
+ struct
[RESEND PATCH v5 0/4] Add perf interface to expose nvdimm
Patchset adds performance stats reporting support for nvdimm. Added interface includes support for pmu register/unregister functions. A structure is added called nvdimm_pmu to be used for adding arch/platform specific data such as cpumask, nvdimm device pointer and pmu event functions like event_init/add/read/del. User could use the standard perf tool to access perf events exposed via pmu. Interface also defines supported event list, config fields for the event attributes and their corresponding bit values which are exported via sysfs. Patch 3 exposes IBM pseries platform nmem* device performance stats using this interface. Result from power9 pseries lpar with 2 nvdimm device: Ex: List all event by perf list command:# perf list nmem nmem0/cache_rh_cnt/[Kernel PMU event] nmem0/cache_wh_cnt/[Kernel PMU event] nmem0/cri_res_util/[Kernel PMU event] nmem0/ctl_res_cnt/ [Kernel PMU event] nmem0/ctl_res_tm/ [Kernel PMU event] nmem0/fast_w_cnt/ [Kernel PMU event] nmem0/host_l_cnt/ [Kernel PMU event] nmem0/host_l_dur/ [Kernel PMU event] nmem0/host_s_cnt/ [Kernel PMU event] nmem0/host_s_dur/ [Kernel PMU event] nmem0/med_r_cnt/ [Kernel PMU event] nmem0/med_r_dur/ [Kernel PMU event] nmem0/med_w_cnt/ [Kernel PMU event] nmem0/med_w_dur/ [Kernel PMU event] nmem0/mem_life/[Kernel PMU event] nmem0/poweron_secs/[Kernel PMU event] ... nmem1/mem_life/[Kernel PMU event] nmem1/poweron_secs/[Kernel PMU event] Patch1: Introduces the nvdimm_pmu structure Patch2: Adds common interface to add arch/platform specific data includes nvdimm device pointer, pmu data along with pmu event functions. It also defines supported event list and adds attribute groups for format, events and cpumask. It also adds code for cpu hotplug support. Patch3: Add code in arch/powerpc/platform/pseries/papr_scm.c to expose nmem* pmu. It fills in the nvdimm_pmu structure with pmu name, capabilities, cpumask and event functions and then registers the pmu by adding callbacks to register_nvdimm_pmu. Patch4: Sysfs documentation patch Changelog --- v4 -> v5: - Remove multiple variables defined in nvdimm_pmu structure include name and pmu functions(event_int/add/del/read) as they are just used to copy them again in pmu variable. Now we are directly doing this step in arch specific code as suggested by Dan Williams. - Remove attribute group field from nvdimm pmu structure and defined these attribute groups in common interface which includes format, event list along with cpumask as suggested by Dan Williams. Since we added static defination for attrbute groups needed in common interface, removes corresponding code from papr. - Add nvdimm pmu event list with event codes in the common interface. - Remove Acked-by/Reviewed-by/Tested-by tags as code is refactored to handle review comments from Dan. - Make nvdimm_pmu_free_hotplug_memory function static as reported by kernel test robot, also add corresponding Reported-by tag. - Link to the patchset v4: https://lkml.org/lkml/2021/9/3/45 v3 -> v4 - Rebase code on top of current papr_scm code without any logical changes. - Added Acked-by tag from Peter Zijlstra and Reviewed by tag from Madhavan Srinivasan. - Link to the patchset v3: https://lkml.org/lkml/2021/6/17/605 v2 -> v3 - Added Tested-by tag. - Fix nvdimm mailing list in the ABI Documentation. - Link to the patchset v2: https://lkml.org/lkml/2021/6/14/25 v1 -> v2 - Fix hotplug code by adding pmu migration call incase current designated cpu got offline. As pointed by Peter Zijlstra. - Removed the retun -1 part from cpu hotplug offline function. - Link to the patchset v1: https://lkml.org/lkml/2021/6/8/500 Kajol Jain (4): drivers/nvdimm: Add nvdimm pmu structure drivers/nvdimm: Add perf interface to expose nvdimm performance stats powerpc/papr_scm: Add perf interface support docs: ABI: sysfs-bus-nvdimm: Document sysfs event format entries for nvdimm pmu Documentation/ABI/testing/sysfs-bus-nvdimm | 35 +++ arch/powerpc/include/asm/device.h | 5 + arch/powerpc/platforms/pseries/papr_scm.c | 225 ++ drivers/nvdimm/Makefile| 1 + drivers/nvdimm/nd_perf.c | 328 + include/linux/nd.h | 41 +++ 6
[RESEND PATCH v5 1/4] drivers/nvdimm: Add nvdimm pmu structure
A structure is added called nvdimm_pmu, for performance
stats reporting support of nvdimm devices. It can be used to add
device pmu data such as pmu data structure for performance
stats, nvdimm device pointer along with cpumask attributes.
Signed-off-by: Kajol Jain
---
include/linux/nd.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/nd.h b/include/linux/nd.h
index ee9ad76afbba..f5ed4db2d859 100644
--- a/include/linux/nd.h
+++ b/include/linux/nd.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
enum nvdimm_event {
NVDIMM_REVALIDATE_POISON,
@@ -23,6 +24,25 @@ enum nvdimm_claim_class {
NVDIMM_CCLASS_UNKNOWN,
};
+/**
+ * struct nvdimm_pmu - data structure for nvdimm perf driver
+ * @pmu: pmu data structure for nvdimm performance stats.
+ * @dev: nvdimm device pointer.
+ * @cpu: designated cpu for counter access.
+ * @node: node for cpu hotplug notifier link.
+ * @cpuhp_state: state for cpu hotplug notification.
+ * @arch_cpumask: cpumask to get designated cpu for counter access.
+ */
+struct nvdimm_pmu {
+ struct pmu pmu;
+ struct device *dev;
+ int cpu;
+ struct hlist_node node;
+ enum cpuhp_state cpuhp_state;
+ /* cpumask provided by arch/platform specific code */
+ struct cpumask arch_cpumask;
+};
+
struct nd_device_driver {
struct device_driver drv;
unsigned long type;
--
2.26.2
Re: Build regressions/improvements in v5.16-rc1
On Mon, Nov 15, 2021 at 05:44:33PM +0100, Marco Elver wrote:
> On Mon, Nov 15, 2021 at 05:12PM +0100, Geert Uytterhoeven wrote:
> [...]
> > > + /kisskb/src/include/linux/fortify-string.h: error: call to
> > > '__read_overflow' declared with attribute error: detected read beyond
> > > size of object (1st parameter): => 263:25, 277:17
> >
> > in lib/test_kasan.c
> >
> > s390-all{mod,yes}config
> > arm64-allmodconfig (gcc11)
>
> Kees, wasn't that what [1] was meant to fix?
> [1] https://lkml.kernel.org/r/20211006181544.1670992-1-keesc...@chromium.org
Ah, I found it:
http://kisskb.ellerman.id.au/kisskb/buildresult/14660585/log/
it's actually:
inlined from 'kasan_memcmp' at /kisskb/src/lib/test_kasan.c:897:2:
and
inlined from 'kasan_memchr' at /kisskb/src/lib/test_kasan.c:872:2:
I can send a patch doing the same as what [1] does for these cases too.
--
Kees Cook
Re: Build regressions/improvements in v5.16-rc1
On Mon, Nov 15, 2021 at 05:44:33PM +0100, Marco Elver wrote:
> On Mon, Nov 15, 2021 at 05:12PM +0100, Geert Uytterhoeven wrote:
> [...]
> > > + /kisskb/src/include/linux/fortify-string.h: error: call to
> > > '__read_overflow' declared with attribute error: detected read beyond
> > > size of object (1st parameter): => 263:25, 277:17
> >
> > in lib/test_kasan.c
> >
> > s390-all{mod,yes}config
> > arm64-allmodconfig (gcc11)
>
> Kees, wasn't that what [1] was meant to fix?
> [1] https://lkml.kernel.org/r/20211006181544.1670992-1-keesc...@chromium.org
[1] fixed the ones I found when scanning for __write_overflow(). [2]
fixed some others, so it's possible there are yet more to fix?
Taking a look at Linus's tree, though, the "263" and "277" lines don't
line up correctly. I'll go see if I can reproduce this. Is this with
W=1?
-Kees
[2]
https://www.ozlabs.org/~akpm/mmotm/broken-out/kasan-test-consolidate-workarounds-for-unwanted-__alloc_size-protection.patch
--
Kees Cook
Re: [PATCH 0/3] KEXEC_SIG with appended signature
On 11/12/21 03:30, Michal Suchánek wrote:
Hello,
On Thu, Nov 11, 2021 at 05:26:41PM -0500, Nayna wrote:
On 11/8/21 07:05, Michal Suchánek wrote:
Hello,
On Mon, Nov 08, 2021 at 09:18:56AM +1100, Daniel Axtens wrote:
Michal Suchánek writes:
On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote:
Michal Suchanek writes:
S390 uses appended signature for kernel but implements the check
separately from module loader.
Support for secure boot on powerpc with appended signature is planned -
grub patches submitted upstream but not yet merged.
Power Non-Virtualised / OpenPower already supports secure boot via kexec
with signature verification via IMA. I think you have now sent a
follow-up series that merges some of the IMA implementation, I just
wanted to make sure it was clear that we actually already have support
So is IMA_KEXEC and KEXEC_SIG redundant?
I see some architectures have both. I also see there is a lot of overlap
between the IMA framework and the KEXEC_SIG and MODULE_SIg.
Mimi would be much better placed than me to answer this.
The limits of my knowledge are basically that signature verification for
modules and kexec kernels can be enforced by IMA policies.
For example a secure booted powerpc kernel with module support will have
the following IMA policy set at the arch level:
"appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist
appraise_type=imasig|modsig",
(in arch/powerpc/kernel/ima_arch.c)
Module signature enforcement can be set with either IMA (policy like
"appraise func=MODULE_CHECK appraise_flag=check_blacklist
appraise_type=imasig|modsig" )
or with CONFIG_MODULE_SIG_FORCE/module.sig_enforce=1.
Sometimes this leads to arguably unexpected interactions - for example
commit fa4f3f56ccd2 ("powerpc/ima: Fix secure boot rules in ima arch
policy"), so it might be interesting to see if we can make things easier
to understand.
I suspect that is the root of the problem here. Until distributions pick
up IMA and properly document step by step in detail how to implement,
enable, and debug it the _SIG options are required for users to be able
to make use of signatures.
For secureboot, IMA appraisal policies are configured in kernel at boot time
based on secureboot state of the system, refer
arch/powerpc/kernel/ima_arch.c and security/integrity/ima/ima_efi.c. This
doesn't require any user configuration. Yes, I agree it would be helpful to
update kernel documentation specifying steps to sign the kernel image using
sign-file.
The other part is that distributions apply 'lockdown' patches that change
the security policy depending on secure boot status which were rejected
by upstream which only hook into the _SIG options, and not into the IMA_
options. Of course, I expect this to change when the IMA options are
universally available across architectures and the support picked up by
distributions.
Which brings the third point: IMA features vary across architectures,
and KEXEC_SIG is more common than IMA_KEXEC.
config/arm64/default:CONFIG_HAVE_IMA_KEXEC=y
config/ppc64le/default:CONFIG_HAVE_IMA_KEXEC=y
config/arm64/default:CONFIG_KEXEC_SIG=y
config/s390x/default:CONFIG_KEXEC_SIG=y
config/x86_64/default:CONFIG_KEXEC_SIG=y
KEXEC_SIG makes it much easier to get uniform features across
architectures.
Architectures use KEXEC_SIG vs IMA_KEXEC based on their requirement.
IMA_KEXEC is for the kernel images signed using sign-file (appended
signatures, not PECOFF), provides measurement along with verification, and
That's certainly not the case. S390 uses appended signatures with
KEXEC_SIG, arm64 uses PECOFF with both KEXEC_SIG and IMA_KEXEC.
Yes, S390 uses appended signature, but they also do not support
measurements.
On the other hand for arm64/x86, PECOFF works only with KEXEC_SIG. Look
at the KEXEC_IMAGE_VERIFY_SIG config dependencies in arch/arm64/Kconfig
and KEXEC_BZIMAGE_VERIFY_SIG config dependencies in arch/x86/Kconfig.
Now, if KEXEC_SIG is not enabled, then IMA appraisal policies are
enforced if secure boot is enabled, refer to
security/integrity/ima_efi.c . IMA would fail verification if kernel is
not signed with module sig appended signatures or signature verification
fails.
In short, IMA is used to enforce the existence of a policy if secure
boot is enabled. If they don't support module sig appended signatures,
by definition it fails. Thus PECOFF doesn't work with both KEXEC_SIG and
IMA_KEXEC, but only with KEXEC_SIG.
Lakshmi, do you agree with my reasoning ?
is tied to secureboot state of the system at boot time.
In distrubutions it's also the case with KEXEC_SIG, it's only upstream
where this is different. I don't know why Linux upstream has rejected
this support for KEXEC_SIG.
Anyway, sounds like the difference is that IMA provides measurement but
if you don't use it it does not makes any difference except more comlex
code.
I am unsure what do you mean by "complex code" here. Can you please
elaborate ? IMA policies support for
RE: [PATCH v2 3/3] soc: fsl: Replace kernel.h with the necessary inclusions
> -Original Message- > From: Andy Shevchenko > Sent: Monday, November 15, 2021 5:30 AM > To: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-arm- > ker...@lists.infradead.org > Cc: Leo Li ; Qiang Zhao > Subject: Re: [PATCH v2 3/3] soc: fsl: Replace kernel.h with the necessary > inclusions > > On Wed, Nov 10, 2021 at 12:59:52PM +0200, Andy Shevchenko wrote: > > When kernel.h is used in the headers it adds a lot into dependency > > hell, especially when there are circular dependencies are involved. > > > > Replace kernel.h inclusion with the list of what is really being used. > > > > Signed-off-by: Andy Shevchenko > > --- > > v2: updated Cc list based on previous changes to MAINTAINERS > > Any comments on this, please? > > I really want to decrease amount of kernel.h usage in the common headers. > So others won't copy'n'paste bad example. There seems to be no problem with the patch although I didn't get time to really compile with it applied. Will pick them up later after build test. Regards, Leo
[RFC PATCH 1/3] mm: cma: alloc_contig_range: use pageblock_order as the single alignment.
From: Zi Yan
Pages are grouped in unit of pageblock_order for mobility. cma and
alloc_contig_range() uses pageblock for isolation and migration, so
aligning PFNs to pageblock_order is necessary. But the PFNs used in cma
and alloc_contig_range() were aligned to max(pageblock_order, MAX_ORDER-1).
This makes no difference than aligning only to pageblock_order, since
if pageblock_order > MAX_ORDER, the PFN is pageblock aligned,
otherwise, the PFN is still pageblock aligned. Drop MAX_ORDER alignment
requirement.
When commit 47118af076f6 ("mm: mmzone: MIGRATE_CMA migration type added")
introduced MIGRATE_CMA, __free_one_page() did not prevent merging
freepages on isolate pagelbock and normal pageblock, thus it required
max(pageblock_order, MAX_ORDER-1) alignment. __free_one_page() has
changed and does prevent such merges.
Signed-off-by: Zi Yan
---
include/linux/mmzone.h | 5 +
kernel/dma/contiguous.c | 2 +-
mm/cma.c| 6 ++
mm/page_alloc.c | 12 +---
4 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 58e744b78c2c..6c61aa41a779 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -54,10 +54,7 @@ enum migratetype {
*
* The way to use it is to change migratetype of a range of
* pageblocks to MIGRATE_CMA which can be done by
-* __free_pageblock_cma() function. What is important though
-* is that a range of pageblocks must be aligned to
-* MAX_ORDER_NR_PAGES should biggest page be bigger than
-* a single pageblock.
+* __free_pageblock_cma() function.
*/
MIGRATE_CMA,
#endif
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 3d63d91cba5c..ac35b14b0786 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -399,7 +399,7 @@ static const struct reserved_mem_ops rmem_cma_ops = {
static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
- phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
+ phys_addr_t align = PAGE_SIZE << pageblock_order;
phys_addr_t mask = align - 1;
unsigned long node = rmem->fdt_node;
bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
diff --git a/mm/cma.c b/mm/cma.c
index bc9ca8f3c487..d171158bd418 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -180,8 +180,7 @@ int __init cma_init_reserved_mem(phys_addr_t base,
phys_addr_t size,
return -EINVAL;
/* ensure minimal alignment required by mm core */
- alignment = PAGE_SIZE <<
- max_t(unsigned long, MAX_ORDER - 1, pageblock_order);
+ alignment = PAGE_SIZE << pageblock_order;
/* alignment should be aligned with order_per_bit */
if (!IS_ALIGNED(alignment >> PAGE_SHIFT, 1 << order_per_bit))
@@ -268,8 +267,7 @@ int __init cma_declare_contiguous_nid(phys_addr_t base,
* migratetype page by page allocator's buddy algorithm. In the case,
* you couldn't get a contiguous memory, which is not what we want.
*/
- alignment = max(alignment, (phys_addr_t)PAGE_SIZE <<
- max_t(unsigned long, MAX_ORDER - 1, pageblock_order));
+ alignment = max(alignment, (phys_addr_t)PAGE_SIZE << pageblock_order);
if (fixed && base & (alignment - 1)) {
ret = -EINVAL;
pr_err("Region at %pa must be aligned to %pa bytes\n",
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c5952749ad40..5700f5502d59 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -8922,14 +8922,12 @@ struct page *has_unmovable_pages(struct zone *zone,
struct page *page,
#ifdef CONFIG_CONTIG_ALLOC
static unsigned long pfn_max_align_down(unsigned long pfn)
{
- return pfn & ~(max_t(unsigned long, MAX_ORDER_NR_PAGES,
-pageblock_nr_pages) - 1);
+ return pfn & ~(pageblock_nr_pages - 1);
}
static unsigned long pfn_max_align_up(unsigned long pfn)
{
- return ALIGN(pfn, max_t(unsigned long, MAX_ORDER_NR_PAGES,
- pageblock_nr_pages));
+ return ALIGN(pfn, pageblock_nr_pages);
}
#if defined(CONFIG_DYNAMIC_DEBUG) || \
@@ -9022,8 +9020,8 @@ static int __alloc_contig_migrate_range(struct
compact_control *cc,
* be either of the two.
* @gfp_mask: GFP mask to use during compaction
*
- * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
- * aligned. The PFN range must belong to a single zone.
+ * The PFN range does not have to be pageblock aligned. The PFN range must
+ * belong to a single zone.
*
* The first thing this routine does is attempt to MIGRATE_ISOLATE all
* pageblocks in the range. Once isolated, the pageblocks should not
@@ -9099,7 +9097,7 @@ int alloc_contig_range(unsigned long start, unsigned long
end,
ret = 0;
/*
-* Pages from [start, end) are within
[RFC PATCH 3/3] arch: powerpc: adjust fadump alignment to pageblock aligned.
From: Zi Yan CMA only requires pageblock alignment. Change fadump too. Signed-off-by: Zi Yan --- arch/powerpc/include/asm/fadump-internal.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/fadump-internal.h b/arch/powerpc/include/asm/fadump-internal.h index 8d61c8f3fec4..9198f20b6b68 100644 --- a/arch/powerpc/include/asm/fadump-internal.h +++ b/arch/powerpc/include/asm/fadump-internal.h @@ -20,9 +20,7 @@ #define memblock_num_regions(memblock_type)(memblock.memblock_type.cnt) /* Alignment per CMA requirement. */ -#define FADUMP_CMA_ALIGNMENT (PAGE_SIZE << \ -max_t(unsigned long, MAX_ORDER - 1,\ -pageblock_order)) +#define FADUMP_CMA_ALIGNMENT (PAGE_SIZE << pageblock_order) /* FAD commands */ #define FADUMP_REGISTER1 -- 2.33.0
[RFC PATCH 2/3] drivers: virtio_mem: use pageblock size as the minimum virtio_mem size.
From: Zi Yan
alloc_contig_range() now only needs to be aligned to pageblock_order,
drop virtio_mem size requirement that it needs to be the max of
pageblock_order and MAX_ORDER.
Signed-off-by: Zi Yan
---
drivers/virtio/virtio_mem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 0da0af251c73..a0a0994b42e2 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -2436,15 +2436,13 @@ static int virtio_mem_init_hotplug(struct virtio_mem
*vm)
VIRTIO_MEM_DEFAULT_OFFLINE_THRESHOLD);
/*
-* We want subblocks to span at least MAX_ORDER_NR_PAGES and
-* pageblock_nr_pages pages. This:
+* We want subblocks to span at least pageblock_nr_pages pages. This:
* - Simplifies our page onlining code (virtio_mem_online_page_cb)
* and fake page onlining code (virtio_mem_fake_online).
* - Is required for now for alloc_contig_range() to work reliably -
* it doesn't properly handle smaller granularity on ZONE_NORMAL.
*/
- sb_size = max_t(uint64_t, MAX_ORDER_NR_PAGES,
- pageblock_nr_pages) * PAGE_SIZE;
+ sb_size = pageblock_nr_pages * PAGE_SIZE;
sb_size = max_t(uint64_t, vm->device_block_size, sb_size);
if (sb_size < memory_block_size_bytes() && !force_bbm) {
--
2.33.0
[RFC PATCH 3/3] arch: powerpc: adjust fadump alignment to be pageblock aligned.
From: Zi Yan CMA only requires pageblock alignment now. Change CMA alignment in fadump too. Signed-off-by: Zi Yan --- arch/powerpc/include/asm/fadump-internal.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/fadump-internal.h b/arch/powerpc/include/asm/fadump-internal.h index 8d61c8f3fec4..9198f20b6b68 100644 --- a/arch/powerpc/include/asm/fadump-internal.h +++ b/arch/powerpc/include/asm/fadump-internal.h @@ -20,9 +20,7 @@ #define memblock_num_regions(memblock_type)(memblock.memblock_type.cnt) /* Alignment per CMA requirement. */ -#define FADUMP_CMA_ALIGNMENT (PAGE_SIZE << \ -max_t(unsigned long, MAX_ORDER - 1,\ -pageblock_order)) +#define FADUMP_CMA_ALIGNMENT (PAGE_SIZE << pageblock_order) /* FAD commands */ #define FADUMP_REGISTER1 -- 2.33.0
[RFC PATCH 0/3] Use pageblock_order for cma and alloc_contig_range alignment.
From: Zi Yan Hi David, You suggested to make alloc_contig_range() deal with pageblock_order instead of MAX_ORDER - 1 and get rid of MAX_ORDER - 1 dependency in virtio_mem[1]. This patchset is my attempt to achieve that. Please take a look and let me know if I am doing it correctly or not. >From what my understanding, cma required alignment of max(MAX_ORDER - 1, pageblock_order), because when MIGRATE_CMA was introduced, __free_one_page() does not prevent merging two different pageblocks, when MAX_ORDER - 1 > pageblock_order. But current __free_one_page() implementation does prevent that. It should be OK to just align cma to pageblock_order. alloc_contig_range() relies on MIGRATE_CMA to get free pages, so it can use pageblock_order as alignment too. In terms of virtio_mem, if I understand correctly, it relies on alloc_contig_range() to obtain contiguous free pages and offlines them to reduce guest memory size. As the result of alloc_contig_range() alignment change, virtio_mem should be able to just align PFNs to pageblock_order. Thanks. [1] https://lore.kernel.org/linux-mm/28b57903-fae6-47ac-7e1b-a1dd41421...@redhat.com/ Zi Yan (3): mm: cma: alloc_contig_range: use pageblock_order as the single alignment. drivers: virtio_mem: use pageblock size as the minimum virtio_mem size. arch: powerpc: adjust fadump alignment to be pageblock aligned. arch/powerpc/include/asm/fadump-internal.h | 4 +--- drivers/virtio/virtio_mem.c| 6 ++ include/linux/mmzone.h | 5 + kernel/dma/contiguous.c| 2 +- mm/cma.c | 6 ++ mm/page_alloc.c| 12 +--- 6 files changed, 12 insertions(+), 23 deletions(-) -- 2.33.0
Re: [PATCH 16/39] irqdomain: Make normal and nomap irqdomains exclusive
Hello Mark,
On 5/20/21 18:37, Marc Zyngier wrote:
Direct mappings are completely exclusive of normal mappings, meaning
that we can refactor the code slightly so that we can get rid of
the revmap_direct_max_irq field and use the revmap_size field
instead, reducing the size of the irqdomain structure.
Signed-off-by: Marc Zyngier
This patch is breaking the POWER9/POWER10 XIVE driver (these are not
old PPC systems :) on machines sharing the same LSI HW IRQ. For instance,
a linux KVM guest with a virtio-rng and a virtio-balloon device. In that
case, Linux creates two distinct IRQ mappings which can lead to some
unexpected behavior.
A fix to go forward would be to change the XIVE IRQ domain to use a
'Tree' domain for reverse mapping and not the 'No Map' domain mapping.
I will keep you updated for XIVE.
Thanks,
C.
---
include/linux/irqdomain.h | 6 +++---
kernel/irq/irqdomain.c| 45 ++-
2 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 723495ec5a2f..0916cf9c6e20 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -149,8 +149,6 @@ struct irq_domain_chip_generic;
* @parent: Pointer to parent irq_domain to support hierarchy irq_domains
*
* Revmap data, used internally by irq_domain
- * @revmap_direct_max_irq: The largest hwirq that can be set for controllers
that
- * support direct mapping
* @revmap_size: Size of the linear map table @revmap[]
* @revmap_tree: Radix map tree for hwirqs that don't fit in the linear map
* @revmap: Linear table of hwirq->virq reverse mappings
@@ -173,7 +171,6 @@ struct irq_domain {
/* reverse map data. The linear map gets appended to the irq_domain */
irq_hw_number_t hwirq_max;
- unsigned int revmap_direct_max_irq;
unsigned int revmap_size;
struct radix_tree_root revmap_tree;
struct mutex revmap_tree_mutex;
@@ -207,6 +204,9 @@ enum {
*/
IRQ_DOMAIN_MSI_NOMASK_QUIRK = (1 << 6),
+ /* Irq domain doesn't translate anything */
+ IRQ_DOMAIN_FLAG_NO_MAP = (1 << 7),
+
/*
* Flags starting from IRQ_DOMAIN_FLAG_NONCORE are reserved
* for implementation specific purposes and ignored by the
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index e0143e640683..fa94c86e47d4 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -146,6 +146,10 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle
*fwnode, int size,
static atomic_t unknown_domains;
+ if (WARN_ON((size && direct_max) ||
+ (!IS_ENABLED(CONFIG_IRQ_DOMAIN_NOMAP) && direct_max)))
+ return NULL;
+
domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) * size),
GFP_KERNEL, of_node_to_nid(to_of_node(fwnode)));
if (!domain)
@@ -213,8 +217,14 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle
*fwnode, int size,
domain->ops = ops;
domain->host_data = host_data;
domain->hwirq_max = hwirq_max;
+
+ if (direct_max) {
+ size = direct_max;
+ domain->flags |= IRQ_DOMAIN_FLAG_NO_MAP;
+ }
+
domain->revmap_size = size;
- domain->revmap_direct_max_irq = direct_max;
+
irq_domain_check_hierarchy(domain);
mutex_lock(_domain_mutex);
@@ -482,9 +492,18 @@ struct irq_domain *irq_get_default_host(void)
return irq_default_domain;
}
+static bool irq_domain_is_nomap(struct irq_domain *domain)
+{
+ return IS_ENABLED(CONFIG_IRQ_DOMAIN_NOMAP) &&
+ (domain->flags & IRQ_DOMAIN_FLAG_NO_MAP);
+}
+
static void irq_domain_clear_mapping(struct irq_domain *domain,
irq_hw_number_t hwirq)
{
+ if (irq_domain_is_nomap(domain))
+ return;
+
if (hwirq < domain->revmap_size) {
domain->revmap[hwirq] = 0;
} else {
@@ -498,6 +517,9 @@ static void irq_domain_set_mapping(struct irq_domain
*domain,
irq_hw_number_t hwirq,
struct irq_data *irq_data)
{
+ if (irq_domain_is_nomap(domain))
+ return;
+
if (hwirq < domain->revmap_size) {
domain->revmap[hwirq] = irq_data->irq;
} else {
@@ -629,9 +651,9 @@ unsigned int irq_create_direct_mapping(struct irq_domain
*domain)
pr_debug("create_direct virq allocation failed\n");
return 0;
}
- if (virq >= domain->revmap_direct_max_irq) {
+ if (virq >= domain->revmap_size) {
pr_err("ERROR: no free irqs available below %i maximum\n",
- domain->revmap_direct_max_irq);
+ domain->revmap_size);
irq_free_desc(virq);
return 0;
}
@@ -879,10
Re: Build regressions/improvements in v5.16-rc1
On 11/15/21 17:12, Geert Uytterhoeven wrote:
> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven
> wrote:
>> Below is the list of build error/warning regressions/improvements in
>> v5.16-rc1[1] compared to v5.15[2].
>>
>> Summarized:
>> - build errors: +20/-13
>> - build warnings: +3/-28
>>
>> Happy fixing! ;-)
>>
>> Thanks to the linux-next team for providing the build service.
>>
>> [1]
>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/
>> (all 90 configs)
>> [2]
>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/
>> (all 90 configs)
>>
>>
>> *** ERRORS ***
>>
>> 20 error regressions:
>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':'
>> before '__stringify': => 33:4, 18:4
>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes'
>> defined but not used [-Werror=unused-label]: => 38:1, 23:1
>
> due to static_branch_likely() in crypto/api.c
>
> parisc-allmodconfig
fixed now in the parisc for-next git tree.
>> + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined
>> [-Werror]: => 531
>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size
>> of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: =>
>> 47:1
>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size
>> of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: =>
>> 499:1
>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size
>> of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: =>
>> 334:1
>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size
>> of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: =>
>> 354:1
>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824
>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 372:1
>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224
>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 204:1
>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800
>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 476:1
>
> parisc-allmodconfig
parisc needs much bigger frame sizes, so I'm not astonished here.
During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply tempted
to
increase it this time to 4096, unless someone has a better idea
>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2240 bytes is
>> larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2304 bytes is
>> larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2320 bytes is
>> larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>
> powerpc-allmodconfig
>
>> + /kisskb/src/include/linux/compiler_types.h: error: call to
>> '__compiletime_assert_366' declared with attribute error: FIELD_PREP: value
>> too large for the field: => 335:38
>
> in drivers/pinctrl/pinctrl-apple-gpio.c
>
> arm64-allmodconfig (gcc8)
>
>> + /kisskb/src/include/linux/fortify-string.h: error: call to
>> '__read_overflow' declared with attribute error: detected read beyond size
>> of object (1st parameter): => 263:25, 277:17
>
> in lib/test_kasan.c
>
> s390-all{mod,yes}config
> arm64-allmodconfig (gcc11)
>
>> + error: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko]
>> undefined!: => N/A
>> + error: modpost: "mips_cm_lock_other"
>> [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>> + error: modpost: "mips_cm_unlock_other"
>> [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>> + error: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko]
>> undefined!: => N/A
>> + error: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko]
>> undefined!: => N/A
>
> mips-allmodconfig
>
>> 3 warning regressions:
>> + : warning: #warning syscall futex_waitv not implemented [-Wcpp]:
>> => 1559:2
>
> powerpc, m68k, mips, s390, parisc (and probably more)
Will someone update all of them at once?
Helge
>> + arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for
>> MCTP: => 322
>> + arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for
>> MCTP: => 295
>
> Yeah, that happens when symbols are changed from tristate to bool...
> Will be fixed in 5.17-rc1, with the next defconfig refresh.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
>
Re: Build regressions/improvements in v5.16-rc1
On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven wrote:
> Below is the list of build error/warning regressions/improvements in
> v5.16-rc1[1] compared to v5.15[2].
>
> Summarized:
> - build errors: +20/-13
> - build warnings: +3/-28
>
> Happy fixing! ;-)
>
> Thanks to the linux-next team for providing the build service.
>
> [1]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/
> (all 90 configs)
> [2]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/
> (all 90 configs)
>
>
> *** ERRORS ***
>
> 20 error regressions:
> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':'
> before '__stringify': => 33:4, 18:4
> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes'
> defined but not used [-Werror=unused-label]: => 38:1, 23:1
due to static_branch_likely() in crypto/api.c
parisc-allmodconfig
> + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined
> [-Werror]: => 531
> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size
> of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 47:1
> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size
> of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: =>
> 499:1
> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size
> of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: =>
> 334:1
> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size
> of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: =>
> 354:1
> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824
> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 372:1
> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224
> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 204:1
> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800
> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 476:1
parisc-allmodconfig
> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2240 bytes is larger
> than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2304 bytes is larger
> than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2320 bytes is larger
> than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
powerpc-allmodconfig
> + /kisskb/src/include/linux/compiler_types.h: error: call to
> '__compiletime_assert_366' declared with attribute error: FIELD_PREP: value
> too large for the field: => 335:38
in drivers/pinctrl/pinctrl-apple-gpio.c
arm64-allmodconfig (gcc8)
> + /kisskb/src/include/linux/fortify-string.h: error: call to
> '__read_overflow' declared with attribute error: detected read beyond size of
> object (1st parameter): => 263:25, 277:17
in lib/test_kasan.c
s390-all{mod,yes}config
arm64-allmodconfig (gcc11)
> + error: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko]
> undefined!: => N/A
> + error: modpost: "mips_cm_lock_other"
> [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
> + error: modpost: "mips_cm_unlock_other"
> [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
> + error: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko]
> undefined!: => N/A
> + error: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko]
> undefined!: => N/A
mips-allmodconfig
> 3 warning regressions:
> + : warning: #warning syscall futex_waitv not implemented [-Wcpp]:
> => 1559:2
powerpc, m68k, mips, s390, parisc (and probably more)
> + arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for
> MCTP: => 322
> + arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for
> MCTP: => 295
Yeah, that happens when symbols are changed from tristate to bool...
Will be fixed in 5.17-rc1, with the next defconfig refresh.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 3/5] powerpc: Use preemption model accessors
Doh, thought I had sent this one out already... On 11/11/21 15:55, Michael Ellerman wrote: > Valentin Schneider writes: >> Per PREEMPT_DYNAMIC, checking CONFIG_PREEMPT doesn't tell you the actual >> preemption model of the live kernel. Use the newly-introduced accessors >> instead. >> >> sched_init() -> preempt_dynamic_init() happens way before IRQs are set up, >> so this should be fine. > > Despite the name interrupt_exit_kernel_prepare() is called before IRQs > are setup, traps and page faults are "interrupts" here. > > So I'm not sure about adding that call there, because it will trigger a > WARN if called early in boot, which will trigger a trap and depending on > the context we may not survive. > > I'd be happier if we can make it a build-time check. > This can't be done at build-time for PREEMPT_DYNAMIC, but that can be punted off to whoever will implement ppc support for that :-) AFAICT if this can't use preempt_dynamic_mode (due to how "late" it is setup), the preempt_schedule_irq() needs to go and ppc needs to use irqentry_exit() / irqentry_exit_cond_resched(). I dropped that for v2. > cheers >
Re: [PATCH v3 1/4] powerpc/watchdog: Fix missed watchdog reset due to memory ordering race
Le 10/11/2021 à 03:50, Nicholas Piggin a écrit :
It is possible for all CPUs to miss the pending cpumask becoming clear,
and then nobody resetting it, which will cause the lockup detector to
stop working. It will eventually expire, but watchdog_smp_panic will
avoid doing anything if the pending mask is clear and it will never be
reset.
Order the cpumask clear vs the subsequent test to close this race.
Add an extra check for an empty pending mask when the watchdog fires and
finds its bit still clear, to try to catch any other possible races or
bugs here and keep the watchdog working. The extra test in
arch_touch_nmi_watchdog is required to prevent the new warning from
firing off.
Debugged-by: Laurent Dufour
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/watchdog.c | 41 +-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/watchdog.c b/arch/powerpc/kernel/watchdog.c
index f9ea0e5357f9..3c60872b6a2c 100644
--- a/arch/powerpc/kernel/watchdog.c
+++ b/arch/powerpc/kernel/watchdog.c
@@ -135,6 +135,10 @@ static void set_cpumask_stuck(const struct cpumask
*cpumask, u64 tb)
{
cpumask_or(_smp_cpus_stuck, _smp_cpus_stuck, cpumask);
cpumask_andnot(_smp_cpus_pending, _smp_cpus_pending, cpumask);
+ /*
+* See wd_smp_clear_cpu_pending()
+*/
+ smp_mb();
if (cpumask_empty(_smp_cpus_pending)) {
wd_smp_last_reset_tb = tb;
cpumask_andnot(_smp_cpus_pending,
@@ -215,13 +219,44 @@ static void wd_smp_clear_cpu_pending(int cpu, u64 tb)
cpumask_clear_cpu(cpu, _smp_cpus_stuck);
wd_smp_unlock();
+ } else {
+ /*
+* The last CPU to clear pending should have reset the
+* watchdog so we generally should not find it empty
+* here if our CPU was clear. However it could happen
+* due to a rare race with another CPU taking the
+* last CPU out of the mask concurrently.
+*
+* We can't add a warning for it. But just in case
+* there is a problem with the watchdog that is causing
+* the mask to not be reset, try to kick it along here.
+*/
+ if (unlikely(cpumask_empty(_smp_cpus_pending)))
+ goto none_pending;
If I understand correctly, that branch is a security in case the code is not
working as expected. But I'm really wondering if that's really needed, and we
will end up with a contention on the watchdog lock while this path should be
lockless, and I'd say that in most of the case there is nothing to do after
grabbing that lock. Am I missing something risky here?
}
return;
}
+
cpumask_clear_cpu(cpu, _smp_cpus_pending);
+
+ /*
+* Order the store to clear pending with the load(s) to check all
+* words in the pending mask to check they are all empty. This orders
+* with the same barrier on another CPU. This prevents two CPUs
+* clearing the last 2 pending bits, but neither seeing the other's
+* store when checking if the mask is empty, and missing an empty
+* mask, which ends with a false positive.
+*/
+ smp_mb();
if (cpumask_empty(_smp_cpus_pending)) {
unsigned long flags;
+none_pending:
+ /*
+* Double check under lock because more than one CPU could see
+* a clear mask with the lockless check after clearing their
+* pending bits.
+*/
wd_smp_lock();
if (cpumask_empty(_smp_cpus_pending)) {
wd_smp_last_reset_tb = tb;
@@ -312,8 +347,12 @@ void arch_touch_nmi_watchdog(void)
{
unsigned long ticks = tb_ticks_per_usec * wd_timer_period_ms * 1000;
int cpu = smp_processor_id();
- u64 tb = get_tb();
+ u64 tb;
+ if (!cpumask_test_cpu(cpu, _cpumask))
+ return;
+
+ tb = get_tb();
if (tb - per_cpu(wd_timer_tb, cpu) >= ticks) {
per_cpu(wd_timer_tb, cpu) = tb;
wd_smp_clear_cpu_pending(cpu, tb);
Re: [PATCH v2] powerpc/64s: Get LPID bit width from device tree
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.16-rc1 next-2025]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-64s-Get-LPID-bit-width-from-device-tree/2020-160038
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc64-randconfig-c024-2025 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/b8fe7181506bf3011295456a9ee471ddf49d694d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Nicholas-Piggin/powerpc-64s-Get-LPID-bit-width-from-device-tree/2020-160038
git checkout b8fe7181506bf3011295456a9ee471ddf49d694d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross
ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
arch/powerpc/mm/init_64.c: In function 'mmu_early_init_devtree':
>> arch/powerpc/mm/init_64.c:472:13: error: variable 'rc' set but not used
>> [-Werror=unused-but-set-variable]
472 | int rc;
| ^~
cc1: all warnings being treated as errors
vim +/rc +472 arch/powerpc/mm/init_64.c
469
470 void __init mmu_early_init_devtree(void)
471 {
> 472 int rc;
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] net/wan/fsl_ucc_hdlc: fix sparse warnings
Hello: This patch was applied to netdev/net-next.git (master) by David S. Miller : On Mon, 15 Nov 2021 12:08:59 +0100 you wrote: > CHECK drivers/net/wan/fsl_ucc_hdlc.c > drivers/net/wan/fsl_ucc_hdlc.c:309:57: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:309:57:expected void [noderef] __iomem * > drivers/net/wan/fsl_ucc_hdlc.c:309:57:got restricted __be16 * > drivers/net/wan/fsl_ucc_hdlc.c:311:46: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:311:46:expected void [noderef] __iomem * > drivers/net/wan/fsl_ucc_hdlc.c:311:46:got restricted __be32 * > drivers/net/wan/fsl_ucc_hdlc.c:320:57: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:320:57:expected void [noderef] __iomem * > drivers/net/wan/fsl_ucc_hdlc.c:320:57:got restricted __be16 * > drivers/net/wan/fsl_ucc_hdlc.c:322:46: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:322:46:expected void [noderef] __iomem * > drivers/net/wan/fsl_ucc_hdlc.c:322:46:got restricted __be32 * > drivers/net/wan/fsl_ucc_hdlc.c:372:29: warning: incorrect type in assignment > (different base types) > drivers/net/wan/fsl_ucc_hdlc.c:372:29:expected unsigned short [usertype] > drivers/net/wan/fsl_ucc_hdlc.c:372:29:got restricted __be16 [usertype] > drivers/net/wan/fsl_ucc_hdlc.c:379:36: warning: restricted __be16 degrades to > integer > drivers/net/wan/fsl_ucc_hdlc.c:402:12: warning: incorrect type in assignment > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:402:12:expected struct qe_bd [noderef] > __iomem *bd > drivers/net/wan/fsl_ucc_hdlc.c:402:12:got struct qe_bd *curtx_bd > drivers/net/wan/fsl_ucc_hdlc.c:425:20: warning: incorrect type in assignment > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:425:20:expected struct qe_bd [noderef] > __iomem *[assigned] bd > drivers/net/wan/fsl_ucc_hdlc.c:425:20:got struct qe_bd *tx_bd_base > drivers/net/wan/fsl_ucc_hdlc.c:427:16: error: incompatible types in > comparison expression (different address spaces): > drivers/net/wan/fsl_ucc_hdlc.c:427:16:struct qe_bd [noderef] __iomem * > drivers/net/wan/fsl_ucc_hdlc.c:427:16:struct qe_bd * > drivers/net/wan/fsl_ucc_hdlc.c:462:33: warning: incorrect type in argument 1 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:506:41: warning: incorrect type in argument 1 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:528:33: warning: incorrect type in argument 1 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:552:38: warning: incorrect type in argument 1 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:596:67: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:611:41: warning: incorrect type in argument 1 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:851:38: warning: incorrect type in initializer > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:854:40: warning: incorrect type in argument 1 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:855:40: warning: incorrect type in argument 1 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:858:39: warning: incorrect type in argument 1 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:861:37: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:866:38: warning: incorrect type in initializer > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:868:21: warning: incorrect type in argument 1 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:870:40: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:871:40: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:873:39: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:993:57: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:995:46: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:1004:57: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:1006:46: warning: incorrect type in argument 2 > (different address spaces) > drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef > expression > drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef > expression > drivers/net/wan/fsl_ucc_hdlc.c:724:29: warning: dereference of noderef > expression > drivers/net/wan/fsl_ucc_hdlc.c:815:21: warning: dereference of noderef > expression > drivers/net/wan/fsl_ucc_hdlc.c:1021:29: warning: dereference of noderef > expression > > [...] Here is
Re: [PATCH v2 3/3] soc: fsl: Replace kernel.h with the necessary inclusions
On Wed, Nov 10, 2021 at 12:59:52PM +0200, Andy Shevchenko wrote: > When kernel.h is used in the headers it adds a lot into dependency hell, > especially when there are circular dependencies are involved. > > Replace kernel.h inclusion with the list of what is really being used. > > Signed-off-by: Andy Shevchenko > --- > v2: updated Cc list based on previous changes to MAINTAINERS Any comments on this, please? I really want to decrease amount of kernel.h usage in the common headers. So others won't copy'n'paste bad example. -- With Best Regards, Andy Shevchenko
Re: [PATCH] powerpc/book3e: Fix TLBCAM preset at boot
On 15 November 2021 at 10:05 am, Christophe Leroy wrote:
Commit 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if
init is done") was supposed to just add an additional parameter to
map_mem_in_cams() and always set it to 'true' at that time.
But a few call sites were messed up. Fix them.
Reported-by: Christian Zigotzky
Fixes: 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if init is
done")
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/kaslr_booke.c | 2 +-
arch/powerpc/mm/nohash/tlb.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c
b/arch/powerpc/mm/nohash/kaslr_booke.c
index 8fc49b1b4a91..6ec978967da0 100644
--- a/arch/powerpc/mm/nohash/kaslr_booke.c
+++ b/arch/powerpc/mm/nohash/kaslr_booke.c
@@ -314,7 +314,7 @@ static unsigned long __init kaslr_choose_location(void
*dt_ptr, phys_addr_t size
pr_warn("KASLR: No safe seed for randomizing the kernel
base.\n");
ram = min_t(phys_addr_t, __max_low_memory, size);
- ram = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM, true, false);
+ ram = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM, true, true);
linear_sz = min_t(unsigned long, ram, SZ_512M);
/* If the linear size is smaller than 64M, do not randmize */
diff --git a/arch/powerpc/mm/nohash/tlb.c b/arch/powerpc/mm/nohash/tlb.c
index 89353d4f5604..647bf454a0fa 100644
--- a/arch/powerpc/mm/nohash/tlb.c
+++ b/arch/powerpc/mm/nohash/tlb.c
@@ -645,7 +645,7 @@ static void early_init_this_mmu(void)
if (map)
linear_map_top = map_mem_in_cams(linear_map_top,
-num_cams, true, true);
+num_cams, false, true);
}
#endif
@@ -766,7 +766,7 @@ void setup_initial_memory_limit(phys_addr_t first_memblock_base,
num_cams = (mfspr(SPRN_TLB1CFG) & TLBnCFG_N_ENTRY) / 4;
linear_sz = map_mem_in_cams(first_memblock_size, num_cams,
- false, true);
+ true, true);
ppc64_rma_size = min_t(u64, linear_sz, 0x4000);
} else
Tested-by: Christian Zigotzky
Thanks
[PATCH] net/wan/fsl_ucc_hdlc: fix sparse warnings
CHECK drivers/net/wan/fsl_ucc_hdlc.c drivers/net/wan/fsl_ucc_hdlc.c:309:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:309:57:expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:309:57:got restricted __be16 * drivers/net/wan/fsl_ucc_hdlc.c:311:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:311:46:expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:311:46:got restricted __be32 * drivers/net/wan/fsl_ucc_hdlc.c:320:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:320:57:expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:320:57:got restricted __be16 * drivers/net/wan/fsl_ucc_hdlc.c:322:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:322:46:expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:322:46:got restricted __be32 * drivers/net/wan/fsl_ucc_hdlc.c:372:29: warning: incorrect type in assignment (different base types) drivers/net/wan/fsl_ucc_hdlc.c:372:29:expected unsigned short [usertype] drivers/net/wan/fsl_ucc_hdlc.c:372:29:got restricted __be16 [usertype] drivers/net/wan/fsl_ucc_hdlc.c:379:36: warning: restricted __be16 degrades to integer drivers/net/wan/fsl_ucc_hdlc.c:402:12: warning: incorrect type in assignment (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:402:12:expected struct qe_bd [noderef] __iomem *bd drivers/net/wan/fsl_ucc_hdlc.c:402:12:got struct qe_bd *curtx_bd drivers/net/wan/fsl_ucc_hdlc.c:425:20: warning: incorrect type in assignment (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:425:20:expected struct qe_bd [noderef] __iomem *[assigned] bd drivers/net/wan/fsl_ucc_hdlc.c:425:20:got struct qe_bd *tx_bd_base drivers/net/wan/fsl_ucc_hdlc.c:427:16: error: incompatible types in comparison expression (different address spaces): drivers/net/wan/fsl_ucc_hdlc.c:427:16:struct qe_bd [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:427:16:struct qe_bd * drivers/net/wan/fsl_ucc_hdlc.c:462:33: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:506:41: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:528:33: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:552:38: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:596:67: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:611:41: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:851:38: warning: incorrect type in initializer (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:854:40: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:855:40: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:858:39: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:861:37: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:866:38: warning: incorrect type in initializer (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:868:21: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:870:40: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:871:40: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:873:39: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:993:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:995:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:1004:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:1006:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:724:29: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:815:21: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:1021:29: warning: dereference of noderef expression Most of the warnings are due to DMA memory being incorrectly handled as IO memory. Fix it by doing direct read/write and doing proper dma_rmb() / dma_wmb(). Other problems are type mismatches or lack of use of IO accessors. Cc: Rasmus Villemoes Reported-by: kernel test robot Link:
[PATCH v3] powerpc/code-patching: Improve verification of patchability
Today, patch_instruction() assumes that it is called exclusively on
valid addresses, and only checks that it is not called on an init
address after init section has been freed.
Improve verification by calling kernel_text_address() instead.
kernel_text_address() already includes a verification of
initmem release.
Cc: Michael Neuling
Signed-off-by: Christophe Leroy
---
v3:
- At the same time also remove init_mem_is_free as it was the last user (Was
done in patch 3 in v2)
- Drop patch 2 (was merged via mm tree)
---
arch/powerpc/include/asm/setup.h | 1 -
arch/powerpc/lib/code-patching.c | 5 ++---
arch/powerpc/mm/mem.c| 2 --
3 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 6c1a7d217d1a..426a2d8d028f 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -9,7 +9,6 @@ extern void ppc_printk_progress(char *s, unsigned short hex);
extern unsigned int rtas_data;
extern unsigned long long memory_limit;
-extern bool init_mem_is_free;
extern void *zalloc_maybe_bootmem(size_t size, gfp_t mask);
struct device_node;
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index c5ed98823835..5e2fe133639e 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -190,10 +190,9 @@ static int do_patch_instruction(u32 *addr, struct ppc_inst
instr)
int patch_instruction(u32 *addr, struct ppc_inst instr)
{
/* Make sure we aren't patching a freed init section */
- if (init_mem_is_free && init_section_contains(addr, 4)) {
- pr_debug("Skipping init section patching addr: 0x%px\n", addr);
+ if (!kernel_text_address((unsigned long)addr))
return 0;
- }
+
return do_patch_instruction(addr, instr);
}
NOKPROBE_SYMBOL(patch_instruction);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index bd5d91a31183..8e301cd8925b 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -26,7 +26,6 @@
#include
unsigned long long memory_limit;
-bool init_mem_is_free;
unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)]
__page_aligned_bss;
EXPORT_SYMBOL(empty_zero_page);
@@ -312,7 +311,6 @@ void free_initmem(void)
{
ppc_md.progress = ppc_printk_progress;
mark_initmem_nx();
- init_mem_is_free = true;
free_initmem_default(POISON_FREE_INITMEM);
}
--
2.31.1
Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
Hi, this is your Linux kernel regression tracker speaking. This looks stalled, as afaics nothing to get this regression fixed happened since below mail. How can we things rolling again? Eugene, were you able to look into the patch from Joakim? Or did I miss anything and some progress to fix this was made elsewhere? Please let me know if that's the case. Ciao, Thorsten (carrying his Linux kernel regression tracker hat) P.S.: As a Linux kernel regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them. Unfortunately therefore I sometimes will get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me about it in a public reply. That's in everyone's interest, as what I wrote above might be misleading to everyone reading this; any suggestion I gave they thus might sent someone reading this down the wrong rabbit hole, which none of us wants. P.P.S.: Feel free to ignore the following lines, they are only meant for regzbot, my Linux kernel regression tracking bot (https://linux-regtracking.leemhuis.info/regzbot/): #regzbot poke On 02.11.21 22:15, Joakim Tjernlund wrote: > On Sat, 2021-10-30 at 14:20 +, Joakim Tjernlund wrote: >> On Fri, 2021-10-29 at 17:14 +, Eugene Bordenkircher wrote: > >>> We've discovered a situation where the FSL udc driver >>> (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterating over >>> the request queue, but the queue has been corrupted at some point so it >>> loops infinitely. I believe we have narrowed into the offending code, but >>> we are in need of assistance trying to find an appropriate fix for the >>> problem. The identified code appears to be in all versions of the Linux >>> kernel the driver exists in. >>> >>> The problem appears to be when handling a USB_REQ_GET_STATUS request. The >>> driver gets this request and then calls the ch9getstatus() function. In >>> this function, it starts a request by "borrowing" the per device >>> status_req, filling it in, and then queuing it with a call to >>> list_add_tail() to add the request to the endpoint queue. Right before it >>> exits the function however, it's calling ep0_prime_status(), which is >>> filling out that same status_req structure and then queuing it with another >>> call to list_add_tail() to add the request to the endpoint queue. This >>> adds two instances of the exact same LIST_HEAD to the endpoint queue, which >>> breaks the list since the prev and next pointers end up pointing to the >>> wrong things. This ends up causing a hard loop the next time nuke() gets >>> called, which happens on the next setup IRQ. >>> >>> I'm not sure what the appropriate fix to this problem is, mostly due to my >>> lack of expertise in USB and this driver stack. The code has been this way >>> in the kernel for a very long time, which suggests that it has been >>> working, unless USB_REQ_GET_STATUS requests are never made. This further >>> suggests that there is something else going on that I don't understand. >>> Deleting the call to ep0_prime_status() and the following ep0stall() call >>> appears, on the surface, to get the device working again, but may have side >>> effects that I'm not seeing. >>> >>> I'm hopeful someone in the community can help provide some information on >>> what I may be missing or help come up with a solution to the problem. A >>> big thank you to anyone who would like to help out. >>> >>> Eugene >> >> Run into this to a while ago. Found the bug and a few more fixes. >> This is against 4.19 so you may have to tweak them a bit. >> Feel free to upstream them. >> >> Jocke > > Curious, did my patches help? Good to known once we upgrade as well. > > Jocke
[PATCH] powerpc/book3e: Fix TLBCAM preset at boot
Commit 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if
init is done") was supposed to just add an additional parameter to
map_mem_in_cams() and always set it to 'true' at that time.
But a few call sites were messed up. Fix them.
Reported-by: Christian Zigotzky
Fixes: 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if init is
done")
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/kaslr_booke.c | 2 +-
arch/powerpc/mm/nohash/tlb.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c
b/arch/powerpc/mm/nohash/kaslr_booke.c
index 8fc49b1b4a91..6ec978967da0 100644
--- a/arch/powerpc/mm/nohash/kaslr_booke.c
+++ b/arch/powerpc/mm/nohash/kaslr_booke.c
@@ -314,7 +314,7 @@ static unsigned long __init kaslr_choose_location(void
*dt_ptr, phys_addr_t size
pr_warn("KASLR: No safe seed for randomizing the kernel
base.\n");
ram = min_t(phys_addr_t, __max_low_memory, size);
- ram = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM, true, false);
+ ram = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM, true, true);
linear_sz = min_t(unsigned long, ram, SZ_512M);
/* If the linear size is smaller than 64M, do not randmize */
diff --git a/arch/powerpc/mm/nohash/tlb.c b/arch/powerpc/mm/nohash/tlb.c
index 89353d4f5604..647bf454a0fa 100644
--- a/arch/powerpc/mm/nohash/tlb.c
+++ b/arch/powerpc/mm/nohash/tlb.c
@@ -645,7 +645,7 @@ static void early_init_this_mmu(void)
if (map)
linear_map_top = map_mem_in_cams(linear_map_top,
-num_cams, true, true);
+num_cams, false, true);
}
#endif
@@ -766,7 +766,7 @@ void setup_initial_memory_limit(phys_addr_t
first_memblock_base,
num_cams = (mfspr(SPRN_TLB1CFG) & TLBnCFG_N_ENTRY) / 4;
linear_sz = map_mem_in_cams(first_memblock_size, num_cams,
- false, true);
+ true, true);
ppc64_rma_size = min_t(u64, linear_sz, 0x4000);
} else
--
2.31.1
[PATCH] powerpc/signal32: Fix sigset_t copy
The conversion from __copy_from_user() to __get_user() by
commit d3ccc9781560 ("powerpc/signal: Use __get_user() to copy
sigset_t") introduced a regression in __get_user_sigset() for
powerpc/32. The bug was subsequently moved into
unsafe_get_user_sigset().
The bug is due to the copied 64 bit value being truncated to
32 bits while being assigned to dst->sig[0]
The regression was reported by users of the Xorg packages distributed in
Debian/powerpc --
"The symptoms are that the fb screen goes blank, with the backlight
remaining on and no errors logged in /var/log; wdm (or startx) run
with no effect (I tried logging in in the blind, with no effect).
And they are hard to kill, requiring 'kill -KILL ...'"
Fix the regression by copying each word of the sigset, not only the
first one.
__get_user_sigset() was tentatively optimised to copy 64 bits at once
in order to minimise KUAP unlock/lock impact, but the unsafe variant
doesn't suffer that, so it can just copy words.
Cc: Christopher M. Riedl
Fixes: 887f3ceb51cd ("powerpc/signal32: Convert do_setcontext[_tm]() to user
access block")
Cc: sta...@vger.kernel.org
Reported-by: Finn Thain
Reported-and-tested-by: Stan Johnson
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/signal.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index 1f07317964e4..618aeccdf691 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -25,8 +25,14 @@ static inline int __get_user_sigset(sigset_t *dst, const
sigset_t __user *src)
return __get_user(dst->sig[0], (u64 __user *)>sig[0]);
}
-#define unsafe_get_user_sigset(dst, src, label) \
- unsafe_get_user((dst)->sig[0], (u64 __user *)&(src)->sig[0], label)
+#define unsafe_get_user_sigset(dst, src, label) do { \
+ sigset_t *__dst = dst; \
+ const sigset_t __user *__src = src; \
+ int i; \
+ \
+ for (i = 0; i < _NSIG_WORDS; i++) \
+ unsafe_get_user(__dst->sig[i], &__src->sig[i], label); \
+} while (0)
#ifdef CONFIG_VSX
extern unsigned long copy_vsx_to_user(void __user *to,
--
2.31.1
[PATCH] powerpc/8xx: Fix pinned TLBs with CONFIG_STRICT_KERNEL_RWX
As spotted and explained in commit c12ab8dbc492 ("powerpc/8xx: Fix
Oops with STRICT_KERNEL_RWX without DEBUG_RODATA_TEST"), the selection
of STRICT_KERNEL_RWX without selecting DEBUG_RODATA_TEST has spotted
the lack of the DIRTY bit in the pinned kernel data TLBs.
This problem should have been detected a lot earlier if things had
been working as expected. But due to an incredible level of chance or
mishap, this went undetected because of a set of bugs: In fact the
DTLBs were not pinned, because instead of setting the reserve bit
in MD_CTR, it was set in MI_CTR that is the register for ITLBs.
But then, another huge bug was there: the physical address was
reset to 0 at the boundary between RO and RW areas, leading to the
same physical space being mapped at both 0xc000 and 0xc800.
This had by miracle no consequence until now because the entry was
not really pinned so it was overwritten soon enough to go undetected.
Of course, now that we really pin the DTLBs, it must be fixed as well.
Depends-on: c12ab8dbc492 ("powerpc/8xx: Fix Oops with STRICT_KERNEL_RWX without
DEBUG_RODATA_TEST")
Fixes: f76c8f6d257c ("powerpc/8xx: Add function to set pinned TLBs")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_8xx.S | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 2d596881b70e..0d073b9fd52c 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -733,6 +733,7 @@ _GLOBAL(mmu_pin_tlb)
#ifdef CONFIG_PIN_TLB_DATA
LOAD_REG_IMMEDIATE(r6, PAGE_OFFSET)
LOAD_REG_IMMEDIATE(r7, MI_SVALID | MI_PS8MEG | _PMD_ACCESSED)
+ li r8, 0
#ifdef CONFIG_PIN_TLB_IMMR
li r0, 3
#else
@@ -741,26 +742,26 @@ _GLOBAL(mmu_pin_tlb)
mtctr r0
cmpwi r4, 0
beq 4f
- LOAD_REG_IMMEDIATE(r8, 0xf0 | _PAGE_RO | _PAGE_SPS | _PAGE_SH |
_PAGE_PRESENT)
LOAD_REG_ADDR(r9, _sinittext)
2: ori r0, r6, MD_EVALID
+ ori r12, r8, 0xf0 | _PAGE_RO | _PAGE_SPS | _PAGE_SH | _PAGE_PRESENT
mtspr SPRN_MD_CTR, r5
mtspr SPRN_MD_EPN, r0
mtspr SPRN_MD_TWC, r7
- mtspr SPRN_MD_RPN, r8
+ mtspr SPRN_MD_RPN, r12
addir5, r5, 0x100
addis r6, r6, SZ_8M@h
addis r8, r8, SZ_8M@h
cmplw r6, r9
bdnzt lt, 2b
-
-4: LOAD_REG_IMMEDIATE(r8, 0xf0 | _PAGE_DIRTY | _PAGE_SPS | _PAGE_SH |
_PAGE_PRESENT)
+4:
2: ori r0, r6, MD_EVALID
+ ori r12, r8, 0xf0 | _PAGE_DIRTY | _PAGE_SPS | _PAGE_SH |
_PAGE_PRESENT
mtspr SPRN_MD_CTR, r5
mtspr SPRN_MD_EPN, r0
mtspr SPRN_MD_TWC, r7
- mtspr SPRN_MD_RPN, r8
+ mtspr SPRN_MD_RPN, r12
addir5, r5, 0x100
addis r6, r6, SZ_8M@h
addis r8, r8, SZ_8M@h
@@ -781,7 +782,7 @@ _GLOBAL(mmu_pin_tlb)
#endif
#if defined(CONFIG_PIN_TLB_IMMR) || defined(CONFIG_PIN_TLB_DATA)
lis r0, (MD_RSV4I | MD_TWAM)@h
- mtspr SPRN_MI_CTR, r0
+ mtspr SPRN_MD_CTR, r0
#endif
mtspr SPRN_SRR1, r10
mtspr SPRN_SRR0, r11
--
2.31.1
Re: [PATCH] soc: fsl: qe: Fix typo in a comment
Le 13/11/2021 à 06:59, Jason Wang a écrit : The double `is' in a comment is repeated, thus one of them should be removed. You are also clean blanks it seems, so say it or don't do it. Signed-off-by: Jason Wang --- drivers/soc/fsl/qe/qe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index 4d38c80f8be8..b3c226eb5292 100644 --- a/drivers/soc/fsl/qe/qe.c +++ b/drivers/soc/fsl/qe/qe.c @@ -147,7 +147,7 @@ EXPORT_SYMBOL(qe_issue_cmd); * memory mapped space. * The BRG clock is the QE clock divided by 2. * It was set up long ago during the initial boot phase and is - * is given to us. + * given to us. * Baud rate clocks are zero-based in the driver code (as that maps * to port numbers). Documentation uses 1-based numbering. */ @@ -421,7 +421,7 @@ static void qe_upload_microcode(const void *base, for (i = 0; i < be32_to_cpu(ucode->count); i++) iowrite32be(be32_to_cpu(code[i]), _immr->iram.idata); - + This change is not linked to the double "is". /* Set I-RAM Ready Register */ iowrite32be(QE_IRAM_READY, _immr->iram.iready); }
Re: [PATCH] mm: Remove a repeated word in a comment
Le 13/11/2021 à 05:40, Jason Wang a écrit :
The double word `up' in a comment is repeated, thus one of
them should be removed.
If you do other changes than this one, say it here as well, see below.
Signed-off-by: Jason Wang
---
drivers/macintosh/mediabay.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index eab7e83c11c4..ec23094263e7 100644
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -129,7 +129,7 @@ enum {
/*
* Functions for polling content of media bay
*/
-
+
This change is not part of your description.
static u8
ohare_mb_content(struct media_bay_info *bay)
{
@@ -331,12 +331,12 @@ static void keylargo_mb_un_reset_ide(struct
media_bay_info* bay)
static inline void set_mb_power(struct media_bay_info* bay, int onoff)
{
- /* Power up up and assert the bay reset line */
+ /* Power up and assert the bay reset line */
if (onoff) {
bay->ops->power(bay, 1);
bay->state = mb_powering_up;
pr_debug("mediabay%d: powering up\n", bay->index);
- } else {
+ } else {
This change is not part of your description.
/* Make sure everything is powered down & disabled */
bay->ops->power(bay, 0);
bay->state = mb_powering_down;
@@ -577,7 +577,7 @@ static int media_bay_attach(struct macio_dev *mdev,
macio_release_resources(mdev);
return -ENOMEM;
}
-
+
This change is not part of your description.
i = media_bay_count++;
bay = _bays[i];
bay->mdev = mdev;
@@ -745,7 +745,7 @@ static int __init media_bay_init(void)
if (!machine_is(powermac))
return 0;
- macio_register_driver(_bay_driver);
+ macio_register_driver(_bay_driver);
This change is not part of your description.
return 0;
}
