linux-kernel - Re: [PATCH] sched: Transform resched_task() into resched

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:	Sun, 29 Jun 2014 09:20:59 +0200
From:	Andreas Mohr <andi@...as.de>
To:	Kirill Tkhai <tkhai@...dex.ru>
Cc:	linux-kernel@...r.kernel.org, peterz@...radead.org,
	tkhai@...dex.ru, mingo@...hat.com
Subject: Re: [PATCH] sched: Transform resched_task() into resched_curr()

Hi,

I cannot speak too much about scheduler specifics, but from a structural POV
I'm unsure about such a change (into this direction).

We seem to be going from a nicely fine-grained function
(task-struct-specific, and thus operating on task scope alone,
except for interesting lockdep_assert_held() outer-env validation-only parts)
to one which has a *broader* scope (namely, wholly rq-parameterized),
thus now drawing the rq dependency into the equation:
this patch introduces access to rq->curr specifics *within
function implementation* (as the first measure within a function,
which in itself might be considered a smell),
and it needlessly widens the scope of concerns of this handler
by now enabling full access to any rq struct members there -
we'll then end up with the next guy introducing
some strange dependency on other rq parts within this handler
which that guy would not have been tempted to do in the first place
if it had remained strictly task-based......

I'd wager that the size benefit possibly dominantly stems from
getting rid of rq->curr indirection lookup at the many user call sites.
Thus it might be a good idea
to instead create a non-inlined resched_curr() wrapper
which merely forwards to resched_task(),
to have the currently strictly task-focussed (pun intended ;) approach
of resched_task() properly preserved.

Generally spoken, this incident and the "interesting" status quo
of very often doing an open-coded rq->curr lookup when calling resched_task()
could prompt a rethinking of relationship of task vs. rq,
since by clearing up (and focussing on) design intentions,
one could "automatically" end up
with more elegant and thus better function implementations.

Thank you for your activities in the scheduler area!

Andreas Mohr
--
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/