Re: [powerpc] kernel BUG fs/xfs/xfs_message.c:102! [4k block]

2023-10-12 Thread Dave Chinner
On Thu, Oct 12, 2023 at 03:51:04PM +0530, Sachin Sant wrote:
> While running xfstests on a IBM Power10 server having xfs file system with
> 4k block size following crash was seen
> 
> [ 1609.771548] run fstests xfs/238 at 2023-10-11 17:00:40
> [ 1609.971214] XFS (sdb1): Mounting V5 Filesystem 
> 1105d60c-9514-4e7a-af6a-632d99bf06ea
> [ 1609.980693] XFS (sdb1): Ending clean mount
> [ 1609.982166] xfs filesystem being mounted at /mnt/test supports timestamps 
> until 2038-01-19 (0x7fff)
> [ 1610.024793] XFS (sdb2): Mounting V5 Filesystem 
> 60de8f0c-c80e-4a2a-b60a-f41a9cc0feca
> [ 1610.030295] XFS (sdb2): Ending clean mount
> [ 1610.031342] xfs filesystem being mounted at /mnt/scratch supports 
> timestamps until 2038-01-19 (0x7fff)
> [ 1610.087139] XFS: Assertion failed: bp->b_flags & XBF_DONE, file: 
> fs/xfs/xfs_trans_buf.c, line: 241
> [ 1610.087162] [ cut here ]
> [ 1610.087165] kernel BUG at fs/xfs/xfs_message.c:102!
> [ 1610.087168] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 1610.087171] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries
> [ 1610.087175] Modules linked in: overlay dm_zero dm_thin_pool 
> dm_persistent_data dm_bio_prison dm_snapshot dm_bufio loop dm_flakey xfs 
> dm_mod nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet 
> nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat 
> nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bonding rfkill ip_set tls 
> nf_tables libcrc32c nfnetlink pseries_rng vmx_crypto ext4 mbcache jbd2 sd_mod 
> t10_pi crc64_rocksoft crc64 sg ibmvscsi scsi_transport_srp ibmveth fuse [last 
> unloaded: scsi_debug]
> [ 1610.087220] CPU: 11 PID: 225897 Comm: kworker/11:46 Not tainted 
> 6.6.0-rc5-gb8b05bc6d83c #1
> [ 1610.087224] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 
> of:IBM,FW1030.20 (NH1030_058) hv:phyp pSeries
> [ 1610.087227] Workqueue: xfs-inodegc/sdb2 xfs_inodegc_worker [xfs]
> [ 1610.087303] NIP: c00802857edc LR: c00802857ec8 CTR: 
> 7fff
> [ 1610.087306] REGS: c0002441b810 TRAP: 0700 Not tainted 
> (6.6.0-rc5-gb8b05bc6d83c)
> [ 1610.087309] MSR: 8282b033  CR: 
> 28000424 XER: 0007
> [ 1610.087318] CFAR: c00802857d1c IRQMASK: 0 
> [ 1610.087318] GPR00: c00802857ec8 c0002441bab0 c00802a68300 
> ffea 
> [ 1610.087318] GPR04: 000a c0002441b9b0  
> c008016c6c40 
> [ 1610.087318] GPR08: ffc0 0001  
> c0080285a3a8 
> [ 1610.087318] GPR12: c08311d0 c0117fff1b00 c0197de8 
> c936bf40 
> [ 1610.087318] GPR16:    
> c009d16d48b0 
> [ 1610.087318] GPR20: c00079e80205 c0001cb52f80 c0001cb52fc0 
> 8000 
> [ 1610.087318] GPR24: 0001 c0002441bbc8 c000e77a7000 
> c000209b7e00 
> [ 1610.087318] GPR28: c0080279ae48 c008016b25f0 c0002441bc10 
> c0002dabaee8 
> [ 1610.087354] NIP [c00802857edc] assfail+0x54/0x74 [xfs]
> [ 1610.087420] LR [c00802857ec8] assfail+0x40/0x74 [xfs]
> [ 1610.087485] Call Trace:
> [ 1610.087486] [c0002441bab0] [c00802857ec8] assfail+0x40/0x74 [xfs] 
> (unreliable)
> [ 1610.087551] [c0002441bb10] [c0080281cebc] 
> xfs_trans_read_buf_map+0x384/0x590 [xfs]
> [ 1610.087622] [c0002441bba0] [c0080279ae48] xfs_imap_to_bp+0x70/0xa8 
> [xfs]
> [ 1610.087691] [c0002441bbf0] [c0080280c3ec] 
> xfs_inode_item_precommit+0x244/0x320 [xfs]
> [ 1610.087760] [c0002441bc60] [c008027f3034] 
> xfs_trans_run_precommits+0xac/0x160 [xfs]
> [ 1610.087830] [c0002441bcb0] [c008027f45b0] 
> __xfs_trans_commit+0x68/0x430 [xfs]
> [ 1610.087900] [c0002441bd20] [c008027dfc30] 
> xfs_inactive_ifree+0x158/0x2a0 [xfs]
> [ 1610.087969] [c0002441bdb0] [c008027dff84] xfs_inactive+0x20c/0x420 
> [xfs]
> [ 1610.088037] [c0002441bdf0] [c008027ceb90] 
> xfs_inodegc_worker+0x148/0x250 [xfs]
> [ 1610.088106] [c0002441be40] [c0188130] 
> process_scheduled_works+0x230/0x4f0
> [ 1610.088113] [c0002441bf10] [c018b164] worker_thread+0x1e4/0x500
> [ 1610.088118] [c0002441bf90] [c0197f18] kthread+0x138/0x140
> [ 1610.088122] [c0002441bfe0] [c000df98] 
> start_kernel_thread+0x14/0x18
> [ 1610.088127] Code: e8a5ca38 7c641b78 3c62 e863ca48 f8010010 f821ffa1 
> 4bfffd91 3d22 e929ca50 89290010 2f89 419e0008 <0fe0> 0fe0 
> 38210060 e8010010 
> [ 1610.088140] ---[ end trace  ]---
> [ 1610.093928] sh (1070303): drop_caches: 3
> [ 1610.095600] pstore: backend (nvram) writing error (-1)
> [ 1610.095605]
> 
> xfs/238 test was executed when the crash was encountered.
> Devices were formatted with 4k block size.

Yeah, I've seen this once before, I think I know what the problem is
from analysis of that failure, but I've been unable to reproduce it
again so I've not been able to confirm 

Re: [PATCH v3 1/2] ASoC: dt-bindings: sound-card-common: List DAPM endpoints ignoring system suspend

2023-10-12 Thread Rob Herring
On Wed, Oct 11, 2023 at 10:21:33PM +0100, Mark Brown wrote:
> On Wed, Oct 11, 2023 at 07:47:58PM +0800, Chancel Liu wrote:
> 
> > +  lpa-widgets:
> > +$ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > +description: |
> > +  A list of DAPM endpoints which mark paths between these endpoints 
> > should
> > +  not be disabled when system enters in suspend state. LPA means low 
> > power
> > +  audio case. For example on asymmetric multiprocessor, there are 
> > Cortex-A
> 
> I suspect that the DT maintainers would prefer that this description be
> workshopped a bit to remove the Linux specifics.

And Cortex A/M specifics if this is a common binding.


>  I think the key thing
> here is that these are endpoints that can be active over suspend of the
> main application processor that the current operating system is running
> (system DT stuff is an interesting corner case here...), and the example
> is probably a bit specific.  Other bindings use "audio sound widgets"
> rather than "DAPM widgets".
> 
> We also shouldn't see that these endpoints "should not be disabled"
> since that implies that they should be left on even if they aren't
> active which isn't quite the case, instead it's that we can continue
> playing an audio stream through them in suspend.

This seems like one of those things that everyone has/does, and everyone 
handles it a bit differently. I applaud trying to do something common, 
but it isn't really common until we have multiple users.

Rob


Re: [PATCH v5 1/5] powerpc/code-patching: introduce patch_instructions()

2023-10-12 Thread Hari Bathini

Thanks for the review, Christophe.

On 10/10/23 11:16 pm, Christophe Leroy wrote:



Le 28/09/2023 à 21:48, Hari Bathini a écrit :

patch_instruction() entails setting up pte, patching the instruction,
clearing the pte and flushing the tlb. If multiple instructions need
to be patched, every instruction would have to go through the above
drill unnecessarily. Instead, introduce function patch_instructions()
that sets up the pte, clears the pte and flushes the tlb only once per
page range of instructions to be patched. This adds a slight overhead
to patch_instruction() call while improving the patching time for
scenarios where more than one instruction needs to be patched.


Not a "slight" but a "significant" overhead on PPC32.

Thinking about it once more I don't think it is a good idea to try and
merge that into the existing code_patching logic which is really single
instruction performance oriented.

Anyway, comments below.



Signed-off-by: Hari Bathini 
---
   arch/powerpc/include/asm/code-patching.h |  1 +
   arch/powerpc/lib/code-patching.c | 93 +---
   2 files changed, 85 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/include/asm/code-patching.h 
b/arch/powerpc/include/asm/code-patching.h
index 3f881548fb61..43a4aedfa703 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -74,6 +74,7 @@ int create_cond_branch(ppc_inst_t *instr, const u32 *addr,
   int patch_branch(u32 *addr, unsigned long target, int flags);
   int patch_instruction(u32 *addr, ppc_inst_t instr);
   int raw_patch_instruction(u32 *addr, ppc_inst_t instr);
+int patch_instructions(void *addr, void *code, size_t len, bool repeat_instr);


I don't like void *, you can do to much nasty things with that.
I think you want u32 *

   
   static inline unsigned long patch_site_addr(s32 *site)

   {
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index b00112d7ad46..4ff002bc41f6 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -278,7 +278,36 @@ static void unmap_patch_area(unsigned long addr)
flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
   }
   
-static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t instr)

+static int __patch_instructions(u32 *patch_addr, void *code, size_t len, bool 
repeat_instr)
+{
+   unsigned long start = (unsigned long)patch_addr;
+
+   /* Repeat instruction */
+   if (repeat_instr) {
+   ppc_inst_t instr = ppc_inst_read(code);
+
+   if (ppc_inst_prefixed(instr)) {
+   u64 val = ppc_inst_as_ulong(instr);
+
+   memset64((uint64_t *)patch_addr, val, len / 8);


Use u64 instead of uint64_t.


+   } else {
+   u32 val = ppc_inst_val(instr);
+
+   memset32(patch_addr, val, len / 4);
+   }
+   } else
+   memcpy(patch_addr, code, len);


Missing braces, see
https://docs.kernel.org/process/coding-style.html#placing-braces-and-spaces


+
+   smp_wmb();  /* smp write barrier */
+   flush_icache_range(start, start + len);
+   return 0;
+}
+
+/*
+ * A page is mapped and instructions that fit the page are patched.
+ * Assumes 'len' to be (PAGE_SIZE - offset_in_page(addr)) or below.
+ */
+static int __do_patch_instructions_mm(u32 *addr, void *code, size_t len, bool 
repeat_instr)
   {
int err;
u32 *patch_addr;
@@ -307,11 +336,15 @@ static int __do_patch_instruction_mm(u32 *addr, 
ppc_inst_t instr)
   
   	orig_mm = start_using_temp_mm(patching_mm);
   
-	err = __patch_instruction(addr, instr, patch_addr);

+   /* Single instruction case. */
+   if (len == 0) {
+   err = __patch_instruction(addr, *(ppc_inst_t *)code, 
patch_addr);


Take care, you can't convert u32 * to ppc_inst_t that way, you have to
use ppc_inst_read() otherwise you'll get odd result with prefixed
instructions depending on endianness.

   
-	/* hwsync performed by __patch_instruction (sync) if successful */

-   if (err)
-   mb();  /* sync */
+   /* hwsync performed by __patch_instruction (sync) if successful 
*/
+   if (err)
+   mb();  /* sync */


Get this away, see my patch at
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/e88b154eaf2efd9ff177d472d3411dcdec8ff4f5.1696675567.git.christophe.le...@csgroup.eu/


+   } else
+   err = __patch_instructions(patch_addr, code, len, repeat_instr);
   
   	/* context synchronisation performed by __patch_instruction (isync or exception) */

stop_using_temp_mm(patching_mm, orig_mm);
@@ -328,7 +361,11 @@ static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t 
instr)
return err;
   }
   
-static int __do_patch_instruction(u32 *addr, ppc_inst_t instr)

+/*
+ * A page is mapped and instructions that fit the page are patched.
+ * Assumes 'len' to be 

[PATCH v6 5/5] powerpc/bpf: use bpf_jit_binary_pack_[alloc|finalize|free]

2023-10-12 Thread Hari Bathini
Use bpf_jit_binary_pack_alloc in powerpc jit. The jit engine first
writes the program to the rw buffer. When the jit is done, the program
is copied to the final location with bpf_jit_binary_pack_finalize.
With multiple jit_subprogs, bpf_jit_free is called on some subprograms
that haven't got bpf_jit_binary_pack_finalize() yet. Implement custom
bpf_jit_free() like in commit 1d5f82d9dd47 ("bpf, x86: fix freeing of
not-finalized bpf_prog_pack") to call bpf_jit_binary_pack_finalize(),
if necessary. As bpf_flush_icache() is not needed anymore, remove it.

Signed-off-by: Hari Bathini 
Acked-by: Song Liu 
---
 arch/powerpc/net/bpf_jit.h|  18 ++---
 arch/powerpc/net/bpf_jit_comp.c   | 106 ++
 arch/powerpc/net/bpf_jit_comp32.c |  13 ++--
 arch/powerpc/net/bpf_jit_comp64.c |  10 +--
 4 files changed, 96 insertions(+), 51 deletions(-)

diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index 72b7bb34fade..cdea5dccaefe 100644
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -36,9 +36,6 @@
EMIT(PPC_RAW_BRANCH(offset)); \
} while (0)
 
-/* bl (unconditional 'branch' with link) */
-#define PPC_BL(dest)   EMIT(PPC_RAW_BL((dest) - (unsigned long)(image + 
ctx->idx)))
-
 /* "cond" here covers BO:BI fields. */
 #define PPC_BCC_SHORT(cond, dest)\
do {  \
@@ -147,12 +144,6 @@ struct codegen_context {
 #define BPF_FIXUP_LEN  2 /* Two instructions => 8 bytes */
 #endif
 
-static inline void bpf_flush_icache(void *start, void *end)
-{
-   smp_wmb();  /* smp write barrier */
-   flush_icache_range((unsigned long)start, (unsigned long)end);
-}
-
 static inline bool bpf_is_seen_register(struct codegen_context *ctx, int i)
 {
return ctx->seen & (1 << (31 - i));
@@ -169,16 +160,17 @@ static inline void bpf_clear_seen_register(struct 
codegen_context *ctx, int i)
 }
 
 void bpf_jit_init_reg_mapping(struct codegen_context *ctx);
-int bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64 
func);
-int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context 
*ctx,
+int bpf_jit_emit_func_call_rel(u32 *image, u32 *fimage, struct codegen_context 
*ctx, u64 func);
+int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct 
codegen_context *ctx,
   u32 *addrs, int pass, bool extra_pass);
 void bpf_jit_build_prologue(u32 *image, struct codegen_context *ctx);
 void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx);
 void bpf_jit_realloc_regs(struct codegen_context *ctx);
 int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context *ctx, int 
tmp_reg, long exit_addr);
 
-int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image, int pass, struct 
codegen_context *ctx,
- int insn_idx, int jmp_off, int dst_reg);
+int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image, u32 *fimage, int 
pass,
+ struct codegen_context *ctx, int insn_idx,
+ int jmp_off, int dst_reg);
 
 #endif
 
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index e7ca270a39d5..a79d7c478074 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -44,9 +44,12 @@ int bpf_jit_emit_exit_insn(u32 *image, struct 
codegen_context *ctx, int tmp_reg,
 }
 
 struct powerpc_jit_data {
-   struct bpf_binary_header *header;
+   /* address of rw header */
+   struct bpf_binary_header *hdr;
+   /* address of ro final header */
+   struct bpf_binary_header *fhdr;
u32 *addrs;
-   u8 *image;
+   u8 *fimage;
u32 proglen;
struct codegen_context ctx;
 };
@@ -67,11 +70,14 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
struct codegen_context cgctx;
int pass;
int flen;
-   struct bpf_binary_header *bpf_hdr;
+   struct bpf_binary_header *fhdr = NULL;
+   struct bpf_binary_header *hdr = NULL;
struct bpf_prog *org_fp = fp;
struct bpf_prog *tmp_fp;
bool bpf_blinded = false;
bool extra_pass = false;
+   u8 *fimage = NULL;
+   u32 *fcode_base;
u32 extable_len;
u32 fixup_len;
 
@@ -101,9 +107,16 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
addrs = jit_data->addrs;
if (addrs) {
cgctx = jit_data->ctx;
-   image = jit_data->image;
-   bpf_hdr = jit_data->header;
+   /*
+* JIT compiled to a writable location (image/code_base) first.
+* It is then moved to the readonly final location 
(fimage/fcode_base)
+* using instruction patching.
+*/
+   fimage = jit_data->fimage;
+   fhdr = jit_data->fhdr;

[PATCH v6 4/5] powerpc/bpf: rename powerpc64_jit_data to powerpc_jit_data

2023-10-12 Thread Hari Bathini
powerpc64_jit_data is a misnomer as it is meant for both ppc32 and
ppc64. Rename it to powerpc_jit_data.

Signed-off-by: Hari Bathini 
Acked-by: Song Liu 
---
 arch/powerpc/net/bpf_jit_comp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index ecd7cffbbe28..e7ca270a39d5 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -43,7 +43,7 @@ int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context 
*ctx, int tmp_reg,
return 0;
 }
 
-struct powerpc64_jit_data {
+struct powerpc_jit_data {
struct bpf_binary_header *header;
u32 *addrs;
u8 *image;
@@ -63,7 +63,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
u8 *image = NULL;
u32 *code_base;
u32 *addrs;
-   struct powerpc64_jit_data *jit_data;
+   struct powerpc_jit_data *jit_data;
struct codegen_context cgctx;
int pass;
int flen;
-- 
2.41.0



[PATCH v6 3/5] powerpc/bpf: implement bpf_arch_text_invalidate for bpf_prog_pack

2023-10-12 Thread Hari Bathini
Implement bpf_arch_text_invalidate and use it to fill unused part of
the bpf_prog_pack with trap instructions when a BPF program is freed.

Signed-off-by: Hari Bathini 
Acked-by: Song Liu 
---
 arch/powerpc/net/bpf_jit_comp.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index c740eac8d584..ecd7cffbbe28 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -292,3 +292,18 @@ void *bpf_arch_text_copy(void *dst, void *src, size_t len)
 
return err ? ERR_PTR(err) : dst;
 }
+
+int bpf_arch_text_invalidate(void *dst, size_t len)
+{
+   u32 insn = BREAKPOINT_INSTRUCTION;
+   int ret;
+
+   if (WARN_ON_ONCE(core_kernel_text((unsigned long)dst)))
+   return -EINVAL;
+
+   mutex_lock(_mutex);
+   ret = patch_instructions(dst, , len, true);
+   mutex_unlock(_mutex);
+
+   return ret;
+}
-- 
2.41.0



[PATCH v6 2/5] powerpc/bpf: implement bpf_arch_text_copy

2023-10-12 Thread Hari Bathini
bpf_arch_text_copy is used to dump JITed binary to RX page, allowing
multiple BPF programs to share the same page. Use the newly introduced
patch_instructions() to implement it.

Signed-off-by: Hari Bathini 
Acked-by: Song Liu 
---
 arch/powerpc/net/bpf_jit_comp.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 37043dfc1add..c740eac8d584 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -13,9 +13,13 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
 
+#include 
+#include 
+
 #include "bpf_jit.h"
 
 static void bpf_jit_fill_ill_insns(void *area, unsigned int size)
@@ -274,3 +278,17 @@ int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image, 
int pass, struct code
ctx->exentry_idx++;
return 0;
 }
+
+void *bpf_arch_text_copy(void *dst, void *src, size_t len)
+{
+   int err;
+
+   if (WARN_ON_ONCE(core_kernel_text((unsigned long)dst)))
+   return ERR_PTR(-EINVAL);
+
+   mutex_lock(_mutex);
+   err = patch_instructions(dst, src, len, false);
+   mutex_unlock(_mutex);
+
+   return err ? ERR_PTR(err) : dst;
+}
-- 
2.41.0



[PATCH v6 1/5] powerpc/code-patching: introduce patch_instructions()

2023-10-12 Thread Hari Bathini
patch_instruction() entails setting up pte, patching the instruction,
clearing the pte and flushing the tlb. If multiple instructions need
to be patched, every instruction would have to go through the above
drill unnecessarily. Instead, introduce patch_instructions() function
that sets up the pte, clears the pte and flushes the tlb only once per
page range of instructions to be patched. This duplicates most of the
code patching logic, instead of merging with it, to avoid performance
degradation observed for single instruction patching on ppc32 with
the code path merged.

Signed-off-by: Hari Bathini 
Acked-by: Song Liu 
---

Changes in v6:
* Skipped merging code path of patch_instruction() & patch_instructions()
  to avoid performance overhead observed on ppc32 with that.


 arch/powerpc/include/asm/code-patching.h |   1 +
 arch/powerpc/lib/code-patching.c | 138 +++
 2 files changed, 139 insertions(+)

diff --git a/arch/powerpc/include/asm/code-patching.h 
b/arch/powerpc/include/asm/code-patching.h
index 3f881548fb61..0e29ccf903d0 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -74,6 +74,7 @@ int create_cond_branch(ppc_inst_t *instr, const u32 *addr,
 int patch_branch(u32 *addr, unsigned long target, int flags);
 int patch_instruction(u32 *addr, ppc_inst_t instr);
 int raw_patch_instruction(u32 *addr, ppc_inst_t instr);
+int patch_instructions(u32 *addr, u32 *code, size_t len, bool repeat_instr);
 
 static inline unsigned long patch_site_addr(s32 *site)
 {
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index b00112d7ad46..a115496f934b 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -378,6 +378,144 @@ int patch_instruction(u32 *addr, ppc_inst_t instr)
 }
 NOKPROBE_SYMBOL(patch_instruction);
 
+static int __patch_instructions(u32 *patch_addr, u32 *code, size_t len, bool 
repeat_instr)
+{
+   unsigned long start = (unsigned long)patch_addr;
+
+   /* Repeat instruction */
+   if (repeat_instr) {
+   ppc_inst_t instr = ppc_inst_read(code);
+
+   if (ppc_inst_prefixed(instr)) {
+   u64 val = ppc_inst_as_ulong(instr);
+
+   memset64((u64 *)patch_addr, val, len / 8);
+   } else {
+   u32 val = ppc_inst_val(instr);
+
+   memset32(patch_addr, val, len / 4);
+   }
+   } else {
+   memcpy(patch_addr, code, len);
+   }
+
+   smp_wmb();  /* smp write barrier */
+   flush_icache_range(start, start + len);
+   return 0;
+}
+
+/*
+ * A page is mapped and instructions that fit the page are patched.
+ * Assumes 'len' to be (PAGE_SIZE - offset_in_page(addr)) or below.
+ */
+static int __do_patch_instructions_mm(u32 *addr, u32 *code, size_t len, bool 
repeat_instr)
+{
+   struct mm_struct *patching_mm, *orig_mm;
+   unsigned long pfn = get_patch_pfn(addr);
+   unsigned long text_poke_addr;
+   spinlock_t *ptl;
+   u32 *patch_addr;
+   pte_t *pte;
+   int err;
+
+   patching_mm = __this_cpu_read(cpu_patching_context.mm);
+   text_poke_addr = __this_cpu_read(cpu_patching_context.addr);
+   patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
+
+   pte = get_locked_pte(patching_mm, text_poke_addr, );
+   if (!pte)
+   return -ENOMEM;
+
+   __set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn, 
PAGE_KERNEL), 0);
+
+   /* order PTE update before use, also serves as the hwsync */
+   asm volatile("ptesync" ::: "memory");
+
+   /* order context switch after arbitrary prior code */
+   isync();
+
+   orig_mm = start_using_temp_mm(patching_mm);
+
+   err = __patch_instructions(patch_addr, code, len, repeat_instr);
+
+   /* context synchronisation performed by __patch_instructions */
+   stop_using_temp_mm(patching_mm, orig_mm);
+
+   pte_clear(patching_mm, text_poke_addr, pte);
+   /*
+* ptesync to order PTE update before TLB invalidation done
+* by radix__local_flush_tlb_page_psize (in _tlbiel_va)
+*/
+   local_flush_tlb_page_psize(patching_mm, text_poke_addr, 
mmu_virtual_psize);
+
+   pte_unmap_unlock(pte, ptl);
+
+   return err;
+}
+
+/*
+ * A page is mapped and instructions that fit the page are patched.
+ * Assumes 'len' to be (PAGE_SIZE - offset_in_page(addr)) or below.
+ */
+static int __do_patch_instructions(u32 *addr, u32 *code, size_t len, bool 
repeat_instr)
+{
+   unsigned long pfn = get_patch_pfn(addr);
+   unsigned long text_poke_addr;
+   u32 *patch_addr;
+   pte_t *pte;
+   int err;
+
+   text_poke_addr = (unsigned 
long)__this_cpu_read(cpu_patching_context.addr) & PAGE_MASK;
+   patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
+
+   pte = __this_cpu_read(cpu_patching_context.pte);
+   

[PATCH v6 0/5] powerpc/bpf: use BPF prog pack allocator

2023-10-12 Thread Hari Bathini
Most BPF programs are small, but they consume a page each. For systems
with busy traffic and many BPF programs, this may also add significant
pressure on instruction TLB. High iTLB pressure usually slows down the
whole system causing visible performance degradation for production
workloads.

bpf_prog_pack, a customized allocator that packs multiple bpf programs
into preallocated memory chunks, was proposed [1] to address it. This
series extends this support on powerpc.

Both bpf_arch_text_copy() & bpf_arch_text_invalidate() functions,
needed for this support depend on instruction patching in text area.
Currently, patch_instruction() supports patching only one instruction
at a time. The first patch introduces patch_instructions() function
to enable patching more than one instruction at a time. This helps in
avoiding performance degradation while JITing bpf programs.

Patches 2 & 3 implement the above mentioned arch specific functions
using patch_instructions(). Patch 4 fixes a misnomer in bpf JITing
code. The last patch enables the use of BPF prog pack allocator on
powerpc and also, ensures cleanup is handled gracefully.

[1] https://lore.kernel.org/bpf/20220204185742.271030-1-s...@kernel.org/

Changes in v6:
* No changes in patches 2-5/5 except addition of Acked-by tags from Song.
* Skipped merging code path of patch_instruction() & patch_instructions()
  to avoid performance overhead observed on ppc32 with that.

Changes in v5:
* Moved introduction of patch_instructions() as 1st patch in series.
* Improved patch_instructions() to use memset & memcpy.
* Fixed the misnomer in JITing code as a separate patch.
* Removed unused bpf_flush_icache() function.

Changes in v4:
* Updated bpf_patch_instructions() definition in patch 1/5 so that
  it doesn't have to be updated again in patch 2/5.
* Addressed Christophe's comment on bpf_arch_text_invalidate() return
  value in patch 2/5.

Changes in v3:
* Fixed segfault issue observed on ppc32 due to inaccurate offset
  calculation for branching.
* Tried to minimize the performance impact for patch_instruction()
  with the introduction of patch_instructions().
* Corrected uses of u32* vs ppc_instr_t.
* Moved the change that introduces patch_instructions() to after
  enabling bpf_prog_pack support.
* Added few comments to improve code readability.

Changes in v2:
* Introduced patch_instructions() to help with patching bpf programs.


Hari Bathini (5):
  powerpc/code-patching: introduce patch_instructions()
  powerpc/bpf: implement bpf_arch_text_copy
  powerpc/bpf: implement bpf_arch_text_invalidate for bpf_prog_pack
  powerpc/bpf: rename powerpc64_jit_data to powerpc_jit_data
  powerpc/bpf: use bpf_jit_binary_pack_[alloc|finalize|free]

 arch/powerpc/include/asm/code-patching.h |   1 +
 arch/powerpc/lib/code-patching.c | 138 +
 arch/powerpc/net/bpf_jit.h   |  18 +--
 arch/powerpc/net/bpf_jit_comp.c  | 145 ++-
 arch/powerpc/net/bpf_jit_comp32.c|  13 +-
 arch/powerpc/net/bpf_jit_comp64.c|  10 +-
 6 files changed, 271 insertions(+), 54 deletions(-)

-- 
2.41.0



[PATCH 2/2] sparc: Allow nesting of lazy MMU mode

2023-10-12 Thread Matthew Wilcox (Oracle)
As noted in commit 49147beb0ccb ("x86/xen: allow nesting of same lazy
mode"), we can now nest calls to arch_enter_lazy_mmu_mode().  Use ->active
as a counter instead of a flag and only drain the batch when the counter
hits 0.

Signed-off-by: Matthew Wilcox (Oracle) 
Fixes: bcc6cc832573 ("mm: add default definition of set_ptes()")
---
 arch/sparc/mm/tlb.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
index b44d79d778c7..a82c7c32e47d 100644
--- a/arch/sparc/mm/tlb.c
+++ b/arch/sparc/mm/tlb.c
@@ -54,16 +54,15 @@ void arch_enter_lazy_mmu_mode(void)
 {
struct tlb_batch *tb = this_cpu_ptr(_batch);
 
-   tb->active = 1;
+   tb->active++;
 }
 
 void arch_leave_lazy_mmu_mode(void)
 {
struct tlb_batch *tb = this_cpu_ptr(_batch);
 
-   if (tb->tlb_nr)
+   if ((--tb->active == 0) && tb->tlb_nr)
flush_tlb_pending();
-   tb->active = 0;
 }
 
 static void tlb_batch_add_one(struct mm_struct *mm, unsigned long vaddr,
-- 
2.40.1



[PATCH 1/2] powerpc: Allow nesting of lazy MMU mode

2023-10-12 Thread Matthew Wilcox (Oracle)
As noted in commit 49147beb0ccb ("x86/xen: allow nesting of same lazy
mode"), we can now nest calls to arch_enter_lazy_mmu_mode().  Use ->active
as a counter instead of a flag and only drain the batch when the counter
hits 0.

Signed-off-by: Matthew Wilcox (Oracle) 
Fixes: bcc6cc832573 ("mm: add default definition of set_ptes()")
---
 arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h 
b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index 146287d9580f..bc845d876ed2 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
@@ -38,7 +38,7 @@ static inline void arch_enter_lazy_mmu_mode(void)
 */
preempt_disable();
batch = this_cpu_ptr(_tlb_batch);
-   batch->active = 1;
+   batch->active++;
 }
 
 static inline void arch_leave_lazy_mmu_mode(void)
@@ -49,9 +49,8 @@ static inline void arch_leave_lazy_mmu_mode(void)
return;
batch = this_cpu_ptr(_tlb_batch);
 
-   if (batch->index)
+   if ((--batch->active == 0) && batch->index)
__flush_tlb_pending(batch);
-   batch->active = 0;
preempt_enable();
 }
 
-- 
2.40.1



[PATCH 0/2] Allow nesting of lazy MMU mode

2023-10-12 Thread Matthew Wilcox (Oracle)
Dave Woodhouse reported that we now nest calls to
arch_enter_lazy_mmu_mode().  That was inadvertent, but in principle we
should allow it.  On further investigation, Juergen already fixed it
for Xen, but didn't tell anyone.  Fix it for Sparc & PowerPC too.
This may or may not help fix the problem that Erhard reported.

Matthew Wilcox (Oracle) (2):
  powerpc: Allow nesting of lazy MMU mode
  sparc: Allow nesting of lazy MMU mode

 arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 5 ++---
 arch/sparc/mm/tlb.c| 5 ++---
 2 files changed, 4 insertions(+), 6 deletions(-)

-- 
2.40.1



Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

2023-10-12 Thread Geoff Levand
On 10/12/23 17:41, Johannes Berg wrote:
> But seriously - is it worth to try to keep a wireless driver for it if
> we don't even know anyone using a PS3 at all?

There is still a considerable user base for the PS3, so we
must keep the ps3-gelic-wireless driver.

-Geoff



Re: [Bisected] [1b4fa28a8b07] Build failure "net/core/gso_test.c"

2023-10-12 Thread Kees Cook
On Thu, Oct 12, 2023 at 11:57:46AM +0200, Florian Westphal wrote:
> Tasmiya Nalatwad  wrote:
> > Greetings,
> > 
> > [net-next] [6.6-rc4] Build failure "net/core/gso_test.c"
> > 
> > --- Traces ---
> > 
> > make -j 33 -s && make modules_install && make install
> > net/core/gso_test.c:58:48: error: initializer element is not constant
> >    58 | .segs = (const unsigned int[]) { gso_size },
> >   |    ^
> 
> Ouch, I can reproduce this with: gcc --version
> gcc (Debian 12.2.0-14) 12.2.0
> Copyright (C) 2022 Free Software Foundation, Inc.
> 
> gcc 13.2.1 and clang-16.0.6 are ok.
> 
> Whats the preference here?  We could use simple preprocessor constant
> or we could require much more recent compiler version for the net
> kunit tests via kconfig.
> 
> gcc-12.2.0 can compile it after this simple s//g "fix":
> 
> diff --git a/net/core/gso_test.c b/net/core/gso_test.c
> --- a/net/core/gso_test.c
> +++ b/net/core/gso_test.c
> @@ -4,7 +4,7 @@
>  #include 
>  
>  static const char hdr[] = "abcdefgh";
> -static const int gso_size = 1000;
> +#define GSO_TEST_SIZE 1000

This fixes the build for me too.

Tested-by: Kees Cook 
Reviewed-by: Kees Cook 

-Kees

>  
>  static void __init_skb(struct sk_buff *skb)
>  {
> @@ -18,7 +18,7 @@ static void __init_skb(struct sk_buff *skb)
>  
>   /* proto is arbitrary, as long as not ETH_P_TEB or vlan */
>   skb->protocol = htons(ETH_P_ATALK);
> - skb_shinfo(skb)->gso_size = gso_size;
> + skb_shinfo(skb)->gso_size = GSO_TEST_SIZE;
>  }
>  
>  enum gso_test_nr {
> @@ -53,70 +53,70 @@ static struct gso_test_case cases[] = {
>   {
>   .id = GSO_TEST_NO_GSO,
>   .name = "no_gso",
> - .linear_len = gso_size,
> + .linear_len = GSO_TEST_SIZE,
>   .nr_segs = 1,
> - .segs = (const unsigned int[]) { gso_size },
> + .segs = (const unsigned int[]) { GSO_TEST_SIZE },
>   },
>   {
>   .id = GSO_TEST_LINEAR,
>   .name = "linear",
> - .linear_len = gso_size + gso_size + 1,
> + .linear_len = GSO_TEST_SIZE + GSO_TEST_SIZE + 1,
>   .nr_segs = 3,
> - .segs = (const unsigned int[]) { gso_size, gso_size, 1 },
> + .segs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
> 1 },
>   },
>   {
>   .id = GSO_TEST_FRAGS,
>   .name = "frags",
> - .linear_len = gso_size,
> + .linear_len = GSO_TEST_SIZE,
>   .nr_frags = 2,
> - .frags = (const unsigned int[]) { gso_size, 1 },
> + .frags = (const unsigned int[]) { GSO_TEST_SIZE, 1 },
>   .nr_segs = 3,
> - .segs = (const unsigned int[]) { gso_size, gso_size, 1 },
> + .segs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
> 1 },
>   },
>   {
>   .id = GSO_TEST_FRAGS_PURE,
>   .name = "frags_pure",
>   .nr_frags = 3,
> - .frags = (const unsigned int[]) { gso_size, gso_size, 2 },
> + .frags = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
> 2 },
>   .nr_segs = 3,
> - .segs = (const unsigned int[]) { gso_size, gso_size, 2 },
> + .segs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
> 2 },
>   },
>   {
>   .id = GSO_TEST_GSO_PARTIAL,
>   .name = "gso_partial",
> - .linear_len = gso_size,
> + .linear_len = GSO_TEST_SIZE,
>   .nr_frags = 2,
> - .frags = (const unsigned int[]) { gso_size, 3 },
> + .frags = (const unsigned int[]) { GSO_TEST_SIZE, 3 },
>   .nr_segs = 2,
> - .segs = (const unsigned int[]) { 2 * gso_size, 3 },
> + .segs = (const unsigned int[]) { 2 * GSO_TEST_SIZE, 3 },
>   },
>   {
>   /* commit 89319d3801d1: frag_list on mss boundaries */
>   .id = GSO_TEST_FRAG_LIST,
>   .name = "frag_list",
> - .linear_len = gso_size,
> + .linear_len = GSO_TEST_SIZE,
>   .nr_frag_skbs = 2,
> - .frag_skbs = (const unsigned int[]) { gso_size, gso_size },
> + .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, 
> GSO_TEST_SIZE },
>   .nr_segs = 3,
> - .segs = (const unsigned int[]) { gso_size, gso_size, gso_size },
> + .segs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
> GSO_TEST_SIZE },
>   },
>   {
>   .id = GSO_TEST_FRAG_LIST_PURE,
>   .name = "frag_list_pure",
>   .nr_frag_skbs = 2,
> - .frag_skbs = (const unsigned int[]) { gso_size, gso_size },
> + .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, 
> GSO_TEST_SIZE },
>   .nr_segs = 2,
> - .segs = (const unsigned int[]) { gso_size, 

Re: [PATCH 1/3] perf tests test_arm_coresight: Fix the shellcheck warning in latest test_arm_coresight.sh

2023-10-12 Thread Athira Rajeev



> On 12-Oct-2023, at 9:37 PM, Suzuki K Poulose  wrote:
> 
> Hi,
> 
> On 12/10/2023 16:56, Athira Rajeev wrote:
>>> On 05-Oct-2023, at 3:06 PM, Suzuki K Poulose  wrote:
>>> 
>>> On 05/10/2023 06:02, Namhyung Kim wrote:
 On Thu, Sep 28, 2023 at 9:11 PM Athira Rajeev
  wrote:
> 
> 
> ...
> 
>>> Thanks for the fix.
>>> 
>>> Nothing to do with this patch, but I am wondering if the original patch
>>> is over engineered and may not be future proof.
>>> 
>>> e.g.,
>>> 
>>> cs_etm_dev_name() {
>>> + cs_etm_path=$(find  /sys/bus/event_source/devices/cs_etm/ -name cpu* 
>>> -print -quit)
>>> 
>>> Right there you got the device name and we can easily deduce the name of
>>> the "ETM" node.
>>> 
>>> e.g,:
>>> etm=$(basename $(readlink cs_etm_path) | sed "s/[0-9]\+$//")
>>> 
>>> And practically, nobody prevents an ETE mixed with an ETM on a "hybrid"
>>> system (hopefully, no one builds it ;-))
>>> 
>>> Also, instead of hardcoding "ete" and "etm" prefixes from the arch part,
>>> we should simply use the cpu nodes from :
>>> 
>>> /sys/bus/event_source/devices/cs_etm/
>>> 
>>> e.g.,
>>> 
>>> arm_cs_etm_traverse_path_test() {
>>> # Iterate for every ETM device
>>> for c in /sys/bus/event_source/devices/cs_etm/cpu*; do
>>> # Read the link to be on the safer side
>>> dev=`readlink $c`
>>> 
>>> # Find the ETM device belonging to which CPU
>>> cpu=`cat $dev/cpu`
>>> 
>>> # Use depth-first search (DFS) to iterate outputs
>>> arm_cs_iterate_devices $dev $cpu
>>> done;
>>> }
>>> 
>>> 
>>> 
 You'd better add Coresight folks on this.
 Maybe this file was missing in the MAINTAINERS file.
>>> 
>>> And the original author of the commit, that introduced the issue too.
>>> 
>>> Suzuki
>> Hi All,
>> Thanks for the discussion and feedbacks.
>> This patch fixes the shellcheck warning introduced in function 
>> "cs_etm_dev_name". But with the changes that Suzuki suggested, we won't need 
>> the function "cs_etm_dev_name" since the code will use 
>> "/sys/bus/event_source/devices/cs_etm/" .  In that case, can I drop this 
>> patch for now from this series ?
> 
> Yes, please. James will send out the proposed patch

Hi Suzuki,

Sure. Thanks! 

Athira
> 
> Suzuki
> 
> 



Re: [PATCH 1/3] perf tests test_arm_coresight: Fix the shellcheck warning in latest test_arm_coresight.sh

2023-10-12 Thread Suzuki K Poulose

Hi,

On 12/10/2023 16:56, Athira Rajeev wrote:




On 05-Oct-2023, at 3:06 PM, Suzuki K Poulose  wrote:

On 05/10/2023 06:02, Namhyung Kim wrote:

On Thu, Sep 28, 2023 at 9:11 PM Athira Rajeev
 wrote:




...


Thanks for the fix.

Nothing to do with this patch, but I am wondering if the original patch
is over engineered and may not be future proof.

e.g.,

cs_etm_dev_name() {
+ cs_etm_path=$(find  /sys/bus/event_source/devices/cs_etm/ -name cpu* -print 
-quit)

Right there you got the device name and we can easily deduce the name of
the "ETM" node.

e.g,:
etm=$(basename $(readlink cs_etm_path) | sed "s/[0-9]\+$//")

And practically, nobody prevents an ETE mixed with an ETM on a "hybrid"
system (hopefully, no one builds it ;-))

Also, instead of hardcoding "ete" and "etm" prefixes from the arch part,
we should simply use the cpu nodes from :

/sys/bus/event_source/devices/cs_etm/

e.g.,

arm_cs_etm_traverse_path_test() {
# Iterate for every ETM device
for c in /sys/bus/event_source/devices/cs_etm/cpu*; do
# Read the link to be on the safer side
dev=`readlink $c`

# Find the ETM device belonging to which CPU
cpu=`cat $dev/cpu`

# Use depth-first search (DFS) to iterate outputs
arm_cs_iterate_devices $dev $cpu
done;
}




You'd better add Coresight folks on this.
Maybe this file was missing in the MAINTAINERS file.


And the original author of the commit, that introduced the issue too.

Suzuki


Hi All,
Thanks for the discussion and feedbacks.

This patch fixes the shellcheck warning introduced in function "cs_etm_dev_name". But with the 
changes that Suzuki suggested, we won't need the function "cs_etm_dev_name" since the code will use 
"/sys/bus/event_source/devices/cs_etm/" .  In that case, can I drop this patch for now from this 
series ?



Yes, please. James will send out the proposed patch

Suzuki




Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

2023-10-12 Thread Johannes Berg
On Thu, 2023-10-12 at 16:36 +0200, Arnd Bergmann wrote:
> 
> ps3-gelic-wireless

Didn't Sony disable Linux on PS3 eventually? Though maybe someone still
has some devices with old software.

johannes


Re: [PATCH 1/3] perf tests test_arm_coresight: Fix the shellcheck warning in latest test_arm_coresight.sh

2023-10-12 Thread Athira Rajeev



> On 05-Oct-2023, at 3:06 PM, Suzuki K Poulose  wrote:
> 
> On 05/10/2023 06:02, Namhyung Kim wrote:
>> On Thu, Sep 28, 2023 at 9:11 PM Athira Rajeev
>>  wrote:
>>> 
>>> Running shellcheck on tests/shell/test_arm_coresight.sh
>>> throws below warnings:
>>> 
>>> In tests/shell/test_arm_coresight.sh line 15:
>>> cs_etm_path=$(find  /sys/bus/event_source/devices/cs_etm/ -name 
>>> cpu* -print -quit)
>>>   ^--^ SC2061: Quote the parameter to -name so the shell 
>>> won't interpret it.
>>> 
>>> In tests/shell/test_arm_coresight.sh line 20:
>>> if [ $archhver -eq 5 -a "$(printf "0x%X\n" $archpart)" = 
>>> "0xA13" ] ; then
>>>  ^-- SC2166: Prefer [ p ] && [ q ] as [ 
>>> p -a q ] is not well defined
>>> 
>>> This warning is observed after commit:
>>> "commit bb350847965d ("perf test: Update cs_etm testcase for Arm ETE")"
>>> 
>>> Fixed this issue by using quoting 'cpu*' for SC2061 and
>>> using "&&" in line number 20 for SC2166 warning
>>> 
>>> Fixes: bb350847965d ("perf test: Update cs_etm testcase for Arm ETE")
>>> Signed-off-by: Athira Rajeev 
> 
> Thanks for the fix.
> 
> Nothing to do with this patch, but I am wondering if the original patch
> is over engineered and may not be future proof.
> 
> e.g.,
> 
> cs_etm_dev_name() {
> + cs_etm_path=$(find  /sys/bus/event_source/devices/cs_etm/ -name cpu* -print 
> -quit)
> 
> Right there you got the device name and we can easily deduce the name of
> the "ETM" node.
> 
> e.g,:
> etm=$(basename $(readlink cs_etm_path) | sed "s/[0-9]\+$//")
> 
> And practically, nobody prevents an ETE mixed with an ETM on a "hybrid"
> system (hopefully, no one builds it ;-))
> 
> Also, instead of hardcoding "ete" and "etm" prefixes from the arch part,
> we should simply use the cpu nodes from :
> 
> /sys/bus/event_source/devices/cs_etm/
> 
> e.g.,
> 
> arm_cs_etm_traverse_path_test() {
> # Iterate for every ETM device
> for c in /sys/bus/event_source/devices/cs_etm/cpu*; do
> # Read the link to be on the safer side
> dev=`readlink $c`
> 
> # Find the ETM device belonging to which CPU
> cpu=`cat $dev/cpu`
> 
> # Use depth-first search (DFS) to iterate outputs
> arm_cs_iterate_devices $dev $cpu
> done;
> }
> 
> 
> 
>> You'd better add Coresight folks on this.
>> Maybe this file was missing in the MAINTAINERS file.
> 
> And the original author of the commit, that introduced the issue too.
> 
> Suzuki

Hi All,
Thanks for the discussion and feedbacks.

This patch fixes the shellcheck warning introduced in function 
"cs_etm_dev_name". But with the changes that Suzuki suggested, we won't need 
the function "cs_etm_dev_name" since the code will use 
"/sys/bus/event_source/devices/cs_etm/" .  In that case, can I drop this patch 
for now from this series ?

Thanks
Athira

> 
>> Thanks,
>> Namhyung
>>> ---
>>>  tools/perf/tests/shell/test_arm_coresight.sh | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/tools/perf/tests/shell/test_arm_coresight.sh 
>>> b/tools/perf/tests/shell/test_arm_coresight.sh
>>> index fe78c4626e45..f2115dfa24a5 100755
>>> --- a/tools/perf/tests/shell/test_arm_coresight.sh
>>> +++ b/tools/perf/tests/shell/test_arm_coresight.sh
>>> @@ -12,12 +12,12 @@
>>>  glb_err=0
>>> 
>>>  cs_etm_dev_name() {
>>> -   cs_etm_path=$(find  /sys/bus/event_source/devices/cs_etm/ -name 
>>> cpu* -print -quit)
>>> +   cs_etm_path=$(find  /sys/bus/event_source/devices/cs_etm/ -name 
>>> 'cpu*' -print -quit)
>>> trcdevarch=$(cat ${cs_etm_path}/mgmt/trcdevarch)
>>> archhver=$((($trcdevarch >> 12) & 0xf))
>>> archpart=$(($trcdevarch & 0xfff))
>>> 
>>> -   if [ $archhver -eq 5 -a "$(printf "0x%X\n" $archpart)" = "0xA13" ] 
>>> ; then
>>> +   if [ $archhver -eq 5 ] && [ "$(printf "0x%X\n" $archpart)" = 
>>> "0xA13" ] ; then
>>> echo "ete"
>>> else
>>> echo "etm"
>>> --
>>> 2.31.1




Re: [PATCH 1/3] perf tests test_arm_coresight: Fix the shellcheck warning in latest test_arm_coresight.sh

2023-10-12 Thread Athira Rajeev



> On 05-Oct-2023, at 9:15 PM, David Laight  wrote:
> 
> From: David Laight
>> Sent: 05 October 2023 11:16
> ...
>>> - cs_etm_path=$(find  /sys/bus/event_source/devices/cs_etm/ -name cpu* 
>>> -print -quit)
>>> + cs_etm_path=$(find  /sys/bus/event_source/devices/cs_etm/ -name 'cpu*' 
>>> -print -quit)
>> 
>> Isn't the intention to get the shell to expand "cpu* ?
>> So quoting it completely breaks the script.
> 
> Complete brain-fade :-(

Hi David,

Yeah, quoting it also will expand

Thanks
Athira
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 
> 1PT, UK
> Registration No: 1397386 (Wales)
> 



Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

2023-10-12 Thread Johannes Berg
On Thu, 2023-10-12 at 17:39 +0200, Geert Uytterhoeven wrote:
> Hi Johannes,
> 
> On Thu, Oct 12, 2023 at 5:28 PM Johannes Berg  
> wrote:
> > On Thu, 2023-10-12 at 16:36 +0200, Arnd Bergmann wrote:
> > > 
> > > ps3-gelic-wireless
> > 
> > Didn't Sony disable Linux on PS3 eventually? Though maybe someone still
> > has some devices with old software.
> 
> If you didn't update the firmware, you could keep on using Linux.
> 
> And people may have found a vulnerability in more recent firmware
> versions that allows them to run custom software.

Yeah, fair.

> I don't know, it's been +10 years ago I touched a PS3 ;-)

I never had one :-)

But seriously - is it worth to try to keep a wireless driver for it if
we don't even know anyone using a PS3 at all?

But maybe we'll find someone :-)

johannes


Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

2023-10-12 Thread Geert Uytterhoeven
Hi Johannes,

On Thu, Oct 12, 2023 at 5:28 PM Johannes Berg  wrote:
> On Thu, 2023-10-12 at 16:36 +0200, Arnd Bergmann wrote:
> >
> > ps3-gelic-wireless
>
> Didn't Sony disable Linux on PS3 eventually? Though maybe someone still
> has some devices with old software.

If you didn't update the firmware, you could keep on using Linux.

And people may have found a vulnerability in more recent firmware
versions that allows them to run custom software.
I don't know, it's been +10 years ago I touched a PS3 ;-)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

2023-10-12 Thread Geert Uytterhoeven
CC geoff, ppc

On Thu, Oct 12, 2023 at 4:46 PM Kalle Valo  wrote:
> "Arnd Bergmann"  writes:
>
> > On Thu, Oct 12, 2023, at 13:47, Kalle Valo wrote:
> >>
> >> Is anyone willing to submit patches? Use wireless-next as the baseline
> >> for patches and one driver per commit, please. That way it's easy to
> >> revert later, if needed (hopefully not).
> >
> > I can do it, I've already done most of the work for moving the
> > drivers, so I just need to split up my existing patch and leave out
> > the bits that get added to drivers/staging.
>
> Awesome, thank you!
>
> > I'll also send Greg a patch to remove rtl8192u now that we know
> > that this has been broken for 7 years. Similarly, I'd include
> > another patch to remove PCMCIA support for libertas, as that
> > would otherwise be the only remaining 16-bit PCMCIA wlan card,
> > and I could find no indication of this one ever being popular,
> > unlike the USB/SDIO/SPI variants of the same device or the
> > other PCMCIA drivers.
> >
> > This would leave only a handful of wext implementations in the
> > tree: ipw2x00, ps3-gelic-wireless, staging/rtl8712, staging/rtl8192e
> > and staging/ks7010. Since ipw2x00 is apparently still supported
> > in theory and was rather popular on Pentium-M based systems 20
> > years ago, this may still need to be converted to cfg80211
> > before you can remove support for wext style drivers altogether.
> > ps3-gelic-wireless and rtl8712 are also still maintained but have
> > a much smaller user base I assume.
>
> Actually I would prefer to remove ipw2x00 and ps3-gelic-wireless as
> well. I have not seen any evidence that there would be users for those
> drivers. If we find out that there really are users I can easily add the
> drivers back. The faster we get rid of wext the better, it really needs
> to go away.
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


Re: [Bisected] PowerMac G5 fails booting kernel 6.6-rc3 (BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe)

2023-10-12 Thread Erhard Furtner
On Thu, 12 Oct 2023 10:47:51 +1100
Michael Ellerman  wrote:

> I don't see this crash on my quad G5.
> 
> I notice that your config has CONFIG_FLATMEM=y. Can you try switching to
> SPARSEMEM and see if that helps? It might help us narrow down the bug at
> least.

Your assumption was right, interesting! With CONFIG_SpARSEMEM=y my G5 boots up 
just fine (dmesg attached).

I did set CONFIG_FLATMEM=y in the .config as it's a G5 11,2 with a Dual-Core 
970MP, not Dual-CPU as the G5 7,3. So I saw no point in using SpARSEMEM as it's 
a single-CPU machine.

Regards,
Erhard


dmesg_66-rc5_g5
Description: Binary data


Re: [PATCHv8 1/5] powerpc/setup : Enable boot_cpu_hwid for PPC32

2023-10-12 Thread Pingfan Liu
On Wed, Oct 11, 2023 at 6:53 PM Sourabh Jain  wrote:
>
> Hello Pingfan,
> >>> With this patch series applied, the kdump kernel fails to boot on
> >>> powerpc with nr_cpus=1.
> >>>
> >>> Console logs:
> >>> ---
> >>> [root]# echo c > /proc/sysrq-trigger
> >>> [   74.783235] sysrq: Trigger a crash
> >>> [   74.783244] Kernel panic - not syncing: sysrq triggered crash
> >>> [   74.783252] CPU: 58 PID: 3838 Comm: bash Kdump: loaded Not tainted
> >>> 6.6.0-rc5pf-nr-cpus+ #3
> >>> [   74.783259] Hardware name: POWER10 (raw) phyp pSeries
> >>> [   74.783275] Call Trace:
> >>> [   74.783280] [c0020f4ebac0] [c0ed9f38]
> >>> dump_stack_lvl+0x6c/0x9c (unreliable)
> >>> [   74.783291] [c0020f4ebaf0] [c0150300] panic+0x178/0x438
> >>> [   74.783298] [c0020f4ebb90] [c0936d48]
> >>> sysrq_handle_crash+0x28/0x30
> >>> [   74.783304] [c0020f4ebbf0] [c093773c]
> >>> __handle_sysrq+0x10c/0x250
> >>> [   74.783309] [c0020f4ebc90] [c0937fa8]
> >>> write_sysrq_trigger+0xc8/0x168
> >>> [   74.783314] [c0020f4ebcd0] [c0665d8c]
> >>> proc_reg_write+0x10c/0x1b0
> >>> [   74.783321] [c0020f4ebd00] [c058da54]
> >>> vfs_write+0x104/0x4b0
> >>> [   74.783326] [c0020f4ebdc0] [c058dfdc]
> >>> ksys_write+0x7c/0x140
> >>> [   74.783331] [c0020f4ebe10] [c0033a64]
> >>> system_call_exception+0x144/0x3a0
> >>> [   74.783337] [c0020f4ebe50] [c000c554]
> >>> system_call_common+0xf4/0x258
> >>> [   74.783343] --- interrupt: c00 at 0x7fffa0721594
> >>> [   74.783352] NIP:  7fffa0721594 LR: 7fffa0697bf4 CTR:
> >>> 
> >>> [   74.783364] REGS: c0020f4ebe80 TRAP: 0c00   Not tainted
> >>> (6.6.0-rc5pf-nr-cpus+)
> >>> [   74.783376] MSR:  8280f033
> >>>   CR: 2802  XER: 
> >>> [   74.783394] IRQMASK: 0
> >>> [   74.783394] GPR00: 0004 7c4b6800 7fffa0807300
> >>> 0001
> >>> [   74.783394] GPR04: 00013549ea60 0002 0010
> >>> 
> >>> [   74.783394] GPR08:   
> >>> 
> >>> [   74.783394] GPR12:  7fffa0abaf70 4000
> >>> 00011a0f9798
> >>> [   74.783394] GPR16: 00011a0f9724 00011a097688 00011a02ff70
> >>> 00011a0fd568
> >>> [   74.783394] GPR20: 000135554bf0 0001 00011a0aa478
> >>> 7c4b6a24
> >>> [   74.783394] GPR24: 7c4b6a20 00011a0faf94 0002
> >>> 00013549ea60
> >>> [   74.783394] GPR28: 0002 7fffa08017a0 00013549ea60
> >>> 0002
> >>> [   74.783440] NIP [7fffa0721594] 0x7fffa0721594
> >>> [   74.783443] LR [7fffa0697bf4] 0x7fffa0697bf4
> >>> [   74.783447] --- interrupt: c00
> >>> I'm in purgatory
> >>> [0.00] radix-mmu: Page sizes from device-tree:
> >>> [0.00] radix-mmu: Page size shift = 12 AP=0x0
> >>> [0.00] radix-mmu: Page size shift = 16 AP=0x5
> >>> [0.00] radix-mmu: Page size shift = 21 AP=0x1
> >>> [0.00] radix-mmu: Page size shift = 30 AP=0x2
> >>> [0.00] Activating Kernel Userspace Access Prevention
> >>> [0.00] Activating Kernel Userspace Execution Prevention
> >>> [0.00] radix-mmu: Mapped 0x-0x0001
> >>> with 64.0 KiB pages (exec)
> >>> [0.00] radix-mmu: Mapped 0x0001-0x0020
> >>> with 64.0 KiB pages
> >>> [0.00] radix-mmu: Mapped 0x0020-0x2000
> >>> with 2.00 MiB pages
> >>> [0.00] radix-mmu: Mapped 0x2000-0x2260
> >>> with 2.00 MiB pages (exec)
> >>> [0.00] radix-mmu: Mapped 0x2260-0x4000
> >>> with 2.00 MiB pages
> >>> [0.00] radix-mmu: Mapped 0x4000-0x00018000
> >>> with 1.00 GiB pages
> >>> [0.00] radix-mmu: Mapped 0x00018000-0x0001a000
> >>> with 2.00 MiB pages
> >>> [0.00] lpar: Using radix MMU under hypervisor
> >>> [0.00] Linux version 6.6.0-rc5pf-nr-cpus+
> >>> (r...@ltcever7x0-lp1.aus.stglabs.ibm.com) (gcc (GCC) 8.5.0 20210514 (Red
> >>> Hat 8.5.0-20), GNU ld version 2.30-123.el8) #3 SMP Mon Oct  9 11:07:
> >>> 41 CDT 2023
> >>> [0.00] Found initrd at 0xc00022e6:0xc000248f08d8
> >>> [0.00] Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200
> >>> 0xf06 of:IBM,FW1060.00 (NM1060_016) hv:phyp pSeries
> >>> [0.00] printk: bootconsole [udbg0] enabled
> >>> [0.00] the round shift between dt seq and the cpu logic number:
> >>> 56
> >>> [0.00] BUG: Unable to handle kernel data access on write at
> >>> 0xc001a000
> >>> [0.00] Faulting instruction address: 0xc00022009c64
> >>> [0.00] Oops: Kernel access of bad area, sig: 11 [#1]
> >>> [0.00] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
> >>> 

[PATCH v2] ASoC: fsl: Fix PM disable depth imbalance in fsl_easrc_probe

2023-10-12 Thread Zhang Shurong
The pm_runtime_enable will increase power disable depth. Thus
a pairing decrement is needed on the error handling path to
keep it balanced according to context. We fix it by calling
pm_runtime_disable when error returns.

Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
Signed-off-by: Zhang Shurong 
---
v1->v2: add Fixes tag

 sound/soc/fsl/fsl_easrc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index ba62995c909a..ec53bda46a46 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -1966,17 +1966,21 @@ static int fsl_easrc_probe(struct platform_device *pdev)
  _easrc_dai, 1);
if (ret) {
dev_err(dev, "failed to register ASoC DAI\n");
-   return ret;
+   goto err_pm_disable;
}
 
ret = devm_snd_soc_register_component(dev, _asrc_component,
  NULL, 0);
if (ret) {
dev_err(>dev, "failed to register ASoC platform\n");
-   return ret;
+   goto err_pm_disable;
}
 
return 0;
+
+err_pm_disable:
+   pm_runtime_disable(>dev);
+   return ret;
 }
 
 static void fsl_easrc_remove(struct platform_device *pdev)
-- 
2.30.2



Re: [Bisected] [1b4fa28a8b07] Build failure "net/core/gso_test.c"

2023-10-12 Thread Tasmiya Nalatwad

Greetings,

Thank you Florian. I have tried the changes suggested by you and it 
fixes the issue. With the suggested changes the problem is not seen.


On 10/12/23 15:27, Florian Westphal wrote:

.linear_len = GSO_TEST_SIZE,


--
Regards,
Tasmiya Nalatwad
IBM Linux Technology Center



Re: [Bisected] PowerMac G5 fails booting kernel 6.6-rc3 (BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe)

2023-10-12 Thread Michael Ellerman
Erhard Furtner  writes:
> Greetings!
>
> Kernel 6.5.5 boots fine on my PowerMac G5 11,2 but kernel 6.6-rc3 fails to 
> boot with following dmesg shown on the OpenFirmware console (transcribed 
> screenshot):
>
> [...]
> SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> rcu: Hierarchical RCU implementation.
>  Tracing variant of Tasks RCU enabled.
> rcu: RCU calculated value of scheduler-enlistment delay is 30 jiffies.
> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
> mpic: Setting up MPIC " MPIC 1   " version 1.2 at f804, max 2 CPUs
> mpic: ISU size: 124, shift: 7, mask: 7f
> mpic: Initializing for 124 sources
> mpic: Setting up HT PICs workarounds for U3/U4
> BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe
> Faulting instruction address: 0xc005dc40
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT  6.6.0-rc3-PMacGS #1
> Hardware name: PowerMac11,2 PPC970MP 0x440101 PowerMac
> NIP:  c005dc40 LR: c000 CTR: c0007730
> REGS: c22bf510 TRAP: 0380   Tainted: GT 
> (6.6.0-rc3-PMacGS)
> MSR:  90001032   CR: 44004242  XER: 
> IRQMASK: 3
> GPR00:  c22bf7b0 c10c0b00 01ac
> GPR04: 03c8 0300 c000f20001ae 0300
> GPR08: 0006 feffbb62ffec65ff 0001 
> GPR12: 90001032 c2362000 c0f76b80 0349ecd8
> GPR16: 02367ba8 02367f08 0006 
> GPR20: 01ac c0f6f920 c22cd985 000c
> GPR24: 0300 0003b0a3691d c0003e00803e 
> GPR28: c00c c000f20001ee feffbb62ffec65fe 01ac
> NIP [c005dc40] hash_page_do_lazy_icache+0x50/0x100
> LR [c000] __hash_page_4K+0x420/0x590
> Call Trace:
> [c22bf7e0] [] 0x
> [c22bf8c0] [c005e164] hash_page_mm+0x364/0x6f0
> [c22bf990] [c005e684] do_hash_fault+0x114/0x2b0
> [c22bf9c0] [c00078e8] data_access_common_virt+0x198/0x1f0
> --- interrupt: 300 at mpic_init+0x4bc/0x10c4
> NIP:  c2020a5c LR: c2020a04 CTR: 
> REGS: c22bf9f0 TRAP: 0300   Tainted: GT 
> (6.6.0-rc3-PMacGS)
> MSR:  90001032   CR: 24004248  XER: 
> DAR: c0003e00803e DSISR: 4000 IRQMASK: 1
> GPR00:  c22bfc90 c10c0b00 c0003e008030
> GPR04:    
> GPR08:  221b80894c06df2f  
> GPR12:  c2362000 c0f76b80 0349ecd8
> GPR16: 02367ba8 02367f08 02367c70 
> GPR20: 567ce25e8c9202b7 c0f6f920 0001 c0003e008030
> GPR24: c226f348 0004 c404c640 
> GPR28: c0003e008030 c404c000 45886d8559cb69b4 c22bfc90
> NIP [c005dc40] mpic_init+0x4bc/0x10c4
> LR [c000] mpic_init+0x464/0x10c4
> ~~~ interrupt: 300
> [c22bfd90] [c2022ae4] pmac_setup_one_mpic+0x258/0x2dc
> [c22bf2e0] [c2022df4] pmac_pic_init+0x28c/0x3d8
> [c22bfef0] [c200b750] init_IRQ+0x90/0x140
> [c22bff30] [c20053c0] start_kernel+0x57c/0x78c
> [c22bffe0] [c000cb48] start_here_common+0x1c/0x20
> Code: 0929 7c292040 4081007c fbc10020 3d220127 78843664 3929d700 ebc9 
> 7fde2214 e93e 712a0001 40820064  71232000 40820048 e93e
> ---[ end trace  ]---

Can you checkout the exact commit that crash is from and do:

 $ make arch/powerpc/mm/book3s64/hash_utils.lst

And paste/attach the content of that file.

cheers


Re: [PATCH v2 7/8] tty: Add SBI debug console support to HVC SBI driver

2023-10-12 Thread Björn Töpel
Anup Patel  writes:

> From: Atish Patra 
>
> RISC-V SBI specification supports advanced debug console
> support via SBI DBCN extension.
>
> Extend the HVC SBI driver to support it.
>
> Signed-off-by: Atish Patra 
> Signed-off-by: Anup Patel 
> ---
>  drivers/tty/hvc/Kconfig |  2 +-
>  drivers/tty/hvc/hvc_riscv_sbi.c | 76 ++---
>  2 files changed, 70 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
> index 4f9264d005c0..6e05c5c7bca1 100644
> --- a/drivers/tty/hvc/Kconfig
> +++ b/drivers/tty/hvc/Kconfig
> @@ -108,7 +108,7 @@ config HVC_DCC_SERIALIZE_SMP
>  
>  config HVC_RISCV_SBI
>   bool "RISC-V SBI console support"
> - depends on RISCV_SBI_V01
> + depends on RISCV_SBI
>   select HVC_DRIVER
>   help
> This enables support for console output via RISC-V SBI calls, which
> diff --git a/drivers/tty/hvc/hvc_riscv_sbi.c b/drivers/tty/hvc/hvc_riscv_sbi.c
> index 31f53fa77e4a..da318d7f55c5 100644
> --- a/drivers/tty/hvc/hvc_riscv_sbi.c
> +++ b/drivers/tty/hvc/hvc_riscv_sbi.c
> @@ -39,21 +39,83 @@ static int hvc_sbi_tty_get(uint32_t vtermno, char *buf, 
> int count)
>   return i;
>  }
>  
> -static const struct hv_ops hvc_sbi_ops = {
> +static const struct hv_ops hvc_sbi_v01_ops = {
>   .get_chars = hvc_sbi_tty_get,
>   .put_chars = hvc_sbi_tty_put,
>  };
>  
> -static int __init hvc_sbi_init(void)
> +static int hvc_sbi_dbcn_tty_put(uint32_t vtermno, const char *buf, int count)
>  {
> - return PTR_ERR_OR_ZERO(hvc_alloc(0, 0, _sbi_ops, 16));
> + phys_addr_t pa;
> + struct sbiret ret;
> +
> + if (is_vmalloc_addr(buf))
> + pa = page_to_phys(vmalloc_to_page(buf)) + offset_in_page(buf);

What is assumed from buf here? If buf is crossing a page, you need to
adjust the count, no?

> + else
> + pa = __pa(buf);
> +
> + if (IS_ENABLED(CONFIG_32BIT))
> + ret = sbi_ecall(SBI_EXT_DBCN, SBI_EXT_DBCN_CONSOLE_WRITE,
> + count, lower_32_bits(pa), upper_32_bits(pa),
> + 0, 0, 0);
> + else
> + ret = sbi_ecall(SBI_EXT_DBCN, SBI_EXT_DBCN_CONSOLE_WRITE,
> + count, pa, 0, 0, 0, 0);
> + if (ret.error)
> + return 0;
> +
> + return count;
>  }
> -device_initcall(hvc_sbi_init);
>  
> -static int __init hvc_sbi_console_init(void)
> +static int hvc_sbi_dbcn_tty_get(uint32_t vtermno, char *buf, int count)
>  {
> - hvc_instantiate(0, 0, _sbi_ops);
> + phys_addr_t pa;
> + struct sbiret ret;
> +
> + if (is_vmalloc_addr(buf))
> + pa = page_to_phys(vmalloc_to_page(buf)) + offset_in_page(buf);

And definitely adjust count here, if we're crossing a page!


Björn


Re: [PATCH v6 4/9] mm: thp: Introduce anon_orders and anon_always_mask sysfs files

2023-10-12 Thread Michael Ellerman
Andrew Morton  writes:
> On Sun, 08 Oct 2023 09:54:22 +1100 Michael Ellerman  
> wrote:
>
>> > I don't know why powerpc's PTE_INDEX_SIZE is variable.
>> 
>> To allow a single vmlinux to boot using either the Hashed Page Table
>> MMU, or Radix Tree MMU, which have different page table geometry.
>> 
>> That's a pretty crucial feature for distros, so that they can build a
>> single kernel to boot on Power8/9/10.
>
> Dumb question: why can't distros ship two kernels and have the boot
> loader (or something else) pick the appropriate one?

I'm not a grub expert, but AFAIK it doesn't support loading a different
kernel based on CPU/firwmare features. I'm quite sure it can't do that
on powerpc at least.

We also have another bootloader (petitboot) that is still supported by
some distros, and can't do that.

The other problem is like David says, distros are generally reluctant to
add new kernel configurations unless they absolutely have to. It adds
more work for them, more things to track, and can confuse users leading
to spurious bug reports.

cheers


Re: [Bisected] [1b4fa28a8b07] Build failure "net/core/gso_test.c"

2023-10-12 Thread Florian Westphal
Tasmiya Nalatwad  wrote:
> Greetings,
> 
> [net-next] [6.6-rc4] Build failure "net/core/gso_test.c"
> 
> --- Traces ---
> 
> make -j 33 -s && make modules_install && make install
> net/core/gso_test.c:58:48: error: initializer element is not constant
>    58 | .segs = (const unsigned int[]) { gso_size },
>   |    ^

Ouch, I can reproduce this with: gcc --version
gcc (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.

gcc 13.2.1 and clang-16.0.6 are ok.

Whats the preference here?  We could use simple preprocessor constant
or we could require much more recent compiler version for the net
kunit tests via kconfig.

gcc-12.2.0 can compile it after this simple s//g "fix":

diff --git a/net/core/gso_test.c b/net/core/gso_test.c
--- a/net/core/gso_test.c
+++ b/net/core/gso_test.c
@@ -4,7 +4,7 @@
 #include 
 
 static const char hdr[] = "abcdefgh";
-static const int gso_size = 1000;
+#define GSO_TEST_SIZE 1000
 
 static void __init_skb(struct sk_buff *skb)
 {
@@ -18,7 +18,7 @@ static void __init_skb(struct sk_buff *skb)
 
/* proto is arbitrary, as long as not ETH_P_TEB or vlan */
skb->protocol = htons(ETH_P_ATALK);
-   skb_shinfo(skb)->gso_size = gso_size;
+   skb_shinfo(skb)->gso_size = GSO_TEST_SIZE;
 }
 
 enum gso_test_nr {
@@ -53,70 +53,70 @@ static struct gso_test_case cases[] = {
{
.id = GSO_TEST_NO_GSO,
.name = "no_gso",
-   .linear_len = gso_size,
+   .linear_len = GSO_TEST_SIZE,
.nr_segs = 1,
-   .segs = (const unsigned int[]) { gso_size },
+   .segs = (const unsigned int[]) { GSO_TEST_SIZE },
},
{
.id = GSO_TEST_LINEAR,
.name = "linear",
-   .linear_len = gso_size + gso_size + 1,
+   .linear_len = GSO_TEST_SIZE + GSO_TEST_SIZE + 1,
.nr_segs = 3,
-   .segs = (const unsigned int[]) { gso_size, gso_size, 1 },
+   .segs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
1 },
},
{
.id = GSO_TEST_FRAGS,
.name = "frags",
-   .linear_len = gso_size,
+   .linear_len = GSO_TEST_SIZE,
.nr_frags = 2,
-   .frags = (const unsigned int[]) { gso_size, 1 },
+   .frags = (const unsigned int[]) { GSO_TEST_SIZE, 1 },
.nr_segs = 3,
-   .segs = (const unsigned int[]) { gso_size, gso_size, 1 },
+   .segs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
1 },
},
{
.id = GSO_TEST_FRAGS_PURE,
.name = "frags_pure",
.nr_frags = 3,
-   .frags = (const unsigned int[]) { gso_size, gso_size, 2 },
+   .frags = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
2 },
.nr_segs = 3,
-   .segs = (const unsigned int[]) { gso_size, gso_size, 2 },
+   .segs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
2 },
},
{
.id = GSO_TEST_GSO_PARTIAL,
.name = "gso_partial",
-   .linear_len = gso_size,
+   .linear_len = GSO_TEST_SIZE,
.nr_frags = 2,
-   .frags = (const unsigned int[]) { gso_size, 3 },
+   .frags = (const unsigned int[]) { GSO_TEST_SIZE, 3 },
.nr_segs = 2,
-   .segs = (const unsigned int[]) { 2 * gso_size, 3 },
+   .segs = (const unsigned int[]) { 2 * GSO_TEST_SIZE, 3 },
},
{
/* commit 89319d3801d1: frag_list on mss boundaries */
.id = GSO_TEST_FRAG_LIST,
.name = "frag_list",
-   .linear_len = gso_size,
+   .linear_len = GSO_TEST_SIZE,
.nr_frag_skbs = 2,
-   .frag_skbs = (const unsigned int[]) { gso_size, gso_size },
+   .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, 
GSO_TEST_SIZE },
.nr_segs = 3,
-   .segs = (const unsigned int[]) { gso_size, gso_size, gso_size },
+   .segs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE, 
GSO_TEST_SIZE },
},
{
.id = GSO_TEST_FRAG_LIST_PURE,
.name = "frag_list_pure",
.nr_frag_skbs = 2,
-   .frag_skbs = (const unsigned int[]) { gso_size, gso_size },
+   .frag_skbs = (const unsigned int[]) { GSO_TEST_SIZE, 
GSO_TEST_SIZE },
.nr_segs = 2,
-   .segs = (const unsigned int[]) { gso_size, gso_size },
+   .segs = (const unsigned int[]) { GSO_TEST_SIZE, GSO_TEST_SIZE },
},
{
/* commit 43170c4e0ba7: GRO of frag_list trains */
.id = GSO_TEST_FRAG_LIST_NON_UNIFORM,
.name = 

[powerpc] kernel BUG fs/xfs/xfs_message.c:102! [4k block]

2023-10-12 Thread Sachin Sant
While running xfstests on a IBM Power10 server having xfs file system with
4k block size following crash was seen

[ 1609.771548] run fstests xfs/238 at 2023-10-11 17:00:40
[ 1609.971214] XFS (sdb1): Mounting V5 Filesystem 
1105d60c-9514-4e7a-af6a-632d99bf06ea
[ 1609.980693] XFS (sdb1): Ending clean mount
[ 1609.982166] xfs filesystem being mounted at /mnt/test supports timestamps 
until 2038-01-19 (0x7fff)
[ 1610.024793] XFS (sdb2): Mounting V5 Filesystem 
60de8f0c-c80e-4a2a-b60a-f41a9cc0feca
[ 1610.030295] XFS (sdb2): Ending clean mount
[ 1610.031342] xfs filesystem being mounted at /mnt/scratch supports timestamps 
until 2038-01-19 (0x7fff)
[ 1610.087139] XFS: Assertion failed: bp->b_flags & XBF_DONE, file: 
fs/xfs/xfs_trans_buf.c, line: 241
[ 1610.087162] [ cut here ]
[ 1610.087165] kernel BUG at fs/xfs/xfs_message.c:102!
[ 1610.087168] Oops: Exception in kernel mode, sig: 5 [#1]
[ 1610.087171] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries
[ 1610.087175] Modules linked in: overlay dm_zero dm_thin_pool 
dm_persistent_data dm_bio_prison dm_snapshot dm_bufio loop dm_flakey xfs dm_mod 
nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 
nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack 
nf_defrag_ipv6 nf_defrag_ipv4 bonding rfkill ip_set tls nf_tables libcrc32c 
nfnetlink pseries_rng vmx_crypto ext4 mbcache jbd2 sd_mod t10_pi crc64_rocksoft 
crc64 sg ibmvscsi scsi_transport_srp ibmveth fuse [last unloaded: scsi_debug]
[ 1610.087220] CPU: 11 PID: 225897 Comm: kworker/11:46 Not tainted 
6.6.0-rc5-gb8b05bc6d83c #1
[ 1610.087224] Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf06 
of:IBM,FW1030.20 (NH1030_058) hv:phyp pSeries
[ 1610.087227] Workqueue: xfs-inodegc/sdb2 xfs_inodegc_worker [xfs]
[ 1610.087303] NIP: c00802857edc LR: c00802857ec8 CTR: 7fff
[ 1610.087306] REGS: c0002441b810 TRAP: 0700 Not tainted 
(6.6.0-rc5-gb8b05bc6d83c)
[ 1610.087309] MSR: 8282b033  CR: 
28000424 XER: 0007
[ 1610.087318] CFAR: c00802857d1c IRQMASK: 0 
[ 1610.087318] GPR00: c00802857ec8 c0002441bab0 c00802a68300 
ffea 
[ 1610.087318] GPR04: 000a c0002441b9b0  
c008016c6c40 
[ 1610.087318] GPR08: ffc0 0001  
c0080285a3a8 
[ 1610.087318] GPR12: c08311d0 c0117fff1b00 c0197de8 
c936bf40 
[ 1610.087318] GPR16:    
c009d16d48b0 
[ 1610.087318] GPR20: c00079e80205 c0001cb52f80 c0001cb52fc0 
8000 
[ 1610.087318] GPR24: 0001 c0002441bbc8 c000e77a7000 
c000209b7e00 
[ 1610.087318] GPR28: c0080279ae48 c008016b25f0 c0002441bc10 
c0002dabaee8 
[ 1610.087354] NIP [c00802857edc] assfail+0x54/0x74 [xfs]
[ 1610.087420] LR [c00802857ec8] assfail+0x40/0x74 [xfs]
[ 1610.087485] Call Trace:
[ 1610.087486] [c0002441bab0] [c00802857ec8] assfail+0x40/0x74 [xfs] 
(unreliable)
[ 1610.087551] [c0002441bb10] [c0080281cebc] 
xfs_trans_read_buf_map+0x384/0x590 [xfs]
[ 1610.087622] [c0002441bba0] [c0080279ae48] xfs_imap_to_bp+0x70/0xa8 
[xfs]
[ 1610.087691] [c0002441bbf0] [c0080280c3ec] 
xfs_inode_item_precommit+0x244/0x320 [xfs]
[ 1610.087760] [c0002441bc60] [c008027f3034] 
xfs_trans_run_precommits+0xac/0x160 [xfs]
[ 1610.087830] [c0002441bcb0] [c008027f45b0] 
__xfs_trans_commit+0x68/0x430 [xfs]
[ 1610.087900] [c0002441bd20] [c008027dfc30] 
xfs_inactive_ifree+0x158/0x2a0 [xfs]
[ 1610.087969] [c0002441bdb0] [c008027dff84] xfs_inactive+0x20c/0x420 
[xfs]
[ 1610.088037] [c0002441bdf0] [c008027ceb90] 
xfs_inodegc_worker+0x148/0x250 [xfs]
[ 1610.088106] [c0002441be40] [c0188130] 
process_scheduled_works+0x230/0x4f0
[ 1610.088113] [c0002441bf10] [c018b164] worker_thread+0x1e4/0x500
[ 1610.088118] [c0002441bf90] [c0197f18] kthread+0x138/0x140
[ 1610.088122] [c0002441bfe0] [c000df98] 
start_kernel_thread+0x14/0x18
[ 1610.088127] Code: e8a5ca38 7c641b78 3c62 e863ca48 f8010010 f821ffa1 
4bfffd91 3d22 e929ca50 89290010 2f89 419e0008 <0fe0> 0fe0 
38210060 e8010010 
[ 1610.088140] ---[ end trace  ]---
[ 1610.093928] sh (1070303): drop_caches: 3
[ 1610.095600] pstore: backend (nvram) writing error (-1)
[ 1610.095605]

xfs/238 test was executed when the crash was encountered.
Devices were formatted with 4k block size.

Running 'yes | mkfs -t xfs -f -b size=4096 -f /dev/sdb1'
meta-data=/dev/sdb1 isize=512 agcount=4, agsize=2621440 blks
 = sectsz=4096 attr=2, projid32bit=1
 = crc=1 finobt=1, sparse=1, rmapbt=0
 = reflink=1 bigtime=0 inobtcount=0
 data = bsize=4096 blocks=10485760, imaxpct=25
 = sunit=0 swidth=0 blks
 naming =version 2 bsize=4096 ascii-ci=0, ftype=1
 log =internal log bsize=4096 blocks=5120, version=2
 = sectsz=4096 

Re: [PATCH V2] tools/perf: Add perf binary dependent rule for shellcheck log in Makefile.perf

2023-10-12 Thread Athira Rajeev



> On 09-Oct-2023, at 10:38 AM, Namhyung Kim  wrote:
> 
> Hello,
> 
> Sorry for the late reply.
> 
> On Thu, Oct 5, 2023 at 8:27 AM Athira Rajeev
>  wrote:
>> 
>> 
>> 
>>> On 29-Sep-2023, at 12:19 PM, Athira Rajeev  
>>> wrote:
>>> 
>>> Add rule in new Makefile "tests/Makefile.tests" for running
>>> shellcheck on shell test scripts. This automates below shellcheck
>>> into the build.
>>> 
>>> $ for F in $(find tests/shell/ -perm -o=x -name '*.sh'); do shellcheck -S 
>>> warning $F; done
>>> 
>>> Condition for shellcheck is added in Makefile.perf to avoid build
>>> breakage in the absence of shellcheck binary. Update Makefile.perf
>>> to contain new rule for "SHELLCHECK_TEST" which is for making
>>> shellcheck test as a dependency on perf binary. Added
>>> "tests/Makefile.tests" to run shellcheck on shellscripts in
>>> tests/shell. The make rule "SHLLCHECK_RUN" ensures that, every
>>> time during make, shellcheck will be run only on modified files
>>> during subsequent invocations. By this, if any newly added shell
>>> scripts or fixes in existing scripts breaks coding/formatting
>>> style, it will get captured during the perf build.
>>> 
>>> Example build failure with present scripts in tests/shell:
>>> 
>>> INSTALL libsubcmd_headers
>>> INSTALL libperf_headers
>>> INSTALL libapi_headers
>>> INSTALL libsymbol_headers
>>> INSTALL libbpf_headers
>>> make[3]: *** 
>>> [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: 
>>> output/tests/shell/record_sideband.dep] Error 1
>>> make[3]: *** Waiting for unfinished jobs
>>> make[3]: *** 
>>> [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: 
>>> output/tests/shell/test_arm_coresight.dep] Error 1
>>> make[3]: *** 
>>> [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: 
>>> output/tests/shell/lock_contention.dep] Error 1
>>> make[2]: *** [Makefile.perf:675: SHELLCHECK_TEST] Error 2
>>> make[1]: *** [Makefile.perf:238: sub-make] Error 2
>>> make: *** [Makefile:70: all] Error 2
>>> 
>>> After this, for testing, changed "tests/shell/record.sh" to
>>> break shellcheck format. In the next make run, it is
>>> also captured:
> 
> Where can I see the actual failure messages?
Hi Namhyung,
Thanks for the review comments.

Example, with current tree, we have these format issues:

 GENSKEL /root/athira/linux/tools/perf/util/bpf_skel/kwork_trace.skel.h
CC bench/uprobe.o
CC util/header.o
LD bench/perf-in.o
make[3]: *** [/root/athira/linux/tools/perf/tests/Makefile.tests:17: 
output/tests/shell/stat_all_metricgroups.dep] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: *** [/root/athira/linux/tools/perf/tests/Makefile.tests:17: 
output/tests/shell/record_sideband.dep] Error 1
CC util/bpf_counter.o
CC util/bpf_counter_cgroup.o
CC util/bpf_ftrace.o
CC util/bpf_off_cpu.o
CC util/bpf-filter.o
make[3]: *** [/root/athira/linux/tools/perf/tests/Makefile.tests:15: 
output/tests/shell/test_arm_coresight.dep] Error 1
make[3]: *** [/root/athira/linux/tools/perf/tests/Makefile.tests:15: 
output/tests/shell/lock_contention.dep] Error 1
make[2]: *** [Makefile.perf:679: SHELLCHECK_TEST] Error 2
make[2]: *** Waiting for unfinished jobs
LD util/perf-in.o
LD perf-in.o
make[1]: *** [Makefile.perf:242: sub-make] Error 2
make: *** [Makefile:70: all] Error 2

The actual fail can be seen here:

# cat output/tests/shell/stat_all_metricgroups.dep.log 

In ./tests/shell/stat_all_metricgroups.sh line 7:
function ParanoidAndNotRoot()
^-- SC2112: 'function' keyword is non-standard. Delete it.

For more information:
https://www.shellcheck.net/wiki/SC2112 -- 'function' keyword is non-standar...
> 


>>> 
>>> make[3]: *** 
>>> [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: 
>>> output/tests/shell/record_sideband.dep] Error 1
>>> make[3]: *** Waiting for unfinished jobs
>>> make[3]: *** 
>>> [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: 
>>> output/tests/shell/record.dep] Error 1
>>> make[3]: *** 
>>> [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: 
>>> output/tests/shell/test_arm_coresight.dep] Error 1
>>> make[3]: *** 
>>> [/root/athira/namhyung/perf-tools-next/tools/perf/tests/Makefile.tests:17: 
>>> output/tests/shell/lock_contention.dep] Error 1
>>> make[2]: *** [Makefile.perf:675: SHELLCHECK_TEST] Error 2
>>> make[1]: *** [Makefile.perf:238: sub-make] Error 2
>>> make: *** [Makefile:70: all] Error 2
> 
> So is this reported at build time before I run the test command?
> I'm ok with that but maybe I need to build it even though I know
> some test is broken.  Can we have an option to do that like with
> `make NO_SHELLCHECK=1` ?

Yes, agree Namhyung. Valid point.
I will add that in V3

> 
>>> 
>>> Signed-off-by: Athira Rajeev 
>>> ---
>>> Changelog:
>>> v1 -> v2:
>>> Version1 had shellcheck in feature check which is not
>>> required since shellcheck is already a binary. Presence
>>> of binary can be checked using:
>>> $(shell 

Re: [PATCH v6 4/9] mm: thp: Introduce anon_orders and anon_always_mask sysfs files

2023-10-12 Thread David Hildenbrand

On 10.10.23 02:20, Andrew Morton wrote:

On Sun, 08 Oct 2023 09:54:22 +1100 Michael Ellerman  wrote:


I don't know why powerpc's PTE_INDEX_SIZE is variable.


To allow a single vmlinux to boot using either the Hashed Page Table
MMU, or Radix Tree MMU, which have different page table geometry.

That's a pretty crucial feature for distros, so that they can build a
single kernel to boot on Power8/9/10.


Dumb question: why can't distros ship two kernels and have the boot
loader (or something else) pick the appropriate one?


One answer I keep hearing over and over again is "test matrix 
explosion". So distros only do it when unavoidable: for example, when 
differing PAGE_SIZE is required (e.g., 4k vs 64k) or we're dealing with 
RT support (RT vs !RT).


--
Cheers,

David / dhildenb



[Bisected] [1b4fa28a8b07] Build failure "net/core/gso_test.c"

2023-10-12 Thread Tasmiya Nalatwad

Greetings,

[net-next] [6.6-rc4] Build failure "net/core/gso_test.c"

--- Traces ---

make -j 33 -s && make modules_install && make install
net/core/gso_test.c:58:48: error: initializer element is not constant
   58 | .segs = (const unsigned int[]) { gso_size },
  |    ^
net/core/gso_test.c:58:48: note: (near initialization for ‘cases[0]’)
net/core/gso_test.c:65:48: error: initializer element is not constant
   65 | .segs = (const unsigned int[]) { gso_size, 
gso_size, 1 },

  |    ^
net/core/gso_test.c:65:48: note: (near initialization for ‘cases[1]’)
net/core/gso_test.c:72:49: error: initializer element is not constant
   72 | .frags = (const unsigned int[]) { gso_size, 1 },
  | ^
net/core/gso_test.c:72:49: note: (near initialization for ‘cases[2]’)
net/core/gso_test.c:74:48: error: initializer element is not constant
   74 | .segs = (const unsigned int[]) { gso_size, 
gso_size, 1 },

  |    ^
net/core/gso_test.c:74:48: note: (near initialization for ‘cases[2]’)
net/core/gso_test.c:80:49: error: initializer element is not constant
   80 | .frags = (const unsigned int[]) { gso_size, 
gso_size, 2 },

  | ^
net/core/gso_test.c:80:49: note: (near initialization for ‘cases[3]’)
net/core/gso_test.c:82:48: error: initializer element is not constant
   82 | .segs = (const unsigned int[]) { gso_size, 
gso_size, 2 },

  |    ^
net/core/gso_test.c:82:48: note: (near initialization for ‘cases[3]’)
net/core/gso_test.c:89:49: error: initializer element is not constant
   89 | .frags = (const unsigned int[]) { gso_size, 3 },
  | ^
net/core/gso_test.c:89:49: note: (near initialization for ‘cases[4]’)
net/core/gso_test.c:91:48: error: initializer element is not constant
   91 | .segs = (const unsigned int[]) { 2 * gso_size, 3 },
  |    ^
net/core/gso_test.c:91:48: note: (near initialization for ‘cases[4]’)
net/core/gso_test.c:99:53: error: initializer element is not constant
   99 | .frag_skbs = (const unsigned int[]) { gso_size, 
gso_size },

  | ^
net/core/gso_test.c:99:53: note: (near initialization for ‘cases[5]’)
net/core/gso_test.c:101:48: error: initializer element is not constant
  101 | .segs = (const unsigned int[]) { gso_size, 
gso_size, gso_size },

  |    ^
net/core/gso_test.c:101:48: note: (near initialization for ‘cases[5]’)
net/core/gso_test.c:107:53: error: initializer element is not constant
  107 | .frag_skbs = (const unsigned int[]) { gso_size, 
gso_size },

  | ^
net/core/gso_test.c:107:53: note: (near initialization for ‘cases[6]’)
net/core/gso_test.c:109:48: error: initializer element is not constant
  109 | .segs = (const unsigned int[]) { gso_size, 
gso_size },

  |    ^
net/core/gso_test.c:109:48: note: (near initialization for ‘cases[6]’)
net/core/gso_test.c:117:53: error: initializer element is not constant
  117 | .frag_skbs = (const unsigned int[]) { gso_size, 
1, gso_size, 2 },

  | ^
net/core/gso_test.c:117:53: note: (near initialization for ‘cases[7]’)
net/core/gso_test.c:119:48: error: initializer element is not constant
  119 | .segs = (const unsigned int[]) { gso_size, 
gso_size, gso_size, 3 },

  |    ^
net/core/gso_test.c:119:48: note: (near initialization for ‘cases[7]’)
make[4]: *** [scripts/Makefile.build:243: net/core/gso_test.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[3]: *** [scripts/Makefile.build:480: net/core] Error 2
make[3]: *** Waiting for unfinished jobs

make[2]: *** [scripts/Makefile.build:480: net] Error 2
make[2]: *** Waiting for unfinished jobs
make[1]: *** [/root/net-next/Makefile:1913: .] Error 2
make: *** [Makefile:234: __sub-make] Error 2

gitbisect points to below commit, reverting the below commit resolves 
the issue


commit 1b4fa28a8b07eb331aeb7fbfc806c0d2e3dc3627
    net: parametrize skb_segment unit test to expand coverage

--
Regards,
Tasmiya Nalatwad
IBM Linux Technology Center



Re: [PATCH mm-unstable v9 14/31] s390: Convert various pgalloc functions to use ptdescs

2023-10-12 Thread Heiko Carstens
On Mon, Aug 07, 2023 at 04:04:56PM -0700, Vishal Moola (Oracle) wrote:
> As part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents, convert various page table functions to use ptdescs.
> 
> Some of the functions use the *get*page*() helper functions. Convert
> these to use pagetable_alloc() and ptdesc_address() instead to help
> standardize page tables further.
> 
> Acked-by: Mike Rapoport (IBM) 
> Signed-off-by: Vishal Moola (Oracle) 
> ---
>  arch/s390/include/asm/pgalloc.h |   4 +-
>  arch/s390/include/asm/tlb.h |   4 +-
>  arch/s390/mm/pgalloc.c  | 128 
>  3 files changed, 69 insertions(+), 67 deletions(-)
...
> diff --git a/arch/s390/mm/pgalloc.c b/arch/s390/mm/pgalloc.c
> index d7374add7820..07fc660a24aa 100644
> --- a/arch/s390/mm/pgalloc.c
> +++ b/arch/s390/mm/pgalloc.c
...
> @@ -488,16 +486,20 @@ static void base_pgt_free(unsigned long *table)
>  static unsigned long *base_crst_alloc(unsigned long val)
>  {
>   unsigned long *table;
> + struct ptdesc *ptdesc;
>  
> - table = (unsigned long *)__get_free_pages(GFP_KERNEL, CRST_ALLOC_ORDER);
> - if (table)
> - crst_table_init(table, val);
> + ptdesc = pagetable_alloc(GFP_KERNEL & ~__GFP_HIGHMEM, CRST_ALLOC_ORDER);

I guess I must miss something, but what is the reason to mask out
__GFP_HIGHMEM here? It is not part of GFP_KERNEL, nor does s390 support
HIGHMEM.