Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

We’re showing branches in this repository, but you can also compare across forks.

base fork: NigelCunningham/tuxonice-kernel
head fork: NigelCunningham/tuxonice-kernel
Commits on Feb 27, 2013
Marcin Ślusarz mslusarz drm/nouveau/vm: fix memory corruption when pgt allocation fails
commit cfd376b upstream.

If we return freed vm, nouveau_drm_open will happily call nouveau_cli_destroy,
which will try to free it again.

Reported-by: Peter Hurley <>
Signed-off-by: Marcin Slusarz <>
Signed-off-by: Ben Skeggs <>
Signed-off-by: Greg Kroah-Hartman <>
Dave Hansen x86-32, mm: Rip out x86_32 NUMA remapping code
commit f03574f upstream.

This code was an optimization for 32-bit NUMA systems.

It has probably been the cause of a number of subtle bugs over
the years, although the conditions to excite them would have
been hard to trigger.  Essentially, we remap part of the kernel
linear mapping area, and then sometimes part of that area gets
freed back in to the bootmem allocator.  If those pages get
used by kernel data structures (say mem_map[] or a dentry),
there's no big deal.  But, if anyone ever tried to use the
linear mapping for these pages _and_ cared about their physical
address, bad things happen.

For instance, say you passed __GFP_ZERO to the page allocator
and then happened to get handed one of these pages, it zero the
remapped page, but it would make a pte to the _old_ page.
There are probably a hundred other ways that it could screw
with things.

We don't need to hang on to performance optimizations for
these old boxes any more.  All my 32-bit NUMA systems are long
dead and buried, and I probably had access to more than most

This code is causing real things to break today:

I looked in to actually fixing this, but it requires surgery
to way too much brittle code, as well as stuff like

[ hpa: Cc: this for -stable, since it is a memory corruption issue.
  However, an alternative is to simply mark NUMA as depends BROKEN
  rather than EXPERIMENTAL in the X86_32 subclause... ]

Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
H. Peter Anvin x86-32, mm: Remove reference to resume_map_numa_kva()
commit bb112ae upstream.

Remove reference to removed function resume_map_numa_kva().

Signed-off-by: H. Peter Anvin <>
Cc: Dave Hansen <>
Signed-off-by: Greg Kroah-Hartman <>
H. Peter Anvin x86-32, mm: Remove reference to alloc_remap()
commit 07f4207 upstream.

We have removed the remap allocator for x86-32, and x86-64 never had
it (and doesn't need it).  Remove residual reference to it.

Reported-by: Yinghai Lu <>
Signed-off-by: H. Peter Anvin <>
Cc: Dave Hansen <>
Signed-off-by: Greg Kroah-Hartman <>
Vinson Lee perf tools: Fix build with bison 2.3 and older.
commit 85df3b3 upstream.

The %name-prefix "prefix" syntax is not available on bison 2.3 and
older. Substitute with the -p "prefix" command-line option for
compatibility with older versions of bison.

This patch fixes this build error with older versions of bison.

    CC util/sysfs.o
    BISON util/pmu-bison.c
util/pmu.y:2.14-24: syntax error, unexpected string, expecting =
make: *** [util/pmu-bison.c] Error 1

Signed-off-by: Vinson Lee <>
Tested-by: Li Zefan <>
Cc: Ingo Molnar <>
Cc: Jiri Olsa <>
Cc: Li Zefan <>
Cc: Namhyung Kim <>
Cc: Paul Mackerras <>
Cc: Pekka Enberg <>
Signed-off-by: Arnaldo Carvalho de Melo <>
Signed-off-by: Greg Kroah-Hartman <>
Jiri Olsa perf hists: Fix period symbol_conf.field_sep display
commit c0d246b upstream.

Currently we don't properly display hist data with symbol_conf.field_sep
separator. We need to display either space or separator.

Signed-off-by: Jiri Olsa <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Peter Zijlstra <>
Cc: Ingo Molnar <>
Cc: Paul Mackerras <>
Cc: Corey Ashford <>
Cc: Frederic Weisbecker <>
Cc: Namhyung Kim <>
Signed-off-by: Arnaldo Carvalho de Melo <>
Cc: Josh Boyer <>
Signed-off-by: Greg Kroah-Hartman <>
Linus Torvalds torvalds mm: fix pageblock bitmap allocation
commit 7c45512 upstream.

Commit c060f94 ("mm: use aligned zone start for pfn_to_bitidx
calculation") fixed out calculation of the index into the pageblock
bitmap when a !SPARSEMEM zome was not aligned to pageblock_nr_pages.

However, the _allocation_ of that bitmap had never taken this alignment
requirement into accout, so depending on the exact size and alignment of
the zone, the use of that index could then access past the allocation,
resulting in some very subtle memory corruption.

This was reported (and bisected) by Ingo Molnar: one of his random
config builds would hang with certain very specific kernel command line

In the meantime, commit c060f94 has been marked for stable, so this
fix needs to be back-ported to the stable kernels that backported the
commit to use the right alignment.

Bisected-and-tested-by: Ingo Molnar <>
Acked-by: Mel Gorman <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
H. Peter Anvin Eliminate Perl warning
commit 63a3f60 upstream.

defined(@array) is deprecated in Perl and gives off a warning.
Restructure the code to remove that warning.

[ hpa: it would be interesting to revert to the timeconst.bc script.
  It appears that the failures reported by akpm during testing of
  that script was due to a known broken version of make, not a problem
  with bc.  The Makefile rules could probably be restructured to avoid
  the make bug, or it is probably old enough that it doesn't matter. ]

Reported-by: Andi Kleen <>
Signed-off-by: H. Peter Anvin <>
Cc: Andrew Morton <>
Signed-off-by: Greg Kroah-Hartman <>
Thomas Gleixner genirq: Avoid deadlock in spurious handling
commit e716efd upstream.

commit 52553dd(genirq: fix regression in irqfixup, irqpoll)
introduced a potential deadlock by calling the action handler with the
irq descriptor lock held.

Remove the call and let the handling code run even for an interrupt
where only a single action is registered. That matches the goal of
the above commit and avoids the deadlock.

Document the confusing action = desc->action reload in the handling
loop while at it.

Reported-and-tested-by: "Wang, Warner" <>
Tested-by: Edward Donovan <>
Cc: "Wang, Song-Bo (Stoney)" <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
Stanislaw Gruszka sgruszka posix-cpu-timers: Fix nanosleep task_struct leak
commit e6c42c2 upstream.

The trinity fuzzer triggered a task_struct reference leak via
clock_nanosleep with CPU_TIMERs. do_cpu_nanosleep() calls
posic_cpu_timer_create(), but misses a corresponding
posix_cpu_timer_del() which leads to the task_struct reference leak.

Reported-and-tested-by: Tommi Rantala <>
Signed-off-by: Stanislaw Gruszka <>
Cc: Dave Jones <>
Cc: John Stultz <>
Cc: Oleg Nesterov <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
Leonid Shatz hrtimer: Prevent hrtimer_enqueue_reprogram race
commit b22affe upstream.

hrtimer_enqueue_reprogram contains a race which could result in
timer.base switch during unlock/lock sequence.

hrtimer_enqueue_reprogram is releasing the lock protecting the timer
base for calling raise_softirq_irqsoff() due to a lock ordering issue
versus rq->lock.

If during that time another CPU calls __hrtimer_start_range_ns() on
the same hrtimer, the timer base might switch, before the current CPU
can lock base->lock again and therefor the unlock_timer_base() call
will unlock the wrong lock.

[ tglx: Added comment and massaged changelog ]

Signed-off-by: Leonid Shatz <>
Signed-off-by: Izik Eidus <>
Cc: Andrea Arcangeli <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
Olaf Hering x86: Hyper-V: register clocksource only if its advertised
commit 32068f6 upstream.

Enable hyperv_clocksource only if its advertised as a feature.
XenServer 6 returns the signature which is checked in
ms_hyperv_platform(), but it does not offer all features. Currently the
clocksource is enabled unconditionally in ms_hyperv_init_platform(), and
the result is a hanging guest.

Hyper-V spec Bit 1 indicates the availability of Partition Reference
Counter.  Register the clocksource only if this bit is set.

The guest in question prints this in dmesg:
 [    0.000000] Hypervisor detected: Microsoft HyperV
 [    0.000000] HyperV: features 0x70, hints 0x0

This bug can be reproduced easily be setting 'viridian=1' in a HVM domU
.cfg file. A workaround without this patch is to boot the HVM guest with

Signed-off-by: Olaf Hering <>
Signed-off-by: K. Y. Srinivasan <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
Konstantin Khlebnikov koct9i workqueue: un-GPL function delayed_work_timer_fn()
commit 1438ade upstream.

commit d8e794d ("workqueue: set
delayed_work->timer function on initialization") exports function
delayed_work_timer_fn() only for GPL modules. This makes delayed-works
unusable for non-GPL modules, because initialization macro now requires
GPL symbol. For example schedule_delayed_work() available for non-GPL.

Signed-off-by: Konstantin Khlebnikov <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Greg Kroah-Hartman <>
Denis evdenis ALSA: ali5451: remove irq enabling in pointer callback
commit dacae5a upstream.

snd_ali_pointer function is called with local
interrupts disabled. However it seems very strange to
reenable them in such way.

Found by Linux Driver Verification project (

Signed-off-by: Denis Efremov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
Denis evdenis ALSA: rme32.c irq enabling after spin_lock_irq
commit f49a59c upstream.

According to the other code in this driver and similar
code in rme96 it seems, that spin_lock_irq in
snd_rme32_capture_close function should be paired
with spin_unlock_irq.

Found by Linux Driver Verification project (

Signed-off-by: Denis Efremov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
Dirkjan Bussink dbussink tty: Prevent deadlock in n_gsm driver
commit 4d9b109 upstream.

This change fixes a deadlock when the multiplexer is closed while there
are still client side ports open.

When the multiplexer is closed and there are active tty's it tries to
close them with tty_vhangup. This has a problem though, because
tty_vhangup needs the tty_lock. This patch changes it to unlock the
tty_lock before attempting the hangup and relocks afterwards. The
additional call to tty_port_tty_set is needed because otherwise the
port stays active because of the reference counter.

This change also exposed another problem that other code paths don't
expect that the multiplexer could have been closed. This patch also adds
checks for these cases in the gsmtty_ class of function that could be

The documentation explicitly states that "first close all virtual ports
before closing the physical port" but we've found this to not always
reality in our field situations. The GPRS / UTMS modem sometimes crashes
and needs a power cycle in that case which means cleanly shutting down
everything is not always possible. This change makes it much more robust
for our situation where at least the system is recoverable with this patch
and doesn't hang in a deadlock situation inside the kernel.

The patch is against the long term support kernel (3.4.27) and should
apply cleanly to more recent branches. Tested with a Telit GE864-QUADV2
and Telit HE910 modem.

Signed-off-by: Dirkjan Bussink <>
Signed-off-by: Greg Kroah-Hartman <>
utrace utrace tty: set_termios/set_termiox should not return -EINTR
commit 183d95c upstream.

read command causes bash to abort with double free or corruption (out).

A simple test-case from Roman:

	// Compile the reproducer and send sigchld ti that process.
	// EINTR occurs even if SA_RESTART flag is set.

	void handler(int sig)

	  struct sigaction act;
	  act.sa_handler = handler;
	  act.sa_flags = SA_RESTART;
	  sigaction (SIGCHLD, &act, 0);
	  struct termio ttp;
	  ioctl(0, TCGETA, &ttp);
	    if (ioctl(0, TCSETAW, ttp) < 0)
		if (errno == EINTR)
		  fprintf(stderr, "BUG!"); return(1);

Change set_termios/set_termiox to return -ERESTARTSYS to fix this
particular problem.

I didn't dare to change other EINTR's in drivers/tty/, but they look
equally wrong.

Reported-by: Roman Rakus <>
Reported-by: Lingzhu Xiang <>
Signed-off-by: Oleg Nesterov <>
Cc: Jiri Slaby <>
Signed-off-by: Greg Kroah-Hartman <>
Johan Hovold jhovold USB: serial: fix null-pointer dereferences on disconnect
commit b2ca699 upstream.

Make sure serial-driver dtr_rts is called with disc_mutex held after
checking the disconnected flag.

Due to a bug in the tty layer, dtr_rts may get called after a device has
been disconnected and the tty-device unregistered. Some drivers have had
individual checks for disconnect to make sure the disconnected interface
was not accessed, but this should really be handled in usb-serial core
(at least until the long-standing tty-bug has been fixed).

Note that the problem has been made more acute with commit 0998d06
("device-core: Ensure drvdata = NULL when no driver is bound") as the
port data is now also NULL when dtr_rts is called resulting in further

Reported-by: Chris Ruehl <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Thomas Gleixner serial: imx: Fix recursive locking bug
commit 677fe55 upstream.

commit 9ec1882 (tty: serial: imx: console write routing is unsafe
on SMP) introduced a recursive locking bug in imx_console_write().

The callchain is:

          spin_lock_irqsave(&sport->port.lock,flags); <--- DEAD

The bad news is that the kernel debugging facilities can dectect the
problem, but the printks never surface on the serial console for
obvious reasons.

There is a similar issue with oops_in_progress. If the kernel crashes
we really don't want to be stuck on the lock and unable to tell what

In general most UP originated drivers miss these checks and nobody
ever notices because CONFIG_PROVE_LOCKING seems to be still ignored by
a large number of developers.

The solution is to avoid locking in the sysrq case and trylock in the
oops_in_progress case.

This scheme is used in other drivers as well and it would be nice if
we could move this to a common place, so the usual copy/paste/modify
bugs can be avoided.

Now there is another issue with this scheme:

CPU0 	    	     	 CPU1
			   sysrq_detection() -> sets port->sysrq
			 return from interrupt
     if (port->sysrq)
     	avoid locking

port->sysrq is reset with the next receive character. So as long as
the port->sysrq is not reset and this can take an endless amount of
time if after the break no futher receive character follows, all
console writes happen unlocked.

While the current writer is protected against other console writers by
the console sem, it's unprotected against open/close or other
operations which fiddle with the port. That's what the above mentioned
commit tried to solve.

That's an issue in all drivers which use that scheme and unfortunately
there is no easy workaround. The only solution is to have a separate
indicator port->sysrq_cpu. uart_handle_sysrq_char() then sets it to
smp_processor_id() before calling into handle_sysrq() and resets it to
-1 after that. Then change the locking check to:

     if (port->sysrq_cpu == smp_processor_id())
     	 locked = 0;
     else if (oops_in_progress)
         locked = spin_trylock_irqsave(port->lock, flags);
  	 spin_lock_irqsave(port->lock, flags);

That would force all other cpus into the spin_lock path. Problem
solved, but that's way beyond the scope of this fix and really wants
to be implemented in a common function which calls the uart specific
write function to avoid another gazillion of hard to debug
copy/paste/modify bugs.

Reported-and-tested-by: Tim Sander <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
Michael Chan serial_core: Fix type definition for PORT_BRCM_TRUMANAGE.
commit 85f0244 upstream.

It was mistakenly defined to be 24 instead of the next higher number 25.

Reported-by: Alexander Shishkin <>
Cc: Stephen Hurd <>
Signed-off-by: Michael Chan <>
Signed-off-by: Greg Kroah-Hartman <>
lwfinger lwfinger b43: Increase number of RX DMA slots
commit ccae0e5 upstream.

Bastian Bittorf reported that some of the silent freezes on a Linksys WRT54G
were due to overflow of the RX DMA ring buffer, which was created with 64
slots. That finding reminded me that I was seeing similar crashed on a netbook,
which also has a relatively slow processor. After increasing the number of
slots to 128, runs on the netbook that previously failed now worked; however,
I found that 109 slots had been used in one test. For that reason, the number
of slots is being increased to 256.

Signed-off-by: Larry Finger <>
Cc: Bastian Bittorf <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
lwfinger lwfinger rtlwifi: rtl8192cu: Add new USB ID
commit 8708aac upstream.

A new model of the RTL8188CUS has appeared.

Reported-and-tested-by: Thomas Rosenkrantz <>
Signed-off-by: Larry Finger <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
Jussi Kivilinna jkivilin rtlwifi: usb: allocate URB control message setup_packet and data buff…
…er separately

commit bc6b892 upstream.

rtlwifi allocates both setup_packet and data buffer of control message urb,
using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for
allocating is:
	struct {
		u8 data[254];
		struct usb_ctrlrequest dr;

Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and
DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory
corruptions and freezes.

Patch changes setup packet to be allocated separately.

 - Use WARN_ON_ONCE instead of WARN_ON

Signed-off-by: Jussi Kivilinna <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
Nicolas Pitre tty vt: fix character insertion overflow
commit a883b70 upstream.

Commit 81732c3 ("tty vt: Fix line garbage in virtual console on
command line edition") broke insert_char() in multiple ways.  Then
commit b1a925f ("tty vt: Fix a regression in command line edition")
partially fixed it.  However, the buffer being moved is still too large
and overflowing beyond the end of the current line, corrupting existing
characters on the next line.

Example test case:

echo -e "abc\nde\x1b[A\x1b[4h \x1b[4l\x1b[B"

Expected result:

ab c

Current result:

ab c

Needless to say that this is very annoying when inserting words in the
middle of paragraphs with certain text editors.

Signed-off-by: Nicolas Pitre <>
Acked-by: Jean-François Moine <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Stefan Bader xen: Send spinlock IPI to all waiters
commit 76eaca0 upstream.

There is a loophole between Xen's current implementation of
pv-spinlocks and the scheduler. This was triggerable through
a testcase until v3.6 changed the TLB flushing code. The
problem potentially is still there just not observable in the
same way.

What could happen was (is):

1. CPU n tries to schedule task x away and goes into a slow
   wait for the runq lock of CPU n-# (must be one with a lower
2. CPU n-#, while processing softirqs, tries to balance domains
   and goes into a slow wait for its own runq lock (for updating
   some records). Since this is a spin_lock_irqsave in softirq
   context, interrupts will be re-enabled for the duration of
   the poll_irq hypercall used by Xen.
3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives
   an interrupt (e.g. endio) and when processing the interrupt,
   tries to wake up task x. But that is in schedule and still
   on_cpu, so try_to_wake_up goes into a tight loop.
4. The runq lock of CPU n-# gets unlocked, but the message only
   gets sent to the first waiter, which is CPU n-# and that is
   busily stuck.
5. CPU n-# never returns from the nested interruption to take and
   release the lock because the scheduler uses a busy wait.
   And CPU n never finishes the task migration because the unlock
   notification only went to CPU n-#.

To avoid this and since the unlocking code has no real sense of
which waiter is best suited to grab the lock, just send the IPI
to all of them. This causes the waiters to return from the hyper-
call (those not interrupted at least) and do active spinlocking.


Acked-by: Jan Beulich <>
Signed-off-by: Stefan Bader <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
Wei Liu liuw xen: close evtchn port if binding to irq fails
commit e7e44e4 upstream.

Signed-off-by: Wei Liu <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
Minchan Kim minchank zram: Fix deadlock bug in partial read/write
commit 7e5a510 upstream.

Now zram allocates new page with GFP_KERNEL in zram I/O path
if IO is partial. Unfortunately, It may cause deadlock with
reclaim path like below.

write_page from fs
				write_page from fs
				fs_lock <-- deadlock

This patch fixes it by using GFP_NOIO.  In read path, we
reorganize code flow so that kmap_atomic is called after the
GFP_NOIO allocation.

Acked-by: Jerome Marchand <>
Acked-by: Nitin Gupta <>
[ don't use GFP_ATOMIC ]
Signed-off-by: Pekka Enberg <>
Signed-off-by: Minchan Kim <>
Signed-off-by: Greg Kroah-Hartman <>
Bjorn Helgaas bjorn-helgaas Driver core: treat unregistered bus_types as having no devices
commit 4fa3e78 upstream.

A bus_type has a list of devices (klist_devices), but the list and the
subsys_private structure that contains it are not initialized until the
bus_type is registered with bus_register().

The panic/reboot path has fixups that look up devices in pci_bus_type.  If
we panic before registering pci_bus_type, the bus_type exists but the list
does not, so mach_reboot_fixups() trips over a null pointer and panics

          bus_find_device(&pci_bus_type, ...)
            bus->p is NULL

Joonsoo reported a problem when panicking before PCI was initialized.
I think this patch should be sufficient to replace the patch he posted
here: ("[PATCH] x86, reboot: skip
reboot_fixups in early boot phase")

Reported-by: Joonsoo Kim <>
Signed-off-by: Bjorn Helgaas <>
Signed-off-by: Greg Kroah-Hartman <>
Robin Holt mmu_notifier_unregister NULL Pointer deref and multiple ->release() c…

commit 751efd8 upstream.

There is a race condition between mmu_notifier_unregister() and

Assume two tasks, one calling mmu_notifier_unregister() as a result of a
filp_close() ->flush() callout (task A), and the other calling
mmu_notifier_release() from an mmput() (task B).

                A                               B
t1                                              srcu_read_lock()
t2              if (!hlist_unhashed())
t3                                              srcu_read_unlock()
t4              srcu_read_lock()
t5                                              hlist_del_init_rcu()
t6                                              synchronize_srcu()
t7              srcu_read_unlock()
t8              hlist_del_rcu()  <--- NULL pointer deref.

Additionally, the list traversal in __mmu_notifier_release() is not
protected by the by the mmu_notifier_mm->hlist_lock which can result in
callouts to the ->release() notifier from both mmu_notifier_unregister()
and __mmu_notifier_release().

-stable suggestions:

The stable trees prior to 3.7.y need commits 21a9273 and
7040030 cherry-picked in that order prior to cherry-picking this
commit.  The 3.7.y tree already has those two commits.

Signed-off-by: Robin Holt <>
Cc: Andrea Arcangeli <>
Cc: Wanpeng Li <>
Cc: Xiao Guangrong <>
Cc: Avi Kivity <>
Cc: Hugh Dickins <>
Cc: Marcelo Tosatti <>
Cc: Sagi Grimberg <>
Cc: Haggai Eran <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Cornelia Huck cohuck KVM: s390: Handle hosts not supporting s390-virtio.
commit 55c171a upstream.

Running under a kvm host does not necessarily imply the presence of
a page mapped above the main memory with the virtio information;
however, the code includes a hard coded access to that page.

Instead, check for the presence of the page and exit gracefully
before we hit an addressing exception if it does not exist.

Reviewed-by: Marcelo Tosatti <>
Reviewed-by: Alexander Graf <>
Signed-off-by: Cornelia Huck <>
Signed-off-by: Gleb Natapov <>
Signed-off-by: Greg Kroah-Hartman <>
Christian Borntraeger borntraeger s390/kvm: Fix store status for ACRS/FPRS
commit 15bc8d8 upstream.

On store status we need to copy the current state of registers
into a save area. Currently we might save stale versions:
The sie state descriptor doesnt have fields for guest ACRS,FPRS,
those registers are simply stored in the host registers. The host
program must copy these away if needed. We do that in vcpu_put/load.

If we now do a store status in KVM code between vcpu_put/load, the
saved values are not up-to-date. Lets collect the ACRS/FPRS before
saving them.

This also fixes some strange problems with hotplug and virtio-ccw,
since the low level machine check handler (on hotplug a machine check
will happen) will revalidate all registers with the content of the
save area.

Signed-off-by: Christian Borntraeger <>
Signed-off-by: Gleb Natapov <>
Signed-off-by: Greg Kroah-Hartman <>
Thomas Gleixner futex: Revert "futex: Mark get_robust_list as deprecated"
commit fe2b05f upstream.

This reverts commit ec0c427.

get_robust_list() is in use and a removal would break existing user
space. With the permission checks in place it's not longer a security
hole. Remove the deprecation warnings.

Signed-off-by: Thomas Gleixner <>
Cc: Cyrill Gorcunov <>
Cc: Richard Weinberger <>
Signed-off-by: Greg Kroah-Hartman <>
Jim Somerville inotify: remove broken mask checks causing unmount to be EINVAL
commit 676a067 upstream.

Running the command:

	inotifywait -e unmount /mnt/disk

immediately aborts with a -EINVAL return code.  This is however a valid
parameter.  This abort occurs only if unmount is the sole event
parameter.  If other event parameters are supplied, then the unmount
event wait will work.

The problem was introduced by commit 44b350f ("inotify: Fix mask
checks").  In that commit, it states:

	The mask checks in inotify_update_existing_watch() and
	inotify_new_watch() are useless because inotify_arg_to_mask()
	sets FS_IN_IGNORED and FS_EVENT_ON_CHILD bits anyway.

But instead of removing the useless checks, it did this:

	        mask = inotify_arg_to_mask(arg);
	-       if (unlikely(!mask))
	+       if (unlikely(!(mask & IN_ALL_EVENTS)))
	                return -EINVAL;

The problem is that IN_ALL_EVENTS doesn't include IN_UNMOUNT, and other
parts of the code keep IN_UNMOUNT separate from IN_ALL_EVENTS.  So the
check should be:

	if (unlikely(!(mask & (IN_ALL_EVENTS | IN_UNMOUNT))))

But inotify_arg_to_mask(arg) always sets the IN_UNMOUNT bit in the mask
anyway, so the check is always going to pass and thus should simply be
removed.  Also note that inotify_arg_to_mask completely controls what
mask bits get set from arg, there's no way for invalid bits to get
enabled there.

Lets fix it by simply removing the useless broken checks.

Signed-off-by: Jim Somerville <>
Signed-off-by: Paul Gortmaker <>
Cc: Jerome Marchand <>
Cc: John McCutchan <>
Cc: Robert Love <>
Cc: Eric Paris <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
MITSUNARI Shigeo herumi fs/block_dev.c: page cache wrongly left invalidated after revalidate_…

commit 7630b66 upstream.

We found that bdev->bd_invalidated was left set once revalidate_disk()
is called, which results in page cache flush every time that device is

Specifically, we found this problem in MD block device.  Once we resize
a MD device, mdadm --monitor periodically flush all page cache for that
device every 60 or 1000 seconds when it opens the device.

This bug lies since at least 3.2.0 till the latest kernel(3.6.2).  Patch
is attached.

The following steps will reproduce the problem.

1. prepair a block device (eg /dev/sdb).

2. create two partitions:

   sudo parted /dev/sdb
   mklabel gpt
   mkpart primary 0% 50%
   mkpart primary 50% 100%

3. create a md device.

   sudo mdadm -C /dev/md/hoge -l 1 -n 2 -e 1.2 --assume-clean --auto=md --symlink=no /dev/sdb1 /dev/sdb2

4. create file system and mount it

   sudo mkfs.ext3 /dev/md/hoge
   sudo mkdir /mnt/test
   sudo mount /dev/md/hoge /mnt/test

5. try to resize the device

   sudo mdadm -G /dev/md/hoge --size=max

6. create a file to fill file cache.

  sudo dd if=/dev/urandom of=/mnt/test/data bs=1M count=10

and verify the current status of file by free command.

7. mdadm monitor will open the md device every 1000 seconds and you
   will find all file cache on the device are cleared.

The timing can be reduced by the following steps.

a) kill mdadm and restart it with --delay option

   /sbin/mdadm --monitor --delay=30 --pid-file /var/run/mdadm/ --daemonise --scan --syslog

or open the md device directly.

   sudo dd if=/dev/md/hoge of=/dev/null bs=4096 count=1

Signed-off-by: MITSUNARI Shigeo <>
Cc: Al Viro <>
Cc: Jeff Moyer <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Junxiao Bi ocfs2: unlock super lock if lockres refresh failed
commit 3278bb7 upstream.

If lockres refresh failed, the super lock will never be released which
will cause some processes on other cluster nodes hung forever.

Signed-off-by: Junxiao Bi <>
Cc: Joel Becker <>
Cc: Mark Fasheh <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Lars-Peter Clausen larsclausen drivers/video/backlight/adp88?0_bl.c: fix resume
commit 5eb02c0 upstream.

Clearing the NSTBY bit in the control register also automatically clears
the BLEN bit.  So we need to make sure to set it again during resume,
otherwise the backlight will stay off.

Signed-off-by: Lars-Peter Clausen <>
Acked-by: Michael Hennerich <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Greg Thelen tmpfs: fix use-after-free of mempolicy object
commit 5f00110 upstream.

The tmpfs remount logic preserves filesystem mempolicy if the mpol=M
option is not specified in the remount request.  A new policy can be
specified if mpol=M is given.

Before this patch remounting an mpol bound tmpfs without specifying
mpol= mount option in the remount request would set the filesystem's
mempolicy object to a freed mempolicy object.

To reproduce the problem boot a DEBUG_PAGEALLOC kernel and run:
    # mkdir /tmp/x

    # mount -t tmpfs -o size=100M,mpol=interleave nodev /tmp/x

    # grep /tmp/x /proc/mounts
    nodev /tmp/x tmpfs rw,relatime,size=102400k,mpol=interleave:0-3 0 0

    # mount -o remount,size=200M nodev /tmp/x

    # grep /tmp/x /proc/mounts
    nodev /tmp/x tmpfs rw,relatime,size=204800k,mpol=??? 0 0
        # note ? garbage in mpol=... output above

    # dd if=/dev/zero of=/tmp/x/f count=1
        # panic here

    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<          (null)>]           (null)
    Oops: 0010 [#1] SMP DEBUG_PAGEALLOC
    Call Trace:

Non-debug kernels will not crash immediately because referencing the
dangling mpol will not cause a fault.  Instead the filesystem will
reference a freed mempolicy object, which will cause unpredictable

The problem boils down to a dropped mpol reference below if
shmem_parse_options() does not allocate a new mpol:

    config = *sbinfo
    shmem_parse_options(data, &config, true)
    sbinfo->mpol = config.mpol  /* BUG: saves unreferenced mpol */

This patch avoids the crash by not releasing the mempolicy if
shmem_parse_options() doesn't create a new mpol.

How far back does this issue go? I see it in both 2.6.36 and 3.3.  I did
not look back further.

Signed-off-by: Greg Thelen <>
Acked-by: Hugh Dickins <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Mel Gorman mm/fadvise.c: drain all pagevecs if POSIX_FADV_DONTNEED fails to disc…
…ard all pages

commit 67d46b2 upstream.

Rob van der Heij reported the following (paraphrased) on private mail.

	The scenario is that I want to avoid backups to fill up the page
	cache and purge stuff that is more likely to be used again (this is
	with s390x Linux on z/VM, so I don't give it as much memory that
	we don't care anymore). So I have something with LD_PRELOAD that
	intercepts the close() call (from tar, in this case) and issues
	a posix_fadvise() just before closing the file.

	This mostly works, except for small files (less than 14 pages)
	that remains in page cache after the face.

Unfortunately Rob has not had a chance to test this exact patch but the
test program below should be reproducing the problem he described.

The issue is the per-cpu pagevecs for LRU additions.  If the pages are
added by one CPU but fadvise() is called on another then the pages
remain resident as the invalidate_mapping_pages() only drains the local
pagevecs via its call to pagevec_release().  The user-visible effect is
that a program that uses fadvise() properly is not obeyed.

A possible fix for this is to put the necessary smarts into
invalidate_mapping_pages() to globally drain the LRU pagevecs if a
pagevec page could not be discarded.  The downside with this is that an
inode cache shrink would send a global IPI and memory pressure
potentially causing global IPI storms is very undesirable.

Instead, this patch adds a check during fadvise(POSIX_FADV_DONTNEED) to
check if invalidate_mapping_pages() discarded all the requested pages.
If a subset of pages are discarded it drains the LRU pagevecs and tries
again.  If the second attempt fails, it assumes it is due to the pages
being mapped, locked or dirty and does not care.  With this patch, an
application using fadvise() correctly will be obeyed but there is a
downside that a malicious application can force the kernel to send
global IPIs and increase overhead.

If accepted, I would like this to be considered as a -stable candidate.
It's not an urgent issue but it's a system call that is not working as
advertised which is weak.

The following test program demonstrates the problem.  It should never
report that pages are still resident but will without this patch.  It
assumes that CPU 0 and 1 exist.

int main() {
	int fd;
	int pagesize = getpagesize();
	ssize_t written = 0, expected;
	char *buf;
	unsigned char *vec;
	int resident, i;
	cpu_set_t set;

	/* Prepare a buffer for writing */
	expected = FILESIZE_PAGES * pagesize;
	buf = malloc(expected + 1);
	if (buf == NULL) {
	buf[expected] = 0;
	memset(buf, 'a', expected);

	/* Prepare the mincore vec */
	vec = malloc(FILESIZE_PAGES);
	if (vec == NULL) {

	/* Bind ourselves to CPU 0 */
	CPU_SET(0, &set);
	if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) {

	/* open file, unlink and write buffer */
	fd = open("fadvise-test-file", O_CREAT|O_EXCL|O_RDWR);
	if (fd == -1) {
	while (written < expected) {
		ssize_t this_write;
		this_write = write(fd, buf + written, expected - written);

		if (this_write == -1) {

		written += this_write;

	 * Force ourselves to another CPU. If fadvise only flushes the local
	 * CPUs pagevecs then the fadvise will fail to discard all file pages
	CPU_SET(1, &set);
	if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) {

	/* sync and fadvise to discard the page cache */
	if (posix_fadvise(fd, 0, expected, POSIX_FADV_DONTNEED) == -1) {

	/* map the file and use mincore to see which parts of it are resident */
	buf = mmap(NULL, expected, PROT_READ, MAP_SHARED, fd, 0);
	if (buf == NULL) {
	if (mincore(buf, expected, vec) == -1) {

	/* Check residency */
	for (i = 0, resident = 0; i < FILESIZE_PAGES; i++) {
		if (vec[i])
	if (resident != 0) {
		printf("Nr unexpected pages resident: %d\n", resident);

	munmap(buf, expected);

Signed-off-by: Mel Gorman <>
Reported-by: Rob van der Heij <>
Tested-by: Rob van der Heij <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Jan Beulich jbeulich xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()
commit 51ac889 upstream.

... as being guest triggerable (e.g. by invoking
XEN_PCI_OP_enable_msi{,x} on a device not being MSI/MSI-X capable).

This is CVE-2013-0231 / XSA-43.

Also make the two messages uniform in both their wording and severity.

Signed-off-by: Jan Beulich <>
Acked-by: Ian Campbell <>
Reviewed-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
Grant Likely drivercore: Fix ordering between deferred_probe and exiting initcalls
commit d72cca1 upstream.

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 <>
Tested-by: Haojian Zhuang <>
Cc: Arnd Bergmann <>
Cc: Russell King <>
Cc: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
fanchaoting umount oops when remove blocklayoutdriver first
commit 5a12cca upstream.

now pnfs client uses block layout, maybe we can remove
blocklayoutdriver first. if we umount later,
it can cause oops in unset_pnfs_layoutdriver.
because nfss->pnfs_curr_ld->clear_layoutdriver is invalid.

reproduce it:
 modprobe  blocklayoutdriver
 mount -t nfs4 -o minorversion=1 pnfsip:/ /mnt/
 rmmod blocklayoutdriver
 umount /mnt

then you can see following

Pid: 17023, comm: umount.nfs4 Tainted: GF          O 3.7.0-rc6-pnfs #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
RIP: 0010:[<ffffffffa04cfe6d>]  [<ffffffffa04cfe6d>] unset_pnfs_layoutdriver+0x1d/0x70 [nfsv4]
RSP: 0018:ffff8800022d9e48  EFLAGS: 00010286
RAX: ffffffffa04a1b00 RBX: ffff88000b013800 RCX: 0000000000000001
RDX: ffffffff81ae8ee0 RSI: ffff880001ee94b8 RDI: ffff88000b013800
RBP: ffff8800022d9e58 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880001ee9400
R13: ffff8800105978c0 R14: 00007fff25846c08 R15: 0000000001bba550
FS:  00007f45ae7f0700(0000) GS:ffff880012c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffffa04a1b38 CR3: 0000000002c0c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process umount.nfs4 (pid: 17023, threadinfo ffff8800022d8000, task ffff880006e48aa0)
ffff8800105978c0 ffff88000b013800 ffff8800022d9e78 ffffffffa04cd0ce
ffff8800022d9e78 ffff88000b013800 ffff8800022d9ea8 ffffffffa04755a7
ffff8800022d9ea8 ffff880002f96400 ffff88000b013800 ffff880002f96400
Call Trace:
[<ffffffffa04cd0ce>] nfs4_destroy_server+0x1e/0x30 [nfsv4]
[<ffffffffa04755a7>] nfs_free_server+0xb7/0x150 [nfs]
[<ffffffffa047d4d5>] nfs_kill_super+0x35/0x40 [nfs]
[<ffffffff81178d35>] deactivate_locked_super+0x45/0x70
[<ffffffff8117986a>] deactivate_super+0x4a/0x70
[<ffffffff81193ee2>] mntput_no_expire+0xd2/0x130
[<ffffffff81194d62>] sys_umount+0x72/0xe0
[<ffffffff8154af59>] system_call_fastpath+0x16/0x1b
Code: 06 e1 b8 ea ff ff ff eb 9e 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 8b 87 80 03 00 00 48 89 fb 48 85 c0 74 29 <48> 8b 40 38 48 85 c0 74 02 ff d0 48 8b 03 3e ff 48 04 0f 94 c2
RIP  [<ffffffffa04cfe6d>] unset_pnfs_layoutdriver+0x1d/0x70 [nfsv4]
RSP <ffff8800022d9e48>
CR2: ffffffffa04a1b38
---[ end trace 29f75aaedda058bf ]---

Signed-off-by: fanchaoting<>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
Trond Myklebust NLM: Ensure that we resend all pending blocking locks after a reclaim
commit 666b3d8 upstream.

Currently, nlmclnt_lock will break out of the for(;;) loop when
the reclaimer wakes up the blocking lock thread by setting
nlm_lck_denied_grace_period. This causes the lock request to fail
with an ENOLCK error.
The intention was always to ensure that we resend the lock request
after the grace period has expired.

Reported-by: Wangyuan Zhang <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
Weston Andros Adamson NFSv4.1: Don't decode skipped layoutgets
commit 085b7a4 upstream.

layoutget's prepare hook can call rpc_exit with status = NFS4_OK (0).
Because of this, nfs4_proc_layoutget can't depend on a 0 status to mean
that the RPC was successfully sent, received and parsed.

To fix this, use the result's len member to see if parsing took place.

This fixes the following OOPS -- calling xdr_init_decode() with a buffer length
0 doesn't set the stream's 'p' member and ends up using uninitialized memory
in filelayout_decode_layout.

BUG: unable to handle kernel paging request at 0000000000008050
IP: [<ffffffff81282e78>] memcpy+0x18/0x120
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:11.0/0000:02:01.0/irq
Modules linked in: nfs_layout_nfsv41_files nfs lockd fscache auth_rpcgss nfs_acl autofs4 sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log dm_mod ppdev parport_pc parport snd_ens1371 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc e1000 microcode vmware_balloon i2c_piix4 i2c_core sg shpchp ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptspi mptscsih mptbase scsi_transport_spi [last unloaded: speedstep_lib]

Pid: 1665, comm: flush-0:22 Not tainted 2.6.32-356-test-2 #2 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
RIP: 0010:[<ffffffff81282e78>]  [<ffffffff81282e78>] memcpy+0x18/0x120
RSP: 0018:ffff88003dfab588  EFLAGS: 00010206
RAX: ffff88003dc42000 RBX: ffff88003dfab610 RCX: 0000000000000009
RDX: 000000003f807ff0 RSI: 0000000000008050 RDI: ffff88003dc42000
RBP: ffff88003dfab5b0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000080 R12: 0000000000000024
R13: ffff88003dc42000 R14: ffff88003f808030 R15: ffff88003dfab6a0
FS:  0000000000000000(0000) GS:ffff880003420000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000008050 CR3: 000000003bc92000 CR4: 00000000001407e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process flush-0:22 (pid: 1665, threadinfo ffff88003dfaa000, task ffff880037f77540)
ffffffffa0398ac1 ffff8800397c5940 ffff88003dfab610 ffff88003dfab6a0
<d> ffff88003dfab5d0 ffff88003dfab680 ffffffffa01c150b ffffea0000d82e70
<d> 000000508116713b 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[<ffffffffa0398ac1>] ? xdr_inline_decode+0xb1/0x120 [sunrpc]
[<ffffffffa01c150b>] filelayout_decode_layout+0xeb/0x350 [nfs_layout_nfsv41_files]
[<ffffffffa01c17fc>] filelayout_alloc_lseg+0x8c/0x3c0 [nfs_layout_nfsv41_files]
[<ffffffff8150e6ce>] ? __wait_on_bit+0x7e/0x90

Signed-off-by: Weston Andros Adamson <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
Tomasz Guszkowski p54usb: corrected USB ID for T-Com Sinus 154 data II
commit 008e33f upstream.

Corrected USB ID for T-Com Sinus 154 data II. ISL3887-based. The
device was tested in managed mode with no security, WEP 128
bit and WPA-PSK (TKIP) with firmware (md5sum:
7d676323ac60d6e1a3b6d61e8c528248). It works.

Signed-off-by: Tomasz Guszkowski <>
Acked-By: Christian Lamparter <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
cladisch cladisch ALSA: usb-audio: fix Roland A-PRO support
commit 7da5804 upstream.

The quirk for the Roland/Cakewalk A-PRO keyboards accidentally used the
wrong interface number, which prevented the driver from attaching to the

Signed-off-by: Clemens Ladisch <>
Signed-off-by: Greg Kroah-Hartman <>
Pawel Moll ALSA: usb: Fix Processing Unit Descriptor parsers
commit b531f81 upstream.

Commit 99fc864 "ALSA: usb-mixer:
parse descriptors with structs" introduced a set of useful parsers
for descriptors. Unfortunately the parses for the Processing Unit
Descriptor came with a very subtle bug...

Functions uac_processing_unit_iProcessing() and
uac_processing_unit_specific() were indexing the baSourceID array
forgetting the fields before the iProcessing and process-specific

The problem was observed with Sound Blaster Extigy mixer,
where nNrModes in Up/Down-mix Processing Unit Descriptor
was accessed at offset 10 of the descriptor (value 0)
instead of offset 15 (value 7). In result the resulting
control had interesting limit values:

Simple mixer control 'Channel Routing Mode Select',0
  Capabilities: volume volume-joined penum
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - -1
  Mono: -1 [100%]

Fixed by starting from the bmControls, which was calculated
correctly, instead of baSourceID.

Now the mentioned control is fine:

Simple mixer control 'Channel Routing Mode Select',0
  Capabilities: volume volume-joined penum
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 6
  Mono: 0 [0%]

Signed-off-by: Pawel Moll <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
Takashi Iwai tiwai ALSA: hda - Release assigned pin/cvt at error path of hdmi_pcm_open()
commit 2ad779b upstream.

If the driver detects and invalid ELD, it gives an open error.
But it forgot to release the assigned pin, converter and spdif ctls
before returning.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
Anssi Hannula anssih ALSA: hda - Fix default multichannel HDMI mapping regression
commit 2060873 upstream.

Commit d45e688 ("ALSA: hda - Provide
the proper channel mapping for generic HDMI driver") added support for
custom channel maps in the HDA HDMI driver. Due to a mistake in an
'if' condition the custom map is always used even when no such map has
been set. This causes incorrect channel mapping for multichannel audio
by default.

Pass per_pin->chmap_set to hdmi_setup_channel_mapping() as a parameter
so that it can use it for detecting if a custom map has been set instead
of checking if map is NULL (which is never the case).

Reported-by: Staffan Lindberg <>
Signed-off-by: Anssi Hannula <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
Fernando Luis Vazquez Cao ALSA: hda - Workaround for silent output on Sony Vaio VGC-LN51JGB wit…
…h ALC889

commit 12e31a7 upstream.

Some Vaio all-in-one desktop PCs (for example VGC-LN51JGB) are affected by
the same issue that caused Vaio Z laptops to become silent: the speaker pin
must be connected to the first DAC even though the codec itself advertises
flexible routing through any of the DACs.

Use the no-primary-hp fixup for choosing the speaker pin as the primary so
that the right DAC is assigned on this device.

Signed-off-by: Fernando Luis Vazquez Cao <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
diwic diwic ALSA: hda - hdmi: ELD shouldn't be valid after unplug
commit bbfd8a1 upstream.

Currently, eld_valid is never set to false, except at kernel module
load time. This patch makes sure that eld is no longer valid when
the cable is (hot-)unplugged.

Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
Bob Peterson GFS2: Get a block reservation before resizing a file
commit d2b47cf upstream.

This patch allocates a block reservation structure before growing
or shrinking a file. Without this structure, the grow or shink code
can reference the bad pointer.

Signed-off-by: Bob Peterson <>
Signed-off-by: Steven Whitehouse <>
Signed-off-by: Greg Kroah-Hartman <>
davem330 davem330 sunvdc: Fix off-by-one in generic_request().
[ Upstream commit f4d9605 ]

The 'operations' bitmap corresponds one-for-one with the operation
codes, no adjustment is necessary.

Reported-by: Mark Kettenis <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
davem330 davem330 sparc64: Add missing HAVE_ARCH_TRANSPARENT_HUGEPAGE.
[ Upstream commit b9156eb ]

This got missed in the cleanups done for the S390 THP

CC: Gerald Schaefer <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
davem330 davem330 sparc64: Fix get_user_pages_fast() wrt. THP.
[ Upstream commit 89a7791 ]

Mostly mirrors the s390 logic, as unlike x86 we don't need the
SetPageReferenced() bits.

On sparc64 we also lack a user/privileged bit in the huge PMDs.

In order to make this work for THP and non-THP builds, some header
file adjustments were necessary.  Namely, provide the PMD_HUGE_* bit
defines and the pmd_large() inline unconditionally rather than

Reported-by: Aneesh Kumar K.V <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
davem330 davem330 sparc64: Fix gfp_flags setting in tsb_grow().
[ Upstream commit a55ee1f ]

We should "|= more_flags" rather than "= more_flags".

Reported-by: David Rientjes <>
Acked-by: David Rientjes <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
davem330 davem330 sparc64: Handle hugepage TSB being NULL.
[ Upstream commit bcd896b ]

Accomodate the possibility that the TSB might be NULL at
the point that update_mmu_cache() is invoked.  This is
necessary because we will sometimes need to defer the TSB
allocation to the first fault that happens in the 'mm'.

Seperate out the hugepage PTE test into a seperate function
so that the logic is clearer.

Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
davem330 davem330 sparc64: Fix tsb_grow() in atomic context.
[ Upstream commit 0fbebed ]

If our first THP installation for an MM is via the set_pmd_at() done
during khugepaged's collapsing we'll end up in tsb_grow() trying to do
a GFP_KERNEL allocation with several locks held.

Simply using GFP_ATOMIC in this situation is not the best option
because we really can't have this fail, so we'd really like to keep
this an order 0 GFP_KERNEL allocation if possible.

Also, doing the TSB allocation from khugepaged is a really bad idea
because we'll allocate it potentially from the wrong NUMA node in that

So what we do is defer the hugepage TSB allocation until the first TLB
miss we take on a hugepage.  This is slightly tricky because we have
to handle two unusual cases:

1) Taking the first hugepage TLB miss in the window trap handler.
   We'll call the winfix_trampoline when that is detected.

2) An initial TSB allocation via TLB miss races with a hugetlb
   fault on another cpu running the same MM.  We handle this by
   unconditionally loading the TSB we see into the current cpu
   even if it's non-NULL at hugetlb_setup time.

Reported-by: Meelis Roos <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
davem330 davem330 sparc64: Fix huge PMD to PTE translation for sun4u in TLB miss handler.
[ Upstream commit 76968ad ]

When we set the sun4u version of the PTE execute bit, it's:


_PAGE_EXEC_4U is 0x1000, unfortunately the immedate field of the
'or' instruction is a signed 13-bit value.  So the above actually
assembles into:

	or	REG, -4096, REG

completely corrupting the final PTE value.

Set it with a:

	sethi	%hi(_PAGE_EXEC_4U), TMP

sequence instead.

This fixes "git gc" crashes on sun4u machines.

Reported-by: Meelis Roos <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
Adam Jackson nwnk drm/i915: Fix up mismerge of 3490ea5 in 3.7.y
The 3.7.y version of this seems to have missed a hunk in i9xx_update_wm.

Tested-by: Glen Gray <>
Signed-off-by: Adam Jackson <>
Signed-off-by: Greg Kroah-Hartman <>
Nicholas Bellinger target: Fix divide by zero bug in fabric_max_sectors for unconfigured…
… devices

commit 7a3cf6c upstream

This patch fixes a possible divide by zero bug when the fabric_max_sectors
device attribute is written and backend se_device failed to be successfully
configured -> enabled.

Go ahead and use block_size=512 within se_dev_set_fabric_max_sectors()
in the event of a target_configure_device() failure case, as no valid
dev->dev_attrib.block_size value will have been setup yet.

Signed-off-by: Nicholas Bellinger <>
Cc: Herton Ronaldo Krzesinski <>
Signed-off-by: Greg Kroah-Hartman <>
minipli minipli sock_diag: Fix out-of-bounds access to sock_diag_handlers[]
[ Upstream commit 6e601a5 ]

Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
with a family greater or equal then AF_MAX -- the array size of
sock_diag_handlers[]. The current code does not test for this
condition therefore is vulnerable to an out-of-bound access opening
doors for a privilege escalation.

Signed-off-by: Mathias Krause <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
Greg Kroah-Hartman gregkh Linux 3.7.10 356d8c6