From: Christophe Leroy
[ Upstream commit e7e846dc6c73fbc94ae8b4ec20d05627646416f2 ]
Booting with CONFIG_DEBUG_VIRTUAL leads to following warning when
passing hugepage reservation on command line:
Kernel command line: hugepagesz=1g hugepages=1 hugepagesz=64m hugepages=1
hugepagesz=256m hugepa
From: Christophe Leroy
[ Upstream commit e7e846dc6c73fbc94ae8b4ec20d05627646416f2 ]
Booting with CONFIG_DEBUG_VIRTUAL leads to following warning when
passing hugepage reservation on command line:
Kernel command line: hugepagesz=1g hugepages=1 hugepagesz=64m hugepages=1
hugepagesz=256m hugepa
Le 12/10/2024 à 05:56, Luming Yu a écrit :
>> generic irq entry support via generic irqentry is added for powerpc.
>> There may be duplciate calls and missing callbacks requires further
>> work.
>>
>> Signed-off-by: Luming Yu
>
>This patch doesn't apply.
sorry to hear that. :-(
the ppc linux-c
From: Christophe Leroy
[ Upstream commit e7e846dc6c73fbc94ae8b4ec20d05627646416f2 ]
Booting with CONFIG_DEBUG_VIRTUAL leads to following warning when
passing hugepage reservation on command line:
Kernel command line: hugepagesz=1g hugepages=1 hugepagesz=64m hugepages=1
hugepagesz=256m hugepa
From: Shengjiu Wang
[ Upstream commit 72455e33173c1a00c0ce93d2b0198eb45d5f4195 ]
FCONT=1 means On FIFO error, the SAI will continue from the
same word that caused the FIFO error to set after the FIFO
warning flag has been cleared.
Set FCONT bit in control register to avoid the channel swap
issu
From: Christophe Leroy
[ Upstream commit e7e846dc6c73fbc94ae8b4ec20d05627646416f2 ]
Booting with CONFIG_DEBUG_VIRTUAL leads to following warning when
passing hugepage reservation on command line:
Kernel command line: hugepagesz=1g hugepages=1 hugepagesz=64m hugepages=1
hugepagesz=256m hugepa
On Sat, 12 Oct 2024 at 10:44, Linus Torvalds
wrote:
>
> Anyway, what's the speculation window size like?
Note that this is important basically because we do *NOT* want to
check the address against TASK_SIZE_MAX like we used to, because not
only is TASK_SIZE_MAX not a compile-time constant, but wi
On Sat, 12 Oct 2024 at 17:53, Linus Torvalds
wrote:
>
> So no, the address masking can not depend on things like
> __VIRTUAL_MASK_SHIFT, it would need to at least take LAM into account
> too. Not that I know if there are any CPU's out there that actually
> have LAM enabled.
Lunar Lake and Arrow L
On Sat, Oct 12, 2024 at 09:48:57AM +0100, Andrew Cooper wrote:
> On 12/10/2024 5:09 am, Josh Poimboeuf wrote:
> > For x86-64, the barrier_nospec() in copy_from_user() is overkill and
> > painfully slow. Instead, use pointer masking to force the user pointer
> > to a non-kernel value even in specul
On Wed, 09 Oct 2024 15:46:42 +0800, Shengjiu Wang wrote:
> add cs42888 codec support
>
> Chancel Liu (2):
> ASoC: imx-card: Set mclk for codec
> ASoC: imx-card: Add CS42888 support
>
> sound/soc/fsl/imx-card.c | 59 +++-
> 1 file changed, 52 insertions(+),
On 12/10/2024 3:09 pm, Josh Poimboeuf wrote:
> On Sat, Oct 12, 2024 at 09:48:57AM +0100, Andrew Cooper wrote:
>> On 12/10/2024 5:09 am, Josh Poimboeuf wrote:
>>> For x86-64, the barrier_nospec() in copy_from_user() is overkill and
>>> painfully slow. Instead, use pointer masking to force the user
On 12/10/2024 4:44 pm, Linus Torvalds wrote:
> On Sat, 12 Oct 2024 at 01:49, Andrew Cooper wrote:
>> You do realise mask_user_address() is unsafe under speculation on AMD
>> systems?
> That had *better* not be true.
Yeah I'd prefer it wasn't true either.
>> Had the mask_user_address() patch been
On Sat, 05 Oct 2024 10:53:29 +0200, Christophe Leroy wrote:
> Following OOPS is encountered while loading test_bpf module
> on powerpc 8xx:
>
> [ 218.835567] BUG: Unable to handle kernel data access on write at 0xcb00
> [ 218.842473] Faulting instruction address: 0xc0017a80
> [ 218.847451]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Linus,
Please pull another powerpc fix for 6.12:
The following changes since commit 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b:
Linux 6.12-rc2 (2024-10-06 15:32:27 -0700)
are available in the git repository at:
https://git.kernel.org/pub/sc
On Sat, Oct 12, 2024 at 09:09:23AM -0500, Josh Poimboeuf wrote:
> On Sat, Oct 12, 2024 at 09:48:57AM +0100, Andrew Cooper wrote:
> > On 12/10/2024 5:09 am, Josh Poimboeuf wrote:
> > > For x86-64, the barrier_nospec() in copy_from_user() is overkill and
> > > painfully slow. Instead, use pointer ma
On Sat, 12 Oct 2024 at 01:49, Andrew Cooper wrote:
>
> You do realise mask_user_address() is unsafe under speculation on AMD
> systems?
That had *better* not be true.
> Had the mask_user_address() patch been put for review, this feedback
> would have been given then.
That's BS.
Why? Look at co
On Sat, 12 Oct 2024 at 07:21, Borislav Petkov wrote:
>
> Commit
>
> 2865baf54077 ("x86: support user address masking instead of
> non-speculative conditional")
No.
Thos started long before. Again, see commit b19b74bc99b1 ("x86/mm:
Rework address range check in get_user() and put_user(
On Sat, 12 Oct 2024 at 10:23, Andrew Cooper wrote:
>>
> This logic is asymmetric.
>
> For an address in the upper half (canonical or non-canonical), it ORs
> with -1 and fully replaces the prior address.
Right. The point is that non-canonical addresses will fault, and
kernel addresses are guarant
Le 12/10/2024 à 05:56, Luming Yu a écrit :
generic irq entry support via generic irqentry is added for powerpc.
There may be duplciate calls and missing callbacks requires further
work.
Signed-off-by: Luming Yu
This patch doesn't apply.
Applying: powerpc/entry: add irqentry_state and gene
Le 11/10/2024 à 13:46, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 10/10/2024 à 11:12, Thomas Weißschuh a écrit :
I'll try to see why this doesn't work for ppc32.
PC-rel instructions only exist on very very recent powerpc CPUs (power10 ?)
Yeah power10 or later.
On PPC64,
On 12/10/2024 5:09 am, Josh Poimboeuf wrote:
> For x86-64, the barrier_nospec() in copy_from_user() is overkill and
> painfully slow. Instead, use pointer masking to force the user pointer
> to a non-kernel value even in speculative paths.
>
> Signed-off-by: Josh Poimboeuf
You do realise mask_us
21 matches
Mail list logo
