On Thu, Jun 20, 2024 at 03:48:24PM -0700, Andi Kleen wrote:
> Kees Cook writes:
>
> > 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'
Kees Cook writes:
> 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 allocation
On Wed, Jun 19, 2024 at 11:13:22PM +0200, Javier Carrasco wrote:
> This case of the common error message upon failure of
> input_allocate_device() repeats the word "input".
>
> Drop one "input" from the error message.
>
> Signed-off-by: Javier Carrasco
Applied, thank you.
--
Dmitry
On Wed, Jun 19, 2024 at 11:13:21PM +0200, Javier Carrasco wrote:
> Use the __counted_by compiler attribute for the data[] flexible array
> member to improve the results of array bound sanitizers.
>
> Signed-off-by: Javier Carrasco
Applied, thank you.
--
Dmitry
Use the struct_size macro to calculate the size of the tll, which
includes a trailing flexible array.
Signed-off-by: Javier Carrasco
---
The memory allocation used to be carried out in two steps:
tll = devm_kzalloc(dev, sizeof(struct usbtll_omap), GFP_KERNEL);
tll->ch_clk = devm_kzalloc(dev, si
Use the __counted_by compiler attribute for the "struct clk *ch_clk[]"
flexible array member to improve the results of array bound sanitizers.
The comments for the variables are no longer needed as it is now clear
what is what.
Signed-off-by: Javier Carrasco
---
drivers/mfd/omap-usb-tll.c | 4 +
change-id: 20240620-omap-usb-tll-counted_by-aac57c173018
Best regards,
--
Javier Carrasco
On 6/20/24 8:46 PM, Kees Cook wrote:
> On Thu, Jun 20, 2024 at 03:37:31PM +0200, Vlastimil Babka wrote:
>> On 6/20/24 3:08 PM, Vlastimil Babka wrote:
>> > On 6/19/24 9:33 PM, Kees Cook wrote:
>> > I was wondering why I don't see the buckets in slabinfo and turns out it
>> > was
>> > SLAB_MERGE_DEF
On 6/20/24 8:54 PM, Kees Cook wrote:
> On Thu, Jun 20, 2024 at 03:56:27PM +0200, Vlastimil Babka wrote:
>> > @@ -549,6 +549,11 @@ void *kmem_cache_alloc_lru_noprof(struct kmem_cache
>> > *s, struct list_lru *lru,
>> >
>> > void kmem_cache_free(struct kmem_cache *s, void *objp);
>> >
>> > +kme
then match->n_channels updated here:
if (!match)
goto out_report_nd;
+ match->n_channels = n_channels;
Thanks for the explanation.
This is what I was looking for, and I missed this line.
Sorry for the noise.
No worries. Glad to help. :)
--
Gustavo
On Thu, Jun 20, 2024 at 10:58:49PM +0530, Anjali K wrote:
> However given that:
> (i) The dtl buffer is read-only. The dtl trace is a set of metrics which
> are collected to be read by privileged users.
> (ii)
On Fri, 31 May 2024 16:07:26 -0700, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/string_kunit.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/string_helpers_kunit.o
>
> Add the missing invocation of the MODULE_DE
On Thu, Jun 20, 2024 at 03:56:27PM +0200, Vlastimil Babka wrote:
> On 6/19/24 9:33 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 available
Le 20/06/2024 à 20:08, Gustavo A. R. Silva a écrit :
On 6/20/24 12:02, Gustavo A. R. Silva wrote:
My understanding is that 'match', is allocated by :
match = kzalloc(struct_size(match, channels, n_channels),
GFP_KERNEL);
So match->n_channels is *0* when iwl_mvm_query_set_freqs() is c
On Thu, Jun 20, 2024 at 03:08:32PM +0200, Vlastimil Babka wrote:
> On 6/19/24 9:33 PM, Kees Cook wrote:
> > Introduce CONFIG_SLAB_BUCKETS which provides the infrastructure to
> > support separated kmalloc buckets (in the following kmem_buckets_create()
> > patches and future codetag-based separatio
On Thu, Jun 20, 2024 at 03:37:31PM +0200, Vlastimil Babka wrote:
> On 6/20/24 3:08 PM, Vlastimil Babka wrote:
> > On 6/19/24 9:33 PM, Kees Cook wrote:
> > I was wondering why I don't see the buckets in slabinfo and turns out it was
> > SLAB_MERGE_DEFAULT. It would probably make sense for SLAB_MERGE
On Thu, Jun 20, 2024 at 11:47:58AM +0800, liuyuntao (F) wrote:
>
>
> On 2024/6/20 5:47, Kees Cook wrote:
> > An unintended consequence of commit 9c573cd31343 ("randomize_kstack:
> > Improve entropy diffusion") was that the per-architecture entropy size
> > filtering reduced how many bits were bei
On Tue, Jun 18, 2024 at 10:22:42AM +0200, Peter Zijlstra wrote:
> On Mon, Jun 17, 2024 at 10:28:20AM -0700, Kees Cook wrote:
>
> > But, using type attributes we have much more flexibility. Hence, the
> > proposed "wraps" attribute:
> > https://github.com/llvm/llvm-project/pull/86618
>
> So I stil
On 6/20/24 12:02, Gustavo A. R. Silva wrote:
My understanding is that 'match', is allocated by :
match = kzalloc(struct_size(match, channels, n_channels), GFP_KERNEL);
So match->n_channels is *0* when iwl_mvm_query_set_freqs() is called.
n_channels is updated in the line before calli
My understanding is that 'match', is allocated by :
match = kzalloc(struct_size(match, channels, n_channels), GFP_KERNEL);
So match->n_channels is *0* when iwl_mvm_query_set_freqs() is called.
n_channels is updated in the line before calling kzalloc():
n_channels = iwl_mvm_query_num_ma
Hi Kees
Thank you for your review.
On 17/06/24 23:29, Kees Cook wrote:
> On Fri, Jun 14, 2024 at 11:08:44PM +0530, Anjali K wrote:
>> Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
>> results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
>> shown below.
Le 19/06/2024 à 23:12, Kees Cook a écrit :
Both struct cfg80211_wowlan_nd_match and struct cfg80211_wowlan_nd_info
pre-allocate space for channels and matches, but then may end up using
fewer that the full allocation. Shrink the associated counter
(n_channels and n_matches) after counting the res
On 5/31/2024 4:07 PM, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/string_kunit.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/string_helpers_kunit.o
>
> Add the missing invocation of the MODULE_DESCRIPTION() ma
On 6/19/24 9:33 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 available. This means it isn't
> possible to separate specific sets of dynamically
On 6/20/24 3:08 PM, Vlastimil Babka wrote:
> On 6/19/24 9:33 PM, Kees Cook wrote:
> I was wondering why I don't see the buckets in slabinfo and turns out it was
> SLAB_MERGE_DEFAULT. It would probably make sense for SLAB_MERGE_DEFAULT to
> depends on !SLAB_BUCKETS now as the merging defeats the pur
On 6/19/24 9:33 PM, Kees Cook wrote:
> Introduce CONFIG_SLAB_BUCKETS which provides the infrastructure to
> support separated kmalloc buckets (in the following kmem_buckets_create()
> patches and future codetag-based separation). Since this will provide
> a mitigation for a very common case of expl
Add a new "power_per_core" PMU and "energy-per-core" event for
monitoring energy consumption by each core. The existing energy-cores
event aggregates the energy consumption at the package level.
This new event aligns with the AMD's per_core energy counters.
Tested the package level and core level
After making the rapl_model struct global, the rapl_msrs global
variable isn't needed, so remove it.
Also it will be cleaner when new per-core scope PMU is added. As we will
need to maintain two rapl_msrs array(one for per-core scope and one for
package scope PMU), inside the rapl_model struct.
S
Prep for addition of power_per_core PMU to handle core scope energy
consumption for AMD CPUs.
Replace the generic names with *_pkg*, to differentiate between the
scopes of the two different PMUs and their variables.
No functional change.
Signed-off-by: Dhananjay Ugwekar
---
arch/x86/events/rap
Prep for per-core RAPL PMU addition.
No functional change.
Signed-off-by: Dhananjay Ugwekar
---
arch/x86/events/rapl.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
index 70c7b35fb4d2..f815c60ec551 100644
---
This is in preparation for the addition of per-core RAPL counter support
for AMD CPUs.
The CPU online and offline functions will need to handle the setting up and
migration of the new per-core PMU as well. The wrapper functions added
below will make it easier to pass the corresponding args for bot
This patch is in preparation for addition of per-core energy counter
support for AMD CPUs.
Per-core energy counter PMU will need a separate cpumask. It seems like
a better approach to add the cpumask inside the rapl_pmus struct, instead
of creating another global cpumask variable for per-core PMU.
To support AMD's per_core RAPL counter, we will need to check
per_core capability of the current rapl_model multiple times in
rapl_cpu_online/offline, init_rapl_pmus functions, so cache the
matched rapl model in a global variable, to avoid calling
x86_match_cpu() multiple times.
No functional chan
Rename struct rapl_pmu variables from "pmu" to "rapl_pmu", to
avoid any confusion between the variables of two different
structs pmu and rapl_pmu. As rapl_pmu also contains a pointer to
struct pmu, which leads to situations in code like pmu->pmu,
which is needlessly confusing. Above scenario is rep
After commit ("x86/cpu/topology: Add support for the AMD 0x8026 leaf"),
on AMD processors that support extended CPUID leaf 0x8026, the
topology_die_cpumask() and topology_logical_die_id() macros, no longer
return the package cpumask and package id, instead they return the CCD
(Core Complex
Currently the energy-cores event in the power PMU aggregates energy
consumption data at a package level. On the other hand the core energy
RAPL counter in AMD CPUs has a core scope (which means the energy
consumption is recorded separately for each core). Earlier efforts to add
the core event in t
On Wed, Jun 19, 2024, at 23:47, Kees Cook wrote:
> An unintended consequence of commit 9c573cd31343 ("randomize_kstack:
> Improve entropy diffusion") was that the per-architecture entropy size
> filtering reduced how many bits were being added to the mix, rather than
> how many bits were being used
On Wed, Jun 19, 2024 at 02:47:15PM -0700, Kees Cook wrote:
> An unintended consequence of commit 9c573cd31343 ("randomize_kstack:
> Improve entropy diffusion") was that the per-architecture entropy size
> filtering reduced how many bits were being added to the mix, rather than
> how many bits were
On Wed, Jun 19, 2024 at 02:47:15PM -0700, Kees Cook wrote:
> An unintended consequence of commit 9c573cd31343 ("randomize_kstack:
> Improve entropy diffusion") was that the per-architecture entropy size
> filtering reduced how many bits were being added to the mix, rather than
> how many bits were
39 matches
Mail list logo
