01 Apr, 2014
19 commits
-
commit 4c235cb9e35407bdb4a2debeef4dc8721e8f91f2 upstream.
Commit 65939301acdb (arm: set initrd_start/initrd_end for fdt scan)
caused the FDT initrd_start and initrd_end to override the
phys_initrd_start and phys_initrd_size set by the initrd= kernel
parameter. With this patch initrd_start and initrd_end will be
overridden if phys_initrd_start and phys_initrd_size are set by the
kernel initrd= parameter.Fixes: 65939301acdb (arm: set initrd_start/initrd_end for fdt scan)
Signed-off-by: Ben Peddell
Acked-by: Jason Cooper
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit d9317aea16ecec7694271ef11fb7791a0f0d9cc5 upstream.
As part of a workaround for a hardware erratum in the SFC9100 family
(SF bug 35388), the TX_DESC_UPD_DWORD register address is also used
for communicating with the event block, and only descriptor pointer
values < 2048 are valid.If the TX DMA ring size is increased to 4096 descriptors (which the
firmware still allows) then we may write a descriptor pointer
value >= 2048, which has entirely different and undesirable effects!Limit the TX DMA ring size correctly when this workaround is in
effect.Fixes: 8127d661e77f ('sfc: Add support for Solarflare SFC9100 family')
Signed-off-by: Ben Hutchings
Signed-off-by: Shradha Shah
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 177c53d943368fc97644ebc0a250dc8e2d124250 upstream.
We must use smp_call_function_single(.wait=1) for the
irq_cpu_stop_queue_work() to ensure the queueing is actually done under
stop_cpus_lock. Without this we could have dropped the lock by the time
we do the queueing and get the race we tried to fix.Fixes: 7053ea1a34fa ("stop_machine: Fix race between stop_two_cpus() and stop_cpus()")
Signed-off-by: Peter Zijlstra
Cc: Prarit Bhargava
Cc: Rik van Riel
Cc: Mel Gorman
Cc: Christoph Hellwig
Cc: Andrew Morton
Link: http://lkml.kernel.org/r/20140228123905.GK3104@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit e126a646f77fdd66978785cb0a3a5e46b07aee2e upstream.
The REVISION_ID register is not currently marked readable. snd_soc_read()
refuses to read the register, and hence probe() fails.Fixes: d4807ad2c4c0 ("regmap: Check readable regs in _regmap_read")
[exposed the bug, by checking for readability]
Fixes: 685e42154dcf ("ASoC: Replace max98090 Device Driver")
[left out this register from the readable list]
Signed-off-by: Stephen Warren
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 9a1ea2dbff11547a8e664f143c1ffefc586a577a upstream.
With the current full handling, there is a race between osds and
clients getting the first map marked full. If the osd wins, it will
return -ENOSPC to any writes, but the client may already have writes
in flight. This results in the client getting the error and
propagating it up the stack. For rbd, the block layer turns this into
EIO, which can cause corruption in filesystems above it.To avoid this race, osds are being changed to drop writes that came
from clients with an osdmap older than the last osdmap marked full.
In order for this to work, clients must resend all writes after they
encounter a full -> not full transition in the osdmap. osds will wait
for an updated map instead of processing a request from a client with
a newer map, so resent writes will not be dropped by the osd unless
there is another not full -> full transition.This approach requires both osds and clients to be fixed to avoid the
race. Old clients talking to osds with this fix may hang instead of
returning EIO and potentially corrupting an fs. New clients talking to
old osds have the same behavior as before if they encounter this race.Fixes: http://tracker.ceph.com/issues/6938
Reviewed-by: Sage Weil
Signed-off-by: Josh Durgin
Signed-off-by: Greg Kroah-Hartman -
commit d29adb34a94715174c88ca93e8aba955850c9bde upstream.
The PAUSEWR and PAUSERD flags are meant to stop the cluster from
processing writes and reads, respectively. The FULL flag is set when
the cluster determines that it is out of space, and will no longer
process writes. PAUSEWR and PAUSERD are purely client-side settings
already implemented in userspace clients. The osd does nothing special
with these flags.When the FULL flag is set, however, the osd responds to all writes
with -ENOSPC. For cephfs, this makes sense, but for rbd the block
layer translates this into EIO. If a cluster goes from full to
non-full quickly, a filesystem on top of rbd will not behave well,
since some writes succeed while others get EIO.Fix this by blocking any writes when the FULL flag is set in the osd
client. This is the same strategy used by userspace, so apply it by
default. A follow-on patch makes this configurable.__map_request() is called to re-target osd requests in case the
available osds changed. Add a paused field to a ceph_osd_request, and
set it whenever an appropriate osd map flag is set. Avoid queueing
paused requests in __map_request(), but force them to be resent if
they become unpaused.Also subscribe to the next osd map from the monitor if any of these
flags are set, so paused requests can be unblocked as soon as
possible.Fixes: http://tracker.ceph.com/issues/6079
Reviewed-by: Sage Weil
Signed-off-by: Josh Durgin
Signed-off-by: Greg Kroah-Hartman -
commit e351bf25fa373a3de0be2141b962c5c3c27006a2 upstream.
It upsets static checkers when we don't check for allocation failure. I
moved the memset() of "tv" earlier so we don't use uninitialized data on
error.
Fixes: 1d212cf0c2d8 ('[media] cx18: struct i2c_client is too big for stack')Signed-off-by: Dan Carpenter
Acked-by: Andy Walls
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 324ed533bf0b23c309b805272c4ffcc5d51493a6 upstream.
We recently introduced some new error paths but the unlocks are missing.
Fixes: 0065a79a8698 ('[media] dw2102: Don't use dynamic static allocation')Signed-off-by: Dan Carpenter
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 1cdbcc5db4e6d51ce9bb1313195167cada9aa6e9 upstream.
We recently introduced some new error paths which are missing their
unlocks.
Fixes: 64f7ef8afbf8 ('[media] cxusb: Don't use dynamic static allocation')Signed-off-by: Dan Carpenter
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 292f503cade2b1d966239ef56a851e6897d1ba92 upstream.
We need to use the same net namespace that was used to resolve
the hostname and sockaddr arguments.Fixes: 32e62b7c3ef09 (NFS: Add nfs4_update_server)
Cc: Chuck Lever
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 33b7107f59a61236d94ecd6b45e20283cd5abcc8 upstream.
In commit 6892b41d9701283085b655c6086fb57a5d63fa47
Author: Lad, Prabhakar
Date: Tue Jun 25 21:24:51 2013 +0530
net: davinci: emac: Convert to devm_* apithe call of request_irq is replaced by devm_request_irq and the call
of free_irq is removed. But since interrupts are requested in
emac_dev_open, doing ifconfig up/down on the board requests the
interrupts again each time, causing devm_request_irq to fail. The
interface is dead until the device is rebooted.This patch reverts said commit partially: It changes the driver back
to use request_irq instead of devm_request_irq, puts free_irq back in
place, but keeps the remaining changes of the original patch.Reported-by: Jon Ringle
Signed-off-by: Christian Riesch
Cc: Lad, Prabhakar
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit a2fb4d782c61f77480e586578eeb4dfd27d134ea upstream.
STI console is used on parisc and m68k HP machines. This patch partly reverts
my previous commit and as such restores the fonts for the m68k machines.Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit 87291347c49dc40aa339f587b209618201c2e527 upstream.
In event format strings, the array size is reported in two locations.
One in array subscript and then via the "size:" attribute. The values
reported there have a mismatch.For e.g., in sched:sched_switch the prev_comm and next_comm character
arrays have subscript values as [32] where as the actual field size is
16.name: sched_switch
ID: 301
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1;signed:0;
field:int common_pid; offset:4; size:4; signed:1;field:char prev_comm[32]; offset:8; size:16; signed:1;
field:pid_t prev_pid; offset:24; size:4; signed:1;
field:int prev_prio; offset:28; size:4; signed:1;
field:long prev_state; offset:32; size:8; signed:1;
field:char next_comm[32]; offset:40; size:16; signed:1;
field:pid_t next_pid; offset:56; size:4; signed:1;
field:int next_prio; offset:60; size:4; signed:1;After bisection, the following commit was blamed:
92edca0 tracing: Use direct field, type and system namesThis commit removes the duplication of strings for field->name and
field->type assuming that all the strings passed in
__trace_define_field() are immutable. This is not true for arrays, where
the type string is created in event_storage variable and field->type for
all array fields points to event_storage.Use __stringify() to create a string constant for the type string.
Also, get rid of event_storage and event_storage_mutex that are not
needed anymore.also, an added benefit is that this reduces the overhead of events a bit more:
text data bss dec hex filename
8424787 2036472 1302528 11763787 b3804b vmlinux
8420814 2036408 1302528 11759750 b37086 vmlinux.patchedLink: http://lkml.kernel.org/r/1392349908-29685-1-git-send-email-vnagarnaik@google.com
Cc: Laurent Chavey
Signed-off-by: Vaibhav Nagarnaik
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit 0f4706d2740f2a221cd502922b22e522009041d9 upstream.
We have reports of heavy screen corruption if we try to use the stolen
memory reserved by the BIOS whilst the DMA-Remapper is active. This
quirk may be only specific to a few machines or BIOSes, but first lets
apply the big hammer and always disable use of stolen memory when DMAR
is active.v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 5c673b60a9b3b23486f4eda75c72e91d31d26a2b upstream.
We need to enable interrupt processing before all the modeset
state is set up. But that means we can fall over when we get a pipe
underrun. This shouldn't happen as long as the bios works correctly
but as usual this turns out to be wishful thinking.So disable error interrupts at irq install time and rely on the
re-enabling code in the modeset functions to take care of this.Note that due to the SDE interrupt handling race we must
uncondtionally enable all interrupt sources in SDEIER, hence no need
to enable the SERR bit specifically.On gmch platforms we don't have an explicit enable/mask bit for fifo
underruns. Fixing this up would require a bit of software tracking,
hence is material for a separate patch. To make this possible we need
to switch all gmch platforms to the new pipestat interrupt handling
scheme Imre implemented for vlv, and then also add a safe form of sw
state checking to __cpu_fifo_underrun_reporting_enabled a bit.v2: Also handle the ilk/snb cpu fifo underrun bits accordingly.
Spotted by Ville.v3: Also handle the south interrupt underrun bits on ibx. Again
spotted by Ville.Reported-by: Rob Clark
Cc: Rob Clark
Cc: Ville Syrjälä
Tested-by: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 24bd9bf54d45d28089251cdf62bf14323d1aa827 upstream.
| has a higher precedence than ?. Therefore, the calculation doesn't do
at all what you would expect. Thanks to Ken for convincing me that this
was indeed the issue. Send me back to C programmer school, please.I'm sort of surprised PSR was continuing to work for people. It should
be broken IMO (and it was broken for me, but I had assumed it never
worked).Regression from:
commit ed8546ac1f99b850879f07b1e9b06b42fb0a36d9
Author: Ben Widawsky
Date: Mon Nov 4 22:45:05 2013 -0800drm/i915/bdw: Support eDP PSR
Cc: Rodrigo Vivi
Cc: Kenneth Graunke
Cc: Art Runyan
Reported-by: "Kumar, Kiran S"
Signed-off-by: Ben Widawsky
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 224aa3ed45c8735ae02bb2ecca002409fa6aa772 upstream.
Vybrids PIT register is monitonic decreasing. However, sched_clock
reading needs to be monitonic increasing. Use bitwise not to get
the complement of the clock register. This fixes the clock going
backward. Also, the clock now starts at 0 since we load the
register with the maximum value at start.Signed-off-by: Stefan Agner
Acked-by: Shawn Guo
Cc: daniel.lezcano@linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux@arm.linux.org.uk
Link: http://lkml.kernel.org/r/d25af915993aec1b486be653eb86f748ddef54fe.1394057313.git.stefan@agner.ch
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 749d32237bf39e6576dd95bfdf24e4378e51716c upstream.
The snd_compr_open function would always return 0 even if the compressed
ops open function failed, obviously this is incorrect. Looks like this
was introduced by a small typo in:commit a0830dbd4e42b38aefdf3fb61ba5019a1a99ea85
ALSA: Add a reference counter to card instanceThis patch returns the value from the compressed op as it should.
Signed-off-by: Charles Keepax
Acked-by: Vinod Koul
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 47587fc098451c2100dc1fb618855fc2e2d937af upstream.
I noticed that after hot unplugging a Logitech unifying receiver
(drivers/hid/hid-logitech-dj.c) the kernel would occasionally spew a
stack trace similar to this:usb 1-1.1.2: USB disconnect, device number 7
WARNING: CPU: 0 PID: 2865 at fs/sysfs/group.c:216 device_del+0x40/0x1b0()
sysfs group ffffffff8187fa20 not found for kobject 'hidraw0'
[...]
CPU: 0 PID: 2865 Comm: upowerd Tainted: G W 3.14.0-rc4 #7
Hardware name: LENOVO 7783PN4/ , BIOS 9HKT43AUS 07/11/2011
0000000000000009 ffffffff814cd684 ffff880427ccfdf8 ffffffff810616e7
ffff88041ec61800 ffff880427ccfe48 ffff88041e444d80 ffff880426fab8e8
ffff880429359960 ffffffff8106174c ffffffff81714b98 0000000000000028
Call Trace:
[] ? dump_stack+0x41/0x51
[] ? warn_slowpath_common+0x77/0x90
[] ? warn_slowpath_fmt+0x4c/0x50
[] ? device_del+0x40/0x1b0
[] ? device_unregister+0x2f/0x50
[] ? device_destroy+0x3a/0x40
[] ? drop_ref+0x55/0x120 [hid]
[] ? hidraw_release+0x96/0xb0 [hid]
[] ? __fput+0xca/0x210
[] ? task_work_run+0x97/0xd0
[] ? do_notify_resume+0x69/0xa0
[] ? int_signal+0x12/0x17
---[ end trace 63f4a46f6566d737 ]---During device removal hid_disconnect() is called via hid_hw_stop() to
stop the device and free all its resources, including the sysfs
files. The problem is that if a user space process, such as upowerd,
holds a reference to a hidraw file the corresponding sysfs files will
be kept around (drop_ref() does not call device_destroy() if the open
counter is not 0) and it will be usb_disconnect() who, by calling
device_del() for the USB device, will indirectly remove the sysfs
files of the hidraw device (sysfs_remove_dir() is recursive these
days). Because of this, by the time user space releases the last
reference to the hidraw file and drop_ref() tries to destroy the
device the sysfs files are already gone and the kernel will print
the warning above.Fix this by calling device_destroy() at USB disconnect time.
Signed-off-by: Fernando Luis Vazquez Cao
Reviewed-by: David Herrmann
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
24 Mar, 2014
21 commits
-
commit 89935315f192abf7068d0044cefc84f162c3c81f upstream.
Before commit b355cee88e3b (ACPI / resources: ignore invalid ACPI
device resources), if acpi_dev_resource_memory()/acpi_dev_resource_io()
returns false, it means the the resource is not a memeory/IO resource.But after commit b355cee88e3b, those functions return false if the
given memory/IO resource entry is invalid (the length of the resource
is zero).This breaks pnpacpi_allocated_resource(), because it now recognizes
the invalid memory/io resources as resources of unknown type. Thus
users see confusing warning messages on machines with zero length
ACPI memory/IO resources.Fix the problem by rearranging pnpacpi_allocated_resource() so that
it calls acpi_dev_resource_memory() for memory type and IO type
resources only, respectively.Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources)
Signed-off-by: Zhang Rui
Reported-and-tested-by: Markus Trippelsdorf
Reported-and-tested-by: Julian Wollrath
Reported-and-tested-by: Paul Bolle
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 4fb1a86fb5e4209a7d4426d4e586c58e9edc74ac upstream.
Sometimes the cleanup after memcg hierarchy testing gets stuck in
mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0.There may turn out to be several causes, but a major cause is this: the
workitem to offline parent can get run before workitem to offline child;
parent's mem_cgroup_reparent_charges() circles around waiting for the
child's pages to be reparented to its lrus, but it's holding
cgroup_mutex which prevents the child from reaching its
mem_cgroup_reparent_charges().Further testing showed that an ordered workqueue for cgroup_destroy_wq
is not always good enough: percpu_ref_kill_and_confirm's call_rcu_sched
stage on the way can mess up the order before reaching the workqueue.Instead, when offlining a memcg, call mem_cgroup_reparent_charges() on
all its children (and grandchildren, in the correct order) to have their
charges reparented first.Fixes: e5fca243abae ("cgroup: use a dedicated workqueue for cgroup destruction")
Signed-off-by: Filipe Brandenburger
Signed-off-by: Hugh Dickins
Reviewed-by: Tejun Heo
Acked-by: Michal Hocko
Cc: Johannes Weiner
Cc: [v3.10+]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 84fe6826c28f69d8708bd575faed7f75e6b6f57f upstream.
Page table entries on ARM64 are 64 bits, and some pte functions such as
pte_dirty return a bitwise-and of a flag with the pte value. If the
flag to be tested resides in the upper 32 bits of the pte, then we run
into the danger of the result being dropped if downcast.For example:
gather_stats(page, md, pte_dirty(*pte), 1);
where pte_dirty(*pte) is downcast to an int.This patch adds a double logical invert to all the pte_ accessors to
ensure predictable downcasting.Signed-off-by: Steve Capper
[steve.capper@linaro.org: rebased patch to leave pte_write alone to
allow for merge with 3.13 stable]
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit 5837c80e870bc3b12ac6a98cdc9ce7a9522a8fb6 upstream.
This patch addresses a bug in bio_integrity_verify() code that has
been causing DIF READ verify operations to be silently skipped.The issue is that bio->bi_idx will have been incremented within
bio_advance() code in the normal blk_update_request() ->
req_bio_endio() completion path, and bio_integrity_verify() is
using bio_for_each_segment() which starts the bio segment walk
at the current bio->bi_idx.So instead use bio_for_each_segment_all() to always start the bio
segment walk from zero, regardless of the current bio->bi_idx
value after bio_advance() has been called.(Context change for v3.10.y -> v3.13.y code - nab)
Cc: Martin K. Petersen
Cc: Jens Axboe
Cc: Christoph Hellwig
Signed-off-by: Nicholas Bellinger
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 87c99203fea897fbdd84b681ad9fced2517dcf98 upstream.
The file uses u16 type but doesn't include its definition explicitly
I was getting this error when including this header in my driver:
arch/mips/include/asm/mipsregs.h:644:33: error: unknown type name ‘u16’
Signed-off-by: Qais Yousef
Reviewed-by: Steven J. Hill
Acked-by: David Daney
Signed-off-by: John Crispin
Patchwork: http://patchwork.linux-mips.org/patch/6212/
Signed-off-by: Greg Kroah-Hartman -
commit d22e6338db7f613dd4f6095c190682fcc519e4b7 upstream.
Recent changes to retry on ESTALE in linkat
(commit 442e31ca5a49e398351b2954b51f578353fdf210)
introduced a mountpoint reference leak and a small memory
leak in case a filesystem link operation returns ESTALE
which is pretty normal for distributed filesystems like
lustre, nfs and so on.
Free old_path in such a case.[AV: there was another missing path_put() nearby - on the previous
goto retry]Signed-off-by: Oleg Drokin:
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit acc3d5cec84f82ebea535fa0bd9500ac3df2aee9 upstream.
Change "dummy supplies not allowed" error message to warning instead, as this
is a just warning message with no change to the behavior.[Added a CC to stable since some other bug fixes cause this to come up
more frequently on PCs which is how it was noticed -- broonie]Signed-off-by: Shuah Khan
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 1f91ecc14deea9461aca93273d78871ec4d98fcd upstream.
When selecting the audio output destinations (headphones,
FP headphones, multichannel output), the channel routing
should be changed depending on what destination selected.
Also unnecessary I2S channels are digitally muted. This
function called when the user selects the destination
in the ALSA mixer.Signed-off-by: Roman Volkov
Signed-off-by: Clemens Ladisch
Signed-off-by: Greg Kroah-Hartman -
commit 61d8d2abc15e9232c3914c55502b73e559366583 upstream.
A documentation update exposed the existance of the turbo ratio
register. Update baytrail support to use the turbo range.Signed-off-by: Dirk Brandewie
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 007bea098b869945a462420a1f9d442ff169f722 upstream.
Baytrail requires setting P state and voltage pairs when adjusting the
requested P state. Add function for retrieving the valid voltage
values and modify *_set_pstate() functions to caluclate the
appropriate voltage for the requested P state.Signed-off-by: Dirk Brandewie
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit c2412d91c68426e22add16550f97ae5cd988a159 upstream.
If audit is disabled, we shouldn't generate loginuid audit
log.Acked-by: Eric Paris
Signed-off-by: Gao feng
Signed-off-by: Richard Guy Briggs
Signed-off-by: Eric Paris
Signed-off-by: Greg Kroah-Hartman -
commit a2aa75e18a21b21952dc6daa9bac7c9f4426f81f upstream.
When using a mix of compressed file extents and prealloc extents, it
is possible to fill a page of a file with random, garbage data from
some unrelated previous use of the page, instead of a sequence of zeroes.A simple sequence of steps to get into such case, taken from the test
case I made for xfstests, is:_scratch_mkfs
_scratch_mount "-o compress-force=lzo"
$XFS_IO_PROG -f -c "pwrite -S 0x06 -b 18670 266978 18670" $SCRATCH_MNT/foobar
$XFS_IO_PROG -c "falloc 26450 665194" $SCRATCH_MNT/foobar
$XFS_IO_PROG -c "truncate 542872" $SCRATCH_MNT/foobar
$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobarThis results in the following file items in the fs tree:
item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160
inode generation 6 transid 6 size 542872 block group 0 mode 100600
item 5 key (257 INODE_REF 256) itemoff 15863 itemsize 16
inode ref index 2 namelen 6 name: foobar
item 6 key (257 EXTENT_DATA 0) itemoff 15810 itemsize 53
extent data disk byte 0 nr 0 gen 6
extent data offset 0 nr 24576 ram 266240
extent compression 0
item 7 key (257 EXTENT_DATA 24576) itemoff 15757 itemsize 53
prealloc data disk byte 12849152 nr 241664 gen 6
prealloc data offset 0 nr 241664
item 8 key (257 EXTENT_DATA 266240) itemoff 15704 itemsize 53
extent data disk byte 12845056 nr 4096 gen 6
extent data offset 0 nr 20480 ram 20480
extent compression 2
item 9 key (257 EXTENT_DATA 286720) itemoff 15651 itemsize 53
prealloc data disk byte 13090816 nr 405504 gen 6
prealloc data offset 0 nr 258048The on disk extent at offset 266240 (which corresponds to 1 single disk block),
contains 5 compressed chunks of file data. Each of the first 4 compress 4096
bytes of file data, while the last one only compresses 3024 bytes of file data.
Therefore a read into the file region [285648 ; 286720[ (length = 4096 - 3024 =
1072 bytes) should always return zeroes (our next extent is a prealloc one).The solution here is the compression code path to zero the remaining (untouched)
bytes of the last page it uncompressed data into, as the information about how
much space the file data consumes in the last page is not known in the upper layer
fs/btrfs/extent_io.c:__do_readpage(). In __do_readpage we were correctly zeroing
the remainder of the page but only if it corresponds to the last page of the inode
and if the inode's size is not a multiple of the page size.This would cause not only returning random data on reads, but also permanently
storing random data when updating parts of the region that should be zeroed.
For the example above, it means updating a single byte in the region [285648 ; 286720[
would store that byte correctly but also store random data on disk.A test case for xfstests follows soon.
Signed-off-by: Filipe David Borba Manana
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman -
commit 5de865eebb8330eee19c37b31fb6f315a09d4273 upstream.
While running the test btrfs/004 from xfstests in a loop, it failed
about 1 time out of 20 runs in my desktop. The failure happened in
the backref walking part of the test, and the test's error message was
like this:# btrfs/004 93s ... [failed, exit status 1] - output mismatch (see /home/fdmanana/git/hub/xfstests_2/results//btrfs/004.out.bad)
# --- tests/btrfs/004.out 2013-11-26 18:25:29.263333714 +0000
# +++ /home/fdmanana/git/hub/xfstests_2/results//btrfs/004.out.bad 2013-12-10 15:25:10.327518516 +0000
# @@ -1,3 +1,8 @@
# QA output created by 004
# *** test backref walking
# -*** done
# +unexpected output from
# + /home/fdmanana/git/hub/btrfs-progs/btrfs inspect-internal logical-resolve -P 141512704 /home/fdmanana/btrfs-tests/scratch_1
# +expected inum: 405, expected address: 454656, file: /home/fdmanana/btrfs-tests/scratch_1/snap1/p0/d6/d3d/d156/fce, got:
# +
...
(Run 'diff -u tests/btrfs/004.out /home/fdmanana/git/hub/xfstests_2/results//btrfs/004.out.bad' to see the entire diff)
Ran: btrfs/004
Failures: btrfs/004
Failed 1 of 1 testsBut immediately after the test finished, the btrfs inspect-internal command
returned the expected output:$ btrfs inspect-internal logical-resolve -P 141512704 /home/fdmanana/btrfs-tests/scratch_1
inode 405 offset 454656 root 258
inode 405 offset 454656 root 5It turned out this was because the btrfs_search_old_slot() calls performed
during backref walking (backref.c:__resolve_indirect_ref) were not finding
anything. The reason for this turned out to be that the tree mod logging
code was not logging some node multi-step operations atomically, therefore
btrfs_search_old_slot() callers iterated often over an incomplete tree that
wasn't fully consistent with any tree state from the past. Besides missing
items, this often (but not always) resulted in -EIO errors during old slot
searches, reported in dmesg like this:[ 4299.933936] ------------[ cut here ]------------
[ 4299.933949] WARNING: CPU: 0 PID: 23190 at fs/btrfs/ctree.c:1343 btrfs_search_old_slot+0x57b/0xab0 [btrfs]()
[ 4299.933950] Modules linked in: btrfs raid6_pq xor pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep rfcomm bluetooth parport_pc ppdev binfmt_misc joydev snd_hda_codec_h
[ 4299.933977] CPU: 0 PID: 23190 Comm: btrfs Tainted: G W O 3.12.0-fdm-btrfs-next-16+ #70
[ 4299.933978] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Pro4, BIOS P1.50 09/04/2012
[ 4299.933979] 000000000000053f ffff8806f3fd98f8 ffffffff8176d284 0000000000000007
[ 4299.933982] 0000000000000000 ffff8806f3fd9938 ffffffff8104a81c ffff880659c64b70
[ 4299.933984] ffff880659c643d0 ffff8806599233d8 ffff880701e2e938 0000160000000000
[ 4299.933987] Call Trace:
[ 4299.933991] [] dump_stack+0x55/0x76
[ 4299.933994] [] warn_slowpath_common+0x8c/0xc0
[ 4299.933997] [] warn_slowpath_null+0x1a/0x20
[ 4299.934003] [] btrfs_search_old_slot+0x57b/0xab0 [btrfs]
[ 4299.934005] [] ? _raw_read_unlock+0x2b/0x50
[ 4299.934010] [] ? __tree_mod_log_search+0x81/0xc0 [btrfs]
[ 4299.934019] [] __resolve_indirect_refs+0x130/0x5f0 [btrfs]
[ 4299.934027] [] ? free_extent_buffer+0x61/0xc0 [btrfs]
[ 4299.934034] [] find_parent_nodes+0x1fc/0xe40 [btrfs]
[ 4299.934042] [] ? defrag_lookup_extent+0xe0/0xe0 [btrfs]
[ 4299.934048] [] ? defrag_lookup_extent+0xe0/0xe0 [btrfs]
[ 4299.934056] [] iterate_extent_inodes+0xe0/0x250 [btrfs]
[ 4299.934058] [] ? _raw_spin_unlock+0x2b/0x50
[ 4299.934065] [] iterate_inodes_from_logical+0x92/0xb0 [btrfs]
[ 4299.934071] [] ? defrag_lookup_extent+0xe0/0xe0 [btrfs]
[ 4299.934078] [] btrfs_ioctl+0xf65/0x1f60 [btrfs]
[ 4299.934080] [] ? handle_mm_fault+0x278/0xb00
[ 4299.934083] [] ? up_read+0x23/0x40
[ 4299.934085] [] ? __do_page_fault+0x20c/0x5a0
[ 4299.934088] [] do_vfs_ioctl+0x96/0x570
[ 4299.934090] [] ? error_sti+0x5/0x6
[ 4299.934093] [] ? trace_hardirqs_off_caller+0x28/0xd0
[ 4299.934096] [] ? retint_swapgs+0xe/0x13
[ 4299.934098] [] SyS_ioctl+0x91/0xb0
[ 4299.934100] [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 4299.934102] [] system_call_fastpath+0x16/0x1b
[ 4299.934102] [] system_call_fastpath+0x16/0x1b
[ 4299.934104] ---[ end trace 48f0cfc902491414 ]---
[ 4299.934378] btrfs bad fsid on block 0These tree mod log operations that must be performed atomically, tree_mod_log_free_eb,
tree_mod_log_eb_copy, tree_mod_log_insert_root and tree_mod_log_insert_move, used to
be performed atomically before the following commit:c8cc6341653721b54760480b0d0d9b5f09b46741
(Btrfs: stop using GFP_ATOMIC for the tree mod log allocations)That change removed the atomicity of such operations. This patch restores the
atomicity while still not doing the GFP_ATOMIC allocations of tree_mod_elem
structures, so it has to do the allocations using GFP_NOFS before acquiring
the mod log lock.This issue has been experienced by several users recently, such as for example:
http://www.spinics.net/lists/linux-btrfs/msg28574.html
After running the btrfs/004 test for 679 consecutive iterations with this
patch applied, I didn't ran into the issue anymore.Signed-off-by: Filipe David Borba Manana
Signed-off-by: Josef Bacik
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman -
commit 783577663507411e36e459390ef056556e93ef29 upstream.
In ctree.c:tree_mod_log_set_node_key() we were calling
__tree_mod_log_insert_key() even when the modification doesn't need
to be logged. This would allocate a tree_mod_elem structure, fill it
and pass it to __tree_mod_log_insert(), which would just acquire
the tree mod log write lock and then free the tree_mod_elem structure
and return (that is, a no-op).Therefore call tree_mod_log_insert() instead of __tree_mod_log_insert()
which just returns immediately if the modification doesn't need to be
logged (without allocating the structure, fill it, acquire write lock,
free structure).Signed-off-by: Filipe David Borba Manana
Signed-off-by: Josef Bacik
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman -
commit 731bd6a93a6e9172094a2322bd0ee964bb1f4d63 upstream.
For non-eager fpu mode, thread's fpu state is allocated during the first
fpu usage (in the context of device not available exception). This
(math_state_restore()) can be a blocking call and hence we enable
interrupts (which were originally disabled when the exception happened),
allocate memory and disable interrupts etc.But the eager-fpu mode, call's the same math_state_restore() from
kernel_fpu_end(). The assumption being that tsk_used_math() is always
set for the eager-fpu mode and thus avoid the code path of enabling
interrupts, allocating fpu state using blocking call and disable
interrupts etc.But the below issue was noticed by Maarten Baert, Nate Eldredge and
few others:If a user process dumps core on an ecrypt fs while aesni-intel is loaded,
we get a BUG() in __find_get_block() complaining that it was called with
interrupts disabled; then all further accesses to our ecrypt fs hang
and we have to reboot.The aesni-intel code (encrypting the core file that we are writing) needs
the FPU and quite properly wraps its code in kernel_fpu_{begin,end}(),
the latter of which calls math_state_restore(). So after kernel_fpu_end(),
interrupts may be disabled, which nobody seems to expect, and they stay
that way until we eventually get to __find_get_block() which barfs.For eager fpu, most the time, tsk_used_math() is true. At few instances
during thread exit, signal return handling etc, tsk_used_math() might
be false.In kernel_fpu_end(), for eager-fpu, call math_state_restore()
only if tsk_used_math() is set. Otherwise, don't bother. Kernel code
path which cleared tsk_used_math() knows what needs to be done
with the fpu state.Reported-by: Maarten Baert
Reported-by: Nate Eldredge
Suggested-by: Linus Torvalds
Signed-off-by: Suresh Siddha
Link: http://lkml.kernel.org/r/1391410583.3801.6.camel@europa
Cc: George Spelvin
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit b12bb60d6c350b348a4e1460cd68f97ccae9822e upstream.
If the initialization of storvsc fails, the storvsc_device_destroy()
causes NULL pointer dereference.storvsc_bus_scan()
scsi_scan_target()
__scsi_scan_target()
scsi_probe_and_add_lun(hostdata=NULL)
scsi_alloc_sdev(hostdata=NULL)sdev->hostdata = hostdata
now the host allocation fails
__scsi_remove_device(sdev)
calls sdev->host->hostt->slave_destroy() ==
storvsc_device_destroy(sdev)
access of sdev->hostdata->request_mempoolSigned-off-by: Ales Novak
Signed-off-by: Thomas Abraham
Reviewed-by: Jiri Kosina
Acked-by: K. Y. Srinivasan
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit f324777ea88bab2522602671e46fc0851d7d5e35 upstream.
This fixes requesting of the MSI-X vectors for the base response queue.
The iteration in the for loop in qla24xx_enable_msix() was incorrect.
We should only iterate of the first two MSI-X vectors and not the total
number of MSI-X vectors that have given to the driver for this device
from pci_enable_msix() in this function.Signed-off-by: Chad Dupuis
Signed-off-by: Saurav Kashyap
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream.
Signed-off-by: Giridhar Malavali
Signed-off-by: Saurav Kashyap
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit c59053a23d586675c25d789a7494adfdc02fba57 upstream.
In the first place, the loop 'for' in the macro 'for_each_isci_host'
(drivers/scsi/isci/host.h:314) is incorrect, because it accesses
the 3rd element of 2 element array. After the 2nd iteration it executes
the instruction:
ihost = to_pci_info(pdev)->hosts[2]
(while the size of the 'hosts' array equals 2) and reads an
out of range element.In the second place, this loop is incorrectly optimized by GCC v4.8
(see http://marc.info/?l=linux-kernel&m=138998871911336&w=2).
As a result, on platforms with two SCU controllers,
the loop is executed more times than it can be (for i=0,1 and 2).
It causes kernel panic during entering the S3 state
and the following oops after 'rmmod isci':BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] __list_add+0x1b/0xc0
Oops: 0000 [#1] SMP
RIP: 0010:[] [] __list_add+0x1b/0xc0
Call Trace:
[] __mutex_lock_slowpath+0x114/0x1b0
[] mutex_lock+0x1f/0x30
[] sas_disable_events+0x1b/0x50 [libsas]
[] sas_unregister_ha+0x18/0x60 [libsas]
[] isci_unregister+0x1e/0x40 [isci]
[] isci_pci_remove+0x5d/0x100 [isci]
[] pci_device_remove+0x3b/0xb0
[] __device_release_driver+0x7f/0xf0
[] driver_detach+0xa8/0xb0
[] bus_remove_driver+0x9b/0x120
[] driver_unregister+0x2c/0x50
[] pci_unregister_driver+0x23/0x80
[] isci_exit+0x10/0x1e [isci]
[] SyS_delete_module+0x16b/0x2d0
[] ? do_notify_resume+0x61/0xa0
[] system_call_fastpath+0x16/0x1bThe loop has been corrected.
This patch fixes kernel panic during entering the S3 state
and the above oops.Signed-off-by: Lukasz Dorau
Reviewed-by: Maciej Patelczyk
Tested-by: Lukasz Dorau
Signed-off-by: Dan Williams
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream.
Remove an erroneous BUG_ON() in the case of a hard reset timeout. The
reset timeout handler puts the port into the "awaiting link-up" state.
The timeout causes the device to be disconnected and we need to be in
the awaiting link-up state to re-connect the port. The BUG_ON() made
the incorrect assumption that resets never timeout and we always
complete the reset in the "resetting" state.Testing this patch also uncovered that libata continues to attempt to
reset the port long after the driver has torn down the context. Once
the driver has committed to abandoning the link it must indicate to
libata that recovery ends by returning -ENODEV from
->lldd_I_T_nexus_reset().Acked-by: Lukasz Dorau
Reported-by: David Milburn
Reported-by: Xun Ni
Tested-by: Xun Ni
Signed-off-by: Dan Williams
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman
