10 Nov, 2015
1 commit
-
commit bb387002693ed28b2bb0408c5dec65521b71e5f1 upstream.
interval displays the probability and vice versa.
Fixes: 6adc4a22f20bb ("fault-inject: add ratelimit option")
Acked-by: Akinobu Mita
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
23 Oct, 2015
1 commit
-
commit d046b770c9fc36ccb19c27afdb8322220108cbc7 upstream.
The check for invoking iommu->lazy_flush() from iommu_tbl_range_alloc()
has to be refactored so that we only call ->lazy_flush() if it is
non-null.I had a sparc kernel that was crashing when I was trying to process some
very large perf.data files- the crash happens when the scsi driver calls
into dma_4v_map_sg and thus the iommu_tbl_range_alloc().Signed-off-by: Sowmini Varadhan
Cc: Benjamin Herrenschmidt
Cc: Guenter Roeck
Cc: David S. Miller
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
30 Sep, 2015
2 commits
-
[ Upstream commit 142b942a75cb10ede1b42bf85368d41449ab4e3b ]
If rhashtable_walk_next detects a resize operation in progress, it jumps
to the new table and continues walking that one. But it misses to drop
the reference to it's current item, leading it to continue traversing
the new table's bucket in which the current item is sorted into, and
after reaching that bucket's end continues traversing the new table's
second bucket instead of the first one, thereby potentially missing
items.This fixes the rhashtable runtime test for me. Bug probably introduced
by Herbert Xu's patch eddee5ba ("rhashtable: Fix walker behaviour during
rehash") although not explicitly tested.Fixes: eddee5ba ("rhashtable: Fix walker behaviour during rehash")
Signed-off-by: Phil Sutter
Acked-by: Herbert Xu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 2d3862d26e67a59340ba1cf1748196c76c5787de upstream.
When loading x86 64bit kernel above 4GiB with patched grub2, got kernel
gunzip error.| early console in decompress_kernel
| decompress_kernel:
| input: [0x807f2143b4-0x807ff61aee]
| output: [0x807cc00000-0x807f3ea29b] 0x027ea29c: output_len
| boot via startup_64
| KASLR using RDTSC...
| new output: [0x46fe000000-0x470138cfff] 0x0338d000: output_run_size
| decompress: [0x46fe000000-0x47007ea29b]
Cc: Alexandre Courbot
Cc: Jon Medhurst
Cc: Stephen Warren
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
11 Aug, 2015
1 commit
-
commit c9d120b0b2b5069cb2ae62f8eac0cef31c8544be upstream.
If dma-debug is disabled due to a memory error, DMA unmaps do not affect
the dma_active_cacheline radix tree anymore, and debug_dma_assert_idle()
can print false warnings.Disable debug_dma_assert_idle() when dma_debug_disabled() is true.
Signed-off-by: Haggai Eran
Fixes: 0abdd7a81b7e ("dma-debug: introduce debug_dma_assert_idle()")
Cc: Dan Williams
Cc: Joerg Roedel
Cc: Vinod Koul
Cc: Russell King
Cc: James Bottomley
Cc: Florian Fainelli
Cc: Sebastian Ott
Cc: Jiri Kosina
Cc: Horia Geanta
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
04 Aug, 2015
1 commit
-
commit 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 upstream.
bitmap_parselist("", &mask, nmaskbits) will erroneously set bit zero in
the mask. The same bug is visible in cpumask_parselist() since it is
layered on top of the bitmask code, e.g. if you boot with "isolcpus=",
you will actually end up with cpu zero isolated.The bug was introduced in commit 4b060420a596 ("bitmap, irq: add
smp_affinity_list interface to /proc/irq") when bitmap_parselist() was
generalized to support userspace as well as kernelspace.Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq")
Signed-off-by: Chris Metcalf
Cc: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
19 Jun, 2015
1 commit
-
Revert commit 534b483a86e6 ("cpumask: don't perform while loop in
cpumask_next_and()").This was a minor optimization, but it puts a `struct cpumask' on the
stack, which consumes too much stack space.Sergey Senozhatsky
Reported-by: Peter Zijlstra
Cc: Sergey Senozhatsky
Cc: Tejun Heo
Cc: "David S. Miller"
Cc: Amir Vadai
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Jun, 2015
1 commit
-
Pull more MIPS fixes from Ralf Baechle:
"Another round of 4.1 MIPS fixes, one fix to a MIPS-specific #if
condition in lib/mpi, one fix to the MIPS GIC irqchip driver and one
SSB fix.Details:
- fix handling of clock in chipco SSB driver.
- fix two MIPS-specific #if conditions to correctly work for GCC 5.1.
- fix damage to R6 pgtable bits done by XPA support.
- fix possible crash due to unloading modules that contain statically
defined platform devices.
- fix disabling of the MSA ASE on context switch to also work
correctly when a new thread/process has the CPU for the very first
time.This is part of linux-next and has been beaten to death on
Imagination's test farm.While things are not looking too grim this pull request also means the
rate of fixes for 4.1 remains nearly constant so I'd not be unhappy if
you'd delay the release"* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MPI: MIPS: Fix compilation error with GCC 5.1
IRQCHIP: mips-gic: Don't nest calls to do_IRQ()
MIPS: MSA: bugfix - disable MSA correctly for new threads/processes.
MIPS: Loongson: Do not register 8250 platform device from module.
MIPS: Cobalt: Do not build MTD platform device registration code as module.
SSB: Fix handling of ssb_pmu_get_alp_clock()
MIPS: pgtable-bits: Fix XPA damage to R6 definitions.
13 Jun, 2015
1 commit
-
This patch fixes mips compilation error:
lib/mpi/generic_mpih-mul1.c: In function 'mpihelp_mul_1':
lib/mpi/longlong.h:651:2: error: impossible constraint in 'asm'Signed-off-by: Jaedon Shin
Cc: Linux-MIPS
Patchwork: https://patchwork.linux-mips.org/patch/10546/
Signed-off-by: Ralf Baechle
09 Jun, 2015
1 commit
-
Pull networking fixes from David Miller:
1) Fix stack allocation in s390 BPF JIT, from Michael Holzheu.
2) Disable LRO on openvswitch paths, from Jiri Benc.
3) UDP early demux doesn't handle multicast group membership properly,
fix from Shawn Bohrer.4) Fix TX queue hang due to incorrect handling of mixed sized fragments
and linearlization in i40e driver, from Anjali Singhai Jain.5) Cannot use disable_irq() in timer handler of AMD xgbe driver, from
Thomas Lendacky.6) b2net driver improperly assumes pci_alloc_consistent() gives zero'd
out memory, use dma_zalloc_coherent(). From Sriharsha Basavapatna.7) Fix use-after-free in MPLS and ipv6, from Robert Shearman.
8) Missing neif_napi_del() calls in cleanup paths of b44 driver, from
Hauke Mehrtens.* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
net: replace last open coded skb_orphan_frags with function call
net: bcmgenet: power on MII block for all MII modes
ipv6: Fix protocol resubmission
ipv6: fix possible use after free of dev stats
b44: call netif_napi_del()
bridge: disable softirqs around br_fdb_update to avoid lockup
Revert "bridge: use _bh spinlock variant for br_fdb_update to avoid lockup"
mpls: fix possible use after free of device
be2net: Replace dma/pci_alloc_coherent() calls with dma_zalloc_coherent()
bridge: use _bh spinlock variant for br_fdb_update to avoid lockup
amd-xgbe: Use disable_irq_nosync from within timer function
rhashtable: add missing import
i40e: Make sure to be in VEB mode if SRIOV is enabled at probe
i40e: start up in VEPA mode by default
i40e/i40evf: Fix mixed size frags and linearization
ipv4/udp: Verify multicast group is ours in upd_v4_early_demux()
openvswitch: disable LRO
s390/bpf: fix bpf frame pointer setup
s390/bpf: fix stack allocation
07 Jun, 2015
2 commits
-
rhashtable uses EXPORT_SYMBOL_GPL() without importing linux/export.h
directly it is only imported indirectly through some other includes.Signed-off-by: Hauke Mehrtens
Signed-off-by: David S. Miller -
Pull swiotlb fix from Konrad Rzeszutek Wilk:
"Tiny little fix which just converts an function to be static. Really
tiny"* 'stable/for-linus-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb:
swiotlb: do not export map_single function
06 Jun, 2015
1 commit
-
The map_single() function is not defined as static, even though it
doesn't seem to be used anywhere else in the kernel. Make it static to
avoid namespace pollution since this is a rather generic symbol.Signed-off-by: Alexandre Courbot
Signed-off-by: Konrad Rzeszutek Wilk
03 Jun, 2015
2 commits
-
strnlen_user() can return a number in a range 0 to count +
sizeof(unsigned long) - 1. Clarify the comment at the top of the
function so that users don't think the function returns at most count+1.Signed-off-by: Jan Kara
[ Also added commentary about preferably not using this function ]
Signed-off-by: Linus Torvalds -
If the specified maximum length of the string is a multiple of unsigned
long, we would load one long behind the specified maximum. If that
happens to be in a next page, we can hit a page fault although we were
not expected to.Fix the off-by-one bug in the test whether we are at the end of the
specified range.Signed-off-by: Jan Kara
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds
30 May, 2015
2 commits
-
Pull xfs fixes from Dave Chinner:
"This is a little larger than I'd like late in the release cycle, but
all the fixes are for regressions introduced in the 4.1-rc1 merge, or
are needed back in -stable kernels fairly quickly as they are
filesystem corruption or userspace visible correctness issues.Changes in this update:
- regression fix for new rename whiteout code
- regression fixes for new superblock generic per-cpu counter code
- fix for incorrect error return sign introduced in 3.17
- metadata corruption fixes that need to go back to -stable kernels"
* tag 'xfs-for-linus-4.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs:
xfs: fix broken i_nlink accounting for whiteout tmpfile inode
xfs: xfs_iozero can return positive errno
xfs: xfs_attr_inactive leaves inconsistent attr fork state behind
xfs: extent size hints can round up extents past MAXEXTLEN
xfs: inode and free block counters need to use __percpu_counter_compare
percpu_counter: batch size aware __percpu_counter_compare()
xfs: use percpu_counter_read_positive for mp->m_icount -
Pull fixes for cpumask and modules from Rusty Russell:
"** NOW WITH TESTING! **Two fixes which got lost in my recent distraction. One is a weird
cpumask function which needed to be rewritten, the other is a module
bug which is cc:stable"* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
cpumask_set_cpu_local_first => cpumask_local_spread, lament
module: Call module notifier on failure after complete_formation()
29 May, 2015
1 commit
-
XFS uses non-stanard batch sizes for avoiding frequent global
counter updates on it's allocated inode counters, as they increment
or decrement in batches of 64 inodes. Hence the standard percpu
counter batch of 32 means that the counter is effectively a global
counter. Currently Xfs uses a batch size of 128 so that it doesn't
take the global lock on every single modification.However, Xfs also needs to compare accurately against zero, which
means we need to use percpu_counter_compare(), and that has a
hard-coded batch size of 32, and hence will spuriously fail to
detect when it is supposed to use precise comparisons and hence
the accounting goes wrong.Add __percpu_counter_compare() to take a custom batch size so we can
use it sanely in XFS and factor percpu_counter_compare() to use it.Signed-off-by: Dave Chinner
Acked-by: Tejun Heo
Signed-off-by: Dave Chinner
28 May, 2015
1 commit
-
da91309e0a7e (cpumask: Utility function to set n'th cpu...) created a
genuinely weird function. I never saw it before, it went through DaveM.
(He only does this to make us other maintainers feel better about our own
mistakes.)cpumask_set_cpu_local_first's purpose is say "I need to spread things
across N online cpus, choose the ones on this numa node first"; you call
it in a loop.It can fail. One of the two callers ignores this, the other aborts and
fails the device open.It can fail in two ways: allocating the off-stack cpumask, or through a
convoluted codepath which AFAICT can only occur if cpu_online_mask
changes. Which shouldn't happen, because if cpu_online_mask can change
while you call this, it could return a now-offline cpu anyway.It contains a nonsensical test "!cpumask_of_node(numa_node)". This was
drawn to my attention by Geert, who said this causes a warning on Sparc.
It sets a single bit in a cpumask instead of returning a cpu number,
because that's what the callers want.It could be made more efficient by passing the previous cpu rather than
an index, but that would be more invasive to the callers.Fixes: da91309e0a7e8966d916a74cce42ed170fde06bf
Signed-off-by: Rusty Russell (then rebased)
Tested-by: Amir Vadai
Acked-by: Amir Vadai
Acked-by: David S. Miller
17 May, 2015
1 commit
-
We currently have no limit on the number of elements in a hash table.
This is a problem because some users (tipc) set a ceiling on the
maximum table size and when that is reached the hash table may
degenerate. Others may encounter OOM when growing and if we allow
insertions when that happens the hash table perofrmance may also
suffer.This patch adds a new paramater insecure_max_entries which becomes
the cap on the table. If unset it defaults to max_size * 2. If
it is also zero it means that there is no cap on the number of
elements in the table. However, the table will grow whenever the
utilisation hits 100% and if that growth fails, you will get ENOMEM
on insertion.As allowing oversubscription is potentially dangerous, the name
contains the word insecure.Note that the cap is not a hard limit. This is done for performance
reasons as enforcing a hard limit will result in use of atomic ops
that are heavier than the ones we currently use.The reasoning is that we're only guarding against a gross over-
subscription of the table, rather than a small breach of the limit.Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller
07 May, 2015
1 commit
-
Pull RCU fix from Ingo Molnar:
"An RCU Kconfig fix that eliminates an annoying interactive kconfig
question for CONFIG_RCU_TORTURE_TEST_SLOW_INIT"* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
rcu: Control grace-period delays directly from value
06 May, 2015
3 commits
-
The documentation shows a need for gcc > 4.9.2, but it's really >=. The
Kconfig entries don't show require versions so add them. Correct a
latter/later typo too. Also mention that gcc 5 required to catch out of
bounds accesses to global and stack variables.Signed-off-by: Joe Perches
Signed-off-by: Andrey Ryabinin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The file lib/find_last_bit.c was no longer used and supposed to be
deleted by commit 8f6f19dd51 ("lib: move find_last_bit to
lib/find_next_bit.c") but that delete didn't happen. This gets rid of
it.Signed-off-by: Yury Norov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Pull crypto fixes from Herbert Xu:
"This fixes a build problem with bcm63xx and yet another fix to the
memzero_explicit function to ensure that the memset is not elided"* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
hwrng: bcm63xx - Fix driver compilation
lib: make memzero_explicit more robust against dead store elimination
04 May, 2015
1 commit
-
In commit 0b053c951829 ("lib: memzero_explicit: use barrier instead
of OPTIMIZER_HIDE_VAR"), we made memzero_explicit() more robust in
case LTO would decide to inline memzero_explicit() and eventually
find out it could be elimiated as dead store.While using barrier() works well for the case of gcc, recent efforts
from LLVMLinux people suggest to use llvm as an alternative to gcc,
and there, Stephan found in a simple stand-alone user space example
that llvm could nevertheless optimize and thus elimitate the memset().
A similar issue has been observed in the referenced llvm bug report,
which is regarded as not-a-bug.Based on some experiments, icc is a bit special on its own, while it
doesn't seem to eliminate the memset(), it could do so with an own
implementation, and then result in similar findings as with llvm.The fix in this patch now works for all three compilers (also tested
with more aggressive optimization levels). Arguably, in the current
kernel tree it's more of a theoretical issue, but imho, it's better
to be pedantic about it.It's clearly visible with gcc/llvm though, with the below code: if we
would have used barrier() only here, llvm would have omitted clearing,
not so with barrier_data() variant:static inline void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
barrier_data(s);
}int main(void)
{
char buff[20];
memzero_explicit(buff, sizeof(buff));
return 0;
}$ gcc -O2 test.c
$ gdb a.out
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000400400 : lea -0x28(%rsp),%rax
0x0000000000400405 : movq $0x0,-0x28(%rsp)
0x000000000040040e : movq $0x0,-0x20(%rsp)
0x0000000000400417 : movl $0x0,-0x18(%rsp)
0x000000000040041f : xor %eax,%eax
0x0000000000400421 : retq
End of assembler dump.$ clang -O2 test.c
$ gdb a.out
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004004f0 : xorps %xmm0,%xmm0
0x00000000004004f3 : movaps %xmm0,-0x18(%rsp)
0x00000000004004f8 : movl $0x0,-0x8(%rsp)
0x0000000000400500 : lea -0x18(%rsp),%rax
0x0000000000400505 : xor %eax,%eax
0x0000000000400507 : retq
End of assembler dump.As gcc, clang, but also icc defines __GNUC__, it's sufficient to define
this in compiler-gcc.h only to be picked up. For a fallback or otherwise
unsupported compiler, we define it as a barrier. Similarly, for ecc which
does not support gcc inline asm.Reference: https://llvm.org/bugs/show_bug.cgi?id=15495
Reported-by: Stephan Mueller
Tested-by: Stephan Mueller
Signed-off-by: Daniel Borkmann
Cc: Theodore Ts'o
Cc: Stephan Mueller
Cc: Hannes Frederic Sowa
Cc: mancha security
Cc: Mark Charlebois
Cc: Behan Webster
Signed-off-by: Herbert Xu
28 Apr, 2015
1 commit
-
Pull networking fixes from David Miller:
1) mlx4 doesn't check fully for supported valid RSS hash function, fix
from Amir Vadai2) Off by one in ibmveth_change_mtu(), from David Gibson
3) Prevent altera chip from reporting false error interrupts in some
circumstances, from Chee Nouk Phoon4) Get rid of that stupid endless loop trying to allocate a FIN packet
in TCP, and in the process kill deadlocks. From Eric Dumazet5) Fix get_rps_cpus() crash due to wrong invalid-cpu value, also from
Eric Dumazet6) Fix two bugs in async rhashtable resizing, from Thomas Graf
7) Fix topology server listener socket namespace bug in TIPC, from Ying
Xue8) Add some missing HAS_DMA kconfig dependencies, from Geert
Uytterhoeven9) bgmac driver intends to force re-polling but does so by returning
the wrong value from it's ->poll() handler. Fix from Rafał Miłecki10) When the creater of an rhashtable configures a max size for it,
don't bark in the logs and drop insertions when that is exceeded.
Fix from Johannes Berg11) Recover from out of order packets in ppp mppe properly, from Sylvain
Rochet* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (41 commits)
bnx2x: really disable TPA if 'disable_tpa' option is set
net:treewide: Fix typo in drivers/net
net/mlx4_en: Prevent setting invalid RSS hash function
mdio-mux-gpio: use new gpiod_get_array and gpiod_put_array functions
netfilter; Add some missing default cases to switch statements in nft_reject.
ppp: mppe: discard late packet in stateless mode
ppp: mppe: sanity error path rework
net/bonding: Make DRV macros private
net: rfs: fix crash in get_rps_cpus()
altera tse: add support for fixed-links.
pxa168: fix double deallocation of managed resources
net: fix crash in build_skb()
net: eth: altera: Resolve false errors from MSGDMA to TSE
ehea: Fix memory hook reference counting crashes
net/tg3: Release IRQs on permanent error
net: mdio-gpio: support access that may sleep
inet: fix possible panic in reqsk_queue_unlink()
rhashtable: don't attempt to grow when at max_size
bgmac: fix requests for extra polling calls from NAPI
tcp: avoid looping in tcp_send_fin()
...
25 Apr, 2015
1 commit
-
Pull md updates from Neil Brown:
"More updates that usual this time. A few have performance impacts
which hould mostly be positive, but RAID5 (in particular) can be very
work-load ensitive... We'll have to wait and see.Highlights:
- "experimental" code for managing md/raid1 across a cluster using
DLM. Code is not ready for general use and triggers a WARNING if
used. However it is looking good and mostly done and having in
mainline will help co-ordinate development.- RAID5/6 can now batch multiple (4K wide) stripe_heads so as to
handle a full (chunk wide) stripe as a single unit.- RAID6 can now perform read-modify-write cycles which should help
performance on larger arrays: 6 or more devices.- RAID5/6 stripe cache now grows and shrinks dynamically. The value
set is used as a minimum.- Resync is now allowed to go a little faster than the 'mininum' when
there is competing IO. How much faster depends on the speed of the
devices, so the effective minimum should scale with device speed to
some extent"* tag 'md/4.1' of git://neil.brown.name/md: (58 commits)
md/raid5: don't do chunk aligned read on degraded array.
md/raid5: allow the stripe_cache to grow and shrink.
md/raid5: change ->inactive_blocked to a bit-flag.
md/raid5: move max_nr_stripes management into grow_one_stripe and drop_one_stripe
md/raid5: pass gfp_t arg to grow_one_stripe()
md/raid5: introduce configuration option rmw_level
md/raid5: activate raid6 rmw feature
md/raid6 algorithms: xor_syndrome() for SSE2
md/raid6 algorithms: xor_syndrome() for generic int
md/raid6 algorithms: improve test program
md/raid6 algorithms: delta syndrome functions
raid5: handle expansion/resync case with stripe batching
raid5: handle io error of batch list
RAID5: batch adjacent full stripe write
raid5: track overwrite disk count
raid5: add a new flag to track if a stripe can be batched
raid5: use flex_array for scribble data
md raid0: access mddev->queue (request queue member) conditionally because it is not set when accessed from dm-raid
md: allow resync to go faster when there is competing IO.
md: remove 'go_faster' option from ->sync_request()
...
23 Apr, 2015
2 commits
-
The current code currently only stops inserting rehashes into the
chain when no resizes are currently scheduled. As long as resizes
are scheduled and while inserting above the utilization watermark,
more and more rehashes will be scheduled.This lead to a perfect DoS storm with thousands of rehashes
scheduled which lead to thousands of spinlocks to be taken
sequentially.Instead, only allow either a series of resizes or a single rehash.
Drop any further rehashes and return -EBUSY.Fixes: ccd57b1bd324 ("rhashtable: Add immediate rehash during insertion")
Signed-off-by: Thomas Graf
Acked-by: Herbert Xu
Signed-off-by: David S. Miller -
When rhashtable_insert_rehash() fails with ENOMEM, this indicates that
we can't allocate the necessary memory in the current context but the
limits as set by the user would still allow to grow.Thus attempt an async resize in the background where we can allocate
using GFP_KERNEL which is more likely to succeed. The insertion itself
will still fail to indicate pressure.This fixes a bug where the table would never continue growing once the
utilization is above 100%.Fixes: ccd57b1bd324 ("rhashtable: Add immediate rehash during insertion")
Signed-off-by: Thomas Graf
Acked-by: Herbert Xu
Signed-off-by: David S. Miller
22 Apr, 2015
6 commits
-
Pull sparc fixes from David Miller:
1) ldc_alloc_exp_dring() can be called from softints, so use
GFP_ATOMIC. From Sowmini Varadhan.2) Some minor warning/build fixups for the new iommu-common code on
certain archs and with certain debug options enabled. Also from
Sowmini Varadhan.* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc: Use GFP_ATOMIC in ldc_alloc_exp_dring() as it can be called in softirq context
sparc64: Use M7 PMC write on all chips T4 and onward.
iommu-common: rename iommu_pool_hash to iommu_hash_common
iommu-common: fix x86_64 compiler warnings -
The second and (last) optimized XOR syndrome calculation. This version
supports right and left side optimization. All CPUs with architecture
older than Haswell will benefit from it.It should be noted that SSE2 movntdq kills performance for memory areas
that are read and written simultaneously in chunks smaller than cache
line size. So use movdqa instead for P/Q writes in sse21 and sse22 XOR
functions.Signed-off-by: Markus Stockhausen
Signed-off-by: NeilBrown -
Start the algorithms with the very basic one. It is left and right
optimized. That means we can avoid all calculations for unneeded pages
above the right stop offset. For pages below the left start offset we
still need the syndrome multiplication but without reading data pages.Signed-off-by: Markus Stockhausen
Signed-off-by: NeilBrown -
It is always helpful to have a test tool in place if we implement
new data critical algorithms. So add some test routines to the raid6
checker that can prove if the new xor_syndrome() works as expected.Run through all permutations of start/stop pages per algorithm and
simulate a xor_syndrome() assisted rmw run. After each rmw check if
the recovery algorithm still confirms that the stripe is fine.Signed-off-by: Markus Stockhausen
Signed-off-by: NeilBrown -
v3: s-o-b comment, explanation of performance and descision for
the start/stop implementationImplementing rmw functionality for RAID6 requires optimized syndrome
calculation. Up to now we can only generate a complete syndrome. The
target P/Q pages are always overwritten. With this patch we provide
a framework for inplace P/Q modification. In the first place simply
fill those functions with NULL values.xor_syndrome() has two additional parameters: start & stop. These
will indicate the first and last page that are changing during a
rmw run. That makes it possible to avoid several unneccessary loops
and speed up calculation. The caller needs to implement the following
logic to make the functions work.1) xor_syndrome(disks, start, stop, ...): "Remove" all data of source
blocks inside P/Q between (and including) start and end.2) modify any block with start
Signed-off-by: NeilBrown -
Pull char/misc driver updates from Greg KH:
"Here's the big char/misc driver patchset for 4.1-rc1.Lots of different driver subsystem updates here, nothing major, full
details are in the shortlog.All of this has been in linux-next for a while"
* tag 'char-misc-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (133 commits)
mei: trace: remove unused TRACE_SYSTEM_STRING
DTS: ARM: OMAP3-N900: Add lis3lv02d support
Documentation: DT: lis302: update wakeup binding
lis3lv02d: DT: add wakeup unit 2 and wakeup threshold
lis3lv02d: DT: use s32 to support negative values
Drivers: hv: hv_balloon: correctly handle num_pages>INT_MAX case
Drivers: hv: hv_balloon: correctly handle val.freeram directory
coresight-tmc: Adding a status interface to sysfs
coresight: remove the unnecessary configuration coresight-default-sink
...
21 Apr, 2015
3 commits
-
When CONFIG_DEBUG_FORCE_WEAK_PER_CPU is set, the DEFINE_PER_CPU_SECTION
macro will define an extern __pcpu_unique_##name variable that could
conflict with the same definition in powerpc at this time. Avoid that
conflict by renaming iommu_pool_hash in iommu-common.cThanks to Guenter Roeck for catching this, and helping to test the fix.
Signed-off-by: Sowmini Varadhan
Tested-by: Guenter Roeck
Reviewed-by: Guenter Roeck
Signed-off-by: David S. Miller -
Declare iommu_large_alloc as static. Remove extern definition for
iommu_tbl_pool_init().Signed-off-by: Sowmini Varadhan
Tested-by: Guenter Roeck
Reviewed-by: Guenter Roeck
Signed-off-by: David S. Miller -
Pull final removal of deprecated cpus_* cpumask functions from Rusty Russell:
"This is the final removal (after several years!) of the obsolete
cpus_* functions, prompted by their mis-use in staging.With these function removed, all cpu functions should only iterate to
nr_cpu_ids, so we finally only allocate that many bits when cpumasks
are allocated offstack"* tag 'cpumask-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (25 commits)
cpumask: remove __first_cpu / __next_cpu
cpumask: resurrect CPU_MASK_CPU0
linux/cpumask.h: add typechecking to cpumask_test_cpu
cpumask: only allocate nr_cpumask_bits.
Fix weird uses of num_online_cpus().
cpumask: remove deprecated functions.
mips: fix obsolete cpumask_of_cpu usage.
x86: fix more deprecated cpu function usage.
ia64: remove deprecated cpus_ usage.
powerpc: fix deprecated CPU_MASK_CPU0 usage.
CPU_MASK_ALL/CPU_MASK_NONE: remove from deprecated region.
staging/lustre/o2iblnd: Don't use cpus_weight
staging/lustre/libcfs: replace deprecated cpus_ calls with cpumask_
staging/lustre/ptlrpc: Do not use deprecated cpus_* functions
blackfin: fix up obsolete cpu function usage.
parisc: fix up obsolete cpu function usage.
tile: fix up obsolete cpu function usage.
arm64: fix up obsolete cpu function usage.
mips: fix up obsolete cpu function usage.
x86: fix up obsolete cpu function usage.
...
20 Apr, 2015
1 commit
-
The test_data_1_le[] array is a const array of const char *. To avoid
dropping any const information, we need to use "const char * const *",
not just "const char **".I'm not sure why the different test arrays end up having different
const'ness, but let's make the pointer we use to traverse them as const
as possible, since we modify neither the array of pointers _or_ the
pointers we find in the array.Signed-off-by: Linus Torvalds
19 Apr, 2015
1 commit
-
They were for use by the deprecated first_cpu() and next_cpu() wrappers,
but sparc used them directly.They're now replaced by cpumask_first / cpumask_next. And __next_cpu_nr
is completely obsolete.Signed-off-by: Rusty Russell
Acked-by: David S. Miller