omap4-v4l2-camera:omap4-v4l2-camera.git
6 years agocan: Add missing socket check in can/bcm release.
Dave Jones [Mon, 13 Jun 2011 10:58:05 +0000 (11:58 +0100)]
can: Add missing socket check in can/bcm release.

We can get here with a NULL socket argument passed from userspace,
so we need to handle it accordingly.

Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c6914a6f261aca0c9f715f883a353ae7ff51fe83)
CVE-2011-1598
BugLink: http://bugs.launchpad.net/bugs/796502
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
6 years agofs/partitions/efi.c: corrupted GUID partition tables can cause kernel oops
Timo Warns [Fri, 10 Jun 2011 10:05:59 +0000 (11:05 +0100)]
fs/partitions/efi.c: corrupted GUID partition tables can cause kernel oops

The kernel automatically evaluates partition tables of storage devices.
The code for evaluating GUID partitions (in fs/partitions/efi.c) contains
a bug that causes a kernel oops on certain corrupted GUID partition
tables.

This bug has security impacts, because it allows, for example, to
prepare a storage device that crashes a kernel subsystem upon connecting
the device (e.g., a "USB Stick of (Partial) Death").

crc = efi_crc32((const unsigned char *) (*gpt), le32_to_cpu((*gpt)->header_size));

computes a CRC32 checksum over gpt covering (*gpt)->header_size bytes.
There is no validation of (*gpt)->header_size before the efi_crc32 call.

A corrupted partition table may have large values for (*gpt)->header_size.
 In this case, the CRC32 computation access memory beyond the memory
allocated for gpt, which may cause a kernel heap overflow.

Validate value of GUID partition table header size.

[akpm@linux-foundation.org: fix layout and indenting]
Signed-off-by: Timo Warns <warns@pre-sense.de>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Cc: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3eb8e74ec72736b9b9d728bad30484ec89c91dde)
CVE-2011-1577
BugLink: http://bugs.launchpad.net/bugs/795418
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
6 years agoUBUNTU: [Config] Turn on CONFIG_USER_NS and DEVPTS_MULTIPLE_INSTANCES.
Paolo Pisati [Tue, 7 Jun 2011 12:58:40 +0000 (14:58 +0200)]
UBUNTU: [Config] Turn on CONFIG_USER_NS and DEVPTS_MULTIPLE_INSTANCES.

These options are already on in omap3, moreover without these we
can't get lxc to work.

BugLink: http://bugs.launchpad.net/bugs/787749
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
6 years agobonding: Incorrect TX queue offset, CVE-2011-1581
Phil Oester [Mon, 6 Jun 2011 10:35:23 +0000 (11:35 +0100)]
bonding: Incorrect TX queue offset, CVE-2011-1581

When packets come in from a device with >= 16 receive queues
headed out a bonding interface, syslog gets filled with this:

    kernel: bond0 selects TX queue 16, but real number of TX queues is 16

because queue_mapping is offset by 1.  Adjust return value
to account for the offset.

This is a revision of my earlier patch (which did not use the
skb_rx_queue_* helpers - thanks to Ben for the suggestion).
Andy submitted a similar patch which emits a pr_warning on
invalid queue selection, but I believe the log spew is
not useful.  We can revisit that question in the future,
but in the interim I believe fixing the core problem is
worthwhile.

Signed-off-by: Phil Oester <kernel@linuxace.com>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit fd0e435b0fe85622f167b84432552885a4856ac8)
CVE-2011-1581
BugLink: http://bugs.launchpad.net/bugs/792312
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
6 years agoagp: fix OOM and buffer overflow
Vasiliy Kulikov [Thu, 14 Apr 2011 16:55:19 +0000 (20:55 +0400)]
agp: fix OOM and buffer overflow

BugLink: http://bugs.launchpad.net/bugs/775809
commit b522f02184b413955f3bc952e3776ce41edc6355 upstream.

page_count is copied from userspace.  agp_allocate_memory() tries to
check whether this number is too big, but doesn't take into account the
wrap case.  Also agp_create_user_memory() doesn't check whether
alloc_size is calculated from num_agp_pages variable without overflow.
This may lead to allocation of too small buffer with following buffer
overflow.

Another problem in agp code is not addressed in the patch - kernel memory
exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls).  It is not checked
whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()).
Each allocation is limited to 16KB, though, there is no per-process limit.
This might lead to OOM situation, which is not even solved in case of the
caller death by OOM killer - the memory is allocated for another (faked) process.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
6 years agocan: add missing socket check in can/raw release
Oliver Hartkopp [Wed, 20 Apr 2011 01:57:15 +0000 (01:57 +0000)]
can: add missing socket check in can/raw release

BugLink: http://bugs.launchpad.net/bugs/780546
commit 10022a6c66e199d8f61d9044543f38785713cbbd upstream.

v2: added space after 'if' according code style.

We can get here with a NULL socket argument passed from userspace,
so we need to handle it accordingly.

Thanks to Dave Jones pointing at this issue in net/can/bcm.c

Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
6 years agoagp: fix arbitrary kernel memory writes
Vasiliy Kulikov [Thu, 14 Apr 2011 16:55:16 +0000 (20:55 +0400)]
agp: fix arbitrary kernel memory writes

BugLink: http://bugs.launchpad.net/bugs/775809
commit 194b3da873fd334ef183806db751473512af29ce upstream.

pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl
cmds of agp_ioctl() and passed to agpioc_bind_wrap().  As said in the
comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND,
and it is not checked at all in case of AGPIOC_UNBIND.  As a result, user
with sufficient privileges (usually "video" group) may generate either
local DoS or privilege escalation.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
6 years agompt2sas: prevent heap overflows and unchecked reads
Dan Rosenberg [Tue, 5 Apr 2011 16:45:59 +0000 (12:45 -0400)]
mpt2sas: prevent heap overflows and unchecked reads

BugLink: http://bugs.launchpad.net/bugs/780546
commit a1f74ae82d133ebb2aabb19d181944b4e83e9960 upstream.

At two points in handling device ioctls via /dev/mpt2ctl, user-supplied
length values are used to copy data from userspace into heap buffers
without bounds checking, allowing controllable heap corruption and
subsequently privilege escalation.

Additionally, user-supplied values are used to determine the size of a
copy_to_user() as well as the offset into the buffer to be read, with no
bounds checking, allowing users to read arbitrary kernel memory.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Acked-by: Eric Moore <eric.moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
6 years agoUBUNTU: Start new release
Paolo Pisati [Mon, 30 May 2011 12:47:52 +0000 (14:47 +0200)]
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
6 years agoUBUNTU: Ubuntu-2.6.38-1209.13
Bryan Wu [Thu, 28 Apr 2011 05:56:45 +0000 (13:56 +0800)]
UBUNTU: Ubuntu-2.6.38-1209.13

Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
6 years agoUBUNTU: Bump ABI
Bryan Wu [Thu, 28 Apr 2011 05:55:16 +0000 (13:55 +0800)]
UBUNTU: Bump ABI

Ignore: yes
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
6 years agoUBUNTU: [Config] Sync up configs for 2.6.38.4
Bryan Wu [Thu, 28 Apr 2011 05:53:43 +0000 (13:53 +0800)]
UBUNTU: [Config] Sync up configs for 2.6.38.4

Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
6 years agoUBUNTU: cherry-pick 6 patches from u2 of 'for-ubuntu' branch
Bryan Wu [Thu, 28 Apr 2011 05:24:41 +0000 (13:24 +0800)]
UBUNTU: cherry-pick 6 patches from u2 of 'for-ubuntu' branch

Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
6 years agoarm/dt: vexpress: Update basic DT to use skeleton.dtsi file.
Grant Likely [Thu, 14 Apr 2011 20:59:44 +0000 (14:59 -0600)]
arm/dt: vexpress: Update basic DT to use skeleton.dtsi file.

Converted .dts file to use skeleton.dtsi, and added 'dtbs' target.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
6 years agoarm/dt: Fix broken dtbs rule.
Grant Likely [Thu, 14 Apr 2011 20:58:56 +0000 (14:58 -0600)]
arm/dt: Fix broken dtbs rule.

On recent make, commit 1449fb96, "arm/dt: Add a make rule to build
dtb for enabled boards" breaks build of the kernel immediately:

/projects/linaro/linux-2.6/arch/arm/Makefile:292: *** mixed implicit
and normal rules.  Stop.

> $ rpm -q make
> make-3.82-4.fc15.x86_64
>
> ''The previous behavior of mixing implicit and pattern rules in one line
> like that was never supported or documented, but due to a "hole" in the
> parser it worked for certain specific cases (for example, reversing that
> line so the pattern comes first would not work, nor would adding extra
> explicit targets after the pattern target).
>
> In 3.82, the parser was tightened in this respect and that "hole" was
> closed, hence you see this error.''

This patch splits the rule to fix the bug.

Reported-by: Andy Green <andy.green@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
6 years agoOMAP: Fixed gpio polarity of gpio USB-phy reset.
Juergen Kilb [Thu, 14 Apr 2011 07:31:43 +0000 (09:31 +0200)]
OMAP: Fixed gpio polarity of gpio USB-phy reset.

With commit 19403165 a main part of ehci-omap.c moved to
drivers/mfd/omap-usb-host.c created by commit 17cdd29d.
Due to this reorganisation the polarity used to reset the
external USB phy changed and USB host doesn't recognize
any devices.

Signed-off-by: Juergen Kilb <J.Kilb@phytec.de>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
6 years agoARM: vexpress: add basic dts DT source
Lorenzo Pieralisi [Wed, 13 Apr 2011 18:02:21 +0000 (19:02 +0100)]
ARM: vexpress: add basic dts DT source

This patch provides a simple device tree source for the Versatile
Express board. It just defines memory layout and assigns a compatible string
to the board.

Compiled blob tested on Versatile Express, passed to the kernel
through u-boot. 'chosen' node defined within u-boot to avoid cluttering
the default dts configuration.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
6 years agoARM: vexpress: add basic DT platform matching support
Lorenzo Pieralisi [Wed, 13 Apr 2011 18:02:20 +0000 (19:02 +0100)]
ARM: vexpress: add basic DT platform matching support

This patch adds a DT match table to the Versatile Express machine
description in order to enable basic device tree support.

Tested on a Versatile Express board where the device tree blob is
passed to the kernel by u-boot.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
6 years agoARM: EXYNOS4: Register HSMMC2 before HSMMC0 on SMDKV310 board
Tushar Behera [Wed, 13 Apr 2011 04:38:54 +0000 (10:08 +0530)]
ARM: EXYNOS4: Register HSMMC2 before HSMMC0 on SMDKV310 board

On Exynos4210 SOC, of all the HSMMC controllers only HSMMC2 can
be used as a boot media. Hence the default SD/MMC card should be
connected to HSMMC2. The secondary card is connected to HSMMC0.

If HSMMC0 is registered before HSMMC2, the device node for default
MMC card changes depending on whether secondary card is connected
or not. It creates problem in mounting the file-system present in
default SD/MMC card. Hence HSMMC2 should be registered before HSMMC0.

Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
6 years agoUBUNTU: merge Ubuntu-2.6.38-9.43
Bryan Wu [Thu, 28 Apr 2011 03:53:06 +0000 (11:53 +0800)]
UBUNTU: merge Ubuntu-2.6.38-9.43

Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
6 years agoMerge 'Ubuntu-2.6.38-9.43' into ti-omap4
Bryan Wu [Thu, 28 Apr 2011 03:43:48 +0000 (11:43 +0800)]
Merge 'Ubuntu-2.6.38-9.43' into ti-omap4

Conflicts:
include/net/bluetooth/hci.h

Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
6 years agoUBUNTU: Start new release
Bryan Wu [Thu, 28 Apr 2011 03:42:23 +0000 (11:42 +0800)]
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
6 years agoUBUNTU: Ubuntu-2.6.38-9.43
Brad Figg [Thu, 28 Apr 2011 00:12:39 +0000 (17:12 -0700)]
UBUNTU: Ubuntu-2.6.38-9.43

Signed-off-by: Brad Figg <brad.figg@canonical.com>
6 years ago(pre-stable) drm/i915: Sanitize the output registers after resume
Chris Wilson [Tue, 12 Apr 2011 17:06:51 +0000 (18:06 +0100)]
(pre-stable) drm/i915: Sanitize the output registers after resume

BugLink: http://bugs.launchpad.net/bugs/745304
Similar to booting, we need to inspect the state left by the BIOS and
remove any conflicting bits before we take over. The example reported by
Seth Forshee is very similar to the bug we encountered with the state left
by grub2, that the crtc pipe<->planning mapping was reversed from our
expectations and so we failed to turn off the outputs when booting or,
in this case, resuming. This may be in fact the same bug, but triggered
at resume time.

This patch rearranges the code we already have to clear up the
conflicting state upon init and calls it from reset (which is called
after we have lost control of the hardware, i.e. along both the boot and
resume paths) instead.

Reported-and-tested-by: Seth Forshee <seth.forshee@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35796
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
6 years agoUBUNTU: [Config] s/USB_MUSB_TUSB6010/USB_MUSB_OMAP2PLUS/ on omap3 to get musb
Paolo Pisati [Wed, 13 Apr 2011 15:20:11 +0000 (17:20 +0200)]
UBUNTU: [Config] s/USB_MUSB_TUSB6010/USB_MUSB_OMAP2PLUS/ on omap3 to get musb

BugLink: https://bugs.launchpad.net/ubuntu/+bug/759913
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
6 years agoUBUNTU: SAUCE: Revert "x86, hibernate: Initialize mmu_cr4_features during boot"
Herton Ronaldo Krzesinski [Mon, 18 Apr 2011 15:38:49 +0000 (12:38 -0300)]
UBUNTU: SAUCE: Revert "x86, hibernate: Initialize mmu_cr4_features during boot"

This reverts commit 60d3abc3a55c37376c989e65f87fe25f78281793.

Since the update to 2.6.38.3, this fix isn't needed, as the problematic
commit ("x86: Cleanup highmap after brk is concluded") which required it
got reverted. To keep things clean, revert the fix too.

BugLink: http://bugs.launchpad.net/bugs/764758
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
6 years agofs/partitions/ldm.c: fix oops caused by corrupted partition table, CVE-2011-1017
Timo Warns [Tue, 26 Apr 2011 20:37:09 +0000 (13:37 -0700)]
fs/partitions/ldm.c: fix oops caused by corrupted partition table, CVE-2011-1017

BugLink: http://bugs.launchpad.net/bugs/771382
CVE-2011-1017

The kernel automatically evaluates partition tables of storage devices.
The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains
a bug that causes a kernel oops on certain corrupted LDM partitions.
A kernel subsystem seems to crash, because, after the oops, the kernel no
longer recognizes newly connected storage devices.

The patch validates the value of vblk_size.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Timo Warns <warns@pre-sense.de>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Cc: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Richard Russon <rich@flatcap.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry-pick from commit c340b1d640001c8c9ecff74f68fd90422ae2448a)
Signed-off-by: Brad Figg <brad.figg@canonical.com>
Acked-by: John Johansen <john.johansen@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
6 years agoUBUNTU: [Config] Add cachefiles.ko to virtual flavour
Tim Gardner [Mon, 25 Apr 2011 19:41:36 +0000 (13:41 -0600)]
UBUNTU: [Config] Add cachefiles.ko to virtual flavour

BugLink: http://bugs.launchpad.net/bugs/770430
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
6 years ago(pre stable) ath9k_hw: partially revert "fix dma descriptor rx error bit parsing"
Felix Fietkau [Thu, 13 Jan 2011 23:06:27 +0000 (00:06 +0100)]
(pre stable) ath9k_hw: partially revert "fix dma descriptor rx error bit parsing"

BugLink: http://bugs.launchpad.net/bugs/735171
The rx error bit parsing was changed to consider PHY errors and various
decryption errors separately. While correct according to the documentation,
this is causing spurious decryption error reports in some situations.

Fix this by restoring the original order of the checks in those places,
where the errors are meant to be mutually exclusive.

If a CRC error is reported, then MIC failure and decryption errors
are irrelevant, and a PHY error is unlikely.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(cherry picked from commit 115dad7a7f42e68840392767323ceb9306dbdb36)

Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
6 years agoUBUNTU: [Config] updateconfigs for 2.6.38.4
Leann Ogasawara [Fri, 22 Apr 2011 17:01:21 +0000 (10:01 -0700)]
UBUNTU: [Config] updateconfigs for 2.6.38.4

Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoLinux 2.6.38.4
Greg Kroah-Hartman [Thu, 21 Apr 2011 21:34:46 +0000 (14:34 -0700)]
Linux 2.6.38.4

BugLink: http://bugs.launchpad.net/bugs/769042
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoip: ip_options_compile() resilient to NULL skb route
Eric Dumazet [Thu, 14 Apr 2011 05:55:37 +0000 (05:55 +0000)]
ip: ip_options_compile() resilient to NULL skb route

BugLink: http://bugs.launchpad.net/bugs/769042
commit c65353daf137dd41f3ede3baf62d561fca076228 upstream.

Scot Doyle demonstrated ip_options_compile() could be called with an skb
without an attached route, using a setup involving a bridge, netfilter,
and forged IP packets.

Let's make ip_options_compile() and ip_options_rcv_srr() a bit more
robust, instead of changing bridge/netfilter code.

With help from Hiroaki SHIMODA.

Reported-by: Scot Doyle <lkml@scotdoyle.com>
Tested-by: Scot Doyle <lkml@scotdoyle.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agobridge: reset IPCB in br_parse_ip_options
Eric Dumazet [Tue, 12 Apr 2011 20:39:14 +0000 (13:39 -0700)]
bridge: reset IPCB in br_parse_ip_options

BugLink: http://bugs.launchpad.net/bugs/769042
commit f8e9881c2aef1e982e5abc25c046820cd0b7cf64 upstream.

Commit 462fb2af9788a82 (bridge : Sanitize skb before it enters the IP
stack), missed one IPCB init before calling ip_options_compile()

Thanks to Scot Doyle for his tests and bug reports.

Reported-by: Scot Doyle <lkml@scotdoyle.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Acked-by: Bandan Das <bandan.das@stratus.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Cc: Jan Lübbe <jluebbe@debian.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoperf tool: Fix gcc 4.6.0 issues
Kyle McMartin [Mon, 24 Jan 2011 16:13:04 +0000 (11:13 -0500)]
perf tool: Fix gcc 4.6.0 issues

BugLink: http://bugs.launchpad.net/bugs/769042
commit fb7d0b3cefb80a105f7fd26bbc62e0cbf9192822 upstream.

GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf
due to the -Werror=unused-but-set-variable flag.

I've gone through and annotated some of the assignments that had side
effects (ie: return value from a function) with the __used annotation,
and in some cases, just removed unused code.

In a few cases, we were assigning something useful, but not using it in
later parts of the function.

kyle@dreadnought:~/src% gcc --version
gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3)

Cc: Ingo Molnar <mingo@redhat.com>
LKML-Reference: <20110124161304.GK27353@bombadil.infradead.org>
Signed-off-by: Kyle McMartin <kyle@redhat.com>
[ committer note: Fixed up the annotation fixes, as that code moved recently ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
[Backported to 2.6.38.2 by deleting unused but set variables]
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoBluetooth: Fix HCI_RESET command synchronization
Gustavo F. Padovan [Wed, 16 Mar 2011 18:36:29 +0000 (15:36 -0300)]
Bluetooth: Fix HCI_RESET command synchronization

BugLink: http://bugs.launchpad.net/bugs/769042
BugLink: http://bugs.launchpad.net/bugs/700292
commit f630cf0d5434e3923e1b8226ffa2753ead6b0ce5 upstream.

We can't send new commands before a cmd_complete for the HCI_RESET command
shows up.

Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Reported-by: Justin P. Mattock <justinmattock@gmail.com>
Reported-by: Ed Tomlinson <edt@aei.ca>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Tested-by: Justin P. Mattock <justinmattock@gmail.com>
Tested-by: Mikko Vinni <mmvinni@yahoo.com>
Tested-by: Ed Tomlinson <edt@aei.ca>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoradeon: Fix KMS CP writeback on big endian machines.
Michel Dänzer [Thu, 7 Apr 2011 14:17:47 +0000 (16:17 +0200)]
radeon: Fix KMS CP writeback on big endian machines.

BugLink: http://bugs.launchpad.net/bugs/769042
commit dc66b325f161bb651493c7d96ad44876b629cf6a upstream.

This is necessary even with PCI(e) GART, and it makes writeback work even with
AGP on my PowerBook. Might still be unreliable with older revisions of UniNorth
and other AGP bridges though.

Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Reviewed-by: Alex Deucher <alex.deucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: Fix unplug of device with active streams
Matthew Wilcox [Tue, 28 Sep 2010 04:57:32 +0000 (00:57 -0400)]
USB: Fix unplug of device with active streams

BugLink: http://bugs.launchpad.net/bugs/769042
commit b214f191d95ba4b5a35aebd69cd129cf7e3b1884 upstream.

If I unplug a device while the UAS driver is loaded, I get an oops
in usb_free_streams().  This is because usb_unbind_interface() calls
usb_disable_interface() which calls usb_disable_endpoint() which sets
ep_out and ep_in to NULL.  Then the UAS driver calls usb_pipe_endpoint()
which returns a NULL pointer and passes an array of NULL pointers to
usb_free_streams().

I think the correct fix for this is to check for the NULL pointer
in usb_free_streams() rather than making the driver check for this
situation.  My original patch for this checked for dev->state ==
USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is
conditional, so not all drivers would want this check.

Note from Sarah Sharp: This patch does avoid a potential dereference,
but the real fix (which will be implemented later) is to set the
.soft_unbind flag in the usb_driver structure for the UAS driver, and
all drivers that allocate streams.  The driver should free any streams
when it is unbound from the interface.  This avoids leaking stream rings
in the xHCI driver when usb_disable_interface() is called.

This should be queued for stable trees back to 2.6.35.

Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: xhci - also free streams when resetting devices
Dmitry Torokhov [Wed, 13 Apr 2011 06:06:28 +0000 (23:06 -0700)]
USB: xhci - also free streams when resetting devices

BugLink: http://bugs.launchpad.net/bugs/769042
commit 2dea75d96ade3c7cd2bfe73f99c7b3291dc3d03a upstream.

Currently, when resetting a device, xHCI driver disables all but one
endpoints and frees their rings, but leaves alone any streams that
might have been allocated. Later, when users try to free allocated
streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
ep->ring is NULL.

Let's free not only rings but also stream data as well, so that
calling free_streams() on a device that was reset will be safe.

This should be queued for stable trees back to 2.6.35.

Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: xhci - fix math in xhci_get_endpoint_interval()
Dmitry Torokhov [Thu, 24 Mar 2011 05:41:23 +0000 (22:41 -0700)]
USB: xhci - fix math in xhci_get_endpoint_interval()

BugLink: http://bugs.launchpad.net/bugs/769042
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a upstream.

When parsing exponent-expressed intervals we subtract 1 from the
value and then expect it to match with original + 1, which is
highly unlikely, and we end with frequent spew:

usb 3-4: ep 0x83 - rounding interval to 512 microframes

Also, parsing interval for fullspeed isochronous endpoints was
incorrect - according to USB spec they use exponent-based
intervals (but xHCI spec claims frame-based intervals). I trust
USB spec more, especially since USB core agrees with it.

This should be queued for stable kernels back to 2.6.31.

Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: xhci - fix unsafe macro definitions
Dmitry Torokhov [Sun, 20 Mar 2011 09:15:17 +0000 (02:15 -0700)]
USB: xhci - fix unsafe macro definitions

BugLink: http://bugs.launchpad.net/bugs/769042
commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream.

Macro arguments used in expressions need to be enclosed in parenthesis
to avoid unpleasant surprises.

This should be queued for kernels back to 2.6.31

Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices
Dmitry Torokhov [Sat, 19 Mar 2011 04:29:01 +0000 (21:29 -0700)]
USB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices

BugLink: http://bugs.launchpad.net/bugs/769042
commit 2868a2b1ba8f9c7f6c4170519ebb6c62934df70e upstream.

Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
for decoding bInterval values as HighSpeed ones so adjust the code
accordingly.

Also bandwidth reservation for SuperSpeed matches highspeed, not
low/full speed.

Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: EHCI: unlink unused QHs when the controller is stopped
Alan Stern [Tue, 5 Apr 2011 17:36:15 +0000 (13:36 -0400)]
USB: EHCI: unlink unused QHs when the controller is stopped

BugLink: http://bugs.launchpad.net/bugs/769042
commit 94ae4976e253757e9b03a44d27d41b20f1829d80 upstream.

This patch (as1458) fixes a problem affecting ultra-reliable systems:
When hardware failover of an EHCI controller occurs, the data
structures do not get released correctly.  This is because the routine
responsible for removing unused QHs from the async schedule assumes
the controller is running properly (the frame counter is used in
determining how long the QH has been idle) -- but when a failover
causes the controller to be electronically disconnected from the PCI
bus, obviously it stops running.

The solution is simple: Allow scan_async() to remove a QH from the
async schedule if it has been idle for long enough _or_ if the
controller is stopped.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-Tested-by: Dan Duval <dan.duval@stratus.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agousb: qcserial add missing errorpath kfrees
Steven Hardy [Mon, 4 Apr 2011 17:02:25 +0000 (18:02 +0100)]
usb: qcserial add missing errorpath kfrees

BugLink: http://bugs.launchpad.net/bugs/769042
commit cb62d65f966146a39fdde548cb474dacf1d00fa5 upstream.

There are two -ENODEV error paths in qcprobe where the allocated private
data is not freed, this patch adds the two missing kfrees to avoid
leaking memory on the error path

Signed-off-by: Steven Hardy <shardy@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agousb: qcserial avoid pointing to freed memory
Steven Hardy [Mon, 4 Apr 2011 16:59:55 +0000 (17:59 +0100)]
usb: qcserial avoid pointing to freed memory

BugLink: http://bugs.launchpad.net/bugs/769042
commit 99ab3f9e4eaec35fd2d7159c31b71f17f7e613e3 upstream.

Rework the qcprobe logic such that serial->private is not set when
qcprobe exits with -ENODEV, otherwise serial->private will point to freed
memory on -ENODEV

Signed-off-by: Steven Hardy <shardy@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agousb: Fix qcserial memory leak on rmmod
Steven Hardy [Mon, 4 Apr 2011 16:57:37 +0000 (17:57 +0100)]
usb: Fix qcserial memory leak on rmmod

BugLink: http://bugs.launchpad.net/bugs/769042
commit 10c9ab15d6aee153968d150c05b3ee3df89673de upstream.

qcprobe function allocates serial->private but this is never freed, this
patch adds a new function qc_release() which frees serial->private, after
calling usb_wwan_release

Signed-off-by: Steven Hardy <shardy@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agopowerpc/perf_event: Skip updating kernel counters if register value shrinks
Eric B Munson [Fri, 15 Apr 2011 08:12:30 +0000 (08:12 +0000)]
powerpc/perf_event: Skip updating kernel counters if register value shrinks

BugLink: http://bugs.launchpad.net/bugs/769042
commit 86c74ab317c1ef4d37325e0d7ca8a01a796b0bd7 upstream.

Because of speculative event roll back, it is possible for some event coutners
to decrease between reads on POWER7.  This causes a problem with the way that
counters are updated.  Delta calues are calculated in a 64 bit value and the
top 32 bits are masked.  If the register value has decreased, this leaves us
with a very large positive value added to the kernel counters.  This patch
protects against this by skipping the update if the delta would be negative.
This can lead to a lack of precision in the coutner values, but from my testing
the value is typcially fewer than 10 samples at a time.

Signed-off-by: Eric B Munson <emunson@mgebm.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agopowerpc: Fix oops if scan_dispatch_log is called too early
Anton Blanchard [Thu, 7 Apr 2011 21:44:21 +0000 (21:44 +0000)]
powerpc: Fix oops if scan_dispatch_log is called too early

BugLink: http://bugs.launchpad.net/bugs/769042
commit 84ffae55af79d7b8834fd0c08d0d1ebf2c77f91e upstream.

We currently enable interrupts before the dispatch log for the boot
cpu is setup. If a timer interrupt comes in early enough we oops in
scan_dispatch_log:

Unable to handle kernel paging request for data at address 0x00000010

...

.scan_dispatch_log+0xb0/0x170
.account_system_vtime+0xa0/0x220
.irq_enter+0x88/0xc0
.do_IRQ+0x48/0x230

The patch below adds a check to scan_dispatch_log to ensure the
dispatch log has been allocated.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoproc: do proper range check on readdir offset
Linus Torvalds [Mon, 18 Apr 2011 17:36:54 +0000 (10:36 -0700)]
proc: do proper range check on readdir offset

BugLink: http://bugs.launchpad.net/bugs/769042
commit d8bdc59f215e62098bc5b4256fd9928bf27053a1 upstream.

Rather than pass in some random truncated offset to the pid-related
functions, check that the offset is in range up-front.

This is just cleanup, the previous commit fixed the real problem.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agonext_pidmap: fix overflow condition
Linus Torvalds [Mon, 18 Apr 2011 17:35:30 +0000 (10:35 -0700)]
next_pidmap: fix overflow condition

BugLink: http://bugs.launchpad.net/bugs/769042
commit c78193e9c7bcbf25b8237ad0dec82f805c4ea69b upstream.

next_pidmap() just quietly accepted whatever 'last' pid that was passed
in, which is not all that safe when one of the users is /proc.

Admittedly the proc code should do some sanity checking on the range
(and that will be the next commit), but that doesn't mean that the
helper functions should just do that pidmap pointer arithmetic without
checking the range of its arguments.

So clamp 'last' to PID_MAX_LIMIT.  The fact that we then do "last+1"
doesn't really matter, the for-loop does check against the end of the
pidmap array properly (it's only the actual pointer arithmetic overflow
case we need to worry about, and going one bit beyond isn't going to
overflow).

[ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ]

Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>
Analyzed-by: Robert Święcki <robert@swiecki.net>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: option: Added support for Samsung GT-B3730/GT-B3710 LTE USB modem.
Marius B. Kotsbak [Mon, 21 Mar 2011 23:01:53 +0000 (00:01 +0100)]
USB: option: Added support for Samsung GT-B3730/GT-B3710 LTE USB modem.

BugLink: http://bugs.launchpad.net/bugs/769042
commit 80f9df3e0093ad9f1eeefd2ff7fd27daaa518d25 upstream.

Bind only modem AT command endpoint to option.

Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: ftdi_sio: add ids for Hameg HO720 and HO730
Paul Friedrich [Fri, 18 Mar 2011 10:13:55 +0000 (11:13 +0100)]
USB: ftdi_sio: add ids for Hameg HO720 and HO730

BugLink: http://bugs.launchpad.net/bugs/769042
commit c53c2fab40cf16e13af66f40bfd27200cda98d2f upstream.

usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720
and HO730

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: ftdi_sio: add PID for OCT DK201 docking station
Johan Hovold [Fri, 8 Apr 2011 15:38:22 +0000 (17:38 +0200)]
USB: ftdi_sio: add PID for OCT DK201 docking station

BugLink: http://bugs.launchpad.net/bugs/769042
commit 11a31d84129dc3133417d626643d714c9df5317e upstream.

Add PID 0x0103 for serial port of the OCT DK201 docking station.

Reported-by: Jan Hoogenraad <jan@hoogenraad.net>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUSB: ftdi_sio: Added IDs for CTI USB Serial Devices
Christian Simon [Mon, 28 Mar 2011 19:54:47 +0000 (21:54 +0200)]
USB: ftdi_sio: Added IDs for CTI USB Serial Devices

BugLink: http://bugs.launchpad.net/bugs/769042
commit 5a9443f08c83c294c5c806a689c1184b27cb26b3 upstream.

I added new ProdutIds for two devices from CTI GmbH Leipzig.

Signed-off-by: Christian Simon <simon@swine.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agousb: musb: temporarily make it bool
Felipe Balbi [Tue, 22 Mar 2011 09:31:37 +0000 (11:31 +0200)]
usb: musb: temporarily make it bool

BugLink: http://bugs.launchpad.net/bugs/769042
commit 7a180e70cfc56e131bfe4796773df2acfc7d4180 upstream.

Due to the recent changes to musb's glue layers,
we can't compile musb-hdrc as a module - compilation
will break due to undefined symbol musb_debug. In
order to fix that, we need a big re-work of the
debug support on the MUSB driver.

Because that would mean a lot of new code coming
into the -rc series, it's best to defer that to
next merge window and for now just disable module
support for MUSB.

Once we get the refactor of the debugging support
done, we can simply revert this patch and things
will go back to normal again.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agobrk: COMPAT_BRK: fix detection of randomized brk
Jiri Kosina [Thu, 14 Apr 2011 22:22:09 +0000 (15:22 -0700)]
brk: COMPAT_BRK: fix detection of randomized brk

BugLink: http://bugs.launchpad.net/bugs/769042
commit 4471a675dfc7ca676c165079e91c712b09dc9ce4 upstream.

5520e89 ("brk: fix min_brk lower bound computation for COMPAT_BRK")
tried to get the whole logic of brk randomization for legacy
(libc5-based) applications finally right.

It turns out that the way to detect whether brk has actually been
randomized in the end or not introduced by that patch still doesn't work
for those binaries, as reported by Geert:

: /sbin/init from my old m68k ramdisk exists prematurely.
:
: Before the patch:
:
: | brk(0x80005c8e)                         = 0x80006000
:
: After the patch:
:
: | brk(0x80005c8e)                         = 0x80005c8e
:
: Old libc5 considers brk() to have failed if the return value is not
: identical to the requested value.

I don't like it, but currently see no better option than a bit flag in
task_struct to catch the CONFIG_COMPAT_BRK && randomize_va_space == 2
case.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agovmscan: all_unreclaimable() use zone->all_unreclaimable as a name
KOSAKI Motohiro [Thu, 14 Apr 2011 22:22:12 +0000 (15:22 -0700)]
vmscan: all_unreclaimable() use zone->all_unreclaimable as a name

BugLink: http://bugs.launchpad.net/bugs/769042
commit 929bea7c714220fc76ce3f75bef9056477c28e74 upstream.

all_unreclaimable check in direct reclaim has been introduced at 2.6.19
by following commit.

2006 Sep 25; commit 408d8544; oom: use unreclaimable info

And it went through strange history. firstly, following commit broke
the logic unintentionally.

2008 Apr 29; commit a41f24ea; page allocator: smarter retry of
      costly-order allocations

Two years later, I've found obvious meaningless code fragment and
restored original intention by following commit.

2010 Jun 04; commit bb21c7ce; vmscan: fix do_try_to_free_pages()
      return value when priority==0

But, the logic didn't works when 32bit highmem system goes hibernation
and Minchan slightly changed the algorithm and fixed it .

2010 Sep 22: commit d1908362: vmscan: check all_unreclaimable
      in direct reclaim path

But, recently, Andrey Vagin found the new corner case. Look,

struct zone {
  ..
        int                     all_unreclaimable;
  ..
        unsigned long           pages_scanned;
  ..
}

zone->all_unreclaimable and zone->pages_scanned are neigher atomic
variables nor protected by lock.  Therefore zones can become a state of
zone->page_scanned=0 and zone->all_unreclaimable=1.  In this case, current
all_unreclaimable() return false even though zone->all_unreclaimabe=1.

This resulted in the kernel hanging up when executing a loop of the form

1. fork
2. mmap
3. touch memory
4. read memory
5. munmmap

as described in
http://www.gossamer-threads.com/lists/linux/kernel/1348725#1348725

Is this ignorable minor issue?  No.  Unfortunately, x86 has very small dma
zone and it become zone->all_unreclamble=1 easily.  and if it become
all_unreclaimable=1, it never restore all_unreclaimable=0.  Why?  if
all_unreclaimable=1, vmscan only try DEF_PRIORITY reclaim and
a-few-lru-pages>>DEF_PRIORITY always makes 0.  that mean no page scan at
all!

Eventually, oom-killer never works on such systems.  That said, we can't
use zone->pages_scanned for this purpose.  This patch restore
all_unreclaimable() use zone->all_unreclaimable as old.  and in addition,
to add oom_killer_disabled check to avoid reintroduce the issue of commit
d1908362 ("vmscan: check all_unreclaimable in direct reclaim path").

Reported-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agosched: Fix erroneous all_pinned logic
Ken Chen [Fri, 8 Apr 2011 19:20:16 +0000 (12:20 -0700)]
sched: Fix erroneous all_pinned logic

BugLink: http://bugs.launchpad.net/bugs/769042
commit b30aef17f71cf9e24b10c11cbb5e5f0ebe8a85ab upstream.

The scheduler load balancer has specific code to deal with cases of
unbalanced system due to lots of unmovable tasks (for example because of
hard CPU affinity). In those situation, it excludes the busiest CPU that
has pinned tasks for load balance consideration such that it can perform
second 2nd load balance pass on the rest of the system.

This all works as designed if there is only one cgroup in the system.

However, when we have multiple cgroups, this logic has false positives and
triggers multiple load balance passes despite there are actually no pinned
tasks at all.

The reason it has false positives is that the all pinned logic is deep in
the lowest function of can_migrate_task() and is too low level:

load_balance_fair() iterates each task group and calls balance_tasks() to
migrate target load. Along the way, balance_tasks() will also set a
all_pinned variable. Given that task-groups are iterated, this all_pinned
variable is essentially the status of last group in the scanning process.
Task group can have number of reasons that no load being migrated, none
due to cpu affinity. However, this status bit is being propagated back up
to the higher level load_balance(), which incorrectly think that no tasks
were moved.  It kick off the all pinned logic and start multiple passes
attempt to move load onto puller CPU.

To fix this, move the all_pinned aggregation up at the iterator level.
This ensures that the status is aggregated over all task-groups, not just
last one in the list.

Signed-off-by: Ken Chen <kenchen@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/BANLkTi=ernzNawaR5tJZEsV_QVnfxqXmsQ@mail.gmail.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoRTC: add missing "return 0" in new alarm func for rtc-bfin.c
Mike Frysinger [Fri, 18 Mar 2011 08:26:24 +0000 (04:26 -0400)]
RTC: add missing "return 0" in new alarm func for rtc-bfin.c

BugLink: http://bugs.launchpad.net/bugs/769042
commit 8c122b96866580c99e44f3f07ac93a993d964ec3 upstream.

The new bfin_rtc_alarm_irq_enable function forgot to add a "return 0" to
the end leading to the build warning:
drivers/rtc/rtc-bfin.c: In function 'bfin_rtc_alarm_irq_enable':
drivers/rtc/rtc-bfin.c:253: warning: control reaches end of non-void function

CC: Thomas Gleixner <tglx@linutronix.de>
CC: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoi2c-algo-bit: Call pre/post_xfer for bit_test
Alex Deucher [Sun, 17 Apr 2011 08:20:19 +0000 (10:20 +0200)]
i2c-algo-bit: Call pre/post_xfer for bit_test

BugLink: http://bugs.launchpad.net/bugs/769042
commit d3b3e15da14ded61c9654db05863b04a2435f4cc upstream.

Apparently some distros set i2c-algo-bit.bit_test to 1 by
default.  In some cases this causes i2c_bit_add_bus
to fail and prevents the i2c bus from being added.  In the
radeon case, we fail to add the ddc i2c buses which prevents
the driver from being able to detect attached monitors.
The i2c bus works fine even if bit_test fails.  This is likely
due to gpio switching that is required and handled in the
pre/post_xfer hooks, so call the pre/post_xfer hooks in the
bit test as well.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=36221

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoARM: 6864/1: hw_breakpoint: clear DBGVCR out of reset
Will Deacon [Tue, 5 Apr 2011 12:57:53 +0000 (13:57 +0100)]
ARM: 6864/1: hw_breakpoint: clear DBGVCR out of reset

BugLink: http://bugs.launchpad.net/bugs/769042
commit e89c0d7090c54d7b11b9b091e495a1ae345dd3ff upstream.

The DBGVCR, used for configuring vector catch debug events, is UNKNOWN
out of reset on ARMv7. When enabling monitor mode, this must be zeroed
to avoid UNPREDICTABLE behaviour.

This patch adds the zeroing code to the debug reset path.

Reported-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agovfs: Fix absolute RCU path walk failures due to uninitialized seq number
Tim Chen [Fri, 15 Apr 2011 18:39:29 +0000 (11:39 -0700)]
vfs: Fix absolute RCU path walk failures due to uninitialized seq number

BugLink: http://bugs.launchpad.net/bugs/769042
commit c1530019e311c91d14b24d8e74d233152d806e45 upstream.

During RCU walk in path_lookupat and path_openat, the rcu lookup
frequently failed if looking up an absolute path, because when root
directory was looked up, seq number was not properly set in nameidata.

We dropped out of RCU walk in nameidata_drop_rcu due to mismatch in
directory entry's seq number.  We reverted to slow path walk that need
to take references.

With the following patch, I saw a 50% increase in an exim mail server
benchmark throughput on a 4-socket Nehalem-EX system.

Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agox86, amd: Disable GartTlbWlkErr when BIOS forgets it
Joerg Roedel [Fri, 15 Apr 2011 12:47:40 +0000 (14:47 +0200)]
x86, amd: Disable GartTlbWlkErr when BIOS forgets it

BugLink: http://bugs.launchpad.net/bugs/769042
commit 5bbc097d890409d8eff4e3f1d26f11a9d6b7c07e upstream.

This patch disables GartTlbWlk errors on AMD Fam10h CPUs if
the BIOS forgets to do is (or is just too old). Letting
these errors enabled can cause a sync-flood on the CPU
causing a reboot.

The AMD BKDG recommends disabling GART TLB Wlk Error completely.

This patch is the fix for

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

on my machine.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Link: http://lkml.kernel.org/r/20110415131152.GJ18463@8bytes.org
Tested-by: Alexandre Demers <alexandre.f.demers@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agox86, AMD: Set ARAT feature on AMD processors
Boris Ostrovsky [Tue, 15 Mar 2011 16:13:44 +0000 (12:13 -0400)]
x86, AMD: Set ARAT feature on AMD processors

BugLink: http://bugs.launchpad.net/bugs/769042
commit b87cf80af3ba4b4c008b4face3c68d604e1715c6 upstream.

Support for Always Running APIC timer (ARAT) was introduced in
commit db954b5898dd3ef3ef93f4144158ea8f97deb058. This feature
allows us to avoid switching timers from LAPIC to something else
(e.g. HPET) and go into timer broadcasts when entering deep
C-states.

AMD processors don't provide a CPUID bit for that feature but
they also keep APIC timers running in deep C-states (except for
cases when the processor is affected by erratum 400). Therefore
we should set ARAT feature bit on AMD CPUs.

Tested-by: Borislav Petkov <borislav.petkov@amd.com>
Acked-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: Mark Langsdorf <mark.langsdorf@amd.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
LKML-Reference: <1300205624-4813-1-git-send-email-ostr@amd64.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUBIFS: fix oops when R/O file-system is fsync'ed
Artem Bityutskiy [Wed, 13 Apr 2011 07:31:52 +0000 (10:31 +0300)]
UBIFS: fix oops when R/O file-system is fsync'ed

BugLink: http://bugs.launchpad.net/bugs/769042
commit 78530bf7f2559b317c04991b52217c1608d5a58d upstream.

This patch fixes severe UBIFS bug: UBIFS oopses when we 'fsync()' an
file on R/O-mounter file-system. We (the UBIFS authors) incorrectly
thought that VFS would not propagate 'fsync()' down to the file-system
if it is read-only, but this is not the case.

It is easy to exploit this bug using the following simple perl script:

use strict;
use File::Sync qw(fsync sync);

die "File path is not specified" if not defined $ARGV[0];
my $path = $ARGV[0];

open FILE, "<", "$path" or die "Cannot open $path: $!";
fsync(\*FILE) or die "cannot fsync $path: $!";
close FILE or die "Cannot close $path: $!";

Thanks to Reuben Dowle <Reuben.Dowle@navico.com> for reporting about this
issue.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reported-by: Reuben Dowle <Reuben.Dowle@navico.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoMAINTAINERS: update STABLE BRANCH info
Randy Dunlap [Thu, 14 Apr 2011 22:22:07 +0000 (15:22 -0700)]
MAINTAINERS: update STABLE BRANCH info

BugLink: http://bugs.launchpad.net/bugs/769042
commit d00ebeac5f24f290636f7a895dafc124b2930a08 upstream.

Drop Chris Wright from STABLE maintainers.  He hasn't done STABLE release
work for quite some time.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agooom-kill: remove boost_dying_task_prio()
KOSAKI Motohiro [Thu, 14 Apr 2011 22:22:13 +0000 (15:22 -0700)]
oom-kill: remove boost_dying_task_prio()

BugLink: http://bugs.launchpad.net/bugs/769042
commit 341aea2bc48bf652777fb015cc2b3dfa9a451817 upstream.

This is an almost-revert of commit 93b43fa ("oom: give the dying task a
higher priority").

That commit dramatically improved oom killer logic when a fork-bomb
occurs.  But I've found that it has nasty corner case.  Now cpu cgroup has
strange default RT runtime.  It's 0!  That said, if a process under cpu
cgroup promote RT scheduling class, the process never run at all.

If an admin inserts a !RT process into a cpu cgroup by setting
rtruntime=0, usually it runs perfectly because a !RT task isn't affected
by the rtruntime knob.  But if it promotes an RT task via an explicit
setscheduler() syscall or an OOM, the task can't run at all.  In short,
the oom killer doesn't work at all if admins are using cpu cgroup and don't
touch the rtruntime knob.

Eventually, kernel may hang up when oom kill occur.  I and the original
author Luis agreed to disable this logic.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Luis Claudio R. Goncalves <lclaudio@uudg.org>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoramfs: fix memleak on no-mmu arch
Bob Liu [Thu, 14 Apr 2011 22:22:20 +0000 (15:22 -0700)]
ramfs: fix memleak on no-mmu arch

BugLink: http://bugs.launchpad.net/bugs/769042
commit b836aec53e2bce71de1d5415313380688c851477 upstream.

On no-mmu arch, there is a memleak during shmem test.  The cause of this
memleak is ramfs_nommu_expand_for_mapping() added page refcount to 2
which makes iput() can't free that pages.

The simple test file is like this:

  int main(void)
  {
int i;
key_t k = ftok("/etc", 42);

for ( i=0; i<100; ++i) {
int id = shmget(k, 10000, 0644|IPC_CREAT);
if (id == -1) {
printf("shmget error\n");
}
if(shmctl(id, IPC_RMID, NULL ) == -1) {
printf("shm  rm error\n");
return -1;
}
}
printf("run ok...\n");
return 0;
  }

And the result:

  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        17912        42408            0            0
  -/+ buffers:              17912        42408
  root:/> shmem
  run ok...
  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        19096        41224            0            0
  -/+ buffers:              19096        41224
  root:/> shmem
  run ok...
  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        20296        40024            0            0
  -/+ buffers:              20296        40024
  ...

After this patch the test result is:(no memleak anymore)

  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        16668        43652            0            0
  -/+ buffers:              16668        43652
  root:/> shmem
  run ok...
  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        16668        43652            0            0
  -/+ buffers:              16668        43652

Signed-off-by: Bob Liu <lliubbo@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agomm/thp: use conventional format for boolean attributes
Ben Hutchings [Thu, 14 Apr 2011 22:22:21 +0000 (15:22 -0700)]
mm/thp: use conventional format for boolean attributes

BugLink: http://bugs.launchpad.net/bugs/769042
commit e27e6151b154ff6e5e8162efa291bc60196d29ea upstream.

The conventional format for boolean attributes in sysfs is numeric ("0" or
"1" followed by new-line).  Any boolean attribute can then be read and
written using a generic function.  Using the strings "yes [no]", "[yes]
no" (read), "yes" and "no" (write) will frustrate this.

[akpm@linux-foundation.org: use kstrtoul()]
[akpm@linux-foundation.org: test_bit() doesn't return 1/0, per Neil]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Tested-by: David Rientjes <rientjes@google.com>
Cc: NeilBrown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agokstrto*: converting strings to integers done (hopefully) right
Alexey Dobriyan [Tue, 22 Mar 2011 23:34:40 +0000 (16:34 -0700)]
kstrto*: converting strings to integers done (hopefully) right

BugLink: http://bugs.launchpad.net/bugs/769042
commit 33ee3b2e2eb9b4b6c64dcf9ed66e2ac3124e748c upstream.

1. simple_strto*() do not contain overflow checks and crufty,
   libc way to indicate failure.
2. strict_strto*() also do not have overflow checks but the name and
   comments pretend they do.
3. Both families have only "long long" and "long" variants,
   but users want strtou8()
4. Both "simple" and "strict" prefixes are wrong:
   Simple doesn't exactly say what's so simple, strict should not exist
   because conversion should be strict by default.

The solution is to use "k" prefix and add convertors for more types.
Enter
kstrtoull()
kstrtoll()
kstrtoul()
kstrtol()
kstrtouint()
kstrtoint()

kstrtou64()
kstrtos64()
kstrtou32()
kstrtos32()
kstrtou16()
kstrtos16()
kstrtou8()
kstrtos8()

Include runtime testsuite (somewhat incomplete) as well.

strict_strto*() become deprecated, stubbed to kstrto*() and
eventually will be removed altogether.

Use kstrto*() in code today!

Note: on some archs _kstrtoul() and _kstrtol() are left in tree, even if
      they'll be unused at runtime. This is temporarily solution,
      because I don't want to hardcode list of archs where these
      functions aren't needed. Current solution with sizeof() and
      __alignof__ at least always works.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agofutex: Set FLAGS_HAS_TIMEOUT during futex_wait restart setup
Darren Hart [Thu, 14 Apr 2011 22:41:57 +0000 (15:41 -0700)]
futex: Set FLAGS_HAS_TIMEOUT during futex_wait restart setup

BugLink: http://bugs.launchpad.net/bugs/769042
commit 0cd9c6494ee5c19aef085152bc37f3a4e774a9e1 upstream.

The FLAGS_HAS_TIMEOUT flag was not getting set, causing the restart_block to
restart futex_wait() without a timeout after a signal.

Commit b41277dc7a18ee332d in 2.6.38 introduced the regression by accidentally
removing the the FLAGS_HAS_TIMEOUT assignment from futex_wait() during the setup
of the restart block. Restore the originaly behavior.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=32922

Reported-by: Tim Smith <tsmith201104@yahoo.com>
Reported-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: John Kacur <jkacur@redhat.com>
Link: http://lkml.kernel.org/r/%3Cdaac0eb3af607f72b9a4d3126b2ba8fb5ed3b883.1302820917.git.dvhart%40linux.intel.com%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agosparc64: Fix build errors with gcc-4.6.0
David S. Miller [Sun, 27 Feb 2011 07:40:02 +0000 (23:40 -0800)]
sparc64: Fix build errors with gcc-4.6.0

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit c6fee0810df4e0f4cf9c4834d2569ca01c02cffc ]

Most of the warnings emitted (we fail arch/sparc file
builds with -Werror) were legitimate but harmless, however
one case (n2_pcr_write) was a genuine bug.

Based almost entirely upon a patch by Sam Ravnborg.

Reported-by: Dennis Gilmore <dennis@ausil.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agosparc32: Pass task_struct to schedule_tail() in ret_from_fork
Tkhai Kirill [Thu, 31 Mar 2011 07:52:38 +0000 (00:52 -0700)]
sparc32: Pass task_struct to schedule_tail() in ret_from_fork

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit 47c7c97a93a5b8f719093dbf83555090b3b8228b ]

We have to pass task_struct of previous process to function
schedule_tail(). Currently in ret_from_fork previous thread_info
is passed:

switch_to: mov %g6, %g3 /* previous thread_info in g6 */

ret_from_fork: call    schedule_tail
                mov    %g3, %o0 /* previous thread_info is passed */

void schedule_tail(struct task_struct *prev);

Signed-off-by: Tkhai Kirill <tkhai@yandex.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agosparc32: Fix might-be-used-uninitialized warning in do_sparc_fault().
David S. Miller [Wed, 9 Mar 2011 21:00:47 +0000 (13:00 -0800)]
sparc32: Fix might-be-used-uninitialized warning in do_sparc_fault().

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit c816be7b5f24585baa9eba1f2413935f771d6ad6 ]

When we try to handle vmalloc faults, we can take a code
path which uses "code" before we actually set it.

Amusingly gcc-3.3 notices this yet gcc-4.x does not.

Reported-by: Bob Breuer <breuerr@mc.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agosparc: Fix .size directive for do_int_load
Ben Hutchings [Wed, 9 Mar 2011 20:54:27 +0000 (12:54 -0800)]
sparc: Fix .size directive for do_int_load

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit 35043c428f1fcb92feb5792f5878a8852ee00771 ]

gas used to accept (and ignore?) .size directives which referred to
undefined symbols, as this does.  In binutils 2.21 these are treated
as errors.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agobridge: Reset IPCB when entering IP stack on NF_FORWARD
Herbert Xu [Fri, 18 Mar 2011 05:27:28 +0000 (05:27 +0000)]
bridge: Reset IPCB when entering IP stack on NF_FORWARD

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit 6b1e960fdbd75dcd9bcc3ba5ff8898ff1ad30b6e ]

Whenever we enter the IP stack proper from bridge netfilter we
need to ensure that the skb is in a form the IP stack expects
it to be in.

The entry point on NF_FORWARD did not meet the requirements of
the IP stack, therefore leading to potential crashes/panics.

This patch fixes the problem.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agovlan: should take into account needed_headroom
Eric Dumazet [Fri, 18 Mar 2011 00:27:27 +0000 (00:27 +0000)]
vlan: should take into account needed_headroom

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit d870bfb9d366c5d466c0f5419a4ec95a3f71ea8a ]

Commit c95b819ad7 (gre: Use needed_headroom)
made gre use needed_headroom instead of hard_header_len

This uncover a bug in vlan code.

We should make sure vlan devices take into account their
real_dev->needed_headroom or we risk a crash in ipgre_header(), because
we dont have enough room to push IP header in skb.

Reported-by: Diddi Oscarsson <diddi@diddi.se>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoxfrm: Refcount destination entry on xfrm_lookup
Steffen Klassert [Tue, 15 Mar 2011 21:12:49 +0000 (21:12 +0000)]
xfrm: Refcount destination entry on xfrm_lookup

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit fbd5060875d25f7764fd1c3d35b83a8ed1d88d7b ]

We return a destination entry without refcount if a socket
policy is found in xfrm_lookup. This triggers a warning on
a negative refcount when freeeing this dst entry. So take
a refcount in this case to fix it.

This refcount was forgotten when xfrm changed to cache bundles
instead of policies for outgoing flows.

Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agotcp: avoid cwnd moderation in undo
Yuchung Cheng [Mon, 14 Mar 2011 10:57:03 +0000 (10:57 +0000)]
tcp: avoid cwnd moderation in undo

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit 67d4120a1793138bc9f4a6eb61d0fc5298ed97e0 ]

In the current undo logic, cwnd is moderated after it was restored
to the value prior entering fast-recovery. It was moderated first
in tcp_try_undo_recovery then again in tcp_complete_cwr.

Since the undo indicates recovery was false, these moderations
are not necessary. If the undo is triggered when most of the
outstanding data have been acknowledged, the (restored) cwnd is
falsely pulled down to a small value.

This patch removes these cwnd moderations if cwnd is undone
  a) during fast-recovery
b) by receiving DSACKs past fast-recovery

Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agosctp: Pass __GFP_NOWARN to hash table allocation attempts.
David S. Miller [Thu, 31 Mar 2011 00:51:36 +0000 (17:51 -0700)]
sctp: Pass __GFP_NOWARN to hash table allocation attempts.

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit a84b50ceb7d640437d0dc28a2bef0d0de054de89 ]

Like DCCP and other similar pieces of code, there are mechanisms
here to try allocating smaller hash tables if the allocation
fails.  So pass in __GFP_NOWARN like the others do instead of
emitting a scary message.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agopppoe: drop PPPOX_ZOMBIEs in pppoe_flush_dev
Ulrich Weber [Wed, 6 Apr 2011 21:04:49 +0000 (14:04 -0700)]
pppoe: drop PPPOX_ZOMBIEs in pppoe_flush_dev

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit ae07b0b221b6ab2edf9e3abd518aec6cd3f1ba66 ]

otherwise we loop forever if a PPPoE socket was set
to PPPOX_ZOMBIE state by a PADT message when the
ethernet device is going down afterwards.

Signed-off-by: Ulrich Weber <uweber@astaro.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agonet_sched: fix ip_tos2prio
Dan Siemon [Tue, 15 Mar 2011 13:56:07 +0000 (13:56 +0000)]
net_sched: fix ip_tos2prio

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit 4a2b9c3756077c05dd8666e458a751d2248b61b6 ]

ECN support incorrectly maps ECN BESTEFFORT packets to TC_PRIO_FILLER
(1) instead of TC_PRIO_BESTEFFORT (0)

This means ECN enabled flows are placed in pfifo_fast/prio low priority
band, giving ECN enabled flows [ECT(0) and CE codepoints] higher drop
probabilities.

This is rather unfortunate, given we would like ECN being more widely
used.

Ref : http://www.coverfire.com/archives/2011/03/13/pfifo_fast-and-ecn/

Signed-off-by: Dan Siemon <dan@coverfire.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Dave Täht <d@taht.net>
Cc: Jonathan Morton <chromatix99@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agonet ipv6: Fix duplicate /proc/sys/net/ipv6/neigh directory entries.
Eric W. Biederman [Tue, 22 Mar 2011 01:23:34 +0000 (18:23 -0700)]
net ipv6: Fix duplicate /proc/sys/net/ipv6/neigh directory entries.

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit 9d2a8fa96a44ba242de3a6f56acaef7a40a97b97 ]

When I was fixing issues with unregisgtering tables under /proc/sys/net/ipv6/neigh
by adding a mount point it appears I missed a critical ordering issue, in the
ipv6 initialization.  I had not realized that ipv6_sysctl_register is called
at the very end of the ipv6 initialization and in particular after we call
neigh_sysctl_register from ndisc_init.

"neigh" needs to be initialized in ipv6_static_sysctl_register which is
the first ipv6 table to initialized, and definitely before ndisc_init.
This removes the weirdness of duplicate tables while still providing a
"neigh" mount point which prevents races in sysctl unregistering.

This was initially reported at https://bugzilla.kernel.org/show_bug.cgi?id=31232
Reported-by: sunkan@zappa.cx
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agol2tp: fix possible oops on l2tp_eth module unload
James Chapman [Tue, 22 Mar 2011 01:10:25 +0000 (18:10 -0700)]
l2tp: fix possible oops on l2tp_eth module unload

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit 8aa525a9340da4227797a06221ca08399006635f ]

A struct used in the l2tp_eth driver for registering network namespace
ops was incorrectly marked as __net_initdata, leading to oops when
module unloaded.

BUG: unable to handle kernel paging request at ffffffffa00ec098
IP: [<ffffffff8123dbd8>] ops_exit_list+0x7/0x4b
PGD 142d067 PUD 1431063 PMD 195da8067 PTE 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/module/l2tp_eth/refcnt
Call Trace:
 [<ffffffff8123dc94>] ? unregister_pernet_operations+0x32/0x93
 [<ffffffff8123dd20>] ? unregister_pernet_device+0x2b/0x38
 [<ffffffff81068b6e>] ? sys_delete_module+0x1b8/0x222
 [<ffffffff810c7300>] ? do_munmap+0x254/0x318
 [<ffffffff812c64e5>] ? page_fault+0x25/0x30
 [<ffffffff812c6952>] ? system_call_fastpath+0x16/0x1b

Signed-off-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agogianfar: Fall back to software tcp/udp checksum on older controllers
Alex Dubov [Wed, 16 Mar 2011 17:57:13 +0000 (17:57 +0000)]
gianfar: Fall back to software tcp/udp checksum on older controllers

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit 4363c2fddb1399b728ef21ee8101c148a311ea45 ]

As specified by errata eTSEC49 of MPC8548 and errata eTSEC12 of MPC83xx,
older revisions of gianfar controllers will be unable to calculate a TCP/UDP
packet checksum for some alignments of the appropriate FCB. This patch checks
for FCB alignment on such controllers and falls back to software checksumming
if the alignment is known to be bad.

Signed-off-by: Alex Dubov <oakad@yahoo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agofib: add rtnl locking in ip_fib_net_exit
Eric Dumazet [Wed, 30 Mar 2011 23:57:46 +0000 (16:57 -0700)]
fib: add rtnl locking in ip_fib_net_exit

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit e2666f84958adb3a034b98e99699b55705117e01 ]

Daniel J Blueman reported a lockdep splat in trie_firstleaf(), caused by
RTNL being not locked before a call to fib_table_flush()

Reported-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agobridge: Fix possibly wrong MLD queries' ethernet source address
Linus Lüssing [Tue, 22 Mar 2011 11:40:32 +0000 (11:40 +0000)]
bridge: Fix possibly wrong MLD queries' ethernet source address

BugLink: http://bugs.launchpad.net/bugs/769042
[ Upstream commit a7bff75b087e7a355838a32efe61707cfa73c194 ]

The ipv6_dev_get_saddr() is currently called with an uninitialized
destination address. Although in tests it usually seemed to nevertheless
always fetch the right source address, there seems to be a possible race
condition.

Therefore this commit changes this, first setting the destination
address and only after that fetching the source address.

Reported-by: Jan Beulich <JBeulich@novell.com>
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoperf: Fix task context scheduling
Peter Zijlstra [Thu, 31 Mar 2011 08:29:26 +0000 (10:29 +0200)]
perf: Fix task context scheduling

BugLink: http://bugs.launchpad.net/bugs/769042
commit ab711fe08297de1485fff0a366e6db8828cafd6a upstream.

Jiri reported:

 |
 | - once an event is created by sys_perf_event_open, task context
 |   is created and it stays even if the event is closed, until the
 |   task is finished ... thats what I see in code and I assume it's
 |   correct
 |
 | - when the task opens event, perf_sched_events jump label is
 |   incremented and following callbacks are started from scheduler
 |
 |         __perf_event_task_sched_in
 |         __perf_event_task_sched_out
 |
 |   These callback *in/out set/unset cpuctx->task_ctx value to the
 |   task context.
 |
 | - close is called on event on CPU 0:
 |         - the task is scheduled on CPU 0
 |         - __perf_event_task_sched_in is called
 |         - cpuctx->task_ctx is set
 |         - perf_sched_events jump label is decremented and == 0
 |         - __perf_event_task_sched_out is not called
 |         - cpuctx->task_ctx on CPU 0 stays set
 |
 | - exit is called on CPU 1:
 |         - the task is scheduled on CPU 1
 |         - perf_event_exit_task is called
 |         - task_ctx_sched_out unsets cpuctx->task_ctx on CPU 1
 |         - put_ctx destroys the context
 |
 | - another call of perf_rotate_context on CPU 0 will use invalid
 |   task_ctx pointer, and eventualy panic.
 |

Cure this the simplest possibly way by partially reverting the
jump_label optimization for the sched_out case.

Reported-and-tested-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Oleg Nesterov <oleg@redhat.com>
LKML-Reference: <1301520405.4859.213.camel@twins>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUBIFS: fix assertion warnings
Artem Bityutskiy [Tue, 29 Mar 2011 06:45:21 +0000 (09:45 +0300)]
UBIFS: fix assertion warnings

BugLink: http://bugs.launchpad.net/bugs/769042
commit c88ac00c5af70c2a0741da14b22cdcf8507ddd92 upstream.

This patch fixes UBIFS assertion warnings like:

UBIFS assert failed in ubifs_leb_unmap at 135 (pid 29365)
Pid: 29365, comm: integck Tainted: G          I 2.6.37-ubi-2.6+ #34
Call Trace:
 [<ffffffffa047c663>] ubifs_lpt_init+0x95e/0x9ee [ubifs]
 [<ffffffffa04623a7>] ubifs_remount_fs+0x2c7/0x762 [ubifs]
 [<ffffffff810f066e>] do_remount_sb+0xb6/0x101
 [<ffffffff81106ff4>] ? do_mount+0x191/0x78e
 [<ffffffff811070bb>] do_mount+0x258/0x78e
 [<ffffffff810da1e8>] ? alloc_pages_current+0xa2/0xc5
 [<ffffffff81107674>] sys_mount+0x83/0xbd
 [<ffffffff81009a12>] system_call_fastpath+0x16/0x1b

They happen when we re-mount from R/O mode to R/W mode. While
re-mounting, we write to the media, but we still have the c->ro_mount
flag set. The fix is very simple - just clear the flag before
starting re-mounting R/W.

These warnings are caused by the following commit:
2ef13294d29bcfb306e0d360f1b97f37b647b0c0

For -stable guys: this bug was introduced in 2.6.38, this is materieal
for 2.6.38-stable.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agovm: fix mlock() on stack guard page
Linus Torvalds [Tue, 12 Apr 2011 21:15:51 +0000 (14:15 -0700)]
vm: fix mlock() on stack guard page

BugLink: http://bugs.launchpad.net/bugs/769042
commit 95042f9eb78a8d9a17455e2ef263f2f310ecef15 upstream.

Commit 53a7706d5ed8 ("mlock: do not hold mmap_sem for extended periods
of time") changed mlock() to care about the exact number of pages that
__get_user_pages() had brought it.  Before, it would only care about
errors.

And that doesn't work, because we also handled one page specially in
__mlock_vma_pages_range(), namely the stack guard page.  So when that
case was handled, the number of pages that the function returned was off
by one.  In particular, it could be zero, and then the caller would end
up not making any progress at all.

Rather than try to fix up that off-by-one error for the mlock case
specially, this just moves the logic to handle the stack guard page
into__get_user_pages() itself, thus making all the counts come out
right automatically.

Reported-by: Robert Święcki <robert@swiecki.net>
Cc: Hugh Dickins <hughd@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agomca.c: Fix cast from integer to pointer warning
Jeff Mahoney [Thu, 24 Feb 2011 22:23:09 +0000 (17:23 -0500)]
mca.c: Fix cast from integer to pointer warning

BugLink: http://bugs.launchpad.net/bugs/769042
commit c1d036c4d1cb00b7e8473a2ad0a78f13e13a8183 upstream.

ia64_mca_cpu_init has a void *data local variable that is assigned
the value from either __get_free_pages() or mca_bootmem(). The problem
is that __get_free_pages returns an unsigned long and mca_bootmem, via
alloc_bootmem(), returns a void *. format_mca_init_stack takes the void *,
and it's also used with __pa(), but that casts it to long anyway.

This results in the following build warning:

arch/ia64/kernel/mca.c:1898: warning: assignment makes pointer from
integer without a cast

Cast the return of __get_free_pages to a void * to avoid
the warning.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agotioca: Fix assignment from incompatible pointer warnings
Jeff Mahoney [Thu, 24 Feb 2011 20:33:24 +0000 (15:33 -0500)]
tioca: Fix assignment from incompatible pointer warnings

BugLink: http://bugs.launchpad.net/bugs/769042
commit b4a6b3436531f6c5256e6d60d388c3c28ff1a0e9 upstream.

The prototype for sn_pci_provider->{dma_map,dma_map_consistent} expects
an unsigned long instead of a u64.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agox86: Fix a bogus unwind annotation in lib/semaphore_32.S
Jan Beulich [Tue, 1 Mar 2011 14:28:02 +0000 (14:28 +0000)]
x86: Fix a bogus unwind annotation in lib/semaphore_32.S

BugLink: http://bugs.launchpad.net/bugs/769042
commit e938c287ea8d977e079f07464ac69923412663ce upstream.

'simple' would have required specifying current frame address
and return address location manually, but that's obviously not
the case (and not necessary) here.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
LKML-Reference: <4D6D1082020000780003454C@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoNET: cdc-phonet, handle empty phonet header
Jiri Slaby [Sun, 13 Mar 2011 06:54:31 +0000 (06:54 +0000)]
NET: cdc-phonet, handle empty phonet header

BugLink: http://bugs.launchpad.net/bugs/769042
commit 468c3f924f043cad7a04f4f4d5224a2c9bc886c1 upstream.

Currently, for N 5800 XM I get:
cdc_phonet: probe of 1-6:1.10 failed with error -22

It's because phonet_header is empty. Extra altsetting looks like
there:
E 05 24 00 01 10 03 24 ab 05 24 06 0a 0b 04 24 fd  .$....$..$....$.
E 00                                               .

I don't see the header used anywhere so just check if the phonet
descriptor is there, not the structure itself.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Cc: David S. Miller <davem@davemloft.net>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoALSA: hda - Fix pin-config of Gigabyte mobo
Takashi Iwai [Mon, 28 Mar 2011 10:05:31 +0000 (12:05 +0200)]
ALSA: hda - Fix pin-config of Gigabyte mobo

BugLink: http://bugs.launchpad.net/bugs/769042
commit c6b358748e19ce7e230b0926ac42696bc485a562 upstream.

Use pin-fix instead of the static quirk for Gigabyte mobos 1458:a002.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=677256
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agoUBIFS: restrict world-writable debugfs files
Vasiliy Kulikov [Fri, 4 Feb 2011 12:24:19 +0000 (15:24 +0300)]
UBIFS: restrict world-writable debugfs files

BugLink: http://bugs.launchpad.net/bugs/769042
commit 8c559d30b4e59cf6994215ada1fe744928f494bf upstream.

Don't allow everybody to dump sensitive information about filesystems.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agovideo: sn9c102: world-wirtable sysfs files
Vasiliy Kulikov [Fri, 4 Feb 2011 12:23:33 +0000 (09:23 -0300)]
video: sn9c102: world-wirtable sysfs files

BugLink: http://bugs.launchpad.net/bugs/769042
commit 14ddc3188d50855ae2a419a6aced995e2834e5d4 upstream.

Don't allow everybody to change video settings.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agocifs: wrap received signature check in srv_mutex
Jeff Layton [Sat, 2 Apr 2011 11:34:30 +0000 (07:34 -0400)]
cifs: wrap received signature check in srv_mutex

BugLink: http://bugs.launchpad.net/bugs/769042
commit 157c249114508aa71daa308a426e15d81a4eed00 upstream.

While testing my patchset to fix asynchronous writes, I hit a bunch
of signature problems when testing with signing on. The problem seems
to be that signature checks on receive can be running at the same
time as a process that is sending, or even that multiple receives can
be checking signatures at the same time, clobbering the same data
structures.

While we're at it, clean up the comments over cifs_calculate_signature
and add a note that the srv_mutex should be held when calling this
function.

This patch seems to fix the problems for me, but I'm not clear on
whether it's the best approach. If it is, then this should probably
go to stable too.

Cc: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agocifs: set ra_pages in backing_dev_info
Jeff Layton [Fri, 25 Mar 2011 20:25:57 +0000 (16:25 -0400)]
cifs: set ra_pages in backing_dev_info

BugLink: http://bugs.launchpad.net/bugs/769042
commit 2b6c26a0a62cc0bab0ad487533d5581d7c293fef upstream.

Commit 522440ed made cifs set backing_dev_info on the mapping attached
to new inodes. This change caused a fairly significant read performance
regression, as cifs started doing page-sized reads exclusively.

By virtue of the fact that they're allocated as part of cifs_sb_info by
kzalloc, the ra_pages on cifs BDIs get set to 0, which prevents any
readahead. This forces the normal read codepaths to use readpage instead
of readpages causing a four-fold increase in the number of read calls
with the default rsize.

Fix it by setting ra_pages in the BDI to the same value as that in the
default_backing_dev_info.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=31662

Reported-and-Tested-by: Till <till2.schaefer@uni-dortmund.de>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agocifs: check for private_data before trying to put it
Jeff Layton [Tue, 5 Apr 2011 23:23:47 +0000 (16:23 -0700)]
cifs: check for private_data before trying to put it

BugLink: http://bugs.launchpad.net/bugs/769042
commit 7797069305d13252fd66cf722aa8f2cbeb3c95cd upstream.

cifs_close doesn't check that the filp->private_data is non-NULL before
trying to put it. That can cause an oops in certain error conditions
that can occur on open or lookup before the private_data is set.

Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
6 years agocifs: always do is_path_accessible check in cifs_mount
Jeff Layton [Mon, 14 Mar 2011 17:48:08 +0000 (13:48 -0400)]
cifs: always do is_path_accessible check in cifs_mount

BugLink: http://bugs.launchpad.net/bugs/769042
commit 70945643722ffeac779d2529a348f99567fa5c33 upstream.

Currently, we skip doing the is_path_accessible check in cifs_mount if
there is no prefixpath. I have a report of at least one server however
that allows a TREE_CONNECT to a share that has a DFS referral at its
root. The reporter in this case was using a UNC that had no prefixpath,
so the is_path_accessible check was not triggered and the box later hit
a BUG() because we were chasing a DFS referral on the root dentry for
the mount.

This patch fixes this by removing the check for a zero-length
prefixpath.  That should make the is_path_accessible check be done in
this situation and should allow the client to chase the DFS referral at
mount time instead.

Reported-and-Tested-by: Yogesh Sharma <ysharma@cymer.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>