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:   Thu, 29 Dec 2022 22:17:48 +0200
From:   "Farber, Eliav" <farbere@...zon.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     <mchehab@...nel.org>, <tony.luck@...el.com>, <james.morse@....com>,
        <rric@...nel.org>, <linux-edac@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <talel@...zon.com>,
        <jonnyc@...zon.com>, <hhhawa@...zon.com>, <hanochu@...zon.com>,
        <itamark@...zon.com>, <shellykz@...zon.com>, <amitlavi@...zon.com>,
        <dkl@...zon.com>
Subject: Re: [PATCH v2] edac: fix period calculation in
 edac_device_reset_delay_period()

On 12/29/2022 5:23 PM, Borislav Petkov wrote:
> On Thu, Oct 20, 2022 at 12:44:58PM +0000, Eliav Farber wrote:
>> Fix period calculation in case user sets a value of 1000.
>> The input of round_jiffies_relative() should be in jiffies and not in
>> milli-seconds.
>>
>> Signed-off-by: Eliav Farber <farbere@...zon.com>
>
> Fixes: c4cf3b454eca ("EDAC: Rework workqueue handling")
>
> I guess.
>
> Also, I think the one-liner below does the same, no?

The one-liner below will not work.
See the comment in edac_device_workq_setup() that explains why round
is used:
"
optimize here for the 1 second case, which will be normal value, to
fire ON the 1 second time event. This helps reduce all sorts of
timers firing on sub-second basis, while they are happy
to fire together on the 1 second exactly
"
So only the first schedule should be rounded.
But all other schedules after that should be 1000ms.
When rounding jiffs and saving it in edac_dev->delay it means that all
future schedules will not be with the correct delay.

The fix I suggested is the same logic used in:
  - edac_device_workq_setup()
  - edac_device_workq_function()

--
Regards, Eliav


> ---
>
> diff --git a/drivers/edac/edac_device.c b/drivers/edac/edac_device.c
> index 19522c568aa5..88942a6edc2c 100644
> --- a/drivers/edac/edac_device.c
> +++ b/drivers/edac/edac_device.c
> @@ -399,7 +399,7 @@ void edac_device_reset_delay_period(struct 
> edac_device_ctl_info *edac_dev,
>        unsigned long jiffs = msecs_to_jiffies(value);
>
>        if (value == 1000)
> -               jiffs = round_jiffies_relative(value);
> +               jiffs = round_jiffies_relative(jiffs);
>
>        edac_dev->poll_msec = value;
>        edac_dev->delay     = jiffs;
>
> -- 
> Regards/Gruss,
>    Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ