Mel Gorman [Tue, 7 Jan 2014 14:00:47 +0000 (14:00 +0000)]
mm: numa: guarantee that tlb_flush_pending updates are visible before page table updates
commit
af2c1401e6f9177483be4fad876d0073669df9df upstream.
According to documentation on barriers, stores issued before a LOCK can
complete after the lock implying that it's possible tlb_flush_pending
can be visible after a page table update. As per revised documentation,
this patch adds a smp_mb__before_spinlock to guarantee the correct
ordering.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rik van Riel [Tue, 7 Jan 2014 14:00:46 +0000 (14:00 +0000)]
mm: fix TLB flush race between migration, and change_protection_range
commit
20841405940e7be0617612d521e206e4b6b325db upstream.
There are a few subtle races, between change_protection_range (used by
mprotect and change_prot_numa) on one side, and NUMA page migration and
compaction on the other side.
The basic race is that there is a time window between when the PTE gets
made non-present (PROT_NONE or NUMA), and the TLB is flushed.
During that time, a CPU may continue writing to the page.
This is fine most of the time, however compaction or the NUMA migration
code may come in, and migrate the page away.
When that happens, the CPU may continue writing, through the cached
translation, to what is no longer the current memory location of the
process.
This only affects x86, which has a somewhat optimistic pte_accessible.
All other architectures appear to be safe, and will either always flush,
or flush whenever there is a valid mapping, even with no permissions
(SPARC).
The basic race looks like this:
CPU A CPU B CPU C
load TLB entry
make entry PTE/PMD_NUMA
fault on entry
read/write old page
start migrating page
change PTE/PMD to new page
read/write old page [*]
flush TLB
reload TLB from new entry
read/write new page
lose data
[*] the old page may belong to a new user at this point!
The obvious fix is to flush remote TLB entries, by making sure that
pte_accessible aware of the fact that PROT_NONE and PROT_NUMA memory may
still be accessible if there is a TLB flush pending for the mm.
This should fix both NUMA migration and compaction.
[mgorman@suse.de: fix build]
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:45 +0000 (14:00 +0000)]
mm: numa: avoid unnecessary disruption of NUMA hinting during migration
commit
de466bd628e8d663fdf3f791bc8db318ee85c714 upstream.
do_huge_pmd_numa_page() handles the case where there is parallel THP
migration. However, by the time it is checked the NUMA hinting
information has already been disrupted. This patch adds an earlier
check with some helpers.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:44 +0000 (14:00 +0000)]
mm: numa: clear numa hinting information on mprotect
commit
1667918b6483b12a6496bf54151b827b8235d7b1 upstream.
On a protection change it is no longer clear if the page should be still
accessible. This patch clears the NUMA hinting fault bits on a
protection change.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:43 +0000 (14:00 +0000)]
sched: numa: skip inaccessible VMAs
commit
3c67f474558748b604e247d92b55dfe89654c81d upstream.
Inaccessible VMA should not be trapping NUMA hint faults. Skip them.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:42 +0000 (14:00 +0000)]
mm: numa: avoid unnecessary work on the failure path
commit
eb4489f69f224356193364dc2762aa009738ca7f upstream.
If a PMD changes during a THP migration then migration aborts but the
failure path is doing more work than is necessary.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:41 +0000 (14:00 +0000)]
mm: numa: ensure anon_vma is locked to prevent parallel THP splits
commit
c3a489cac38d43ea6dc4ac240473b44b46deecf7 upstream.
The anon_vma lock prevents parallel THP splits and any associated
complexity that arises when handling splits during THP migration. This
patch checks if the lock was successfully acquired and bails from THP
migration if it failed for any reason.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:40 +0000 (14:00 +0000)]
mm: numa: do not clear PTE for pte_numa update
commit
0c5f83c23ca703d32f930393825487257a5cde6d upstream.
The TLB must be flushed if the PTE is updated but change_pte_range is
clearing the PTE while marking PTEs pte_numa without necessarily
flushing the TLB if it reinserts the same entry. Without the flush,
it's conceivable that two processors have different TLBs for the same
virtual address and at the very least it would generate spurious faults.
This patch only unmaps the pages in change_pte_range for a full
protection change.
[riel@redhat.com: write pte_numa pte back to the page tables]
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Rik van Riel <riel@redhat.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Chegu Vinod <chegu_vinod@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:39 +0000 (14:00 +0000)]
mm: numa: do not clear PMD during PTE update scan
commit
5a6dac3ec5f583cc8ee7bc53b5500a207c4ca433 upstream.
If the PMD is flushed then a parallel fault in handle_mm_fault() will
enter the pmd_none and do_huge_pmd_anonymous_page() path where it'll
attempt to insert a huge zero page. This is wasteful so the patch
avoids clearing the PMD when setting pmd_numa.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:38 +0000 (14:00 +0000)]
mm: clear pmd_numa before invalidating
commit
67f87463d3a3362424efcbe8b40e4772fd34fc61 upstream.
On x86, PMD entries are similar to _PAGE_PROTNONE protection and are
handled as NUMA hinting faults. The following two page table protection
bits are what defines them
_PAGE_NUMA:set _PAGE_PRESENT:clear
A PMD is considered present if any of the _PAGE_PRESENT, _PAGE_PROTNONE,
_PAGE_PSE or _PAGE_NUMA bits are set. If pmdp_invalidate encounters a
pmd_numa, it clears the present bit leaving _PAGE_NUMA which will be
considered not present by the CPU but present by pmd_present. The
existing caller of pmdp_invalidate should handle it but it's an
inconsistent state for a PMD. This patch keeps the state consistent
when calling pmdp_invalidate.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:37 +0000 (14:00 +0000)]
mm: numa: call MMU notifiers on THP migration
commit
f714f4f20e59ea6eea264a86b9a51fd51b88fc54 upstream.
MMU notifiers must be called on THP page migration or secondary MMUs
will get very confused.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Tue, 7 Jan 2014 14:00:36 +0000 (14:00 +0000)]
mm: numa: serialise parallel get_user_page against THP migration
commit
2b4847e73004c10ae6666c2e27b5c5430aed8698 upstream.
Base pages are unmapped and flushed from cache and TLB during normal
page migration and replaced with a migration entry that causes any
parallel NUMA hinting fault or gup to block until migration completes.
THP does not unmap pages due to a lack of support for migration entries
at a PMD level. This allows races with get_user_pages and
get_user_pages_fast which commit
3f926ab945b6 ("mm: Close races between
THP migration and PMD numa clearing") made worse by introducing a
pmd_clear_flush().
This patch forces get_user_page (fast and normal) on a pmd_numa page to
go through the slow get_user_page path where it will serialise against
THP migration and properly account for the NUMA hinting fault. On the
migration side the page table lock is taken for each PTE update.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Alex Thorlton <athorlton@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rob Herring [Mon, 30 Dec 2013 01:37:43 +0000 (19:37 -0600)]
Revert "of/address: Handle #address-cells > 2 specially"
commit
13fcca8f25f4e9ce7f55da9cd353bb743236e212 upstream.
This reverts commit
e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7.
Nikita Yushchenko reports:
While trying to make freescale p2020ds and mpc8572ds boards working
with mainline kernel, I faced that commit
e38c0a1f (Handle
Both these boards have uli1575 chip.
Corresponding part in device tree is something like
uli1575@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
ranges = <0x2000000 0x0 0x80000000
0x2000000 0x0 0x80000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x10000>;
isa@1e {
...
I.e. it has #address-cells = <3>
With commit
e38c0a1f reverted, devices under uli1575 are registered
correctly, e.g. for rtc
OF: ** translation for device /pcie@
ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
OF: bus is isa (na=2, ns=1) on /pcie@
ffe09000/pcie@0/uli1575@0/isa@1e
OF: translating address:
00000001 00000070
OF: parent bus is default (na=3, ns=2) on /pcie@
ffe09000/pcie@0/uli1575@0
OF: walking ranges...
OF: ISA map, cp=0, s=1000, da=70
OF: parent translation for:
01000000 00000000 00000000
OF: with offset: 70
OF: one level translation:
00000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@
ffe09000/pcie@0
OF: walking ranges...
OF: default map, cp=
a0000000, s=
20000000, da=70
OF: default map, cp=0, s=10000, da=70
OF: parent translation for:
01000000 00000000 00000000
OF: with offset: 70
OF: one level translation:
01000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@
ffe09000
OF: walking ranges...
OF: PCI map, cp=0, s=10000, da=70
OF: parent translation for:
01000000 00000000 00000000
OF: with offset: 70
OF: one level translation:
01000000 00000000 00000070
OF: parent bus is default (na=2, ns=2) on /
OF: walking ranges...
OF: PCI map, cp=0, s=10000, da=70
OF: parent translation for:
00000000 ffc10000
OF: with offset: 70
OF: one level translation:
00000000 ffc10070
OF: reached root node
With commit
e38c0a1f in place, address translation fails:
OF: ** translation for device /pcie@
ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
OF: bus is isa (na=2, ns=1) on /pcie@
ffe09000/pcie@0/uli1575@0/isa@1e
OF: translating address:
00000001 00000070
OF: parent bus is default (na=3, ns=2) on /pcie@
ffe09000/pcie@0/uli1575@0
OF: walking ranges...
OF: ISA map, cp=0, s=1000, da=70
OF: parent translation for:
01000000 00000000 00000000
OF: with offset: 70
OF: one level translation:
00000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@
ffe09000/pcie@0
OF: walking ranges...
OF: default map, cp=
a0000000, s=
20000000, da=70
OF: default map, cp=0, s=10000, da=70
OF: not found !
Thierry Reding confirmed this commit was not needed after all:
"We ended up merging a different address representation for Tegra PCIe
and I've confirmed that reverting this commit doesn't cause any obvious
regressions. I think all other drivers in drivers/pci/host ended up
copying what we did on Tegra, so I wouldn't expect any other breakage
either."
There doesn't appear to be a simple way to support both behaviours, so
reverting this as nothing should be depending on the new behaviour.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Tue, 31 Dec 2013 12:37:46 +0000 (13:37 +0100)]
intel_pstate: Fail initialization if P-state information is missing
commit
98a947abdd54e5de909bebadfced1696ccad30cf upstream.
If pstate.current_pstate is 0 after the initial
intel_pstate_get_cpu_pstates(), this means that we were unable to
obtain any useful P-state information and there is no reason to
continue, so free memory and return an error in that case.
This fixes the following divide error occuring in a nested KVM
guest:
Intel P-state driver initializing.
Intel pstate controlling: cpu 0
cpufreq: __cpufreq_add_dev: ->get() failed
divide error: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-0.rc4.git5.1.fc21.x86_64 #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task:
ffff88001ea20000 ti:
ffff88001e9bc000 task.ti:
ffff88001e9bc000
RIP: 0010:[<
ffffffff815c551d>] [<
ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
RSP: 0000:
ffff88001ee03e18 EFLAGS:
00010246
RAX:
0000000000000000 RBX:
ffff88001a454348 RCX:
0000000000006100
RDX:
0000000000000000 RSI:
0000000000000000 RDI:
0000000000000000
RBP:
ffff88001ee03e38 R08:
0000000000000000 R09:
0000000000000000
R10:
ffff88001ea20000 R11:
0000000000000000 R12:
00000c0a1ea20000
R13:
1ea200001ea20000 R14:
ffffffff815c5400 R15:
ffff88001a454348
FS:
0000000000000000(0000) GS:
ffff88001ee00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000000000000000 CR3:
0000000001c0c000 CR4:
00000000000006f0
Stack:
fffffffb1a454390 ffffffff821a4500 ffff88001a454390 0000000000000100
ffff88001ee03ea8 ffffffff81083e9a ffffffff81083e15 ffffffff82d5ed40
ffffffff8258cc60 0000000000000000 ffffffff81ac39de 0000000000000000
Call Trace:
<IRQ>
[<
ffffffff81083e9a>] call_timer_fn+0x8a/0x310
[<
ffffffff81083e15>] ? call_timer_fn+0x5/0x310
[<
ffffffff815c5400>] ? pid_param_set+0x130/0x130
[<
ffffffff81084354>] run_timer_softirq+0x234/0x380
[<
ffffffff8107aee4>] __do_softirq+0x104/0x430
[<
ffffffff8107b5fd>] irq_exit+0xcd/0xe0
[<
ffffffff81770645>] smp_apic_timer_interrupt+0x45/0x60
[<
ffffffff8176efb2>] apic_timer_interrupt+0x72/0x80
<EOI>
[<
ffffffff810e15cd>] ? vprintk_emit+0x1dd/0x5e0
[<
ffffffff81757719>] printk+0x67/0x69
[<
ffffffff815c1493>] __cpufreq_add_dev.isra.13+0x883/0x8d0
[<
ffffffff815c14f0>] cpufreq_add_dev+0x10/0x20
[<
ffffffff814a14d1>] subsys_interface_register+0xb1/0xf0
[<
ffffffff815bf5cf>] cpufreq_register_driver+0x9f/0x210
[<
ffffffff81fb19af>] intel_pstate_init+0x27d/0x3be
[<
ffffffff81761e3e>] ? mutex_unlock+0xe/0x10
[<
ffffffff81fb1732>] ? cpufreq_gov_dbs_init+0x12/0x12
[<
ffffffff8100214a>] do_one_initcall+0xfa/0x1b0
[<
ffffffff8109dbf5>] ? parse_args+0x225/0x3f0
[<
ffffffff81f64193>] kernel_init_freeable+0x1fc/0x287
[<
ffffffff81f638d0>] ? do_early_param+0x88/0x88
[<
ffffffff8174b530>] ? rest_init+0x150/0x150
[<
ffffffff8174b53e>] kernel_init+0xe/0x130
[<
ffffffff8176e27c>] ret_from_fork+0x7c/0xb0
[<
ffffffff8174b530>] ? rest_init+0x150/0x150
Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 e0 08 48 99 <49> f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa 1f 89
RIP [<
ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
RSP <
ffff88001ee03e18>
---[ end trace
f166110ed22cc37a ]---
Kernel panic - not syncing: Fatal exception in interrupt
Reported-and-tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Toshi Kani [Wed, 27 Nov 2013 20:33:09 +0000 (13:33 -0700)]
ACPI / PCI / hotplug: Avoid warning when _ADR not present
commit
f26ca1d699e8b54a50d9faf82327d3c2072aaedd upstream.
acpiphp_enumerate_slots() walks ACPI namenamespace under
a PCI host bridge with callback register_slot().
register_slot() evaluates _ADR for all the device objects
and emits a warning message for any error. Some platforms
have _HID device objects (such as HPET and IPMI), which
trigger unnecessary warning messages.
This patch avoids emitting a warning message when a target
device object does not have _ADR.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Tue, 3 Dec 2013 10:20:06 +0000 (11:20 +0100)]
ext2: Fix oops in ext2_get_block() called from ext2_quota_write()
commit
df4e7ac0bb70abc97fbfd9ef09671fc084b3f9db upstream.
ext2_quota_write() doesn't properly setup bh it passes to
ext2_get_block() and thus we hit assertion BUG_ON(maxblocks == 0) in
ext2_get_blocks() (or we could actually ask for mapping arbitrary number
of blocks depending on whatever value was on stack).
Fix ext2_quota_write() to properly fill in number of blocks to map.
Reviewed-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reported-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Wed, 11 Dec 2013 23:13:10 +0000 (17:13 -0600)]
rtlwifi: pci: Fix oops on driver unload
commit
9278db6279e28d4d433bc8a848e10b4ece8793ed upstream.
On Fedora systems, unloading rtl8192ce causes an oops. This patch fixes the
problem reported at https://bugzilla.redhat.com/show_bug.cgi?id=852761.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Mon, 16 Dec 2013 11:04:36 +0000 (12:04 +0100)]
radiotap: fix bitmap-end-finding buffer overrun
commit
bd02cd2549cfcdfc57cb5ce57ffc3feb94f70575 upstream.
Evan Huus found (by fuzzing in wireshark) that the radiotap
iterator code can access beyond the length of the buffer if
the first bitmap claims an extension but then there's no
data at all. Fix this.
Reported-by: Evan Huus <eapache@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shirish Pargaonkar [Wed, 11 Dec 2013 22:29:53 +0000 (16:29 -0600)]
cifs: set FILE_CREATED
commit
f1e3268126a35b9d3cb8bf67487fcc6cd13991d8 upstream.
Set FILE_CREATED on O_CREAT|O_EXCL.
cifs code didn't change during commit
116cc0225381415b96551f725455d067f63a76a0
Kernel bugzilla 66251
Signed-off-by: Shirish Pargaonkar <spargaonkar@suse.com>
Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sachin Prabhu [Mon, 25 Nov 2013 17:09:48 +0000 (17:09 +0000)]
cifs: We do not drop reference to tlink in CIFSCheckMFSymlink()
commit
750b8de6c4277d7034061e1da50663aa1b0479e4 upstream.
When we obtain tcon from cifs_sb, we use cifs_sb_tlink() to first obtain
tlink which also grabs a reference to it. We do not drop this reference
to tlink once we are done with the call.
The patch fixes this issue by instead passing tcon as a parameter and
avoids having to obtain a reference to the tlink. A lookup for the tcon
is already made in the calling functions and this way we avoid having to
re-run the lookup. This is also consistent with the argument list for
other similar calls for M-F symlinks.
We should also return an ENOSYS when we do not find a protocol specific
function to lookup the MF Symlink data.
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Wed, 18 Dec 2013 12:07:32 +0000 (07:07 -0500)]
libata, freezer: avoid block device removal while system is frozen
commit
85fbd722ad0f5d64d1ad15888cd1eb2188bfb557 upstream.
Freezable kthreads and workqueues are fundamentally problematic in
that they effectively introduce a big kernel lock widely used in the
kernel and have already been the culprit of several deadlock
scenarios. This is the latest occurrence.
During resume, libata rescans all the ports and revalidates all
pre-existing devices. If it determines that a device has gone
missing, the device is removed from the system which involves
invalidating block device and flushing bdi while holding driver core
layer locks. Unfortunately, this can race with the rest of device
resume. Because freezable kthreads and workqueues are thawed after
device resume is complete and block device removal depends on
freezable workqueues and kthreads (e.g. bdi_wq, jbd2) to make
progress, this can lead to deadlock - block device removal can't
proceed because kthreads are frozen and kthreads can't be thawed
because device resume is blocked behind block device removal.
839a8e8660b6 ("writeback: replace custom worker pool implementation
with unbound workqueue") made this particular deadlock scenario more
visible but the underlying problem has always been there - the
original forker task and jbd2 are freezable too. In fact, this is
highly likely just one of many possible deadlock scenarios given that
freezer behaves as a big kernel lock and we don't have any debug
mechanism around it.
I believe the right thing to do is getting rid of freezable kthreads
and workqueues. This is something fundamentally broken. For now,
implement a funny workaround in libata - just avoid doing block device
hot[un]plug while the system is frozen. Kernel engineering at its
finest. :(
v2: Add EXPORT_SYMBOL_GPL(pm_freezing) for cases where libata is built
as a module.
v3: Comment updated and polling interval changed to 10ms as suggested
by Rafael.
v4: Add #ifdef CONFIG_FREEZER around the hack as pm_freezing is not
defined when FREEZER is not configured thus breaking build.
Reported by kbuild test robot.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Tomaž Šolc <tomaz.solc@tablix.org>
Reviewed-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=62801
Link: http://lkml.kernel.org/r/20131213174932.GA27070@htj.dyndns.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Carino [Tue, 17 Dec 2013 02:15:53 +0000 (18:15 -0800)]
libata: implement ATA_HORKAGE_NO_NCQ_TRIM and apply it to Micro M500 SSDs
commit
f78dea064c5f7de07de4912a6e5136dbc443d614 upstream.
Certain drives cannot handle queued TRIM commands properly, even
though support is indicated in the IDENTIFY DEVICE buffer. This patch
allows for disabling the commands for the affected drives and apply it
to the Micron/Crucial M500 SSDs which exhibit incorrect protocol
behavior when issued queued TRIM commands, which could lead to silent
data corruption.
tj: Merged two unnecessarily split patches and made minor edits
including shortening horkage name.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: http://lkml.kernel.org/g/1387246554-7311-1-git-send-email-marc.ceeeee@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robin H. Johnson [Mon, 16 Dec 2013 17:31:19 +0000 (09:31 -0800)]
libata: disable a disk via libata.force params
commit
b8bd6dc36186fe99afa7b73e9e2d9a98ad5c4865 upstream.
A user on StackExchange had a failing SSD that's soldered directly
onto the motherboard of his system. The BIOS does not give any option
to disable it at all, so he can't just hide it from the OS via the
BIOS.
The old IDE layer had hdX=noprobe override for situations like this,
but that was never ported to the libata layer.
This patch implements a disable flag for libata.force.
Example use:
libata.force=2.0:disable
[v2 of the patch, removed the nodisable flag per Tejun Heo]
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: http://unix.stackexchange.com/questions/102648/how-to-tell-linux-kernel-3-0-to-completely-ignore-a-failing-disk
Link: http://askubuntu.com/questions/352836/how-can-i-tell-linux-kernel-to-completely-ignore-a-disk-as-if-it-was-not-even-co
Link: http://superuser.com/questions/599333/how-to-disable-kernel-probing-for-drive
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michele Baldessari [Mon, 25 Nov 2013 19:00:14 +0000 (19:00 +0000)]
libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8
commit
87809942d3fa60bafb7a58d0bdb1c79e90a6821d upstream.
We've received multiple reports in Fedora via (BZ 907193)
that the Seagate Momentus SpinPoint M8 errors out when enabling AA:
[ 2.555905] ata2.00: failed to enable AA (error_mask=0x1)
[ 2.568482] ata2.00: failed to enable AA (error_mask=0x1)
Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk.
Reported-by: Nicholas <arealityfarbetween@googlemail.com>
Signed-off-by: Michele Baldessari <michele@acksyn.org>
Tested-by: Nicholas <arealityfarbetween@googlemail.com>
Acked-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Vasut [Mon, 25 Nov 2013 08:47:00 +0000 (09:47 +0100)]
ahci: imx: Explicitly clear IMX6Q_GPR13_SATA_MPLL_CLK_EN
commit
10becdb402af4fd4808a0491a726b96128c41076 upstream.
We must clear this IMX6Q_GPR13_SATA_MPLL_CLK_EN bit on i.MX6Q, otherwise
Linux will fail to find the attached drive on some boards.
This entire fix was:
Reported-by: Eric Nelson <eric.nelson@boundarydevices.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Richard Zhu <r65037@freescale.com>
Cc: Linux-IDE <linux-ide@vger.kernel.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilia Mirkin [Thu, 12 Dec 2013 03:19:01 +0000 (22:19 -0500)]
drm/nouveau: only runtime suspend by default in optimus configuration
commit
b25b4427e9dfba073cf9bc86603956ed395eb6e3 upstream.
The intent was to only enable it by default for optimus, e.g. see the
runtime_idle callback. The suspend callback may be called directly, e.g.
as a result of nouveau_crtc_set_config.
Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shuah Khan [Fri, 22 Nov 2013 17:54:28 +0000 (10:54 -0700)]
power_supply: Fix Oops from NULL pointer dereference from wakeup_source_activate
commit
80c6463e2fa3377febfc98a6672d92d07f3c26c1 upstream.
power_supply_register() calls device_init_wakeup() to register a wakeup
source before initializing dev_name. As a result, device_wakeup_enable()
end up registering wakeup source with a null name when
wakeup_source_register() gets called with dev_name(dev) which is null at
the time.
When kernel is booted with wakeup_source_activate enabled, it will panic
when the trace point code tries to dereference ws->name.
Fixed the problem by moving up the kobject_set_name() call prior to
accesses to dev_name(). Replaced kobject_set_name() with dev_set_name()
which is the right interface to be called from drivers. Fixed the call to
device_del() prior to device_add() in for wakeup_init_failed error
handling code.
Trace after the change:
bash-2143 [003] d... 132.280697: wakeup_source_activate: BAT1 state=0x20001
kworker/3:2-1169 [003] d... 132.281305: wakeup_source_deactivate: BAT1 state=0x30000
Oops message:
[ 819.769934] device: 'BAT1': device_add
[ 819.770078] PM: Adding info for No Bus:BAT1
[ 819.770235] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 819.770435] IP: [<
ffffffff813381c0>] skip_spaces+0x30/0x30
[ 819.770572] PGD
3efd90067 PUD
3eff61067 PMD 0
[ 819.770716] Oops: 0000 [#1] SMP
[ 819.770829] Modules linked in: arc4 iwldvm mac80211 x86_pkg_temp_thermal coretemp kvm_intel joydev i915 kvm uvcvideo ghash_clmulni_intel videobuf2_vmalloc aesni_intel videobuf2_memops videobuf2_core aes_x86_64 ablk_helper cryptd videodev iwlwifi lrw rfcomm gf128mul glue_helper bnep btusb media bluetooth parport_pc hid_generic ppdev snd_hda_codec_hdmi drm_kms_helper snd_hda_codec_realtek cfg80211 drm tpm_infineon samsung_laptop snd_hda_intel usbhid snd_hda_codec hid snd_hwdep snd_pcm microcode snd_page_alloc snd_timer psmouse i2c_algo_bit lpc_ich tpm_tis video wmi mac_hid serio_raw ext2 lp parport r8169 mii
[ 819.771802] CPU: 0 PID: 2167 Comm: bash Not tainted 3.12.0+ #25
[ 819.771876] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 900X3C/900X3D/900X4C/900X4D/SAMSUNG_NP1234567890, BIOS P03AAC 07/12/2012
[ 819.772022] task:
ffff88002e6ddcc0 ti:
ffff8804015ca000 task.ti:
ffff8804015ca000
[ 819.772119] RIP: 0010:[<
ffffffff813381c0>] [<
ffffffff813381c0>] skip_spaces+0x30/0x30
[ 819.772242] RSP: 0018:
ffff8804015cbc70 EFLAGS:
00010046
[ 819.772310] RAX:
0000000000000003 RBX:
ffff88040cfd6d40 RCX:
0000000000000018
[ 819.772397] RDX:
0000000000020001 RSI:
0000000000000000 RDI:
0000000000000000
[ 819.772484] RBP:
ffff8804015cbcc0 R08:
0000000000000000 R09:
ffff8803f0768d40
[ 819.772570] R10:
ffffea001033b800 R11:
0000000000000000 R12:
ffffffff81c519c0
[ 819.772656] R13:
0000000000020001 R14:
0000000000000000 R15:
0000000000020001
[ 819.772744] FS:
00007ff98309b740(0000) GS:
ffff88041f200000(0000) knlGS:
0000000000000000
[ 819.772845] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 819.772917] CR2:
0000000000000000 CR3:
00000003f59dc000 CR4:
00000000001407f0
[ 819.773001] Stack:
[ 819.773030]
ffffffff81114003 ffff8804015cbcb0 0000000000000000 0000000000000046
[ 819.773146]
ffff880409757a18 ffff8803f065a160 0000000000000000 0000000000020001
[ 819.773273]
0000000000000000 0000000000000000 ffff8804015cbce8 ffffffff8143e388
[ 819.773387] Call Trace:
[ 819.773434] [<
ffffffff81114003>] ? ftrace_raw_event_wakeup_source+0x43/0xe0
[ 819.773520] [<
ffffffff8143e388>] wakeup_source_report_event+0xb8/0xd0
[ 819.773595] [<
ffffffff8143e3cd>] __pm_stay_awake+0x2d/0x50
[ 819.773724] [<
ffffffff8153395c>] power_supply_changed+0x3c/0x90
[ 819.773795] [<
ffffffff8153407c>] power_supply_register+0x18c/0x250
[ 819.773869] [<
ffffffff813d8d18>] sysfs_add_battery+0x61/0x7b
[ 819.773935] [<
ffffffff813d8d69>] battery_notify+0x37/0x3f
[ 819.774001] [<
ffffffff816ccb7c>] notifier_call_chain+0x4c/0x70
[ 819.774071] [<
ffffffff81073ded>] __blocking_notifier_call_chain+0x4d/0x70
[ 819.774149] [<
ffffffff81073e26>] blocking_notifier_call_chain+0x16/0x20
[ 819.774227] [<
ffffffff8109397a>] pm_notifier_call_chain+0x1a/0x40
[ 819.774316] [<
ffffffff81095b66>] hibernate+0x66/0x1c0
[ 819.774407] [<
ffffffff81093931>] state_store+0x71/0xa0
[ 819.774507] [<
ffffffff81331d8f>] kobj_attr_store+0xf/0x20
[ 819.774613] [<
ffffffff811f8618>] sysfs_write_file+0x128/0x1c0
[ 819.774735] [<
ffffffff8118579d>] vfs_write+0xbd/0x1e0
[ 819.774841] [<
ffffffff811861d9>] SyS_write+0x49/0xa0
[ 819.774939] [<
ffffffff816d1052>] system_call_fastpath+0x16/0x1b
[ 819.775055] Code: 89 f8 48 89 e5 f6 82 c0 a6 84 81 20 74 15 0f 1f 44 00 00 48 83 c0 01 0f b6 10 f6 82 c0 a6 84 81 20 75 f0 5d c3 66 0f 1f 44 00 00 <80> 3f 00 55 48 89 e5 74 15 48 89 f8 0f 1f 40 00 48 83 c0 01 80
[ 819.775760] RIP [<
ffffffff813381c0>] skip_spaces+0x30/0x30
[ 819.775881] RSP <
ffff8804015cbc70>
[ 819.775949] CR2:
0000000000000000
[ 819.794175] ---[ end trace
c4ef25127039952e ]---
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Acked-by: Anton Vorontsov <anton@enomsg.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Boyer [Fri, 11 Oct 2013 12:45:51 +0000 (08:45 -0400)]
cpupower: Fix segfault due to incorrect getopt_long arugments
commit
f447ef4a56dee4b68a91460bcdfe06b5011085f2 upstream.
If a user calls 'cpupower set --perf-bias 15', the process will end with
a SIGSEGV in libc because cpupower-set passes a NULL optarg to the atoi
call. This is because the getopt_long structure currently has all of
the options as having an optional_argument when they really have a
required argument. We change the structure to use required_argument to
match the short options and it resolves the issue.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1000439
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Blanchard [Mon, 23 Dec 2013 01:19:51 +0000 (12:19 +1100)]
powerpc: Align p_end
commit
286e4f90a72c0b0621dde0294af6ed4b0baddabb upstream.
p_end is an 8 byte value embedded in the text section. This means it
is only 4 byte aligned when it should be 8 byte aligned. Fix this
by adding an explicit alignment.
This fixes an issue where POWER7 little endian builds with
CONFIG_RELOCATABLE=y fail to boot.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Neuling [Mon, 16 Dec 2013 04:12:43 +0000 (15:12 +1100)]
powerpc: Fix bad stack check in exception entry
commit
90ff5d688e61f49f23545ffab6228bd7e87e6dc7 upstream.
In EXCEPTION_PROLOG_COMMON() we check to see if the stack pointer (r1)
is valid when coming from the kernel. If it's not valid, we die but
with a nice oops message.
Currently we allocate a stack frame (subtract INT_FRAME_SIZE) before we
check to see if the stack pointer is negative. Unfortunately, this
won't detect a bad stack where r1 is less than INT_FRAME_SIZE.
This patch fixes the check to compare the modified r1 with
-INT_FRAME_SIZE. With this, bad kernel stack pointers (including NULL
pointers) are correctly detected again.
Kudos to Paulus for finding this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kiszka [Sun, 29 Dec 2013 01:29:30 +0000 (02:29 +0100)]
KVM: x86: Fix APIC map calculation after re-enabling
commit
e66d2ae7c67bd9ac982a3d1890564de7f7eabf4b upstream.
Update arch.apic_base before triggering recalculate_apic_map. Otherwise
the recalculation will work against the previous state of the APIC and
will fail to build the correct map when an APIC is hardware-enabled
again.
This fixes a regression of
1e08ec4a13.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kiszka [Sat, 28 Dec 2013 15:31:52 +0000 (16:31 +0100)]
KVM: nVMX: Unconditionally uninit the MMU on nested vmexit
commit
29bf08f12b2fd72b882da0d85b7385e4a438a297 upstream.
Three reasons for doing this: 1. arch.walk_mmu points to arch.mmu anyway
in case nested EPT wasn't in use. 2. this aligns VMX with SVM. But 3. is
most important: nested_cpu_has_ept(vmcs12) queries the VMCS page, and if
one guest VCPU manipulates the page of another VCPU in L2, we may be
fooled to skip over the nested_ept_uninit_mmu_context, leaving mmu in
nested state. That can crash the host later on if nested_ept_get_cr3 is
invoked while L1 already left vmxon and nested.current_vmcs12 became
NULL therefore.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathy Vanhoef [Thu, 28 Nov 2013 11:21:45 +0000 (12:21 +0100)]
ath9k_htc: properly set MAC address and BSSID mask
commit
657eb17d87852c42b55c4b06d5425baa08b2ddb3 upstream.
Pick the MAC address of the first virtual interface as the new hardware MAC
address. Set BSSID mask according to this MAC address. This fixes CVE-2013-4579.
Signed-off-by: Mathy Vanhoef <vanhoefm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sujith Manoharan [Mon, 16 Dec 2013 01:34:59 +0000 (07:04 +0530)]
ath9k: Fix interrupt handling for the AR9002 family
commit
73f0b56a1ff64e7fb6c3a62088804bab93bcedc2 upstream.
This patch adds a driver workaround for a HW issue.
A race condition in the HW results in missing interrupts,
which can be avoided by a read/write with the ISR register.
All chips in the AR9002 series are affected by this bug - AR9003
and above do not have this problem.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Korsgaard [Mon, 16 Dec 2013 10:35:35 +0000 (11:35 +0100)]
dm9601: work around tx fifo sync issue on dm962x
commit
4263c86dca5198da6bd3ad826d0b2304fbe25776 upstream.
Certain dm962x revisions contain an bug, where if a USB bulk transfer retry
(E.G. if bulk crc mismatch) happens right after a transfer with odd or
maxpacket length, the internal tx hardware fifo gets out of sync causing
the interface to stop working.
Work around it by adding up to 3 bytes of padding to ensure this situation
cannot trigger.
This workaround also means we never pass multiple-of-maxpacket size skb's
to usbnet, so the length adjustment to handle usbnet's padding of those can
be removed.
Reported-by: Joseph Chang <joseph_chang@davicom.com.tw>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Korsgaard [Mon, 16 Dec 2013 10:35:33 +0000 (11:35 +0100)]
dm9601: fix reception of full size ethernet frames on dm9620/dm9621a
commit
407900cfb54bdb2cfa228010b6697305f66b2948 upstream.
dm9620/dm9621a require room for 4 byte padding even in dm9601 (3 byte
header) mode.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ard Biesheuvel [Mon, 23 Dec 2013 17:49:30 +0000 (18:49 +0100)]
auxvec.h: account for AT_HWCAP2 in AT_VECTOR_SIZE_BASE
commit
f60900f2609e893c7f8d0bccc7ada4947dac4cd5 upstream.
Commit
2171364d1a92 ("powerpc: Add HWCAP2 aux entry") introduced a new
AT_ auxv entry type AT_HWCAP2 but failed to update AT_VECTOR_SIZE_BASE
accordingly.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes:
2171364d1a92 (powerpc: Add HWCAP2 aux entry)
Acked-by: Michael Neuling <michael@neuling.org>
Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Fri, 6 Dec 2013 20:07:32 +0000 (15:07 -0500)]
cgroup: fix cgroup_create() error handling path
commit
266ccd505e8acb98717819cef9d91d66c7b237cc upstream.
ae7f164a09 ("cgroup: move cgroup->subsys[] assignment to
online_css()") moved cgroup->subsys[] assignements later in
cgroup_create() but didn't update error handling path accordingly
leading to the following oops and leaking later css's after an
online_css() failure. The oops is from cgroup destruction path being
invoked on the partially constructed cgroup which is not ready to
handle empty slots in cgrp->subsys[] array.
BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
IP: [<
ffffffff810eeaa8>] cgroup_destroy_locked+0x118/0x2f0
PGD
a780a067 PUD
aadbe067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 6 PID: 7360 Comm: mkdir Not tainted 3.13.0-rc2+ #69
Hardware name:
task:
ffff8800b9dbec00 ti:
ffff8800a781a000 task.ti:
ffff8800a781a000
RIP: 0010:[<
ffffffff810eeaa8>] [<
ffffffff810eeaa8>] cgroup_destroy_locked+0x118/0x2f0
RSP: 0018:
ffff8800a781bd98 EFLAGS:
00010282
RAX:
ffff880586903878 RBX:
ffff880586903800 RCX:
ffff880586903820
RDX:
ffff880586903860 RSI:
ffff8800a781bdb0 RDI:
ffff880586903820
RBP:
ffff8800a781bde8 R08:
ffff88060e0b8048 R09:
ffffffff811d7bc1
R10:
000000000000008c R11:
0000000000000001 R12:
ffff8800a72286c0
R13:
0000000000000000 R14:
ffffffff81cf7a40 R15:
0000000000000001
FS:
00007f60ecda57a0(0000) GS:
ffff8806272c0000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000008 CR3:
00000000a7a03000 CR4:
00000000000007e0
Stack:
ffff880586903860 ffff880586903910 ffff8800a72286c0 ffff880586903820
ffffffff81cf7a40 ffff880586903800 ffff88060e0b8018 ffffffff81cf7a40
ffff8800b9dbec00 ffff8800b9dbf098 ffff8800a781bec8 ffffffff810ef5bf
Call Trace:
[<
ffffffff810ef5bf>] cgroup_mkdir+0x55f/0x5f0
[<
ffffffff811c90ae>] vfs_mkdir+0xee/0x140
[<
ffffffff811cb07e>] SyS_mkdirat+0x6e/0xf0
[<
ffffffff811c6a19>] SyS_mkdir+0x19/0x20
[<
ffffffff8169e569>] system_call_fastpath+0x16/0x1b
This patch moves reference bumping inside online_css() loop, clears
css_ar[] as css's are brought online successfully, and updates
err_destroy path so that either a css is fully online and destroyed by
cgroup_destroy_locked() or the error path frees it. This creates a
duplicate css free logic in the error path but it will be cleaned up
soon.
v2: Li pointed out that cgroup_destroy_locked() would do NULL-deref if
invoked with a cgroup which doesn't have all css's populated.
Update cgroup_destroy_locked() so that it skips NULL css's.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Reported-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nithin Sujir [Fri, 20 Dec 2013 01:44:11 +0000 (17:44 -0800)]
tg3: Expand 4g_overflow_test workaround to skb fragments of any size.
commit
375679104ab3ccfd18dcbd7ba503734fb9a2c63a upstream.
The current driver assumes that an skb fragment can only be upto jumbo
size. Presumably this was a fast-path optimization. This assumption is
no longer true as fragments can be upto 32k.
v2: Remove unnecessary parantheses per Eric Dumazet.
Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Li Wang [Wed, 13 Nov 2013 07:22:14 +0000 (15:22 +0800)]
ceph: Avoid data inconsistency due to d-cache aliasing in readpage()
commit
56f91aad69444d650237295f68c195b74d888d95 upstream.
If the length of data to be read in readpage() is exactly
PAGE_CACHE_SIZE, the original code does not flush d-cache
for data consistency after finishing reading. This patches fixes
this.
Signed-off-by: Li Wang <liwang@ubuntukylin.com>
Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Olšák [Mon, 23 Dec 2013 16:11:35 +0000 (17:11 +0100)]
drm/radeon: set correct pipe config for Hawaii in DCE
commit
35a905282b20e556cd09f348f9c2bc8a22ea26d5 upstream.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 23 Dec 2013 14:31:58 +0000 (09:31 -0500)]
drm/radeon: 0x9649 is SUMO2 not SUMO
commit
d00adcc8ae9e22eca9d8af5f66c59ad9a74c90ec upstream.
Fixes rendering corruption due to incorrect
gfx configuration.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=63599
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Olšák [Sun, 22 Dec 2013 01:18:01 +0000 (02:18 +0100)]
drm/radeon: expose render backend mask to the userspace
commit
439a1cfffe2c1a06e5a6394ccd5d18a8e89b15d3 upstream.
This will allow userspace to correctly program the PA_SC_RASTER_CONFIG
register, so it can be considered a fix.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Olšák [Sun, 22 Dec 2013 01:18:00 +0000 (02:18 +0100)]
drm/radeon: fix render backend setup for SI and CIK
commit
9fadb352ed73edd7801a280b552d33a6040c8721 upstream.
Only the render backends of the first shader engine were enabled. The others
were erroneously disabled. Enabling the other render backends improves
performance a lot.
Unigine Sanctuary on Bonaire:
Before: 15 fps
After: 90 fps
Judging from the fan noise, the GPU was also underclocked when the other
render backends were disabled, resulting in horrible performance. The fan is
a lot noisy under load now.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Fri, 20 Dec 2013 16:48:54 +0000 (17:48 +0100)]
drm/radeon: fix UVD 256MB check
commit
bae651dbd7ade3c5d6518f89599ae680a2fe2b85 upstream.
Otherwise the kernel might reject our decoding requests.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Tue, 17 Dec 2013 14:34:50 +0000 (14:34 +0000)]
drm/i915: Use the correct GMCH_CTRL register for Sandybridge+
commit
a885b3ccc74d8e38074e1c43a47c354c5ea0b01e upstream.
The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is in UEFI mode.
Note that the register is still marked as locked RO on Sandybridge, so
vgaarb is still dysfunctional.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paulo Zanoni [Fri, 6 Dec 2013 22:29:01 +0000 (20:29 -0200)]
drm/i915: change CRTC assertion on LCPLL disable
commit
96b4026878d9dac71bd4c3d6e05c7fbb16a3e0aa upstream.
Currently, PC8 is enabled at modeset_global_resources, which is called
after intel_modeset_update_state. Due to this, there's a small race
condition on the case where we start enabling PC8, then do a modeset
while PC8 is still being enabled. The racing condition triggers a WARN
because intel_modeset_update_state will mark the CRTC as enabled, then
the thread that's still enabling PC8 might look at the data structure
and think that PC8 is being enabled while a pipe is enabled. Despite
the WARN, this is not really a bug since we'll wait for the
PC8-enabling thread to finish when we call modeset_global_resources.
The spec says the CRTC cannot be enabled when we disable LCPLL, so we
had a check for crtc->base.enabled. If we change to crtc->active we
will still prevent disabling LCPLL while the CRTC is enabled, and we
will also prevent the WARN above.
This is a replacement for the previous patch named
"drm/i915: get/put PC8 when we get/put a CRTC"
Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
(cherry picked from commit
798183c54799fbe1e5a5bfabb3a8c0505ffd2149
from -next due to Dave's report.)
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Wed, 4 Dec 2013 11:37:09 +0000 (11:37 +0000)]
drm/i915: Fix erroneous dereference of batch_obj inside reset_status
commit
4db080f9e93411c3c41ec402244da28e2bbde835 upstream.
As the rings may be processed and their requests deallocated in a
different order to the natural retirement during a reset,
/* Whilst this request exists, batch_obj will be on the
* active_list, and so will hold the active reference. Only when this
* request is retired will the the batch_obj be moved onto the
* inactive_list and lose its active reference. Hence we do not need
* to explicitly hold another reference here.
*/
is violated, and the batch_obj may be dereferenced after it had been
freed on another ring. This can be simply avoided by processing the
status update prior to deallocating any requests.
Fixes regression (a possible OOPS following a GPU hang) from
commit
aa60c664e6df502578454621c3a9b1f087ff8d25
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Wed Jun 12 15:13:20 2013 +0300
drm/i915: find guilty batch buffer on ring resets
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Add the code comment Chris supplied.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 20 Dec 2013 00:41:46 +0000 (19:41 -0500)]
drm/radeon: fix asic gfx values for scrapper asics
commit
e2f6c88fb903e123edfd1106b0b8310d5117f774 upstream.
Fixes gfx corruption on certain TN/RL parts.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=60389
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 13 Dec 2013 14:05:49 +0000 (09:05 -0500)]
drm/radeon: check for 0 count in speaker allocation and SAD code
commit
b67ce39a30976171e7b96b30a94a0216ab89df97 upstream.
If there is no speaker allocation block or SAD block, bail
early.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=72283
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 9 Dec 2013 22:46:59 +0000 (17:46 -0500)]
drm/radeon/dpm: disable ss on Cayman
commit
c745fe611ca42295c9d91d8e305d27983e9132ef upstream.
Spread spectrum seems to cause hangs when dynamic clock
switching is enabled. Disable it for now. This does not
affect performance or the amount of power saved. Tracked
down by Martin Andersson.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69723
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Tue, 10 Dec 2013 12:20:59 +0000 (13:20 +0100)]
drm/i915: don't update the dri1 breadcrumb with modesetting
commit
6c719faca2aceca72f1bf5b1645c1734ed3e9447 upstream.
The update is horribly racy since it doesn't protect at all against
concurrent closing of the master fd. And it can't really since that
requires us to grab a mutex.
Instead of jumping through hoops and offloading this to a worker
thread just block this bit of code for the modesetting driver.
Note that the race is fairly easy to hit since we call the breadcrumb
function for any interrupt. So the vblank interrupt (which usually
keeps going for a bit) is enough. But even if we'd block this and only
update the breadcrumb for user interrupts from the CS we could hit
this race with kms/gem userspace: If a non-master is waiting somewhere
(and hence has interrupts enabled) and the master closes its fd
(probably due to crashing).
v2: Add a code comment to explain why fixing this for real isn't
really worth it. Also improve the commit message a bit.
v3: Fix the spelling in the comment.
Reported-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Thu, 5 Dec 2013 14:42:34 +0000 (15:42 +0100)]
drm/i915: Fix use-after-free in do_switch
commit
acc240d41ea1ab9c488a79219fb313b5b46265ae upstream.
So apparently under ridiculous amounts of memory pressure we can get
into trouble in do_switch when we try to move the old hw context
backing storage object onto the active lists.
With list debugging enabled that usually results in us chasing a
poisoned pointer - which means we've hit upon a vma that has been
removed from all lrus with list_del (and then deallocated, so it's a
real use-after free).
Ian Lister has done some great callchain chasing and noticed that we
can reenter do_switch:
i915_gem_do_execbuffer()
i915_switch_context()
do_switch()
from = ring->last_context;
i915_gem_object_pin()
i915_gem_object_bind_to_gtt()
ret = drm_mm_insert_node_in_range_generic();
// If the above call fails then it will try i915_gem_evict_something()
// If that fails it will call i915_gem_evict_everything() ...
i915_gem_evict_everything()
i915_gpu_idle()
i915_switch_context(DEFAULT_CONTEXT)
Like with everything else where the shrinker or eviction code can
invalidate pointers we need to reload relevant state.
Note that there's no need to recheck whether a context switch is still
required because:
- Doing a switch to the same context is harmless (besides wasting a
bit of energy).
- This can only happen with the default context. But since that one's
pinned we'll never call down into evict_everything under normal
circumstances. Note that there's a little driver bringup fun
involved namely that we could recourse into do_switch for the
initial switch. Atm we're fine since we assign the context pointer
only after the call to do_switch at driver load or resume time. And
in the gpu reset case we skip the entire setup sequence (which might
be a bug on its own, but definitely not this one here).
Cc'ing stable since apparently ChromeOS guys are seeing this in the
wild (and not just on artificial stress tests), see the reference.
Note that in upstream code doesn't calle evict_everything directly
from evict_something, that's an extension in this product branch. But
we can still hit upon this bug (and apparently we do, see the linked
backtraces). I've noticed this while trying to construct a testcase
for this bug and utterly failed to provoke it. It looks like we need
to driver the system squarly into the lowmem wall and provoke the
shrinker to evict the context object by doing the last-ditch
evict_everything call.
Aside: There's currently no means to get a badly-fragmenting hw
context object away from a bad spot in the upstream code. We should
fix this by at least adding some code to evict_something to handle hw
contexts.
References: https://code.google.com/p/chromium/issues/detail?id=248191
Reported-by: Ian Lister <ian.lister@intel.com>
Cc: Ian Lister <ian.lister@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Bloomfield, Jon <jon.bloomfield@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: Ian Lister <ian.lister@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Wed, 4 Dec 2013 14:52:06 +0000 (14:52 +0000)]
drm/i915: Hold mutex across i915_gem_release
commit
0d1430a3f4b7cfd8779b78740a4182321f3ca7f3 upstream.
Inorder to serialise the closing of the file descriptor and its
subsequent release of client requests with i915_gem_free_request(), we
need to hold the struct_mutex in i915_gem_release(). Failing to do so
has the potential to trigger an OOPS, later with a use-after-free.
Testcase: igt/gem_close_race
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70874
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71029
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Mon, 2 Dec 2013 09:08:06 +0000 (11:08 +0200)]
drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
commit
027476642811f8559cbe00ef6cc54db230e48a20 upstream.
Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the locks, but the init codepath
doesn't, so fix that.
Note: This slipped through since we only disable pipes if the
plane/pipe linking doesn't match. Which is only relevant on older
gen3 mobile machines, if the BIOS fails to set up our preferred
linking.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-and-reported-by: Paul Bolle <pebolle@tiscali.nl>
[danvet: Add note now that I could confirm my theory with the log
files Paul Bolle provided.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Wed, 11 Dec 2013 16:43:58 +0000 (11:43 -0500)]
drm/radeon: add missing display tiling setup for oland
commit
227ae10f17a5f2fd1307b7e582b603ef7bbb7e97 upstream.
Fixes improperly set up display params for 2D tiling on
oland.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Tue, 10 Dec 2013 16:57:37 +0000 (17:57 +0100)]
drm/radeon: fix typo in cik_copy_dma
commit
1b3abef830db98c11d7f916a483abaf2501f3323 upstream.
Otherwise we end up with a rather strange looking result.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 2 Dec 2013 23:15:51 +0000 (18:15 -0500)]
drm/radeon: Fix sideport problems on certain RS690 boards
commit
8333f0fe133be420ce3fcddfd568c3a559ab274e upstream.
Some RS690 boards with 64MB of sideport memory show up as
having 128MB sideport + 256MB of UMA. In this case,
just skip the sideport memory and use UMA. This fixes
rendering corruption and should improve performance.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=35457
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Mon, 9 Dec 2013 07:23:57 +0000 (23:23 -0800)]
drm/ttm: Fix accesses through vmas with only partial coverage
commit
d386735588c3e22129c2bc6eb64fc1d37a8f805c upstream.
VMAs covering a bo but that didn't start at the same address space offset as
the bo they were mapping were incorrectly generating SEGFAULT errors in
the fault handler.
Reported-by: Joseph Dolinak <kanilo2@yahoo.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafał Miłecki [Sat, 7 Dec 2013 12:22:42 +0000 (13:22 +0100)]
drm/edid: add quirk for BPC in Samsung NP700G7A-S01PL notebook
commit
49d45a31b71d7d9da74485922bdb63faf3dc9684 upstream.
This bug in EDID was exposed by:
commit
eccea7920cfb009c2fa40e9ecdce8c36f61cab66
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Mon Mar 26 15:12:54 2012 -0400
drm/radeon/kms: improve bpc handling (v2)
Which resulted in kind of regression in 3.5. This fixes
https://bugs.freedesktop.org/show_bug.cgi?id=70934
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Tue, 17 Dec 2013 18:09:32 +0000 (10:09 -0800)]
net_dma: mark broken
commit
77873803363c9e831fc1d1e6895c084279090c22 upstream.
net_dma can cause data to be copied to a stale mapping if a
copy-on-write fault occurs during dma. The application sees missing
data.
The following trace is triggered by modifying the kernel to WARN if it
ever triggers copy-on-write on a page that is undergoing dma:
WARNING: CPU: 24 PID: 2529 at lib/dma-debug.c:485 debug_dma_assert_idle+0xd2/0x120()
ioatdma 0000:00:04.0: DMA-API: cpu touching an active dma mapped page [pfn=0x16bcd9]
Modules linked in: iTCO_wdt iTCO_vendor_support ioatdma lpc_ich pcspkr dca
CPU: 24 PID: 2529 Comm: linbug Tainted: G W 3.13.0-rc1+ #353
00000000000001e5 ffff88016f45f688 ffffffff81751041 ffff88017ab0ef70
ffff88016f45f6d8 ffff88016f45f6c8 ffffffff8104ed9c ffffffff810f3646
ffff8801768f4840 0000000000000282 ffff88016f6cca10 00007fa2bb699349
Call Trace:
[<
ffffffff81751041>] dump_stack+0x46/0x58
[<
ffffffff8104ed9c>] warn_slowpath_common+0x8c/0xc0
[<
ffffffff810f3646>] ? ftrace_pid_func+0x26/0x30
[<
ffffffff8104ee86>] warn_slowpath_fmt+0x46/0x50
[<
ffffffff8139c062>] debug_dma_assert_idle+0xd2/0x120
[<
ffffffff81154a40>] do_wp_page+0xd0/0x790
[<
ffffffff811582ac>] handle_mm_fault+0x51c/0xde0
[<
ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
[<
ffffffff8175fc2c>] __do_page_fault+0x19c/0x530
[<
ffffffff8175c196>] ? _raw_spin_lock_bh+0x16/0x40
[<
ffffffff810f3539>] ? trace_clock_local+0x9/0x10
[<
ffffffff810fa1f4>] ? rb_reserve_next_event+0x64/0x310
[<
ffffffffa0014c00>] ? ioat2_dma_prep_memcpy_lock+0x60/0x130 [ioatdma]
[<
ffffffff8175ffce>] do_page_fault+0xe/0x10
[<
ffffffff8175c862>] page_fault+0x22/0x30
[<
ffffffff81643991>] ? __kfree_skb+0x51/0xd0
[<
ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
[<
ffffffff81388ea2>] ? memcpy_toiovec+0x52/0xa0
[<
ffffffff8164770f>] skb_copy_datagram_iovec+0x5f/0x2a0
[<
ffffffff8169d0f4>] tcp_rcv_established+0x674/0x7f0
[<
ffffffff816a68c5>] tcp_v4_do_rcv+0x2e5/0x4a0
[..]
---[ end trace
e30e3b01191b7617 ]---
Mapped at:
[<
ffffffff8139c169>] debug_dma_map_page+0xb9/0x160
[<
ffffffff8142bf47>] dma_async_memcpy_pg_to_pg+0x127/0x210
[<
ffffffff8142cce9>] dma_memcpy_pg_to_iovec+0x119/0x1f0
[<
ffffffff81669d3c>] dma_skb_copy_datagram_iovec+0x11c/0x2b0
[<
ffffffff8169d1ca>] tcp_rcv_established+0x74a/0x7f0:
...the problem is that the receive path falls back to cpu-copy in
several locations and this trace is just one of the areas. A few
options were considered to fix this:
1/ sync all dma whenever a cpu copy branch is taken
2/ modify the page fault handler to hold off while dma is in-flight
Option 1 adds yet more cpu overhead to an "offload" that struggles to compete
with cpu-copy. Option 2 adds checks for behavior that is already documented as
broken when using get_user_pages(). At a minimum a debug mode is warranted to
catch and flag these violations of the dma-api vs get_user_pages().
Thanks to David for his reproducer.
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
Reported-by: David Whipple <whipple@securedatainnovations.ch>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Richter [Sun, 15 Dec 2013 15:18:01 +0000 (16:18 +0100)]
firewire: sbp2: bring back WRITE SAME support
commit
ce027ed98fd176710fb14be9d6015697b62436f0 upstream.
Commit
54b2b50c20a6 "[SCSI] Disable WRITE SAME for RAID and virtual
host adapter drivers" disabled WRITE SAME support for all SBP-2 attached
targets. But as described in the changelog of commit
b0ea5f19d3d8
"firewire: sbp2: allow WRITE SAME and REPORT SUPPORTED OPERATION CODES",
it is not required to blacklist WRITE SAME.
Bring the feature back by reverting the sbp2.c hunk of commit
54b2b50c20a6.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kirill Tkhai [Wed, 27 Nov 2013 15:59:13 +0000 (19:59 +0400)]
sched/rt: Fix rq's cpupri leak while enqueue/dequeue child RT entities
commit
757dfcaa41844595964f1220f1d33182dae49976 upstream.
This patch touches the RT group scheduling case.
Functions inc_rt_prio_smp() and dec_rt_prio_smp() change (global) rq's
priority, while rt_rq passed to them may be not the top-level rt_rq.
This is wrong, because changing of priority on a child level does not
guarantee that the priority is the highest all over the rq. So, this
leak makes RT balancing unusable.
The short example: the task having the highest priority among all rq's
RT tasks (no one other task has the same priority) are waking on a
throttle rt_rq. The rq's cpupri is set to the task's priority
equivalent, but real rq->rt.highest_prio.curr is less.
The patch below fixes the problem.
Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
CC: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/49231385567953@web4m.yandex.ru
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukas Czerner [Wed, 30 Oct 2013 15:10:52 +0000 (11:10 -0400)]
ext4: fix FITRIM in no journal mode
commit
8f9ff189205a6817aee5a1f996f876541f86e07c upstream.
When using FITRIM ioctl on a file system without journal it will
only trim the block group once, no matter how many times you invoke
FITRIM ioctl and how many block you release from the block group.
It is because we only clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT in journal
callback. Fix this by clearing the bit in no journal mode as well.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Jorge Fábregas <jorge.fabregas@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Theodore Ts'o [Fri, 20 Dec 2013 14:29:35 +0000 (09:29 -0500)]
ext4: add explicit casts when masking cluster sizes
commit
f5a44db5d2d677dfbf12deee461f85e9ec633961 upstream.
The missing casts can cause the high 64-bits of the physical blocks to
be lost. Set up new macros which allows us to make sure the right
thing happen, even if at some point we end up supporting larger
logical block numbers.
Thanks to the Emese Revfy and the PaX security team for reporting this
issue.
Reported-by: PaX Team <pageexec@freemail.hu>
Reported-by: Emese Revfy <re.emese@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 18 Dec 2013 05:44:44 +0000 (00:44 -0500)]
ext4: fix deadlock when writing in ENOSPC conditions
commit
34cf865d54813aab3497838132fb1bbd293f4054 upstream.
Akira-san has been reporting rare deadlocks of his machine when running
xfstests test 269 on ext4 filesystem. The problem turned out to be in
ext4_da_reserve_metadata() and ext4_da_reserve_space() which called
ext4_should_retry_alloc() while holding i_data_sem. Since
ext4_should_retry_alloc() can force a transaction commit, this is a
lock ordering violation and leads to deadlocks.
Fix the problem by just removing the retry loops. These functions should
just report ENOSPC to the caller (e.g. ext4_da_write_begin()) and that
function must take care of retrying after dropping all necessary locks.
Reported-and-tested-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Mon, 9 Dec 2013 02:11:59 +0000 (21:11 -0500)]
ext4: Do not reserve clusters when fs doesn't support extents
commit
30fac0f75da24dd5bb43c9e911d2039a984ac815 upstream.
When the filesystem doesn't support extents (like in ext2/3
compatibility modes), there is no need to reserve any clusters. Space
estimates for writing are exact, hole punching doesn't need new
metadata, and there are no unwritten extents to convert.
This fixes a problem when filesystem still having some free space when
accessed with a native ext2/3 driver suddently reports ENOSPC when
accessed with ext4 driver.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Mon, 9 Dec 2013 01:52:31 +0000 (20:52 -0500)]
ext4: fix del_timer() misuse for ->s_err_report
commit
9105bb149bbbc555d2e11ba5166dfe7a24eae09e upstream.
That thing should be del_timer_sync(); consider what happens
if ext4_put_super() call of del_timer() happens to come just as it's
getting run on another CPU. Since that timer reschedules itself
to run next day, you are pretty much guaranteed that you'll end up
with kfree'd scheduled timer, with usual fun consequences. AFAICS,
that's -stable fodder all way back to 2010... [the second del_timer_sync()
is almost certainly not needed, but it doesn't hurt either]
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eryu Guan [Wed, 4 Dec 2013 02:22:21 +0000 (21:22 -0500)]
ext4: check for overlapping extents in ext4_valid_extent_entries()
commit
5946d089379a35dda0e531710b48fca05446a196 upstream.
A corrupted ext4 may have out of order leaf extents, i.e.
extent: lblk 0--1023, len 1024, pblk 9217, flags: LEAF UNINIT
extent: lblk 1000--2047, len 1024, pblk 10241, flags: LEAF UNINIT
^^^^ overlap with previous extent
Reading such extent could hit BUG_ON() in ext4_es_cache_extent().
BUG_ON(end < lblk);
The problem is that __read_extent_tree_block() tries to cache holes as
well but assumes 'lblk' is greater than 'prev' and passes underflowed
length to ext4_es_cache_extent(). Fix it by checking for overlapping
extents in ext4_valid_extent_entries().
I hit this when fuzz testing ext4, and am able to reproduce it by
modifying the on-disk extent by hand.
Also add the check for (ee_block + len - 1) in ext4_valid_extent() to
make sure the value is not overflow.
Ran xfstests on patched ext4 and no regression.
Cc: Lukáš Czerner <lczerner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Junho Ryu [Tue, 3 Dec 2013 23:10:28 +0000 (18:10 -0500)]
ext4: fix use-after-free in ext4_mb_new_blocks
commit
4e8d2139802ce4f41936a687f06c560b12115247 upstream.
ext4_mb_put_pa should hold pa->pa_lock before accessing pa->pa_count.
While ext4_mb_use_preallocated checks pa->pa_deleted first and then
increments pa->count later, ext4_mb_put_pa decrements pa->pa_count
before holding pa->pa_lock and then sets pa->pa_deleted.
* Free sequence
ext4_mb_put_pa (1): atomic_dec_and_test pa->pa_count
ext4_mb_put_pa (2): lock pa->pa_lock
ext4_mb_put_pa (3): check pa->pa_deleted
ext4_mb_put_pa (4): set pa->pa_deleted=1
ext4_mb_put_pa (5): unlock pa->pa_lock
ext4_mb_put_pa (6): remove pa from a list
ext4_mb_pa_callback: free pa
* Use sequence
ext4_mb_use_preallocated (1): iterate over preallocation
ext4_mb_use_preallocated (2): lock pa->pa_lock
ext4_mb_use_preallocated (3): check pa->pa_deleted
ext4_mb_use_preallocated (4): increase pa->pa_count
ext4_mb_use_preallocated (5): unlock pa->pa_lock
ext4_mb_release_context: access pa
* Use-after-free sequence
[initial status] <pa->pa_deleted = 0, pa_count = 1>
ext4_mb_use_preallocated (1): iterate over preallocation
ext4_mb_use_preallocated (2): lock pa->pa_lock
ext4_mb_use_preallocated (3): check pa->pa_deleted
ext4_mb_put_pa (1): atomic_dec_and_test pa->pa_count
[pa_count decremented] <pa->pa_deleted = 0, pa_count = 0>
ext4_mb_use_preallocated (4): increase pa->pa_count
[pa_count incremented] <pa->pa_deleted = 0, pa_count = 1>
ext4_mb_use_preallocated (5): unlock pa->pa_lock
ext4_mb_put_pa (2): lock pa->pa_lock
ext4_mb_put_pa (3): check pa->pa_deleted
ext4_mb_put_pa (4): set pa->pa_deleted=1
[race condition!] <pa->pa_deleted = 1, pa_count = 1>
ext4_mb_put_pa (5): unlock pa->pa_lock
ext4_mb_put_pa (6): remove pa from a list
ext4_mb_pa_callback: free pa
ext4_mb_release_context: access pa
AddressSanitizer has detected use-after-free in ext4_mb_new_blocks
Bug report: http://goo.gl/rG1On3
Signed-off-by: Junho Ryu <jayr@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Theodore Ts'o [Mon, 2 Dec 2013 14:31:36 +0000 (09:31 -0500)]
ext4: call ext4_error_inode() if jbd2_journal_dirty_metadata() fails
commit
ae1495b12df1897d4f42842a7aa7276d920f6290 upstream.
While it's true that errors can only happen if there is a bug in
jbd2_journal_dirty_metadata(), if a bug does happen, we need to halt
the kernel or remount the file system read-only in order to avoid
further data loss. The ext4_journal_abort_handle() function doesn't
do any of this, and while it's likely that this call (since it doesn't
adjust refcounts) will likely result in the file system eventually
deadlocking since the current transaction will never be able to close,
it's much cleaner to call let ext4's error handling system deal with
this situation.
There's a separate bug here which is that if certain jbd2 errors
errors occur and file system is mounted errors=continue, the file
system will probably eventually end grind to a halt as described
above. But things have been this way in a long time, and usually when
we have these sorts of errors it's pretty much a disaster --- and
that's why the jbd2 layer aggressively retries memory allocations,
which is the most likely cause of these jbd2 errors.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Drews [Mon, 25 Nov 2013 22:15:55 +0000 (14:15 -0800)]
ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs
commit
f6308b36c411dc5afd6a6f73e6454722bfde57b7 upstream.
This adds the new ACPI ID (INT33FC) for the BayTrail GPIO
banks as seen on a BayTrail M System-On-Chip platform. This
ACPI ID is used by the BayTrail GPIO (pinctrl) driver to
manage the Low Power Subsystem (LPSS).
Signed-off-by: Paul Drews <paul.drews@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Len Brown [Wed, 18 Dec 2013 21:44:57 +0000 (16:44 -0500)]
x86 idle: Repair large-server 50-watt idle-power regression
commit
40e2d7f9b5dae048789c64672bf3027fbb663ffa upstream.
Linux 3.10 changed the timing of how thread_info->flags is touched:
x86: Use generic idle loop
(
7d1a941731fabf27e5fb6edbebb79fe856edb4e5)
This caused Intel NHM-EX and WSM-EX servers to experience a large number
of immediate MONITOR/MWAIT break wakeups, which caused cpuidle to demote
from deep C-states to shallow C-states, which caused these platforms
to experience a significant increase in idle power.
Note that this issue was already present before the commit above,
however, it wasn't seen often enough to be noticed in power measurements.
Here we extend an errata workaround from the Core2 EX "Dunnington"
to extend to NHM-EX and WSM-EX, to prevent these immediate
returns from MWAIT, reducing idle power on these platforms.
While only acpi_idle ran on Dunnington, intel_idle
may also run on these two newer systems.
As of today, there are no other models that are known
to need this tweak.
Link: http://lkml.kernel.org/r/CAJvTdK=%2BaNN66mYpCGgbHGCHhYQAKx-vB0kJSWjVpsNb_hOAtQ@mail.gmail.com
Signed-off-by: Len Brown <len.brown@intel.com>
Link: http://lkml.kernel.org/r/baff264285f6e585df757d58b17788feabc68918.1387403066.git.len.brown@intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tony Lindgren [Fri, 27 Dec 2013 17:33:27 +0000 (09:33 -0800)]
ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting
commit
7e367c18c059c638bf6fb540f1decec18d64cb55 upstream.
Looks like the LCD panel on LDP has been broken quite a while, and
recently got fixed by commit
0b2aa8bed3e1 (gpio: twl4030: Fix regression
for twl gpio output). However, there's still an issue left where the panel
backlight does not come on if the LCD drivers are built into the
kernel.
Fix the issue by registering the DPI LCD panel only after the twl4030
GPIO has probed.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[tony@atomide.com: updated per Tomi's comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suman Anna [Mon, 23 Dec 2013 22:53:11 +0000 (16:53 -0600)]
ARM: OMAP2+: hwmod_data: fix missing OMAP_INTC_START in irq data
commit
6d4c88304794442055eaea1c07f3c7b988b8c924 upstream.
Commit 7d7e1eb (ARM: OMAP2+: Prepare for irqs.h removal) and commit
ec2c082 (ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ)
updated the way interrupts for OMAP2/3 devices are defined in the
HWMOD data structures to being an index plus a fixed offset (defined
by OMAP_INTC_START).
Couple of irqs in the OMAP2/3 hwmod data were misconfigured completely
as they were missing this OMAP_INTC_START relative offset. Add this
offset back to fix the incorrect irq data for the following modules:
OMAP2 - GPMC, RNG
OMAP3 - GPMC, ISP MMU & IVA MMU
Signed-off-by: Suman Anna <s-anna@ti.com>
Fixes:
7d7e1eba7e92 ("ARM: OMAP2+: Prepare for irqs.h removal")
Fixes:
ec2c0825ca31 ("ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ")
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rajendra Nayak [Thu, 12 Dec 2013 09:52:49 +0000 (15:22 +0530)]
ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL
commit
38958c15dc640a9249e4f0cd0dfb0ddc7a23464d upstream.
With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with
DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon
to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
On DRA7 though, we seem to be missing this flag, and atleast on the DRA7 EVM
where we use uart1 for console, boot fails with DEBUG_LL enabled.
Reported-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Lokesh Vutla <lokeshvutla@ti.com> # on a different base
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Fixes:
7dedd346941d ("ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL")
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Dooks [Mon, 16 Dec 2013 12:38:48 +0000 (12:38 +0000)]
ARM: shmobile: r8a7790: fix shdi resource sizes
commit
d721a15c300c5f638a11573a6dd492158e737d6a upstream.
The r8a7790.dtsi file has four sdhi nodes which the first two have the wrong
resource size for their register block. This causes the sh_modbile_sdhi driver
to fail to communicate with card at-all.
Change sdhi{0,1} node size from 0x100 to 0x200 to correct these nodes
as per Kuninori Morimoto's response to the original patch where all four
nodes where changed. sdhi{2,3} are the correct size.
This bug has been present since sdhi resources were added to the r8a7790 by
8c9b1aa41853272a ("ARM: shmobile: r8a7790: add MMCIF and SDHI DT
templates") in v3.11-rc2.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Tested-by: William Towle <william.towle@codethink.co.uk>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Tue, 17 Dec 2013 17:09:08 +0000 (17:09 +0000)]
arm64: ptrace: avoid using HW_BREAKPOINT_EMPTY for disabled events
commit
cdc27c27843248ae7eb0df5fc261dd004eaa5670 upstream.
Commit
8f34a1da35ae ("arm64: ptrace: use HW_BREAKPOINT_EMPTY type for
disabled breakpoints") fixed an issue with GDB trying to zero breakpoint
control registers. The problem there is that the arch hw_breakpoint code
will attempt to create a (disabled), execute breakpoint of length 0.
This will fail validation and report unexpected failure to GDB. To avoid
this, we treated disabled breakpoints as HW_BREAKPOINT_EMPTY, but that
seems to have broken with recent kernels, causing watchpoints to be
treated as TYPE_INST in the core code and returning ENOSPC for any
further breakpoints.
This patch fixes the problem by prioritising the `enable' field of the
breakpoint: if it is cleared, we simply update the perf_event_attr to
indicate that the thing is disabled and don't bother changing either the
type or the length. This reinforces the behaviour that the breakpoint
control register is essentially read-only apart from the enable bit
when disabling a breakpoint.
Reported-by: Aaron Liu <liucy214@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Tue, 10 Dec 2013 06:16:29 +0000 (16:46 +1030)]
scripts/link-vmlinux.sh: only filter kernel symbols for arm
commit
7122c3e9154b5d9a7422f68f02d8acf050fad2b0 upstream.
Actually CONFIG_PAGE_OFFSET isn't same with PAGE_OFFSET, so
it isn't easy to figue out PAGE_OFFSET defined in header
file from scripts.
Because CONFIG_PAGE_OFFSET may not be defined in some ARCHs(
64bit ARCH), or defined as bogus value in !MMU case, so
this patch only applys the filter on ARM when CONFIG_PAGE_OFFSET
is defined as the original problem is only on ARM.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Fixes:
f6537f2f0eba4eba3354e48dbe3047db6d8b6254
Singed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miao Xie [Mon, 16 Dec 2013 07:20:01 +0000 (15:20 +0800)]
ftrace: Initialize the ftrace profiler for each possible cpu
commit
c4602c1c818bd6626178d6d3fcc152d9f2f48ac0 upstream.
Ftrace currently initializes only the online CPUs. This implementation has
two problems:
- If we online a CPU after we enable the function profile, and then run the
test, we will lose the trace information on that CPU.
Steps to reproduce:
# echo 0 > /sys/devices/system/cpu/cpu1/online
# cd <debugfs>/tracing/
# echo <some function name> >> set_ftrace_filter
# echo 1 > function_profile_enabled
# echo 1 > /sys/devices/system/cpu/cpu1/online
# run test
- If we offline a CPU before we enable the function profile, we will not clear
the trace information when we enable the function profile. It will trouble
the users.
Steps to reproduce:
# cd <debugfs>/tracing/
# echo <some function name> >> set_ftrace_filter
# echo 1 > function_profile_enabled
# run test
# cat trace_stat/function*
# echo 0 > /sys/devices/system/cpu/cpu1/online
# echo 0 > function_profile_enabled
# echo 1 > function_profile_enabled
# cat trace_stat/function*
# run test
# cat trace_stat/function*
So it is better that we initialize the ftrace profiler for each possible cpu
every time we enable the function profile instead of just the online ones.
Link: http://lkml.kernel.org/r/1387178401-10619-1-git-send-email-miaox@cn.fujitsu.com
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jie Liu [Tue, 26 Nov 2013 13:38:49 +0000 (21:38 +0800)]
xfs: fix infinite loop by detaching the group/project hints from user dquot
commit
718cc6f88cbfc4fbd39609f28c4c86883945f90d upstream.
xfs_quota(8) will hang up if trying to turn group/project quota off
before the user quota is off, this could be 100% reproduced by:
# mount -ouquota,gquota /dev/sda7 /xfs
# mkdir /xfs/test
# xfs_quota -xc 'off -g' /xfs <-- hangs up
# echo w > /proc/sysrq-trigger
# dmesg
SysRq : Show Blocked State
task PC stack pid father
xfs_quota D
0000000000000000 0 27574 2551 0x00000000
[snip]
Call Trace:
[<
ffffffff81aaa21d>] schedule+0xad/0xc0
[<
ffffffff81aa327e>] schedule_timeout+0x35e/0x3c0
[<
ffffffff8114b506>] ? mark_held_locks+0x176/0x1c0
[<
ffffffff810ad6c0>] ? call_timer_fn+0x2c0/0x2c0
[<
ffffffffa0c25380>] ? xfs_qm_shrink_count+0x30/0x30 [xfs]
[<
ffffffff81aa3306>] schedule_timeout_uninterruptible+0x26/0x30
[<
ffffffffa0c26155>] xfs_qm_dquot_walk+0x235/0x260 [xfs]
[<
ffffffffa0c059d8>] ? xfs_perag_get+0x1d8/0x2d0 [xfs]
[<
ffffffffa0c05805>] ? xfs_perag_get+0x5/0x2d0 [xfs]
[<
ffffffffa0b7707e>] ? xfs_inode_ag_iterator+0xae/0xf0 [xfs]
[<
ffffffffa0c22280>] ? xfs_trans_free_dqinfo+0x50/0x50 [xfs]
[<
ffffffffa0b7709f>] ? xfs_inode_ag_iterator+0xcf/0xf0 [xfs]
[<
ffffffffa0c261e6>] xfs_qm_dqpurge_all+0x66/0xb0 [xfs]
[<
ffffffffa0c2497a>] xfs_qm_scall_quotaoff+0x20a/0x5f0 [xfs]
[<
ffffffffa0c2b8f6>] xfs_fs_set_xstate+0x136/0x180 [xfs]
[<
ffffffff8136cf7a>] do_quotactl+0x53a/0x6b0
[<
ffffffff812fba4b>] ? iput+0x5b/0x90
[<
ffffffff8136d257>] SyS_quotactl+0x167/0x1d0
[<
ffffffff814cf2ee>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<
ffffffff81abcd19>] system_call_fastpath+0x16/0x1b
It's fine if we turn user quota off at first, then turn off other
kind of quotas if they are enabled since the group/project dquot
refcount is decreased to zero once the user quota if off. Otherwise,
those dquots refcount is non-zero due to the user dquot might refer
to them as hint(s). Hence, above operation cause an infinite loop
at xfs_qm_dquot_walk() while trying to purge dquot cache.
This problem has been around since Linux 3.4, it was introduced by:
[
b84a3a9675 xfs: remove the per-filesystem list of dquots ]
Originally we will release the group dquot pointers because the user
dquots maybe carrying around as a hint via xfs_qm_detach_gdquots().
However, with above change, there is no such work to be done before
purging group/project dquot cache.
In order to solve this problem, this patch introduces a special routine
xfs_qm_dqpurge_hints(), and it would release the group/project dquot
pointers the user dquots maybe carrying around as a hint, and then it
will proceed to purge the user dquot cache if requested.
(cherry picked from commit
df8052e7dae00bde6f21b40b6e3e1099770f3afc)
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Thu, 12 Dec 2013 20:24:11 +0000 (12:24 -0800)]
target/file: Update hw_max_sectors based on current block_size
commit
95cadace8f3959282e76ebf8b382bd0930807d2c upstream.
This patch allows FILEIO to update hw_max_sectors based on the current
max_bytes_per_io. This is required because vfs_[writev,readv]() can accept
a maximum of 2048 iovecs per call, so the enforced hw_max_sectors really
needs to be calculated based on block_size.
This addresses a >= v3.5 bug where block_size=512 was rejecting > 1M
sized I/O requests, because FD_MAX_SECTORS was hardcoded to 2048 for
the block_size=4096 case.
(v2: Use max_bytes_per_io instead of ->update_hw_max_sectors)
Reported-by: Henrik Goldman <hg@x-formation.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Thu, 12 Dec 2013 00:20:13 +0000 (16:20 -0800)]
iser-target: Move INIT_WORK setup into isert_create_device_ib_res
commit
2853c2b6671509591be09213954d7249ca6ff224 upstream.
This patch moves INIT_WORK setup for cq_desc->cq_[rx,tx]_work into
isert_create_device_ib_res(), instead of being done each callback
invocation in isert_cq_[rx,tx]_callback().
This also fixes a 'INFO: trying to register non-static key' warning
when cancel_work_sync() is called before INIT_WORK has setup the
struct work_struct.
Reported-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Wed, 11 Dec 2013 23:45:32 +0000 (15:45 -0800)]
iscsi-target: Fix incorrect np->np_thread NULL assignment
commit
db6077fd0b7dd41dc6ff18329cec979379071f87 upstream.
When shutting down a target there is a race condition between
iscsit_del_np() and __iscsi_target_login_thread().
The latter sets the thread pointer to NULL, and the former
tries to issue kthread_stop() on that pointer without any
synchronization.
This patch moves the np->np_thread NULL assignment into
iscsit_del_np(), after kthread_stop() has completed. It also
removes the signal_pending() + np_state check, and only
exits when kthread_should_stop() is true.
Reported-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Mon, 25 Nov 2013 22:53:57 +0000 (14:53 -0800)]
iscsi-target: Fix-up all zero data-length CDBs with R/W_BIT set
commit
4454b66cb67f14c33cd70ddcf0ff4985b26324b7 upstream.
This patch changes special case handling for ISCSI_OP_SCSI_CMD
where an initiator sends a zero length Expected Data Transfer
Length (EDTL), but still sets the WRITE and/or READ flag bits
when no payload transfer is requested.
Many, many moons ago two special cases where added for an ancient
version of ESX that has long since been fixed, so instead of adding
a new special case for the reported bug with a Broadcom 57800 NIC,
go ahead and always strip off the incorrect WRITE + READ flag bits.
Also, avoid sending a reject here, as RFC-3720 does mandate this
case be handled without protocol error.
Reported-by: Witold Bazakbal <865perl@wp.pl>
Tested-by: Witold Bazakbal <865perl@wp.pl>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Yongjun [Tue, 29 Oct 2013 01:56:34 +0000 (09:56 +0800)]
iser-target: fix error return code in isert_create_device_ib_res()
commit
94a7111043d99819cd0a72d9b3174c7054adb2a0 upstream.
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shivaram Upadhyayula [Tue, 10 Dec 2013 10:36:40 +0000 (16:06 +0530)]
qla2xxx: Fix schedule_delayed_work() for target timeout calculations
commit
63832aabec12a28a41a221773ab3819d30ba0a67 upstream.
This patch fixes two cases in qla_target.c code where the
schedule_delayed_work() value was being incorrectly calculated
from sess->expires - jiffies.
Signed-off-by: Shivaram U <shivaram.u@quadstor.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin LaHaise [Sat, 21 Dec 2013 20:49:28 +0000 (15:49 -0500)]
aio: fix kioctx leak introduced by "aio: Fix a trinity splat"
commit
1881686f842065d2f92ec9c6424830ffc17d23b0 upstream.
e34ecee2ae791df674dfb466ce40692ca6218e43 reworked the percpu reference
counting to correct a bug trinity found. Unfortunately, the change lead
to kioctxes being leaked because there was no final reference count to
put. Add that reference count back in to fix things.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Mon, 23 Dec 2013 22:45:01 +0000 (17:45 -0500)]
selinux: selinux_setprocattr()->ptrace_parent() needs rcu_read_lock()
commit
c0c1439541f5305b57a83d599af32b74182933fe upstream.
selinux_setprocattr() does ptrace_parent(p) under task_lock(p),
but task_struct->alloc_lock doesn't pin ->parent or ->ptrace,
this looks confusing and triggers the "suspicious RCU usage"
warning because ptrace_parent() does rcu_dereference_check().
And in theory this is wrong, spin_lock()->preempt_disable()
doesn't necessarily imply rcu_read_lock() we need to access
the ->parent.
Reported-by: Evan McNabb <emcnabb@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chad Hanson [Mon, 23 Dec 2013 22:45:01 +0000 (17:45 -0500)]
selinux: fix broken peer recv check
commit
46d01d63221c3508421dd72ff9c879f61053cffc upstream.
Fix a broken networking check. Return an error if peer recv fails. If
secmark is active and the packet recv succeeds the peer recv error is
ignored.
Signed-off-by: Chad Hanson <chanson@trustedcs.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Wed, 6 Nov 2013 08:25:27 +0000 (09:25 +0100)]
usb: musb: only cancel work if it is initialized
commit
66fadea5b79c07154126bb0db375be915f611246 upstream.
Since commit
c5340bd14 ("usb: musb: cancel work on removal") the workqueue
is cancelled but then if we bail out before the workqueue is setup we
get this:
|INFO: trying to register non-static key.
|the code is fine but needs lockdep annotation.
|turning off the locking correctness validator.
|CPU: 0 PID: 708 Comm: modprobe Not tainted 3.12.0+ #435
|[<
c00867bc>] (lock_acquire+0xf0/0x108) from [<
c00529d0>] (flush_work+0x38/0x2ec)
|[<
c00529d0>] (flush_work+0x38/0x2ec) from [<
c0052d24>] (__cancel_work_timer+0xa0/0x134)
|[<
c0052d24>] (__cancel_work_timer+0xa0/0x134) from [<
bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc])
|[<
bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc]) from [<
bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc])
|[<
bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc]) from [<
c0294bf0>] (platform_drv_probe+0x1c/0x24)
|[<
c0294bf0>] (platform_drv_probe+0x1c/0x24) from [<
c0293970>] (driver_probe_device+0x90/0x224)
|[<
c0293970>] (driver_probe_device+0x90/0x224) from [<
c0291ef0>] (bus_for_each_drv+0x60/0x8c)
|[<
c0291ef0>] (bus_for_each_drv+0x60/0x8c) from [<
c02938bc>] (device_attach+0x80/0xa4)
|[<
c02938bc>] (device_attach+0x80/0xa4) from [<
c0292b24>] (bus_probe_device+0x88/0xac)
|[<
c0292b24>] (bus_probe_device+0x88/0xac) from [<
c0291490>] (device_add+0x388/0x6c8)
|[<
c0291490>] (device_add+0x388/0x6c8) from [<
c02952a0>] (platform_device_add+0x188/0x22c)
|[<
c02952a0>] (platform_device_add+0x188/0x22c) from [<
bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps])
|[<
bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps]) from [<
c0294bf0>] (platform_drv_probe+0x1c/0x24)
|platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
|musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
This patch moves the init part to earlier part so it can be cleaned as
part of the fail3 label because now it is surrounded by the fail4 label.
Step two is to remove it from musb_free() and add it to the two cleanup
paths (error path and device removal) separately.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Wed, 16 Oct 2013 10:50:07 +0000 (12:50 +0200)]
usb: musb: core: Call dma_controller_destroy() in error path only once.
commit
8d1aad7485e653c2c5fd985b326096f680f7d918 upstream.
In commit f3ce4d5 ("usb: musb: core: call dma_controller_destroy() in the err path")
I erroneously assumed that the dma controller is not removed in the
error patch. This was wrong because it happens later via musb_free().
That means the original commit can be reverted because it is wrong or we
do this, so it is more obvious.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Chen [Thu, 5 Dec 2013 07:20:50 +0000 (15:20 +0800)]
usb: chipidea: fix nobody cared IRQ when booting with host role
commit
5a1e1456fc633da5291285b1fff75d2a7507375b upstream.
If we connect Male-A-To-Male-A cable between otg-host and host pc,
the ci->vbus_active is set wrongly, and cause the controller run
at peripheral mode when we load gadget module (ci_udc_start will be run),
but the software runs at host mode due to id = 0. The ehci_irq
can't handle suspend (USBi_SLI) interrupt which is enabled for
peripheral mode, it causes no one will handle irq error.
This patch is needed for 3.12 stable
Acked-by: Michael Grzeschik <mgr@pengutronix.de>
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fabio Estevam [Thu, 5 Dec 2013 07:20:49 +0000 (15:20 +0800)]
usb: chipidea: host: Only disable the vbus regulator if it is not NULL
commit
cc5c9eb67f912cb2c349b04063ff9f444affbc59 upstream.
Commit
40ed51a4b (usb: chipidea: host: add vbus regulator
control) introduced a smatch complaint because regulator_disable() is called
without checking whether ci->platdata->reg_vbus is not NULL.
Fix this by adding the check.
This patch is needed for 3.12 stable
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Fri, 29 Nov 2013 19:17:45 +0000 (20:17 +0100)]
usb: cdc-wdm: manage_power should always set needs_remote_wakeup
commit
4144bc861ed7934d56f16d2acd808d44af0fcc90 upstream.
Reported-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Kleine-Budde [Sat, 14 Dec 2013 13:36:25 +0000 (14:36 +0100)]
can: peak_usb: fix mem leak in pcan_usb_pro_init()
commit
20fb4eb96fb0350d28fc4d7cbfd5506711079592 upstream.
This patch fixes a memory leak in pcan_usb_pro_init(). In patch
f14e224 net: can: peak_usb: Do not do dma on the stack
the struct pcan_usb_pro_fwinfo *fi and struct pcan_usb_pro_blinfo *bi were
converted from stack to dynamic allocation va kmalloc(). However the
corresponding kfree() was not introduced.
This patch adds the missing kfree().
Reported-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 9 Dec 2013 13:53:36 +0000 (14:53 +0100)]
xhci: Limit the spurious wakeup fix only to HP machines
commit
6962d914f317b119e0db7189199b21ec77a4b3e0 upstream.
We've got regression reports that my previous fix for spurious wakeups
after S5 on HP Haswell machines leads to the automatic reboot at
shutdown on some machines. It turned out that the fix for one side
triggers another BIOS bug in other side. So, it's exclusive.
Since the original S5 wakeups have been confirmed only on HP machines,
it'd be safer to apply it only to limited machines. As a wild guess,
limiting to machines with HP PCI SSID should suffice.
This patch should be backported to kernels as old as 3.12, that
contain the commit
638298dc66ea36623dbc2757a24fc2c4ab41b016 "xhci: Fix
spurious wakeups after S5 on Haswell".
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: <dashing.meng@gmail.com>
Reported-by: Niklas Schnelle <niklas@komani.de>
Reported-by: Giorgos <ganastasiouGR@gmail.com>
Reported-by: <art1@vhex.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Kunilov [Tue, 3 Dec 2013 20:11:30 +0000 (12:11 -0800)]
usb: serial: zte_ev: move support for ZTE AC2726 from zte_ev back to option
commit
52d0dc7597c89b2ab779f3dcb9b9bf0800dd9218 upstream.
ZTE AC2726 EVDO modem drops ppp connection every minute when driven by
zte_ev but works fine when driven by option. Move the support for AC2726
back to option driver.
Signed-off-by: Dmitry Kunilov <dmitry.kunilov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mika Westerberg [Tue, 10 Dec 2013 10:56:59 +0000 (12:56 +0200)]
serial: 8250_dw: add new ACPI IDs
commit
d24c195f90cb1adb178d26d84c722d4b9e551e05 upstream.
Newer Intel PCHs with LPSS have the same Designware controllers than
Haswell but ACPI IDs are different. Add these IDs to the driver list.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Cameron [Wed, 11 Dec 2013 18:45:00 +0000 (18:45 +0000)]
iio:adc:ad7887 Fix channel reported endianness from cpu to big endian
commit
e39d99059ad7f75d7ae2d3c59055d3c476cdb0d9 upstream.
Note this also sets the endianness to big endian whereas it would
previously have defaulted to the cpu endian. Hence technically
this is a bug fix on LE platforms.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>