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:   Wed, 17 Mar 2021 11:01:04 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Reinette Chatre <reinette.chatre@...el.com>,
        Bhaskar Chowdhury <unixbhaskar@...il.com>,
        fenghua.yu@...el.com, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, x86@...nel.org, hpa@...or.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kernel: cpu: resctrl: Minor typo fix in the file
 pseudo_lock.c

On 3/17/21 10:54 AM, Reinette Chatre wrote:
> Hi Bhaskar,
> 
> Thank you very much for catching this typo.
> 
> My feedback [1] to a previous patch from you applies here also. The prefix should be "x86/resctrl:" for contributions to this area.

Bhaskar,
Pretty much all of your patches need to have improved Subject: lines.
The file name that is being modified should not be at the end of the Subject.

> 
> [1] https://lore.kernel.org/lkml/7e3a5c13-db5c-7399-2b80-f1284786ea77@intel.com/
> 
> On 3/17/2021 1:40 AM, Bhaskar Chowdhury wrote:
>>
>> s/derefence/dereference/
>>
>> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@...il.com>
>> ---
>>   arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
>> index e916646adc69..43990a882b36 100644
>> --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
>> +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
>> @@ -1307,7 +1307,7 @@ int rdtgroup_pseudo_lock_create(struct rdtgroup *rdtgrp)
>>            * If the thread does not get on the CPU for whatever
>>            * reason and the process which sets up the region is
>>            * interrupted then this will leave the thread in runnable
>> -         * state and once it gets on the CPU it will derefence
>> +         * state and once it gets on the CPU it will dereference
>>            * the cleared, but not freed, plr struct resulting in an
>>            * empty pseudo-locking loop.
>>            */
>> -- 
>> 2.30.2
>>
> 
> Reinette


-- 
~Randy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ