<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/include/linux/kmod.h, branch v3.3</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v3.3</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v3.3'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2011-12-09T22:36:36+00:00</updated>
<entry>
<title>PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()</title>
<updated>2011-12-09T22:36:36+00:00</updated>
<author>
<name>Srivatsa S. Bhat</name>
<email>srivatsa.bhat@linux.vnet.ibm.com</email>
</author>
<published>2011-12-09T22:36:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b298d289c79211508f11cb50749b0d1d54eb244a'/>
<id>urn:sha1:b298d289c79211508f11cb50749b0d1d54eb244a</id>
<content type='text'>
Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.

However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:

...
if (usermodehelper_is_disabled())
        goto out;

/* Do actual work */
...

out:
        return err;

Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.

In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.

Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591

This patch adds proper synchronization to fix this issue.

It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.

Signed-off-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
</content>
</entry>
<entry>
<title>treewide: use __printf not __attribute__((format(printf,...)))</title>
<updated>2011-11-01T00:30:54+00:00</updated>
<author>
<name>Joe Perches</name>
<email>joe@perches.com</email>
</author>
<published>2011-11-01T00:11:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b9075fa968a0a4347aef35e235e2995c0e57dddd'/>
<id>urn:sha1:b9075fa968a0a4347aef35e235e2995c0e57dddd</id>
<content type='text'>
Standardize the style for compiler based printf format verification.
Standardized the location of __printf too.

Done via script and a little typing.

$ grep -rPl --include=*.[ch] -w "__attribute__" * | \
  grep -vP "^(tools|scripts|include/linux/compiler-gcc.h)" | \
  xargs perl -n -i -e 'local $/; while (&lt;&gt;) { s/\b__attribute__\s*\(\s*\(\s*format\s*\(\s*printf\s*,\s*(.+)\s*,\s*(.+)\s*\)\s*\)\s*\)/__printf($1, $2)/g ; print; }'

[akpm@linux-foundation.org: revert arch bits]
Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
Cc: "Kirill A. Shutemov" &lt;kirill@shutemov.name&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>KEYS/DNS: Fix ____call_usermodehelper() to not lose the session keyring</title>
<updated>2011-06-17T16:40:48+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2011-06-17T10:25:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=879669961b11e7f40b518784863a259f735a72bf'/>
<id>urn:sha1:879669961b11e7f40b518784863a259f735a72bf</id>
<content type='text'>
____call_usermodehelper() now erases any credentials set by the
subprocess_inf::init() function.  The problem is that commit
17f60a7da150 ("capabilites: allow the application of capability limits
to usermode helpers") creates and commits new credentials with
prepare_kernel_cred() after the call to the init() function.  This wipes
all keyrings after umh_keys_init() is called.

The best way to deal with this is to put the init() call just prior to
the commit_creds() call, and pass the cred pointer to init().  That
means that umh_keys_init() and suchlike can modify the credentials
_before_ they are published and potentially in use by the rest of the
system.

This prevents request_key() from working as it is prevented from passing
the session keyring it set up with the authorisation token to
/sbin/request-key, and so the latter can't assume the authority to
instantiate the key.  This causes the in-kernel DNS resolver to fail
with ENOKEY unconditionally.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Eric Paris &lt;eparis@redhat.com&gt;
Tested-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'next' into for-linus</title>
<updated>2011-05-24T12:55:24+00:00</updated>
<author>
<name>James Morris</name>
<email>jmorris@namei.org</email>
</author>
<published>2011-05-24T12:55:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=434d42cfd05a7cc452457a81d2029540cba12150'/>
<id>urn:sha1:434d42cfd05a7cc452457a81d2029540cba12150</id>
<content type='text'>
</content>
</entry>
<entry>
<title>kmod: always provide usermodehelper_disable()</title>
<updated>2011-05-17T21:19:18+00:00</updated>
<author>
<name>Kay Sievers</name>
<email>kay.sievers@vrfy.org</email>
</author>
<published>2011-05-10T19:27:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=13d53f8775c6a00b070a3eef6833795412eb7fcd'/>
<id>urn:sha1:13d53f8775c6a00b070a3eef6833795412eb7fcd</id>
<content type='text'>
We need to prevent kernel-forked processes during system poweroff.
Such processes try to access the filesystem whose disks we are
trying to shutdown at the same time. This causes delays and exceptions
in the storage drivers.

A follow-up patch will add these calls and need usermodehelper_disable()
also on systems without suspend support.

Signed-off-by: Kay Sievers &lt;kay.sievers@vrfy.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
</content>
</entry>
<entry>
<title>PM: Print a warning if firmware is requested when tasks are frozen</title>
<updated>2011-05-17T21:19:17+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rjw@sisk.pl</email>
</author>
<published>2011-05-06T18:09:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a144c6a6c924aa1da04dd77fb84b89927354fdff'/>
<id>urn:sha1:a144c6a6c924aa1da04dd77fb84b89927354fdff</id>
<content type='text'>
Some drivers erroneously use request_firmware() from their -&gt;resume()
(or -&gt;thaw(), or -&gt;restore()) callbacks, which is not going to work
unless the firmware has been built in.  This causes system resume to
stall until the firmware-loading timeout expires, which makes users
think that the resume has failed and reboot their machines
unnecessarily.  For this reason, make _request_firmware() print a
warning and return immediately with error code if it has been called
when tasks are frozen and it's impossible to start any new usermode
helpers.

Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Reviewed-by: Valdis Kletnieks &lt;valdis.kletnieks@vt.edu&gt;
</content>
</entry>
<entry>
<title>capabilites: allow the application of capability limits to usermode helpers</title>
<updated>2011-04-04T00:31:04+00:00</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2011-04-01T21:07:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=17f60a7da150fdd0cfb9756f86a262daa72c835f'/>
<id>urn:sha1:17f60a7da150fdd0cfb9756f86a262daa72c835f</id>
<content type='text'>
There is no way to limit the capabilities of usermodehelpers. This problem
reared its head recently when someone complained that any user with
cap_net_admin was able to load arbitrary kernel modules, even though the user
didn't have cap_sys_module.  The reason is because the actual load is done by
a usermode helper and those always have the full cap set.  This patch addes new
sysctls which allow us to bound the permissions of usermode helpers.

/proc/sys/kernel/usermodehelper/bset
/proc/sys/kernel/usermodehelper/inheritable

You must have CAP_SYS_MODULE  and CAP_SETPCAP to change these (changes are
&amp;= ONLY).  When the kernel launches a usermodehelper it will do so with these
as the bset and pI.

-v2:	make globals static
	create spinlock to protect globals

-v3:	require both CAP_SETPCAP and CAP_SYS_MODULE
-v4:	fix the typo s/CAP_SET_PCAP/CAP_SETPCAP/ because I didn't commit
Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
No-objection-from: Serge E. Hallyn &lt;serge.hallyn@canonical.com&gt;
Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Serge E. Hallyn &lt;serge.hallyn@canonical.com&gt;
Acked-by: Andrew G. Morgan &lt;morgan@kernel.org&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
</content>
</entry>
<entry>
<title>umh: creds: kill subprocess_info-&gt;cred logic</title>
<updated>2010-05-27T16:12:45+00:00</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2010-05-26T21:43:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c70a626d3eba373514c72287c93588b6974a0059'/>
<id>urn:sha1:c70a626d3eba373514c72287c93588b6974a0059</id>
<content type='text'>
Now that nobody ever changes subprocess_info-&gt;cred we can kill this member
and related code.  ____call_usermodehelper() always runs in the context of
freshly forked kernel thread, it has the proper -&gt;cred copied from its
parent kthread, keventd.

Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>umh: creds: convert call_usermodehelper_keys() to use subprocess_info-&gt;init()</title>
<updated>2010-05-27T16:12:45+00:00</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2010-05-26T21:43:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=685bfd2c48bb3284d31e73ff3151c957d76deda9'/>
<id>urn:sha1:685bfd2c48bb3284d31e73ff3151c957d76deda9</id>
<content type='text'>
call_usermodehelper_keys() uses call_usermodehelper_setkeys() to change
subprocess_info-&gt;cred in advance.  Now that we have info-&gt;init() we can
change this code to set tgcred-&gt;session_keyring in context of execing
kernel thread.

Note: since currently call_usermodehelper_keys() is never called with
UMH_NO_WAIT, call_usermodehelper_keys()-&gt;key_get() and umh_keys_cleanup()
are not really needed, we could rely on install_session_keyring_to_cred()
which does key_get() on success.

Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>exec: replace call_usermodehelper_pipe with use of umh init function and resolve limit</title>
<updated>2010-05-27T16:12:44+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2010-05-26T21:42:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=898b374af6f71041bd3bceebe257e564f3f1d458'/>
<id>urn:sha1:898b374af6f71041bd3bceebe257e564f3f1d458</id>
<content type='text'>
The first patch in this series introduced an init function to the
call_usermodehelper api so that processes could be customized by caller.
This patch takes advantage of that fact, by customizing the helper in
do_coredump to create the pipe and set its core limit to one (for our
recusrsion check).  This lets us clean up the previous uglyness in the
usermodehelper internals and factor call_usermodehelper out entirely.
While I'm at it, we can also modify the helper setup to look for a core
limit value of 1 rather than zero for our recursion check

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Reviewed-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
