Re: [PATCH v2 5/7] powerpc/secvar: Handle max object size in the consumer
On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote:
> Currently the max object size is handled in the core secvar code with
> an
> entirely OPAL-specific implementation, so create a new max_size() op
> and
> move the existing implementation into the powernv platform. Should
> be
> no functional change.
>
> Signed-off-by: Russell Currey
LGTM
Reviewed-by: Andrew Donnellan
> ---
> arch/powerpc/include/asm/secvar.h | 1 +
> arch/powerpc/kernel/secvar-sysfs.c | 17 +++--
> arch/powerpc/platforms/powernv/opal-secvar.c | 19
> +++
> 3 files changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/secvar.h
> b/arch/powerpc/include/asm/secvar.h
> index 3b7e5a3625bd..92d2c051918b 100644
> --- a/arch/powerpc/include/asm/secvar.h
> +++ b/arch/powerpc/include/asm/secvar.h
> @@ -21,6 +21,7 @@ struct secvar_operations {
> int (*set)(const char *key, uint64_t key_len, u8 *data,
> uint64_t data_size);
> ssize_t (*format)(char *buf);
> + int (*max_size)(uint64_t *max_size);
> };
>
> #ifdef CONFIG_PPC_SECURE_BOOT
> diff --git a/arch/powerpc/kernel/secvar-sysfs.c
> b/arch/powerpc/kernel/secvar-sysfs.c
> index 190238f51335..aa1daec480e1 100644
> --- a/arch/powerpc/kernel/secvar-sysfs.c
> +++ b/arch/powerpc/kernel/secvar-sysfs.c
> @@ -122,27 +122,16 @@ static struct kobj_type secvar_ktype = {
> static int update_kobj_size(void)
> {
>
> - struct device_node *node;
> u64 varsize;
> - int rc = 0;
> + int rc = secvar_ops->max_size();
>
> - node = of_find_compatible_node(NULL, NULL, "ibm,secvar-
> backend");
> - if (!of_device_is_available(node)) {
> - rc = -ENODEV;
> - goto out;
> - }
> -
> - rc = of_property_read_u64(node, "max-var-size", );
> if (rc)
> - goto out;
> + return rc;
>
> data_attr.size = varsize;
> update_attr.size = varsize;
>
> -out:
> - of_node_put(node);
> -
> - return rc;
> + return 0;
> }
>
> static int secvar_sysfs_load(void)
> diff --git a/arch/powerpc/platforms/powernv/opal-secvar.c
> b/arch/powerpc/platforms/powernv/opal-secvar.c
> index 5e9de06b2533..07260460e966 100644
> --- a/arch/powerpc/platforms/powernv/opal-secvar.c
> +++ b/arch/powerpc/platforms/powernv/opal-secvar.c
> @@ -125,11 +125,30 @@ static ssize_t opal_secvar_format(char *buf)
> return rc;
> }
>
> +static int opal_secvar_max_size(uint64_t *max_size)
> +{
> + int rc;
> + struct device_node *node;
> +
> + node = of_find_compatible_node(NULL, NULL, "ibm,secvar-
> backend");
> + if (!of_device_is_available(node)) {
> + rc = -ENODEV;
> + goto out;
> + }
> +
> + rc = of_property_read_u64(node, "max-var-size", max_size);
> +
> +out:
> + of_node_put(node);
> + return rc;
> +}
> +
> static const struct secvar_operations opal_secvar_ops = {
> .get = opal_get_variable,
> .get_next = opal_get_next_variable,
> .set = opal_set_variable,
> .format = opal_secvar_format,
> + .max_size = opal_secvar_max_size,
> };
>
> static int opal_secvar_probe(struct platform_device *pdev)
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: [PATCH] mm: remove zap_page_range and create zap_vma_pages
On Tue 03-01-23 16:27:32, Mike Kravetz wrote: > zap_page_range was originally designed to unmap pages within an address > range that could span multiple vmas. While working on [1], it was > discovered that all callers of zap_page_range pass a range entirely within > a single vma. In addition, the mmu notification call within zap_page > range does not correctly handle ranges that span multiple vmas. When > crossing a vma boundary, a new mmu_notifier_range_init/end call pair > with the new vma should be made. > > Instead of fixing zap_page_range, do the following: > - Create a new routine zap_vma_pages() that will remove all pages within > the passed vma. Most users of zap_page_range pass the entire vma and > can use this new routine. > - For callers of zap_page_range not passing the entire vma, instead call > zap_page_range_single(). > - Remove zap_page_range. > > [1] > https://lore.kernel.org/linux-mm/20221114235507.294320-2-mike.krav...@oracle.com/ > Suggested-by: Peter Xu > Signed-off-by: Mike Kravetz This looks even better than the previous version. Acked-by: Michal Hocko minor nit [...] > diff --git a/mm/page-writeback.c b/mm/page-writeback.c > index ad608ef2a243..ffa36cfe5884 100644 > --- a/mm/page-writeback.c > +++ b/mm/page-writeback.c > @@ -2713,7 +2713,7 @@ void folio_account_cleaned(struct folio *folio, struct > bdi_writeback *wb) > * > * The caller must hold lock_page_memcg(). Most callers have the folio > * locked. A few have the folio blocked from truncation through other > - * means (eg zap_page_range() has it mapped and is holding the page table > + * means (eg zap_vma_pages() has it mapped and is holding the page table > * lock). This can also be called from mark_buffer_dirty(), which I > * cannot prove is always protected against truncate. strictly speaking this should be unmap_page_range -- Michal Hocko SUSE Labs
Re: [PATCH 3/4] powerpc/pseries: Expose PLPKS config values, support additional fields
On Wed, 2023-01-04 at 14:57 +1100, Russell Currey wrote: > > + maxobjlabelsize = be16_to_cpu(config->maxobjlabelsize) - > > + MAX_LABEL_ATTR_SIZE; > > + maxobjlabelsize = maxobjlabelsize < 0 ? 0 : > > maxobjlabelsize; > > Isn't a bit of precision lost here? There has to be a better way to > handle this. We get a be16 from the hypervisor, turn it into a u16, > and assign that to an s16 in order to handle underflow. Can we just > check if the size we're given is large enough? The hypervisor > documentation also says this value must be at least 255, if we sanity > check that we don't have to worry about underflow. Agreed, and it makes more sense for the value that we return to the user to be the same as the number we actually get from the hypervisor. I'll fix it in the next spin. -- Andrew DonnellanOzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH 4/4] powerpc/pseries: Implement signed update for PLPKS objects
On Wed, 2023-01-04 at 15:04 +1100, Russell Currey wrote:
> > + if (!rc) {
> > + rc = plpks_confirm_object_flushed(label, auth);
> > + rc = pseries_status_to_err(rc);
>
> Doesn't plpks_confirm_object_flushed() already return a Linux-
> friendly
> error code? If I'm reading this right, we'd be replacing any non-
> zero
> return code with -EINVAL.
Good catch, will fix.
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: [PATCH v2 4/7] powerpc/secvar: Handle format string in the consumer
On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote:
> The code that handles the format string in secvar-sysfs.c is entirely
> OPAL specific, so create a new "format" op in secvar_operations to
> make
> the secvar code more generic. No functional change.
>
> Signed-off-by: Russell Currey
LGTM
Reviewed-by: Andrew Donnellan
> ---
> arch/powerpc/include/asm/secvar.h | 1 +
> arch/powerpc/kernel/secvar-sysfs.c | 21 +---
> arch/powerpc/platforms/powernv/opal-secvar.c | 25
>
> 3 files changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/secvar.h
> b/arch/powerpc/include/asm/secvar.h
> index 4cc35b58b986..3b7e5a3625bd 100644
> --- a/arch/powerpc/include/asm/secvar.h
> +++ b/arch/powerpc/include/asm/secvar.h
> @@ -20,6 +20,7 @@ struct secvar_operations {
> uint64_t keybufsize);
> int (*set)(const char *key, uint64_t key_len, u8 *data,
> uint64_t data_size);
> + ssize_t (*format)(char *buf);
> };
>
> #ifdef CONFIG_PPC_SECURE_BOOT
> diff --git a/arch/powerpc/kernel/secvar-sysfs.c
> b/arch/powerpc/kernel/secvar-sysfs.c
> index 02e9fee1552e..190238f51335 100644
> --- a/arch/powerpc/kernel/secvar-sysfs.c
> +++ b/arch/powerpc/kernel/secvar-sysfs.c
> @@ -21,26 +21,7 @@ static struct kset *secvar_kset;
> static ssize_t format_show(struct kobject *kobj, struct
> kobj_attribute *attr,
> char *buf)
> {
> - ssize_t rc = 0;
> - struct device_node *node;
> - const char *format;
> -
> - node = of_find_compatible_node(NULL, NULL, "ibm,secvar-
> backend");
> - if (!of_device_is_available(node)) {
> - rc = -ENODEV;
> - goto out;
> - }
> -
> - rc = of_property_read_string(node, "format", );
> - if (rc)
> - goto out;
> -
> - rc = sysfs_emit(buf, "%s\n", format);
> -
> -out:
> - of_node_put(node);
> -
> - return rc;
> + return secvar_ops->format(buf);
> }
>
>
> diff --git a/arch/powerpc/platforms/powernv/opal-secvar.c
> b/arch/powerpc/platforms/powernv/opal-secvar.c
> index 14133e120bdd..5e9de06b2533 100644
> --- a/arch/powerpc/platforms/powernv/opal-secvar.c
> +++ b/arch/powerpc/platforms/powernv/opal-secvar.c
> @@ -101,10 +101,35 @@ static int opal_set_variable(const char *key,
> uint64_t ksize, u8 *data,
> return opal_status_to_err(rc);
> }
>
> +static ssize_t opal_secvar_format(char *buf)
> +{
> + ssize_t rc = 0;
> + struct device_node *node;
> + const char *format;
> +
> + node = of_find_compatible_node(NULL, NULL, "ibm,secvar-
> backend");
> + if (!of_device_is_available(node)) {
> + rc = -ENODEV;
> + goto out;
> + }
> +
> + rc = of_property_read_string(node, "format", );
> + if (rc)
> + goto out;
> +
> + rc = sysfs_emit(buf, "%s\n", format);
> +
> +out:
> + of_node_put(node);
> +
> + return rc;
> +}
> +
> static const struct secvar_operations opal_secvar_ops = {
> .get = opal_get_variable,
> .get_next = opal_get_next_variable,
> .set = opal_set_variable,
> + .format = opal_secvar_format,
> };
>
> static int opal_secvar_probe(struct platform_device *pdev)
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: [PATCH v2 3/7] powerpc/secvar: Use sysfs_emit() instead of sprintf()
On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote: > The secvar format string and object size sysfs files are both ASCII > text, and should use sysfs_emit(). No functional change. > > Suggested-by: Greg Kroah-Hartman > Signed-off-by: Russell Currey LGTM Reviewed-by: Andrew Donnellan > --- > v2: new > > arch/powerpc/kernel/secvar-sysfs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/secvar-sysfs.c > b/arch/powerpc/kernel/secvar-sysfs.c > index 1ee4640a2641..02e9fee1552e 100644 > --- a/arch/powerpc/kernel/secvar-sysfs.c > +++ b/arch/powerpc/kernel/secvar-sysfs.c > @@ -35,7 +35,7 @@ static ssize_t format_show(struct kobject *kobj, > struct kobj_attribute *attr, > if (rc) > goto out; > > - rc = sprintf(buf, "%s\n", format); > + rc = sysfs_emit(buf, "%s\n", format); > > out: > of_node_put(node); > @@ -57,7 +57,7 @@ static ssize_t size_show(struct kobject *kobj, > struct kobj_attribute *attr, > return rc; > } > > - return sprintf(buf, "%llu\n", dsize); > + return sysfs_emit(buf, "%llu\n", dsize); > } > > static ssize_t data_read(struct file *filep, struct kobject *kobj, -- Andrew DonnellanOzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH v2 2/7] powerpc/secvar: WARN_ON_ONCE() if multiple secvar ops are set
On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote:
> The secvar code only supports one consumer at a time.
>
> Multiple consumers aren't possible at this point in time, but we'd
> want
> it to be obvious if it ever could happen.
>
> Signed-off-by: Russell Currey
This seems sensible - there aren't any cases where set_secvar_ops()
should be called twice.
> ---
> arch/powerpc/kernel/secvar-ops.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/secvar-ops.c
> b/arch/powerpc/kernel/secvar-ops.c
> index 6a29777d6a2d..aa1b2adc2710 100644
> --- a/arch/powerpc/kernel/secvar-ops.c
> +++ b/arch/powerpc/kernel/secvar-ops.c
> @@ -8,10 +8,12 @@
>
> #include
> #include
> +#include
>
> -const struct secvar_operations *secvar_ops __ro_after_init;
> +const struct secvar_operations *secvar_ops __ro_after_init = NULL;
I think this is implicitly NULL, but it's fine to make it explicit.
Reviewed-by: Andrew Donnellan
>
> void set_secvar_ops(const struct secvar_operations *ops)
> {
> + WARN_ON_ONCE(secvar_ops);
> secvar_ops = ops;
> }
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: [PATCH] drivers/misc/ocxl/context.c : eliminate unnecessary type conversions
On Mon, 2022-12-26 at 10:51 +0800, Dong Chuanjian wrote:
> remove unnecessary void* type casting.
>
> Signed-off-by: Dong Chuanjian
[+linuxppc-dev, which was misspelled in the original email]
Acked-by: Andrew Donnellan
>
> diff --git a/drivers/misc/ocxl/context.c
> b/drivers/misc/ocxl/context.c
> index 9eb0d93b01c6..d6e081812300 100644
> --- a/drivers/misc/ocxl/context.c
> +++ b/drivers/misc/ocxl/context.c
> @@ -55,7 +55,7 @@ EXPORT_SYMBOL_GPL(ocxl_context_alloc);
> */
> static void xsl_fault_error(void *data, u64 addr, u64 dsisr)
> {
> - struct ocxl_context *ctx = (struct ocxl_context *) data;
> + struct ocxl_context *ctx = data;
>
> mutex_lock(>xsl_error_lock);
> ctx->xsl_error.addr = addr;
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: [PATCH] powerpc: Fix a wrong version calculation issue in ld_version
On Tue, Jan 03, 2023 at 04:32:18PM +0100, Andreas Schwab wrote: > On Jan 03 2023, Ojaswin Mujoo wrote: > > > If version is of the form x.y.z and length(z) == 8, then most probably > > it is a date [mmdd]. As an approximation, discard the dd and > > parts and keep the mm part in the version. > > I don't think any part of the date should be mixed into the computed > version. It just means that it's a snapshot from after the 2.37 > release, so it should be treated like 2.37 (no further releases has been > made from this branch). > I see, in that case I agree that we can strip out the date part and treat it as x.y.0. I'll wait a bit to see if there are any other comments and then send out a v2. Thanks, ojaswin > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
Re: [PATCH] PCI/AER: Rate limit the reporting of the correctable errors
On Wed, Jan 04, 2023 at 10:27:33AM +0530, Rajat Khandelwal wrote: > Hi Bjorn, > > Thanks for the acknowledgement. > > On 1/4/2023 12:44 AM, Bjorn Helgaas wrote: > > [+cc Paul, Sasha, Leon, Frederick] > > > > (Please cc folks who have commented on previous versions of your > > patch.) > > > > On Tue, Jan 03, 2023 at 10:25:48PM +0530, Rajat Khandelwal wrote: > > > There are many instances where correctable errors tend to inundate > > > the message buffer. We observe such instances during thunderbolt PCIe > > > tunneling. <...> > > > [54982.838808] igc :2b:00.0: device [8086:5502] error > > > status/mask=1000/2000 > > > [54982.838817] igc :2b:00.0:[12] Timeout > > Please remove the timestamps; they don't contribute to understanding > > the problem. > > --> Sure. Please don't add "-->" or any marker to replies. It breaks mail color scheme. > > > > > > This gets repeated continuously, thus inundating the buffer. > > Did you verify that we actually clear the Correctable Error Status > > register? > > --> This patch targets only rate limiting the correctable errors since they > are > non-fatal, and they kind of inundate the CPU logs, particularly during > thunderbolt > connections. It doesn't have an impact anywhere else. > As per your suggestion in the igc patch, I found rate limiting as a doable > option > currently. Have eradicated any kind of masking the bits. You didn't answer on the asked question. "Did you verify that we actually clear the Correctable Error Status register?". Thanks
Re: [PATCH] PCI/AER: Rate limit the reporting of the correctable errors
Hi Bjorn, Thanks for the acknowledgement. On 1/4/2023 12:44 AM, Bjorn Helgaas wrote: [+cc Paul, Sasha, Leon, Frederick] (Please cc folks who have commented on previous versions of your patch.) On Tue, Jan 03, 2023 at 10:25:48PM +0530, Rajat Khandelwal wrote: There are many instances where correctable errors tend to inundate the message buffer. We observe such instances during thunderbolt PCIe tunneling. It's true that they are mitigated by the hardware and are non-fatal but we shouldn't be spamming the logs with such correctable errors as it confuses other kernel developers less familiar with PCI errors, support staff, and users who happen to look at the logs, hence rate limit them. I want a better understanding of why we have so many errors before rate-limiting everybody. --> So, we are debugging this inside Intel along with the thunderbolt/PCIe team. Apparently, it will take some time to reach to a conclusion. Since I witness these errors in other thunderbolt devices also, I am currently segregating all the TBT devices so that we have proper data to debug. A typical example log inside an HP TBT4 dock: [54912.661142] pcieport :00:07.0: AER: Multiple Corrected error received: :2b:00.0 [54912.661194] igc :2b:00.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID) [54912.661203] igc :2b:00.0: device [8086:5502] error status/mask=1100/2000 [54912.661211] igc :2b:00.0:[ 8] Rollover [54912.661219] igc :2b:00.0:[12] Timeout [54982.838760] pcieport :00:07.0: AER: Corrected error received: :2b:00.0 [54982.838798] igc :2b:00.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID) [54982.838808] igc :2b:00.0: device [8086:5502] error status/mask=1000/2000 [54982.838817] igc :2b:00.0:[12] Timeout Please remove the timestamps; they don't contribute to understanding the problem. --> Sure. This gets repeated continuously, thus inundating the buffer. Did you verify that we actually clear the Correctable Error Status register? --> This patch targets only rate limiting the correctable errors since they are non-fatal, and they kind of inundate the CPU logs, particularly during thunderbolt connections. It doesn't have an impact anywhere else. As per your suggestion in the igc patch, I found rate limiting as a doable option currently. Have eradicated any kind of masking the bits. https://bugzilla.kernel.org/show_bug.cgi?id=216863 looks like a similar issue. The issue Frederick is seeing happens when resuming from sleep. Is there some event that triggers the correctable errors you see? --> The signatures look similar but there is no such event which triggers these errors. I witness them in many situations (hot plug, cold boot, warm boot, s0ix, etc.). Further, I think the replay correctable errors arise in thunderbolt PCIe devices because the timeout values are not adjusted properly concerning thunderbolt daisy chains. Not sure, but since these PCIe devices work directly on the motherboard, and only give issues when they are inside thunderbolt devices, I think the addition of PCIe bridges in the daisy chain is not synced with proper timeout values. Bjorn
Re: [PATCH v2 1/7] powerpc/pseries: Log hcall return codes for PLPKS debug
On Fri, 2022-12-30 at 15:20 +1100, Russell Currey wrote:
> The plpks code converts hypervisor return codes into their Linux
> equivalents so that users can understand them. Having access to the
> original return codes is really useful for debugging, so add a
> pr_debug() so we don't lose information from the conversion.
>
> Signed-off-by: Russell Currey
This is indeed useful to have.
Reviewed-by: Andrew Donnellan
Tested-by: Andrew Donnellan
> ---
> arch/powerpc/platforms/pseries/plpks.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/plpks.c
> b/arch/powerpc/platforms/pseries/plpks.c
> index 9e4401aabf4f..820218eb894f 100644
> --- a/arch/powerpc/platforms/pseries/plpks.c
> +++ b/arch/powerpc/platforms/pseries/plpks.c
> @@ -131,6 +131,8 @@ static int pseries_status_to_err(int rc)
> err = -EINVAL;
> }
>
> + pr_debug("Converted hypervisor code %d to Linux %d\n", rc,
> err);
> +
> return err;
> }
>
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: [PATCH 4/4] powerpc/pseries: Implement signed update for PLPKS objects
On Tue, 2022-12-20 at 18:16 +1100, Andrew Donnellan wrote:
> From: Nayna Jain
>
> The Platform Keystore provides a signed update interface which can be
> used
> to create, replace or append to certain variables in the PKS in a
> secure
> fashion, with the hypervisor requiring that the update be signed
> using the
> Platform Key.
>
> Implement an interface to the H_PKS_SIGNED_UPDATE hcall in the plpks
> driver to allow signed updates to PKS objects.
>
> (The plpks driver doesn't need to do any cryptography or otherwise
> handle
> the actual signed variable contents - that will be handled by
> userspace
> tooling.)
>
> Signed-off-by: Nayna Jain
> [ajd: split patch, rewrite commit message, add timeout handling]
> Co-developed-by: Andrew Donnellan
> Signed-off-by: Andrew Donnellan
> ---
> arch/powerpc/include/asm/hvcall.h | 3 +-
> arch/powerpc/platforms/pseries/plpks.c | 81 +++-
> --
> arch/powerpc/platforms/pseries/plpks.h | 5 ++
> 3 files changed, 79 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/hvcall.h
> b/arch/powerpc/include/asm/hvcall.h
> index 95fd7f9485d5..33b26c0cb69b 100644
> --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -336,7 +336,8 @@
> #define H_SCM_FLUSH0x44C
> #define H_GET_ENERGY_SCALE_INFO0x450
> #define H_WATCHDOG 0x45C
> -#define MAX_HCALL_OPCODE H_WATCHDOG
> +#define H_PKS_SIGNED_UPDATE0x454
> +#define MAX_HCALL_OPCODE H_PKS_SIGNED_UPDATE
>
> /* Scope args for H_SCM_UNBIND_ALL */
> #define H_UNBIND_SCOPE_ALL (0x1)
> diff --git a/arch/powerpc/platforms/pseries/plpks.c
> b/arch/powerpc/platforms/pseries/plpks.c
> index c5ae00a8a968..9e4401aabf4f 100644
> --- a/arch/powerpc/platforms/pseries/plpks.c
> +++ b/arch/powerpc/platforms/pseries/plpks.c
> @@ -30,9 +30,9 @@
> #define MAX_NAME_SIZE 239
> #define MAX_DATA_SIZE 4000
>
> -#define PKS_FLUSH_MAX_TIMEOUT 5000 //msec
> -#define PKS_FLUSH_SLEEP 10 //msec
> -#define PKS_FLUSH_SLEEP_RANGE 400
> +#define PKS_MAX_TIMEOUT5000 // msec
> +#define PKS_FLUSH_SLEEP10 // msec
> +#define PKS_FLUSH_SLEEP_RANGE 400
>
> static u8 *ospassword;
> static u16 ospasswordlength;
> @@ -95,6 +95,12 @@ static int pseries_status_to_err(int rc)
> err = -ENOENT;
> break;
> case H_BUSY:
> + case H_LONG_BUSY_ORDER_1_MSEC:
> + case H_LONG_BUSY_ORDER_10_MSEC:
> + case H_LONG_BUSY_ORDER_100_MSEC:
> + case H_LONG_BUSY_ORDER_1_SEC:
> + case H_LONG_BUSY_ORDER_10_SEC:
> + case H_LONG_BUSY_ORDER_100_SEC:
> err = -EBUSY;
> break;
> case H_AUTHORITY:
> @@ -198,14 +204,17 @@ static struct label *construct_label(char
> *component, u8 varos, u8 *name,
> u16 namelen)
> {
> struct label *label;
> - size_t slen;
> + size_t slen = 0;
>
> if (!name || namelen > MAX_NAME_SIZE)
> return ERR_PTR(-EINVAL);
>
> - slen = strlen(component);
> - if (component && slen > sizeof(label->attr.prefix))
> - return ERR_PTR(-EINVAL);
> + // Support NULL component for signed updates
> + if (component) {
> + slen = strlen(component);
> + if (slen > sizeof(label->attr.prefix))
> + return ERR_PTR(-EINVAL);
> + }
>
> // The label structure must not cross a page boundary, so we
> align to the next power of 2
> label = kzalloc(roundup_pow_of_two(sizeof(*label)),
> GFP_KERNEL);
> @@ -372,7 +381,7 @@ static int plpks_confirm_object_flushed(struct
> label *label,
> usleep_range(PKS_FLUSH_SLEEP,
> PKS_FLUSH_SLEEP +
> PKS_FLUSH_SLEEP_RANGE);
> timeout = timeout + PKS_FLUSH_SLEEP;
> - } while (timeout < PKS_FLUSH_MAX_TIMEOUT);
> + } while (timeout < PKS_MAX_TIMEOUT);
>
> if (timed_out)
> rc = -ETIMEDOUT;
> @@ -382,6 +391,60 @@ static int plpks_confirm_object_flushed(struct
> label *label,
> return rc;
> }
>
> +int plpks_signed_update_var(struct plpks_var var, u64 flags)
> +{
> + unsigned long retbuf[PLPAR_HCALL9_BUFSIZE] = {0};
> + int rc;
> + struct label *label;
> + struct plpks_auth *auth;
> + u64 continuetoken = 0;
> + u64 timeout = 0;
> +
> + if (!var.data || var.datalen <= 0 || var.namelen >
> MAX_NAME_SIZE)
> + return -EINVAL;
> +
> + if (!(var.policy & SIGNEDUPDATE))
> + return -EINVAL;
> +
> + auth = construct_auth(PKS_OS_OWNER);
> + if (IS_ERR(auth))
> + return PTR_ERR(auth);
> +
> + label = construct_label(var.component, var.os, var.name,
> var.namelen);
> + if (IS_ERR(label)) {
> + rc = PTR_ERR(label);
> + goto out;
> + }
Re: [PATCH 3/4] powerpc/pseries: Expose PLPKS config values, support additional fields
On Tue, 2022-12-20 at 18:16 +1100, Andrew Donnellan wrote:
> From: Nayna Jain
>
> The plpks driver uses the H_PKS_GET_CONFIG hcall to retrieve
> configuration
> and status information about the PKS from the hypervisor.
>
> Update _plpks_get_config() to handle some additional fields. Add
> getter
> functions to allow the PKS configuration information to be accessed
> from
> other files.
>
> While we're here, move the config struct in _plpks_get_config() off
> the
> stack - it's getting large and we also need to make sure it doesn't
> cross
> a page boundary.
>
> Signed-off-by: Nayna Jain
> [ajd: split patch, extend to support additional v3 API fields, minor
> fixes]
> Co-developed-by: Andrew Donnellan
> Signed-off-by: Andrew Donnellan
> ---
> arch/powerpc/platforms/pseries/plpks.c | 118 ++-
> --
> arch/powerpc/platforms/pseries/plpks.h | 58
> 2 files changed, 164 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/plpks.c
> b/arch/powerpc/platforms/pseries/plpks.c
> index 8ccc91143370..c5ae00a8a968 100644
> --- a/arch/powerpc/platforms/pseries/plpks.c
> +++ b/arch/powerpc/platforms/pseries/plpks.c
> @@ -38,8 +38,16 @@ static u8 *ospassword;
> static u16 ospasswordlength;
>
> // Retrieved with H_PKS_GET_CONFIG
> +static u8 version;
> +static u16 objoverhead;
> static u16 maxpwsize;
> static u16 maxobjsize;
> +static s16 maxobjlabelsize;
> +static u32 totalsize;
> +static u32 usedspace;
> +static u32 supportedpolicies;
> +static u32 maxlargeobjectsize;
> +static u64 signedupdatealgorithms;
>
> struct plpks_auth {
> u8 version;
> @@ -220,32 +228,118 @@ static struct label *construct_label(char
> *component, u8 varos, u8 *name,
> static int _plpks_get_config(void)
> {
> unsigned long retbuf[PLPAR_HCALL_BUFSIZE] = { 0 };
> - struct {
> + struct config {
> u8 version;
> u8 flags;
> - __be32 rsvd0;
> + __be16 rsvd0;
> + __be16 objoverhead;
> __be16 maxpwsize;
> __be16 maxobjlabelsize;
> __be16 maxobjsize;
> __be32 totalsize;
> __be32 usedspace;
> __be32 supportedpolicies;
> - __be64 rsvd1;
> - } __packed config;
> + __be32 maxlargeobjectsize;
> + __be64 signedupdatealgorithms;
> + u8 rsvd1[476];
> + } __packed *config;
> size_t size;
> - int rc;
> + int rc = 0;
> +
> + size = sizeof(*config);
> +
> + // Config struct must not cross a page boundary. So long as
> the struct
> + // size is a power of 2, this should be fine as alignment is
> guaranteed
> + config = kzalloc(size, GFP_KERNEL);
> + if (!config) {
> + rc = -ENOMEM;
> + goto err;
> + }
>
> - size = sizeof(config);
> + rc = plpar_hcall(H_PKS_GET_CONFIG, retbuf,
> virt_to_phys(config), size);
>
> - rc = plpar_hcall(H_PKS_GET_CONFIG, retbuf,
> virt_to_phys(), size);
> + if (rc != H_SUCCESS) {
> + rc = pseries_status_to_err(rc);
> + goto err;
> + }
>
> - if (rc != H_SUCCESS)
> - return pseries_status_to_err(rc);
> + version = config->version;
> + objoverhead = be16_to_cpu(config->objoverhead);
> + maxpwsize = be16_to_cpu(config->maxpwsize);
> + maxobjsize = be16_to_cpu(config->maxobjsize);
> + maxobjlabelsize = be16_to_cpu(config->maxobjlabelsize) -
> + MAX_LABEL_ATTR_SIZE;
> + maxobjlabelsize = maxobjlabelsize < 0 ? 0 : maxobjlabelsize;
Isn't a bit of precision lost here? There has to be a better way to
handle this. We get a be16 from the hypervisor, turn it into a u16,
and assign that to an s16 in order to handle underflow. Can we just
check if the size we're given is large enough? The hypervisor
documentation also says this value must be at least 255, if we sanity
check that we don't have to worry about underflow.
> + totalsize = be32_to_cpu(config->totalsize);
> + usedspace = be32_to_cpu(config->usedspace);
> + supportedpolicies = be32_to_cpu(config->supportedpolicies);
> + maxlargeobjectsize = be32_to_cpu(config->maxlargeobjectsize);
> + signedupdatealgorithms = be64_to_cpu(config-
> >signedupdatealgorithms);
> +
> +err:
> + kfree(config);
> + return rc;
> +}
>
> - maxpwsize = be16_to_cpu(config.maxpwsize);
> - maxobjsize = be16_to_cpu(config.maxobjsize);
> +u8 plpks_get_version(void)
> +{
> + return version;
> +}
> +
> +u16 plpks_get_objoverhead(void)
> +{
> + return objoverhead;
> +}
> +
> +u16 plpks_get_maxpwsize(void)
> +{
> + return maxpwsize;
> +}
> +
> +u16 plpks_get_maxobjectsize(void)
> +{
> + return maxobjsize;
> +}
> +
> +u16 plpks_get_maxobjectlabelsize(void)
and it's returned as a u16
Re: [PATCH 2/4] powerpc/pseries: Fix alignment of PLPKS structures and buffers
On Tue, 2022-12-20 at 18:16 +1100, Andrew Donnellan wrote:
> A number of structures and buffers passed to PKS hcalls have
> alignment
> requirements, which could on occasion cause problems:
>
> - Authorisation structures must be 16-byte aligned and must not cross
> a
> page boundary
>
> - Label structures must not cross page coundaries
>
> - Password output buffers must not cross page boundaries
>
> Round up the allocations of these structures/buffers to the next
> power of
> 2 to make sure this happens.
>
> Reported-by: Benjamin Gray
> Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform
> KeyStore")
> Signed-off-by: Andrew Donnellan
>
Reviewed-by: Russell Currey
Re: [PATCH 1/4] powerpc/pseries: Fix handling of PLPKS object flushing timeout
On Tue, 2022-12-20 at 18:16 +1100, Andrew Donnellan wrote:
> plpks_confirm_object_flushed() uses the H_PKS_CONFIRM_OBJECT_FLUSHED
> hcall
> to check whether changes to an object in the Platform KeyStore have
> been
> flushed to non-volatile storage.
>
> The hcall returns two output values, the return code and the flush
> status.
> plpks_confirm_object_flushed() polls the hcall until either the flush
> status has updated, the return code is an error, or a timeout has
> been
> exceeded.
>
> While we're still polling, the hcall is returning H_SUCCESS (0) as
> the
> return code. In the timeout case, this means that upon exiting the
> polling
> loop, rc is 0, and therefore 0 is returned to the user.
>
> Handle the timeout case separately and return ETIMEDOUT if triggered.
>
> Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform
> KeyStore")
> Reported-by: Benjamin Gray
> Signed-off-by: Andrew Donnellan
Tested-by: Russell Currey
Reviewed-by: Russell Currey
[PATCH] ASoC: fsl_micfil: Correct the number of steps on SX controls
The parameter "max" of SOC_SINGLE_SX_TLV() means the number of steps
rather than maximum value. This patch corrects the minimum value to -8
and the number of steps to 15.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_micfil.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index d7e6fc996166..d4d3bc7ca87c 100644
--- a/sound/soc/fsl/fsl_micfil.c
+++ b/sound/soc/fsl/fsl_micfil.c
@@ -325,21 +325,21 @@ static int hwvad_detected(struct snd_kcontrol *kcontrol,
static const struct snd_kcontrol_new fsl_micfil_snd_controls[] = {
SOC_SINGLE_SX_TLV("CH0 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(0), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(0), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH1 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(1), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(1), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH2 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(2), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(2), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH3 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(3), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(3), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH4 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(4), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(4), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH5 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(5), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(5), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH6 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(6), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(6), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH7 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(7), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(7), 0x8, 0xF, gain_tlv),
SOC_ENUM_EXT("MICFIL Quality Select",
fsl_micfil_quality_enum,
micfil_quality_get, micfil_quality_set),
--
2.25.1
Re: [bpf-next v1] bpf: drop deprecated bpf_jit_enable == 2
在 2023/1/3 下午11:42，“Daniel Borkmann” 写入:
On 1/3/23 2:24 PM, x...@infragraf.org wrote:
> From: Tonghao Zhang
>
> The x86_64 can't dump the valid insn in this way. A test BPF prog
> which include subprog:
>
> $ llvm-objdump -d subprog.o
> Disassembly of section .text:
> :
> 0:18 01 00 00 73 75 62 70 00 00 00 00 72 6f 67 00 r1 =
29114459903653235 ll
> 2:7b 1a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r1
> 3:bf a1 00 00 00 00 00 00 r1 = r10
> 4:07 01 00 00 f8 ff ff ff r1 += -8
> 5:b7 02 00 00 08 00 00 00 r2 = 8
> 6:85 00 00 00 06 00 00 00 call 6
> 7:95 00 00 00 00 00 00 00 exit
> Disassembly of section raw_tp/sys_enter:
> :
> 0:85 10 00 00 ff ff ff ff call -1
> 1:b7 00 00 00 00 00 00 00 r0 = 0
> 2:95 00 00 00 00 00 00 00 exit
>
> kernel print message:
> [ 580.775387] flen=8 proglen=51 pass=3 image=a000c20c
from=kprobe-load pid=1643
> [ 580.777236] JIT code: : cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc cc
> [ 580.779037] JIT code: 0010: cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc cc
> [ 580.780767] JIT code: 0020: cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc cc
> [ 580.782568] JIT code: 0030: cc cc cc
>
> $ bpf_jit_disasm
> 51 bytes emitted from JIT compiler (pass:3, flen:8)
> a000c20c + :
> 0:int3
> 1:int3
> 2:int3
> 3:int3
> 4:int3
> 5:int3
> ...
>
> Until bpf_jit_binary_pack_finalize is invoked, we copy rw_header to header
> and then image/insn is valid. BTW, we can use the "bpftool prog dump"
JITed instructions.
>
> * clean up the doc
> * remove bpf_jit_disasm tool
> * set bpf_jit_enable only 0 or 1.
>
> Signed-off-by: Tonghao Zhang
> Suggested-by: Alexei Starovoitov
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: Andrii Nakryiko
> Cc: Martin KaFai Lau
> Cc: Song Liu
> Cc: Yonghong Song
> Cc: John Fastabend
> Cc: KP Singh
> Cc: Stanislav Fomichev
> Cc: Hao Luo
> Cc: Jiri Olsa
> Cc: Hou Tao
> ---
> Documentation/admin-guide/sysctl/net.rst | 2 +-
> Documentation/networking/filter.rst | 98 +--
> arch/arm/net/bpf_jit_32.c| 4 -
> arch/arm64/net/bpf_jit_comp.c| 4 -
> arch/loongarch/net/bpf_jit.c | 4 -
> arch/mips/net/bpf_jit_comp.c | 3 -
> arch/powerpc/net/bpf_jit_comp.c | 11 -
> arch/riscv/net/bpf_jit_core.c| 3 -
> arch/s390/net/bpf_jit_comp.c | 4 -
> arch/sparc/net/bpf_jit_comp_32.c | 3 -
> arch/sparc/net/bpf_jit_comp_64.c | 13 -
> arch/x86/net/bpf_jit_comp.c | 3 -
> arch/x86/net/bpf_jit_comp32.c| 3 -
> net/core/sysctl_net_core.c | 14 +-
> tools/bpf/.gitignore | 1 -
> tools/bpf/Makefile | 10 +-
> tools/bpf/bpf_jit_disasm.c | 332 ---
> 17 files changed, 8 insertions(+), 504 deletions(-)
> delete mode 100644 tools/bpf/bpf_jit_disasm.c
>
> diff --git a/Documentation/admin-guide/sysctl/net.rst
b/Documentation/admin-guide/sysctl/net.rst
> index 6394f5dc2303..45d3d965276c 100644
> --- a/Documentation/admin-guide/sysctl/net.rst
> +++ b/Documentation/admin-guide/sysctl/net.rst
> @@ -87,7 +87,7 @@ Values:
>
> - 0 - disable the JIT (default value)
> - 1 - enable the JIT
> - - 2 - enable the JIT and ask the compiler to emit traces on kernel log.
> + - 2 - deprecated in linux 6.2
I'd make it more clear in the docs and reword it as follows (also, it'll be
in 6.3, not 6.2):
- 2 - enable the JIT and ask the compiler to emit traces on kernel log.
(deprecated since v6.3, use ``bpftool prog dump jited id ``
instead)
>
> bpf_jit_harden
> --
[...]
> diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
> index 5b1ce656baa1..731a2eb0f68e 100644
> --- a/net/core/sysctl_net_core.c
> +++ b/net/core/sysctl_net_core.c
> @@ -275,16 +275,8 @@ static int proc_dointvec_minmax_bpf_enable(struct
ctl_table *table, int write,
>
> tmp.data = _enable;
> ret = proc_dointvec_minmax(, write, buffer, lenp, ppos);
> - if (write && !ret) {
> - if (jit_enable < 2 ||
> - (jit_enable == 2 && bpf_dump_raw_ok(current_cred( {
> - *(int *)table->data = jit_enable;
> -
[PATCH] mm: remove zap_page_range and create zap_vma_pages
zap_page_range was originally designed to unmap pages within an address
range that could span multiple vmas. While working on [1], it was
discovered that all callers of zap_page_range pass a range entirely within
a single vma. In addition, the mmu notification call within zap_page
range does not correctly handle ranges that span multiple vmas. When
crossing a vma boundary, a new mmu_notifier_range_init/end call pair
with the new vma should be made.
Instead of fixing zap_page_range, do the following:
- Create a new routine zap_vma_pages() that will remove all pages within
the passed vma. Most users of zap_page_range pass the entire vma and
can use this new routine.
- For callers of zap_page_range not passing the entire vma, instead call
zap_page_range_single().
- Remove zap_page_range.
[1]
https://lore.kernel.org/linux-mm/20221114235507.294320-2-mike.krav...@oracle.com/
Suggested-by: Peter Xu
Signed-off-by: Mike Kravetz
---
RFC->v1 Created zap_vma_pages to zap entire vma (Christoph Hellwig)
Did not add Acked-by's as routine was changed.
arch/arm64/kernel/vdso.c| 6 ++---
arch/powerpc/kernel/vdso.c | 4 +---
arch/powerpc/platforms/book3s/vas-api.c | 2 +-
arch/powerpc/platforms/pseries/vas.c| 3 +--
arch/riscv/kernel/vdso.c| 6 ++---
arch/s390/kernel/vdso.c | 4 +---
arch/s390/mm/gmap.c | 2 +-
arch/x86/entry/vdso/vma.c | 4 +---
drivers/android/binder_alloc.c | 2 +-
include/linux/mm.h | 7 --
mm/memory.c | 30 -
mm/page-writeback.c | 2 +-
net/ipv4/tcp.c | 7 +++---
13 files changed, 21 insertions(+), 58 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index e59a32aa0c49..0119dc91abb5 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -138,13 +138,11 @@ int vdso_join_timens(struct task_struct *task, struct
time_namespace *ns)
mmap_read_lock(mm);
for_each_vma(vmi, vma) {
- unsigned long size = vma->vm_end - vma->vm_start;
-
if (vma_is_special_mapping(vma, vdso_info[VDSO_ABI_AA64].dm))
- zap_page_range(vma, vma->vm_start, size);
+ zap_vma_pages(vma);
#ifdef CONFIG_COMPAT_VDSO
if (vma_is_special_mapping(vma, vdso_info[VDSO_ABI_AA32].dm))
- zap_page_range(vma, vma->vm_start, size);
+ zap_vma_pages(vma);
#endif
}
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 507f8228f983..7a2ff9010f17 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -120,10 +120,8 @@ int vdso_join_timens(struct task_struct *task, struct
time_namespace *ns)
mmap_read_lock(mm);
for_each_vma(vmi, vma) {
- unsigned long size = vma->vm_end - vma->vm_start;
-
if (vma_is_special_mapping(vma, _spec))
- zap_page_range(vma, vma->vm_start, size);
+ zap_vma_pages(vma);
}
mmap_read_unlock(mm);
diff --git a/arch/powerpc/platforms/book3s/vas-api.c
b/arch/powerpc/platforms/book3s/vas-api.c
index eb5bed333750..9580e8e12165 100644
--- a/arch/powerpc/platforms/book3s/vas-api.c
+++ b/arch/powerpc/platforms/book3s/vas-api.c
@@ -414,7 +414,7 @@ static vm_fault_t vas_mmap_fault(struct vm_fault *vmf)
/*
* When the LPAR lost credits due to core removal or during
* migration, invalidate the existing mapping for the current
-* paste addresses and set windows in-active (zap_page_range in
+* paste addresses and set windows in-active (zap_vma_pages in
* reconfig_close_windows()).
* New mapping will be done later after migration or new credits
* available. So continue to receive faults if the user space
diff --git a/arch/powerpc/platforms/pseries/vas.c
b/arch/powerpc/platforms/pseries/vas.c
index 4ad6e510d405..559112312810 100644
--- a/arch/powerpc/platforms/pseries/vas.c
+++ b/arch/powerpc/platforms/pseries/vas.c
@@ -760,8 +760,7 @@ static int reconfig_close_windows(struct vas_caps *vcap,
int excess_creds,
* is done before the original mmap() and after the ioctl.
*/
if (vma)
- zap_page_range(vma, vma->vm_start,
- vma->vm_end - vma->vm_start);
+ zap_vma_pages(vma);
mmap_write_unlock(task_ref->mm);
mutex_unlock(_ref->mmap_mutex);
diff --git a/arch/riscv/kernel/vdso.c b/arch/riscv/kernel/vdso.c
index e410275918ac..5c30212d8d1c 100644
--- a/arch/riscv/kernel/vdso.c
+++ b/arch/riscv/kernel/vdso.c
@@ -124,13 +124,11 @@ int vdso_join_timens(struct task_struct *task, struct
time_namespace *ns)
Re: [FSL P50x0] DPAA Ethernet issue
> On 3. Jan 2023, at 05:04, Christian Zigotzky wrote: > > On 02 January 2023 at 04:32 am, Christian Zigotzky wrote: >> On 01 January 2023 at 07:11 pm, Sean Anderson wrote: >> >> Thank you for testing this. Unfortunately, I have no P-series hardware, >> so I was unable to test the 10gec/dtsec parts of this conversion. I had >> hoped that this would get tested by someone with the hardware (at NXP) >> before now, but it seems you get to be the "lucky" first user. >> >> I see you have labeled one of your kernels as supporting QEMU. Do you >> happen to have instructions for running Linux on QEMU? >> >> Can you try the following patch. I think my mail client will mangle it, so >> I have also attached it to this email. >> >> >> >> Hi Sean, >> >> Thanks a lot for your answer. >> >> I use the virtio-net device in a virtual e5500 QEMU/KVM HV machine. [1] [2] >> >> I will test your patch as soon as possible. >> >> Thanks, >> Christian >> >> [1] QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel >> uImage-6.2 -drive >> format=raw,file=void-live-powerpc-20220129.img,index=0,if=virtio -netdev >> user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw root=/dev/vda2" >> -device virtio-gpu -device virtio-mouse-pci -device virtio-keyboard-pci >> -device pci-ohci,id=newusb -audiodev >> id=sndbe,driver=pa,server=/run/user/1000/pulse/native -device >> usb-audio,bus=newusb.0 -enable-kvm -smp 4 -fsdev >> local,security_model=passthrough,id=fsdev0,path=/home/amigaone/Music -device >> virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=hostshare >> >> [2] https://forum.hyperion-entertainment.com/viewtopic.php?p=46749 > > Hi Sean, > > I tested your patch with the RC2 today but unfortunately the kernel doesn't > link after compiling. > > Error messages: > > LD .tmp_vmlinux.kallsyms1 > `.exit.text' referenced in section `__bug_table' of crypto/algboss.o: defined > in discarded section `.exit.text' of crypto/algboss.o > `.exit.text' referenced in section `__bug_table' of crypto/algif_hash.o: > defined in discarded section `.exit.text' of crypto/algif_hash.o > `.exit.text' referenced in section `__bug_table' of > drivers/char/hw_random/core.o: defined in discarded section `.exit.text' of > drivers/char/hw_random/core.o > make[1]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1 > make: *** [Makefile:1252: vmlinux] Error 2 > > Maybe it is not an issue because of the patch because the RC1 compilied and > linked with the patch. > > @Dave > Please test the RC1 with Sean's patch. > > Download: http://www.xenosoft.de/uImage-6.2-dpaa-t1 > > Cheers, > Christian Hi Sean, Dave successfully tested the DPAA Ethernet with the patched RC1 on his P5020 board (X5000) today. Link to the test thread: https://forum.hyperion-entertainment.com/viewtopic.php?p=56360#p56360 Your patch has solved the issue. Thanks for your help. Cheers, Christian
Re: [FSL P50x0] DPAA Ethernet issue
On 1/2/23 02:58, Linux kernel regression tracking (#info) wrote: > [TLDR: I'm adding this report to the list of tracked Linux kernel > regressions; all text you find below is based on a few templates > paragraphs you might have encountered already already in similar form. > See link in footer if these mails annoy you.] > > On 01.01.23 15:18, Christian Zigotzky wrote: >> >> The DPAA Ethernet doesn’t work anymore on our FSL P5020/P5040 boards [1] >> since the first updates after the final kernel 6.1 [2]. >> We bisected yesterday [3] and found the problematic commit [4]. I was >> able to revert it. After that the DPAA Ethernet works again. I created a >> patch for reverting the commit [4]. After patching and compiling, the >> DPAA Ethernet also works again. >> >> It seems, that the new driver doesn’t work with our onboard DPAA network >> interfaces. >> >> Could you please check your commit? [4] >> >> Thanks, >> Christian >> >> [1] http://wiki.amiga.org/index.php?title=X5000 >> [2] https://forum.hyperion-entertainment.com/viewtopic.php?p=56326#p56326 >> [3] https://forum.hyperion-entertainment.com/viewtopic.php?p=56334#p56334 >> [4] lnet: dpaa: Convert to phylink: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.1=5d93cfcf7360eac9903774fe94f626c9ead2049d > > Thanks for the report. To be sure the issue doesn't fall through the > cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression > tracking bot: > > #regzbot ^introduced 5d93cfcf7360 > #regzbot title lnet: dpaa: Ethernet issues > #regzbot ignore-activity > > This isn't a regression? This issue or a fix for it are already > discussed somewhere else? It was fixed already? You want to clarify when > the regression started to happen? Or point out I got the title or > something else totally wrong? Then just reply and tell me -- ideally > while also telling regzbot about it, as explained by the page listed in > the footer of this mail. > > Reminder for developers: When fixing the issue, add 'Link:' tags > pointing to the report (see page linked in footer for details). > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) #regzbot fix: 7dc618385419
Re: [PATCH] PCI/AER: Rate limit the reporting of the correctable errors
[+cc Paul, Sasha, Leon, Frederick] (Please cc folks who have commented on previous versions of your patch.) On Tue, Jan 03, 2023 at 10:25:48PM +0530, Rajat Khandelwal wrote: > There are many instances where correctable errors tend to inundate > the message buffer. We observe such instances during thunderbolt PCIe > tunneling. > > It's true that they are mitigated by the hardware and are non-fatal > but we shouldn't be spamming the logs with such correctable errors as it > confuses other kernel developers less familiar with PCI errors, support > staff, and users who happen to look at the logs, hence rate limit them. I want a better understanding of why we have so many errors before rate-limiting everybody. > A typical example log inside an HP TBT4 dock: > [54912.661142] pcieport :00:07.0: AER: Multiple Corrected error received: > :2b:00.0 > [54912.661194] igc :2b:00.0: PCIe Bus Error: severity=Corrected, > type=Data Link Layer, (Transmitter ID) > [54912.661203] igc :2b:00.0: device [8086:5502] error > status/mask=1100/2000 > [54912.661211] igc :2b:00.0:[ 8] Rollover > [54912.661219] igc :2b:00.0:[12] Timeout > [54982.838760] pcieport :00:07.0: AER: Corrected error received: > :2b:00.0 > [54982.838798] igc :2b:00.0: PCIe Bus Error: severity=Corrected, > type=Data Link Layer, (Transmitter ID) > [54982.838808] igc :2b:00.0: device [8086:5502] error > status/mask=1000/2000 > [54982.838817] igc :2b:00.0:[12] Timeout Please remove the timestamps; they don't contribute to understanding the problem. > This gets repeated continuously, thus inundating the buffer. Did you verify that we actually clear the Correctable Error Status register? https://bugzilla.kernel.org/show_bug.cgi?id=216863 looks like a similar issue. The issue Frederick is seeing happens when resuming from sleep. Is there some event that triggers the correctable errors you see? Bjorn
[PATCH] PCI/AER: Rate limit the reporting of the correctable errors
There are many instances where correctable errors tend to inundate
the message buffer. We observe such instances during thunderbolt PCIe
tunneling.
It's true that they are mitigated by the hardware and are non-fatal
but we shouldn't be spamming the logs with such correctable errors as it
confuses other kernel developers less familiar with PCI errors, support
staff, and users who happen to look at the logs, hence rate limit them.
A typical example log inside an HP TBT4 dock:
[54912.661142] pcieport :00:07.0: AER: Multiple Corrected error received:
:2b:00.0
[54912.661194] igc :2b:00.0: PCIe Bus Error: severity=Corrected, type=Data
Link Layer, (Transmitter ID)
[54912.661203] igc :2b:00.0: device [8086:5502] error
status/mask=1100/2000
[54912.661211] igc :2b:00.0:[ 8] Rollover
[54912.661219] igc :2b:00.0:[12] Timeout
[54982.838760] pcieport :00:07.0: AER: Corrected error received:
:2b:00.0
[54982.838798] igc :2b:00.0: PCIe Bus Error: severity=Corrected, type=Data
Link Layer, (Transmitter ID)
[54982.838808] igc :2b:00.0: device [8086:5502] error
status/mask=1000/2000
[54982.838817] igc :2b:00.0:[12] Timeout
This gets repeated continuously, thus inundating the buffer.
Signed-off-by: Rajat Khandelwal
---
drivers/pci/pcie/aer.c | 54 +++---
include/linux/pci.h| 3 +++
2 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index e2d8a74f83c3..7ae6761a8e59 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -684,23 +684,24 @@ static void __aer_print_error(struct pci_dev *dev,
{
const char **strings;
unsigned long status = info->status & ~info->mask;
- const char *level, *errmsg;
+ const char *errmsg;
int i;
- if (info->severity == AER_CORRECTABLE) {
+ if (info->severity == AER_CORRECTABLE)
strings = aer_correctable_error_string;
- level = KERN_WARNING;
- } else {
+ else
strings = aer_uncorrectable_error_string;
- level = KERN_ERR;
- }
for_each_set_bit(i, , 32) {
errmsg = strings[i];
if (!errmsg)
errmsg = "Unknown Error Bit";
- pci_printk(level, dev, " [%2d] %-22s%s\n", i, errmsg,
+ if (info->severity == AER_CORRECTABLE)
+ pci_warn_ratelimited(dev, " [%2d] %-22s%s\n", i,
errmsg,
+info->first_error == i ? "
(First)" : "");
+ else
+ pci_err(dev, " [%2d] %-22s%s\n", i, errmsg,
info->first_error == i ? " (First)" : "");
}
pci_dev_aer_stats_incr(dev, info);
@@ -710,7 +711,6 @@ void aer_print_error(struct pci_dev *dev, struct
aer_err_info *info)
{
int layer, agent;
int id = ((dev->bus->number << 8) | dev->devfn);
- const char *level;
if (!info->status) {
pci_err(dev, "PCIe Bus Error: severity=%s, type=Inaccessible,
(Unregistered Agent ID)\n",
@@ -721,14 +718,21 @@ void aer_print_error(struct pci_dev *dev, struct
aer_err_info *info)
layer = AER_GET_LAYER_ERROR(info->severity, info->status);
agent = AER_GET_AGENT(info->severity, info->status);
- level = (info->severity == AER_CORRECTABLE) ? KERN_WARNING : KERN_ERR;
+ if (info->severity == AER_CORRECTABLE) {
+ pci_warn_ratelimited(dev, "PCIe Bus Error: severity=%s,
type=%s, (%s)\n",
+aer_error_severity_string[info->severity],
+aer_error_layer[layer],
aer_agent_string[agent]);
- pci_printk(level, dev, "PCIe Bus Error: severity=%s, type=%s, (%s)\n",
- aer_error_severity_string[info->severity],
- aer_error_layer[layer], aer_agent_string[agent]);
+ pci_warn_ratelimited(dev, " device [%04x:%04x] error
status/mask=%08x/%08x\n",
+dev->vendor, dev->device, info->status,
info->mask);
+ } else {
+ pci_err(dev, "PCIe Bus Error: severity=%s, type=%s, (%s)\n",
+ aer_error_severity_string[info->severity],
+ aer_error_layer[layer], aer_agent_string[agent]);
- pci_printk(level, dev, " device [%04x:%04x] error
status/mask=%08x/%08x\n",
- dev->vendor, dev->device, info->status, info->mask);
+ pci_err(dev, " device [%04x:%04x] error
status/mask=%08x/%08x\n",
+ dev->vendor, dev->device, info->status, info->mask);
+ }
__aer_print_error(dev, info);
@@ -748,11 +755,19 @@ static void aer_print_port_info(struct pci_dev *dev,
struct aer_err_info *info)
u8 bus = info->id >> 8;
u8 devfn = info->id & 0xff;
[bpf-next v1] bpf: drop deprecated bpf_jit_enable == 2
From: Tonghao Zhang The x86_64 can't dump the valid insn in this way. A test BPF prog which include subprog: $ llvm-objdump -d subprog.o Disassembly of section .text: : 0: 18 01 00 00 73 75 62 70 00 00 00 00 72 6f 67 00 r1 = 29114459903653235 ll 2: 7b 1a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r1 3: bf a1 00 00 00 00 00 00 r1 = r10 4: 07 01 00 00 f8 ff ff ff r1 += -8 5: b7 02 00 00 08 00 00 00 r2 = 8 6: 85 00 00 00 06 00 00 00 call 6 7: 95 00 00 00 00 00 00 00 exit Disassembly of section raw_tp/sys_enter: : 0: 85 10 00 00 ff ff ff ff call -1 1: b7 00 00 00 00 00 00 00 r0 = 0 2: 95 00 00 00 00 00 00 00 exit kernel print message: [ 580.775387] flen=8 proglen=51 pass=3 image=a000c20c from=kprobe-load pid=1643 [ 580.777236] JIT code: : cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [ 580.779037] JIT code: 0010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [ 580.780767] JIT code: 0020: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [ 580.782568] JIT code: 0030: cc cc cc $ bpf_jit_disasm 51 bytes emitted from JIT compiler (pass:3, flen:8) a000c20c + : 0: int3 1: int3 2: int3 3: int3 4: int3 5: int3 ... Until bpf_jit_binary_pack_finalize is invoked, we copy rw_header to header and then image/insn is valid. BTW, we can use the "bpftool prog dump" JITed instructions. * clean up the doc * remove bpf_jit_disasm tool * set bpf_jit_enable only 0 or 1. Signed-off-by: Tonghao Zhang Suggested-by: Alexei Starovoitov Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Andrii Nakryiko Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: John Fastabend Cc: KP Singh Cc: Stanislav Fomichev Cc: Hao Luo Cc: Jiri Olsa Cc: Hou Tao --- Documentation/admin-guide/sysctl/net.rst | 2 +- Documentation/networking/filter.rst | 98 +-- arch/arm/net/bpf_jit_32.c| 4 - arch/arm64/net/bpf_jit_comp.c| 4 - arch/loongarch/net/bpf_jit.c | 4 - arch/mips/net/bpf_jit_comp.c | 3 - arch/powerpc/net/bpf_jit_comp.c | 11 - arch/riscv/net/bpf_jit_core.c| 3 - arch/s390/net/bpf_jit_comp.c | 4 - arch/sparc/net/bpf_jit_comp_32.c | 3 - arch/sparc/net/bpf_jit_comp_64.c | 13 - arch/x86/net/bpf_jit_comp.c | 3 - arch/x86/net/bpf_jit_comp32.c| 3 - net/core/sysctl_net_core.c | 14 +- tools/bpf/.gitignore | 1 - tools/bpf/Makefile | 10 +- tools/bpf/bpf_jit_disasm.c | 332 --- 17 files changed, 8 insertions(+), 504 deletions(-) delete mode 100644 tools/bpf/bpf_jit_disasm.c diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index 6394f5dc2303..45d3d965276c 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst @@ -87,7 +87,7 @@ Values: - 0 - disable the JIT (default value) - 1 - enable the JIT - - 2 - enable the JIT and ask the compiler to emit traces on kernel log. + - 2 - deprecated in linux 6.2 bpf_jit_harden -- diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst index f69da5074860..5f51c050e88f 100644 --- a/Documentation/networking/filter.rst +++ b/Documentation/networking/filter.rst @@ -520,102 +520,8 @@ been previously enabled by root:: echo 1 > /proc/sys/net/core/bpf_jit_enable -For JIT developers, doing audits etc, each compile run can output the generated -opcode image into the kernel log via:: - - echo 2 > /proc/sys/net/core/bpf_jit_enable - -Example output from dmesg:: - -[ 3389.935842] flen=6 proglen=70 pass=3 image=a0069c8f -[ 3389.935847] JIT code: : 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 68 -[ 3389.935849] JIT code: 0010: 44 2b 4f 6c 4c 8b 87 d8 00 00 00 be 0c 00 00 00 -[ 3389.935850] JIT code: 0020: e8 1d 94 ff e0 3d 00 08 00 00 75 16 be 17 00 00 -[ 3389.935851] JIT code: 0030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 00 00 -[ 3389.935852] JIT code: 0040: eb 02 31 c0 c9 c3 - -When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set to 1 and -setting any other value than that will return in failure. This is even the case for -setting bpf_jit_enable to 2, since dumping the final JIT image into the kernel log -is discouraged and introspection through bpftool (under tools/bpf/bpftool/) is the -generally recommended approach instead. - -In the kernel source tree under tools/bpf/, there's bpf_jit_disasm for -generating disassembly out of the kernel log's hexdump:: - - # ./bpf_jit_disasm - 70 bytes emitted from JIT compiler (pass:3, flen:6) -
[PATCH v2 1/2] powerpc/ps3: Change updateboltedpp panic to info
Commit fdacae8a84024474afff234bdd1dbe19ad597a10 (powerpc: Activate
CONFIG_STRICT_KERNEL_RWX by default) causes ps3_hpte_updateboltedpp()
to be called. Change the panic statment in ps3_hpte_updateboltedpp()
to a pr_info statement so that bootup can continue.
Signed-off-by: Geoff Levand
---
arch/powerpc/platforms/ps3/htab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/ps3/htab.c
b/arch/powerpc/platforms/ps3/htab.c
index c27e6cf85272..9de62bd52650 100644
--- a/arch/powerpc/platforms/ps3/htab.c
+++ b/arch/powerpc/platforms/ps3/htab.c
@@ -146,7 +146,7 @@ static long ps3_hpte_updatepp(unsigned long slot, unsigned
long newpp,
static void ps3_hpte_updateboltedpp(unsigned long newpp, unsigned long ea,
int psize, int ssize)
{
- panic("ps3_hpte_updateboltedpp() not implemented");
+ pr_info("ps3_hpte_updateboltedpp() not implemented");
}
static void ps3_hpte_invalidate(unsigned long slot, unsigned long vpn,
--
2.34.1
[PATCH v2 2/2] powerpc/ps3: Refresh ps3_defconfig
Refresh ps3_defconfig for v6.2. Signed-off-by: Geoff Levand --- arch/powerpc/configs/ps3_defconfig | 39 +- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/arch/powerpc/configs/ps3_defconfig b/arch/powerpc/configs/ps3_defconfig index 0a1b42c4f26a..52a8c5450ecb 100644 --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -1,8 +1,3 @@ -CONFIG_PPC64=y -CONFIG_CELL_CPU=y -CONFIG_ALTIVEC=y -CONFIG_SMP=y -CONFIG_NR_CPUS=2 CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_HIGH_RES_TIMERS=y @@ -10,11 +5,12 @@ CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_EMBEDDED=y # CONFIG_PERF_EVENTS is not set -# CONFIG_COMPAT_BRK is not set -CONFIG_SLAB=y CONFIG_PROFILING=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y +CONFIG_PPC64=y +CONFIG_CELL_CPU=y +CONFIG_ALTIVEC=y +CONFIG_SMP=y +CONFIG_NR_CPUS=2 # CONFIG_PPC_POWERNV is not set # CONFIG_PPC_PSERIES is not set # CONFIG_PPC_PMAC is not set @@ -27,17 +23,20 @@ CONFIG_PS3_FLASH=y CONFIG_PS3_VRAM=m CONFIG_PS3_LPM=m # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set -# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set -CONFIG_BINFMT_MISC=y CONFIG_KEXEC=y CONFIG_PPC_4K_PAGES=y -# CONFIG_SPARSEMEM_VMEMMAP is not set -# CONFIG_COMPACTION is not set CONFIG_SCHED_SMT=y CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_SECCOMP is not set -# CONFIG_PCI is not set +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_BINFMT_MISC=y +CONFIG_SLAB=y +# CONFIG_COMPAT_BRK is not set +# CONFIG_SPARSEMEM_VMEMMAP is not set +# CONFIG_COMPACTION is not set CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -87,7 +86,6 @@ CONFIG_USB_USBNET=m # CONFIG_USB_NET_NET1080 is not set # CONFIG_USB_NET_CDC_SUBSET is not set # CONFIG_USB_NET_ZAURUS is not set -CONFIG_INPUT_FF_MEMLESS=m CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_KEYBOARD is not set @@ -110,13 +108,10 @@ CONFIG_SND=m # CONFIG_SND_DRIVERS is not set CONFIG_SND_USB_AUDIO=m CONFIG_HIDRAW=y -CONFIG_HID_APPLE=m CONFIG_HID_BELKIN=m CONFIG_HID_CHERRY=m CONFIG_HID_EZKEY=m CONFIG_HID_TWINHAN=m -CONFIG_HID_LOGITECH=m -CONFIG_HID_LOGITECH_DJ=m CONFIG_HID_MICROSOFT=m CONFIG_HID_SUNPLUS=m CONFIG_HID_SMARTJOYPLUS=m @@ -151,8 +146,12 @@ CONFIG_CIFS=m CONFIG_NLS=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y +CONFIG_CRYPTO_PCBC=m +CONFIG_CRYPTO_MICHAEL_MIC=m +CONFIG_CRYPTO_LZO=m CONFIG_CRC_CCITT=m CONFIG_CRC_T10DIF=y +CONFIG_PRINTK_TIME=y CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_MEMORY_INIT=y @@ -163,7 +162,3 @@ CONFIG_DEBUG_LOCKDEP=y CONFIG_DEBUG_LIST=y CONFIG_RCU_CPU_STALL_TIMEOUT=60 # CONFIG_FTRACE is not set -CONFIG_CRYPTO_PCBC=m -CONFIG_CRYPTO_MICHAEL_MIC=m -CONFIG_CRYPTO_LZO=m -CONFIG_PRINTK_TIME=y -- 2.34.1
[PATCH v2 0/2] PS3 patches
Hi Michael, This v2 series is just the two PS3 specific patches of the v1 series. -Geoff The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98: Linux 6.2-rc2 (2023-01-01 13:53:16 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git for-merge-powerpc-2 for you to fetch changes up to 99e87549b17feca3494e9df6f4def04a9ec7c042: powerpc/ps3: Refresh ps3_defconfig (2023-01-03 09:42:16 -0800) Geoff Levand (2): powerpc/ps3: Change updateboltedpp panic to info powerpc/ps3: Refresh ps3_defconfig arch/powerpc/configs/ps3_defconfig | 39 +- arch/powerpc/platforms/ps3/htab.c | 2 +- 2 files changed, 18 insertions(+), 23 deletions(-) -- 2.34.1
Re: [PATCH v1 1/3] powerpc: Fix processing of CONFIG_CMDLINE
On Tue, Jan 3, 2023 at 10:45 AM Geoff Levand wrote:
>
> Hi Rob,
>
> On 1/2/23 18:03, Rob Herring wrote:
> > On Mon, Jan 2, 2023 at 1:41 PM Geoff Levand wrote:
>
> >> --- a/arch/powerpc/kernel/prom.c
> >> +++ b/arch/powerpc/kernel/prom.c
> >> @@ -761,7 +761,7 @@ void __init early_init_devtree(void *params)
> >> DBG(" -> early_init_devtree(%px)\n", params);
> >>
> >> /* Too early to BUG_ON(), do it by hand */
> >> - if (!early_init_dt_verify(params))
> >> + if (!early_init_dt_scan(params))
> >
> > It would be nice if this could be used instead, but it does other
> > things like memory setup which I think will not work for some PPC
> > platforms.
>
> It seems like what we need is to pull out the command line processing
> code from early_init_dt_scan_nodes and put that into a new function,
> say early_init_setup_cmdline, then have both early_init_dt_scan_nodes
> and powerpc's early_init_devtree call early_init_setup_cmdline.
>
> I'll split this series into two, one for the PS3 updates, and one
> that adds early_init_setup_cmdline.
What is really needed is to make progress on the generic command line
handling, but the 2 different implementations can't seem to work
together to resolve the differences.
Short of that, I don't really want to see another function exposed to
the arch as I've been trying to reduce them. I'll post an alternative
shortly.
Rob
Re: [PATCH v1 1/3] powerpc: Fix processing of CONFIG_CMDLINE
Hi Rob,
On 1/2/23 18:03, Rob Herring wrote:
> On Mon, Jan 2, 2023 at 1:41 PM Geoff Levand wrote:
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -761,7 +761,7 @@ void __init early_init_devtree(void *params)
>> DBG(" -> early_init_devtree(%px)\n", params);
>>
>> /* Too early to BUG_ON(), do it by hand */
>> - if (!early_init_dt_verify(params))
>> + if (!early_init_dt_scan(params))
>
> It would be nice if this could be used instead, but it does other
> things like memory setup which I think will not work for some PPC
> platforms.
It seems like what we need is to pull out the command line processing
code from early_init_dt_scan_nodes and put that into a new function,
say early_init_setup_cmdline, then have both early_init_dt_scan_nodes
and powerpc's early_init_devtree call early_init_setup_cmdline.
I'll split this series into two, one for the PS3 updates, and one
that adds early_init_setup_cmdline.
-Geoff
Re: [bpf-next v1] bpf: drop deprecated bpf_jit_enable == 2
On 1/3/23 2:24 PM, x...@infragraf.org wrote:
From: Tonghao Zhang
The x86_64 can't dump the valid insn in this way. A test BPF prog
which include subprog:
$ llvm-objdump -d subprog.o
Disassembly of section .text:
:
0: 18 01 00 00 73 75 62 70 00 00 00 00 72 6f 67 00 r1 =
29114459903653235 ll
2: 7b 1a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r1
3: bf a1 00 00 00 00 00 00 r1 = r10
4: 07 01 00 00 f8 ff ff ff r1 += -8
5: b7 02 00 00 08 00 00 00 r2 = 8
6: 85 00 00 00 06 00 00 00 call 6
7: 95 00 00 00 00 00 00 00 exit
Disassembly of section raw_tp/sys_enter:
:
0: 85 10 00 00 ff ff ff ff call -1
1: b7 00 00 00 00 00 00 00 r0 = 0
2: 95 00 00 00 00 00 00 00 exit
kernel print message:
[ 580.775387] flen=8 proglen=51 pass=3 image=a000c20c from=kprobe-load
pid=1643
[ 580.777236] JIT code: : cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc
[ 580.779037] JIT code: 0010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc
[ 580.780767] JIT code: 0020: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc
[ 580.782568] JIT code: 0030: cc cc cc
$ bpf_jit_disasm
51 bytes emitted from JIT compiler (pass:3, flen:8)
a000c20c + :
0: int3
1: int3
2: int3
3: int3
4: int3
5: int3
...
Until bpf_jit_binary_pack_finalize is invoked, we copy rw_header to header
and then image/insn is valid. BTW, we can use the "bpftool prog dump" JITed
instructions.
* clean up the doc
* remove bpf_jit_disasm tool
* set bpf_jit_enable only 0 or 1.
Signed-off-by: Tonghao Zhang
Suggested-by: Alexei Starovoitov
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Andrii Nakryiko
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: John Fastabend
Cc: KP Singh
Cc: Stanislav Fomichev
Cc: Hao Luo
Cc: Jiri Olsa
Cc: Hou Tao
---
Documentation/admin-guide/sysctl/net.rst | 2 +-
Documentation/networking/filter.rst | 98 +--
arch/arm/net/bpf_jit_32.c| 4 -
arch/arm64/net/bpf_jit_comp.c| 4 -
arch/loongarch/net/bpf_jit.c | 4 -
arch/mips/net/bpf_jit_comp.c | 3 -
arch/powerpc/net/bpf_jit_comp.c | 11 -
arch/riscv/net/bpf_jit_core.c| 3 -
arch/s390/net/bpf_jit_comp.c | 4 -
arch/sparc/net/bpf_jit_comp_32.c | 3 -
arch/sparc/net/bpf_jit_comp_64.c | 13 -
arch/x86/net/bpf_jit_comp.c | 3 -
arch/x86/net/bpf_jit_comp32.c| 3 -
net/core/sysctl_net_core.c | 14 +-
tools/bpf/.gitignore | 1 -
tools/bpf/Makefile | 10 +-
tools/bpf/bpf_jit_disasm.c | 332 ---
17 files changed, 8 insertions(+), 504 deletions(-)
delete mode 100644 tools/bpf/bpf_jit_disasm.c
diff --git a/Documentation/admin-guide/sysctl/net.rst
b/Documentation/admin-guide/sysctl/net.rst
index 6394f5dc2303..45d3d965276c 100644
--- a/Documentation/admin-guide/sysctl/net.rst
+++ b/Documentation/admin-guide/sysctl/net.rst
@@ -87,7 +87,7 @@ Values:
- 0 - disable the JIT (default value)
- 1 - enable the JIT
- - 2 - enable the JIT and ask the compiler to emit traces on kernel log.
+ - 2 - deprecated in linux 6.2
I'd make it more clear in the docs and reword it as follows (also, it'll be in
6.3, not 6.2):
- 2 - enable the JIT and ask the compiler to emit traces on kernel log.
(deprecated since v6.3, use ``bpftool prog dump jited id ``
instead)
bpf_jit_harden
--
[...]
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 5b1ce656baa1..731a2eb0f68e 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -275,16 +275,8 @@ static int proc_dointvec_minmax_bpf_enable(struct
ctl_table *table, int write,
tmp.data = _enable;
ret = proc_dointvec_minmax(, write, buffer, lenp, ppos);
- if (write && !ret) {
- if (jit_enable < 2 ||
- (jit_enable == 2 && bpf_dump_raw_ok(current_cred( {
- *(int *)table->data = jit_enable;
- if (jit_enable == 2)
- pr_warn("bpf_jit_enable = 2 was set! NEVER use this
in production, only for JIT debugging!\n");
- } else {
- ret = -EPERM;
- }
- }
+ if (write && !ret)
+ *(int *)table->data = jit_enable;
if (write && ret && min == max)
pr_info_once("CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is
permanently set to 1.\n");
@@ -395,7 +387,7 @@ static struct ctl_table net_core_table[] = {
.extra2 = SYSCTL_ONE,
# else
.extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_TWO,
+
Re: [PATCH] powerpc: Fix a wrong version calculation issue in ld_version
On Jan 03 2023, Ojaswin Mujoo wrote: > If version is of the form x.y.z and length(z) == 8, then most probably > it is a date [mmdd]. As an approximation, discard the dd and > parts and keep the mm part in the version. I don't think any part of the date should be mixed into the computed version. It just means that it's a snapshot from after the 2.37 release, so it should be treated like 2.37 (no further releases has been made from this branch). -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[PATCH] powerpc: Fix a wrong version calculation issue in ld_version
** The Issue **
The ld_version() function seems to compute the wrong version value for
certain ld versions like the following:
$ ld --version GNU ld (GNU Binutils; SUSE Linux Enterprise 15)
2.37.20211103-150100.7.37
For input 2.37.20211103, the value computed is 20234803 which is way
more the value for a higher version like 2.39.0, that is 2390.
This issue was highlighted because with the above ld version, my powerpc
kernel build started failing with ld error: "unrecognized option
--no-warn-rwx-segments". This was caused due to the recent patch
579aee9fc594 added --no-warn-rwx-segments linker flag if the ld version
was greater than 2.39.
Due to the bug in ld_version(), my ld version (2.37.2003) was
wrongly calculated to be greater than 2.39 and the unsupported flag was
added.
** The fix **
If version is of the form x.y.z and length(z) == 8, then most probably
it is a date [mmdd]. As an approximation, discard the dd and
parts and keep the mm part in the version.
Signed-off-by: Ojaswin Mujoo
---
This is just an approximation since I'm not sure how common such release
versions for ld are and I didn't wan't to uneccassarily complicate the
logic. In case we want more accuracy we can try to use the last 4/5
digits to represent a more accurate date. Let me know if that would be
the preferred way.
PS: This issue also exists in ./scripts/ld-version.sh and I can look
into fixing that after this patch.
arch/powerpc/boot/wrapper | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index af04cea82b94..af2688f79224 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -210,6 +210,10 @@ ld_version()
gsub(".*version ", "");
gsub("-.*", "");
split($1,a, ".");
+ if( length(a[3]) == "8" )
+ # a[3] is probably a date of format mmdd. An 8 digit number
will break
+ # the function so just keep the "mm" part as an approximation
+ a[3] = substr(a[3],5,2);
print a[1]*1 + a[2]*100 + a[3]*1;
exit
}'
--
2.31.1
Re: [PATCH v3] arch: rename all internal names __xchg to __arch_xchg
On Fri, Dec 30, 2022 at 03:15:52PM +0100, Andrzej Hajda wrote: > __xchg will be used for non-atomic xchg macro. > > Signed-off-by: Andrzej Hajda > Reviewed-by: Arnd Bergmann > --- > v2: squashed all arch patches into one > v3: fixed alpha/xchg_local, thx to l...@intel.com > --- ... > arch/s390/include/asm/cmpxchg.h | 4 ++-- > diff --git a/arch/s390/include/asm/cmpxchg.h b/arch/s390/include/asm/cmpxchg.h > index 84c3f0d576c5b1..efc16f4aac8643 100644 > --- a/arch/s390/include/asm/cmpxchg.h > +++ b/arch/s390/include/asm/cmpxchg.h > @@ -14,7 +14,7 @@ > > void __xchg_called_with_bad_pointer(void); > > -static __always_inline unsigned long __xchg(unsigned long x, > +static __always_inline unsigned long __arch_xchg(unsigned long x, > unsigned long address, int size) Please adjust the alignment of the second line. > @@ -77,7 +77,7 @@ static __always_inline unsigned long __xchg(unsigned long x, > __typeof__(*(ptr)) __ret; \ > \ > __ret = (__typeof__(*(ptr)))\ > - __xchg((unsigned long)(x), (unsigned long)(ptr),\ > + __arch_xchg((unsigned long)(x), (unsigned long)(ptr), \ > sizeof(*(ptr))); \ Same here. The same is true for a couple of other architectures - not sure if they care however.
[PATCH 5.10 23/63] powerpc: add support for TIF_NOTIFY_SIGNAL
From: Jens Axboe [ Upstream commit 900f0713fdd730fab0f0bfa4a8ca4db2a8985bbe ] Wire up TIF_NOTIFY_SIGNAL handling for powerpc. Cc: linuxppc-dev@lists.ozlabs.org Acked-by: Michael Ellerman Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/include/asm/thread_info.h |5 - arch/powerpc/kernel/signal.c |2 +- 2 files changed, 5 insertions(+), 2 deletions(-) --- a/arch/powerpc/include/asm/thread_info.h +++ b/arch/powerpc/include/asm/thread_info.h @@ -96,6 +96,7 @@ void arch_setup_new_exec(void); #define TIF_SYSCALL_TRACE 0 /* syscall trace active */ #define TIF_SIGPENDING 1 /* signal pending */ #define TIF_NEED_RESCHED 2 /* rescheduling necessary */ +#define TIF_NOTIFY_SIGNAL 3 /* signal notifications exist */ #define TIF_SYSCALL_EMU4 /* syscall emulation active */ #define TIF_RESTORE_TM 5 /* need to restore TM FP/VEC/VSX */ #define TIF_PATCH_PENDING 6 /* pending live patching update */ @@ -121,6 +122,7 @@ void arch_setup_new_exec(void); #define _TIF_SYSCALL_TRACE (1
