linux-kernel - [PATCH 0/5] kmod: Cleanups, simplifications, and make isolation friendly v3

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]

Message-Id: <1438014440-20669-1-git-send-email-fweisbec@gmail.com>
Date:	Mon, 27 Jul 2015 18:27:15 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Christoph Lameter <cl@...ux.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH 0/5] kmod: Cleanups, simplifications, and make isolation friendly v3

This patchset does a bunch of cleanups and converts khelper to use
system unbound workqueues. The 3 first patches should be uncontroversial.
The last 2 patches are debatable.

Kmod creates kernel threads that perform userspace jobs and we want
those to have a large affinity in order not to contend busy CPUs. This
is (partly) why we use khelper which has a wide affinity that the kernel
threads it create can inherit from. Now khelper is a dedicated workqueue
that has singlethread properties which we aren't interested in.

Hence those two debatable changes:

_ We would like to use generic workqueues. System unbound workqueues are
  a very good candidate but they are not wide affine, only node affine.
  Now probably a node is enough to perform many parallel kmod jobs.

_ We would like to remove the wait_for_helper kernel thread (UMH_WAIT_PROC
  handler) to use the workqueue. It means that if the workqueue blocks,
  and no other worker can take pending kmod request, we can be screwed.
  Now if we have 512 threads, this should be enough.

I added Tejun to discuss these things.

Changes since v2, after Oleg reviews:

* Reordered patches such that the uncontroversial patches begin the
  queue and can be applied independantly.

* Tell about the need for workqueue also because we want a privileged
  (root) thread for usermodehelper job.

* Deactivate signal after UMH_WAIT_PROC handler.

* Update comment to handle the fact system unbound workqueues are node
  affine and not wide affine.

---
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
	nohz/kmod-v3

HEAD: 470ed6f10191864d28d2c8f4fd8a349ef58f427b

Thanks,
	Frederic
---

Frederic Weisbecker (5):
      kmod: Bunch of internal functions renames
      kmod: Remove unecessary explicit wide CPU affinity setting
      kmod: Add up-to-date explanations on the purpose of each asynchronous levels
      kmod: Use system_unbound_wq instead of khelper
      kmod: Handle UMH_WAIT_PROC from system unbound workqueue

 include/linux/kmod.h |  2 --
 init/main.c          |  1 -
 kernel/kmod.c        | 91 ++++++++++++++++++++++++++++------------------------
 3 files changed, 49 insertions(+), 45 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/