> From: Kees Cook
> [...]
> Subject: [PATCH] x86/uaccess: Fix missed zeroing of ia32 u64 get_user() range
> checking
>
> When reworking the range checking for get_user(), the get_user_8() case on
> 32-bit wasn't zeroing the high register. (The jump to bad_get_user_8 was
> accidentally dropped.) R
On Mon, Jun 10, 2024 at 02:02:27PM -0700, Kees Cook wrote:
> When reworking the range checking for get_user(), the get_user_8() case
> on 32-bit wasn't zeroing the high register. (The jump to bad_get_user_8
> was accidentally dropped.) Restore the correct error handling
> destination (and rename th
On Tue, 11 Jun 2024 at 05:02, Kees Cook wrote:
>
> When reworking the range checking for get_user(), the get_user_8() case
> on 32-bit wasn't zeroing the high register. (The jump to bad_get_user_8
> was accidentally dropped.) Restore the correct error handling
> destination (and rename the jump to
On Mon, 2024-06-10 at 10:07 +, Dhananjay Ugwekar wrote:
> 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 c
On Mon, 2024-06-10 at 10:07 +, Dhananjay Ugwekar wrote:
> 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 pa
On Thu, Jun 06, 2024 at 05:33:34PM +0100, Simon Horman wrote:
> On Wed, Jun 05, 2024 at 01:39:06AM -0700, Shradha Gupta wrote:
> > On Tue, Jun 04, 2024 at 10:33:49AM +0100, Simon Horman wrote:
> > > On Fri, May 31, 2024 at 08:37:41AM -0700, Shradha Gupta wrote:
> > > > Allow variable size indirecti
On Mon, Jun 10, 2024 at 10:05:44PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 10, 2024 at 10:28:52AM -0700, Kees Cook wrote:
> > On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote:
> > > Hi everyone,
> > >
> > > This is an effort to get rid of all multiplications from allocation
> > > fu
When reworking the range checking for get_user(), the get_user_8() case
on 32-bit wasn't zeroing the high register. (The jump to bad_get_user_8
was accidentally dropped.) Restore the correct error handling
destination (and rename the jump to using the expected ".L" prefix).
While here, switch to u
On Mon, Jun 10, 2024 at 10:28:52AM -0700, Kees Cook wrote:
> On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote:
> > Hi everyone,
> >
> > This is an effort to get rid of all multiplications from allocation
> > functions in order to prevent integer overflows [1][2].
>
> I didn't actually
On 10.06.24 8:23 PM, Kees Cook wrote:
> When a flexible array structure has a __counted_by annotation, its use
> with DEFINE_RAW_FLEX() will result in the count being zero-initialized.
> This is expected since one doesn't want to use RAW with a counted_by
> struct. Adjust the tests to check for t
On Sun, Jun 09, 2024 at 01:54:19PM +0900, Vincent Mailhol wrote:
> A new __counted_by() attribute was introduced in [1]. It makes the
> compiler's sanitizer aware of the actual size of a flexible array
> member, allowing for additional runtime checks.
>
> Apply the __counted_by() attribute to the
On Sun, Jun 09, 2024 at 01:54:18PM +0900, Vincent Mailhol wrote:
> A new __counted_by() attribute was introduced in [1]. It makes the
> compiler's sanitizer aware of the actual size of a flexible array
> member, allowing for additional runtime checks.
>
> Move the end of line comments to the previ
On Mon, Jun 10, 2024 at 11:23:05AM -0700, Kees Cook wrote:
> When a flexible array structure has a __counted_by annotation, its use
> with DEFINE_RAW_FLEX() will result in the count being zero-initialized.
> This is expected since one doesn't want to use RAW with a counted_by
> struct. Adjust the t
When a flexible array structure has a __counted_by annotation, its use
with DEFINE_RAW_FLEX() will result in the count being zero-initialized.
This is expected since one doesn't want to use RAW with a counted_by
struct. Adjust the tests to check for the condition and for compiler
support.
Reported
On pondělí 10. června 2024 17:17:42, SELČ Dhananjay Ugwekar wrote:
> Hello Oleksandr,
>
> On 6/10/2024 7:58 PM, Oleksandr Natalenko wrote:
> > Hello.
> >
> > On pondělí 10. června 2024 12:07:45, SELČ Dhananjay Ugwekar wrote:
> >> Currently the energy-cores event in the power PMU aggregates energy
On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote:
> Hi everyone,
>
> This is an effort to get rid of all multiplications from allocation
> functions in order to prevent integer overflows [1][2].
I didn't actually see these 3 patches in this thread nor via lore.
> In the first patch,
On Fri, 7 Jun 2024 16:54:41 -0300
"Guilherme G. Piccoli" wrote:
> Some code review in the patches themselves (like a missing
> EXPORT_SYMBOL_GPL), but all in all, that's a great addition! Feel free
> to add my:
>
> Tested-by: Guilherme G. Piccoli
Thanks a lot Guilherme! Much appreciated.
I'll
On Fri, Jun 07, 2024 at 04:54:41PM -0300, Guilherme G. Piccoli wrote:
> On 06/06/2024 12:01, Steven Rostedt wrote:
> > Reserve unspecified location of physical memory from kernel command line
> > [...]
> > Solution:
> >
> > The solution I have come up with is to introduce a new "reserve_mem=" kern
Hello Oleksandr,
On 6/10/2024 7:58 PM, Oleksandr Natalenko wrote:
> Hello.
>
> On pondělí 10. června 2024 12:07:45, SELČ Dhananjay Ugwekar wrote:
>> Currently the energy-cores event in the power PMU aggregates energy
>> consumption data at a package level. On the other hand the core energy
>> RAP
Hello.
On pondělí 10. června 2024 12:07:45, SELČ Dhananjay Ugwekar wrote:
> 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
> consumptio
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
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
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
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 cha
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 Sat, Jun 08, 2024 at 10:50:44AM +0200, Erick Archer wrote:
> Hi Andrew,
>
> On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote:
> > Hi everyone,
> >
> > This is an effort to get rid of all multiplications from allocation
> > functions in order to prevent integer overflows [1][2].
> >
On 1.06.24 г. 10:27 ч., Nikolay Borisov wrote:
On 31.05.24 г. 19:28 ч., 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 __for
30 matches
Mail list logo
