linux-kernel - Q. drm/i915 shrinker, synchronize_rcu

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: <7743.1493532478@jrobl>
Date:   Sun, 30 Apr 2017 15:07:58 +0900
From:   "J. R. Okajima" <hooanon05g@...il.com>
To:     joonas.lahtinen@...ux.intel.com
cc:     aarcange@...hat.com, chris@...is-wilson.co.uk,
        daniel.vetter@...ll.ch, jani.nikula@...el.com,
        linux-kernel@...r.kernel.org
Subject: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

Hello,

Since v4.11-rc7 I can see the workqueue stops on my development/test system.
Git-bisecting tells me the suspicious commit is
	c053b5a 2017-04-11 drm/i915: Don't call synchronize_rcu_expedited under struct_mutex

I am not sure whether this is the real cause or not of my problem, but I
have a question.
By the commit, the shrinker handlers ->scan_objects() and
->count_objects() both calls synchronize_rcu_expedited()
unconditionally. Is it a legal RCU bahavour?

I know dev->struct_mutex is unlocked now, but before the commit, these
two handlers were not calling synchronize_rcu_expedited().


J. R. Okajima