aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-18tracing: Fix "gfp_t" format for synthetic eventsZhengjun Xing1-0/+2
In the format of synthetic events, the "gfp_t" is shown as "signed:1", but in fact the "gfp_t" is "unsigned", should be shown as "signed:0". The issue can be reproduced by the following commands: echo 'memlatency u64 lat; unsigned int order; gfp_t gfp_flags; int migratetype' > /sys/kernel/debug/tracing/synthetic_events cat /sys/kernel/debug/tracing/events/synthetic/memlatency/format name: memlatency ID: 2233 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:u64 lat; offset:8; size:8; signed:0; field:unsigned int order; offset:16; size:4; signed:0; field:gfp_t gfp_flags; offset:24; size:4; signed:1; field:int migratetype; offset:32; size:4; signed:1; print fmt: "lat=%llu, order=%u, gfp_flags=%x, migratetype=%d", REC->lat, REC->order, REC->gfp_flags, REC->migratetype Link: http://lkml.kernel.org/r/[email protected] Reviewed-by: Tom Zanussi <[email protected]> Signed-off-by: Zhengjun Xing <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2019-10-18net: usb: lan78xx: Connect PHY before registering MACAndrew Lunn1-6/+6
As soon as the netdev is registers, the kernel can start using the interface. If the driver connects the MAC to the PHY after the netdev is registered, there is a race condition where the interface can be opened without having the PHY connected. Change the order to close this race condition. Fixes: 92571a1aae40 ("lan78xx: Connect phy early") Reported-by: Daniel Wagner <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Tested-by: Daniel Wagner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-18Merge branch 'vsock-virtio-make-the-credit-mechanism-more-robust'David S. Miller1-3/+14
Stefano Garzarella says: ==================== vsock/virtio: make the credit mechanism more robust This series makes the credit mechanism implemented in the virtio-vsock devices more robust. Patch 1 sends an update to the remote peer when the buf_alloc change. Patch 2 prevents a malicious peer (especially the guest) can consume all the memory of the other peer, discarding packets when the credit available is not respected. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-10-18vsock/virtio: discard packets if credit is not respectedStefano Garzarella1-3/+11
If the remote peer doesn't respect the credit information (buf_alloc, fwd_cnt), sending more data than it can send, we should drop the packets to prevent a malicious peer from using all of our memory. This is patch follows the VIRTIO spec: "VIRTIO_VSOCK_OP_RW data packets MUST only be transmitted when the peer has sufficient free buffer space for the payload" Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-18vsock/virtio: send a credit update when buffer size is changedStefano Garzarella1-0/+3
When the user application set a new buffer size value, we should update the remote peer about this change, since it uses this information to calculate the credit available. Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-18mlxsw: spectrum_trap: Push Ethernet header before reporting trapIdo Schimmel1-0/+1
devlink maintains packets and bytes statistics for each trap. Since eth_type_trans() was called to set the skb's protocol, the data pointer no longer points to the start of the packet and the bytes accounting is off by 14 bytes. Fix this by pushing the skb's data pointer to the start of the packet. Fixes: b5ce611fd96e ("mlxsw: spectrum: Add devlink-trap support") Reported-by: Alex Kushnarov <[email protected]> Tested-by: Alex Kushnarov <[email protected]> Acked-by: Jiri Pirko <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-18ASoC: SOF: control: return true when kcontrol values changeDragos Tarcatu1-8/+18
All the kcontrol put() functions are currently returning 0 when successful. This does not go well with alsamixer as it does not seem to get notified on SND_CTL_EVENT_MASK_VALUE callbacks when values change for (some of) the sof kcontrols. This patch fixes that by returning true for volume, switch and enum type kcontrols when values do change in put(). Signed-off-by: Dragos Tarcatu <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-10-18ASoC: stm32: sai: fix sysclk management on shutdownOlivier Moysan1-10/+11
The commit below, adds a call to sysclk callback on shutdown. This introduces a regression in stm32 SAI driver, as some clock services are called twice, leading to unbalanced calls. Move processing related to mclk from shutdown to sysclk callback. When requested frequency is 0, assume shutdown and release mclk. Fixes: 2458adb8f92a ("SoC: simple-card-utils: set 0Hz to sysclk when shutdown") Signed-off-by: Olivier Moysan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-10-18ASoC: Intel: sof-rt5682: add a check for devm_clk_getChuhong Yuan1-0/+9
sof_audio_probe misses a check for devm_clk_get and may cause problems. Add a check for it to fix the bug. Signed-off-by: Chuhong Yuan <[email protected]> Acked-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-10-18ASoC: rsnd: Reinitialize bit clock inversion flag for every format settingJunya Monden1-0/+1
Unlike other format-related DAI parameters, rdai->bit_clk_inv flag is not properly re-initialized when setting format for new stream processing. The inversion, if requested, is then applied not to default, but to a previous value, which leads to SCKP bit in SSICR register being set incorrectly. Fix this by re-setting the flag to its initial value, determined by format. Fixes: 1a7889ca8aba3 ("ASoC: rsnd: fixup SND_SOC_DAIFMT_xB_xF behavior") Cc: Andrew Gabbasov <[email protected]> Cc: Jiada Wang <[email protected]> Cc: Timo Wischer <[email protected]> Cc: [email protected] # v3.17+ Signed-off-by: Junya Monden <[email protected]> Signed-off-by: Eugeniu Rosca <[email protected]> Acked-by: Kuninori Morimoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2019-10-18net: ensure correct skb->tstamp in various fragmentersEric Dumazet4-0/+12
Thomas found that some forwarded packets would be stuck in FQ packet scheduler because their skb->tstamp contained timestamps far in the future. We thought we addressed this point in commit 8203e2d844d3 ("net: clear skb->tstamp in forwarding paths") but there is still an issue when/if a packet needs to be fragmented. In order to meet EDT requirements, we have to make sure all fragments get the original skb->tstamp. Note that this original skb->tstamp should be zero in forwarding path, but might have a non zero value in output path if user decided so. Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Thomas Bartschies <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-18Merge tag 'mmc-v5.4-rc1' of ↵Linus Torvalds4-17/+23
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: "MMC host: - sdhci-iproc: Prevent some spurious interrupts - renesas_sdhi/sh_mmcif: Avoid false warnings about IRQs not found MEMSTICK host: - jmb38x_ms: Fix an error handling path at ->probe()" * tag 'mmc-v5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: memstick: jmb38x_ms: Fix an error handling path in 'jmb38x_ms_probe()' mmc: sdhci-iproc: fix spurious interrupts on Multiblock reads with bcm2711 mmc: sh_mmcif: Use platform_get_irq_optional() for optional interrupt mmc: renesas_sdhi: Do not use platform_get_irq() to count interrupts
2019-10-18Merge branch 'net-bcmgenet-restore-internal-EPHY-support'David S. Miller4-77/+79
Doug Berger says: ==================== net: bcmgenet: restore internal EPHY support I managed to get my hands on an old BCM97435SVMB board to do some testing with the latest kernel and uncovered a number of things that managed to get broken over the years (some by me ;). This commit set attempts to correct the errors I observed in my testing. The first commit applies to all internal PHYs to restore proper reporting of link status when a link comes up. The second commit restores the soft reset to the initialization of the older internal EPHYs used by 40nm Set-Top Box devices. The third corrects a bug I introduced when removing excessive soft resets by altering the initialization sequence in a way that keeps the GENETv3 MAC interface happy. Finally, I observed a number of issues when manually configuring the network interface of the older EPHYs that appear to be resolved by the fourth commit. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-10-18net: bcmgenet: reset 40nm EPHY on energy detectDoug Berger1-1/+8
The EPHY integrated into the 40nm Set-Top Box devices can falsely detect energy when connected to a disabled peer interface. When the peer interface is enabled the EPHY will detect and report the link as active, but on occasion may get into a state where it is not able to exchange data with the connected GENET MAC. This issue has not been observed when the link parameters are auto-negotiated; however, it has been observed with a manually configured link. It has been empirically determined that issuing a soft reset to the EPHY when energy is detected prevents it from getting into this bad state. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-18net: bcmgenet: soft reset 40nm EPHYs before MAC initDoug Berger3-73/+69
It turns out that the "Workaround for putting the PHY in IDDQ mode" used by the internal EPHYs on 40nm Set-Top Box chips when powering down puts the interface to the GENET MAC in a state that can cause subsequent MAC resets to be incomplete. Rather than restore the forced soft reset when powering up internal PHYs, this commit moves the invocation of phy_init_hw earlier in the MAC initialization sequence to just before the MAC reset in the open and resume functions. This allows the interface to be stable and allows the MAC resets to be successful. The bcmgenet_mii_probe() function is split in two to accommodate this. The new function bcmgenet_mii_connect() handles the first half of the functionality before the MAC initialization, and the bcmgenet_mii_config() function is extended to provide the remaining PHY configuration following the MAC initialization. Fixes: 484bfa1507bf ("Revert "net: bcmgenet: Software reset EPHY after power on"") Signed-off-by: Doug Berger <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-18net: phy: bcm7xxx: define soft_reset for 40nm EPHYDoug Berger1-0/+1
The internal 40nm EPHYs use a "Workaround for putting the PHY in IDDQ mode." These PHYs require a soft reset to restore functionality after they are powered back up. This commit defines the soft_reset function to use genphy_soft_reset during phy_init_hw to accommodate this. Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") Signed-off-by: Doug Berger <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-18net: bcmgenet: don't set phydev->link from MACDoug Berger1-3/+1
When commit 28b2e0d2cd13 ("net: phy: remove parameter new_link from phy_mac_interrupt()") removed the new_link parameter it set the phydev->link state from the MAC before invoking phy_mac_interrupt(). However, once commit 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in genphy_read_status") was added this initialization prevents the proper determination of the connection parameters by the function genphy_read_status(). This commit removes that initialization to restore the proper functionality. Fixes: 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in genphy_read_status") Signed-off-by: Doug Berger <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-18Merge tag 'sound-5.4-rc4' of ↵Linus Torvalds5-3/+45
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Just a few small fixes for the usual suspect, HD- and USB-audio: enablement of runtime PM for Nvidia due to the recent PCI changes, a fix for potential hangs with recent HD-audio platforms, and the rest device-specific quirks" * tag 'sound-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda - Force runtime PM on Nvidia HDMI codecs ALSA: hda/realtek - Enable headset mic on Asus MJ401TA ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers ALSA: hdac: clear link output stream mapping ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360
2019-10-18Merge branch 'watchdog-fix' into fixesTony Lindgren1-4/+14
2019-10-18bus: ti-sysc: Fix watchdog quirk handlingTony Lindgren1-4/+14
I noticed that when probed with ti-sysc, watchdog can trigger on am3, am4 and dra7 causing a device reset. Turns out I made several mistakes implementing the watchdog quirk handling: 1. We must do both writes to spr register 2. We must also call the reset quirk on disable 3. On am3 and am4 we need to also set swsup quirk flag I probably only tested this earlier with watchdog service running when the watchdog never gets disabled. Fixes: 4e23be473e30 ("bus: ti-sysc: Add support for module specific reset quirks") Signed-off-by: Tony Lindgren <[email protected]>
2019-10-18ARM: OMAP2+: Add pdata for OMAP3 ISP IOMMUSuman Anna1-0/+7
The OMAP3 ISP IOMMU does not have any reset lines, so it didn't need any pdata previously. The OMAP IOMMU driver now requires the platform data ops for device_enable/idle on all the IOMMU devices after commit db8918f61d51 ("iommu/omap: streamline enable/disable through runtime pm callbacks") to enable/disable the clocks properly and maintain the reference count and the omap_hwmod state machine. So, add these callbacks through iommu pdata quirks for the OMAP3 ISP IOMMU. Signed-off-by: Suman Anna <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2019-10-18ARM: OMAP2+: Plug in device_enable/idle ops for IOMMUsSuman Anna1-0/+4
The OMAP IOMMU driver requires the device_enable/idle platform data ops on all the IOMMU devices to be able to enable and disable the clocks after commit db8918f61d51 ("iommu/omap: streamline enable/disable through runtime pm callbacks"). Plug in these pdata ops for all the existing IOMMUs through pdata quirks to maintain functionality. Signed-off-by: Suman Anna <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2019-10-18Merge tag 'acpi-5.4-rc4' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "Fix possible use-after-free in the ACPI CPPC support code (John Garry) and prevent the ACPI HMAT parsing code from using possibly incorrect data coming from the platform firmware (Daniel Black)" * tag 'acpi-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit() ACPI: HMAT: ACPI_HMAT_MEMORY_PD_VALID is deprecated since ACPI-6.3
2019-10-18Merge tag 'pm-5.4-rc4' of ↵Linus Torvalds7-44/+27
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These include a fix for a recent regression in the ACPI CPU performance scaling code, a PCI device power management fix, a system shutdown fix related to cpufreq, a removal of an ACPI suspend-to-idle blacklist entry and a build warning fix. Specifics: - Fix possible NULL pointer dereference in the ACPI processor scaling initialization code introduced by a recent cpufreq update (Rafael Wysocki). - Fix possible deadlock due to suspending cpufreq too late during system shutdown (Rafael Wysocki). - Make the PCI device system resume code path be more consistent with its PM-runtime counterpart to fix an issue with missing delay on transitions from D3cold to D0 during system resume from suspend-to-idle on some systems (Rafael Wysocki). - Drop Dell XPS13 9360 from the LPS0 Idle _DSM blacklist to make it use suspend-to-idle by default (Mario Limonciello). - Fix build warning in the core system suspend support code (Ben Dooks)" * tag 'pm-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: processor: Avoid NULL pointer dereferences at init time PCI: PM: Fix pci_power_up() PM: sleep: include <linux/pm_runtime.h> for pm_wq cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown ACPI: PM: Drop Dell XPS13 9360 from LPS0 Idle _DSM blacklist
2019-10-18iommu/vt-d: Return the correct dma mask when we are bypassing the IOMMUArvind Sankar1-1/+9
We must return a mask covering the full physical RAM when bypassing the IOMMU mapping. Also, in iommu_need_mapping, we need to check using dma_direct_get_required_mask to ensure that the device's dma_mask can cover physical RAM before deciding to bypass IOMMU mapping. Based on an earlier patch from Christoph Hellwig. Fixes: 249baa547901 ("dma-mapping: provide a better default ->get_required_mask") Signed-off-by: Arvind Sankar <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Acked-by: Joerg Roedel <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2019-10-18perf trace: Honour --max-events in processing syscalls:sys_enter_*Arnaldo Carvalho de Melo1-6/+7
We were doing this only at the sys_exit syscall tracepoint, as for strace-like we count the pair of sys_enter and sys_exit as one event, but when asking specifically for a the syscalls:sys_enter_NAME tracepoint we need to count each of those as an event. I.e. things like: # perf trace --max-events=4 -e syscalls:sys_enter_lseek 0.000 pool/2242 syscalls:sys_enter_lseek(fd: 14<anon_inode:[timerfd]>, offset: 0, whence: CUR) 0.034 pool/2242 syscalls:sys_enter_lseek(fd: 15<anon_inode:[timerfd]>, offset: 0, whence: CUR) 0.051 pool/2242 syscalls:sys_enter_lseek(fd: 16<anon_inode:[timerfd]>, offset: 0, whence: CUR) 2307.900 sshd/30800 syscalls:sys_enter_lseek(fd: 3</usr/lib64/libsystemd.so.0.25.0>, offset: 9032, whence: SET) # Were going on forever, since we only had sys_enter events. Cc: Adrian Hunter <[email protected]> Cc: David Ahern <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-10-18Merge tag 'mkp-scsi-postmerge' of ↵Linus Torvalds1-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi Pull scsi fixes from Martin Petersen: "These two commits were in a separate postmerge branch due to a dependency on changes merged for 5.4 in the block tree. They fix two issues in the intersection of the request cleanup changes from block (b7e9e1fb7a92) and the request batching changes (8930a6c20791) that were made to SCSI during the 5.4 cycle" * tag 'mkp-scsi-postmerge' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi: scsi: core: fix dh and multipathing for SCSI hosts without request batching scsi: core: fix missing .cleanup_rq for SCSI hosts without request batching
2019-10-18libbeauty: Introduce syscall_arg__strtoul_strarray()Arnaldo Carvalho de Melo2-0/+9
To go from strarrays strings to its indexes. Cc: Adrian Hunter <[email protected]> Cc: David Ahern <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-10-18perf tools: Remove unused trace_find_next_event()Steven Rostedt (VMware)2-33/+0
trace_find_next_event() was buggy and pretty much a useless helper. As there are no more users, just remove it. Signed-off-by: Steven Rostedt (VMware) <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: [email protected] Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-10-18perf scripting engines: Iterate on tep event arrays directlySteven Rostedt (VMware)2-4/+13
Instead of calling a useless (and broken) helper function to get the next event of a tep event array, just get the array directly and iterate over it. Note, the broken part was from trace_find_next_event() which after this will no longer be used, and can be removed. Committer notes: This fixes a segfault when generating python scripts from perf.data files with multiple tracepoint events, i.e. the following use case is fixed by this patch: # perf record -e sched:* sleep 1 [ perf record: Woken up 31 times to write data ] [ perf record: Captured and wrote 0.031 MB perf.data (9 samples) ] # perf script -g python Segmentation fault (core dumped) # Reported-by: Daniel Bristot de Oliveira <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-10-18perf trace: Initialize evsel_trace->fmt for syscalls:sys_enter_* tracepointsArnaldo Carvalho de Melo1-0/+23
From the syscall_fmts->arg entries for formatting strace-like syscalls. This is when resolving the string "whence" on a filter expression for the syscalls:sys_enter_lseek: Breakpoint 3, perf_evsel__syscall_arg_fmt (evsel=0xc91ed0, arg=0x7fffffff7cd0 "whence") at builtin-trace.c:3626 3626 { (gdb) n 3628 struct syscall_arg_fmt *fmt = __evsel__syscall_arg_fmt(evsel); (gdb) n 3630 if (evsel->tp_format == NULL || fmt == NULL) (gdb) n 3633 for (field = evsel->tp_format->format.fields; field; field = field->next, ++fmt) (gdb) n 3634 if (strcmp(field->name, arg) == 0) (gdb) p field->name $3 = 0xc945e0 "__syscall_nr" (gdb) n 3633 for (field = evsel->tp_format->format.fields; field; field = field->next, ++fmt) (gdb) p *fmt $4 = {scnprintf = 0x0, strtoul = 0x0, mask_val = 0x0, parm = 0x0, name = 0x0, nr_entries = 0, show_zero = false} (gdb) n 3634 if (strcmp(field->name, arg) == 0) (gdb) p field->name $5 = 0xc94690 "fd" (gdb) n 3633 for (field = evsel->tp_format->format.fields; field; field = field->next, ++fmt) (gdb) n 3634 if (strcmp(field->name, arg) == 0) (gdb) n 3633 for (field = evsel->tp_format->format.fields; field; field = field->next, ++fmt) (gdb) n 3634 if (strcmp(field->name, arg) == 0) (gdb) p *fmt $9 = {scnprintf = 0x489be2 <syscall_arg__scnprintf_strarray>, strtoul = 0x0, mask_val = 0x0, parm = 0xa2da80 <strarray.whences>, name = 0x0, nr_entries = 0, show_zero = false} (gdb) p field->name $10 = 0xc947b0 "whence" (gdb) p fmt->parm $11 = (void *) 0xa2da80 <strarray.whences> (gdb) p *(struct strarray *)fmt->parm $12 = {offset = 0, nr_entries = 5, prefix = 0x724d37 "SEEK_", entries = 0xa2da40 <whences>} (gdb) p (struct strarray *)fmt->parm)->entries Junk after end of expression. (gdb) p ((struct strarray *)fmt->parm)->entries $13 = (const char **) 0xa2da40 <whences> (gdb) p ((struct strarray *)fmt->parm)->entries[0] $14 = 0x724d21 "SET" (gdb) p ((struct strarray *)fmt->parm)->entries[1] $15 = 0x724d25 "CUR" (gdb) p ((struct strarray *)fmt->parm)->entries[2] $16 = 0x724d29 "END" (gdb) p ((struct strarray *)fmt->parm)->entries[2] $17 = 0x724d29 "END" (gdb) p ((struct strarray *)fmt->parm)->entries[3] $18 = 0x724d2d "DATA" (gdb) p ((struct strarray *)fmt->parm)->entries[4] $19 = 0x724d32 "HOLE" (gdb) Cc: Adrian Hunter <[email protected]> Cc: David Ahern <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-10-18iommu/amd: Check PM_LEVEL_SIZE() condition in locked sectionJoerg Roedel1-3/+4
The increase_address_space() function has to check the PM_LEVEL_SIZE() condition again under the domain->lock to avoid a false trigger of the WARN_ON_ONCE() and to avoid that the address space is increase more often than necessary. Reported-by: Qian Cai <[email protected]> Fixes: 754265bcab78 ("iommu/amd: Fix race in increase_address_space()") Reviewed-by: Jerry Snitselaar <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-10-18Merge branch 'nvme-5.4' of git://git.infradead.org/nvme into for-linusJens Axboe7-64/+144
Pull NVMe updates from Keith: "This is a collection of bug fixes committed since the previous pull request that address deadlocks, double resets, memory leaks, and other regression." * 'nvme-5.4' of git://git.infradead.org/nvme: nvme-pci: Set the prp2 correctly when using more than 4k page nvme-tcp: fix possible leakage during error flow nvmet-loop: fix possible leakage during error flow nvme-tcp: Initialize sk->sk_ll_usec only with NET_RX_BUSY_POLL nvme: Wait for reset state when required nvme: Prevent resets during paused controller state nvme: Restart request timers in resetting state nvme: Remove ADMIN_ONLY state nvme-pci: Free tagset if no IO queues nvme: retain split access workaround for capability reads nvme: fix possible deadlock when nvme_update_formats fails
2019-10-18nvme-pci: Set the prp2 correctly when using more than 4k pageKevin Hao1-1/+2
In the current code, the nvme is using a fixed 4k PRP entry size, but if the kernel use a page size which is more than 4k, we should consider the situation that the bv_offset may be larger than the dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then cause the command can't be executed correctly. Fixes: dff824b2aadb ("nvme-pci: optimize mapping of small single segment requests") Cc: [email protected] Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Kevin Hao <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2019-10-18symbol namespaces: revert to previous __ksymtab name schemeMatthias Maennich3-24/+24
The introduction of Symbol Namespaces changed the naming schema of the __ksymtab entries from __kysmtab__symbol to __ksymtab_NAMESPACE.symbol. That caused some breakages in tools that depend on the name layout in either the binaries(vmlinux,*.ko) or in System.map. E.g. kmod's depmod would not be able to read System.map without a patch to support symbol namespaces. A warning reported by depmod for namespaced symbols would look like depmod: WARNING: [...]/uas.ko needs unknown symbol usb_stor_adjust_quirks In order to address this issue, revert to the original naming scheme and rather read the __kstrtabns_<symbol> entries and their corresponding values from __ksymtab_strings to update the namespace values for symbols. After having read all symbols and handled them in handle_modversions(), the symbols are created. In a second pass, read the __kstrtabns_ entries and update the namespaces accordingly. Fixes: 8651ec01daed ("module: add support for symbol namespaces.") Reported-by: Stefan Wahren <[email protected]> Suggested-by: Masahiro Yamada <[email protected]> Acked-by: Will Deacon <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Signed-off-by: Matthias Maennich <[email protected]> Signed-off-by: Jessica Yu <[email protected]>
2019-10-18modpost: make updating the symbol namespace explicitMatthias Maennich1-6/+6
Setting the symbol namespace of a symbol within sym_add_exported feels displaced and lead to issues in the current implementation of symbol namespaces. This patch makes updating the namespace an explicit call to decouple it from adding a symbol to the export list. Acked-by: Will Deacon <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Signed-off-by: Matthias Maennich <[email protected]> Signed-off-by: Jessica Yu <[email protected]>
2019-10-18modpost: delegate updating namespaces to separate functionMatthias Maennich1-3/+21
Let the function 'sym_update_namespace' take care of updating the namespace for a symbol. While this currently only replaces one single location where namespaces are updated, in a following patch, this function will get more call sites. The function signature is intentionally close to sym_update_crc and taking the name by char* seems like unnecessary work as the symbol has to be looked up again. In a later patch of this series, this concern will be addressed. This function ensures that symbol::namespace is either NULL or has a valid non-empty value. Previously, the empty string was considered 'no namespace' as well and this lead to confusion. Acked-by: Will Deacon <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Signed-off-by: Matthias Maennich <[email protected]> Signed-off-by: Jessica Yu <[email protected]>
2019-10-18x86/boot/acpi: Move get_cmdline_acpi_rsdp() under #ifdef guardZhenzhong Duan1-24/+24
When building with "EXTRA_CFLAGS=-Wall" gcc warns: arch/x86/boot/compressed/acpi.c:29:30: warning: get_cmdline_acpi_rsdp defined but not used [-Wunused-function] get_cmdline_acpi_rsdp() is only used when CONFIG_RANDOMIZE_BASE and CONFIG_MEMORY_HOTREMOVE are both enabled, so any build where one of these config options is disabled has this issue. Move the function under the same ifdef guard as the call site. [ tglx: Add context to the changelog so it becomes useful ] Fixes: 41fa1ee9c6d6 ("acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down") Signed-off-by: Zhenzhong Duan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-10-18x86/hyperv: Set pv_info.name to "Hyper-V"Andrea Parri1-0/+4
Michael reported that the x86/hyperv initialization code prints the following dmesg when running in a VM on Hyper-V: [ 0.000738] Booting paravirtualized kernel on bare hardware Let the x86/hyperv initialization code set pv_info.name to "Hyper-V" so dmesg reports correctly: [ 0.000172] Booting paravirtualized kernel on Hyper-V [ tglx: Folded build fix provided by Yue ] Reported-by: Michael Kelley <[email protected]> Signed-off-by: Andrea Parri <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Wei Liu <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Cc: YueHaibing <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-10-18Merge branch 'acpi-tables'Rafael J. Wysocki1-1/+1
* acpi-tables: ACPI: HMAT: ACPI_HMAT_MEMORY_PD_VALID is deprecated since ACPI-6.3
2019-10-18ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit()John Garry1-1/+1
When enabling KASAN and DEBUG_TEST_DRIVER_REMOVE, I find this KASAN warning: [ 20.872057] BUG: KASAN: use-after-free in pcc_data_alloc+0x40/0xb8 [ 20.878226] Read of size 4 at addr ffff00236cdeb684 by task swapper/0/1 [ 20.884826] [ 20.886309] CPU: 19 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00009-ge7f7df3db5bf-dirty #289 [ 20.894994] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019 [ 20.903505] Call trace: [ 20.905942] dump_backtrace+0x0/0x200 [ 20.909593] show_stack+0x14/0x20 [ 20.912899] dump_stack+0xd4/0x130 [ 20.916291] print_address_description.isra.9+0x6c/0x3b8 [ 20.921592] __kasan_report+0x12c/0x23c [ 20.925417] kasan_report+0xc/0x18 [ 20.928808] __asan_load4+0x94/0xb8 [ 20.932286] pcc_data_alloc+0x40/0xb8 [ 20.935938] acpi_cppc_processor_probe+0x4e8/0xb08 [ 20.940717] __acpi_processor_start+0x48/0xb0 [ 20.945062] acpi_processor_start+0x40/0x60 [ 20.949235] really_probe+0x118/0x548 [ 20.952887] driver_probe_device+0x7c/0x148 [ 20.957059] device_driver_attach+0x94/0xa0 [ 20.961231] __driver_attach+0xa4/0x110 [ 20.965055] bus_for_each_dev+0xe8/0x158 [ 20.968966] driver_attach+0x30/0x40 [ 20.972531] bus_add_driver+0x234/0x2f0 [ 20.976356] driver_register+0xbc/0x1d0 [ 20.980182] acpi_processor_driver_init+0x40/0xe4 [ 20.984875] do_one_initcall+0xb4/0x254 [ 20.988700] kernel_init_freeable+0x24c/0x2f8 [ 20.993047] kernel_init+0x10/0x118 [ 20.996524] ret_from_fork+0x10/0x18 [ 21.000087] [ 21.001567] Allocated by task 1: [ 21.004785] save_stack+0x28/0xc8 [ 21.008089] __kasan_kmalloc.isra.9+0xbc/0xd8 [ 21.012435] kasan_kmalloc+0xc/0x18 [ 21.015913] pcc_data_alloc+0x94/0xb8 [ 21.019564] acpi_cppc_processor_probe+0x4e8/0xb08 [ 21.024343] __acpi_processor_start+0x48/0xb0 [ 21.028689] acpi_processor_start+0x40/0x60 [ 21.032860] really_probe+0x118/0x548 [ 21.036512] driver_probe_device+0x7c/0x148 [ 21.040684] device_driver_attach+0x94/0xa0 [ 21.044855] __driver_attach+0xa4/0x110 [ 21.048680] bus_for_each_dev+0xe8/0x158 [ 21.052591] driver_attach+0x30/0x40 [ 21.056155] bus_add_driver+0x234/0x2f0 [ 21.059980] driver_register+0xbc/0x1d0 [ 21.063805] acpi_processor_driver_init+0x40/0xe4 [ 21.068497] do_one_initcall+0xb4/0x254 [ 21.072322] kernel_init_freeable+0x24c/0x2f8 [ 21.076667] kernel_init+0x10/0x118 [ 21.080144] ret_from_fork+0x10/0x18 [ 21.083707] [ 21.085186] Freed by task 1: [ 21.088056] save_stack+0x28/0xc8 [ 21.091360] __kasan_slab_free+0x118/0x180 [ 21.095445] kasan_slab_free+0x10/0x18 [ 21.099183] kfree+0x80/0x268 [ 21.102139] acpi_cppc_processor_exit+0x1a8/0x1b8 [ 21.106832] acpi_processor_stop+0x70/0x80 [ 21.110917] really_probe+0x174/0x548 [ 21.114568] driver_probe_device+0x7c/0x148 [ 21.118740] device_driver_attach+0x94/0xa0 [ 21.122912] __driver_attach+0xa4/0x110 [ 21.126736] bus_for_each_dev+0xe8/0x158 [ 21.130648] driver_attach+0x30/0x40 [ 21.134212] bus_add_driver+0x234/0x2f0 [ 21.0x10/0x18 [ 21.161764] [ 21.163244] The buggy address belongs to the object at ffff00236cdeb600 [ 21.163244] which belongs to the cache kmalloc-256 of size 256 [ 21.175750] The buggy address is located 132 bytes inside of [ 21.175750] 256-byte region [ffff00236cdeb600, ffff00236cdeb700) [ 21.187473] The buggy address belongs to the page: [ 21.192254] page:fffffe008d937a00 refcount:1 mapcount:0 mapping:ffff002370c0fa00 index:0x0 compound_mapcount: 0 [ 21.202331] flags: 0x1ffff00000010200(slab|head) [ 21.206940] raw: 1ffff00000010200 dead000000000100 dead000000000122 ffff002370c0fa00 [ 21.214671] raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000 [ 21.222400] page dumped because: kasan: bad access detected [ 21.227959] [ 21.229438] Memory state around the buggy address: [ 21.234218] ffff00236cdeb580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 21.241427] ffff00236cdeb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 21.248637] >ffff00236cdeb680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 21.255845] ^ [ 21.259062] ffff00236cdeb700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 21.266272] ffff00236cdeb780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 21.273480] ================================================================== It seems that global pcc_data[pcc_ss_id] can be freed in acpi_cppc_processor_exit(), but we may later reference this value, so NULLify it when freed. Also remove the useless setting of data "pcc_channel_acquired", which we're about to free. Fixes: 85b1407bf6d2 ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs") Signed-off-by: John Garry <[email protected]> Cc: 4.15+ <[email protected]> # 4.15+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-10-18Merge branches 'pm-cpufreq' and 'pm-sleep'Rafael J. Wysocki6-31/+16
* pm-cpufreq: ACPI: processor: Avoid NULL pointer dereferences at init time cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown * pm-sleep: PM: sleep: include <linux/pm_runtime.h> for pm_wq ACPI: PM: Drop Dell XPS13 9360 from LPS0 Idle _DSM blacklist
2019-10-17scsi: lpfc: remove left-over BUILD_NVME definesHannes Reinecke2-4/+0
The BUILD_NVME define never got defined anywhere, causing NVMe commands to be treated as SCSI commands when freeing the buffers. This was causing a stuck discovery and a horrible crash in lpfc_set_rrq_active() later on. Link: https://lore.kernel.org/r/[email protected] Fixes: c00f62e6c546 ("scsi: lpfc: Merge per-protocol WQ/CQ pairs into single per-cpu pair") Signed-off-by: Hannes Reinecke <[email protected]> Reviewed-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-10-17scsi: core: try to get module before removing deviceYufen Yu1-1/+10
We have a test case like block/001 in blktests, which will create a scsi device by loading scsi_debug module and then try to delete the device by sysfs interface. At the same time, it may remove the scsi_debug module. And getting a invalid paging request BUG_ON as following: [ 34.625854] BUG: unable to handle page fault for address: ffffffffa0016bb8 [ 34.629189] Oops: 0000 [#1] SMP PTI [ 34.629618] CPU: 1 PID: 450 Comm: bash Tainted: G W 5.4.0-rc3+ #473 [ 34.632524] RIP: 0010:scsi_proc_hostdir_rm+0x5/0xa0 [ 34.643555] CR2: ffffffffa0016bb8 CR3: 000000012cd88000 CR4: 00000000000006e0 [ 34.644545] Call Trace: [ 34.644907] scsi_host_dev_release+0x6b/0x1f0 [ 34.645511] device_release+0x74/0x110 [ 34.646046] kobject_put+0x116/0x390 [ 34.646559] put_device+0x17/0x30 [ 34.647041] scsi_target_dev_release+0x2b/0x40 [ 34.647652] device_release+0x74/0x110 [ 34.648186] kobject_put+0x116/0x390 [ 34.648691] put_device+0x17/0x30 [ 34.649157] scsi_device_dev_release_usercontext+0x2e8/0x360 [ 34.649953] execute_in_process_context+0x29/0x80 [ 34.650603] scsi_device_dev_release+0x20/0x30 [ 34.651221] device_release+0x74/0x110 [ 34.651732] kobject_put+0x116/0x390 [ 34.652230] sysfs_unbreak_active_protection+0x3f/0x50 [ 34.652935] sdev_store_delete.cold.4+0x71/0x8f [ 34.653579] dev_attr_store+0x1b/0x40 [ 34.654103] sysfs_kf_write+0x3d/0x60 [ 34.654603] kernfs_fop_write+0x174/0x250 [ 34.655165] __vfs_write+0x1f/0x60 [ 34.655639] vfs_write+0xc7/0x280 [ 34.656117] ksys_write+0x6d/0x140 [ 34.656591] __x64_sys_write+0x1e/0x30 [ 34.657114] do_syscall_64+0xb1/0x400 [ 34.657627] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 34.658335] RIP: 0033:0x7f156f337130 During deleting scsi target, the scsi_debug module have been removed. Then, sdebug_driver_template belonged to the module cannot be accessd, resulting in scsi_proc_hostdir_rm() BUG_ON. To fix the bug, we add scsi_device_get() in sdev_store_delete() to try to increase refcount of module, avoiding the module been removed. Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yufen Yu <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-10-17scsi: hpsa: add missing hunks in reset-patchDon Brace1-0/+4
Correct returning from reset before outstanding commands are completed for the device. Link: https://lore.kernel.org/r/157107623870.17997.11208813089704833029.stgit@brunhilda Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Kevin Barnett <[email protected]> Signed-off-by: Don Brace <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-10-17scsi: target: core: Do not overwrite CDB byte 1Bodo Stroesser1-21/+0
passthrough_parse_cdb() - used by TCMU and PSCSI - attepts to reset the LUN field of SCSI-2 CDBs (bits 5,6,7 of byte 1). The current code is wrong as for newer commands not having the LUN field it overwrites relevant command bits (e.g. for SECURITY PROTOCOL IN / OUT). We think this code was unnecessary from the beginning or at least it is no longer useful. So we remove it entirely. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bodo Stroesser <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-10-17net: Update address for MediaTek ethernet driver in MAINTAINERSSean Wang1-1/+1
Update maintainers for MediaTek ethernet driver with Mark Lee. He is familiar with MediaTek mt762x series ethernet devices and will keep following maintenance from the vendor side. Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Mark Lee <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-17Merge tag 'arm64-fixes' of ↵Linus Torvalds15-23/+186
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "The main thing here is a long-awaited workaround for a CPU erratum on ThunderX2 which we have developed in conjunction with engineers from Cavium/Marvell. At the moment, the workaround is unconditionally enabled for affected CPUs at runtime but we may add a command-line option to disable it in future if performance numbers show up indicating a significant cost for real workloads. Summary: - Work around Cavium/Marvell ThunderX2 erratum #219 - Fix regression in mlock() ABI caused by sign-extension of TTBR1 addresses - More fixes to the spurious kernel fault detection logic - Fix pathological preemption race when enabling some CPU features at boot - Drop broken kcore macros in favour of generic implementations - Fix userspace view of ID_AA64ZFR0_EL1 when SVE is disabled - Avoid NULL dereference on allocation failure during hibernation" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: tags: Preserve tags for addresses translated via TTBR1 arm64: mm: fix inverted PAR_EL1.F check arm64: sysreg: fix incorrect definition of SYS_PAR_EL1_F arm64: entry.S: Do not preempt from IRQ before all cpufeatures are enabled arm64: hibernate: check pgd table allocation arm64: cpufeature: Treat ID_AA64ZFR0_EL1 as RAZ when SVE is not enabled arm64: Fix kcore macros after 52-bit virtual addressing fallout arm64: Allow CAVIUM_TX2_ERRATUM_219 to be selected arm64: Avoid Cavium TX2 erratum 219 when switching TTBR arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT arm64: KVM: Trap VM ops when ARM64_WORKAROUND_CAVIUM_TX2_219_TVM is set
2019-10-17ipv4: fix race condition between route lookup and invalidationWei Wang1-1/+1
Jesse and Ido reported the following race condition: <CPU A, t0> - Received packet A is forwarded and cached dst entry is taken from the nexthop ('nhc->nhc_rth_input'). Calls skb_dst_set() <t1> - Given Jesse has busy routers ("ingesting full BGP routing tables from multiple ISPs"), route is added / deleted and rt_cache_flush() is called <CPU B, t2> - Received packet B tries to use the same cached dst entry from t0, but rt_cache_valid() is no longer true and it is replaced in rt_cache_route() by the newer one. This calls dst_dev_put() on the original dst entry which assigns the blackhole netdev to 'dst->dev' <CPU A, t3> - dst_input(skb) is called on packet A and it is dropped due to 'dst->dev' being the blackhole netdev There are 2 issues in the v4 routing code: 1. A per-netns counter is used to do the validation of the route. That means whenever a route is changed in the netns, users of all routes in the netns needs to redo lookup. v6 has an implementation of only updating fn_sernum for routes that are affected. 2. When rt_cache_valid() returns false, rt_cache_route() is called to throw away the current cache, and create a new one. This seems unnecessary because as long as this route does not change, the route cache does not need to be recreated. To fully solve the above 2 issues, it probably needs quite some code changes and requires careful testing, and does not suite for net branch. So this patch only tries to add the deleted cached rt into the uncached list, so user could still be able to use it to receive packets until it's done. Fixes: 95c47f9cf5e0 ("ipv4: call dst_dev_put() properly") Signed-off-by: Wei Wang <[email protected]> Reported-by: Ido Schimmel <[email protected]> Reported-by: Jesse Hathaway <[email protected]> Tested-by: Jesse Hathaway <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Cc: David Ahern <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-17Merge tag 'xtensa-20191017' of git://github.com/jcmvbkbc/linux-xtensaLinus Torvalds4-50/+55
Pull Xtensa fixes from Max Filippov: - fix {get,put}_user() for 64bit values - fix warning about static EXPORT_SYMBOL from modpost - fix PCI IO ports mapping for the virt board - fix pasto in change_bit for exclusive access option * tag 'xtensa-20191017' of git://github.com/jcmvbkbc/linux-xtensa: xtensa: fix change_bit in exclusive access option xtensa: virt: fix PCI IO ports mapping xtensa: drop EXPORT_SYMBOL for outs*/ins* xtensa: fix type conversion in __get_user_[no]check xtensa: clean up assembly arguments in uaccess macros xtensa: fix {get,put}_user() for 64bit values