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-next>] [day] [month] [year] [list]
Date:   Wed, 19 Oct 2022 14:31:01 +0100
From:   Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-kernel@...r.kernel.org,
        "Intel-gfx@...ts.freedesktop.org" <Intel-gfx@...ts.freedesktop.org>,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>
Subject: Re: signal: break out of wait loops on kthread_stop()


Hi,

A question regarding a7c01fa93aeb ("signal: break out of wait loops on 
kthread_stop()") if I may.

We have a bunch code in i915, possibly limited to self tests (ie debug 
builds) but still important for our flows, which spawn kernel threads 
and exercises parts of the driver.

Problem we are hitting with this patch is that code did not really need 
to be signal aware until now. Well to say that more accurately - we were 
able to test the code which is normally executed from userspace, so is 
signal aware, but not worry about -ERESTARTSYS or -EINTR within the test 
cases itself.

For example threads which exercise an internal API for a while until the 
parent calls kthread_stop. Now those tests can hit unexpected errors.

Question is how to best approach working around this change. It is of 
course technically possible to rework our code in more than one way, 
although with some cost and impact already felt due reduced pass rates 
in our automated test suites.

Maybe an opt out kthread flag from this new behavior? Would that be 
acceptable as a quick fix? Or any other comments?

Regards,

Tvrtko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ