]> git.itanic.dy.fi Git - linux-stable/log
linux-stable
11 years agoLinux 2.6.34.12 v2.6.34.12
Paul Gortmaker [Thu, 17 May 2012 15:27:28 +0000 (11:27 -0400)]
Linux 2.6.34.12

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agox86/PCI: do not tie MSI MS-7253 use_crs quirk to BIOS version
Jonathan Nieder [Tue, 28 Feb 2012 21:31:35 +0000 (15:31 -0600)]
x86/PCI: do not tie MSI MS-7253 use_crs quirk to BIOS version

commit a97f4f5e524bcd09a85ef0b8821a14d35e69335f upstream.

Carlos was getting

WARNING: at drivers/pci/pci.c:118 pci_ioremap_bar+0x24/0x52()

when probing his sound card, and sound did not work.  After adding
pci=use_crs to the kernel command line, no more trouble.

Ok, we can add a quirk.  dmidecode output reveals that this is an MSI
MS-7253, for which we already have a quirk, but the short-sighted
author tied the quirk to a single BIOS version, making it not kick in
on Carlos's machine with BIOS V1.2.  If a later BIOS update makes it
no longer necessary to look at the _CRS info it will still be
harmless, so let's stop trying to guess which versions have and don't
have accurate _CRS tables.

Addresses https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5533
Also see <https://bugzilla.kernel.org/show_bug.cgi?id=42619>.

Reported-by: Carlos Luna <caralu74@gmail.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agox86/PCI: use host bridge _CRS info on MSI MS-7253
Jonathan Nieder [Tue, 28 Feb 2012 18:51:10 +0000 (11:51 -0700)]
x86/PCI: use host bridge _CRS info on MSI MS-7253

commit 8411371709610c826bf65684f886bfdfb5780ca1 upstream.

In the spirit of commit 29cf7a30f8a0 ("x86/PCI: use host bridge _CRS
info on ASUS M2V-MX SE"), this DMI quirk turns on "pci_use_crs" by
default on a board that needs it.

This fixes boot failures and oopses introduced in 3e3da00c01d0
("x86/pci: AMD one chain system to use pci read out res").  The quirk
is quite targetted (to a specific board and BIOS version) for two
reasons:

 (1) to emphasize that this method of tackling the problem one quirk
     at a time is a little insane

 (2) to give BIOS vendors an opportunity to use simpler tables and
     allow us to return to generic behavior (whatever that happens to
     be) with a later BIOS update

In other words, I am not at all happy with having quirks like this.
But it is even worse for the kernel not to work out of the box on
these machines, so...

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42619
Reported-by: Svante Signell <svante.signell@telia.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoscore: fix off-by-one index into syscall table
Dan Rosenberg [Fri, 20 Jan 2012 22:34:27 +0000 (14:34 -0800)]
score: fix off-by-one index into syscall table

commit c25a785d6647984505fa165b5cd84cfc9a95970b upstream.

If the provided system call number is equal to __NR_syscalls, the
current check will pass and a function pointer just after the system
call table may be called, since sys_call_table is an array with total
size __NR_syscalls.

Whether or not this is a security bug depends on what the compiler puts
immediately after the system call table.  It's likely that this won't do
anything bad because there is an additional NULL check on the syscall
entry, but if there happens to be a non-NULL value immediately after the
system call table, this may result in local privilege escalation.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: <stable@vger.kernel.org>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Cc: Lennox Wu <lennox.wu@gmail.com>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agotty: fix warning in synclink driver
Andres Salomon [Tue, 9 Nov 2010 22:10:38 +0000 (14:10 -0800)]
tty: fix warning in synclink driver

commit dc98d9650891661a20842a8eef9e76536046d897 upstream.

During builds I see the following warning -

  CC [M]  drivers/char/pcmcia/synclink_cs.o
drivers/char/pcmcia/synclink_cs.c:2194: warning: ‘mgslpc_get_icount’ defined but not used

The function is a callback meant to be assigned to get_icount (added during 0587102cf).
Fix accordingly.

Signed-off-by: Andres Salomon <dilinger@queued.net>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agonozomi: Fix warning from the previous TIOCGCOUNT changes
Alan Cox [Tue, 26 Oct 2010 14:56:34 +0000 (15:56 +0100)]
nozomi: Fix warning from the previous TIOCGCOUNT changes

commit 68e29655cc51761d60d5f27b2738816a5b13e415 upstream.

Just remove a now unused variable

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agotty: icount changeover for other main devices
Alan Cox [Thu, 16 Sep 2010 17:21:52 +0000 (18:21 +0100)]
tty: icount changeover for other main devices

commit 0587102cf9f427c185bfdeb2cef41e13ee0264b1 upstream.

Again basically cut and paste

Convert the main driver set to use the hooks for GICOUNT

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agotty: Make tiocgicount a handler
Alan Cox [Thu, 16 Sep 2010 17:21:24 +0000 (18:21 +0100)]
tty: Make tiocgicount a handler

commit d281da7ff6f70efca0553c288bb883e8605b3862 upstream.

Dan Rosenberg noted that various drivers return the struct with uncleared
fields. Instead of spending forever trying to stomp all the drivers that
get it wrong (and every new driver) do the job in one place.

This first patch adds the needed operations and hooks them up, including
the needed USB midlayer and serial core plumbing.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoigb: Fix lack of flush after register write and before delay
Carolyn Wyborny [Sat, 25 Jun 2011 13:18:12 +0000 (13:18 +0000)]
igb: Fix lack of flush after register write and before delay

commit 064b43304ed8ede8e13ff7b4338d09fd37bcffb1 upstream.

Register writes followed by a delay are required to have a flush
before the delay in order to commit the values to the register.  Without
the flush, the code following the delay may not function correctly.

Reported-by: Tong Ho <tong.ho@ericsson.com>
Reported-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agofuse: check size of FUSE_NOTIFY_INVAL_ENTRY message
Miklos Szeredi [Wed, 24 Aug 2011 08:20:17 +0000 (10:20 +0200)]
fuse: check size of FUSE_NOTIFY_INVAL_ENTRY message

commit c2183d1e9b3f313dd8ba2b1b0197c8d9fb86a7ae upstream.

FUSE_NOTIFY_INVAL_ENTRY didn't check the length of the write so the
message processing could overrun and result in a "kernel BUG at
fs/fuse/dev.c:629!"

Reported-by: Han-Wen Nienhuys <hanwenn@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agodrm/ttm: fix ttm_bo_add_ttm(user) failure path
Marcin Slusarz [Mon, 22 Aug 2011 21:17:57 +0000 (21:17 +0000)]
drm/ttm: fix ttm_bo_add_ttm(user) failure path

commit 7c4c3960dff109bc5db4c35da481c212dadb5eb5 upstream.

ttm_tt_destroy kfrees passed object, so we need to nullify
a reference to it.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agox86, UV: Remove UV delay in starting slave cpus
Jack Steiner [Fri, 5 Aug 2011 14:09:00 +0000 (09:09 -0500)]
x86, UV: Remove UV delay in starting slave cpus

commit 05e33fc20ea5e493a2a1e7f1d04f43cdf89f83ed upstream.

Delete the 10 msec delay between the INIT and SIPI when starting
slave cpus. I can find no requirement for this delay. BIOS also
has similar code sequences without the delay.

Removing the delay reduces boot time by 40 sec. Every bit helps.

Signed-off-by: Jack Steiner <steiner@sgi.com>
Link: http://lkml.kernel.org/r/20110805140900.GA6774@sgi.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agox86-32, vdso: On system call restart after SYSENTER, use int $0x80
H. Peter Anvin [Mon, 22 Aug 2011 20:27:06 +0000 (13:27 -0700)]
x86-32, vdso: On system call restart after SYSENTER, use int $0x80

commit 7ca0758cdb7c241cb4e0490a8d95f0eb5b861daf upstream.

When we enter a 32-bit system call via SYSENTER or SYSCALL, we shuffle
the arguments to match the int $0x80 calling convention.  This was
probably a design mistake, but it's what it is now.  This causes
errors if the system call as to be restarted.

For SYSENTER, we have to invoke the instruction from the vdso as the
return address is hardcoded.  Accordingly, we can simply replace the
jump in the vdso with an int $0x80 instruction and use the slower
entry point for a post-restart.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/CA%2B55aFztZ=r5wa0x26KJQxvZOaQq8s2v3u50wCyJcA-Sc4g8gQ@mail.gmail.com
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agofutex: Fix uninterruptible loop due to gate_area
Hugh Dickins [Sat, 31 Dec 2011 19:44:01 +0000 (11:44 -0800)]
futex: Fix uninterruptible loop due to gate_area

commit e6780f7243eddb133cc20ec37fa69317c218b709 upstream.

It was found (by Sasha) that if you use a futex located in the gate
area we get stuck in an uninterruptible infinite loop, much like the
ZERO_PAGE issue.

While looking at this problem, PeterZ realized you'll get into similar
trouble when hitting any install_special_pages() mapping.  And are there
still drivers setting up their own special mmaps without page->mapping,
and without special VM or pte flags to make get_user_pages fail?

In most cases, if page->mapping is NULL, we do not need to retry at all:
Linus points out that even /proc/sys/vm/drop_caches poses no problem,
because it ends up using remove_mapping(), which takes care not to
interfere when the page reference count is raised.

But there is still one case which does need a retry: if memory pressure
called shmem_writepage in between get_user_pages_fast dropping page
table lock and our acquiring page lock, then the page gets switched from
filecache to swapcache (and ->mapping set to NULL) whatever the refcount.
Fault it back in to get the page->mapping needed for key->shared.inode.

Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PG: 2.6.34 variable is page, not page_head, since it doesn't have a5b338f2]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agofutex: Fix regression with read only mappings
Shawn Bohrer [Thu, 30 Jun 2011 16:21:32 +0000 (11:21 -0500)]
futex: Fix regression with read only mappings

commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae upstream.

commit 7485d0d3758e8e6491a5c9468114e74dc050785d (futexes: Remove rw
parameter from get_futex_key()) in 2.6.33 fixed two problems:  First, It
prevented a loop when encountering a ZERO_PAGE. Second, it fixed RW
MAP_PRIVATE futex operations by forcing the COW to occur by
unconditionally performing a write access get_user_pages_fast() to get
the page.  The commit also introduced a user-mode regression in that it
broke futex operations on read-only memory maps.  For example, this
breaks workloads that have one or more reader processes doing a
FUTEX_WAIT on a futex within a read only shared file mapping, and a
writer processes that has a writable mapping issuing the FUTEX_WAKE.

This fixes the regression for valid futex operations on RO mappings by
trying a RO get_user_pages_fast() when the RW get_user_pages_fast()
fails. This change makes it necessary to also check for invalid use
cases, such as anonymous RO mappings (which can never change) and the
ZERO_PAGE which the commit referenced above was written to address.

This patch does restore the original behavior with RO MAP_PRIVATE
mappings, which have inherent user-mode usage problems and don't really
make sense.  With this patch performing a FUTEX_WAIT within a RO
MAP_PRIVATE mapping will be successfully woken provided another process
updates the region of the underlying mapped file.  However, the mmap()
man page states that for a MAP_PRIVATE mapping:

  It is unspecified whether changes made to the file after
  the mmap() call are visible in the mapped region.

So user-mode users attempting to use futex operations on RO MAP_PRIVATE
mappings are depending on unspecified behavior.  Additionally a
RO MAP_PRIVATE mapping could fail to wake up in the following case.

  Thread-A: call futex(FUTEX_WAIT, memory-region-A).
            get_futex_key() return inode based key.
            sleep on the key
  Thread-B: call mprotect(PROT_READ|PROT_WRITE, memory-region-A)
  Thread-B: write memory-region-A.
            COW happen. This process's memory-region-A become related
            to new COWed private (ie PageAnon=1) page.
  Thread-B: call futex(FUETX_WAKE, memory-region-A).
            get_futex_key() return mm based key.
            IOW, we fail to wake up Thread-A.

Once again doing something like this is just silly and users who do
something like this get what they deserve.

While RO MAP_PRIVATE mappings are nonsensical, checking for a private
mapping requires walking the vmas and was deemed too costly to avoid a
userspace hang.

This Patch is based on Peter Zijlstra's initial patch with modifications to
only allow RO mappings for futex operations that need VERIFY_READ access.

Reported-by: David Oliver <david@rgmadvisors.com>
Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: peterz@infradead.org
Cc: eric.dumazet@gmail.com
Cc: zvonler@rgmadvisors.com
Cc: hughd@google.com
Link: http://lkml.kernel.org/r/1309450892-30676-1-git-send-email-sbohrer@rgmadvisors.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[PG: in 34, the variable is "page"; in original 9ea71503a it is page_head]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoALSA: ac97: Add HP Compaq dc5100 SFF(PT003AW) to Headphone Jack Sense whitelist
Daniel T Chen [Mon, 15 Aug 2011 02:43:01 +0000 (22:43 -0400)]
ALSA: ac97: Add HP Compaq dc5100 SFF(PT003AW) to Headphone Jack Sense whitelist

commit eade7b281c9fc18401b989c77d5e5e660b25a3b7 upstream.

BugLink: https://bugs.launchpad.net/bugs/826081
The original reporter needs 'Headphone Jack Sense' enabled to have
audible audio, so add his PCI SSID to the whitelist.

Reported-and-tested-by: Muhammad Khurram Khan
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoALSA: snd_usb_caiaq: track submitted output urbs
Daniel Mack [Sun, 14 Aug 2011 09:31:16 +0000 (11:31 +0200)]
ALSA: snd_usb_caiaq: track submitted output urbs

commit da6094ea7d3c2295473d8f5134279307255d6ebf upstream.

The snd_usb_caiaq driver currently assumes that output urbs are serviced
in time and doesn't track when and whether they are given back by the
USB core. That usually works fine, but due to temporary limitations of
the XHCI stack, we faced that urbs were submitted more than once with
this approach.

As it's no good practice to fire and forget urbs anyway, this patch
introduces a proper bit mask to track which requests have been submitted
and given back.

That alone however doesn't make the driver work in case the host
controller is broken and doesn't give back urbs at all, and the output
stream will stop once all pre-allocated output urbs are consumed. But
it does prevent crashes of the controller stack in such cases.

See http://bugzilla.kernel.org/show_bug.cgi?id=40702 for more details.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-and-tested-by: Matej Laitl <matej@laitl.cz>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoperf tools: do not look at ./config for configuration
Jonathan Nieder [Fri, 5 Aug 2011 16:58:38 +0000 (18:58 +0200)]
perf tools: do not look at ./config for configuration

commit aba8d056078e47350d85b06a9cabd5afcc4b72ea upstream.

In addition to /etc/perfconfig and $HOME/.perfconfig, perf looks for
configuration in the file ./config, imitating git which looks at
$GIT_DIR/config.  If ./config is not a perf configuration file, it
fails, or worse, treats it as a configuration file and changes behavior
in some unexpected way.

"config" is not an unusual name for a file to be lying around and perf
does not have a private directory dedicated for its own use, so let's
just stop looking for configuration in the cwd.  Callers needing
context-sensitive configuration can use the PERF_CONFIG environment
variable.

Requested-by: Christian Ohm <chr.ohm@gmx.net>
Cc: 632923@bugs.debian.org
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Christian Ohm <chr.ohm@gmx.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20110805165838.GA7237@elie.gateway.2wire.net
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agomm: fix wrong vmap address calculations with odd NR_CPUS values
Clemens Ladisch [Tue, 21 Jun 2011 20:09:50 +0000 (22:09 +0200)]
mm: fix wrong vmap address calculations with odd NR_CPUS values

commit f982f91516fa4cfd9d20518833cd04ad714585be upstream.

Commit db64fe02258f ("mm: rewrite vmap layer") introduced code that does
address calculations under the assumption that VMAP_BLOCK_SIZE is a
power of two.  However, this might not be true if CONFIG_NR_CPUS is not
set to a power of two.

Wrong vmap_block index/offset values could lead to memory corruption.
However, this has never been observed in practice (or never been
diagnosed correctly); what caught this was the BUG_ON in vb_alloc() that
checks for inconsistent vmap_block indices.

To fix this, ensure that VMAP_BLOCK_SIZE always is a power of two.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=31572
Reported-by: Pavel Kysilka <goldenfish@linuxsoft.cz>
Reported-by: Matias A. Fonzo <selk@dragora.org>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoALSA: snd-usb-caiaq: Correct offset fields of outbound iso_frame_desc
Daniel Mack [Fri, 5 Aug 2011 11:49:52 +0000 (13:49 +0200)]
ALSA: snd-usb-caiaq: Correct offset fields of outbound iso_frame_desc

commit 15439bde3af7ff88459ea2b5520b77312e958df2 upstream.

This fixes faulty outbount packets in case the inbound packets
received from the hardware are fragmented and contain bogus input
iso frames. The bug has been there for ages, but for some strange
reasons, it was only triggered by newer machines in 64bit mode.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-and-tested-by: William Light <wrl@illest.net>
Reported-by: Pedro Ribeiro <pedrib@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agohwmon: (ibmaem) add missing kfree
Julia Lawall [Tue, 9 Aug 2011 15:10:56 +0000 (11:10 -0400)]
hwmon: (ibmaem) add missing kfree

commit 66a89b2164e2d30661edbd1953eacf0594d8203a upstream.

rs_resp is dynamically allocated in aem_read_sensor(), so it should be freed
before exiting in every case.  This collects the kfree and the return at
the end of the function.

Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoatm: br2864: sent packets truncated in VC routed mode
Chas Williams [Tue, 2 Aug 2011 00:56:14 +0000 (17:56 -0700)]
atm: br2864: sent packets truncated in VC routed mode

commit a08af810cdc29d2ca930e8a869d3d01744c392d8 upstream.

Reported-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoUSB: Serial: Added device ID for Qualcomm Modem in Sagemcom's HiLo3G
Vijay Chavan [Mon, 8 Aug 2011 21:11:12 +0000 (02:41 +0530)]
USB: Serial: Added device ID for Qualcomm Modem in Sagemcom's HiLo3G

commit e468561739fffb972d486b98f66c723936335136 upstream.

A new device ID pair is added for Qualcomm Modem present in Sagemcom's HiLo3G module.

Signed-off-by: Vijay Chavan <VijayChavan007@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoUSB: usb-storage: unusual_devs entry for ARM V2M motherboard.
Nick Bowler [Wed, 13 Jul 2011 15:40:09 +0000 (11:40 -0400)]
USB: usb-storage: unusual_devs entry for ARM V2M motherboard.

commit a871e4f5519d8c52430052e1d340dd5710eb5ad6 upstream.

Connecting the V2M to a Linux host results in a constant stream of
errors spammed to the console, all of the form

  sd 1:0:0:0: ioctl_internal_command return code = 8070000
     : Sense Key : 0x4 [current]
     : ASC=0x0 ASCQ=0x0

The errors appear to be otherwise harmless.  Add an unusual_devs entry
which eliminates all of the error messages.

Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PG: 2.6.34 uses US_ prefix, not USB_ prefix, change accordingly]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoUSB: assign instead of equal in usbtmc.c
Maxim Nikulin [Sat, 9 Jul 2011 16:44:44 +0000 (23:44 +0700)]
USB: assign instead of equal in usbtmc.c

commit 4f1a7a3e78037721496283ea3e87cfefc64d99c7 upstream.

Assign operator instead of equality test in the usbtmc_ioctl_abort_bulk_in() function.

Signed-off-by: Maxim A. Nikulin <M.A.Nikulin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoUSB: xhci: fix OS want to own HC
JiSheng Zhang [Sat, 16 Jul 2011 03:04:19 +0000 (11:04 +0800)]
USB: xhci: fix OS want to own HC

commit 6768458b17f9bf48a4c3a34e49b20344091b5f7e upstream.

Software should set XHCI_HC_OS_OWNED bit to request ownership of xHC.

This patch should be backported to kernels as far back as 2.6.31.

Signed-off-by: JiSheng Zhang <jszhang3@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agopowerpc: pseries: Fix kexec on machines with more than 4TB of RAM
Anton Blanchard [Tue, 26 Jul 2011 18:15:03 +0000 (18:15 +0000)]
powerpc: pseries: Fix kexec on machines with more than 4TB of RAM

commit bed9a31527af8ff3dfbad62a1a42815cef4baab7 upstream.

On a box with 8TB of RAM the MMU hashtable is 64GB in size. That
means we have 4G PTEs. pSeries_lpar_hptab_clear was using a signed
int to store the index which will overflow at 2G.

Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agopowerpc: Fix device tree claim code
Anton Blanchard [Mon, 25 Jul 2011 20:47:07 +0000 (20:47 +0000)]
powerpc: Fix device tree claim code

commit 966728dd88b4026ec58fee169ccceaeaf56ef120 upstream.

I have a box that fails in OF during boot with:

DEFAULT CATCH!, exception-handler=fff00400
at   %SRR0: 49424d2c4c6f6768   %SRR1: 800000004000b002

ie "IBM,Logh". OF got corrupted with a device tree string.

Looking at make_room and alloc_up, we claim the first chunk (1 MB)
but we never claim any more. mem_end is always set to alloc_top
which is the top of our available address space, guaranteeing we will
never call alloc_up and claim more memory.

Also alloc_up wasn't setting alloc_bottom to the bottom of the
available address space.

This doesn't help the box to boot, but we at least fail with
an obvious error. We could relocate the device tree in a future
patch.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoALSA: snd-usb-caiaq: Fix keymap for RigKontrol3
Daniel Mack [Sat, 6 Aug 2011 07:13:08 +0000 (09:13 +0200)]
ALSA: snd-usb-caiaq: Fix keymap for RigKontrol3

commit f4389489b5cbe60b3441869c68bb4afe760969c4 upstream.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: Renato <naretobh@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoALSA: timer - Fix Oops at closing slave timer
Takashi Iwai [Mon, 8 Aug 2011 10:24:46 +0000 (12:24 +0200)]
ALSA: timer - Fix Oops at closing slave timer

commit 0584ffa548b6e59aceb027112f23a55f0133400e upstream.

A slave-timer instance has no timer reference, and this results in
NULL-dereference at stopping the timer, typically called at closing
the device.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=40682

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agonet: Compute protocol sequence numbers and fragment IDs using MD5.
David S. Miller [Thu, 4 Aug 2011 03:50:44 +0000 (20:50 -0700)]
net: Compute protocol sequence numbers and fragment IDs using MD5.

commit 6e5714eaf77d79ae1c8b47e3e040ff5411b717ec upstream.

Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.

Reported-by: Dan Kaminsky <dan@doxpara.com>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
[PG: diffstat vs. 6e5714 differs, since no secure_ipv6_id to delete in 34]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agocrypto: Move md5_transform to lib/md5.c
David S. Miller [Thu, 4 Aug 2011 02:45:10 +0000 (19:45 -0700)]
crypto: Move md5_transform to lib/md5.c

commit bc0b96b54a21246e377122d54569eef71cec535f upstream.

We are going to use this for TCP/IP sequence number and fragment ID
generation.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agox86: HPET: Chose a paranoid safe value for the ETIME check
Thomas Gleixner [Mon, 13 Dec 2010 11:43:23 +0000 (12:43 +0100)]
x86: HPET: Chose a paranoid safe value for the ETIME check

commit f1c18071ad70e2a78ab31fc26a18fcfa954a05c6 upstream.

commit 995bd3bb5 (x86: Hpet: Avoid the comparator readback penalty)
chose 8 HPET cycles as a safe value for the ETIME check, as we had the
confirmation that the posted write to the comparator register is
delayed by two HPET clock cycles on Intel chipsets which showed
readback problems.

After that patch hit mainline we got reports from machines with newer
AMD chipsets which seem to have an even longer delay. See
http://thread.gmane.org/gmane.linux.kernel/1054283 and
http://thread.gmane.org/gmane.linux.kernel/1069458 for further
information.

Boris tried to come up with an ACPI based selection of the minimum
HPET cycles, but this failed on a couple of test machines. And of
course we did not get any useful information from the hardware folks.

For now our only option is to chose a paranoid high and safe value for
the minimum HPET cycles used by the ETIME check. Adjust the minimum ns
value for the HPET clockevent accordingly.

Reported-Bistected-and-Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
LKML-Reference: <alpine.LFD.2.00.1012131222420.2653@localhost6.localdomain6>
Cc: Simon Kirby <sim@hostway.ca>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andreas Herrmann <Andreas.Herrmann3@amd.com>
Cc: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agox86: Hpet: Avoid the comparator readback penalty
Thomas Gleixner [Wed, 15 Sep 2010 13:11:57 +0000 (15:11 +0200)]
x86: Hpet: Avoid the comparator readback penalty

commit 995bd3bb5c78f3ff71339803c0b8337ed36d64fb upstream.

Due to the overly intelligent design of HPETs, we need to workaround
the problem that the compare value which we write is already behind
the actual counter value at the point where the value hits the real
compare register. This happens for two reasons:

1) We read out the counter, add the delta and write the result to the
   compare register. When a NMI or SMI hits between the read out and
   the write then the counter can be ahead of the event already

2) The write to the compare register is delayed by up to two HPET
   cycles in certain chipsets.

We worked around this by reading back the compare register to make
sure that the written value has hit the hardware. For certain ICH9+
chipsets this can require two readouts, as the first one can return
the previous compare register value. That's bad performance wise for
the normal case where the event is far enough in the future.

As we already know that the write can be delayed by up to two cycles
we can avoid the read back of the compare register completely if we
make the decision whether the delta has elapsed already or not based
on the following calculation:

  cmp = event - actual_count;

If cmp is less than 8 HPET clock cycles, then we decide that the event
has happened already and return -ETIME. That covers the above #1 and
seconds).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Nix <nix@esperi.org.uk>
Tested-by: Artur Skawina <art.08.09@gmail.com>
Cc: Damien Wyart <damien.wyart@free.fr>
Tested-by: John Drescher <drescherjm@gmail.com>
Cc: Venkatesh Pallipadi <venki@google.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Tested-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <alpine.LFD.2.00.1009151500060.2416@localhost6.localdomain6>
[PG: diffstat differs from 995bd3bb since deleted comment was re-wrapped]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agodm: fix idr leak on module removal
Alasdair G Kergon [Tue, 2 Aug 2011 11:32:01 +0000 (12:32 +0100)]
dm: fix idr leak on module removal

commit d15b774c2920d55e3d58275c97fbe3adc3afde38 upstream.

Destroy _minor_idr when unloading the core dm module.  (Found by kmemleak.)

Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agodm mpath: fix potential NULL pointer in feature arg processing
Mike Snitzer [Tue, 2 Aug 2011 11:32:00 +0000 (12:32 +0100)]
dm mpath: fix potential NULL pointer in feature arg processing

commit 286f367dad40beb3234a18c17391d03ba939a7f3 upstream.

Avoid dereferencing a NULL pointer if the number of feature arguments
supplied is fewer than indicated.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoALSA: sound/core/pcm_compat.c: adjust array index
Julia Lawall [Thu, 28 Jul 2011 12:46:05 +0000 (14:46 +0200)]
ALSA: sound/core/pcm_compat.c: adjust array index

commit ca9380fd68514c7bc952282c1b4fc70607e9fe43 upstream.

Convert array index from the loop bound to the loop index.

A simplified version of the semantic patch that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression e1,e2,ar;
@@

for(e1 = 0; e1 < e2; e1++) { <...
  ar[
- e2
+ e1
  ]
  ...> }
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoproc: restrict access to /proc/PID/io
Vasiliy Kulikov [Fri, 24 Jun 2011 12:08:38 +0000 (16:08 +0400)]
proc: restrict access to /proc/PID/io

commit 1d1221f375c94ef961ba8574ac4f85c8870ddd51 upstream.

/proc/PID/io may be used for gathering private information.  E.g.  for
openssh and vsftpd daemons wchars/rchars may be used to learn the
precise password length.  Restrict it to processes being able to ptrace
the target process.

ptrace_may_access() is needed to prevent keeping open file descriptor of
"io" file, executing setuid binary and gathering io information of the
setuid'ed process.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoalpha: fix several security issues
Dan Rosenberg [Wed, 15 Jun 2011 22:09:01 +0000 (15:09 -0700)]
alpha: fix several security issues

commit 21c5977a836e399fc710ff2c5367845ed5c2527f upstream.

Fix several security issues in Alpha-specific syscalls.  Untested, but
mostly trivial.

1. Signedness issue in osf_getdomainname allows copying out-of-bounds
kernel memory to userland.

2. Signedness issue in osf_sysinfo allows copying large amounts of
kernel memory to userland.

3. Typo (?) in osf_getsysinfo bounds minimum instead of maximum copy
size, allowing copying large amounts of kernel memory to userland.

4. Usage of user pointer in osf_wait4 while under KERNEL_DS allows
privilege escalation via writing return value of sys_wait4 to kernel
memory.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agocifs: check for NULL session password
Jeff Layton [Mon, 23 Aug 2010 15:38:04 +0000 (11:38 -0400)]
cifs: check for NULL session password

commit 24e6cf92fde1f140d8eb0bf7cd24c2c78149b6b2 upstream.

It's possible for a cifsSesInfo struct to have a NULL password, so we
need to check for that prior to running strncmp on it.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agocifs: fix NULL pointer dereference in cifs_find_smb_ses
Jeff Layton [Wed, 18 Aug 2010 17:13:39 +0000 (13:13 -0400)]
cifs: fix NULL pointer dereference in cifs_find_smb_ses

commit fc87a40677bbe0937e2ff0642c7e83c9a4813f3d upstream.

cifs_find_smb_ses assumes that the vol->password field is a valid
pointer, but that's only the case if a password was passed in via
the options string. It's possible that one won't be if there is
no mount helper on the box.

Reported-by: diabel <gacek-2004@wp.pl>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agocifs: clean up cifs_find_smb_ses (try #2)
Jeff Layton [Wed, 7 Jul 2010 00:43:02 +0000 (20:43 -0400)]
cifs: clean up cifs_find_smb_ses (try #2)

commit 4ff67b720c02c36e54d55b88c2931879b7db1cd2 upstream.

This patch replaces the earlier patch by the same name. The only
difference is that MAX_PASSWORD_SIZE has been increased to attempt to
match the limits that windows enforces.

Do a better job of matching sessions by authtype. Matching by username
for a Kerberos session is incorrect, and anonymous sessions need special
handling.

Also, in the case where we do match by username, we also need to match
by password. That ensures that someone else doesn't "borrow" an existing
session without needing to know the password.

Finally, passwords can be longer than 16 bytes. Bump MAX_PASSWORD_SIZE
to 512 to match the size that the userspace mount helper allows.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
[PG: origin vs. in 2.6.34; ses <-- pSesInfo, server <-- srvTcp ]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agopowerpc/pseries/hvconsole: Fix dropped console output
Anton Blanchard [Tue, 5 Jul 2011 21:51:36 +0000 (21:51 +0000)]
powerpc/pseries/hvconsole: Fix dropped console output

commit 51d33021425e1f905beb4208823146f2fb6517da upstream.

Return -EAGAIN when we get H_BUSY back from the hypervisor. This
makes the hvc console driver retry, avoiding dropped printks.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoEHCI: fix direction handling for interrupt data toggles
Alan Stern [Tue, 19 Jul 2011 18:01:23 +0000 (14:01 -0400)]
EHCI: fix direction handling for interrupt data toggles

commit e04f5f7e423018bcec84c11af2058cdce87816f3 upstream.

This patch (as1480) fixes a rather obscure bug in ehci-hcd.  The
qh_update() routine needs to know the number and direction of the
endpoint corresponding to its QH argument.  The number can be taken
directly from the QH data structure, but the direction isn't stored
there.  The direction is taken instead from the first qTD linked to
the QH.

However, it turns out that for interrupt transfers, qh_update() gets
called before the qTDs are linked to the QH.  As a result, qh_update()
computes a bogus direction value, which messes up the endpoint toggle
handling.  Under the right combination of circumstances this causes
usb_reset_endpoint() not to work correctly, which causes packets to be
dropped and communications to fail.

Now, it's silly for the QH structure not to have direct access to all
the descriptor information for the corresponding endpoint.  Ultimately
it may get a pointer to the usb_host_endpoint structure; for now,
adding a copy of the direction flag solves the immediate problem.

This allows the Spyder2 color-calibration system (a low-speed USB
device that sends all its interrupt data packets with the toggle set
to 0 and hance requires constant use of usb_reset_endpoint) to work
when connected through a high-speed hub.  Thanks to Graeme Gill for
supplying the hardware that allowed me to track down this bug.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Graeme Gill <graeme@argyllcms.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoEHCI: only power off port if over-current is active
Sergei Shtylyov [Wed, 6 Jul 2011 19:19:38 +0000 (23:19 +0400)]
EHCI: only power off port if over-current is active

commit 81463c1d707186adbbe534016cd1249edeab0dac upstream.

MAX4967 USB power supply chip we use on our boards signals over-current when
power is not enabled; once it's enabled, over-current signal returns to normal.
That unfortunately caused the endless stream of "over-current change on port"
messages. The EHCI root hub code reacts on every over-current signal change
with powering off the port -- such change event is generated the moment the
port power is enabled, so once enabled the power is immediately cut off.
I think we should only cut off power when we're seeing the active over-current
signal, so I'm adding such check to that code. I also think that the fact that
we've cut off the port power should be reflected in the result of GetPortStatus
request immediately, hence I'm adding a PORTSCn register readback after write...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agosvcrpc: fix list-corrupting race on nfsd shutdown
J. Bruce Fields [Wed, 29 Jun 2011 20:49:04 +0000 (16:49 -0400)]
svcrpc: fix list-corrupting race on nfsd shutdown

commit ebc63e531cc6a457595dd110b07ac530eae788c3 upstream.

After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd:
split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no
longer removed its xpt_ready (then sk_ready) field from whatever list it
was on, noting that there was no point since the whole list was about to
be destroyed anyway.

That was mostly true, but forgot that a few svc_xprt_enqueue()'s might
still be hanging around playing with the about-to-be-destroyed list, and
could get themselves into trouble writing to freed memory if we left
this xprt on the list after freeing it.

(This is actually functionally identical to a patch made first by Ben
Greear, but with more comments.)

Cc: gnb@fmeh.org
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoext3: Fix oops in ext3_try_to_allocate_with_rsv()
Jan Kara [Mon, 30 May 2011 11:29:20 +0000 (13:29 +0200)]
ext3: Fix oops in ext3_try_to_allocate_with_rsv()

commit ad95c5e9bc8b5885f94dce720137cac8fa8da4c9 upstream.

Block allocation is called from two places: ext3_get_blocks_handle() and
ext3_xattr_block_set(). These two callers are not necessarily synchronized
because xattr code holds only xattr_sem and i_mutex, and
ext3_get_blocks_handle() may hold only truncate_mutex when called from
writepage() path. Block reservation code does not expect two concurrent
allocations to happen to the same inode and thus assertions can be triggered
or reservation structure corruption can occur.

Fix the problem by taking truncate_mutex in xattr code to serialize
allocations.

CC: Sage Weil <sage@newdream.net>
Reported-by: Fyodor Ustinov <ufm@ufm.su>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoxtensa: prevent arbitrary read in ptrace
Dan Rosenberg [Tue, 26 Jul 2011 00:11:53 +0000 (17:11 -0700)]
xtensa: prevent arbitrary read in ptrace

commit 0d0138ebe24b94065580bd2601f8bb7eb6152f56 upstream.

Prevent an arbitrary kernel read.  Check the user pointer with access_ok()
before copying data in.

[akpm@linux-foundation.org: s/EIO/EFAULT/]
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: Christian Zankel <chris@zankel.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agocciss: do not attempt to read from a write-only register
Stephen M. Cameron [Sat, 9 Jul 2011 07:04:12 +0000 (09:04 +0200)]
cciss: do not attempt to read from a write-only register

commit 07d0c38e7d84f911c72058a124c7f17b3c779a65 upstream.

Most smartarrays will tolerate it, but some new ones don't.

Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Note: this is a regression caused by commit 1ddd5049
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoPCI: ARI is a PCIe v2 feature
Chris Wright [Wed, 13 Jul 2011 17:14:33 +0000 (10:14 -0700)]
PCI: ARI is a PCIe v2 feature

commit 864d296cf948aef0fa32b81407541572583f7572 upstream.

The function pci_enable_ari() may mistakenly set the downstream port
of a v1 PCIe switch in ARI Forwarding mode.  This is a PCIe v2 feature,
and with an SR-IOV device on that switch port believing the switch above
is ARI capable it may attempt to use functions 8-255, translating into
invalid (non-zero) device numbers for that bus.  This has been seen
to cause Completion Timeouts and general misbehaviour including hangs
and panics.

Acked-by: Don Dutile <ddutile@redhat.com>
Tested-by: Don Dutile <ddutile@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agopowerpc/kdump: Fix timeout in crash_kexec_wait_realmode
Michael Neuling [Mon, 4 Jul 2011 20:40:10 +0000 (20:40 +0000)]
powerpc/kdump: Fix timeout in crash_kexec_wait_realmode

commit 63f21a56f1cc0b800a4c00349c59448f82473d19 upstream.

The existing code it pretty ugly.  How about we clean it up even more
like this?

From: Anton Blanchard <anton@samba.org>

We check for timeout expiry in the outer loop, but we also need to
check it in the inner loop or we can lock up forever waiting for a
CPU to hit real mode.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agokexec, x86: Fix incorrect jump back address if not preserving context
Huang Ying [Thu, 14 Jul 2011 01:34:37 +0000 (09:34 +0800)]
kexec, x86: Fix incorrect jump back address if not preserving context

commit 050438ed5a05b25cdf287f5691e56a58c2606997 upstream.

In kexec jump support, jump back address passed to the kexeced
kernel via function calling ABI, that is, the function call
return address is the jump back entry.

Furthermore, jump back entry == 0 should be used to signal that
the jump back or preserve context is not enabled in the original
kernel.

But in the current implementation the stack position used for
function call return address is not cleared context
preservation is disabled. The patch fixes this bug.

Reported-and-tested-by: Yin Kangkai <kangkai.yin@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Link: http://lkml.kernel.org/r/1310607277-25029-1-git-send-email-ying.huang@intel.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agopmcraid: reject negative request size
Dan Rosenberg [Mon, 11 Jul 2011 21:08:23 +0000 (14:08 -0700)]
pmcraid: reject negative request size

commit b5b515445f4f5a905c5dd27e6e682868ccd6c09d upstream.

There's a code path in pmcraid that can be reached via device ioctl that
causes all sorts of ugliness, including heap corruption or triggering the
OOM killer due to consecutive allocation of large numbers of pages.

First, the user can call pmcraid_chr_ioctl(), with a type
PMCRAID_PASSTHROUGH_IOCTL.  This calls through to
pmcraid_ioctl_passthrough().  Next, a pmcraid_passthrough_ioctl_buffer
is copied in, and the request_size variable is set to
buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit
signed value provided by the user.  If a negative value is provided
here, bad things can happen.  For example,
pmcraid_build_passthrough_ioadls() is called with this request_size,
which immediately calls pmcraid_alloc_sglist() with a negative size.
The resulting math on allocating a scatter list can result in an
overflow in the kzalloc() call (if num_elem is 0, the sglist will be
smaller than expected), or if num_elem is unexpectedly large the
subsequent loop will call alloc_pages() repeatedly, a high number of
pages will be allocated and the OOM killer might be invoked.

It looks like preventing this value from being negative in
pmcraid_ioctl_passthrough() would be sufficient.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoses: requesting a fault indication
Douglas Gilbert [Thu, 9 Jun 2011 04:27:07 +0000 (00:27 -0400)]
ses: requesting a fault indication

commit 2a350cab9daf9a46322d83b091bb05cf54ccf6ab upstream.

Noticed that when the sysfs interface of the SCSI SES
driver was used to request a fault indication the LED
flashed but the buzzer didn't sound. So it was doing
what REQUEST IDENT (locate) should do.

Changelog:
   - fix the setting of REQUEST FAULT for the device slot
     and array device slot elements in the enclosure control
     diagnostic page
   - note the potentially defective code that reads the
     FAULT SENSED and FAULT REQUESTED bits from the enclosure
     status diagnostic page

The attached patch is against git/scsi-misc-2.6

Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoBlacklist Traxdata CDR4120 and IOMEGA Zip drive to avoid lock ups.
Werner Fink [Thu, 9 Jun 2011 05:24:24 +0000 (10:54 +0530)]
Blacklist Traxdata CDR4120 and IOMEGA Zip drive to avoid lock ups.

commit 82103978189e9731658cd32da5eb85ab7b8542b8 upstream.

This patch resulted from the discussion at
https://bugzilla.novell.com/show_bug.cgi?id=679277,
https://bugzilla.novell.com/show_bug.cgi?id=681840 .

Signed-off-by: Werner Fink <werner@novell.com>
Signed-off-by: Ankit Jain <jankit@suse.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agomac80211: Restart STA timers only on associated state
Rajkumar Manoharan [Thu, 7 Jul 2011 18:03:39 +0000 (23:33 +0530)]
mac80211: Restart STA timers only on associated state

commit 676b58c27475a9defccc025fea1cbd2b141ee539 upstream.

A panic was observed when the device is failed to resume properly,
and there are no running interfaces. ieee80211_reconfig tries
to restart STA timers on unassociated state.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agolibsas: remove expander from dev list on error
Luben Tuikov [Wed, 27 Jul 2011 06:10:48 +0000 (23:10 -0700)]
libsas: remove expander from dev list on error

commit 5911e963d3718e306bcac387b83e259aa4228896 upstream.

If expander discovery fails (sas_discover_expander()), remove the
expander from the port device list (sas_ex_discover_expander()),
before freeing it. Else the list is corrupted and, e.g., when we
attempt to send SMP commands to other devices, the kernel oopses.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Reviewed-by: Jack Wang <jack_wang@usish.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agojme: Fix unmap error (Causing system freeze)
Guo-Fu Tseng [Wed, 20 Jul 2011 16:57:36 +0000 (16:57 +0000)]
jme: Fix unmap error (Causing system freeze)

commit 94c5b41b327e08de0ddf563237855f55080652a1 upstream.

This patch add the missing dma_unmap().
Which solved the critical issue of system freeze on heavy load.

Michal Miroslaw's rejected patch:
[PATCH v2 10/46] net: jme: convert to generic DMA API
Pointed out the issue also, thank you Michal.
But the fix was incorrect. It would unmap needed address
when low memory.

Got lots of feedback from End user and Gentoo Bugzilla.
https://bugs.gentoo.org/show_bug.cgi?id=373109
Thank you all. :)

Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoARM: pxa/cm-x300: fix V3020 RTC functionality
Igor Grinberg [Mon, 9 May 2011 11:41:46 +0000 (14:41 +0300)]
ARM: pxa/cm-x300: fix V3020 RTC functionality

commit 6c7b3ea52e345ab614edb91d3f0e9f3bb3713871 upstream.

While in sleep mode the CS# and other V3020 RTC GPIOs must be driven
high, otherwise V3020 RTC fails to keep the right time in sleep mode.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoUSB: OHCI: fix another regression for NVIDIA controllers
Alan Stern [Fri, 15 Jul 2011 21:22:15 +0000 (17:22 -0400)]
USB: OHCI: fix another regression for NVIDIA controllers

commit 6ea12a04d295235ed67010a09fdea58c949e3eb0 upstream.

The NVIDIA series of OHCI controllers continues to be troublesome.  A
few people using the MCP67 chipset have reported that even with the
most recent kernels, the OHCI controller fails to handle new
connections and spams the system log with "unable to enumerate USB
port" messages.  This is different from the other problems previously
reported for NVIDIA OHCI controllers, although it is probably related.

It turns out that the MCP67 controller does not like to be kept in the
RESET state very long.  After only a few seconds, it decides not to
work any more.  This patch (as1479) changes the PCI initialization
quirk code so that NVIDIA controllers are switched into the SUSPEND
state after 50 ms of RESET.  With no interrupts enabled and all the
downstream devices reset, and thus unable to send wakeup requests,
this should be perfectly safe (even for non-NVIDIA hardware).

The removal code in ohci-hcd hasn't been changed; it will still leave
the controller in the RESET state.  As a result, if someone unloads
ohci-hcd and then reloads it, the controller won't work again until
the system is rebooted.  If anybody complains about this, the removal
code can be updated similarly.

This fixes Bugzilla #22052.

Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agostaging: comedi: fix infoleak to userspace
Vasiliy Kulikov [Sun, 26 Jun 2011 08:56:22 +0000 (12:56 +0400)]
staging: comedi: fix infoleak to userspace

commit 819cbb120eaec7e014e5abd029260db1ca8c5735 upstream.

driver_name and board_name are pointers to strings, not buffers of size
COMEDI_NAMELEN.  Copying COMEDI_NAMELEN bytes of a string containing
less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoUSB: serial: add IDs for WinChipHead USB->RS232 adapter
Wolfgang Denk [Tue, 19 Jul 2011 09:25:38 +0000 (11:25 +0200)]
USB: serial: add IDs for WinChipHead USB->RS232 adapter

commit 026dfaf18973404a01f488d6aa556a8c466e06a4 upstream.

Add ID 4348:5523 for WinChipHead USB->RS 232 adapter with
Prolifec PL2303 chipset

Signed-off-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoUSB: pl2303.h: checkpatch cleanups
Greg Kroah-Hartman [Mon, 17 May 2010 17:33:41 +0000 (10:33 -0700)]
USB: pl2303.h: checkpatch cleanups

commit 5d78fcb0caf219e2e6c8e486d7e31fec1333ac06 upstream.

Minor whitespace cleanups to make checkpatch happy.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agox86: Make Dell Latitude E5420 use reboot=pci
Daniel J Blueman [Fri, 13 May 2011 01:04:59 +0000 (09:04 +0800)]
x86: Make Dell Latitude E5420 use reboot=pci

commit b7798d28ec15d20fd34b70fa57eb13f0cf6d1ecd upstream.

Rebooting on the Dell E5420 often hangs with the keyboard or ACPI
methods, but is reliable via the PCI method.

[ hpa: this was deferred because we believed for a long time that the
  recent reshuffling of the boot priorities in commit
  660e34cebf0a11d54f2d5dd8838607452355f321 fixed this platform.
  Unfortunately that turned out to be incorrect. ]

Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Link: http://lkml.kernel.org/r/1305248699-2347-1-git-send-email-daniel.blueman@gmail.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agolibata: fix unexpectedly frozen port after ata_eh_reset()
Tejun Heo [Wed, 25 May 2011 11:19:39 +0000 (13:19 +0200)]
libata: fix unexpectedly frozen port after ata_eh_reset()

commit 8c56cacc724c7650b893d43068fa66044aa29a61 upstream.

To work around controllers which can't properly plug events while
reset, ata_eh_reset() clears error states and ATA_PFLAG_EH_PENDING
after reset but before RESET is marked done.  As reset is the final
recovery action and full verification of devices including onlineness
and classfication match is done afterwards, this shouldn't lead to
lost devices or missed hotplug events.

Unfortunately, it forgot to thaw the port when clearing EH_PENDING, so
if the condition happens after resetting an empty port, the port could
be left frozen and EH will end without thawing it, making the port
unresponsive to further hotplug events.

Thaw if the port is frozen after clearing EH_PENDING.  This problem is
reported by Bruce Stenning in the following thread.

 http://thread.gmane.org/gmane.linux.kernel/1123265

stable: I think we should weather this patch a bit longer in -rcX
before sending it to -stable.  Please wait at least a month
after this patch makes upstream.  Thanks.

-v2: Fixed spelling in the comment per Dave Howorth.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Bruce Stenning <b.stenning@indigovision.com>
Cc: Dave Howorth <dhoworth@mrc-lmb.cam.ac.uk>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agodavinci: DM365 EVM: fix video input mux bits
Jon Povey [Tue, 19 Jul 2011 03:30:11 +0000 (12:30 +0900)]
davinci: DM365 EVM: fix video input mux bits

commit 9daedd833a38edd90cf7baa1b1fcf61c3a0721e3 upstream.

Video input mux settings for tvp7002 and imager inputs were swapped.
Comment was correct.

Tested on EVM with tvp7002 input.

Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Acked-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agobridge: send proper message_age in config BPDU
stephen hemminger [Fri, 22 Jul 2011 07:47:06 +0000 (07:47 +0000)]
bridge: send proper message_age in config BPDU

commit 0c03150e7ea8f7fcd03cfef29385e0010b22ee92 upstream.

A bridge topology with three systems:

      +------+  +------+
      | A(2) |--| B(1) |
      +------+  +------+
           \    /
          +------+
          | C(3) |
          +------+

What is supposed to happen:
 * bridge with the lowest ID is elected root (for example: B)
 * C detects that A->C is higher cost path and puts in blocking state

What happens. Bridge with lowest id (B) is elected correctly as
root and things start out fine initially. But then config BPDU
doesn't get transmitted from A -> C. Because of that
the link from A-C is transistioned to the forwarding state.

The root cause of this is that the configuration messages
is generated with bogus message age, and dropped before
sending.

In the standardmessage_age is supposed to be:
  the time since the generation of the Configuration BPDU by
  the Root that instigated the generation of this Configuration BPDU.

Reimplement this by recording the timestamp (age + jiffies) when
recording config information. The old code incorrectly used the time
elapsed on the ageing timer which was incorrect.

See also:
  https://bugzilla.vyatta.com/show_bug.cgi?id=7164

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agohwmon: (max1111) Fix race condition causing NULL pointer exception
Pavel Herrmann [Sun, 17 Jul 2011 16:39:19 +0000 (18:39 +0200)]
hwmon: (max1111) Fix race condition causing NULL pointer exception

commit d3f684f2820a7f42acef68bea6622d9032127fb2 upstream.

spi_sync call uses its spi_message parameter to keep completion information,
using a drvdata structure is not thread-safe. Use a mutex to prevent
multiple access to shared driver data.

Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Cyril Hrubis <metan@ucw.cz>
Tested-by: Stanislav Brabec <utx@penguin.cz>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agosi4713-i2c: avoid potential buffer overflow on si4713
Mauro Carvalho Chehab [Sun, 17 Jul 2011 03:24:37 +0000 (00:24 -0300)]
si4713-i2c: avoid potential buffer overflow on si4713

commit dc6b845044ccb7e9e6f3b7e71bd179b3cf0223b6 upstream.

While compiling it with Fedora 15, I noticed this issue:

  inlined from ‘si4713_write_econtrol_string’ at drivers/media/radio/si4713-i2c.c:1065:24:
  arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correct

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
Reviewed-by: Eugene Teo <eugeneteo@kernel.sg>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoSUNRPC: Fix use of static variable in rpcb_getport_async
Ben Greear [Tue, 12 Jul 2011 17:27:55 +0000 (10:27 -0700)]
SUNRPC: Fix use of static variable in rpcb_getport_async

commit ec0dd267bf7d08cb30e321e45a75fd40edd7e528 upstream.

Because struct rpcbind_args *map was declared static, if two
threads entered this method at the same time, the values
assigned to map could be sent two two differen tasks.
This could cause all sorts of problems, include use-after-free
and double-free of memory.

Fix this by removing the static declaration so that the map
pointer is on the stack.

Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoSUNRPC: Fix a race between work-queue and rpc_killall_tasks
Trond Myklebust [Wed, 6 Jul 2011 23:58:23 +0000 (19:58 -0400)]
SUNRPC: Fix a race between work-queue and rpc_killall_tasks

commit b55c59892e1f3b6c7d4b9ccffb4263e1486fb990 upstream.

Since rpc_killall_tasks may modify the rpc_task's tk_action field
without any locking, we need to be careful when dereferencing it.

Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoNFSv4.1: update nfs4_fattr_bitmap_maxsz
Andy Adamson [Mon, 11 Jul 2011 21:17:42 +0000 (17:17 -0400)]
NFSv4.1: update nfs4_fattr_bitmap_maxsz

commit e5012d1f3861d18c7f3814e757c1c3ab3741dbcd upstream.

Attribute IDs assigned in RFC 5661 now require three bitmaps.
Fixes hitting a BUG_ON in xdr_shrink_bufhead when getting ACLs.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agobttv: fix s_tuner for radio
Hans Verkuil [Sun, 12 Jun 2011 10:02:43 +0000 (07:02 -0300)]
bttv: fix s_tuner for radio

commit a024c1a6b274e11596d124619e43c25560f64c01 upstream.

Fix typo: g_tuner should have been s_tuner.

Tested with a bttv card.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agopvrusb2: fix g/s_tuner support
Hans Verkuil [Sun, 12 Jun 2011 09:39:52 +0000 (06:39 -0300)]
pvrusb2: fix g/s_tuner support

commit 50e9efd60b213ce43ad6979bfc18e25eec2d8413 upstream.

The tuner-core subdev requires that the type field of v4l2_tuner is
filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
use that yet, so we have to do it manually based on whether the current
input is radio or not.

Tested with my pvrusb2.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agov4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tuner
Hans Verkuil [Sun, 12 Jun 2011 09:36:41 +0000 (06:36 -0300)]
v4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tuner

commit 227690df75382e46a4f6ea1bbc5df855a674b47f upstream.

The subdevs are supposed to receive a valid tuner type for the g_frequency
and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill
this in v4l2-ioctl.c based on whether the device node from which this is
called is a radio node or not.

The spec does not require applications to fill in the type, and if they
leave it at 0 then the 'check_mode' call in tuner-core.c will return
an error and the ioctl does nothing.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoASoC: Fix Blackfin I2S _pointer() implementation return in bounds values
Mark Brown [Mon, 13 Jun 2011 11:14:07 +0000 (12:14 +0100)]
ASoC: Fix Blackfin I2S _pointer() implementation return in bounds values

commit e999dc50404d401150a5429b6459473a691fd1a0 upstream.

The Blackfin DMA controller can report one frame beyond the end of the
buffer in the wraparound case but ALSA requires that the pointer always
be in the buffer. Do the wraparound to handle this. A similar bug is
likely to apply to the other Blackfin PCM drivers but the code is less
obvious to inspection and I don't have a user to test.

Reported-by: Kieran O'Leary <Kieran.O'Leary@wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agomm: prevent concurrent unmap_mapping_range() on the same inode
Miklos Szeredi [Wed, 23 Feb 2011 12:49:47 +0000 (13:49 +0100)]
mm: prevent concurrent unmap_mapping_range() on the same inode

commit 2aa15890f3c191326678f1bd68af61ec6b8753ec upstream.

Michael Leun reported that running parallel opens on a fuse filesystem
can trigger a "kernel BUG at mm/truncate.c:475"

Gurudas Pai reported the same bug on NFS.

The reason is, unmap_mapping_range() is not prepared for more than
one concurrent invocation per inode.  For example:

  thread1: going through a big range, stops in the middle of a vma and
     stores the restart address in vm_truncate_count.

  thread2: comes in with a small (e.g. single page) unmap request on
     the same vma, somewhere before restart_address, finds that the
     vma was already unmapped up to the restart address and happily
     returns without doing anything.

Another scenario would be two big unmap requests, both having to
restart the unmapping and each one setting vm_truncate_count to its
own value.  This could go on forever without any of them being able to
finish.

Truncate and hole punching already serialize with i_mutex.  Other
callers of unmap_mapping_range() do not, and it's difficult to get
i_mutex protection for all callers.  In particular ->d_revalidate(),
which calls invalidate_inode_pages2_range() in fuse, may be called
with or without i_mutex.

This patch adds a new mutex to 'struct address_space' to prevent
running multiple concurrent unmap_mapping_range() on the same mapping.

[ We'll hopefully get rid of all this with the upcoming mm
  preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex
  lockbreak" patch in particular.  But that is for 2.6.39 ]

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Reported-by: Michael Leun <lkml20101129@newton.leun.net>
Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Acked-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PG: Some chunks dropped, since no ebdfed4dc5 in 34; came in at 2.6.37]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoudp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet
Xufeng Zhang [Tue, 21 Jun 2011 10:43:40 +0000 (10:43 +0000)]
udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet

commit 9cfaa8def1c795a512bc04f2aec333b03724ca2e upstream.

Consider this scenario: When the size of the first received udp packet
is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags.
However, if checksum error happens and this is a blocking socket, it will
goto try_again loop to receive the next packet.  But if the size of the
next udp packet is smaller than receive buffer, MSG_TRUNC flag should not
be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before
receive the next packet, MSG_TRUNC is still set, which is wrong.

Fix this problem by clearing MSG_TRUNC flag when starting over for a
new packet.

Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoipv6/udp: Use the correct variable to determine non-blocking condition
Xufeng Zhang [Tue, 21 Jun 2011 10:43:39 +0000 (10:43 +0000)]
ipv6/udp: Use the correct variable to determine non-blocking condition

commit 32c90254ed4a0c698caa0794ebb4de63fcc69631 upstream.

udpv6_recvmsg() function is not using the correct variable to determine
whether or not the socket is in non-blocking operation, this will lead
to unexpected behavior when a UDP checksum error occurs.

Consider a non-blocking udp receive scenario: when udpv6_recvmsg() is
called by sock_common_recvmsg(), MSG_DONTWAIT bit of flags variable in
udpv6_recvmsg() is cleared by "flags & ~MSG_DONTWAIT" in this call:

    err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT,
                   flags & ~MSG_DONTWAIT, &addr_len);

i.e. with udpv6_recvmsg() getting these values:

int noblock = flags & MSG_DONTWAIT
int flags = flags & ~MSG_DONTWAIT

So, when udp checksum error occurs, the execution will go to
csum_copy_err, and then the problem happens:

    csum_copy_err:
            ...............
            if (flags & MSG_DONTWAIT)
                    return -EAGAIN;
            goto try_again;
            ...............

But it will always go to try_again as MSG_DONTWAIT has been cleared
from flags at call time -- only noblock contains the original value
of MSG_DONTWAIT, so the test should be:

            if (noblock)
                    return -EAGAIN;

This is also consistent with what the ipv4/udp code does.

Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agonet/ipv4: Check for mistakenly passed in non-IPv4 address
Marcus Meissner [Thu, 2 Jun 2011 04:05:22 +0000 (21:05 -0700)]
net/ipv4: Check for mistakenly passed in non-IPv4 address

commit d0733d2e29b652b2e7b1438ececa732e4eed98eb upstream.

Check against mistakenly passing in IPv6 addresses (which would result
in an INADDR_ANY bind) or similar incompatible sockaddrs.

Signed-off-by: Marcus Meissner <meissner@suse.de>
Cc: Reinhard Max <max@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoaf_packet: prevent information leak
Eric Dumazet [Tue, 7 Jun 2011 05:42:06 +0000 (22:42 -0700)]
af_packet: prevent information leak

commit 13fcb7bd322164c67926ffe272846d4860196dc6 upstream.

In 2.6.27, commit 393e52e33c6c2 (packet: deliver VLAN TCI to userspace)
added a small information leak.

Add padding field and make sure its zeroed before copy to user.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agonet: filter: Use WARN_RATELIMIT
Joe Perches [Sat, 21 May 2011 07:48:40 +0000 (07:48 +0000)]
net: filter: Use WARN_RATELIMIT

commit 6c4a5cb219520c7bc937ee186ca53f03733bd09f upstream.

A mis-configured filter can spam the logs with lots of stack traces.

Rate-limit the warnings and add printout of the bogus filter information.

Original-patch-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agobug.h: Add WARN_RATELIMIT
Joe Perches [Sat, 21 May 2011 07:48:39 +0000 (07:48 +0000)]
bug.h: Add WARN_RATELIMIT

commit b3eec79b0776e5340a3db75b34953977c7e5086e upstream.

Add a generic mechanism to ratelimit WARN(foo, fmt, ...) messages
using a hidden per call site static struct ratelimit_state.

Also add an __WARN_RATELIMIT variant to be able to use a specific
struct ratelimit_state.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoPM / Hibernate: Fix free_unnecessary_pages()
Rafael J. Wysocki [Wed, 6 Jul 2011 18:15:23 +0000 (20:15 +0200)]
PM / Hibernate: Fix free_unnecessary_pages()

commit 4d4cf23cdde2f8f9324f5684a7f349e182039529 upstream.

There is a bug in free_unnecessary_pages() that causes it to
attempt to free too many pages in some cases, which triggers the
BUG_ON() in memory_bm_clear_bit() for copy_bm.  Namely, if
count_data_pages() is initially greater than alloc_normal, we get
to_free_normal equal to 0 and "save" greater from 0.  In that case,
if the sum of "save" and count_highmem_pages() is greater than
alloc_highmem, we subtract a positive number from to_free_normal.
Hence, since to_free_normal was 0 before the subtraction and is
an unsigned int, the result is converted to a huge positive number
that is used as the number of pages to free.

Fix this bug by checking if to_free_normal is actually greater
than or equal to the number we're going to subtract from it.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoPM / Hibernate: Avoid hitting OOM during preallocation of memory
Rafael J. Wysocki [Sat, 11 Sep 2010 18:58:27 +0000 (20:58 +0200)]
PM / Hibernate: Avoid hitting OOM during preallocation of memory

commit 6715045ddc7472a22be5e49d4047d2d89b391f45 upstream.

There is a problem in hibernate_preallocate_memory() that it calls
preallocate_image_memory() with an argument that may be greater than
the total number of available non-highmem memory pages.  If that's
the case, the OOM condition is guaranteed to trigger, which in turn
can cause significant slowdown to occur during hibernation.

To avoid that, make preallocate_image_memory() adjust its argument
before calling preallocate_image_pages(), so that the total number of
saveable non-highem pages left is not less than the minimum size of
a hibernation image.  Change hibernate_preallocate_memory() to try to
allocate from highmem if the number of pages allocated by
preallocate_image_memory() is too low.

Modify free_unnecessary_pages() to take all possible memory
allocation patterns into account.

Reported-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Tested-by: M. Vefa Bicakci <bicave@superonline.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agouml: fix CONFIG_STATIC_LINK=y build failure with newer glibc
Roland McGrath [Tue, 26 Oct 2010 21:22:19 +0000 (14:22 -0700)]
uml: fix CONFIG_STATIC_LINK=y build failure with newer glibc

commit aa5fb4dbfd121296ca97c68cf90043a7ea97579d upstream.

With glibc 2.11 or later that was built with --enable-multi-arch, the UML
link fails with undefined references to __rel_iplt_start and similar
symbols.  In recent binutils, the default linker script defines these
symbols (see ld --verbose).  Fix the UML linker scripts to match the new
defaults for these sections.

Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoUSB: don't let the hub driver prevent system sleep
Alan Stern [Wed, 15 Jun 2011 20:29:16 +0000 (16:29 -0400)]
USB: don't let the hub driver prevent system sleep

commit cbb330045e5df8f665ac60227ff898421fc8fb92 upstream.

This patch (as1465) continues implementation of the policy that errors
during suspend or hibernation should not prevent the system from going
to sleep.

In this case, failure to turn on the Suspend feature for a hub port
shouldn't be reported as an error.  There are situations where this
does actually occur (such as when the device plugged into that port
was disconnected in the recent past), and it turns out to be harmless.
There's no reason for it to prevent a system sleep.

Also, don't allow the hub driver to fail a system suspend if the
downstream ports aren't all suspended.  This is also harmless (and
should never happen, given the change mentioned above); printing a
warning message in the kernel log is all we really need to do.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoUSB: don't let errors prevent system sleep
Alan Stern [Wed, 15 Jun 2011 20:27:43 +0000 (16:27 -0400)]
USB: don't let errors prevent system sleep

commit 0af212ba8f123c2eba151af7726c34a50b127962 upstream.

This patch (as1464) implements the recommended policy that most errors
during suspend or hibernation should not prevent the system from going
to sleep.  In particular, failure to suspend a USB driver or a USB
device should not prevent the sleep from succeeding:

Failure to suspend a device won't matter, because the device will
automatically go into suspend mode when the USB bus stops carrying
packets.  (This might be less true for USB-3.0 devices, but let's not
worry about them now.)

Failure of a driver to suspend might lead to trouble later on when the
system wakes up, but it isn't sufficient reason to prevent the system
from going to sleep.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years ago6pack,mkiss: fix lock inconsistency
Arnd Bergmann [Sat, 2 Jul 2011 00:30:00 +0000 (17:30 -0700)]
6pack,mkiss: fix lock inconsistency

commit 6e4e2f811bade330126d4029c88c831784a7efd9 upstream.

Lockdep found a locking inconsistency in the mkiss_close function:

> kernel: [ INFO: inconsistent lock state ]
> kernel: 2.6.39.1 #3
> kernel: ---------------------------------
> kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
> kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
> kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
> kernel: {IN-SOFTIRQ-R} state was registered at:

The message hints that disc_data_lock is aquired with softirqs disabled,
but does not itself disable softirqs, which can in rare circumstances
lead to a deadlock.
The same problem is present in the 6pack driver, this patch fixes both
by using write_lock_bh instead of write_lock.

Reported-by: Bernard F6BVP <f6bvp@free.fr>
Tested-by: Bernard F6BVP <f6bvp@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ralf Baechle<ralf@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoSUNRPC: Ensure the RPC client only quits on fatal signals
Trond Myklebust [Fri, 17 Jun 2011 14:14:59 +0000 (10:14 -0400)]
SUNRPC: Ensure the RPC client only quits on fatal signals

commit 5afa9133cfe67f1bfead6049a9640c9262a7101c upstream.

Fix a couple of instances where we were exiting the RPC client on
arbitrary signals. We should only do so on fatal signals.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agomd: avoid endless recovery loop when waiting for fail device to complete.
NeilBrown [Tue, 28 Jun 2011 06:59:42 +0000 (16:59 +1000)]
md: avoid endless recovery loop when waiting for fail device to complete.

commit 4274215d24633df7302069e51426659d4759c5ed upstream.

If a device fails in a way that causes pending request to take a while
to complete, md will not be able to immediately remove it from the
array in remove_and_add_spares.
It will then incorrectly look like a spare device and md will try to
recover it even though it is failed.
This leads to a recovery process starting and instantly aborting over
and over again.

We should check if the device is faulty before considering it to be a
spare.  This will avoid trying to start a recovery that cannot
proceed.

This bug was introduced in 2.6.26 so that patch is suitable for any
kernel since then.

Reported-by: Jim Paradis <james.paradis@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoi2c-taos-evm: Fix log messages
Jean Delvare [Wed, 29 Jun 2011 09:36:10 +0000 (11:36 +0200)]
i2c-taos-evm: Fix log messages

commit 9b640f2e154268cb516efcaf9c434f2e73c6783e upstream.

* Print all error and information messages even when debugging is
  disabled.
* Don't use adapter device to log messages before it is ready.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agocfq-iosched: fix a rcu warning
Shaohua Li [Mon, 27 Jun 2011 07:03:47 +0000 (09:03 +0200)]
cfq-iosched: fix a rcu warning

commit 3181faa85bda3dc3f5e630a1846526c9caaa38e3 upstream.

I got a rcu warnning at boot. the ioc->ioc_data is rcu_deferenced, but
doesn't hold rcu_read_lock.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agocfq-iosched: fix locking around ioc->ioc_data assignment
Jens Axboe [Sun, 5 Jun 2011 04:01:13 +0000 (06:01 +0200)]
cfq-iosched: fix locking around ioc->ioc_data assignment

commit ab4bd22d3cce6977dc039664cc2d052e3147d662 upstream.

Since we are modifying this RCU pointer, we need to hold
the lock protecting it around it.

This fixes a potential reuse and double free of a cfq
io_context structure. The bug has been in CFQ for a long
time, it hit very few people but those it did hit seemed
to see it a lot.

Tracked in RH bugzilla here:

https://bugzilla.redhat.com/show_bug.cgi?id=577968

Credit goes to Paul Bolle for figuring out that the issue
was around the one-hit ioc->ioc_data cache. Thanks to his
hard work the issue is now fixed.

Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agodebugobjects: Fix boot crash when kmemleak and debugobjects enabled
Marcin Slusarz [Sat, 28 May 2011 11:23:42 +0000 (13:23 +0200)]
debugobjects: Fix boot crash when kmemleak and debugobjects enabled

commit 161b6ae0e067e421b20bb35caf66bdb405c929ac upstream.

Order of initialization look like this:
...
debugobjects
kmemleak
...(lots of other subsystems)...
workqueues (through early initcall)
...

debugobjects use schedule_work for batch freeing of its data and kmemleak
heavily use debugobjects, so when it comes to freeing and workqueues were
not initialized yet, kernel crashes:

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff810854d1>] __queue_work+0x29/0x41a
 [<ffffffff81085910>] queue_work_on+0x16/0x1d
 [<ffffffff81085abc>] queue_work+0x29/0x55
 [<ffffffff81085afb>] schedule_work+0x13/0x15
 [<ffffffff81242de1>] free_object+0x90/0x95
 [<ffffffff81242f6d>] debug_check_no_obj_freed+0x187/0x1d3
 [<ffffffff814b6504>] ? _raw_spin_unlock_irqrestore+0x30/0x4d
 [<ffffffff8110bd14>] ? free_object_rcu+0x68/0x6d
 [<ffffffff8110890c>] kmem_cache_free+0x64/0x12c
 [<ffffffff8110bd14>] free_object_rcu+0x68/0x6d
 [<ffffffff810b58bc>] __rcu_process_callbacks+0x1b6/0x2d9
...

because system_wq is NULL.

Fix it by checking if workqueues susbystem was initialized before using.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20110528112342.GA3068@joi.lan
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agowatchdog: mtx1-wdt: request gpio before using it
Florian Fainelli [Wed, 15 Jun 2011 17:15:23 +0000 (19:15 +0200)]
watchdog: mtx1-wdt: request gpio before using it

commit 9b19d40aa3ebaf1078779da10555da2ab8512422 upstream.

Otherwise, the gpiolib autorequest feature will produce a WARN_ON():

WARNING: at drivers/gpio/gpiolib.c:101 0x8020ec6c()
autorequest GPIO-215
[...]

Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
[PG: use combo gpio_request+gpio_direction_output vs. gpio_request_one
 to avoid build failure, as per v2.6.32.47 commit 35b6863ce555c ]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agouvcvideo: Remove buffers from the queues when freeing
Sjoerd Simons [Tue, 24 May 2011 15:22:03 +0000 (12:22 -0300)]
uvcvideo: Remove buffers from the queues when freeing

commit 8ca2c80b170c47eeb55f0c2a0f2b8edf85f35d49 upstream.

When freeing memory for the video buffers also remove them from the
irq & main queues.

This fixes an oops when doing the following:

open ("/dev/video", ..)
VIDIOC_REQBUFS
VIDIOC_QBUF
VIDIOC_REQBUFS
close ()

As the second VIDIOC_REQBUFS will cause the list entries of the buffers
to be cleared while they still hang around on the main and irc queues

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agomm: fix negative commitlimit when gigantic hugepages are allocated
Rafael Aquini [Wed, 15 Jun 2011 22:08:39 +0000 (15:08 -0700)]
mm: fix negative commitlimit when gigantic hugepages are allocated

commit b0320c7b7d1ac1bd5c2d9dff3258524ab39bad32 upstream.

When 1GB hugepages are allocated on a system, free(1) reports less
available memory than what really is installed in the box.  Also, if the
total size of hugepages allocated on a system is over half of the total
memory size, CommitLimit becomes a negative number.

The problem is that gigantic hugepages (order > MAX_ORDER) can only be
allocated at boot with bootmem, thus its frames are not accounted to
'totalram_pages'.  However, they are accounted to hugetlb_total_pages()

What happens to turn CommitLimit into a negative number is this
calculation, in fs/proc/meminfo.c:

        allowed = ((totalram_pages - hugetlb_total_pages())
                * sysctl_overcommit_ratio / 100) + total_swap_pages;

A similar calculation occurs in __vm_enough_memory() in mm/mmap.c.

Also, every vm statistic which depends on 'totalram_pages' will render
confusing values, as if system were 'missing' some part of its memory.

Impact of this bug:

When gigantic hugepages are allocated and sysctl_overcommit_memory ==
OVERCOMMIT_NEVER.  In a such situation, __vm_enough_memory() goes through
the mentioned 'allowed' calculation and might end up mistakenly returning
-ENOMEM, thus forcing the system to start reclaiming pages earlier than it
would be ususal, and this could cause detrimental impact to overall
system's performance, depending on the workload.

Besides the aforementioned scenario, I can only think of this causing
annoyances with memory reports from /proc/meminfo and free(1).

[akpm@linux-foundation.org: standardize comment layout]
Reported-by: Russ Anderson <rja@sgi.com>
Signed-off-by: Rafael Aquini <aquini@linux.com>
Acked-by: Russ Anderson <rja@sgi.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoath5k: fix memory leak when fewer than N_PD_CURVES are in use
Eugene A. Shatokhin [Wed, 29 Jun 2011 03:04:51 +0000 (23:04 -0400)]
ath5k: fix memory leak when fewer than N_PD_CURVES are in use

commit a0b8de350be458b33248e48b2174d9af8a4c4798 upstream.

We would free the proper number of curves, but in the wrong
slots, due to a missing level of indirection through
the pdgain_idx table.

It's simpler just to try to free all four slots, so do that.

Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
11 years agoPM: Free memory bitmaps if opening /dev/snapshot fails
Michal Kubecek [Sat, 18 Jun 2011 18:34:01 +0000 (20:34 +0200)]
PM: Free memory bitmaps if opening /dev/snapshot fails

commit 8440f4b19494467883f8541b7aa28c7bbf6ac92b upstream.

When opening /dev/snapshot device, snapshot_open() creates memory
bitmaps which are freed in snapshot_release(). But if any of the
callbacks called by pm_notifier_call_chain() returns NOTIFY_BAD, open()
fails, snapshot_release() is never called and bitmaps are not freed.
Next attempt to open /dev/snapshot then triggers BUG_ON() check in
create_basic_memory_bitmaps(). This happens e.g. when vmwatchdog module
is active on s390x.

Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>