kernel/linux.git, branch v3.9.3

Linux 3.9.3

2013-05-19T18:39:04+00:00

target: Use FD_MAX_SECTORS/FD_BLOCKSIZE for blockdevs using fileio

2013-05-19T18:38:47+00:00

commit e3e84cda321703b123f36488f50700f371bc7230 upstream. We can still see the error reported in https://patchwork.kernel.org/patch/2338981/ when using fileio backed by a block device. I'm assuming this will get us past that error (from sbc_parse_cdb), and also assuming it's OK to have our max_sectors be larger than the block's queue max hw sectors? Reported-by: Eric Harney Signed-off-by: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

audit: Make testing for a valid loginuid explicit.

2013-05-19T18:38:47+00:00

commit 780a7654cee8d61819512385e778e4827db4bfbc upstream. audit rule additions containing "-F auid!=4294967295" were failing with EINVAL because of a regression caused by e1760bd. Apparently some userland audit rule sets want to know if loginuid uid has been set and are using a test for auid != 4294967295 to determine that. In practice that is a horrible way to ask if a value has been set, because it relies on subtle implementation details and will break every time the uid implementation in the kernel changes. So add a clean way to test if the audit loginuid has been set, and silently convert the old idiom to the cleaner and more comprehensible new idiom. RGB notes: In upstream, audit_rule_to_entry has been refactored out. This is patch is already upstream in functionally the same form in commit 780a7654cee8d61819512385e778e4827db4bfbc . The decimal constant was cast to unsigned to quiet GCC 4.6 32-bit architecture warnings. Reported-By: Steve Grubb Signed-off-by: "Eric W. Biederman" Tested-by: Richard Guy Briggs Signed-off-by: Eric Paris Backported-by: Richard Guy Briggs Signed-off-by: Greg Kroah-Hartman

parisc: make default cross compiler search more robust (v3)

2013-05-19T18:38:47+00:00

commit 6880b0150a7c25fd75c5ece80abc49ebf53c38c1 upstream. People/distros vary how they prefix the toolchain name for 64bit builds. Rather than enforce one convention over another, add a for loop which does a search for all the general prefixes. For 64bit builds, we now search for (in order): hppa64-unknown-linux-gnu hppa64-linux-gnu hppa64-linux For 32bit builds, we look for: hppa-unknown-linux-gnu hppa-linux-gnu hppa-linux hppa2.0-unknown-linux-gnu hppa2.0-linux-gnu hppa2.0-linux hppa1.1-unknown-linux-gnu hppa1.1-linux-gnu hppa1.1-linux This patch was initiated by Mike Frysinger, with feedback from Jeroen Roovers, John David Anglin and Helge Deller. Signed-off-by: Mike Frysinger Signed-off-by: Jeroen Roovers Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

parisc: fix NATIVE set up in build

2013-05-19T18:38:46+00:00

commit 93782eba49e23c3f311a6b05a19ba15927ec4e8b upstream. The ifeq operator does not accept globs, so this little bit of code will never match (unless uname literally prints out "parsic*"). Rewrite to use a pattern matching operator so that NATIVE is set to 1 on parisc. Signed-off-by: Mike Frysinger Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

parisc: use long branch in fork_like macro

2013-05-19T18:38:46+00:00

commit bbbfde782084b4f0d85ddffb88f1cf4650ff40e4 upstream. The "b" branch instruction used in the fork_like macro only can handle 17-bit pc-relative offsets. This fails with an out of range offset with some .config files. Rewrite to use the "be" instruction which can branch to any address in a space. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

parisc: fix SMP races when updating PTE and TLB entries in entry.S

2013-05-19T18:38:45+00:00

commit f0a18819e261afc5fdbd8c5c6f9943123c5461ba upstream. Currently, race conditions exist in the handling of TLB interruptions in entry.S. In particular, dirty bit updates can be lost if an accessed interruption occurs just after the dirty bit interruption on a different cpu. Lost dirty bit updates result in user pages not being flushed and general system instability. This change adds lock and unlock macros to synchronize all PTE and TLB updates done in entry.S. As a result, userspace stability is significantly improved. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

parisc: only re-enable interrupts if we need to schedule or deliver signals when returning to userspace

2013-05-19T18:38:45+00:00

commit c207a76bf155cb5cf24cf849c08f6555e9180594 upstream. Helge and I have found that we have a kernel stack overflow problem which causes a variety of random failures. Currently, we re-enable interrupts when returning from an external interrupt incase we need to schedule or delivery signals. As a result, a potentially unlimited number of interrupts can occur while we are running on the kernel stack. It is very limited in space (currently, 16k). This change defers enabling interrupts until we have actually decided to schedule or delivery signals. This only occurs when we about to return to userspace. This limits the number of interrupts on the kernel stack to one. In other cases, interrupts remain disabled until the final return from interrupt (rfi). Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

usermodehelper: check subprocess_info->path != NULL

2013-05-19T18:38:45+00:00

commit 264b83c07a84223f0efd0d1db9ccc66d6f88288f upstream. argv_split(empty_or_all_spaces) happily succeeds, it simply returns argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to check sub_info->path != NULL to avoid the crash. This is the minimal fix, todo: - perhaps we should change argv_split() to return NULL or change the callers. - kill or justify ->path[0] check - narrow the scope of helper_lock() Signed-off-by: Oleg Nesterov Acked-By: Lucas De Marchi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drm/radeon: restore nomodeset operation (v2)

2013-05-19T18:38:45+00:00

commit e9ced8e040ebe40e9953db90acbe7d0b58702ebb upstream. When UMS was deprecated it removed support for nomodeset commandline we really want this in distro land so we can debug stuff, everyone should fallback to vesa correctly. v2: oops -1 isn't used anymore, restore original behaviour -1 is default, so we can boot with nomodeset on the command line, then use radeon.modeset=1 to override it for debugging later. Reviewed-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman