[PATCH v2] RISC-V: Clean up the Zicbom block size probing

Jessica Clarke jrtc27 at jrtc27.com
Mon Aug 15 10:36:14 PDT 2022


> On 15 Aug 2022, at 16:40, Nathan Chancellor <nathan at kernel.org> wrote:
> 
> Hi Palmer,
> 
> On Fri, Aug 12, 2022 at 08:40:10AM -0700, Palmer Dabbelt wrote:
>> This fixes two issues: I truncated the warning's hart ID when porting to
>> the 64-bit hart ID code, and the original code's warning handling could
>> fire on an uninitialized hart ID.
>> 
>> The biggest change here is that riscv_cbom_block_size is no longer
>> initialized, as IMO the default isn't sane: there's nothing in the ISA
>> that mandates any specific cache block size, so falling back to one will
>> just silently produce the wrong answer on some systems.  This also
>> changes the probing order so the cache block size is known before
>> enabling Zicbom support.
>> 
>> Fixes: 3aefb2ee5bdd ("riscv: implement Zicbom-based CMO instructions + the t-head variant")
>> Fixes: 1631ba1259d6 ("riscv: Add support for non-coherent devices using zicbom extension")
>> Reported-by: kernel test robot <lkp at intel.com>
>> Signed-off-by: Palmer Dabbelt <palmer at rivosinc.com>
>> 
>> ---
>> 
>> Changes since v1 <https://lore.kernel.org/all/20220812142400.7186-1-palmer@rivosinc.com/>:
>> 
>> * Everything but the unsigned long cbom_hartid.
>> ---
>> arch/riscv/kernel/setup.c       |  2 +-
>> arch/riscv/mm/dma-noncoherent.c | 22 ++++++++++++----------
>> 2 files changed, 13 insertions(+), 11 deletions(-)
>> 
>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
>> index 95ef6e2bf45c..2dfc463b86bb 100644
>> --- a/arch/riscv/kernel/setup.c
>> +++ b/arch/riscv/kernel/setup.c
>> @@ -296,8 +296,8 @@ void __init setup_arch(char **cmdline_p)
>> 	setup_smp();
>> #endif
>> 
>> -	riscv_fill_hwcap();
>> 	riscv_init_cbom_blocksize();
>> +	riscv_fill_hwcap();
>> 	apply_boot_alternatives();
>> }
>> 
>> diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
>> index cd2225304c82..3aa3572715d6 100644
>> --- a/arch/riscv/mm/dma-noncoherent.c
>> +++ b/arch/riscv/mm/dma-noncoherent.c
>> @@ -12,7 +12,7 @@
>> #include <linux/of_device.h>
>> #include <asm/cacheflush.h>
>> 
>> -static unsigned int riscv_cbom_block_size = L1_CACHE_BYTES;
>> +static unsigned int riscv_cbom_block_size;
>> static bool noncoherent_supported;
>> 
>> void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
>> @@ -80,37 +80,39 @@ void riscv_init_cbom_blocksize(void)
>> {
>> 	struct device_node *node;
>> 	int ret;
>> -	u32 val;
>> +	u32 val, probed_block_size;
>> 
>> +	probed_block_size = 0;
>> 	for_each_of_cpu_node(node) {
>> -		unsigned long hartid;
>> -		int cbom_hartid;
>> +		unsigned long hartid, cbom_hartid;
>> 
>> 		ret = riscv_of_processor_hartid(node, &hartid);
>> 		if (ret)
>> 			continue;
>> 
>> -		if (hartid < 0)
>> -			continue;
>> -
>> 		/* set block-size for cbom extension if available */
>> 		ret = of_property_read_u32(node, "riscv,cbom-block-size", &val);
>> 		if (ret)
>> 			continue;
>> 
>> -		if (!riscv_cbom_block_size) {
>> -			riscv_cbom_block_size = val;
>> +		if (!probed_block_size) {
>> +			probed_block_size = val;
>> 			cbom_hartid = hartid;
>> 		} else {
>> -			if (riscv_cbom_block_size != val)
>> +			if (probed_block_size != val)
>> 				pr_warn("cbom-block-size mismatched between harts %d and %lu\n",
> 
>                                                                  ^ %lu?
> 
>> 					cbom_hartid, hartid);
>> 		}
>> 	}
>> +
>> +	if (probed_block_size)
>> +		riscv_cbom_block_size = probed_block_size;
>> }
>> #endif
>> 
>> void riscv_noncoherent_supported(void)
>> {
>> +	WARN_ON(!riscv_cbom_block_size,
>> +	        "Non-coherent DMA support enabled without a block size\n");
>> 	noncoherent_supported = true;
>> }
>> -- 
>> 2.34.1
> 
> For what it's worth, while this should address the uninitialized
> cbom_hartid at runtime (from the quick glance I gave it), it doesn't
> address the compile time warning. I am not sure how to make it clear to
> clang that the if statement will be executed during the first loop
> iteration because probed_block_size is initialized to zero...

The warnings are correct; the variables are declared inside the body,
as I pointed out on IRC when people were discussing the function.

Jess

> Additionally, it appears that WARN() is the right macro, not WARN_ON()
> and an '#include <asm/bug.h>' is needed.
> 
>  arch/riscv/mm/dma-noncoherent.c:104:6: error: variable 'cbom_hartid' is uninitialized when used here [-Werror,-Wuninitialized]
>                                          cbom_hartid, hartid);
>                                          ^~~~~~~~~~~
>  include/linux/printk.h:517:37: note: expanded from macro 'pr_warn'
>          printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
>                                             ^~~~~~~~~~~
>  include/linux/printk.h:464:60: note: expanded from macro 'printk'
>  #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
>                                                             ^~~~~~~~~~~
>  include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
>                  _p_func(_fmt, ##__VA_ARGS__);                           \
>                                  ^~~~~~~~~~~
>  arch/riscv/mm/dma-noncoherent.c:87:36: note: initialize the variable 'cbom_hartid' to silence this warning
>                  unsigned long hartid, cbom_hartid;
>                                                   ^
>                                                    = 0
>  arch/riscv/mm/dma-noncoherent.c:116:10: error: too many arguments provided to function-like macro invocation
>                  "Non-coherent DMA support enabled without a block size\n");
>                  ^
>  include/asm-generic/bug.h:121:9: note: macro 'WARN_ON' defined here
>  #define WARN_ON(condition) ({                                           \
>          ^
>  arch/riscv/mm/dma-noncoherent.c:115:2: error: use of undeclared identifier 'WARN_ON'
>          WARN_ON(!riscv_cbom_block_size,
>          ^
>  3 errors generated.
> 
> Cheers,
> Nathan
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv




More information about the linux-riscv mailing list