Hi Vladimir,
Le 19/02/2024 à 16:30, Vladimir Oltean a écrit :
> Hi Sean,
>
> On Thu, Feb 15, 2024 at 11:23:26AM -0500, Sean Anderson wrote:
>> smp_call_function_single disables IRQs when executing the callback. To
>> prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
>> This
On 2024-03-08 19:08:50 Fri, Michael Ellerman wrote:
> Aneesh Kumar K V writes:
> > On 3/7/24 5:13 PM, Michael Ellerman wrote:
> >> Mahesh Salgaonkar writes:
> >>> nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
> >>> crash when invoked during real mode interrupt
nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
interrupt handler) if percpu allocation comes from vmalloc area.
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()
wrapper
On Mon Apr 8, 2024 at 3:20 PM AEST, Michael Ellerman wrote:
> 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
Hi Adrian,
On Tue, 9 Apr 2024 09:26:39 +0300 Adrian Hunter
wrote:
>
> U64_MAX is not in include/vdso/limits.h, although that isn't noticed on x86
> because x86 includes include/linux/limits.h indirectly. However powerpc
> is more selective, resulting in the following build error:
>
> In
Hi Michael,
Thanks for your reply.
On Tue, Apr 9, 2024 at 4:46 PM Michael Ellerman wrote:
> Hi Lidong,
>
> Thanks for the patch.
>
> I'm not an expert on udev etc. so apologies if any of these questions
> are stupid.
>
> Lidong Zhong writes:
> > We have noticed the following nuisance messages
On Fri, Apr 05, 2024 at 05:42:44PM -0400, Peter Xu wrote:
> In short, hugetlb mappings shouldn't be special comparing to other huge pXd
> and large folio (cont-pXd) mappings for most of the walkers in my mind, if
> not all. I need to look at all the walkers and there can be some tricky
> ones,
Hi David,
> -Original Message-
> From: David Gstir
> Sent: Wednesday, April 3, 2024 12:51 PM
> To: Mimi Zohar ; James Bottomley
> ; Jarkko Sakkinen ; Herbert Xu
> ; David S. Miller
> Cc: David Gstir ; Shawn Guo ;
> Jonathan Corbet ; Sascha Hauer
> ; Pengutronix Kernel Team
> ; Fabio
Hi Jarkko,
> -Original Message-
> From: Jarkko Sakkinen
> Sent: Wednesday, April 3, 2024 9:18 PM
> To: David Gstir ; Mimi Zohar ;
> James Bottomley ; Herbert Xu
> ; David S. Miller
> Cc: Shawn Guo ; Jonathan Corbet
> ; Sascha Hauer ; Pengutronix
> Kernel Team ; Fabio Estevam
> ;
On Fri, 5 Apr 2024 09:20:41 +0200 Uwe Kleine-König wrote:
> 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:
On Tue, Apr 09, 2024 at 04:29:42PM +0800, David Gow wrote:
> > +ifeq ($(CCONFIG_KUNIT_SUPPRESS_BACKTRACE),y)
>
> s/CCONFIG_/CONFIG_/ ?
>
>
Odd, I know I tested this (and it still works ;-).
The additional "C" must have slipped in at some point.
Thanks for noticing!
Guenter
Hello Kshitiz,
On 09.04.24 12:54, Kshitiz Varshney wrote:
> Hi David,
>> + b->fmt_version = DCP_BLOB_VERSION;
>> + get_random_bytes(b->nonce, AES_KEYSIZE_128);
>> + get_random_bytes(b->blob_key, AES_KEYSIZE_128);
>
> We can use HWRNG instead of using kernel RNG. Please refer
>
On Mon, Apr 8, 2024 at 11:27 PM Adrian Hunter wrote:
>
> U64_MAX is not in include/vdso/limits.h, although that isn't noticed on x86
> because x86 includes include/linux/limits.h indirectly. However powerpc
> is more selective, resulting in the following build error:
>
> In file included from :
Michael Ellerman writes:
> Nathan Lynch via B4 Relay
> writes:
>>
>> plpar_hcall(), plpar_hcall9(), and related functions expect callers to
>> provide valid result buffers of certain minimum size. Currently this
>> is communicated only through comments in the code and the compiler has
>> no
On Wed, Apr 03, 2024 at 04:38:00PM +0800, Kefeng Wang wrote:
> The vm_flags of vma already checked under per-VMA lock, if it is a
> bad access, directly set fault to VM_FAULT_BADACCESS and handle error,
> no need to retry with mmap_lock again, the latency time reduces 34% in
> 'lat_sig -P 1 prot
On Wed, Apr 03, 2024 at 04:37:59PM +0800, Kefeng Wang wrote:
> The __do_page_fault() only calls handle_mm_fault() after vm_flags
> checked, and it is only called by do_page_fault(), let's squash
> it into do_page_fault() to cleanup code.
>
> Reviewed-by: Suren Baghdasaryan
> Signed-off-by:
On Wed, Mar 06 2024 at 20:52, Bitao Hu wrote:
> The soft lockup detector lacks a mechanism to identify interrupt storms
> as root cause of a lockup. To enable this the detector needs a
> mechanism to snapshot the interrupt count statistics on a CPU when the
> detector observes a potential lockup
On Tue, 9 Apr 2024 11:12:04 +0200
Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
Hi Ganesh,
Ganesh Goudar writes:
> When a device is hot removed on powernv, the hotplug
> driver clears the device's state. However, on pseries,
> if a device is removed by phyp after reaching the error
> threshold, the kernel remains unaware, leading to the
> device not being torn down. This
Nathan Chancellor writes:
> When building with LLVM_IAS=1, there is an error because
> '-fatal-warnings' is not recognized as a valid flag:
>
> clang: error: unsupported argument '-fatal-warnings' to option '-Wa,'
>
> Use the double hyphen version of the flag, '--fatal-warnings', which
> works
Kefeng Wang writes:
> The access_[pkey]_error() 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. In order to release the correct lock, pass the mm_struct into
> bad_access_pkey()/bad_access(), if mm is NULL,
Nathan Lynch via B4 Relay
writes:
> From: Nathan Lynch
>
> plpar_hcall(), plpar_hcall9(), and related functions expect callers to
> provide valid result buffers of certain minimum size. Currently this
> is communicated only through comments in the code and the compiler has
> no idea.
>
> For
Hi Lidong,
Thanks for the patch.
I'm not an expert on udev etc. so apologies if any of these questions
are stupid.
Lidong Zhong writes:
> We have noticed the following nuisance messages during boot
>
> [7.120610][ T1060] vio vio: uevent: failed to send synthetic uevent
> [7.122281][
On Wed, 3 Apr 2024 at 21:19, Guenter Roeck wrote:
>
> Document API functions for suppressing warning backtraces.
>
> Tested-by: Linux Kernel Functional Testing
> Acked-by: Dan Carpenter
> Reviewed-by: Kees Cook
> Signed-off-by: Guenter Roeck
> ---
This looks good to me: thanks for adding the
On Wed, 3 Apr 2024 at 21:19, Guenter Roeck wrote:
>
> Add unit tests to verify that warning backtrace suppression works.
>
> If backtrace suppression does _not_ work, the unit tests will likely
> trigger unsuppressed backtraces, which should actually help to get
> the affected architectures /
On Wed, 3 Apr 2024 at 21:19, Guenter Roeck wrote:
>
> Count suppressed warning backtraces to enable code which suppresses
> warning backtraces to check if the expected backtrace(s) have been
> observed.
>
> Using atomics for the backtrace count resulted in build errors on some
> architectures due
On Wed, 3 Apr 2024 at 21:19, Guenter Roeck wrote:
>
> Some unit tests intentionally trigger warning backtraces by passing
> bad parameters to API functions. Such unit tests typically check the
> return value from those calls, not the existence of the warning backtrace.
>
> Such intentionally
On Fri, Mar 22, 2024 at 06:02:05PM +0100, Vincent Guittot wrote:
> and then
> se->vruntime = max_vruntime(se->vruntime, vruntime)
>
First things first, I was wrong to assume a "boost" in the CFS code. So I
dug a bit deeper and tried to pinpoint what the difference between CFS and
EEVDF
U64_MAX is not in include/vdso/limits.h, although that isn't noticed on x86
because x86 includes include/linux/limits.h indirectly. However powerpc
is more selective, resulting in the following build error:
In file included from :
lib/vdso/gettimeofday.c: In function 'vdso_calc_ns':
Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made DMA/DMA32 zones span the entire RAM
when RAM starts above 32-bits. This breaks hardware with DMA area that
start above 32-bits. But the commit log says that "we haven't noticed
any such hardware". It
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use direct phys_addr_t limit address for DMA zone limit.
Following commits will add explicit base
of_dma_get_max_cpu_address() returns the highest CPU address that
devices can use for DMA. The implicit assumption is that all CPU
addresses below that limit are suitable for DMA. However the
'dma-ranges' property this code uses also encodes a lower limit for DMA
that is potentially non zero.
Verify that of_dma_get_cpu_limits() sets this new parameter to the
expected result.
Signed-off-by: Baruch Siach
---
drivers/of/unittest.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index
Current code using zone_dma_bits assume that all addresses range in the
bits mask are suitable for DMA. For some existing platforms this
assumption is not correct. DMA range might have non zero lower limit.
Add 'zone_dma_base' for platform code to set base address for DMA zone.
Rename the
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
The platform I have has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB -
36 matches
Mail list logo
