linux-kernel - [PATCH] drivercore: Fix ordering between deferred

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:	Thu, 14 Feb 2013 18:14:27 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	linux-kernel@...r.kernel.org
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Arnd Bergmann <arnd@...db.de>,
	Russell King <linux@....linux.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	stable@...r.kernel.org
Subject: [PATCH] drivercore: Fix ordering between deferred_probe and exiting initcalls

One of the side effects of deferred probe is that some drivers which
used to be probed before initcalls completed are now happening slightly
later. This causes two problems.
- If a console driver gets deferred, then it may not be ready when
  userspace starts. For example, if a uart depends on pinctrl, then the
  uart will get deferred and /dev/console will not be available
- __init sections will be discarded before built-in drivers are probed.
  Strictly speaking, __init functions should not be called in a drivers
  __probe path, but there are a lot of drivers (console stuff again)
  that do anyway. In the past it was perfectly safe to do so because all
  built-in drivers got probed before the end of initcalls.

This patch fixes the problem by forcing the first pass of the deferred
list to complete at late_initcall time. This is late enough to catch the
drivers that are known to have the above issues.

Signed-off-by: Grant Likely <grant.likely@...retlab.ca>
Tested-by: Haojian Zhuang <haojian.zhuang@...aro.org>
Cc: Arnd Bergmann <arnd@...db.de>
Cc: Russell King <linux@....linux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: stable@...r.kernel.org
---

Hi Greg and Linus,

Okay, so this is really late to be sending for v3.8, and it doesn't have
nearly the amount of testing that I would like it to have. I haven't
even put it into linux-next yet. However, it is a real bug that some of
the Linaro folks have run into that is caused by deferred probe. It
isn't very widespread, but it is there.

It probably should be in v3.8, but given how ridiculously late it is and
that it isn't a widespread problem it would probably be just fine to go
in during the v3.9 merge window and get backported to linux-stable. If I
don't hear otherwise then that is what I'll do.

Still, here it is. If you think it really should be merged before
tagging v3.8 then please go ahead and apply it.

For stable it needs to go into v3.4 onwards.

g.


 drivers/base/dd.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e3bbed8..61d3e1b 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -172,6 +172,8 @@ static int deferred_probe_initcall(void)
 
 	driver_deferred_probe_enable = true;
 	driver_deferred_probe_trigger();
+	/* Sort as many dependencies as possible before exiting initcalls */
+	flush_workqueue(deferred_wq);
 	return 0;
 }
 late_initcall(deferred_probe_initcall);
-- 
1.7.10.4

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