Re: [PATCH] serial/pmac_zilog: Remove flawed mitigation for rx irq flood

2024-04-07 Thread Greg Kroah-Hartman
On Mon, Apr 08, 2024 at 07:37:22AM +0200, Jiri Slaby wrote:
> On 08. 04. 24, 7:32, Jiri Slaby wrote:
> > On 08. 04. 24, 7:29, Michael Ellerman wrote:
> > > Many maintainers won't drop Cc: tags if they are there in the submitted
> > > patch. So I agree with Andy that we should encourage folks not to add
> > > them in the first place.
> > 
> > But fix the docs first.
> > 
> > I am personally not biased to any variant (as in: I don't care where CCs
> > live in a patch).
> 
> OTOH, as a submitter, it's a major PITA to carry CCs in notes (to have those
> under the --- line). Esp. when I have patches in a queue for years.

Agreed, let's keep them where they are in the signed-off-by area, it's
not hurting or harming anything to have them there.

thanks,

greg k-h


Re: [PATCH] serial/pmac_zilog: Remove flawed mitigation for rx irq flood

2024-04-07 Thread Jiri Slaby

On 08. 04. 24, 7:32, Jiri Slaby wrote:

On 08. 04. 24, 7:29, Michael Ellerman wrote:

Many maintainers won't drop Cc: tags if they are there in the submitted
patch. So I agree with Andy that we should encourage folks not to add
them in the first place.


But fix the docs first.

I am personally not biased to any variant (as in: I don't care where CCs 
live in a patch).


OTOH, as a submitter, it's a major PITA to carry CCs in notes (to have 
those under the --- line). Esp. when I have patches in a queue for years.


How do people handle that? (Like rebases on current kernel.)


regards,

--
js
suse labs



Re: [PATCH] serial/pmac_zilog: Remove flawed mitigation for rx irq flood

2024-04-07 Thread Jiri Slaby

On 08. 04. 24, 7:29, Michael Ellerman wrote:

Many maintainers won't drop Cc: tags if they are there in the submitted
patch. So I agree with Andy that we should encourage folks not to add
them in the first place.


But fix the docs first.

I am personally not biased to any variant (as in: I don't care where CCs 
live in a patch).


regards,
--
js
suse labs



[PATCH -next 2/3 v2] powerpc: Fix kernel-doc comments in fsl_gtm.c

2024-04-07 Thread Yang Li
Fix some function names in kernel-doc comments.

Signed-off-by: Yang Li 
---
 arch/powerpc/sysdev/fsl_gtm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
index 39186ad6b3c3..3dabc9621810 100644
--- a/arch/powerpc/sysdev/fsl_gtm.c
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -77,7 +77,7 @@ struct gtm {
 static LIST_HEAD(gtms);
 
 /**
- * gtm_get_timer - request GTM timer to use it with the rest of GTM API
+ * gtm_get_timer16 - request GTM timer to use it with the rest of GTM API
  * Context:non-IRQ
  *
  * This function reserves GTM timer for later use. It returns gtm_timer
@@ -110,7 +110,7 @@ struct gtm_timer *gtm_get_timer16(void)
 EXPORT_SYMBOL(gtm_get_timer16);
 
 /**
- * gtm_get_specific_timer - request specific GTM timer
+ * gtm_get_specific_timer16 - request specific GTM timer
  * @gtm:   specific GTM, pass here GTM's device_node->data
  * @timer: specific timer number, Timer1 is 0.
  * Context:non-IRQ
@@ -260,7 +260,7 @@ int gtm_set_timer16(struct gtm_timer *tmr, unsigned long 
usec, bool reload)
 EXPORT_SYMBOL(gtm_set_timer16);
 
 /**
- * gtm_set_exact_utimer16 - (re)set 16 bits timer
+ * gtm_set_exact_timer16 - (re)set 16 bits timer
  * @tmr:   pointer to the gtm_timer structure obtained from gtm_get_timer
  * @usec:  timer interval in microseconds
  * @reload:if set, the timer will reset upon expiry rather than
-- 
2.20.1.7.g153144c



[PATCH -next 3/3 v2] powerpc/rtas: Add kernel-doc comments to smp_startup_cpu()

2024-04-07 Thread Yang Li
This commit adds kernel-doc style comments with complete parameter
descriptions for the function smp_startup_cpu().

Signed-off-by: Yang Li 
---
 arch/powerpc/platforms/cell/smp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/cell/smp.c 
b/arch/powerpc/platforms/cell/smp.c
index 30394c6f8894..fee638fd8970 100644
--- a/arch/powerpc/platforms/cell/smp.c
+++ b/arch/powerpc/platforms/cell/smp.c
@@ -54,6 +54,7 @@ static cpumask_t of_spin_map;
 
 /**
  * smp_startup_cpu() - start the given cpu
+ * @lcpu: Logical CPU ID of the CPU to be started.
  *
  * At boot time, there is nothing to do for primary threads which were
  * started from Open Firmware.  For anything else, call RTAS with the
-- 
2.20.1.7.g153144c



Re: [PATCH v2] serial/pmac_zilog: Remove flawed mitigation for rx irq flood

2024-04-07 Thread Michael Ellerman
Finn Thain  writes:
> On Fri, 5 Apr 2024, Michael Ellerman wrote:
>
>> I assume you have tested this on an actual pmac, as well as qemu?
>> 
>
> I tested the patched driver and its console functionality using Zilog SCC 
> hardware in a Mac IIci, as well as QEMU's q800 virtual machine.
>
> That should suffice from a code coverage point-of-view, since 
> pmz_receive_chars() is portable and independent of CONFIG_PPC_PMAC.
>
> Moreover, I don't know how to get my PowerMac G3 to execute the kludge 
> that's to be removed here. I can't prove it's impossible, though.

Thanks. That's good enough for me.

Acked-by: Michael Ellerman  (powerpc)

cheers


Re: [PATCH] serial/pmac_zilog: Remove flawed mitigation for rx irq flood

2024-04-07 Thread Michael Ellerman
Finn Thain  writes:
> On Fri, 5 Apr 2024, Michael Ellerman wrote:
>> >> > > ---
>> >> > (here is a good location for Cc:)
>> >>
>> >> Documentation/process/submitting-patches.rst indicats that it should 
>> >> be above the "---" separator together with Acked-by etc. Has this 
>> >> convention changed recently?
>> 
>> The docs don't really say where to put the Cc: tags, although they are 
>> mentioned along with other tags which clearly are intended to go above 
>> the separator.
>
> I see no ambiguity there. What's the point of copying the message headers 
> into the message body unless it was intended that they form part of the 
> commit log?

In many cases I think it's the reverse. The Cc headers are in the commit
log *so that* git-send-email will add them to the Cc list when the patch
is sent.

In that case they can sit below the separator and still function.

IMO there is no value in having them in the commit log. The fact that
someone was Cc'ed on a patch 10 years ago is not interesting. If it ever
was interesting, for some forensic purpose, the mail archives would be
the place to look anyway.

>> > I see, I will prepare a patch to discuss this aspect.
>> 
>> FYI there was a discussion about this several years ago, where at least 
>> some maintainers agreed that Cc: tags don't add much value and are 
>> better placed below the --- separator.
>> 
>
> Maintainers who merge patches almost always add tags. And they can use the 
> Cc tags from the message headers if they wish to. Or they can omit them or 
> remove them. I don't mind. And I'd be happy to resubmit the patch with 
> different tags if that's what is needed by the workflow used by Jiri Slaby 
> or Greg Kroah-Hartman.

Many maintainers won't drop Cc: tags if they are there in the submitted
patch. So I agree with Andy that we should encourage folks not to add
them in the first place.

But that's getting very off topic for your submission :)

cheers


[PATCH v2] Add static_key_feature_checks_initialized flag

2024-04-07 Thread Nicholas Miehlbradt
JUMP_LABEL_FEATURE_CHECK_DEBUG used static_key_intialized to determine
whether {cpu,mmu}_has_feature() is used before static keys were
initialized. However, {cpu,mmu}_has_feature() should not be used before
setup_feature_keys() is called but static_key_initialized is set well
before this by the call to jump_label_init() in early_init_devtree().
This creates a window in which JUMP_LABEL_FEATURE_CHECK_DEBUG will not
detect misuse and report errors. Add a flag specifically to indicate
when {cpu,mmu}_has_feature() is safe to use.

Signed-off-by: Nicholas Miehlbradt 
---
v2: Reword commit message

v1: 
https://lore.kernel.org/linuxppc-dev/20240327045911.64543-1-nicho...@linux.ibm.com/
---
 arch/powerpc/include/asm/cpu_has_feature.h | 2 +-
 arch/powerpc/include/asm/feature-fixups.h  | 2 ++
 arch/powerpc/include/asm/mmu.h | 2 +-
 arch/powerpc/lib/feature-fixups.c  | 8 
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/cpu_has_feature.h 
b/arch/powerpc/include/asm/cpu_has_feature.h
index 727d4b321937..0efabccd820c 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -29,7 +29,7 @@ static __always_inline bool cpu_has_feature(unsigned long 
feature)
 #endif
 
 #ifdef CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
-   if (!static_key_initialized) {
+   if (!static_key_feature_checks_initialized) {
printk("Warning! cpu_has_feature() used prior to jump label 
init!\n");
dump_stack();
return early_cpu_has_feature(feature);
diff --git a/arch/powerpc/include/asm/feature-fixups.h 
b/arch/powerpc/include/asm/feature-fixups.h
index 77824bd289a3..17d168dd8b49 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -291,6 +291,8 @@ extern long __start___rfi_flush_fixup, 
__stop___rfi_flush_fixup;
 extern long __start___barrier_nospec_fixup, __stop___barrier_nospec_fixup;
 extern long __start__btb_flush_fixup, __stop__btb_flush_fixup;
 
+extern bool static_key_feature_checks_initialized;
+
 void apply_feature_fixups(void);
 void update_mmu_feature_fixups(unsigned long mask);
 void setup_feature_keys(void);
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 3b72c7ed24cf..24f830cf9bb4 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -251,7 +251,7 @@ static __always_inline bool mmu_has_feature(unsigned long 
feature)
 #endif
 
 #ifdef CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
-   if (!static_key_initialized) {
+   if (!static_key_feature_checks_initialized) {
printk("Warning! mmu_has_feature() used prior to jump label 
init!\n");
dump_stack();
return early_mmu_has_feature(feature);
diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index 4f82581ca203..b7201ba50b2e 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -25,6 +25,13 @@
 #include 
 #include 
 
+/*
+ * Used to generate warnings if mmu or cpu feature check functions that
+ * use static keys before they are initialized.
+ */
+bool static_key_feature_checks_initialized __read_mostly;
+EXPORT_SYMBOL_GPL(static_key_feature_checks_initialized);
+
 struct fixup_entry {
unsigned long   mask;
unsigned long   value;
@@ -679,6 +686,7 @@ void __init setup_feature_keys(void)
jump_label_init();
cpu_feature_keys_init();
mmu_feature_keys_init();
+   static_key_feature_checks_initialized = true;
 }
 
 static int __init check_features(void)
-- 
2.40.1



Re: [PATCH] KVM: PPC: Book3S HV nestedv2: Cancel pending HDEC exception

2024-04-07 Thread Michael Ellerman
Thorsten Leemhuis  writes:
> On 05.04.24 05:20, Michael Ellerman wrote:
>> "Linux regression tracking (Thorsten Leemhuis)"
>>  writes:
>>> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
>>> for once, to make this easily accessible to everyone.
>>>
>>> Was this regression ever resolved? Doesn't look like it, but maybe I
>>> just missed something.
>> 
>> I'm not sure how it ended up on the regression list.
>
> That is easy to explain: I let lei search for mails containing words
> like regress, bisect, and revert to become aware of regressions that
> might need tracking. And...
>
>> IMHO it's not really a regression.
>
> ...sometimes I misjudge or misinterpret something and add it to the
> regression tracking. Looks like that happened here.
>
> Sorry for that and the noise it caused!

No worries.

cheers


Re: [PATCH] MAINTAINERS: Drop Li Yang as their email address stopped working

2024-04-07 Thread Michael Ellerman
Uwe Kleine-König  writes:
> When sending a patch to (among others) Li Yang the nxp MTA replied that
> the address doesn't exist and so the mail couldn't be delivered. The
> error code was 550, so at least technically that's not a temporal issue.
>
> Signed-off-by: Uwe Kleine-König 
> ---
> Hello,
>
> I added the affected maintainers and lists to Cc:, maybe someone there
> knows if this issue is only temporal?

Apparently not. See 
https://lore.kernel.org/all/20240219153016.ntltc76bphwrv6hn@skbuf/

  Leo Li (Li Yang) is no longer with NXP.


cheers

> @Greg: Given that I noticed the non-existing address when sending an usb
> patch, I suggest you care for application of this patch (iff it should
> be applied now). If Li Yang disappeared indeed, I'd prefer to drop the
> contact from MAINTAINERS early to not give wrong expectations to
> contributors.
>
> Best regards
> Uwe
>
>  MAINTAINERS | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7c121493f43d..be19aad15045 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2191,7 +2191,6 @@ N:  mxs
>  
>  ARM/FREESCALE LAYERSCAPE ARM ARCHITECTURE
>  M:   Shawn Guo 
> -M:   Li Yang 
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  S:   Maintained
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
> @@ -8523,7 +8522,6 @@ S:  Maintained
>  F:   drivers/video/fbdev/fsl-diu-fb.*
>  
>  FREESCALE DMA DRIVER
> -M:   Li Yang 
>  M:   Zhang Wei 
>  L:   linuxppc-dev@lists.ozlabs.org
>  S:   Maintained
> @@ -8688,10 +8686,9 @@ F: drivers/soc/fsl/qe/tsa.h
>  F:   include/dt-bindings/soc/cpm1-fsl,tsa.h
>  
>  FREESCALE QUICC ENGINE UCC ETHERNET DRIVER
> -M:   Li Yang 
>  L:   net...@vger.kernel.org
>  L:   linuxppc-dev@lists.ozlabs.org
> -S:   Maintained
> +S:   Orphan
>  F:   drivers/net/ethernet/freescale/ucc_geth*
>  
>  FREESCALE QUICC ENGINE UCC HDLC DRIVER
> @@ -8708,10 +8705,9 @@ S: Maintained
>  F:   drivers/tty/serial/ucc_uart.c
>  
>  FREESCALE SOC DRIVERS
> -M:   Li Yang 
>  L:   linuxppc-dev@lists.ozlabs.org
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
> -S:   Maintained
> +S:   Orphan
>  F:   Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml
>  F:   Documentation/devicetree/bindings/soc/fsl/
>  F:   drivers/soc/fsl/
> @@ -8745,10 +8741,9 @@ F: 
> Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
>  F:   sound/soc/fsl/fsl_qmc_audio.c
>  
>  FREESCALE USB PERIPHERAL DRIVERS
> -M:   Li Yang 
>  L:   linux-...@vger.kernel.org
>  L:   linuxppc-dev@lists.ozlabs.org
> -S:   Maintained
> +S:   Orphan
>  F:   drivers/usb/gadget/udc/fsl*
>  
>  FREESCALE USB PHY DRIVER
>
> base-commit: c85af715cac0a951eea97393378e84bb49384734
> -- 
> 2.43.0


Re: [PATCH -next 1/3] powerpc: boot: Fix a typo in partial_decompress() comment

2024-04-07 Thread Michael Ellerman
Yang Li  writes:
> This commit adds kernel-doc style comments with complete parameter
> descriptions for the function partial_decompress().

This change log doesn't match the subject or the patch.

cheers

> Signed-off-by: Yang Li 
> ---
>  arch/powerpc/boot/decompress.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/decompress.c b/arch/powerpc/boot/decompress.c
> index 977eb15a6d17..6835cb53f034 100644
> --- a/arch/powerpc/boot/decompress.c
> +++ b/arch/powerpc/boot/decompress.c
> @@ -101,7 +101,7 @@ static void print_err(char *s)
>   * @input_size:  length of the input buffer
>   * @outbuf:  output buffer
>   * @output_size: length of the output buffer
> - * @skip number of output bytes to ignore
> + * @_skip:   number of output bytes to ignore
>   *
>   * This function takes compressed data from inbuf, decompresses and write it 
> to
>   * outbuf. Once output_size bytes are written to the output buffer, or the
> -- 
> 2.20.1.7.g153144c


Re: [PATCH 3/9] IB: Convert from tasklet to BH workqueue

2024-04-07 Thread Zhu Yanjun

在 2024/3/27 17:03, Allen Pais 写道:

The only generic interface to execute asynchronously in the BH context is
tasklet; however, it's marked deprecated and has some design flaws. To
replace tasklets, BH workqueue support was recently added. A BH workqueue
behaves similarly to regular workqueues except that the queued work items
are executed in the BH context.

This patch converts drivers/infiniband/* from tasklet to BH workqueue.

Based on the work done by Tejun Heo 
Branch: https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-6.10


I made simple tests. And I can not find the difference on latency and 
throughput on RoCEv2 devices.


Anyone also made tests with these patches on IB? Any difference on 
Latency and throughput?


Thanks,
Zhu Yanjun



Signed-off-by: Allen Pais 
---
  drivers/infiniband/hw/bnxt_re/bnxt_re.h|  3 +-
  drivers/infiniband/hw/bnxt_re/qplib_fp.c   | 21 ++--
  drivers/infiniband/hw/bnxt_re/qplib_fp.h   |  2 +-
  drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 25 ---
  drivers/infiniband/hw/bnxt_re/qplib_rcfw.h |  2 +-
  drivers/infiniband/hw/erdma/erdma.h|  3 +-
  drivers/infiniband/hw/erdma/erdma_eq.c | 11 ---
  drivers/infiniband/hw/hfi1/rc.c|  2 +-
  drivers/infiniband/hw/hfi1/sdma.c  | 37 +++---
  drivers/infiniband/hw/hfi1/sdma.h  |  9 +++---
  drivers/infiniband/hw/hfi1/tid_rdma.c  |  6 ++--
  drivers/infiniband/hw/irdma/ctrl.c |  2 +-
  drivers/infiniband/hw/irdma/hw.c   | 24 +++---
  drivers/infiniband/hw/irdma/main.h |  5 +--
  drivers/infiniband/hw/qib/qib.h|  7 ++--
  drivers/infiniband/hw/qib/qib_iba7322.c|  9 +++---
  drivers/infiniband/hw/qib/qib_rc.c | 16 +-
  drivers/infiniband/hw/qib/qib_ruc.c|  4 +--
  drivers/infiniband/hw/qib/qib_sdma.c   | 11 ---
  drivers/infiniband/sw/rdmavt/qp.c  |  2 +-
  20 files changed, 106 insertions(+), 95 deletions(-)

diff --git a/drivers/infiniband/hw/bnxt_re/bnxt_re.h 
b/drivers/infiniband/hw/bnxt_re/bnxt_re.h
index 9dca451ed522..f511c8415806 100644
--- a/drivers/infiniband/hw/bnxt_re/bnxt_re.h
+++ b/drivers/infiniband/hw/bnxt_re/bnxt_re.h
@@ -42,6 +42,7 @@
  #include 
  #include "hw_counters.h"
  #include 
+#include 
  #define ROCE_DRV_MODULE_NAME  "bnxt_re"
  
  #define BNXT_RE_DESC	"Broadcom NetXtreme-C/E RoCE Driver"

@@ -162,7 +163,7 @@ struct bnxt_re_dev {
u8  cur_prio_map;
  
  	/* FP Notification Queue (CQ & SRQ) */

-   struct tasklet_struct   nq_task;
+   struct work_struct  nq_work;
  
  	/* RCFW Channel */

struct bnxt_qplib_rcfw  rcfw;
diff --git a/drivers/infiniband/hw/bnxt_re/qplib_fp.c 
b/drivers/infiniband/hw/bnxt_re/qplib_fp.c
index 439d0c7c5d0c..052906982cdf 100644
--- a/drivers/infiniband/hw/bnxt_re/qplib_fp.c
+++ b/drivers/infiniband/hw/bnxt_re/qplib_fp.c
@@ -46,6 +46,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include "roce_hsi.h"

@@ -294,9 +295,9 @@ static void __wait_for_all_nqes(struct bnxt_qplib_cq *cq, 
u16 cnq_events)
}
  }
  
-static void bnxt_qplib_service_nq(struct tasklet_struct *t)

+static void bnxt_qplib_service_nq(struct work_struct *t)
  {
-   struct bnxt_qplib_nq *nq = from_tasklet(nq, t, nq_tasklet);
+   struct bnxt_qplib_nq *nq = from_work(nq, t, nq_work);
struct bnxt_qplib_hwq *hwq = >hwq;
struct bnxt_qplib_cq *cq;
int budget = nq->budget;
@@ -394,7 +395,7 @@ void bnxt_re_synchronize_nq(struct bnxt_qplib_nq *nq)
int budget = nq->budget;
  
  	nq->budget = nq->hwq.max_elements;

-   bnxt_qplib_service_nq(>nq_tasklet);
+   bnxt_qplib_service_nq(>nq_work);
nq->budget = budget;
  }
  
@@ -409,7 +410,7 @@ static irqreturn_t bnxt_qplib_nq_irq(int irq, void *dev_instance)

prefetch(bnxt_qplib_get_qe(hwq, sw_cons, NULL));
  
  	/* Fan out to CPU affinitized kthreads? */

-   tasklet_schedule(>nq_tasklet);
+   queue_work(system_bh_wq, >nq_work);
  
  	return IRQ_HANDLED;

  }
@@ -430,8 +431,8 @@ void bnxt_qplib_nq_stop_irq(struct bnxt_qplib_nq *nq, bool 
kill)
nq->name = NULL;
  
  	if (kill)

-   tasklet_kill(>nq_tasklet);
-   tasklet_disable(>nq_tasklet);
+   cancel_work_sync(>nq_work);
+   disable_work_sync(>nq_work);
  }
  
  void bnxt_qplib_disable_nq(struct bnxt_qplib_nq *nq)

@@ -465,9 +466,9 @@ int bnxt_qplib_nq_start_irq(struct bnxt_qplib_nq *nq, int 
nq_indx,
  
  	nq->msix_vec = msix_vector;

if (need_init)
-   tasklet_setup(>nq_tasklet, bnxt_qplib_service_nq);
+   INIT_WORK(>nq_work, bnxt_qplib_service_nq);
else
-   tasklet_enable(>nq_tasklet);
+   enable_and_queue_work(system_bh_wq, >nq_work);
  
  	nq->name = kasprintf(GFP_KERNEL, "bnxt_re-nq-%d@pci:%s",

 nq_indx, pci_name(res->pdev));
@@ 

Re: [PATCH v2 6/7] s390: mm: accelerate pagefault when badaccess

2024-04-07 Thread Heiko Carstens
On Wed, Apr 03, 2024 at 04:38:04PM +0800, Kefeng Wang wrote:
> The vm_flags of vma already checked under per-VMA lock, if it is a
> bad access, directly handle error, no need to retry with mmap_lock
> again. Since the page faut is handled under per-VMA lock, count it
> as a vma lock event with VMA_LOCK_SUCCESS.
> 
> Signed-off-by: Kefeng Wang 
> ---
>  arch/s390/mm/fault.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
> index c421dd44ffbe..162ca2576fd4 100644
> --- a/arch/s390/mm/fault.c
> +++ b/arch/s390/mm/fault.c
> @@ -325,7 +325,8 @@ static void do_exception(struct pt_regs *regs, int access)
>   goto lock_mmap;
>   if (!(vma->vm_flags & access)) {
>   vma_end_read(vma);
> - goto lock_mmap;
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> + return handle_fault_error_nolock(regs, SEGV_ACCERR);

Reviewed-by: Heiko Carstens 


Re: [PATCH v2 0/7] arch/mm/fault: accelerate pagefault when badaccess

2024-04-07 Thread Heiko Carstens
On Sun, Apr 07, 2024 at 03:49:53PM +0800, Kefeng Wang wrote:
> On 2024/4/4 4:45, Andrew Morton wrote:
> > On Wed, 3 Apr 2024 16:37:58 +0800 Kefeng Wang  
> > wrote:
> > 
> > > After VMA lock-based page fault handling enabled, if bad access met
> > > under per-vma lock, it will fallback to mmap_lock-based handling,
> > > so it leads to unnessary mmap lock and vma find again. A test from
> > > lmbench shows 34% improve after this changes on arm64,
> > > 
> > >lat_sig -P 1 prot lat_sig 0.29194 -> 0.19198
> > > 
> > > Only build test on other archs except arm64.
> > 
> > Thanks.  So we now want a bunch of architectures to runtime test this.  Do
> > we have a selftest in place which will adequately do this?
> 
> I don't find such selftest, and badaccess would lead to coredump, the
> performance should not affect most scene, so no selftest is acceptable.
> lmbench is easy to use to measure the performance.

The rationale for this series (performance improvement) is a bit odd,
since I would expect that the changed code is usually never executed.


Re: [PATCH -next 3/3] powerpc/rtas: Add kernel-doc comments to smp_startup_cpu()

2024-04-07 Thread Randy Dunlap



On 4/6/24 11:39 PM, Yang Li wrote:
> This commit adds kernel-doc style comments with complete parameter
> descriptions for the function smp_startup_cpu().
> 
> Signed-off-by: Yang Li 
> ---
>  arch/powerpc/platforms/cell/smp.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/powerpc/platforms/cell/smp.c 
> b/arch/powerpc/platforms/cell/smp.c
> index 30394c6f8894..bdb7adde798d 100644
> --- a/arch/powerpc/platforms/cell/smp.c
> +++ b/arch/powerpc/platforms/cell/smp.c
> @@ -55,6 +55,8 @@ static cpumask_t of_spin_map;
>  /**
>   * smp_startup_cpu() - start the given cpu
>   *
> + * @lcpu: Logical CPU ID of the CPU to be started.

Does this work with the blank line between the function and parameter?
(i.e., no kernel-doc warnings?)

Usually it's done without the extra line.
Otherwise the additional line for @lcpu: looks good to me.

Thanks.

> + *
>   * At boot time, there is nothing to do for primary threads which were
>   * started from Open Firmware.  For anything else, call RTAS with the
>   * appropriate start location.

-- 
#Randy


Re: [PATCH -next 2/3] powerpc: Fix kernel-doc comments in fsl_gtm.c

2024-04-07 Thread Randy Dunlap



On 4/6/24 11:39 PM, Yang Li wrote:
> Fix some function names in kernel-doc comments.
> 
> Signed-off-by: Yang Li 
> ---
>  arch/powerpc/sysdev/fsl_gtm.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
> index 39186ad6b3c3..71e07883eb48 100644
> --- a/arch/powerpc/sysdev/fsl_gtm.c
> +++ b/arch/powerpc/sysdev/fsl_gtm.c
> @@ -77,7 +77,7 @@ struct gtm {
>  static LIST_HEAD(gtms);
>  
>  /**
> - * gtm_get_timer - request GTM timer to use it with the rest of GTM API
> + * gtm_get_timer16 - request GTM timer to use it with the rest of GTM API

ack

>   * Context:  non-IRQ
>   *
>   * This function reserves GTM timer for later use. It returns gtm_timer
> @@ -110,7 +110,7 @@ struct gtm_timer *gtm_get_timer16(void)
>  EXPORT_SYMBOL(gtm_get_timer16);
>  
>  /**
> - * gtm_get_specific_timer - request specific GTM timer
> + * gtm_get_specific_timer16 - request specific GTM timer

ack

>   * @gtm: specific GTM, pass here GTM's device_node->data
>   * @timer:   specific timer number, Timer1 is 0.
>   * Context:  non-IRQ
> @@ -276,7 +276,7 @@ EXPORT_SYMBOL(gtm_set_timer16);
>   * crop precision of the "usec" argument, thus usec is limited to 16 bits
>   * (single timer width).
>   */
> -int gtm_set_exact_timer16(struct gtm_timer *tmr, u16 usec, bool reload)
> +int gtm_set_exact_utimer16(struct gtm_timer *tmr, u16 usec, bool reload)

No, change the kernel-doc comment instead. Otherwise the caller will fail to 
link.

>  {
>   /* quite obvious, frequency which is enough for µSec precision */
>   const int freq = 100;

thanks.
-- 
#Randy


Re: [PATCH -next 1/3] powerpc: boot: Fix a typo in partial_decompress() comment

2024-04-07 Thread Randy Dunlap



On 4/6/24 11:39 PM, Yang Li wrote:
> This commit adds kernel-doc style comments with complete parameter
> descriptions for the function partial_decompress().
> 
> Signed-off-by: Yang Li 

Reviewed-by: Randy Dunlap 

Thanks.

> ---
>  arch/powerpc/boot/decompress.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/boot/decompress.c b/arch/powerpc/boot/decompress.c
> index 977eb15a6d17..6835cb53f034 100644
> --- a/arch/powerpc/boot/decompress.c
> +++ b/arch/powerpc/boot/decompress.c
> @@ -101,7 +101,7 @@ static void print_err(char *s)
>   * @input_size:  length of the input buffer
>   * @outbuf:  output buffer
>   * @output_size: length of the output buffer
> - * @skip number of output bytes to ignore
> + * @_skip:   number of output bytes to ignore
>   *
>   * This function takes compressed data from inbuf, decompresses and write it 
> to
>   * outbuf. Once output_size bytes are written to the output buffer, or the

-- 
#Randy


Re: [PATCH v2 0/7] arch/mm/fault: accelerate pagefault when badaccess

2024-04-07 Thread Kefeng Wang




On 2024/4/4 4:45, Andrew Morton wrote:

On Wed, 3 Apr 2024 16:37:58 +0800 Kefeng Wang  
wrote:


After VMA lock-based page fault handling enabled, if bad access met
under per-vma lock, it will fallback to mmap_lock-based handling,
so it leads to unnessary mmap lock and vma find again. A test from
lmbench shows 34% improve after this changes on arm64,

   lat_sig -P 1 prot lat_sig 0.29194 -> 0.19198

Only build test on other archs except arm64.


Thanks.  So we now want a bunch of architectures to runtime test this.  Do
we have a selftest in place which will adequately do this?


I don't find such selftest, and badaccess would lead to coredump, the
performance should not affect most scene, so no selftest is acceptable.
lmbench is easy to use to measure the performance.


[PATCH -next 1/3] powerpc: boot: Fix a typo in partial_decompress() comment

2024-04-07 Thread Yang Li
This commit adds kernel-doc style comments with complete parameter
descriptions for the function partial_decompress().

Signed-off-by: Yang Li 
---
 arch/powerpc/boot/decompress.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/decompress.c b/arch/powerpc/boot/decompress.c
index 977eb15a6d17..6835cb53f034 100644
--- a/arch/powerpc/boot/decompress.c
+++ b/arch/powerpc/boot/decompress.c
@@ -101,7 +101,7 @@ static void print_err(char *s)
  * @input_size:  length of the input buffer
  * @outbuf:  output buffer
  * @output_size: length of the output buffer
- * @skip number of output bytes to ignore
+ * @_skip:   number of output bytes to ignore
  *
  * This function takes compressed data from inbuf, decompresses and write it to
  * outbuf. Once output_size bytes are written to the output buffer, or the
-- 
2.20.1.7.g153144c



[PATCH -next 2/3] powerpc: Fix kernel-doc comments in fsl_gtm.c

2024-04-07 Thread Yang Li
Fix some function names in kernel-doc comments.

Signed-off-by: Yang Li 
---
 arch/powerpc/sysdev/fsl_gtm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
index 39186ad6b3c3..71e07883eb48 100644
--- a/arch/powerpc/sysdev/fsl_gtm.c
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -77,7 +77,7 @@ struct gtm {
 static LIST_HEAD(gtms);
 
 /**
- * gtm_get_timer - request GTM timer to use it with the rest of GTM API
+ * gtm_get_timer16 - request GTM timer to use it with the rest of GTM API
  * Context:non-IRQ
  *
  * This function reserves GTM timer for later use. It returns gtm_timer
@@ -110,7 +110,7 @@ struct gtm_timer *gtm_get_timer16(void)
 EXPORT_SYMBOL(gtm_get_timer16);
 
 /**
- * gtm_get_specific_timer - request specific GTM timer
+ * gtm_get_specific_timer16 - request specific GTM timer
  * @gtm:   specific GTM, pass here GTM's device_node->data
  * @timer: specific timer number, Timer1 is 0.
  * Context:non-IRQ
@@ -276,7 +276,7 @@ EXPORT_SYMBOL(gtm_set_timer16);
  * crop precision of the "usec" argument, thus usec is limited to 16 bits
  * (single timer width).
  */
-int gtm_set_exact_timer16(struct gtm_timer *tmr, u16 usec, bool reload)
+int gtm_set_exact_utimer16(struct gtm_timer *tmr, u16 usec, bool reload)
 {
/* quite obvious, frequency which is enough for ??Sec precision */
const int freq = 100;
-- 
2.20.1.7.g153144c



[PATCH -next 3/3] powerpc/rtas: Add kernel-doc comments to smp_startup_cpu()

2024-04-07 Thread Yang Li
This commit adds kernel-doc style comments with complete parameter
descriptions for the function smp_startup_cpu().

Signed-off-by: Yang Li 
---
 arch/powerpc/platforms/cell/smp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/cell/smp.c 
b/arch/powerpc/platforms/cell/smp.c
index 30394c6f8894..bdb7adde798d 100644
--- a/arch/powerpc/platforms/cell/smp.c
+++ b/arch/powerpc/platforms/cell/smp.c
@@ -55,6 +55,8 @@ static cpumask_t of_spin_map;
 /**
  * smp_startup_cpu() - start the given cpu
  *
+ * @lcpu: Logical CPU ID of the CPU to be started.
+ *
  * At boot time, there is nothing to do for primary threads which were
  * started from Open Firmware.  For anything else, call RTAS with the
  * appropriate start location.
-- 
2.20.1.7.g153144c