linux-kernel - Re: [PATCH 1/3] selftests/resctrl: Fix schemata write error check

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]

Message-ID: <32f9983a-42e-7cce-8192-bba8bbb93955@linux.intel.com>
Date:   Fri, 25 Aug 2023 11:43:22 +0300 (EEST)
From:   Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To:     Maciej Wieczór-Retman 
        <maciej.wieczor-retman@...el.com>
cc:     LKML <linux-kernel@...r.kernel.org>,
        Reinette Chatre <reinette.chatre@...el.com>,
        fenghua.yu@...el.com
Subject: Re: [PATCH 1/3] selftests/resctrl: Fix schemata write error check

On Fri, 25 Aug 2023, Maciej Wieczór-Retman wrote:
> On 2023-08-24 at 15:52:05 +0300, Ilpo Järvinen wrote:
> >Ki,
> >
> >You're lacking a few people from the To/Cc list. Please see KERNEL 
> >SELFTEST FRAMEWORK entry in MAINTAINERS.
> 
> Thank you, I thought I checked the MAINTAINERS file well enough. I'll
> add them in the next version
> 
> >On Thu, 24 Aug 2023, Wieczor-Retman, Maciej wrote:
> >
> >> Writing bitmasks to the schemata can fail when the bitmask doesn't
> >> adhere to some constraints defined by what a particular CPU supports.
> >> Some example of constraints are max length or being having contiguous
> >
> >"being having" is not good English.
> 
> Thanks, I'll change it
> 
> >> bits. The driver should properly return errors when any rule concerning
> >> bitmask format is broken.
> >> 
> >> Resctrl FS returns error codes from fprintf() only when fclose() is
> >> called.
> >
> >I wonder if this is actually related to libc doing buffering between 
> >fprintf() and the actual write() syscall.
> 
> I started looking and apparently in the manpages for fclose [1] it says
> it uses fflush() to flush any buffered data in the stream. So that would
> probably confirm that it does buffering there.
> 
> In this case is there a situation when the fprintf() before fclose()
> would report an error? I'm thinking if there is a point to keep error
> checking after both function calls or just fclose(). 
>
> Or would putting additional fflush() after fprintf() make some sense?
> To have separate error checks for both function calls.

Another approach would be to use syscalls directly (open, write, and 
close to eliminate the buffering entirely. Given schema is already 
written into local variable first, it would be quite straightforward to do 
that conversion.


-- 
 i.