Herton Ronaldo Krzesinski [Tue, 27 Sep 2011 19:22:02 +0000 (16:22 -0300)]
UBUNTU: Ubuntu-2.6.38-12.51
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Tue, 27 Sep 2011 16:55:28 +0000 (13:55 -0300)]
Revert "drm/i915: disable PCH ports if needed when disabling a CRTC"
This reverts commit
bbeaf8811ba070fd186dfcabc957044c3a1149ac.
It was found that this change is bringing regressions, as can be seen on
Ubuntu bugs 814325, 838181. While a solution isn't found, the change is
being reverted.
BugLink: http://bugs.launchpad.net/bugs/814325
BugLink: http://bugs.launchpad.net/bugs/838181
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Lukas Czerner [Mon, 26 Sep 2011 12:10:14 +0000 (13:10 +0100)]
ext4: Fix max file size and logical block counting of extent format file, CVE-2011-2695
Kazuya Mio reported that he was able to hit BUG_ON(next == lblock)
in ext4_ext_put_gap_in_cache() while creating a sparse file in extent
format and fill the tail of file up to its end. We will hit the BUG_ON
when we write the last block (2^32-1) into the sparse file.
The root cause of the problem lies in the fact that we specifically set
s_maxbytes so that block at s_maxbytes fit into on-disk extent format,
which is 32 bit long. However, we are not storing start and end block
number, but rather start block number and length in blocks. It means
that in order to cover extent from 0 to EXT_MAX_BLOCK we need
EXT_MAX_BLOCK+1 to fit into len (because we counting block 0 as well) -
and it does not.
The only way to fix it without changing the meaning of the struct
ext4_extent members is, as Kazuya Mio suggested, to lower s_maxbytes
by one fs block so we can cover the whole extent we can get by the
on-disk extent format.
Also in many places EXT_MAX_BLOCK is used as length instead of maximum
logical block number as the name suggests, it is all a bit messy. So
this commit renames it to EXT_MAX_BLOCKS and change its usage in some
places to actually be maximum number of blocks in the extent.
The bug which this commit fixes can be reproduced as follows:
dd if=/dev/zero of=/mnt/mp1/file bs=<blocksize> count=1 seek=$((2**32-2))
sync
dd if=/dev/zero of=/mnt/mp1/file bs=<blocksize> count=1 seek=$((2**32-1))
Reported-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
(backported from commit
f17722f917b2f21497deb6edc62fb1683daa08e6)
CVE-2011-2695
BugLink: http://bugs.launchpad.net/bugs/819574
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jesse Sung [Mon, 19 Sep 2011 01:25:14 +0000 (09:25 +0800)]
UBUNTU: SAUCE: Unregister input device only if it is registered
BugLink: https://bugs.launchpad.net/bugs/839238
dev2 is not registered in alps_model_quirk_enabled mode, do not
unregister while disconnecting.
Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Gertjan van Wingerde [Fri, 23 Sep 2011 16:20:00 +0000 (09:20 -0700)]
rt2x00: Serialize TX operations on a queue.
BugLink: https://bugs.launchpad.net/bugs/855239
The rt2x00 driver gets frequent occurrences of the following error message
when operating under load:
phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the
non-full queue 2.
This is caused by simultaneous attempts from mac80211 to send a frame via
rt2x00, which are not properly serialized inside rt2x00queue_write_tx_frame,
causing the second frame to fail sending with the above mentioned error
message.
Fix this by introducing a per-queue spinlock to serialize the TX operations
on that queue.
Reported-by: Andreas Hartmann <andihartmann@01019freenet.de>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(backported from upstream commit
77a861c405da75d81e9e6e32c50eb7f9777777e8)
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stefan Bader [Thu, 22 Sep 2011 16:28:24 +0000 (18:28 +0200)]
UBUNTU: [Config] Include all filesystem modules for virtual
We got another module inclusion request for the virtual package: quota.
Filesystems are not hardware dependant and someone will come and want
any missing one sooner or later. So instead of just adding quota, get over
with it and just include them all. This is what we finally did for
Lucid, too.
BugLink: http://bugs.launchpad.net/bugs/761809
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alex Bligh [Wed, 14 Sep 2011 20:43:36 +0000 (13:43 -0700)]
UBUNTU: SAUCE: net/netfilter/nf_conntrack_netlink.c: fix Oops on container destroy
BugLink: http://bugs.launchpad.net/bugs/843892
Problem:
A repeatable Oops can be caused if a container with networking
unshared is destroyed when it has nf_conntrack entries yet to expire.
A copy of the oops follows below. A perl program generating the oops
repeatably is attached inline below.
Analysis:
The oops is called from cleanup_net when the namespace is
destroyed. conntrack iterates through outstanding events and calls
death_by_timeout on each of them, which in turn produces a call to
ctnetlink_conntrack_event. This calls nf_netlink_has_listeners, which
oopses because net->nfnl is NULL.
The perl program generates the container through fork() then
clone(NS_NEWNET). I does not explicitly set up netlink
explicitly set up netlink, but I presume it was set up else net->nfnl
would have been NULL earlier (i.e. when an earlier connection
timed out). This would thus suggest that net->nfnl is made NULL
during the destruction of the container, which I think is done by
nfnetlink_net_exit_batch.
I can see that the various subsystems are deinitialised in the opposite
order to which the relevant register_pernet_subsys calls are called,
and both nf_conntrack and nfnetlink_net_ops register their relevant
subsystems. If nfnetlink_net_ops registered later than nfconntrack,
then its exit routine would have been called first, which would cause
the oops described. I am not sure there is anything to prevent this
happening in a container environment.
Whilst there's perhaps a more complex problem revolving around ordering
of subsystem deinit, it seems to me that missing a netlink event on a
container that is dying is not a disaster. An early check for net->nfnl
being non-NULL in ctnetlink_conntrack_event appears to fix this. There
may remain a potential race condition if it becomes NULL immediately
after being checked (I am not sure any lock is held at this point or
how synchronisation for subsystem deinitialization works).
Patch:
The patch attached should apply on everything from 2.6.26 (if not before)
onwards; it appears to be a problem on all kernels. This was taken against
Ubuntu-3.0.0-11.17 which is very close to 3.0.4. I have torture-tested it
with the above perl script for 15 minutes or so; the perl script hung the
machine within 20 seconds without this patch.
Applicability:
If this is the right solution, it should be applied to all stable kernels
as well as head. Apart from the minor overhead of checking one variable
against NULL, it can never 'do the wrong thing', because if net->nfnl
is NULL, an oops will inevitably result. Therefore, checking is a reasonable
thing to do unless it can be proven than net->nfnl will never be NULL.
Check net->nfnl for NULL in ctnetlink_conntrack_event to avoid Oops on
container destroy
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Cc: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(applied from -mm http://marc.info/?l=linux-mm-commits&m=
131603308900694&w=2)
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Leann Ogasawara [Wed, 21 Sep 2011 14:30:59 +0000 (07:30 -0700)]
UBUNTU: SAUCE: x86: reboot: Make Dell Latitude E6520 use reboot=pci
BugLink: http://bugs.launchpad.net/bugs/833705
The Dell Latitude E6520 doesn't reboot unless reboot=pci is set.
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Leann Ogasawara [Wed, 21 Sep 2011 14:30:58 +0000 (07:30 -0700)]
UBUNTU: SAUCE: x86: reboot: Make Dell Latitude E6220 use reboot=pci
BugLink: http://bugs.launchpad.net/bugs/838402
The Dell Latitude E6220 doesn't reboot unless reboot=pci is set.
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Len Brown [Fri, 15 Jul 2011 21:37:15 +0000 (17:37 -0400)]
x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS message
BugLink: http://bugs.launchpad.net/bugs/760131
Fix the printk_once() so that it actually prints (didn't print before
due to a stray comma.)
[ hpa: changed to an incremental patch and adjusted the description
accordingly. ]
Signed-off-by: Len Brown <len.brown@intel.com>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.
1107151732480.18606@x980
Cc: <table@kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
(cherry picked from commit
17edf2d79f1ea6dfdb4c444801d928953b9f98d6)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Len Brown [Thu, 14 Jul 2011 04:53:24 +0000 (00:53 -0400)]
x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS
BugLink: http://bugs.launchpad.net/bugs/760131
Since 2.6.36 (
23016bf0d25), Linux prints the existence of "epb" in /proc/cpuinfo,
Since 2.6.38 (
d5532ee7b40), the x86_energy_perf_policy(8) utility has
been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS.
However, the typical BIOS fails to initialize the MSR, presumably
because this is handled by high-volume shrink-wrap operating systems...
Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8).
As a result, WSM-EP, SNB, and later hardware from Intel will run in its
default hardware power-on state (performance), which assumes that users
care for performance at all costs and not for energy efficiency.
While that is fine for performance benchmarks, the hardware's intended default
operating point is "normal" mode...
Initialize the MSR to the "normal" by default during kernel boot.
x86_energy_perf_policy(8) is available to change the default after boot,
should the user have a different preference.
Signed-off-by: Len Brown <len.brown@intel.com>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.
1107140051020.18606@x980
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@kernel.org>
(cherry picked from commit
abe48b108247e9b90b4c6739662a2e5c765ed114)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
David S. Miller [Tue, 20 Sep 2011 10:36:39 +0000 (11:36 +0100)]
net: Compute protocol sequence numbers and fragment IDs using MD5, CVE-2011-3188
Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.
MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)
Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation. So the periodic
regeneration and 8-bit counter have been removed. We compute and
use a full 32-bit sequence number.
For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.
Reported-by: Dan Kaminsky <dan@doxpara.com>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
(backported from commit
6e5714eaf77d79ae1c8b47e3e040ff5411b717ec)
CVE-2011-3188
BugLink: http://bugs.launchpad.net/bugs/834129
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
David S. Miller [Tue, 20 Sep 2011 10:36:38 +0000 (11:36 +0100)]
crypto: Move md5_transform to lib/md5.c, CVE-2011-3188
We are going to use this for TCP/IP sequence number and fragment ID
generation.
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit
bc0b96b54a21246e377122d54569eef71cec535f)
CVE-2011-3188
BugLink: http://bugs.launchpad.net/bugs/834129
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dan Rosenberg [Mon, 19 Sep 2011 10:43:14 +0000 (11:43 +0100)]
Bluetooth: Prevent buffer overflow in l2cap config request, CVE-2011-2497
A remote user can provide a small value for the command size field in
the command header of an l2cap configuration request, resulting in an
integer underflow when subtracting the size of the configuration request
header. This results in copying a very large amount of data via
memcpy() and destroying the kernel heap. Check for underflow.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
(backported from commit
7ac28817536797fd40e9646452183606f9e17f71)
CVE-2011-2497
BugLink: http://bugs.launchpad.net/bugs/838423
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mauro Carvalho Chehab [Sun, 17 Jul 2011 03:24:37 +0000 (00:24 -0300)]
si4713-i2c: avoid potential buffer overflow on si4713, CVE-2011-2700
BugLink: http://bugs.launchpad.net/bugs/844370
CVE-2011-2700
While compiling it with Fedora 15, I noticed this issue:
inlined from ‘si4713_write_econtrol_string’ at drivers/media/radio/si4713-i2c.c:1065:24:
arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correct
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
Reviewed-by: Eugene Teo <eugeneteo@kernel.sg>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
dc6b845044ccb7e9e6f3b7e71bd179b3cf0223b6)
Signed-off-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Wed, 14 Sep 2011 16:14:17 +0000 (10:14 -0600)]
UBUNTU: [Config] Fix binary-% build target
Simplify the checks-% target such that ABI and modules checks are
built in parallel whilst both depend on the build stamp.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Eric Dumazet [Wed, 14 Sep 2011 15:51:15 +0000 (16:51 +0100)]
inet_diag: fix inet_diag_bc_audit(), CVE-2011-2213
A malicious user or buggy application can inject code and trigger an
infinite loop in inet_diag_bc_audit()
Also make sure each instruction is aligned on 4 bytes boundary, to avoid
unaligned accesses.
Reported-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit
eeb1497277d6b1a0a34ed36b97e18f2bd7d6de0d)
CVE-2011-2213
BugLink: http://bugs.launchpad.net/bugs/838421
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Herbert Xu [Tue, 13 Sep 2011 16:48:44 +0000 (17:48 +0100)]
gro: Only reset frag0 when skb can be pulled, CVE-2011-2723
Currently skb_gro_header_slow unconditionally resets frag0 and
frag0_len. However, when we can't pull on the skb this leaves
the GRO fields in an inconsistent state.
This patch fixes this by only resetting those fields after the
pskb_may_pull test.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit
17dd759c67f21e34f2156abcf415e1f60605a188)
CVE-2011-2723
BugLink: http://bugs.launchpad.net/bugs/844371
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Timo Warns [Tue, 13 Sep 2011 15:21:26 +0000 (16:21 +0100)]
befs: Validate length of long symbolic links, CVE-2011-2928
Signed-off-by: Timo Warns <warns@pre-sense.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
338d0f0a6fbc82407864606f5b64b75aeb3c70f2)
CVE-2011-2928
BugLink: http://bugs.launchpad.net/bugs/834124
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jeff Layton [Tue, 13 Sep 2011 13:24:02 +0000 (14:24 +0100)]
cifs: fix possible memory corruption in CIFSFindNext, CVE-2011-3191
The name_len variable in CIFSFindNext is a signed int that gets set to
the resume_name_len in the cifs_search_info. The resume_name_len however
is unsigned and for some infolevels is populated directly from a 32 bit
value sent by the server.
If the server sends a very large value for this, then that value could
look negative when converted to a signed int. That would make that
value pass the PATH_MAX check later in CIFSFindNext. The name_len would
then be used as a length value for a memcpy. It would then be treated
as unsigned again, and the memcpy scribbles over a ton of memory.
Fix this by making the name_len an unsigned value in CIFSFindNext.
Cc: <stable@kernel.org>
Reported-by: Darren Lavender <dcl@hppine99.gbr.hp.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
(cherry-picked from commit
c32dfffaf59f73bbcf4472141b851a4dc5db2bf0 cifs-2.6.git)
CVE-2011-3191
BugLink: http://bugs.launchpad.net/bugs/834135
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dave Airlie [Thu, 21 Apr 2011 21:18:32 +0000 (22:18 +0100)]
drm/i915: restore only the mode of this driver on lastclose (v2)
BugLink: https://bugs.launchpad.net/bugs/848687
i915 calls the panic handler function on last close to reset the modes,
however this is a really bad idea for multi-gpu machines, esp shareable
gpus machines. So add a new entry point for the driver to just restore
its own fbcon mode.
v2: move code into fb helper, fix panic code to block mode change on
powered off GPUs.
[airlied: this hits drm core and I wrote it and it was reviewed on intel-gfx
so really I signed it off twice ;-).]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
e8e7a2b8ccfdae0d4cb6bd25824bbedcd42da316)
Signed-off-by: Evan Broder <ebroder@mokafive.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Ming Lei [Tue, 13 Sep 2011 02:01:24 +0000 (10:01 +0800)]
UBUNTU: SAUCE: fireware: add NO_MSI quirks for o2micro controller
Disable MSI for the O2 Micro, Inc. firewire controller.
BugLink: http://bugs.launchpad.net/bugs/801719
Upstream: http://marc.info/?t=
131475896500002&r=1&w=2
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Wed, 24 Aug 2011 15:44:01 +0000 (09:44 -0600)]
UBUNTU: [Config] Restore prepare-% target
It turns out that some tossers like to shortcut the process during development.
A common sequence for a quick compile test is to preapre the tree, copy the
.config, then perform an in-tree compile. For example,
fakeroot debian/rules clean prepare-generic
cp debian/build/build-generic/.config .
make oldconfig scripts prepare
make M=`pwd`/fs/ext4
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Tue, 23 Aug 2011 15:56:23 +0000 (09:56 -0600)]
UBUNTU: [Config] Use build stamp directly
If build-% is not declared .PHONY, then its always executed.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Mon, 22 Aug 2011 20:11:52 +0000 (14:11 -0600)]
UBUNTU: [Config] Serialize binary indep targets
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Mon, 22 Aug 2011 18:03:43 +0000 (12:03 -0600)]
UBUNTU: [Config] Removed stamp-flavours target
It appears to be superfluous.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Mon, 22 Aug 2011 18:00:00 +0000 (12:00 -0600)]
UBUNTU: [Config] Fix binary-perarch dependencies
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Mon, 22 Aug 2011 17:41:40 +0000 (11:41 -0600)]
UBUNTU: [Config] Improve install-arch-headers speed
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Mon, 22 Aug 2011 17:18:13 +0000 (11:18 -0600)]
UBUNTU: [Config] Set concurrency for kmake invocations
As it turns out, 'kmake modules_install' understands
concurrency, and is quite a bit faster when told to
parallelize the copy operation.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Mon, 22 Aug 2011 16:48:27 +0000 (10:48 -0600)]
UBUNTU: [Config] Build kernel image in parallel with modules
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Mon, 22 Aug 2011 16:43:08 +0000 (10:43 -0600)]
UBUNTU: [Config] Linearize and simplify tree preparation rules
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Mon, 22 Aug 2011 16:00:45 +0000 (10:00 -0600)]
UBUNTU: [Config] Linearize module/abi checks
The module and ABI checks are not independent, so make sure
the modules check is dependent on the ABI check having been
performed. Also drop some superfluous shortcuts along the way.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Tue, 23 Aug 2011 03:16:19 +0000 (21:16 -0600)]
UBUNTU: [Config] kernel preparation cannot be parallelized
Regardless of the concurrency setting, kernel preparation targets
cannot be made in parallel.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Herton Ronaldo Krzesinski [Tue, 27 Sep 2011 19:10:06 +0000 (16:10 -0300)]
UBUNTU: Bump ABI
Ignore: yes
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Tue, 27 Sep 2011 19:08:33 +0000 (16:08 -0300)]
UBUNTU: Start new release
Ignore: yes
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Mon, 12 Sep 2011 20:25:18 +0000 (17:25 -0300)]
UBUNTU: Ubuntu-2.6.38-11.50
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Mon, 12 Sep 2011 20:15:11 +0000 (17:15 -0300)]
Revert "ath9k: use split rx buffers to get rid of order-1 skb allocations"
This fix was not verified in the -proposed kernel to have resolved the
problem, so the patch is being reverted.
This reverts commit
a813c1f0f54b99adf1e7dc391c575c6dae38fd7c.
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Mon, 12 Sep 2011 20:06:31 +0000 (17:06 -0300)]
Revert "KVM: fix kvmclock regression due to missing clock update"
This fix was not verified in the -proposed kernel to have resolved the
problem, so the patch is being reverted.
This reverts commit
b2ad3e0e1b1eafeeff98bedda724a5962bb7ffaa.
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Mon, 12 Sep 2011 20:02:37 +0000 (17:02 -0300)]
Revert "eCryptfs: Handle failed metadata read in lookup"
This fix was not verified in the -proposed kernel to have resolved the
problem, so the patch is being reverted.
This reverts commit
8953034e6cb4b4f7cca0c1bf617ee37b5aa1ed77.
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Mon, 12 Sep 2011 20:00:38 +0000 (17:00 -0300)]
UBUNTU: Start new release
Ignore: yes
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Mon, 29 Aug 2011 19:25:55 +0000 (16:25 -0300)]
UBUNTU: Ubuntu-2.6.38-11.49
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Peter Zijlstra [Fri, 26 Aug 2011 08:59:37 +0000 (09:59 +0100)]
perf: Fix software event overflow, CVE-2011-2918
BugLink: http://bugs.launchpad.net/bugs/834121
The below patch is for -stable only, upstream has a much larger patch
that contains the below hunk in commit
a8b0ca17b80e92faab46ee7179ba9e99ccb61233
Vince found that under certain circumstances software event overflows
go wrong and deadlock. Avoid trying to delete a timer from the timer
callback.
Reported-by: Vince Weaver <vweaver1@eecs.utk.edu>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
CVE-2011-2918
backported from commit
462fee3af72df0de7b60b96c525ffe8baf4db0f0 stable-3.0.y
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Leann Ogasawara [Tue, 23 Aug 2011 18:26:17 +0000 (11:26 -0700)]
ath9k: use split rx buffers to get rid of order-1 skb allocations
BugLink: http://bugs.launchpad.net/bugs/728835
With this change, less CPU time is spent trying to look for consecutive
pages for rx skbs. This also reduces the socket memory required for IP/UDP
reassembly.
Only two buffers per frame are supported. Frames spanning more buffers
will be dropped, but the buffer size is enough to handle the required
AMSDU size.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(cherry picked from commit
0d95521ea74735826cb2e28bebf6a07392c75bfa)
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Andy Whitcroft [Tue, 23 Aug 2011 14:58:32 +0000 (15:58 +0100)]
ipv6: make fragment identifications less predictable, CVE-2011-2699
[ Backport of upstream commit
87c48fa3b4630905f98268dde838ee43626a060c ]
Fernando Gont reported current IPv6 fragment identification generation
was not secure, because using a very predictable system-wide generator,
allowing various attacks.
IPv4 uses inetpeer cache to address this problem and to get good
performance. We'll use this mechanism when IPv6 inetpeer is stable
enough in linux-3.1
For the time being, we use jhash on destination address to provide less
predictable identifications. Also remove a spinlock and use cmpxchg() to
get better SMP performance.
Reported-by: Fernando Gont <fernando@gont.com.ar>
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>
CVE-2011-2699
BugLink: http://bugs.launchpad.net/bugs/827685
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stefan Bader [Wed, 17 Aug 2011 16:47:29 +0000 (18:47 +0200)]
UBUNTU: [Config] Force perf to use libiberty for demangling
Because libbfd is GPLv3 only and perf is GPLv2 only. Also this avoids
statically linking against libbfd to allow multiple versions of perf
being installed in parallel.
See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606050
BugLink: http://bugs.launchpad.net/bugs/783660
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Linus Torvalds [Mon, 28 Mar 2011 02:09:29 +0000 (19:09 -0700)]
proc: fix oops on invalid /proc/<pid>/maps access, CVE-2011-1020
When m_start returns an error, the seq_file logic will still call m_stop
with that error entry, so we'd better make sure that we check it before
using it as a vma.
Introduced by commit
ec6fd8a4355c ("report errors in /proc/*/*map*
sanely"), which replaced NULL with various ERR_PTR() cases.
(On ia64, you happen to get a unaligned fault instead of a page fault,
since the address used is generally some random error code like -EPERM)
Reported-by: Anca Emanuel <anca.emanuel@gmail.com>
Reported-by: Tony Luck <tony.luck@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Américo Wang <xiyou.wangcong@gmail.com>
Cc: Stephen Wilson <wilsons@start.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
76597cd31470fa130784c78fadb4dab2e624a723)
CVE-2011-1020
BugLink: http://bugs.launchpad.net/bugs/813026
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Johansen [Thu, 11 Aug 2011 07:44:56 +0000 (00:44 -0700)]
Add mount option to check uid of device being mounted = expect uid, CVE-2011-1833
Close a TOCTOU race for mounts done via ecryptfs-mount-private. The mount
source (device) can be raced when the ownership test is done in userspace.
Provide Ecryptfs a means to force the uid check at mount time.
(backported from commit
764355487ea220fdc2faf128d577d7f679b91f97)
CVE-2011-1833
BugLink: http://bugs.launchpad.net/bugs/732628
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Nikola Ciprich [Wed, 9 Mar 2011 22:36:51 +0000 (23:36 +0100)]
KVM: fix kvmclock regression due to missing clock update
commit
387b9f97750444728962b236987fbe8ee8cc4f8c moved kvm_request_guest_time_update(vcpu),
breaking 32bit SMP guests using kvm-clock. Fix this by moving (new) clock update function
to proper place.
Signed-off-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
Acked-by: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
(cherry-picked from commit
1aa8ceef0312a6aae7dd863a120a55f1637b361d upstream)
BugLink: http://bugs.launchpad.net/bugs/795717
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
David Dillow [Fri, 5 Aug 2011 19:41:28 +0000 (14:41 -0500)]
drm/nv50-nvc0: work around an evo channel hang that some people see
BugLink: http://bugs.launchpad.net/bugs/583760
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
(cherry picked from commit
59197c026257ab730c7fc8819a0e2b26e125a534)
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Filip Palian [Fri, 5 Aug 2011 10:48:56 +0000 (11:48 +0100)]
Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.
Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding
byte each. This byte in "cinfo" is copied to userspace uninitialized.
Signed-off-by: Filip Palian <filip.palian@pjwstk.edu.pl>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
(backported from commit
8d03e971cf403305217b8e62db3a2e5ad2d6263f)
CVE-2011-2492
BugLink: http://bugs.launchpad.net/bugs/819569
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Benjamin Marzinski [Tue, 2 Aug 2011 09:31:59 +0000 (10:31 +0100)]
GFS2: make sure fallocate bytes is a multiple of blksize, CVE-2011-2689
The GFS2 fallocate code chooses a target size to for allocating chunks of
space. Whenever it can't find any resource groups with enough space free, it
halves its target. Since this target is in bytes, eventually it will no longer
be a multiple of blksize. As long as there is more space available in the
resource group than the target, this isn't a problem, since gfs2 will use the
actual space available, which is always a multiple of blksize. However,
when gfs couldn't fallocate a bigger chunk than the target, it was using the
non-blksize aligned number. This caused a BUG in later code that required
blksize aligned offsets. GFS2 now ensures that bytes is always a multiple of
blksize
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
(cherry picked from commit
6905d9e4dda6112f007e9090bca80507da158e63)
CVE-2011-2689
BugLink: http://bugs.launchpad.net/bugs/819572
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paweł Drewniak [Fri, 24 Jun 2011 06:07:35 +0000 (02:07 -0400)]
pata_marvell: Add support for 88SE91A0, 88SE91A4
BugLink: http://bugs.launchpad.net/bugs/777325
This patch enables support for Marvell IDE PATA controllers found on
Asus P8P67LE motherboard.
The formatting has been corrected and I also received a report from two
users of this motherboard that the patch works.
Signed-off-by: Paweł Drewniak <czajernia@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
(cherry picked from commit
f920fe1cb74191a780d88937f36994231a8faba1)
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Adam Jackson [Mon, 1 Aug 2011 14:19:55 +0000 (15:19 +0100)]
UBUNTU: SAUCE: drm/i915/pch: Fix integer math bugs in panel fitting
Currently sitting in the drm-intel/drm-intel-fixes branch
Consider a 1600x900 panel, upscaling a 1360x768 mode, full-aspect. The
old math would give you:
scaled_width = 1600 * 768; /* 1228800 */
scaled_height = 1360 * 900; /* 1224000 */
if (scaled_width > scaled_height) { /* pillarbox, and true */
width = 1224000 / 768; /* int(1593.75) = 1593 */
x = (1600 - 1593 + 1) / 2; /* 4 */
y = 0;
height = 768;
} /* ... */
This is broken. The total width of scanout would then be 1593 + 4 + 4,
or 1601, which is wider than the panel itself. The hardware very
dutifully implements this, and you end up with a black 45° diagonal from
the top-left corner to the bottom edge of the screen. It's a cool
effect and all, but not what you wanted. Similar things happen for the
letterbox case.
The problem is that you have an integer number of pixels, which means
it's usually impossible to upscale equally on both axes. 1360/768 is
1.7708, 1600/900 is 1.7777. Since we're constrained on the one axis,
the other one wants to come out as an even number of pixels (the panel
is almost certainly even on both axes, and the x/y offsets will be
applied on both sides). In the math above, if 'width' comes out even,
rounding down is correct; if it's odd, you'd rather round up. So just
increment width/height in those cases.
Tested on a Lenovo T500 (Ironlake).
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-By: Daniel Manrique <daniel.manrique@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
BugLink: http://bugs.launchpad.net/bugs/753994
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Ben Hutchings [Thu, 28 Jul 2011 10:05:35 +0000 (11:05 +0100)]
rose: Add length checks to CALL_REQUEST parsing, CVE-2011-1493
Define some constant offsets for CALL_REQUEST based on the description
at <http://www.techfest.com/networking/wan/x25plp.htm> and the
definition of ROSE as using 10-digit (5-byte) addresses. Use them
consistently. Validate all implicit and explicit facilities lengths.
Validate the address length byte rather than either trusting or
assuming its value.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit
e0bccd315db0c2f919e7fcf9cb60db21d9986f52)
CVE-2011-1493
BugLink: http://bugs.launchpad.net/bugs/816550
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Manoj Iyer [Mon, 11 Jul 2011 21:28:35 +0000 (16:28 -0500)]
mmc: Added quirks for Ricoh 1180:e823 lower base clock frequency
BugLink: http://bugs.launchpad.net/bugs/773524
Ricoh 1180:e823 does not recognize certain types of SD/MMC cards,
as reported at http://launchpad.net/bugs/773524. Lowering the SD
base clock frequency from 200Mhz to 50Mhz fixes this issue. This
solution was suggest by Koji Matsumuro, Ricoh Company, Ltd.
This change has no negative performance effect on standard SD
cards, though it's quite possible that there will be one on
UHS-1 cards.
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Tested-by: Daniel Manrique <daniel.manrique@canonical.com>
Cc: Koji Matsumuro <matsumur@nts.ricoh.co.jp>
Cc: <stable@kernel.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit
15bed0f2fa8e1d7db201692532c210a7823d2d21)
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Manoj Iyer [Thu, 26 May 2011 16:19:05 +0000 (11:19 -0500)]
mmc: Add PCI fixup quirks for Ricoh 1180:e823 reader
BugLink: http://bugs.launchpad.net/bugs/773524
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Thu, 21 Jul 2011 20:29:58 +0000 (14:29 -0600)]
UBUNTU: [Config] Add enic/fnic to udebs
BugLink: http://bugs.launchpad.net/bugs/801610
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Shaohua Li [Tue, 19 Jul 2011 15:49:26 +0000 (08:49 -0700)]
vmscan: fix a livelock in kswapd
BugLink: http://bugs.launchpad.net/bugs/813797
I'm running a workload which triggers a lot of swap in a machine with 4
nodes. After I kill the workload, I found a kswapd livelock. Sometimes
kswapd3 or kswapd2 are keeping running and I can't access filesystem,
but most memory is free.
This looks like a regression since commit
08951e545918c159 ("mm: vmscan:
correct check for kswapd sleeping in sleeping_prematurely").
Node 2 and 3 have only ZONE_NORMAL, but balance_pgdat() will return 0
for classzone_idx. The reason is end_zone in balance_pgdat() is 0 by
default, if all zones have watermark ok, end_zone will keep 0.
Later sleeping_prematurely() always returns true. Because this is an
order 3 wakeup, and if classzone_idx is 0, both balanced_pages and
present_pages in pgdat_balanced() are 0. We add a special case here.
If a zone has no page, we think it's balanced. This fixes the livelock.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Al Viro [Thu, 21 Jul 2011 13:13:46 +0000 (14:13 +0100)]
deal with races in /proc/*/{syscall, stack, personality}, CVE-2011-1020
All of those are rw-r--r-- and all are broken for suid - if you open
a file before the target does suid-root exec, you'll be still able
to access it. For personality it's not a big deal, but for syscall
and stack it's a real problem.
Fix: check that task is tracable for you at the time of read().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(backported from commit
a9712bc12c40c172e393f85a9b2ba8db4bf59509)
CVE-2011-1020
BugLink: http://bugs.launchpad.net/bugs/813026
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Al Viro [Thu, 21 Jul 2011 13:13:45 +0000 (14:13 +0100)]
auxv: require the target to be tracable (or yourself), CVE-2011-1020
same as for environ, except that we didn't do any checks to
prevent access after suid execve
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit
2fadaef41283aad7100fa73f01998cddaca25833)
CVE-2011-1020
BugLink: http://bugs.launchpad.net/bugs/813026
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Al Viro [Thu, 21 Jul 2011 13:13:44 +0000 (14:13 +0100)]
close race in /proc/*/environ, CVE-2011-1020
Switch to mm_for_maps(). Maybe we ought to make it r--r--r--,
since we do checks on IO anyway...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit
d6f64b89d7ff22ce05896ab4a93a653e8d0b123d)
CVE-2011-1020
BugLink: http://bugs.launchpad.net/bugs/813026
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Al Viro [Thu, 21 Jul 2011 13:13:43 +0000 (14:13 +0100)]
report errors in /proc/*/*map* sanely, CVE-2011-1020
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit
ec6fd8a4355cda81cd9f06bebc048e83eb514ac7)
CVE-2011-1020
BugLink: http://bugs.launchpad.net/bugs/813026
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Al Viro [Thu, 21 Jul 2011 13:13:42 +0000 (14:13 +0100)]
pagemap: close races with suid execve, CVE-2011-1020
just use mm_for_maps()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit
ca6b0bf0e086513b9ee5efc0aa5770ecb57778af)
CVE-2011-1020
BugLink: http://bugs.launchpad.net/bugs/813026
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Fri, 15 Jul 2011 16:49:42 +0000 (10:49 -0600)]
eCryptfs: Handle failed metadata read in lookup
When failing to read the lower file's crypto metadata during a lookup,
eCryptfs must continue on without throwing an error. For example, there
may be a plaintext file in the lower mount point that the user wants to
delete through the eCryptfs mount.
If an error is encountered while reading the metadata in lookup(), the
eCryptfs inode's size could be incorrect. We must be sure to reread the
plaintext inode size from the metadata when performing an open() or
setattr(). The metadata is already being read in those paths, so this
adds minimal performance overhead.
This patch introduces a flag which will track whether or not the
plaintext inode size has been read so that an incorrect i_size can be
fixed in the open() or setattr() paths.
BugLink: http://bugs.launchpad.net/bugs/509180
Cc: <stable@kernel.org>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
(backported from
3aeb86ea4cd15f728147a3bd5469a205ada8c767)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Keng-Yu Lin [Tue, 19 Jul 2011 10:40:00 +0000 (18:40 +0800)]
UBUNTU: SAUCE: Input: ALPS - Enable Intellimouse mode for Lenovo Zhaoyang E47
The quirk enables the edge-scrolling function of the touchpad.
This patch depends on the following sauce patch:
commit
83ccc92aa7bc9b9d47fc31a7b54e663fb9a3d992
Author: Rezwanul Kabir <Rezwanul_Kabir@dell.com>
Date: Tue Nov 23 20:15:14 2010 +0000
Add support for Intellimouse Mode in ALPS touchpad on Dell E2 series Laptops
Resending modified patch to fix suspend/resume issues and restricting the
quirks to Dell portables only.
Dell E2 series laptops ( M4500, E6510, E6410 etc.) have ALPS touchpads
which are enabled by default as 3-byte generic PS/2 mouse mode. This
patch enables the 4-byte "Intellimouse Mode" ( e.g scrolling support).
Signed-off-by: Rezwanul_Kabir <Rezwanul_Kabir@dell.com>
BugLink: http://bugs.launchpad.net/bugs/632884
Signed-off-by: Andy Whitcroft <apw@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/803005
Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Corentin Chary [Tue, 19 Jul 2011 07:05:53 +0000 (15:05 +0800)]
eeepc-wmi: add keys found on EeePC 1215T
BugLink: http://bugs.launchpad.net/bugs/812644
Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
(cherry picked from commit
9481472559b3ecd366390786628c2fb211d1477b)
Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Herton Ronaldo Krzesinski [Mon, 29 Aug 2011 19:20:25 +0000 (16:20 -0300)]
UBUNTU: Start new release
Ignore: yes
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Fri, 29 Jul 2011 17:51:38 +0000 (14:51 -0300)]
UBUNTU: Ubuntu-2.6.38-11.48
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Jiri Kosina [Thu, 16 Jun 2011 10:21:34 +0000 (12:21 +0200)]
Revert "HID: magicmouse: ignore 'ivalid report id' while switching modes"
This reverts commit
23746a66d7d9e73402c68ef00d708796b97ebd72.
It turned out that the actual reason for failure is not the device
firmware, but bug in Bluetooth stack, which will be fixed by
patch by Ville Tervo which corrects the mask handling for CSR 1.1
Dongles.
BugLink: http://bugs.launchpad.net/bugs/814250
Reported-and-tested-by: Ed Tomlinson <edt@aei.ca>
Reported-and-tested-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
(cherry-picked from commit
c3a4924565e2eecf2539871abd123d35be6d76d5 upstream)
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Stefan Bader <smb@canonical.com>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Herton Ronaldo Krzesinski [Thu, 28 Jul 2011 19:33:44 +0000 (16:33 -0300)]
UBUNTU: Start new release
Ignore: yes
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Steve Conklin [Fri, 15 Jul 2011 17:59:13 +0000 (12:59 -0500)]
UBUNTU: Ubuntu-2.6.38-11.47
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Mel Gorman [Fri, 8 Jul 2011 22:39:40 +0000 (15:39 -0700)]
mm: vmscan: only read new_classzone_idx from pgdat when reclaiming successfully
BugLink: http://bugs.launchpad.net/bugs/808509
During allocator-intensive workloads, kswapd will be woken frequently
causing free memory to oscillate between the high and min watermark. This
is expected behaviour. Unfortunately, if the highest zone is small, a
problem occurs.
When balance_pgdat() returns, it may be at a lower classzone_idx than it
started because the highest zone was unreclaimable. Before checking if it
should go to sleep though, it checks pgdat->classzone_idx which when there
is no other activity will be MAX_NR_ZONES-1. It interprets this as it has
been woken up while reclaiming, skips scheduling and reclaims again. As
there is no useful reclaim work to do, it enters into a loop of shrinking
slab consuming loads of CPU until the highest zone becomes reclaimable for
a long period of time.
There are two problems here. 1) If the returned classzone or order is
lower, it'll continue reclaiming without scheduling. 2) if the highest
zone was marked unreclaimable but balance_pgdat() returns immediately at
DEF_PRIORITY, the new lower classzone is not communicated back to kswapd()
for sleeping.
This patch does two things that are related. If the end_zone is
unreclaimable, this information is communicated back. Second, if the
classzone or order was reduced due to failing to reclaim, new information
is not read from pgdat and instead an attempt is made to go to sleep. Due
to this, it is also necessary that pgdat->classzone_idx be initialised
each time to pgdat->nr_zones - 1 to avoid re-reads being interpreted as
wakeups.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reported-by: Pádraig Brady <P@draigBrady.com>
Tested-by: Pádraig Brady <P@draigBrady.com>
Tested-by: Andrew Lutomirski <luto@mit.edu>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
215ddd6664ced067afca7eebd2d1eb83f064ff5a)
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>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Mel Gorman [Fri, 8 Jul 2011 22:39:39 +0000 (15:39 -0700)]
mm: vmscan: evaluate the watermarks against the correct classzone
BugLink: http://bugs.launchpad.net/bugs/808509
When deciding if kswapd is sleeping prematurely, the classzone is taken
into account but this is different to what balance_pgdat() and the
allocator are doing. Specifically, the DMA zone will be checked based on
the classzone used when waking kswapd which could be for a GFP_KERNEL or
GFP_HIGHMEM request. The lowmem reserve limit kicks in, the watermark is
not met and kswapd thinks it's sleeping prematurely keeping kswapd awake in
error.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reported-by: Pádraig Brady <P@draigBrady.com>
Tested-by: Pádraig Brady <P@draigBrady.com>
Tested-by: Andrew Lutomirski <luto@mit.edu>
Acked-by: Rik van Riel <riel@redhat.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
da175d06b437093f93109ba9e5efbe44dfdf9409)
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>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Mel Gorman [Mon, 11 Jul 2011 09:21:15 +0000 (10:21 +0100)]
mm: vmscan: do not apply pressure to slab if we are not applying pressure to zone
BugLink: http://bugs.launchpad.net/bugs/808509
commit
d7868dae893c83c50c7824bc2bc75f93d114669f
During allocator-intensive workloads, kswapd will be woken frequently
causing free memory to oscillate between the high and min watermark. This
is expected behaviour.
When kswapd applies pressure to zones during node balancing, it checks if
the zone is above a high+balance_gap threshold. If it is, it does not
apply pressure but it unconditionally shrinks slab on a global basis which
is excessive. In the event kswapd is being kept awake due to a high small
unreclaimable zone, it skips zone shrinking but still calls shrink_slab().
Once pressure has been applied, the check for zone being unreclaimable is
being made before the check is made if all_unreclaimable should be set.
This miss of unreclaimable can cause has_under_min_watermark_zone to be
set due to an unreclaimable zone preventing kswapd backing off on
congestion_wait().
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reported-by: Pádraig Brady <P@draigBrady.com>
Tested-by: Pádraig Brady <P@draigBrady.com>
Tested-by: Andrew Lutomirski <luto@mit.edu>
Acked-by: Rik van Riel <riel@redhat.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
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>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Mel Gorman [Tue, 22 Mar 2011 23:33:04 +0000 (16:33 -0700)]
mm: vmscan: kswapd should not free an excessive number of pages when balancing small zones
BugLink: http://bugs.launchpad.net/bugs/808509
When reclaiming for order-0 pages, kswapd requires that all zones be
balanced. Each cycle through balance_pgdat() does background ageing on
all zones if necessary and applies equal pressure on the inactive zone
unless a lot of pages are free already.
A "lot of free pages" is defined as a "balance gap" above the high
watermark which is currently 7*high_watermark. Historically this was
reasonable as min_free_kbytes was small. However, on systems using huge
pages, it is recommended that min_free_kbytes is higher and it is tuned
with hugeadm --set-recommended-min_free_kbytes. With the introduction of
transparent huge page support, this recommended value is also applied. On
X86-64 with 4G of memory, min_free_kbytes becomes 67584 so one would
expect around 68M of memory to be free. The Normal zone is approximately
35000 pages so under even normal memory pressure such as copying a large
file, it gets exhausted quickly. As it is getting exhausted, kswapd
applies pressure equally to all zones, including the DMA32 zone. DMA32 is
approximately 700,000 pages with a high watermark of around 23,000 pages.
In this situation, kswapd will reclaim around (23000*8 where 8 is the high
watermark + balance gap of 7 * high watermark) pages or 718M of pages
before the zone is ignored. What the user sees is that free memory far
higher than it should be.
To avoid an excessive number of pages being reclaimed from the larger
zones, explicitely defines the "balance gap" to be either 1% of the zone
or the low watermark for the zone, whichever is smaller. While kswapd
will check all zones to apply pressure, it'll ignore zones that meets the
(high_wmark + balance_gap) watermark.
To test this, 80G were copied from a partition and the amount of memory
being used was recorded. A comparison of a patch and unpatched kernel can
be seen at
http://www.csn.ul.ie/~mel/postings/minfree-
20110222/memory-usage-hydra.ps
and shows that kswapd is not reclaiming as much memory with the patch
applied.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Shaohua Li <shaohua.li@intel.com>
Cc: "Chen, Tim C" <tim.c.chen@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
8afdcece4911e51cfff2b50a269418914cab8a3f)
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>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Mel Gorman [Fri, 8 Jul 2011 22:39:36 +0000 (15:39 -0700)]
mm: vmscan: correct check for kswapd sleeping in sleeping_prematurely
BugLink: http://bugs.launchpad.net/bugs/808509
During allocator-intensive workloads, kswapd will be woken frequently
causing free memory to oscillate between the high and min watermark. This
is expected behaviour. Unfortunately, if the highest zone is small, a
problem occurs.
This seems to happen most with recent sandybridge laptops but it's
probably a co-incidence as some of these laptops just happen to have a
small Normal zone. The reproduction case is almost always during copying
large files that kswapd pegs at 100% CPU until the file is deleted or
cache is dropped.
The problem is mostly down to sleeping_prematurely() keeping kswapd awake
when the highest zone is small and unreclaimable and compounded by the
fact we shrink slabs even when not shrinking zones causing a lot of time
to be spent in shrinkers and a lot of memory to be reclaimed.
Patch 1 corrects sleeping_prematurely to check the zones matching
the classzone_idx instead of all zones.
Patch 2 avoids shrinking slab when we are not shrinking a zone.
Patch 3 notes that sleeping_prematurely is checking lower zones against
a high classzone which is not what allocators or balance_pgdat()
is doing leading to an artifical belief that kswapd should be
still awake.
Patch 4 notes that when balance_pgdat() gives up on a high zone that the
decision is not communicated to sleeping_prematurely()
This problem affects 2.6.38.8 for certain and is expected to affect 2.6.39
and 3.0-rc4 as well. If accepted, they need to go to -stable to be picked
up by distros and this series is against 3.0-rc4. I've cc'd people that
reported similar problems recently to see if they still suffer from the
problem and if this fixes it.
This patch: correct the check for kswapd sleeping in sleeping_prematurely()
During allocator-intensive workloads, kswapd will be woken frequently
causing free memory to oscillate between the high and min watermark. This
is expected behaviour.
A problem occurs if the highest zone is small. balance_pgdat() only
considers unreclaimable zones when priority is DEF_PRIORITY but
sleeping_prematurely considers all zones. It's possible for this sequence
to occur
1. kswapd wakes up and enters balance_pgdat()
2. At DEF_PRIORITY, marks highest zone unreclaimable
3. At DEF_PRIORITY-1, ignores highest zone setting end_zone
4. At DEF_PRIORITY-1, calls shrink_slab freeing memory from
highest zone, clearing all_unreclaimable. Highest zone
is still unbalanced
5. kswapd returns and calls sleeping_prematurely
6. sleeping_prematurely looks at *all* zones, not just the ones
being considered by balance_pgdat. The highest small zone
has all_unreclaimable cleared but the zone is not
balanced. all_zones_ok is false so kswapd stays awake
This patch corrects the behaviour of sleeping_prematurely to check the
zones balance_pgdat() checked.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reported-by: Pádraig Brady <P@draigBrady.com>
Tested-by: Pádraig Brady <P@draigBrady.com>
Tested-by: Andrew Lutomirski <luto@mit.edu>
Acked-by: Rik van Riel <riel@redhat.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
08951e545918c1594434d000d88a7793e2452a9b)
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>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Stefan Bader [Tue, 12 Jul 2011 13:31:16 +0000 (13:31 +0000)]
UBUNTU: SAUCE: Re-enable RODATA for i386 virtual
This basically reverts the following commit as it seems now fixed.
commit
0b111980fe515c5ab24bf21aca5aebd24c70f605
Author: Stefan Bader <stefan.bader@canonical.com>
Date: Tue Jan 11 23:29:25 2011 +0000
UBUNTU: Temporarily disable RODATA for virtual i386
Setting to RO was ok, but the whole patchset seems to cause
i386 EC instances to panic on boot when setting the kernel data
to read-only and no-execute. So while there is no proper fix
found disable this in the i386 virtual flavour.
BugLink: http://bugs.launchpad.net/bugs/809838
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Seth Forshee [Fri, 1 Jul 2011 10:40:56 +0000 (11:40 +0100)]
(drop after 2.6.38) acer-wmi: Add support for Aspire 1830 wlan hotkey
BugLink: http://bugs.launchpad.net/bugs/771758
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Seth Forshee [Tue, 21 Jun 2011 17:00:33 +0000 (12:00 -0500)]
acer-wmi: Only update rfkill status for associated hotkey events
BugLink: http://bugs.launchpad.net/bugs/771758
acer-wmi is indiscriminately using the device state from hotkey
events to update the various rfkill states. On the Aspire 1830 this
can result in a soft block on the wlan when the touchpad hotkey is
pressed, as it is reporting a non-zero device state that does not
reflect the wireless status. To fix this, only update rfkill states
when a wlan or bluetooth hotkey is pressed.
(backported from commit
92530664bbe5a13aede4a8763459bbe560ad9221 upstream)
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Lee, Chun-Yi [Fri, 1 Jul 2011 10:40:55 +0000 (11:40 +0100)]
acer-wmi: does not poll device status when WMI event is available
BugLink: http://bugs.launchpad.net/bugs/771758
Acer WMI hotkey event's result include current device status, just
need sync the status to killswitch after acer-wmi driver receive
hotkey event but not always poll device status. This is good for
performance.
But, if use EC raw mode, Acer BIOS will not emit wmi event and
leave EC to control device status. So, still startup polling job
when doesn't detect WMI event GUID or user choice to use ec_raw_mode.
Tested on Acer TravelMate 8572 notebook.
Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
(cherry picked from commit
70a9b9047aebd53ac38837a1046da52a2f8d9636)
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tao Ma [Thu, 7 Jul 2011 12:39:00 +0000 (13:39 +0100)]
ext4: init timer earlier to avoid a kernel panic in __save_error_info, CVE-2011-2493
During mount, when we fail to open journal inode or root inode, the
__save_error_info will mod_timer. But actually s_err_report isn't
initialized yet and the kernel oops. The detailed information can
be found https://bugzilla.kernel.org/show_bug.cgi?id=32082.
The best way is to check whether the timer s_err_report is initialized
or not. But it seems that in include/linux/timer.h, we can't find a
good function to check the status of this timer, so this patch just
move the initializtion of s_err_report earlier so that we can avoid
the kernel panic. The corresponding del_timer is also added in the
error path.
Reported-by: Sami Liedes <sliedes@cc.hut.fi>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
(cherry picked from commit
0449641130f5652b344ef6fa39fa019d7e94660a)
CVE-2011-2493
BugLink: http://bugs.launchpad.net/bugs/806929
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Vasiliy Kulikov [Thu, 7 Jul 2011 11:17:08 +0000 (12:17 +0100)]
taskstats: don't allow duplicate entries in listener mode, CVE-2011-2484
Currently a single process may register exit handlers unlimited times.
It may lead to a bloated listeners chain and very slow process
terminations.
Eg after 10KK sent TASKSTATS_CMD_ATTR_REGISTER_CPUMASKs ~300 Mb of
kernel memory is stolen for the handlers chain and "time id" shows 2-7
seconds instead of normal 0.003. It makes it possible to exhaust all
kernel memory and to eat much of CPU time by triggerring numerous exits
on a single CPU.
The patch limits the number of times a single process may register
itself on a single CPU to one.
One little issue is kept unfixed - as taskstats_exit() is called before
exit_files() in do_exit(), the orphaned listener entry (if it was not
explicitly deregistered) is kept until the next someone's exit() and
implicit deregistration in send_cpu_listeners(). So, if a process
registered itself as a listener exits and the next spawned process gets
the same pid, it would inherit taskstats attributes.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
26c4caea9d697043cc5a458b96411b86d7f6babd)
CVE-2011-2484
BugLink: http://bugs.launchpad.net/bugs/806390
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Tim Gardner [Mon, 4 Jul 2011 14:22:13 +0000 (15:22 +0100)]
UBUNTU: SAUCE: rtl8192se: Force a build for a 2.6/3.0 kernel
BugLink: http://bugs.launchpad.net/bugs/805494
The makefile for this module is hideous. It checkes the build host kernel
version in order to determine which driver version should be built. Since
we know it will only _ever_ be built for 2.6/3.0, then just shortcut
the ifeq().
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Ming Lei [Wed, 29 Jun 2011 11:06:25 +0000 (19:06 +0800)]
UBUNTU: SAUCE: fix yama_ptracer_del lockdep warning
yama_ptracer_del can be called in softirq context, so
ptracer_relations_lock may be held in softirq context.
This patch replaces spin_[un]lock with spin_[un]lock_bh for
&ptracer_relations_lock to fix reported lockdep warning and
avoid possible dealock.
BugLink: http://bugs.launchpad.net/bugs/791019
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Keng-Yu Lin [Mon, 27 Jun 2011 17:01:11 +0000 (18:01 +0100)]
UBUNTU: SAUCE: Revert: "dell-laptop: Toggle the unsupported hardware killswitch"
This reverts commit
a3d77411e8b2ad661958c1fbee65beb476ec6d70,
as it causes a mess in the wireless rfkill status on some models.
It is probably a bad idea to toggle the rfkill for all dell models
without the respect to the claim that it is hardware-controlled.
BugLink: http://bugs.launchpad.net/bugs/775281
Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Maarten Lankhorst [Wed, 1 Jun 2011 21:27:50 +0000 (23:27 +0200)]
xhci: Do not issue device reset when device is not setup
BugLink: http://bugs.launchpad.net/bugs/802541
xHCI controllers respond to a Reset Device command when the Slot is in the
Enabled/Disabled state by returning an error. This is fine on other host
controllers, but the Etron xHCI host controller returns a vendor-specific
error code that the xHCI driver doesn't understand. The xHCI driver then
gives up on device enumeration.
Instead of issuing a command that will fail, just return. This fixes the
issue with the xhci driver not working on ASRock P67 Pro/Extreme boards.
This should be backported to stable kernels as far back as 2.6.34.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
(cherry picked from commit
001fd3826f4c736ce292315782d015f768399080)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Maarten Lankhorst [Wed, 1 Jun 2011 21:27:49 +0000 (23:27 +0200)]
xhci: Add defines for hardcoded slot states
BugLink: http://bugs.launchpad.net/bugs/802541
This needs to be added to the stable trees back to 2.6.34 to support an
upcoming bug fix.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
(backported from commit
e2b0217715c6d10379d94bdfe5560af96eecbb7c)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Greg Kroah-Hartman [Fri, 3 Jun 2011 01:35:11 +0000 (10:35 +0900)]
Linux 2.6.38.8
BugLink: http://bugs.launchpad.net/bugs/793702
Kees Cook [Tue, 31 May 2011 18:31:41 +0000 (11:31 -0700)]
AppArmor: fix oops in apparmor_setprocattr
BugLink: http://bugs.launchpad.net/bugs/793702
commit
a5b2c5b2ad5853591a6cac6134cd0f599a720865 upstream.
When invalid parameters are passed to apparmor_setprocattr a NULL deref
oops occurs when it tries to record an audit message. This is because
it is passing NULL for the profile parameter for aa_audit. But aa_audit
now requires that the profile passed is not NULL.
Fix this by passing the current profile on the task that is trying to
setprocattr.
Signed-off-by: Kees Cook <kees@ubuntu.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Lukas Czerner [Fri, 20 May 2011 17:49:04 +0000 (13:49 -0400)]
ext4: Use schedule_timeout_interruptible() for waiting in lazyinit thread
BugLink: http://bugs.launchpad.net/bugs/793702
commit
4ed5c033c11b33149d993734a6a8de1016e8f03f upstream.
In order to make lazyinit eat approx. 10% of io bandwidth at max, we
are sleeping between zeroing each single inode table. For that purpose
we are using timer which wakes up thread when it expires. It is set
via add_timer() and this may cause troubles in the case that thread
has been woken up earlier and in next iteration we call add_timer() on
still running timer hence hitting BUG_ON in add_timer(). We could fix
that by using mod_timer() instead however we can use
schedule_timeout_interruptible() for waiting and hence simplifying
things a lot.
This commit exchange the old "waiting mechanism" with simple
schedule_timeout_interruptible(), setting the time to sleep. Hence we
do not longer need li_wait_daemon waiting queue and others, so get rid
of it.
Addresses-Red-Hat-Bugzilla: #699708
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tian, Kevin [Thu, 12 May 2011 02:56:08 +0000 (10:56 +0800)]
xen mmu: fix a race window causing leave_mm BUG()
BugLink: http://bugs.launchpad.net/bugs/793702
commit
7899891c7d161752f29abcc9bc0a9c6c3a3af26c upstream.
There's a race window in xen_drop_mm_ref, where remote cpu may exit
dirty bitmap between the check on this cpu and the point where remote
cpu handles drop request. So in drop_other_mm_ref we need check
whether TLB state is still lazy before calling into leave_mm. This
bug is rarely observed in earlier kernel, but exaggerated by the
commit
831d52bc153971b70e64eccfbed2b232394f22f8
("x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm")
which clears bitmap after changing the TLB state. the call trace is as below:
---------------------------------
kernel BUG at arch/x86/mm/tlb.c:61!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
CPU 1
Modules linked in: 8021q garp xen_netback xen_blkback blktap blkback_pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sbs sbshc parport_pc lp parport ses enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device serio_raw bnx2 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iTCO_wdt snd soundcore snd_page_alloc i2c_i801 iTCO_vendor_support i2c_core pcs pkr pata_acpi ata_generic ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table]
Pid: 25581, comm: khelper Not tainted 2.6.32.36fixxen #1 Tecal RH2285
RIP: e030:[<
ffffffff8103a3cb>] [<
ffffffff8103a3cb>] leave_mm+0x15/0x46
RSP: e02b:
ffff88002805be48 EFLAGS:
00010046
RAX:
0000000000000000 RBX:
0000000000000001 RCX:
ffff88015f8e2da0
RDX:
ffff88002805be78 RSI:
0000000000000000 RDI:
0000000000000001
RBP:
ffff88002805be48 R08:
ffff88009d662000 R09:
dead000000200200
R10:
dead000000100100 R11:
ffffffff814472b2 R12:
ffff88009bfc1880
R13:
ffff880028063020 R14:
00000000000004f6 R15:
0000000000000000
FS:
00007f62362d66e0(0000) GS:
ffff880028058000(0000) knlGS:
0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000003aabc11909 CR3:
000000009b8ca000 CR4:
0000000000002660
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
00000000000000 00
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process khelper (pid: 25581, threadinfo
ffff88007691e000, task
ffff88009b92db40)
Stack:
ffff88002805be68 ffffffff8100e4ae 0000000000000001 ffff88009d733b88
<0>
ffff88002805be98 ffffffff81087224 ffff88002805be78 ffff88002805be78
<0>
ffff88015f808360 00000000000004f6 ffff88002805bea8 ffffffff81010108
Call Trace:
<IRQ>
[<
ffffffff8100e4ae>] drop_other_mm_ref+0x2a/0x53
[<
ffffffff81087224>] generic_smp_call_function_single_interrupt+0xd8/0xfc
[<
ffffffff81010108>] xen_call_function_single_interrupt+0x13/0x28
[<
ffffffff810a936a>] handle_IRQ_event+0x66/0x120
[<
ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e
[<
ffffffff8128c1c0>] __xen_evtchn_do_upcall+0x1ab/0x27d
[<
ffffffff8128dd11>] xen_evtchn_do_upcall+0x33/0x46
[<
ffffffff81013efe>] xen_do_hyper visor_callback+0x1e/0x30
<EOI>
[<
ffffffff814472b2>] ? _spin_unlock_irqrestore+0x15/0x17
[<
ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
[<
ffffffff81113f71>] ? flush_old_exec+0x3ac/0x500
[<
ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
[<
ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
[<
ffffffff8115115d>] ? load_elf_binary+0x398/0x17ef
[<
ffffffff81042fcf>] ? need_resched+0x23/0x2d
[<
ffffffff811f4648>] ? process_measurement+0xc0/0xd7
[<
ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
[<
ffffffff81113094>] ? search_binary_handler+0xc8/0x255
[<
ffffffff81114362>] ? do_execve+0x1c3/0x29e
[<
ffffffff8101155d>] ? sys_execve+0x43/0x5d
[<
ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
[<
ffffffff81013e28>] ? kernel_execve+0x68/0xd0
[<
ffffffff 8106fc45>] ? __call_usermodehelper+0x0/0x6f
[<
ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
[<
ffffffff8106fb64>] ? ____call_usermodehelper+0x113/0x11e
[<
ffffffff81013daa>] ? child_rip+0xa/0x20
[<
ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
[<
ffffffff81012f91>] ? int_ret_from_sys_call+0x7/0x1b
[<
ffffffff8101371d>] ? retint_restore_args+0x5/0x6
[<
ffffffff81013da0>] ? child_rip+0x0/0x20
Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8
RIP [<
ffffffff8103a3cb>] leave_mm+0x15/0x46
RSP <
ffff88002805be48>
---[ end trace
ce9cee6832a9c503 ]---
Tested-by: Maoxiaoyun<tinnycloud@hotmail.com>
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
[v1: Fleshed out the git description a bit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Hemant Pedanekar [Tue, 5 Apr 2011 07:02:50 +0000 (12:32 +0530)]
PCI: Add quirk for setting valid class for TI816X Endpoint
BugLink: http://bugs.launchpad.net/bugs/793702
commit
63c4408074cbcc070ac17fc10e524800eb9bd0b0 upstream.
TI816X (common name for DM816x/C6A816x/AM389x family) devices configured
to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus
code to skip allocating BARs to these devices resulting into following
type of error when trying to enable them:
"Device 0000:01:00.0 not available because of resource collisions"
The device cannot be operated because of the above issue.
This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based)
'early' fixup quirk to replace class code with
PCI_CLASS_MULTIMEDIA_VIDEO as class.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Trond Myklebust [Thu, 26 May 2011 18:26:35 +0000 (14:26 -0400)]
NFSv4.1: Fix the handling of NFS4ERR_SEQ_MISORDERED errors
BugLink: http://bugs.launchpad.net/bugs/793702
commit
444f72fe7e7b5f4db34cee933fa3546ebb8e9122 upstream.
Currently, the call to nfs4_schedule_session_recovery() will actually just
result in a test of the lease when what we really want is to force a
session reset.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Trond Myklebust [Thu, 26 May 2011 18:26:35 +0000 (14:26 -0400)]
NFSv4: Handle expired stateids when the lease is still valid
BugLink: http://bugs.launchpad.net/bugs/793702
commit
0ced63d1a245ac11241a5d37932e6d04d9c8040d upstream.
Currently, if the server returns NFS4ERR_EXPIRED in reply to a READ or
WRITE, but the RENEW test determines that the lease is still active, we
fail to recover and end up looping forever in a READ/WRITE + RENEW death
spiral.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Trond Myklebust [Sat, 19 Mar 2011 00:21:23 +0000 (20:21 -0400)]
SUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback...
BugLink: http://bugs.launchpad.net/bugs/793702
commit
fe19a96b10032035a35779f42ad59e35d6dd8ffd upstream.
The TCP connection state code depends on the state_change() callback
being called when the SYN_SENT state is set. However the networking layer
doesn't actually call us back in that case.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dave Airlie [Thu, 19 May 2011 04:14:43 +0000 (14:14 +1000)]
drm/radeon/kms: add wait idle ioctl for eg->cayman
BugLink: http://bugs.launchpad.net/bugs/793702
commit
97bfd0acd32e9639c9136e03955d574655d5cc2b upstream.
None of the latest GPUs had this hooked up, this is necessary for
correct operation in a lot of cases, however we should test this on a few
GPUs in these families as we've had problems in this area before.
Reviewed-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 Deucher [Thu, 19 May 2011 15:07:57 +0000 (11:07 -0400)]
drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when asked
BugLink: http://bugs.launchpad.net/bugs/793702
commit
f25a5c63bfa017498c9adecb24d649ae96ba5c68 upstream.
This needs to be explicitly set on btc. It's set by default
on evergreen/fusion, so it fine to just unconditionally enable it for
all chips.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Boqun Feng [Mon, 16 May 2011 08:02:39 +0000 (16:02 +0800)]
drm/i915: fix user irq miss in BSD ring on g4x
BugLink: http://bugs.launchpad.net/bugs/793702
commit
5bfa1063a775836a84f97e4df863fc36e1f856ad upstream.
On g4x, user interrupt in BSD ring is missed.
This is because though g4x and ironlake share the same bsd_ring,
their interrupt control interfaces have _two_ differences.
1.different irq enable/disable functions:
On g4x are i915_enable_irq and i915_disable_irq.
On ironlake are ironlake_enable_irq and ironlake_disable_irq.
2.different irq flag:
On g4x user interrupt flag in BSD ring on is I915_BSD_USER_INTERRUPT.
On ironlake is GT_BSD_USER_INTERRUPT
Old bsd_ring_get/put_irq call ring_get_irq and ring_get_irq.
ring_get_irq and ring_put_irq only call ironlake_enable/disable_irq.
So comes the irq miss on g4x.
To fix this, as other rings' code do, conditionally call different
functions(i915_enable/disable_irq and ironlake_enable/disable_irq)
and use different interrupt flags in bsd_ring_get/put_irq.
Signed-off-by: Boqun Feng <boqun.feng@intel.com>
Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
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>
Namhyung Kim [Thu, 26 May 2011 19:06:50 +0000 (21:06 +0200)]
brd: handle on-demand devices correctly
BugLink: http://bugs.launchpad.net/bugs/793702
commit
af46566885a373b0a526932484cd8fef8de7b598 upstream.
When finding or allocating a ram disk device, brd_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example (I set CONFIG_BLK_DEV_RAM_COUNT=4
for simplicity) :
$ sudo modprobe brd max_part=15
$ ls -l /dev/ram*
brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0
brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
$ sudo mknod /dev/ram4 b 1 64
$ sudo dd if=/dev/zero of=/dev/ram4 bs=4k count=256
256+0 records in
256+0 records out
1048576 bytes (1.0 MB) copied, 0.
00215578 s, 486 MB/s
namhyung@leonhard:linux$ ls -l /dev/ram*
brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0
brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
brw-r--r-- 1 root root 1, 64 2011-05-25 15:45 /dev/ram4
brw-rw---- 1 root disk 1, 1024 2011-05-25 15:44 /dev/ram64
After this patch, /dev/ram4 - instead of /dev/ram64 - was
accessed correctly.
In addition, 'range' passed to blk_register_region() should
include all range of dev_t that RAMDISK_MAJOR can address.
It does not need to be limited by partition numbers unless
'rd_nr' param was specified.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
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>
Namhyung Kim [Thu, 26 May 2011 19:06:50 +0000 (21:06 +0200)]
brd: limit 'max_part' module param to DISK_MAX_PARTS
BugLink: http://bugs.launchpad.net/bugs/793702
commit
315980c8688c4b06713c1a5fe9d64cdf8ab57a72 upstream.
The 'max_part' parameter controls the number of maximum partition
a brd device can have. However if a user specifies very large
value it would exceed the limitation of device minor number and
can cause a kernel panic (or, at least, produce invalid device
nodes in some cases).
On my desktop system, following command kills the kernel. On qemu,
it triggers similar oops but the kernel was alive:
$ sudo modprobe brd max_part=100000
BUG: unable to handle kernel NULL pointer dereference at
0000000000000058
IP: [<
ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
PGD 7af1067 PUD 7b19067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file:
CPU 0
Modules linked in: brd(+)
Pid: 44, comm: insmod Tainted: G W 2.6.39-qemu+ #158 Bochs Bochs
RIP: 0010:[<
ffffffff81110a9a>] [<
ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
RSP: 0018:
ffff880007b15d78 EFLAGS:
00000286
RAX:
ffff880007b05478 RBX:
ffff880007a52760 RCX:
ffff880007b15dc8
RDX:
ffff880007a4f900 RSI:
ffff880007b15e48 RDI:
ffff880007a52760
RBP:
ffff880007b15da8 R08:
0000000000000002 R09:
0000000000000000
R10:
ffff880007b15e48 R11:
ffff880007b05478 R12:
0000000000000000
R13:
ffff880007b05478 R14:
0000000000400920 R15:
0000000000000063
FS:
0000000002160880(0063) GS:
ffff880007c00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000058 CR3:
0000000007b1c000 CR4:
00000000000006b0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
0000000000000000 DR7:
0000000000000000
Process insmod (pid: 44, threadinfo
ffff880007b14000, task
ffff880007acb980)
Stack:
ffff880007b15dc8 ffff880007b05478 ffff880007b15da8 00000000fffffffe
ffff880007a52760 ffff880007b05478 ffff880007b15de8 ffffffff81143c0a
0000000000400920 ffff880007a52760 ffff880007b05478 0000000000000000
Call Trace:
[<
ffffffff81143c0a>] kobject_add_internal+0xdf/0x1a0
[<
ffffffff81143da1>] kobject_add_varg+0x41/0x50
[<
ffffffff81143e6b>] kobject_add+0x64/0x66
[<
ffffffff8113bbe7>] blk_register_queue+0x5f/0xb8
[<
ffffffff81140f72>] add_disk+0xdf/0x289
[<
ffffffffa00040df>] brd_init+0xdf/0x1aa [brd]
[<
ffffffffa0004000>] ? 0xffffffffa0003fff
[<
ffffffffa0004000>] ? 0xffffffffa0003fff
[<
ffffffff8100020a>] do_one_initcall+0x7a/0x12e
[<
ffffffff8108516c>] sys_init_module+0x9c/0x1dc
[<
ffffffff812ff4bb>] system_call_fastpath+0x16/0x1b
Code: 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 75 04 0f 0b eb fe 48 8b 47 18 49 c7 c4 70 1e 4d 81 48 85 c0 74 04 4c 8b 60 30
8b 44 24 58 45 31 ed 0f b6 c4 85 c0 74 0d 48 8b 43 28 48 89
RIP [<
ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
RSP <
ffff880007b15d78>
CR2:
0000000000000058
---[ end trace
aebb1175ce1f6739 ]---
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
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>
projects / linux-flexiantxendom0-natty.git / log