On Mon, Nov 20, 2023 at 07:34:15PM +0100, Vlastimil Babka wrote:
> Some struct slab fields are initialized differently for SLAB and SLUB so
> we can simplify with SLUB being the only remaining allocator.
>
> Reviewed-by: Kees Cook
> Reviewed-by: Marco Elver
> Signed-off-by: Vlastimil Babka
> --
On Mon, Nov 20, 2023 at 07:34:16PM +0100, Vlastimil Babka wrote:
> With SLAB removed, these are never true anymore so we can clean up.
>
> Reviewed-by: Kees Cook
> Acked-by: Michal Hocko
> Signed-off-by: Vlastimil Babka
> ---
> mm/memcontrol.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 de
On Mon, Nov 20, 2023 at 07:34:17PM +0100, Vlastimil Babka wrote:
> The CPUHP_SLAB_PREPARE hooks are only used by SLAB which is removed.
> SLUB defines them as NULL, so we can remove those altogether.
>
> Signed-off-by: Vlastimil Babka
> ---
> include/linux/cpuhotplug.h | 1 -
> include/linux/sla
On Mon, Nov 20, 2023 at 07:34:18PM +0100, Vlastimil Babka wrote:
> In slab_common.c and slab.h headers, we can now remove all code behind
> CONFIG_SLAB and CONFIG_DEBUG_SLAB ifdefs, and remove all CONFIG_SLUB
> ifdefs.
>
> Reviewed-by: Kees Cook
> Signed-off-by: Vlastimil Babka
> ---
> include/
On Mon, Nov 20, 2023 at 07:34:19PM +0100, Vlastimil Babka wrote:
> CONFIG_DEBUG_SLAB is going away with CONFIG_SLAB, so remove dead ifdefs
> in mempool and dmapool code.
>
> Reviewed-by: Kees Cook
> Signed-off-by: Vlastimil Babka
> ---
> mm/dmapool.c | 2 +-
> mm/mempool.c | 6 +++---
> 2 files
On Mon, Nov 20, 2023 at 07:34:20PM +0100, Vlastimil Babka wrote:
> Remove the SLAB implementation. Update CREDITS.
> Also update and properly sort the SLOB entry there.
>
> RIP SLAB allocator (1996 - 2024)
>
> Reviewed-by: Kees Cook
> Signed-off-by: Vlastimil Babka
> ---
> CREDITS
On Mon, Nov 20, 2023 at 07:34:21PM +0100, Vlastimil Babka wrote:
> Nothing outside SLUB itself accesses the struct kmem_cache_cpu fields so
> it does not need to be declared in slub_def.h. This allows also to move
> enum stat_item.
>
> Reviewed-by: Kees Cook
> Signed-off-by: Vlastimil Babka
> --
On 12/6/23 10:31, Hyeonggon Yoo wrote:
> On Mon, Nov 20, 2023 at 07:34:20PM +0100, Vlastimil Babka wrote:
>> Remove the SLAB implementation. Update CREDITS.
>> Also update and properly sort the SLOB entry there.
>>
>> RIP SLAB allocator (1996 - 2024)
>>
>> Reviewed-by: Kees Cook
>> Signed-off-by
On Mon, Nov 20, 2023 at 07:34:22PM +0100, Vlastimil Babka wrote:
> mm/slab.h is the only place to include include/linux/slub_def.h which
> has allowed switching between SLAB and SLUB. Now we can simply move the
> contents over and remove slub_def.h.
>
> Use this opportunity to fix up some whitespa
It's required to not free the memory underlying a requested PWM
while a consumer still has a reference to it. While currently a pwm_chip
doesn't life long enough in all cases, linking the struct pwm to the
pwm_chip results in the right lifetime as soon as the pwmchip is living
long enough. This hap
On 11/30/23 05:33, Peter Zijlstra wrote:
> On Wed, Nov 29, 2023 at 03:07:15PM -0600, Madhavan T. Venkataraman wrote:
>
>> Kernel Lockdown
>> ---
>>
>> But, we must provide at least some security in V2. Otherwise, it is useless.
>>
>> So, we have implemented what we call a kernel loc
On 11/30/23 18:45, Edgecombe, Rick P wrote:
> On Wed, 2023-11-29 at 15:07 -0600, Madhavan T. Venkataraman wrote:
>> Threat Model
>>
>>
>> In the threat model in Heki, the attacker is a user space attacker
>> who exploits
>> a kernel vulnerability to gain more privileges or bypass th
On Wed, Dec 06, 2023 at 10:37:33AM -0600, Madhavan T. Venkataraman wrote:
>
>
> On 11/30/23 05:33, Peter Zijlstra wrote:
> > On Wed, Nov 29, 2023 at 03:07:15PM -0600, Madhavan T. Venkataraman wrote:
> >
> >> Kernel Lockdown
> >> ---
> >>
> >> But, we must provide at least some securi
The return value from nla_len() is never expected to be negative, and can
never be more than struct nlattr::nla_len (a u16). Adjust the prototype
on the function. This will let GCC's value range optimization passes
know that the return can never be negative, and can never be larger than
u16. As rec
On Mon, Nov 20, 2023 at 07:34:23PM +0100, Vlastimil Babka wrote:
> The #include's are scattered at several places of the file, but it does
> not seem this is needed to prevent any include loops (anymore?) so
> consolidate them at the top. Also move the misplaced kmem_cache_init()
> declaration away
On Mon, Nov 20, 2023 at 07:34:24PM +0100, Vlastimil Babka wrote:
> We don't share the hooks between two slab implementations anymore so
> they can be moved away from the header. As part of the move, also move
> should_failslab() from slab_common.c as the pre_alloc hook uses it.
> This means slab.h
On Mon, Nov 20, 2023 at 07:34:25PM +0100, Vlastimil Babka wrote:
> We don't share those between SLAB and SLUB anymore, so most memcg
> related functions can be moved to slub.c proper.
>
> Reviewed-by: Kees Cook
> Acked-by: Michal Hocko
> Signed-off-by: Vlastimil Babka
> ---
> mm/slab.h | 206
On Mon, Nov 20, 2023 at 07:34:26PM +0100, Vlastimil Babka wrote:
> The declaration and associated helpers are not used anywhere else
> anymore.
>
> Reviewed-by: Kees Cook
> Signed-off-by: Vlastimil Babka
> ---
> mm/slab.h | 29 -
> mm/slub.c | 27
On Mon, Nov 20, 2023 at 07:34:28PM +0100, Vlastimil Babka wrote:
> In preparation for the next patch, move the kmalloc_slab() function to
> the header, as it will have callers from two files, and make it inline.
> To avoid unnecessary bloat, remove all size checks/warnings from
> kmalloc_slab() as
On Mon, Nov 20, 2023 at 07:34:29PM +0100, Vlastimil Babka wrote:
> This will eliminate a call between compilation units through
> __kmem_cache_alloc_node() and allow better inlining of the allocation
> fast path.
>
> Reviewed-by: Kees Cook
> Signed-off-by: Vlastimil Babka
> ---
> mm/slab.h
On Mon, Nov 20, 2023 at 07:34:30PM +0100, Vlastimil Babka wrote:
> slab_alloc() is a thin wrapper around slab_alloc_node() with only one
> caller. Replace with direct call of slab_alloc_node().
> __kmem_cache_alloc_lru() itself is a thin wrapper with two callers,
> so replace it with direct calls
On Mon, Nov 20, 2023 at 07:34:31PM +0100, Vlastimil Babka wrote:
> With allocation fastpaths no longer divided between two .c files, we
> have better inlining, however checking the disassembly of
> kmem_cache_alloc() reveals we can do better to make the fastpaths
> smaller and move the less common
On Mon, Nov 20, 2023 at 07:34:32PM +0100, Vlastimil Babka wrote:
> Inspection of kmem_cache_free() disassembly showed we could make the
> fast path smaller by providing few more hints to the compiler, and
> splitting the memcg_slab_free_hook() into an inline part that only
> checks if there's work
On Mon, Nov 20, 2023 at 07:34:11PM +0100, Vlastimil Babka wrote:
> Changes from v1:
> - Added new Patch 01 to fix up kernel docs build (thanks Marco Elver)
> - Additional changes to Kconfig user visible texts in Patch 02 (thanks Kees
> Cook)
> - Whitespace fixes and other fixups (thanks Kees)
>
On Tue, Dec 05, 2023 at 01:39:47PM -0800, Nick Desaulniers wrote:
> Hmm...how does one know that linux/bits.h is the higher-level include
> of asm/bitsperlong.h?
I think this the wrong way of thinking. In general we should always
avoid including asm/ headers unless there is no other way. No othe
25 matches
Mail list logo
