Mark Brown [Fri, 8 Apr 2011 07:32:16 +0000 (16:32 +0900)]
ASoC: Fix output PGA enabling in wm_hubs CODECs
BugLink: http://bugs.launchpad.net/bugs/775809
commit
39cca168bdfaef9d0c496ec27f292445d6184946 upstream.
The output PGA was not being powered up in headphone and speaker paths,
removing the ability to offer volume control and mute with the output
PGA.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Uwe Kleine-König [Mon, 11 Apr 2011 08:59:09 +0000 (10:59 +0200)]
serial/imx: read cts state only after acking cts change irq
BugLink: http://bugs.launchpad.net/bugs/775809
commit
5680e94148a86e8c31fdc5cb0ea0d5c6810c05b0 upstream.
If cts changes between reading the level at the cts input (USR1_RTSS)
and acking the irq (USR1_RTSD) the last edge doesn't generate an irq and
uart_handle_cts_change is called with a outdated value for cts.
The race was introduced by commit
ceca629 ([ARM] 2971/1: i.MX uart handle rts irq)
Reported-by: Arwed Springer <Arwed.Springer@de.trumpf.com>
Tested-by: Arwed Springer <Arwed.Springer@de.trumpf.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mikhail Kshevetskiy [Sun, 27 Mar 2011 00:05:00 +0000 (04:05 +0400)]
tty/n_gsm: fix bug in CRC calculation for gsm1 mode
BugLink: http://bugs.launchpad.net/bugs/775809
commit
9db4e4381a8e881ff65a5d3400bfa471f84217e7 upstream.
Problem description:
gsm_queue() calculate a CRC for arrived frames. As a last step of
CRC calculation it call
gsm->fcs = gsm_fcs_add(gsm->fcs, gsm->received_fcs);
This work perfectly for the case of GSM0 mode as gsm->received_fcs
contain the last piece of data required to generate final CRC.
gsm->received_fcs is not used for GSM1 mode. Thus we put an
additional byte to CRC calculation. As result we get a wrong CRC
and reject incoming frame.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mathew McKernan [Tue, 12 Apr 2011 05:51:37 +0000 (06:51 +0100)]
drm/i915/tv: Remember the detected TV type
BugLink: http://bugs.launchpad.net/bugs/775809
commit
d5627663f2088fa4be447fdcfd52bcb233448d85 upstream.
During detect() we would probe the connection bits to determine if
there was a TV attached, and what video input type (Component, S-Video,
Composite, etc) to use. However, we promptly discarded this vital bit of
information and never propagated it to where it was used to determine
the correct modes and setup the control registers. Fix it!
This fixes a regression from
7b334fcb45b757ffb093696ca3de1b0c8b4a33f1.
Reported-and-tested-by: Mathew McKernan <matmckernan@rauland.com.au>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35977
Signed-off-by: Mathew McKernan <matmckernan@rauland.com.au>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alex Deucher [Thu, 14 Apr 2011 15:19:50 +0000 (11:19 -0400)]
drm/radeon/kms: fix bad shift in atom iio table parser
BugLink: http://bugs.launchpad.net/bugs/775809
commit
8e461123f28e6b17456225e70eb834b3b30d28bb upstream.
Noticed by Patrick Lowry.
Signed-off-by: Alex Deucher <alexdeucher@gmail.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>
Marcin Slusarz [Tue, 19 Apr 2011 21:50:48 +0000 (23:50 +0200)]
drm/nouveau: fix notifier memory corruption bug
BugLink: http://bugs.launchpad.net/bugs/775809
commit
a18d89ca026140eb8ac4459bf70a01c571dd9a32 upstream.
nouveau_bo_wr32 expects offset to be in words, but we pass value in bytes,
so after commit
73412c3854c877e5f37ad944ee8977addde4d35a ("drm/nouveau: allocate
kernel's notifier object at end of block") we started to overwrite some memory
after notifier buffer object (previously m2mf_ntfy was always 0, so it didn't
matter it was a value in bytes).
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Reported-by: Nigel Cunningham <lkml@nigelcunningham.com.au>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alex Deucher [Tue, 19 Apr 2011 19:24:59 +0000 (15:24 -0400)]
drm/radeon/kms: pll tweaks for r7xx
BugLink: http://bugs.launchpad.net/bugs/775809
commit
5785e53ffa73f77fb19e378c899027afc07272bc upstream.
Prefer min m to max p only on pre-r7xx asics.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=36197
Signed-off-by: Alex Deucher <alexdeucher@gmail.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>
Alex Williamson [Fri, 4 Mar 2011 21:52:30 +0000 (14:52 -0700)]
intel-iommu: Fix get_domain_for_dev() error path
BugLink: http://bugs.launchpad.net/bugs/775809
commit
2fe9723df8e45fd247782adea244a5e653c30bf4 upstream.
If we run out of domain_ids and fail iommu_attach_domain(), we
fall into domain_exit() without having setup enough of the
domain structure for this to do anything useful. In fact, it
typically runs off into the weeds walking the bogus domain->devices
list. Just free the domain.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Donald Dutile <ddutile@redhat.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alex Williamson [Fri, 4 Mar 2011 21:52:16 +0000 (14:52 -0700)]
intel-iommu: Unlink domain from iommu
BugLink: http://bugs.launchpad.net/bugs/775809
commit
a97590e56d0d58e1dd262353f7cbd84e81d8e600 upstream.
When we remove a device, we unlink the iommu from the domain, but
we never do the reverse unlinking of the domain from the iommu.
This means that we never clear iommu->domain_ids, eventually leading
to resource exhaustion if we repeatedly bind and unbind a device
to a driver. Also free empty domains to avoid a resource leak.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Donald Dutile <ddutile@redhat.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jan Kiszka [Tue, 2 Nov 2010 07:05:51 +0000 (08:05 +0100)]
intel-iommu: Fix use after release during device attach
BugLink: http://bugs.launchpad.net/bugs/775809
commit
7a6610139a1e1d9297dd1c5d178022eac36839cb upstream.
Obtain the new pgd pointer before releasing the page containing this
value.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Sheng Yang <sheng@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Joerg Roedel [Mon, 18 Apr 2011 13:45:46 +0000 (15:45 +0200)]
x86, gart: Make sure GART does not map physmem above 1TB
BugLink: http://bugs.launchpad.net/bugs/775809
commit
665d3e2af83c8fbd149534db8f57d82fa6fa6753 upstream.
The GART can only map physical memory below 1TB. Make sure
the gart driver in the kernel does not try to map memory
above 1TB.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Link: http://lkml.kernel.org/r/
1303134346-5805-5-git-send-email-joerg.roedel@amd.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Joerg Roedel [Mon, 18 Apr 2011 13:45:45 +0000 (15:45 +0200)]
x86, gart: Set DISTLBWALKPRB bit always
BugLink: http://bugs.launchpad.net/bugs/775809
commit
c34151a742d84ae65db2088ea30495063f697fbe upstream.
The DISTLBWALKPRB bit must be set for the GART because the
gatt table is mapped UC. But the current code does not set
the bit at boot when the BIOS setup the aperture correctly.
Fix that by setting this bit when enabling the GART instead
of the other places.
Cc: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Link: http://lkml.kernel.org/r/
1303134346-5805-4-git-send-email-joerg.roedel@amd.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Amit Shah [Wed, 16 Mar 2011 13:42:10 +0000 (19:12 +0530)]
virtio: Decrement avail idx on buffer detach
BugLink: http://bugs.launchpad.net/bugs/775809
commit
b3258ff1d6086bd2b9eeb556844a868ad7d49bc8 upstream.
When detaching a buffer from a vq, the avail.idx value should be
decremented as well.
This was noticed by hot-unplugging a virtio console port and then
plugging in a new one on the same number (re-using the vqs which were
just 'disowned'). qemu reported
'Guest moved used index from 0 to 256'
when any IO was attempted on the new port.
Reported-by: juzhang <juzhang@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
OGAWA Hirofumi [Mon, 18 Apr 2011 15:48:55 +0000 (11:48 -0400)]
nfsd4: Fix filp leak
BugLink: http://bugs.launchpad.net/bugs/775809
commit
a96e5b90804be8b540d30f4a1453fc87f95b3149 upstream.
23fcf2ec93fb8573a653408316af599939ff9a8e (nfsd4: fix oops on lock failure)
The above patch breaks free path for stp->st_file. If stp was inserted
into sop->so_stateids, we have to free stp->st_file refcount. Because
stp->st_file refcount itself is taken whether or not any refcounts are
taken on the stp->st_file->fi_fds[].
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
J. Bruce Fields [Fri, 15 Apr 2011 22:08:26 +0000 (18:08 -0400)]
nfsd4: fix struct file leak on delegation
BugLink: http://bugs.launchpad.net/bugs/775809
commit
4ee63624fd927376b97ead3a8d00728d437bc8e8 upstream.
Introduced by
acfdf5c383b38f7f4dddae41b97c97f1ae058f49.
Reported-by: Gerhard Heift <ml-nfs-linux-
20110412-ef47@gheift.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Amit Kumar Salecha [Tue, 12 Apr 2011 17:05:55 +0000 (17:05 +0000)]
qlcnic: limit skb frags for non tso packet
BugLink: http://bugs.launchpad.net/bugs/775809
commit
91a403caf0f26c71ce4407fd235b2d6fb225fba9 upstream.
Machines are getting deadlock in four node cluster environment.
All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null)
200 GB storage on a GFS2 filesystem.
This result in memory fragmentation and driver receives 18 frags for
1448 byte packets.
For non tso packet, fw drops the tx request, if it has >14 frags.
Fixing it by pulling extra frags.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jason Conti [Thu, 7 Apr 2011 19:09:57 +0000 (21:09 +0200)]
p54: Initialize extra_len in p54_tx_80211
BugLink: http://bugs.launchpad.net/bugs/775809
commit
a6756da9eace8b4af73e9dea43f1fc2889224c94 upstream.
This patch fixes a very serious off-by-one bug in
the driver, which could leave the device in an
unresponsive state.
The problem was that the extra_len variable [used to
reserve extra scratch buffer space for the firmware]
was left uninitialized. Because p54_assign_address
later needs the value to reserve additional space,
the resulting frame could be to big for the small
device's memory window and everything would
immediately come to a grinding halt.
Reference: https://bugs.launchpad.net/bugs/722185
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Jason Conti <jason.conti@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Liu Yuan [Tue, 19 Apr 2011 11:47:58 +0000 (13:47 +0200)]
block, blk-sysfs: Fix an err return path in blk_register_queue()
BugLink: http://bugs.launchpad.net/bugs/775809
commit
ed5302d3c25006a9edc7a7fbea97a30483f89ef7 upstream.
We do not call blk_trace_remove_sysfs() in err return path
if kobject_add() fails. This path fixes it.
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Christian Lamparter [Wed, 6 Apr 2011 18:40:31 +0000 (20:40 +0200)]
ath: add missing regdomain pair 0x5c mapping
BugLink: http://bugs.launchpad.net/bugs/775809
commit
bd39a274fb7b43374c797bafdb7f506598f36f77 upstream.
Joe Culler reported a problem with his AR9170 device:
> ath: EEPROM regdomain: 0x5c
> ath: EEPROM indicates we should expect a direct regpair map
> ath: invalid regulatory domain/country code 0x5c
> ath: Invalid EEPROM contents
It turned out that the regdomain 'APL7_FCCA' was not mapped yet.
According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to
FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch
should be correct.
Reported-by: Joe Culler <joe.culler@gmail.com>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
amit salecha [Mon, 11 Apr 2011 02:10:22 +0000 (02:10 +0000)]
netxen: limit skb frags for non tso packet
BugLink: http://bugs.launchpad.net/bugs/775809
commit
c968bdf6912cad6d0fc63d7037cc1c870604a808 upstream.
Machines are getting deadlock in four node cluster environment.
All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null)
200 GB storage on a GFS2 filesystem.
This result in memory fragmentation and driver receives 18 frags for
1448 byte packets.
For non tso packet, fw drops the tx request, if it has >14 frags.
Fixing it by pulling extra frags.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Felix Fietkau [Fri, 8 Apr 2011 18:13:18 +0000 (20:13 +0200)]
ath9k_hw: fix stopping rx DMA during resets
BugLink: http://bugs.launchpad.net/bugs/775809
commit
5882da02e9d9089b7e8c739f3e774aaeeff8b7ba upstream.
During PHY errors, the MAC can sometimes fail to enter an idle state on older
hardware (before AR9380) after an rx stop has been requested.
This typically shows up in the kernel log with messages like these:
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
------------[ cut here ]------------
WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
Call Trace:
[<
8023f0e8>] dump_stack+0x8/0x34
[<
80075050>] warn_slowpath_common+0x78/0xa4
[<
80075094>] warn_slowpath_null+0x18/0x24
[<
80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
[<
80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
[<
80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]
When this happens, the state that the MAC enters is easy to identify and
does not result in bogus DMA traffic, however to ensure a working state
after a channel change, the hardware should still be reset.
This patch adds detection for this specific MAC state, after which the above
warnings completely disappear in my tests.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stefan Bader [Fri, 29 Apr 2011 09:27:14 +0000 (11:27 +0200)]
UBUNTU: Include nls_iso8859-1 for virtual images
BugLink: http://bugs.launchpad.net/bugs/732046
It turns out that including cp437 alone is not sufficient to mount
a vfat file system. With this additional module, things were reported
to be working.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: John Johansen <john.johansen@canonical.com>
Acked-by: Herton Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Steve Conklin [Thu, 2 Jun 2011 19:19:37 +0000 (14:19 -0500)]
UBUNTU: Bump ABI
Ignore: yes
Steve Conklin [Thu, 2 Jun 2011 19:14:47 +0000 (14:14 -0500)]
UBUNTU: Start new release
Ignore: yes
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
projects / linux-flexiantxendom0-natty.git / log