From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: "Maciej Wieczór-Retman" <maciej.wieczor-retman@intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Reinette Chatre <reinette.chatre@intel.com>,
fenghua.yu@intel.com
Subject: Re: [PATCH 1/3] selftests/resctrl: Fix schemata write error check
Date: Fri, 25 Aug 2023 11:43:22 +0300 (EEST) [thread overview]
Message-ID: <32f9983a-42e-7cce-8192-bba8bbb93955@linux.intel.com> (raw)
In-Reply-To: <c3yp5kkhrc75tvytkbmep7xknqgomyn52xpogqzsy3sp7kwefm@ikzmp6rgzisr>
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]
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.
next prev parent reply other threads:[~2023-08-25 8:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 12:41 [PATCH 0/3] selftests/resctrl: Bug fix and optimizations Wieczor-Retman, Maciej
2023-08-24 12:41 ` [PATCH 1/3] selftests/resctrl: Fix schemata write error check Wieczor-Retman, Maciej
2023-08-24 12:52 ` Ilpo Järvinen
2023-08-25 6:25 ` Maciej Wieczór-Retman
2023-08-25 8:43 ` Ilpo Järvinen [this message]
2023-08-25 8:50 ` Maciej Wieczór-Retman
2023-08-24 12:41 ` [PATCH 2/3] selftests/resctrl: Move run_benchmark() to a more fitting file Wieczor-Retman, Maciej
2023-08-24 12:56 ` Ilpo Järvinen
2023-08-25 6:26 ` Maciej Wieczór-Retman
2023-08-24 12:41 ` [PATCH 3/3] selftests: Add printf attribute to ksefltest prints Wieczor-Retman, Maciej
2023-08-24 13:10 ` Ilpo Järvinen
2023-08-25 6:34 ` Maciej Wieczór-Retman
2023-08-25 8:28 ` Ilpo Järvinen
2023-08-25 9:05 ` Maciej Wieczór-Retman
2023-08-25 9:14 ` Ilpo Järvinen
2023-08-25 9:16 ` Maciej Wieczór-Retman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32f9983a-42e-7cce-8192-bba8bbb93955@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.wieczor-retman@intel.com \
--cc=reinette.chatre@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox