13 Feb, 2017
13 commits
-
In the MMC subsystem, we see such initializers that only clears the
first member explicitly.For example,
struct mmc_request mrq = {NULL};
sets the first member (.sbc) to NULL explicitly. However, this is
an unstable form because we may insert a non-pointer member at the
top of the struct mmc_request in the future. (if we do so, the
compiler will spit warnings.)So, using a designated initializer is preferred coding style. The
expression above is equivalent to:struct mmc_request mrq = { .sbc = NULL };
Of course, this does not express our intention. We want to fill
all struct members with zeros. Please note struct members are
implicitly zero-cleared unless otherwise specified in the initializer.After all, the most reasonable (and stable) form is:
struct mmc_request mrq = {};
Do likewise for mmc_command, mmc_data as well.
Signed-off-by: Masahiro Yamada
Reviewed-by: Linus Walleij
Signed-off-by: Ulf Hansson -
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Ulf Hansson -
With gcc-4.1.2:
mmc/core/block.c: In function ‘mmc_blk_issue_discard_rq’:
mmc/core/block.c:1150: warning: ‘arg’ may be used uninitialized in this function
mmc/core/block.c:1150: warning: ‘nr’ may be used uninitialized in this function
mmc/core/block.c:1150: warning: ‘from’ may be used uninitialized in this functionWhile this is a false positive, it can be avoided easily by jumping over
the checks for "err" that are always false.Signed-off-by: Geert Uytterhoeven
Signed-off-by: Ulf Hansson -
In the eMMC 5.0 version of the spec, several EXT_CSD fields about
device lifetime are added.- Two types of estimated indications reflected by averaged wear out of memory
- An indication reflected by average reserved blocksExport the information through sysfs.
Signed-off-by: Jungseung Lee
Reviewed-by: Jaehoon Chung
Reviewed-by: Shawn Lin
Signed-off-by: Ulf Hansson -
Setup tuning when the board is HS200 enabled.
Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson -
The function will only be available if SDR104 was detected in probe,
so no need to check in the function itself again.Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson -
The function will only be available if SDR104 was detected in probe,
so no need to check in the function itself again.Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson -
The capability for HW_RESET is only activated if SDR104 is present, so
no need to check for SDR104 in the function itself again.Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson -
Prerequisites for tuning are the same as for hw_reset. We need an SCC
and a supported mode. Populate the tuning related functions only when
those conditions are met. This also removes a tiny race window.
Previously, the functions were populated when the SCC offset was not
initialized which could have led to an OOPS.Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson -
We need a SCC unit for hw_reset. Those units can only be described in
of_data. So, of_data and a valid SCC offset are prerequisites for
enabling the hw_reset capability. Merge the two 'if' conditions into one
and add a check for an scc offset.Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Ulf Hansson -
By using the helper of_device_get_match_data(), we can skip some
checking and make the code simpler.Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Ulf Hansson -
The master bit to enable SDIO interrupts can only be accessed if
SCLKDIVEN bit allows that. However, the core uses the SDIO enable
callback at times when SCLKDIVEN forbids the change. This leads to
"timeout waiting for SD bus idle" messages.We now activate the master bit in probe once if SDIO is supported. IRQ
en-/disabling will be done now by the individual IRQ enablement bits
only.Signed-off-by: Wolfram Sang
Reviewed-by: Yasushi SHOJI
Signed-off-by: Ulf Hansson
12 Feb, 2017
7 commits
-
Pull x86 fixes from Ingo Molnar:
"Last minute x86 fixes:- Fix a softlockup detector warning and long delays if using ptdump
with KASAN enabled.- Two more TSC-adjust fixes for interesting firmware interactions.
- Two commits to fix an AMD CPU topology enumeration bug that caused
a measurable gaming performance regression"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mm/ptdump: Fix soft lockup in page table walker
x86/tsc: Make the TSC ADJUST sanitizing work for tsc_reliable
x86/tsc: Avoid the large time jump when sanitizing TSC ADJUST
x86/CPU/AMD: Fix Zen SMT topology
x86/CPU/AMD: Bring back Compute Unit ID -
Pull timer fix from Ingo Molnar:
"Fix a sporadic missed timer hw reprogramming bug that can result in
random delays"* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tick/nohz: Fix possible missing clock reprog after tick soft restart -
Pull perf fixes from Ingo Molnar:
"A kernel crash fix plus three tooling fixes"* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/core: Fix crash in perf_event_read()
perf callchain: Reference count maps
perf diff: Fix -o/--order option behavior (again)
perf diff: Fix segfault on 'perf diff -o N' option -
Pull lockdep fix from Ingo Molnar:
"This fixes an ugly lockdep stack trace output regression. (But also
affects other stacktrace users such as kmemleak, KASAN, etc)"* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
stacktrace, lockdep: Fix address, newline ugliness -
Pull irq fixes from Ingo Molnar:
"Two last minute ARM irqchip driver fixes"* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/mxs: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND
irqchip/keystone: Fix "scheduling while atomic" on rt -
Pull btrfs fixes from Chris Mason:
"This has two last minute fixes. The highest priority here is a
regression fix for the decompression code, but we also fixed up a
problem with the 32-bit compat ioctls.The decompression bug could hand back the wrong data on big reads when
zlib was used. I have a larger cleanup to make the math here less
error prone, but at this stage in the release Omar's patch is the best
choice"* 'for-linus-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
btrfs: fix btrfs_decompress_buf2page()
btrfs: fix btrfs_compat_ioctl failures on non-compat ioctls -
Pull SCSI fixes from James Bottomley:
"Six fairly small fixes. None is a real show stopper, two automation
detected problems: one memory leak, one use after free and four others
each of which fixes something that has been a significant source of
annoyance to someone"* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: zfcp: fix use-after-free by not tracing WKA port open/close on failed send
scsi: aacraid: Fix INTx/MSI-x issue with older controllers
scsi: mpt3sas: disable ASPM for MPI2 controllers
scsi: mpt3sas: Force request partial completion alignment
scsi: qla2xxx: Avoid that issuing a LIP triggers a kernel crash
scsi: qla2xxx: Fix a recently introduced memory leak
11 Feb, 2017
13 commits
-
If btrfs_decompress_buf2page() is handed a bio with its page in the
middle of the working buffer, then we adjust the offset into the working
buffer. After we copy into the bio, we advance the iterator by the
number of bytes we copied. Then, we have some logic to handle the case
of discontiguous pages and adjust the offset into the working buffer
again. However, if we didn't advance the bio to a new page, we may enter
this case in error, essentially repeating the adjustment that we already
made when we entered the function. The end result is bogus data in the
bio.Previously, we only checked for this case when we advanced to a new
page, but the conversion to bio iterators changed that. This restores
the old, correct behavior.A case I saw when testing with zlib was:
buf_start = 42769
total_out = 46865
working_bytes = total_out - buf_start = 4096
start_byte = 45056The condition (total_out > start_byte && buf_start < start_byte) is
true, so we adjust the offset:buf_offset = start_byte - buf_start = 2287
working_bytes -= buf_offset = 1809
current_buf_start = buf_start = 42769Then, we copy
bytes = min(bvec.bv_len, PAGE_SIZE - buf_offset, working_bytes) = 1809
buf_offset += bytes = 4096
working_bytes -= bytes = 0
current_buf_start += bytes = 44578After bio_advance(), we are still in the same page, so start_byte is the
same. Then, we check (total_out > start_byte && current_buf_start < start_byte),
which is true! So, we adjust the values again:buf_offset = start_byte - buf_start = 2287
working_bytes = total_out - start_byte = 1809
current_buf_start = buf_start + buf_offset = 45056But note that working_bytes was already zero before this, so we should
have stopped copying.Fixes: 974b1adc3b10 ("btrfs: use bio iterators for the decompression handlers")
Reported-by: Pat Erley
Reviewed-by: Chris Mason
Signed-off-by: Omar Sandoval
Signed-off-by: Chris Mason
Reviewed-by: Liu Bo
Tested-by: Liu Bo -
Pull networking fixes from David Miller:
1) If the timing is wrong we can indefinitely stop generating new ipv6
temporary addresses, from Marcus Huewe.2) Don't double free per-cpu stats in ipv6 SIT tunnel driver, from Cong
Wang.3) Put protections in place so that AF_PACKET is not able to submit
packets which don't even have a link level header to drivers. From
Willem de Bruijn.4) Fix memory leaks in ipv4 and ipv6 multicast code, from Hangbin Liu.
5) Don't use udp_ioctl() in l2tp code, UDP version expects a UDP socket
and that doesn't go over very well when it is passed an L2TP one.
Fix from Eric Dumazet.6) Don't crash on NULL pointer in phy_attach_direct(), from Florian
Fainelli.* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
l2tp: do not use udp_ioctl()
xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()
NET: mkiss: Fix panic
net: hns: Fix the device being used for dma mapping during TX
net: phy: Initialize mdio clock at probe function
igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()
xen-netfront: Improve error handling during initialization
sierra_net: Skip validating irrelevant fields for IDLE LSIs
sierra_net: Add support for IPv6 and Dual-Stack Link Sense Indications
kcm: fix 0-length case for kcm_sendmsg()
xen-netfront: Rework the fix for Rx stall during OOM and network stress
net: phy: Fix PHY module checks and NULL deref in phy_attach_direct()
net: thunderx: Fix PHY autoneg for SGMII QLM mode
net: dsa: Do not destroy invalid network devices
ping: fix a null pointer dereference
packet: round up linear to header len
net: introduce device min_header_len
sit: fix a double free on error path
lwtunnel: valid encap attr check should return 0 when lwtunnel is disabled
ipv6: addrconf: fix generation of new temporary addresses -
Pull rdma fixes from Doug Ledford:
"Third round of -rc fixes for 4.10 kernel:- two security related issues in the rxe driver
- one compile issue in the RDMA uapi header"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
RDMA: Don't reference kernel private header from UAPI header
IB/rxe: Fix mem_check_range integer overflow
IB/rxe: Fix resid update -
Pull i2c bugfixes from Wolfram Sang:
"Two bugfixes (proper IO mapping and use of mutex) for a driver feature
we introduced in this cycle"* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: piix4: Request the SMBUS semaphore inside the mutex
i2c: piix4: Fix request_region size -
Pull MMC host fix from Ulf Hansson:
"mmci: Fix hang while waiting for busy-end interrupt"* tag 'mmc-v4.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: mmci: avoid clearing ST Micro busy end interrupt mistakenly -
Pull sound fixes from Takashi Iwai:
"Here are some last-minute fixes: two fixes for races in ALSA sequencer
queue spotted by syzkaller, a revert for a regression of LINE6 driver
(since 4.9), and a trivial new codec ID addition for Nvidia HDMI"* tag 'sound-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - adding a new NV HDMI/DP codec ID in the driver
ALSA: seq: Fix race at creating a queue
Revert "ALSA: line6: Only determine control port properties if needed"
ALSA: seq: Don't handle loop timeout at snd_seq_pool_done() -
Pull nfsd revert from Bruce Fields:
"This patch turned out to have a couple problems. The problems are
fixable, but at least one of the fixes is a little ugly. The original
bug has always been there, so we can wait another week or two to get
this right"* tag 'nfsd-4.10-3' of git://linux-nfs.org/~bfields/linux:
nfsd: Revert "nfsd: special case truncates some more" -
Pull powerpc fixes friom Michael Ellerman:
"Apologies for the late pull request, but Ben has been busy finding bugs.- Userspace was semi-randomly segfaulting on radix due to us
incorrectly handling a fault triggered by autonuma, caused by a
patch we merged earlier in v4.10 to prevent the kernel executing
userspace.- We weren't marking host IPIs properly for KVM in the OPAL ICP
backend.- The ERAT flushing on radix was missing an isync and was incorrectly
marked as DD1 only.- The powernv CPU hotplug code was missing a wakeup type and failing
to flush the interrupt correctly when using OPAL ICPThanks to Benjamin Herrenschmidt"
* tag 'powerpc-4.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/powernv: Properly set "host-ipi" on IPIs
powerpc/powernv: Fix CPU hotplug to handle waking on HVI
powerpc/mm/radix: Update ERAT flushes when invalidating TLB
powerpc/mm: Fix spurrious segfaults on radix with autonuma -
udp_ioctl(), as its name suggests, is used by UDP protocols,
but is also used by L2TP :(L2TP should use its own handler, because it really does not
look the same.SIOCINQ for instance should not assume UDP checksum or headers.
Thanks to Andrey and syzkaller team for providing the report
and a nice reproducer.While crashes only happen on recent kernels (after commit
7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue")), this
probably needs to be backported to older kernels.Fixes: 7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue")
Fixes: 85584672012e ("udp: Fix udp_poll() and ioctl()")
Signed-off-by: Eric Dumazet
Reported-by: Andrey Konovalov
Acked-by: Paolo Abeni
Signed-off-by: David S. Miller -
…linux into for-linus-4.10
-
rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may dereference
queue->rx.sring which is set to NULL in xennet_disconnect_backend().Signed-off-by: Boris Ostrovsky
CC: stable@vger.kernel.org
Reviewed-by: Juergen Gross
Signed-off-by: David S. Miller -
If a USB-to-serial adapter is unplugged, the driver re-initializes, with
dev->hard_header_len and dev->addr_len set to zero, instead of the correct
values. If then a packet is sent through the half-dead interface, the
kernel will panic due to running out of headroom in the skb when pushing
for the AX.25 headers resulting in this panic:[] (skb_panic) from [] (skb_push+0x4c/0x50)
[] (skb_push) from [] (ax25_hard_header+0x34/0xf4 [ax25])
[] (ax25_hard_header [ax25]) from [] (ax_header+0x38/0x40 [mkiss])
[] (ax_header [mkiss]) from [] (neigh_compat_output+0x8c/0xd8)
[] (neigh_compat_output) from [] (ip_finish_output+0x2a0/0x914)
[] (ip_finish_output) from [] (ip_output+0xd8/0xf0)
[] (ip_output) from [] (ip_local_out_sk+0x44/0x48)This patch makes mkiss behave like the 6pack driver. 6pack does not
panic. In 6pack.c sp_setup() (same function name here) the values for
dev->hard_header_len and dev->addr_len are set to the same values as in
my mkiss patch.[ralf@linux-mips.org: Massages original submission to conform to the usual
standards for patch submissions.]Signed-off-by: Thomas Osterried
Signed-off-by: Ralf Baechle
Signed-off-by: David S. Miller -
This patch fixes the device being used to DMA map skb->data.
Erroneous device assignment causes the crash when SMMU is enabled.
This happens during TX since buffer gets DMA mapped with device
correspondign to net_device and gets unmapped using the device
related to DSAF.Signed-off-by: Kejian Yan
Reviewed-by: Yisen Zhuang
Signed-off-by: Salil Mehta
Signed-off-by: David S. Miller
10 Feb, 2017
7 commits
-
Pull irqchip fixes for v4.10 from Jason Cooper
- keystone: Fix scheduling while atomic for realtime
- mxs: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND -
CONFIG_KASAN=y needs a lot of virtual memory mapped for its shadow.
In that case ptdump_walk_pgd_level_core() takes a lot of time to
walk across all page tables and doing this without
a rescheduling causes soft lockups:NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [swapper/0:1]
...
Call Trace:
ptdump_walk_pgd_level_core+0x40c/0x550
ptdump_walk_pgd_level_checkwx+0x17/0x20
mark_rodata_ro+0x13b/0x150
kernel_init+0x2f/0x120
ret_from_fork+0x2c/0x40I guess that this issue might arise even without KASAN on huge machines
with several terabytes of RAM.Stick cond_resched() in pgd loop to fix this.
Reported-by: Tobias Regnery
Signed-off-by: Andrey Ryabinin
Cc: kasan-dev@googlegroups.com
Cc: Alexander Potapenko
Cc: "Paul E . McKenney"
Cc: Dmitry Vyukov
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20170210095405.31802-1-aryabinin@virtuozzo.com
Signed-off-by: Thomas Gleixner -
When the TSC is marked reliable then the synchronization check is skipped,
but that also skips the TSC ADJUST sanitizing code. So on a machine with a
wreckaged BIOS the TSC deviation between CPUs might go unnoticed.Let the TSC adjust sanitizing code run unconditionally and just skip the
expensive synchronization checks when TSC is marked reliable.Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Olof Johansson
Link: http://lkml.kernel.org/r/20170209151231.491189912@linutronix.de
Signed-off-by: Thomas Gleixner -
Olof reported that on a machine which has a BIOS wreckaged TSC the
timestamps in dmesg are making a large jump because the TSC value is
jumping forward after resetting the TSC ADJUST register to a sane value.This can be avoided by calling the TSC ADJUST saniziting function before
initializing the per cpu sched clock machinery. That takes the offset into
account and avoid the time jump.What cannot be avoided is that the 'Firmware Bug' warnings on the secondary
CPUs are printed with the large time offsets because it would be too much
effort and ugly hackery to print those warnings into a buffer and emit them
after the adjustemt on the starting CPUs. It's a firmware bug and should be
fixed in firmware. The weird timestamps are collateral damage and just
illustrate the sillyness of the BIOS folks:[ 0.397445] smp: Bringing up secondary CPUs ...
[ 0.402100] x86: Booting SMP configuration:
[ 0.406343] .... node #0, CPUs: #1
[1265776479.930667] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2978888639075328 CPU1: -2978888639183101
[1265776479.944664] TSC ADJUST synchronize: Reference CPU0: 0 CPU1: -2978888639183101
[ 0.508119] #2
[1265776480.032346] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2978888639075328 CPU2: -2978888639183677
[1265776480.044192] TSC ADJUST synchronize: Reference CPU0: 0 CPU2: -2978888639183677
[ 0.607643] #3
[1265776480.131874] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2978888639075328 CPU3: -2978888639184530
[1265776480.143720] TSC ADJUST synchronize: Reference CPU0: 0 CPU3: -2978888639184530
[ 0.707108] smp: Brought up 1 node, 4 CPUs
[ 0.711271] smpboot: Total of 4 processors activated (21698.88 BogoMIPS)Reported-by: Olof Johansson
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20170209151231.411460506@linutronix.de
Signed-off-by: Thomas Gleixner -
ts->next_tick keeps track of the next tick deadline in order to optimize
clock programmation on irq exit and avoid redundant clock device writes.Now if ts->next_tick missed an update, we may spuriously miss a clock
reprog later as the nohz code is fooled by an obsolete next_tick value.This is what happens here on a specific path: when we observe an
expired timer from the nohz update code on irq exit, we perform a soft
tick restart which simply fires the closest possible tick without
actually exiting the nohz mode and restoring a periodic state. But we
forget to update ts->next_tick accordingly.As a result, after the next tick resulting from such soft tick restart,
the nohz code sees a stale value on ts->next_tick which doesn't match
the clock deadline that just expired. If that obsolete ts->next_tick
value happens to collide with the actual next tick deadline to be
scheduled, we may spuriously bypass the clock reprogramming. In the
worst case, the tick may never fire again.Fix this with a ts->next_tick reset on soft tick restart.
Signed-off-by: Frederic Weisbecker
Reviewed: Wanpeng Li
Acked-by: Rik van Riel
Cc: Peter Zijlstra
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1486485894-29173-1-git-send-email-fweisbec@gmail.com
Signed-off-by: Thomas Gleixner -
Alexei had his box explode because doing read() on a package
(rapl/uncore) event that isn't currently scheduled in ends up doing an
out-of-bounds load.Rework the code to more explicitly deal with event->oncpu being -1.
Reported-by: Alexei Starovoitov
Tested-by: Alexei Starovoitov
Tested-by: David Carrillo-Cisneros
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: eranian@google.com
Fixes: d6a2f9035bfc ("perf/core: Introduce PMU_EV_CAP_READ_ACTIVE_PKG")
Link: http://lkml.kernel.org/r/20170131102710.GL6515@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar
