On Thu, May 23, 2024 at 11:35:37AM +0200, Johannes Berg wrote:
> On Fri, 2024-05-17 at 21:45 +0100, Simon Horman wrote:
> >
> > FWWIW, it seems unfortunate to me that the __counted_by field (n_channels)
> > is set some distance away from the allocation of the flex-array (channels)
> > whose bounds
Add an entry to make myself a maintainer of STM32 DMA controllers drivers
and documentation.
Signed-off-by: Amelie Delaunay
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d6c90161c7bf..e23cc6f644fa 100644
--- a/MAINTAINERS
+++ b/MAINT
The STM32 DMA3 is a Direct Memory Access controller with different features
depending on its hardware configuration.
The channels have not the same capabilities, some have a larger FIFO, so
their performance is higher.
This patch describes STM32 DMA3 bindings, used to select a channel that
fits cli
Gather the STM32 DMA controllers under drivers/dma/stm32/
Signed-off-by: Amelie Delaunay
---
drivers/dma/Kconfig| 34 ++-
drivers/dma/Makefile | 4 +--
drivers/dma/stm32/Kconfig | 37 ++
drivers/dma/s
STM32 DMA3 is a direct memory access controller with different features
depending on its hardware configuration. It is either called LPDMA (Low
Power), GPDMA (General Purpose) or HPDMA (High Performance), and it can
be found in new STM32 MCUs and MPUs.
In STM32MP25 SoC [1], 3 HPDMAs and 1 LPDMA ar
Gather the STM32 DMA controllers bindings under ./dma/stm32/.
Then fix reference to old path in spi/st,stm32-spi.yaml: update the dmas
property description by referring to all STM32 DMA controllers bindings.
Acked-by: Rob Herring (Arm)
Signed-off-by: Amelie Delaunay
---
v3:
- add Rob's Acked-by
STM32 DMA3 controller is able to suspend an ongoing transfer (the transfer
is suspended after the ongoing burst is flushed to the destination) and
resume it from the point it was suspended. No need to reconfigure any
register.
Signed-off-by: Amelie Delaunay
---
drivers/dma/stm32/stm32-dma3.c | 3
Add DMA_MEMCPY capability and relative device_prep_dma_memcpy ops with
stm32_dma3_prep_dma_memcpy(). It reuses stm32_dma3_chan_prep_hw() and
stm32_dma3_prep_hwdesc() helpers.
As this driver relies on both device_config and of_xlate ops to
pre-configure the channel for transfer, add a new helper
(st
Add DMA_CYCLIC capability and relative device_prep_dma_cyclic ops with
stm32_dma3_prep_dma_cyclic(). It reuses stm32_dma3_chan_prep_hw() and
stm32_dma3_chan_prep_hwdesc() helpers.
Signed-off-by: Amelie Delaunay
---
v4:
- remove MEM_TO_MEM comment: only DEV_TO_MEM and MEM_TO_DEV are supported
in
On STM32 DMA3, channels can be reserved, so they are non available for
Linux. This non-availability creates a mismatch between dma_chan id and
DMA3 channel id.
Use dma_async_device_channel_register() to register the channels
after controller registration and change the default channel name, so tha
The High Performance Direct Memory Access (HPDMA) controller is used to
perform programmable data transfers between memory-mapped peripherals
and memories (or between memories) via linked-lists.
There are 3 instances of HPDMA on stm32mp251, using stm32-dma3 driver, with
16 channels per instance an
Channel device name is used for sysfs, but also by dmatest filter function.
With dynamic channel registration, channels can be registered after dma
controller registration. Users may want to have specific channel names.
If name is NULL, the channel name relies on previous implementation,
dmachan.
Implement own device_tx_status ops to compute the residue with a finer
granularity, up to bytes.
STM32 DMA3 has a bitfield, BNDT, in CxTR1 register which reflects the
number of bytes read from the source.
It also has a bitfield, FIFOL, in CxSR register which reflects the FIFO
level in units of prog
STM32 DMA3 driver supports the 3 hardware configurations of the STM32 DMA3
controller:
- LPDMA (Low Power): 4 channels, no FIFO
- GPDMA (General Purpose): 16 channels, FIFO from 8 to 32 bytes
- HPDMA (High Performance): 16 channels, FIFO from 8 to 256 bytes
Hardware configuration of the channels is
Allow variable size indirection table allocation in MANA instead
of using a constant value MANA_INDIRECT_TABLE_SIZE.
The size is now derived from the MANA_QUERY_VPORT_CONFIG and the
indirection table is allocated dynamically.
Signed-off-by: Shradha Gupta
Reviewed-by: Dexuan Cui
Reviewed-by: Haiy
On Thu, May 30, 2024 at 09:23:36AM -0700, Jeff Johnson wrote:
> On 5/30/2024 8:42 AM, Nikolay Borisov wrote:
> >
> >
> > On 29.05.24 г. 21:09 ч., Jeff Johnson wrote:
> >> As discussed in [1] add a prototype for __fortify_panic() to fix the
> >> 'make W=1 C=1' warning:
> >>
> >> arch/x86/boot/comp
On Fri, May 24, 2024 at 03:43:33PM +0200, Vlastimil Babka wrote:
> On 4/24/24 11:41 PM, Kees Cook wrote:
> > Dedicated caches are available for fixed size allocations via
> > kmem_cache_alloc(), but for dynamically sized allocations there is only
> > the global kmalloc API's set of buckets availabl
On Fri, May 24, 2024 at 10:54:58AM -0400, Kent Overstreet wrote:
> On Wed, Apr 24, 2024 at 02:40:57PM -0700, Kees Cook wrote:
> > Hi,
> >
> > Series change history:
> >
> > v3:
> > - clarify rationale and purpose in commit log
> > - rebase to -next (CONFIG_CODE_TAGGING)
> > - simplify call
On Fri, May 24, 2024 at 03:38:58PM +0200, Vlastimil Babka wrote:
> On 4/24/24 11:40 PM, Kees Cook wrote:
> > To be able to choose which buckets to allocate from, make the buckets
> > available to the lower level kmalloc interfaces by adding them as the
> > first argument. Where the bucket is not av
On Fri, May 24, 2024 at 11:01:40AM -0400, Kent Overstreet wrote:
> On Wed, Apr 24, 2024 at 02:40:59PM -0700, Kees Cook wrote:
> > To be able to choose which buckets to allocate from, make the buckets
> > available to the lower level kmalloc interfaces by adding them as the
> > first argument. Where
On Fri, May 31, 2024 at 09:48:49AM -0700, Kees Cook wrote:
> On Fri, May 24, 2024 at 11:01:40AM -0400, Kent Overstreet wrote:
> > On Wed, Apr 24, 2024 at 02:40:59PM -0700, Kees Cook wrote:
> > > To be able to choose which buckets to allocate from, make the buckets
> > > available to the lower level
On Fri, May 31, 2024 at 09:48:49AM -0700, Kees Cook wrote:
> On Fri, May 24, 2024 at 11:01:40AM -0400, Kent Overstreet wrote:
> > On Wed, Apr 24, 2024 at 02:40:59PM -0700, Kees Cook wrote:
> > > To be able to choose which buckets to allocate from, make the buckets
> > > available to the lower level
On Thu, May 30, 2024 at 06:46:39PM +0200, Borislav Petkov wrote:
> On May 30, 2024 6:23:36 PM GMT+02:00, Jeff Johnson
> wrote:
> >On 5/30/2024 8:42 AM, Nikolay Borisov wrote:
> >>
> >>
> >> On 29.05.24 г. 21:09 ч., Jeff Johnson wrote:
> >>> As discussed in [1] add a prototype for __fortify_pani
On 5/31/2024 9:28 AM, Kees Cook wrote:
> On Thu, May 30, 2024 at 09:23:36AM -0700, Jeff Johnson wrote:
>> On 5/30/2024 8:42 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 29.05.24 г. 21:09 ч., Jeff Johnson wrote:
As discussed in [1] add a prototype for __fortify_panic() to fix the
'make W=1 C=
On Fri, May 31, 2024 at 11:28:58AM -0700, Jeff Johnson wrote:
> On 5/31/2024 9:28 AM, Kees Cook wrote:
> > On Thu, May 30, 2024 at 09:23:36AM -0700, Jeff Johnson wrote:
> >> On 5/30/2024 8:42 AM, Nikolay Borisov wrote:
> >>>
> >>>
> >>> On 29.05.24 \u0433. 21:09 \u0447., Jeff Johnson wrote:
>
__kmalloc_node() is considered an "internal" function to the Slab, so
drop it from explicit testing.
Signed-off-by: Kees Cook
---
Cc: Vlastimil Babka
Cc: linux...@kvack.org
Cc: linux-hardening@vger.kernel.org
---
lib/fortify_kunit.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/fort
On Fri, May 31, 2024 at 09:53:28AM -0700, Kees Cook wrote:
> Under CONFIG_FORTIFY_SOURCE, the boot code *does* still uses
> fortify-string.h. It lets us both catch mistakes we can discover at
> compile and will catch egregious runtime mistakes, though the reporting
> is much simpler in the boot cod
Introduce CONFIG_SLAB_BUCKETS which provides the infrastructure to
support separated kmalloc buckets (in the follow kmem_buckets_create()
patches and future codetag-based separation). Since this will provide
a mitigation for a very common case of exploits, enable it by default.
To be able to choos
Hi,
v4:
- Rebase to v6.10-rc1
- Add CONFIG_SLAB_BUCKETS to turn off the feature
v3: https://lore.kernel.org/lkml/20240424213019.make.366-k...@kernel.org/
v2: https://lore.kernel.org/lkml/20240305100933.it.923-k...@kernel.org/
v1: https://lore.kernel.org/lkml/20240304184252.work.496-k...@ke
Plumb kmem_buckets arguments through kvmalloc_node_noprof() so it is
possible to provide an API to perform kvmalloc-style allocations with
a particular set of buckets. Introduce kvmalloc_buckets_node() that takes a
kmem_buckets argument.
Signed-off-by: Kees Cook
---
Cc: Vlastimil Babka
Cc: Chris
Encapsulate the concept of a single set of kmem_caches that are used
for the kmalloc size buckets. Redefine kmalloc_caches as an array
of these buckets (for the different global cache buckets).
Signed-off-by: Kees Cook
---
Cc: Vlastimil Babka
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Ri
Dedicated caches are available for fixed size allocations via
kmem_cache_alloc(), but for dynamically sized allocations there is only
the global kmalloc API's set of buckets available. This means it isn't
possible to separate specific sets of dynamically sized allocations into
a separate collection
The msg subsystem is a common target for exploiting[1][2][3][4][5][6][7]
use-after-free type confusion flaws in the kernel for both read and write
primitives. Avoid having a user-controlled dynamically-size allocation
share the global kmalloc cache by using a separate set of kmalloc buckets
via the
Both memdup_user() and vmemdup_user() handle allocations that are
regularly used for exploiting use-after-free type confusion flaws in
the kernel (e.g. prctl() PR_SET_VMA_ANON_NAME[1] and setxattr[2][3][4]
respectively).
Since both are designed for contents coming from userspace, it allows
for use
On Fri, May 31, 2024 at 05:07:05PM +0200, Amelie Delaunay wrote:
> STM32 DMA3 driver supports the 3 hardware configurations of the STM32 DMA3
> controller:
> - LPDMA (Low Power): 4 channels, no FIFO
> - GPDMA (General Purpose): 16 channels, FIFO from 8 to 32 bytes
> - HPDMA (High Performance): 16 c
On Thu, May 30, 2024 at 01:24:56AM UTC, Andrew Cooper wrote:
> On 29/05/2024 3:20 am, Gatlin Newhouse wrote:
> > diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
> > index a3ec87d198ac..e3fbed9073f8 100644
> > --- a/arch/x86/include/asm/bug.h
> > +++ b/arch/x86/include/asm/bug.h
On Fri, May 31, 2024 at 09:08:16PM +0200, Borislav Petkov wrote:
> On Fri, May 31, 2024 at 09:53:28AM -0700, Kees Cook wrote:
> > Under CONFIG_FORTIFY_SOURCE, the boot code *does* still uses
> > fortify-string.h. It lets us both catch mistakes we can discover at
> > compile and will catch egregious
On Fri, May 31, 2024 at 01:46:37PM -0700, Kees Cook wrote:
> Please do not do this. It still benefits from compile-time sanity
> checking.
Care to elaborate how exactly it benefits?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, May 31, 2024 at 12:51:29PM -0400, Kent Overstreet wrote:
> On Fri, May 31, 2024 at 09:48:49AM -0700, Kees Cook wrote:
> > On Fri, May 24, 2024 at 11:01:40AM -0400, Kent Overstreet wrote:
> > > On Wed, Apr 24, 2024 at 02:40:59PM -0700, Kees Cook wrote:
> > > > To be able to choose which buck
On Fri, May 31, 2024 at 10:49:47PM +0200, Borislav Petkov wrote:
> On Fri, May 31, 2024 at 01:46:37PM -0700, Kees Cook wrote:
> > Please do not do this. It still benefits from compile-time sanity
> > checking.
>
> Care to elaborate how exactly it benefits?
Because when new code gets added that ac
On Fri, May 31, 2024 at 02:06:48PM -0700, Kees Cook wrote:
> ...
> or refactors and forgets to change some name, etc. It's all for catching
> bugs before they happen, etc. And when source string lengths aren't
> known, the runtime checking can kick in too.
Aha, thanks for explaining.
> It happens
On Fri, May 31, 2024 at 11:20:09PM +0200, Borislav Petkov wrote:
> So I get an allergic reaction everytime we wag the dog - i.e., fix the
> code because some tool or option can't handle it even if it is
> a perfectly fine code. In that case it is an unused symbol.
>
> And frankly, I'd prefer the s
On Fri, May 31, 2024 at 02:34:07PM -0700, Kees Cook wrote:
> On Fri, May 31, 2024 at 11:20:09PM +0200, Borislav Petkov wrote:
> > So I get an allergic reaction everytime we wag the dog - i.e., fix the
> > code because some tool or option can't handle it even if it is
> > a perfectly fine code. In t
On 5/31/2024 2:45 PM, Borislav Petkov wrote:
> On Fri, May 31, 2024 at 02:34:07PM -0700, Kees Cook wrote:
>> On Fri, May 31, 2024 at 11:20:09PM +0200, Borislav Petkov wrote:
>>> So I get an allergic reaction everytime we wag the dog - i.e., fix the
>>> code because some tool or option can't handle
c
@@ -510,4 +510,5 @@ static struct kunit_suite memcpy_test_suite = {
kunit_test_suite(memcpy_test_suite);
+MODULE_DESCRIPTION("test cases for memcpy(), memmove(), and memset()");
MODULE_LICENSE("GPL");
---
base-commit: b050496579632f86ee1ef7e7501906db579f3457
change-id: 20240531-md-lib-fortify_source-1cc75bded21f
mmit: b050496579632f86ee1ef7e7501906db579f3457
change-id: 20240531-md-lib-string-d987d813b344
t;);
MODULE_LICENSE("GPL v2");
---
base-commit: b050496579632f86ee1ef7e7501906db579f3457
change-id: 20240531-md-lib-test_ubsan-bca7f68a0707
Bring x86 to parity with arm64, similar to commit 25b84002afb9
("arm64: Support Clang UBSAN trap codes for better reporting").
Enable the output of UBSAN type information on x86 architectures
compiled with clang when CONFIG_UBSAN_TRAP=y. Currently ARM
architectures output which specific sanitizer c
48 matches
Mail list logo
