lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 19 Jun 2018 09:33:30 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     fenghua.yu@...el.com, tony.luck@...el.com,
        vikas.shivappa@...ux.intel.com, gavin.hindman@...el.com,
        jithu.joseph@...el.com, dave.hansen@...el.com, mingo@...hat.com,
        hpa@...or.com, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V6 07/38] x86/intel_rdt: Initialize new resource group
 with sane defaults

Hi Thomas,

On 6/19/2018 5:31 AM, Thomas Gleixner wrote:
> On Thu, 7 Jun 2018, Reinette Chatre wrote:
>> +/**
>> + * cbm_ensure_valid - Enforce validity on provided CBM
>> + * @_val:	Candidate CBM
>> + * @r:		RDT resource to which the CBM belongs
>> + *
>> + * The provided CBM represents all cache portions available for use. This
>> + * may be represented by a bitmap that does not consist of contiguous ones
>> + * and thus be an invalid CBM.
>> + * Here the provided CBM is forced to be a valid CBM by only considering
>> + * the first set of contiguous bits as valid and clearing all bits.
>> + * The intention here is to provide a valid default CBM with which a new
>> + * resource group is initialized. The user can follow this with a
>> + * modification to the CBM if the default does not satisfy the
>> + * requirements.
>> + */
>> +static void cbm_ensure_valid(u32 *_val, struct rdt_resource *r)
>> +{
>> +	unsigned long *val = (unsigned long *)_val;
> 
> I'm a bit worried about the u32 to unsigned long case here. I know that
> cbm_len cannot exceed 32, but still. At least it wants a comment.

Will do.

I am planning to add the following to the next version.

-->8--
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index bef736f6ba2f..7b4a09d81a30 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -2285,6 +2285,14 @@ static int mkdir_mondata_all(struct kernfs_node
*parent_kn,
  */
 static void cbm_ensure_valid(u32 *_val, struct rdt_resource *r)
 {
+	/*
+	 * Convert the u32 _val to an unsigned long required by all the bit
+	 * operations within this function. No more than 32 bits of this
+	 * converted value can be accessed because all bit operations are
+	 * additionally provided with cbm_len that is initialized during
+	 * hardware enumeration using five bits from the EAX register and
+	 * thus never can exceed 32 bits.
+	 */
 	unsigned long *val = (unsigned long *)_val;
 	unsigned int cbm_len = r->cache.cbm_len;
 	unsigned long first_bit, zero_bit;


Reinette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ