public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Andrea Cervesato <andrea.cervesato@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3] userfaultfd: Add test using UFFDIO_POISON
Date: Thu, 19 Feb 2026 12:24:13 +0100	[thread overview]
Message-ID: <aZby3eA2UvAnpWzd@yuki.lan> (raw)
In-Reply-To: <DGIUIYEL9H07.TK6CF1O2WP7H@suse.com>

Hi!
> > +	SAFE_PTHREAD_JOIN(thr, NULL);
> > +	reset_pages();
> 
> This should also go into a cleanup(), otherwise if other syscalls will
> fail (ioctl for instance), memory will be lost.

Technically all memory is released when last reference to it is removed,
which happens on process exit. So no mmaped() memory is not going to
leak.

> > +	if (poison_fault_seen && sigbus_seen) {
> > +		tst_res(TPASS, "POISON successfully triggered SIGBUS");
> > +	} else if (poison_fault_seen && !sigbus_seen) {
> > +		tst_res(TFAIL, "POISON fault seen but no SIGBUS received");
> > +	} else if (!poison_fault_seen && sigbus_seen) {
> > +		tst_res(TFAIL, "SIGBUS received but no poison fault seen");
> > +	} else {
> > +		tst_res(TFAIL, "No poison fault or SIGBUS observed");
> > +	}
> > +}
> > +
> > +static struct tst_test test = {
> > +	.test_all = run,
> > +	.min_kver = "6.6",
> 
> This is not needed, we should use UFFDIO_API instead, in order to verify
> that UFFD_FEATURE_POISON is present and eventually TCONF.
> 
> 
> Also, if I run checkpatch.pl on the code I get:
> 
> WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
> #25: FILE: userfaultfd06.c:25:
> +static volatile int poison_fault_seen;

For variables changed from a different thread atomic operation are
better than volatile, i.e. tst_atomic_load() and tst_atomic_store().

> WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
> #26: FILE: userfaultfd06.c:26:
> +static volatile int sigbus_seen;

This one is wrong, volatile is correct for variables changed for syscall
handlers.

> WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
> #88: FILE: userfaultfd06.c:88:
> +       volatile char dummy;

I do not think that volatile is needed here.

> WARNING: braces {} are not necessary for any arm of this statement
> #120: FILE: userfaultfd06.c:120:
> +       if (poison_fault_seen && sigbus_seen) {
> [...]
> +       } else if (poison_fault_seen && !sigbus_seen) {
> [...]
> +       } else if (!poison_fault_seen && sigbus_seen) {
> [...]
> +       } else {
> [...]
> 
> total: 0 errors, 4 warnings, 134 lines checked
> 
> NOTE: For some of the reported defects, checkpatch may be able to
>       mechanically convert to the typical style using --fix or --fix-inplace.
> 
> userfaultfd06.c has style problems, please review.
> 
> NOTE: If any of the errors are false positives, please report
>       them to the maintainer, see CHECKPATCH in MAINTAINERS.
> 
> If you have `b4`, please run `b4 prep --check` before sending the patch.
> 
> -- 
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com
> 
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  parent reply	other threads:[~2026-02-19 11:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-18 13:50 [LTP] [PATCH v3] userfaultfd: Add test using UFFDIO_POISON Ricardo Branco
2026-02-19  9:54 ` Andrea Cervesato via ltp
2026-02-19 11:21   ` Ricardo Branco
2026-02-19 11:34     ` Andrea Cervesato via ltp
2026-02-19 11:24   ` Cyril Hrubis [this message]
2026-02-19 11:28     ` Andrea Cervesato via ltp
2026-02-19 13:15       ` Cyril Hrubis
2026-02-19 11:37     ` Andrea Cervesato via ltp
2026-02-19 13:26     ` Ricardo Branco
2026-02-19 15:52       ` Cyril Hrubis

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=aZby3eA2UvAnpWzd@yuki.lan \
    --to=chrubis@suse.cz \
    --cc=andrea.cervesato@suse.com \
    --cc=ltp@lists.linux.it \
    /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