perf tools: Update x86's syscall_64.tbl, adding 'io_pgetevents' and 'rseq'
This updates the tools/perf/ copy of the system call table for x86 which makes
'perf trace' become aware of the new 'io_pgetevents' and 'rseq' syscalls, no
matter in which system it gets built, i.e. older systems where the syscalls are
not available in the running kernel (via tracefs) or in the system headers will
still be aware of these syscalls/.
These are the csets introducing the source drift:
05c17cedf85b ("x86: Wire up restartable sequence system call") 7a074e96dee6 ("aio: implement io_pgetevents")
This silences the following tools/perf/ build warning:
Warning: Kernel ABI header at 'tools/perf/arch/x86/entry/syscalls/syscall_64.tbl' differs from latest version at 'arch/x86/entry/syscalls/syscall_64.tbl'
7595bda2fb43 ("drm: Add DRM client cap for aspect-ratio")
The DRM caps are not yet being decoded in 'perf trace', so this sync
doesn't incur in any change in behaviour in any tools, just silencing
this tools/perf/ build warning:
Warning: Kernel ABI header at 'tools/include/uapi/drm/drm.h' differs from latest version at 'include/uapi/drm/drm.h'
Jiri Olsa [Mon, 11 Jun 2018 09:34:22 +0000 (11:34 +0200)]
perf tests: Add valid callback for parse-events test
Adding optional 'valid' callback for events tests in parse-events
object, so we don't try to parse PMUs, which are not supported.
Following line is displayed for skipped test:
running test 52 'intel_pt//u'... SKIP
Committer note:
Use named initializers in the struct evlist_test variable to avoid
breaking the build on centos:5, 6 and others with a similar gcc:
cc1: warnings being treated as errors
tests/parse-events.c: In function 'test_pmu_events':
tests/parse-events.c:1817: error: missing initializer
tests/parse-events.c:1817: error: (near initialization for 'e.type')
Adding the struct parse_events_error argument to parse_events call. Also
adding parse_events_print_error to get more details on the parsing
failures, like:
Use named initializers in the struct parse_events_error variable to
avoid breaking the build on centos5, 6 and others with a similar gcc:
cc1: warnings being treated as errors
tests/parse-events.c: In function 'test_event':
tests/parse-events.c:1696: error: missing initializer
tests/parse-events.c:1696: error: (near initialization for 'err.str')
Sandipan Das [Mon, 11 Jun 2018 10:40:49 +0000 (16:10 +0530)]
perf report powerpc: Fix crash if callchain is empty
For some cases, the callchain provided by the kernel may be empty. So,
the callchain ip filtering code will cause a crash if we do not check
whether the struct ip_callchain pointer is NULL before accessing any
members.
This can be observed on a powerpc64le system running Fedora 27 as shown
below.
Thomas Richter [Mon, 11 Jun 2018 07:31:53 +0000 (09:31 +0200)]
perf test session topology: Fix test on s390
On s390 this test case fails because the socket identifiction numbers
assigned to the CPU are higher than the CPU identification numbers.
F/ix this by adding the platform architecture into the perf data header
flag information. This helps identifiing the test platform and handles
s390 specifics in process_cpu_topology().
Before:
[root@p23lp27 perf]# perf test -vvvvv -F 39
39: Session topology :
--- start ---
templ file: /tmp/perf-test-iUv755
socket_id number is too big.You may need to upgrade the perf tool.
---- end ----
Session topology: Skip
[root@p23lp27 perf]#
After:
[root@p23lp27 perf]# perf test -vvvvv -F 39
39: Session topology :
--- start ---
templ file: /tmp/perf-test-8X8VTs
CPU 0, core 0, socket 6
CPU 1, core 1, socket 3
---- end ----
Session topology: Ok
[root@p23lp27 perf]#
Thomas Richter [Mon, 11 Jun 2018 07:31:52 +0000 (09:31 +0200)]
perf record: Support s390 random socket_id assignment
On s390 the socket identifier assigned to a CPU identifier is random and
(depending on the configuration of the LPAR) may be higher than the CPU
identifier. This is currently not supported.
Fix this by allowing arbitrary socket identifiers being assigned to
CPU id.
Output before:
[root@p23lp27 perf]# ./perf report --header -I -v
...
socket_id number is too big.You may need to upgrade the perf tool.
Error:
The perf.data file has no samples!
# ========
# captured on : Tue May 29 09:29:57 2018
# header version : 1
...
# Core ID and Socket ID information is not available
...
[root@p23lp27 perf]#
Output after:
[root@p23lp27 perf]# ./perf report --header -I -v
...
Error:
The perf.data file has no samples!
# ========
# captured on : Tue May 29 09:29:57 2018
# header version : 1
...
# CPU 0: Core ID 0, Socket ID 6
# CPU 1: Core ID 1, Socket ID 3
# CPU 2: Core ID -1, Socket ID -1
...
[root@p23lp27 perf]#
Laura Abbott [Mon, 11 Jun 2018 18:06:53 +0000 (11:06 -0700)]
staging: android: ion: Return an ERR_PTR in ion_map_kernel
The expected return value from ion_map_kernel is an ERR_PTR. The error
path for a vmalloc failure currently just returns NULL, triggering
a warning in ion_buffer_kmap_get. Encode the vmalloc failure as an ERR_PTR.
Dirk Gouders [Thu, 21 Jun 2018 13:30:54 +0000 (15:30 +0200)]
kconfig: fix line numbers for if-entries in menu tree
The line numers for if-entries in the menu tree are off by one or more
lines which is confusing when debugging for correctness of unrelated changes.
According to the git log, commit a02f0570ae201c49 (kconfig: improve
error handling in the parser) was the last one that changed that part
of the parser and replaced
"if_entry: T_IF expr T_EOL"
by
"if_entry: T_IF expr nl"
but the commit message does not state why this has been done.
When reverting that part of the commit, only the line numers are
corrected (checked with cdebug = DEBUG_PARSE in zconf.y), otherwise
the menu tree remains unchanged (checked with zconfdump() enabled in
conf.c).
Sven Joachim [Mon, 18 Jun 2018 17:45:25 +0000 (19:45 +0200)]
stack-protector: Fix test with 32-bit userland and CONFIG_64BIT=y
When building a 64-bit 4.18-rc1 kernel with a 32-bit userland, I
noticed that stack protection was silently disabled. Adding -m64 in
gcc-x86_64-has-stack-protector.sh fixed that, similar to what has been
noticed in commit 2a61f4747eea ("stack-protector: test compiler
capability in Kconfig and drop AUTO mode") for
gcc-x86_32-has-stack-protector.sh.
Paul Burton [Tue, 19 Jun 2018 20:14:58 +0000 (13:14 -0700)]
powerpc: Remove -Wattribute-alias pragmas
With SYSCALL_DEFINEx() disabling -Wattribute-alias generically, there's
no need to duplicate that for PowerPC syscalls.
This reverts commit 415520373975 ("powerpc: fix build failure by
disabling attribute-alias warning in pci_32") and commit 2479bfc9bc60
("powerpc: Fix build by disabling attribute-alias warning for
SYSCALL_DEFINEx").
Arnd Bergmann [Tue, 19 Jun 2018 20:14:57 +0000 (13:14 -0700)]
disable -Wattribute-alias warning for SYSCALL_DEFINEx()
gcc-8 warns for every single definition of a system call entry
point, e.g.:
include/linux/compat.h:56:18: error: 'compat_sys_rt_sigprocmask' alias between functions of incompatible types 'long int(int, compat_sigset_t *, compat_sigset_t *, compat_size_t)' {aka 'long int(int, struct <anonymous> *, struct <anonymous> *, unsigned int)'} and 'long int(long int, long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))\
^~~~~~~~~~
include/linux/compat.h:45:2: note: in expansion of macro 'COMPAT_SYSCALL_DEFINEx'
COMPAT_SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
^~~~~~~~~~~~~~~~~~~~~~
kernel/signal.c:2601:1: note: in expansion of macro 'COMPAT_SYSCALL_DEFINE4'
COMPAT_SYSCALL_DEFINE4(rt_sigprocmask, int, how, compat_sigset_t __user *, nset,
^~~~~~~~~~~~~~~~~~~~~~
include/linux/compat.h:60:18: note: aliased declaration here
asmlinkage long compat_SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__))\
^~~~~~~~~~
The new warning seems reasonable in principle, but it doesn't
help us here, since we rely on the type mismatch to sanitize the
system call arguments. After I reported this as GCC PR82435, a new
-Wno-attribute-alias option was added that could be used to turn the
warning off globally on the command line, but I'd prefer to do it a
little more fine-grained.
Interestingly, turning a warning off and on again inside of
a single macro doesn't always work, in this case I had to add
an extra statement inbetween and decided to copy the __SC_TEST
one from the native syscall to the compat syscall macro. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256 for more details
about this.
[[email protected]:
- Rebase atop current master.
- Split GCC & version arguments to __diag_ignore() in order to match
changes to the preceding patch.
- Add the comment argument to match the preceding patch.]
Arnd Bergmann [Tue, 19 Jun 2018 20:14:56 +0000 (13:14 -0700)]
kbuild: add macro for controlling warnings to linux/compiler.h
I have occasionally run into a situation where it would make sense to
control a compiler warning from a source file rather than doing so from
a Makefile using the $(cc-disable-warning, ...) or $(cc-option, ...)
helpers.
The approach here is similar to what glibc uses, using __diag() and
related macros to encapsulate a _Pragma("GCC diagnostic ...") statement
that gets turned into the respective "#pragma GCC diagnostic ..." by
the preprocessor when the macro gets expanded.
Like glibc, I also have an argument to pass the affected compiler
version, but decided to actually evaluate that one. For now, this
supports GCC_4_6, GCC_4_7, GCC_4_8, GCC_4_9, GCC_5, GCC_6, GCC_7,
GCC_8 and GCC_9. Adding support for CLANG_5 and other interesting
versions is straightforward here. GNU compilers starting with gcc-4.2
could support it in principle, but "#pragma GCC diagnostic push"
was only added in gcc-4.6, so it seems simpler to not deal with those
at all. The same versions show a large number of warnings already,
so it seems easier to just leave it at that and not do a more
fine-grained control for them.
The use cases I found so far include:
- turning off the gcc-8 -Wattribute-alias warning inside of the
SYSCALL_DEFINEx() macro without having to do it globally.
- Reducing the build time for a simple re-make after a change,
once we move the warnings from ./Makefile and
./scripts/Makefile.extrawarn into linux/compiler.h
- More control over the warnings based on other configurations,
using preprocessor syntax instead of Makefile syntax. This should make
it easier for the average developer to understand and change things.
- Adding an easy way to turn the W=1 option on unconditionally
for a subdirectory or a specific file. This has been requested
by several developers in the past that want to have their subsystems
W=1 clean.
- Integrating clang better into the build systems. Clang supports
more warnings than GCC, and we probably want to classify them
as default, W=1, W=2 etc, but there are cases in which the
warnings should be classified differently due to excessive false
positives from one or the other compiler.
- Adding a way to turn the default warnings into errors (e.g. using
a new "make E=0" tag) while not also turning the W=1 warnings into
errors.
This patch for now just adds the minimal infrastructure in order to
do the first of the list above. As the #pragma GCC diagnostic
takes precedence over command line options, the next step would be
to convert a lot of the individual Makefiles that set nonstandard
options to use __diag() instead.
[[email protected]:
- Rebase atop current master.
- Add __diag_GCC, or more generally __diag_<compiler>, abstraction to
avoid code outside of linux/compiler-gcc.h needing to duplicate
knowledge about different GCC versions.
- Add a comment argument to __diag_{ignore,warn,error} which isn't
used in the expansion of the macros but serves to push people to
document the reason for using them - per feedback from Kees Cook.
- Translate severity to GCC-specific pragmas in linux/compiler-gcc.h
rather than using GCC-specific in linux/compiler_types.h.
- Drop all but GCC 8 macros, since we only need to define macros for
versions that we need to introduce pragmas for, and as of this
series that's just GCC 8.
- Capitalize comments in linux/compiler-gcc.h to match the style of
the rest of the file.
- Line up macro definitions with tabs in linux/compiler-gcc.h.]
Peter Chen [Tue, 12 Jun 2018 01:53:01 +0000 (09:53 +0800)]
usb: typec: tcpm: fix logbuffer index is wrong if _tcpm_log is re-entered
The port->logbuffer_head may be wrong if the two processes enters
_tcpm_log at the mostly same time. The 2nd process enters _tcpm_log
before the 1st process update the index, then the 2nd process will
not allocate logbuffer, when the 2nd process tries to use log buffer,
the index has already updated by the 1st process, so it will get
NULL pointer for updated logbuffer, the error message like below:
Hans de Goede [Thu, 7 Jun 2018 13:54:48 +0000 (15:54 +0200)]
NFC: pn533: Fix wrong GFP flag usage
pn533_recv_response() is an urb completion handler, so it must use
GFP_ATOMIC. pn533_usb_send_frame() OTOH runs from a regular sleeping
context, so the pn533_submit_urb_for_response() there (and only there)
can use the regular GFP_KERNEL flags.
Uniden UBC125 radio scanner has USB interface which fails to work
with cdc_acm driver:
usb 1-1.5: new full-speed USB device number 4 using xhci_hcd
cdc_acm 1-1.5:1.0: Zero length descriptor references
cdc_acm: probe of 1-1.5:1.0 failed with error -22
Adding the NO_UNION_NORMAL quirk for the device fixes the issue:
usb 1-4: new full-speed USB device number 15 using xhci_hcd
usb 1-4: New USB device found, idVendor=1965, idProduct=0018
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: UBC125XLT
usb 1-4: Manufacturer: Uniden Corp.
usb 1-4: SerialNumber: 0001
cdc_acm 1-4:1.0: ttyACM0: USB ACM device
`lsusb -v` of the device:
Bus 001 Device 015: ID 1965:0018 Uniden Corporation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1965 Uniden Corporation
idProduct 0x0018
bcdDevice 0.01
iManufacturer 1 Uniden Corp.
iProduct 2 UBC125XLT
iSerial 3 0001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 48
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0 None
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
Randy Dunlap [Thu, 21 Jun 2018 00:05:42 +0000 (17:05 -0700)]
staging/typec: fix tcpci_rt1711h build errors
Fix Kconfig warning and build errors in staging/typec/rt1711h.c.
The driver uses I2C interfaces so it should depend on I2C.
WARNING: unmet direct dependencies detected for TYPEC_TCPCI
Depends on [m]: STAGING [=y] && TYPEC_TCPM [=y] && I2C [=m]
Selected by [y]:
- TYPEC_RT1711H [=y] && STAGING [=y] && TYPEC_TCPM [=y]
and then:
drivers/staging/typec/tcpci.o: In function `tcpci_probe':
../drivers/staging/typec/tcpci.c:536: undefined reference to `__devm_regmap_init_i2c'
drivers/staging/typec/tcpci.o: In function `tcpci_i2c_driver_init':
../drivers/staging/typec/tcpci.c:593: undefined reference to `i2c_register_driver'
drivers/staging/typec/tcpci.o: In function `tcpci_i2c_driver_exit':
../drivers/staging/typec/tcpci.c:593: undefined reference to `i2c_del_driver'
drivers/staging/typec/tcpci_rt1711h.o: In function `rt1711h_check_revision':
../drivers/staging/typec/tcpci_rt1711h.c:218: undefined reference to `i2c_smbus_read_word_data'
../drivers/staging/typec/tcpci_rt1711h.c:225: undefined reference to `i2c_smbus_read_word_data'
drivers/staging/typec/tcpci_rt1711h.o: In function `rt1711h_probe':
../drivers/staging/typec/tcpci_rt1711h.c:251: undefined reference to `__devm_regmap_init_i2c'
drivers/staging/typec/tcpci_rt1711h.o: In function `rt1711h_i2c_driver_init':
../drivers/staging/typec/tcpci_rt1711h.c:308: undefined reference to `i2c_register_driver'
drivers/staging/typec/tcpci_rt1711h.o: In function `rt1711h_i2c_driver_exit':
../drivers/staging/typec/tcpci_rt1711h.c:308: undefined reference to `i2c_del_driver'
Heikki Krogerus [Thu, 21 Jun 2018 13:43:19 +0000 (16:43 +0300)]
usb: typec: ucsi: Fix for incorrect status data issue
According to UCSI Specification, Connector Change Event only
means a change in the Connector Status and Operation Mode
fields of the STATUS data structure. So any other change
should create another event.
Unfortunately on some platforms the firmware acting as PPM
(platform policy manager - usually embedded controller
firmware) still does not report any other status changes if
there is a connector change event. So if the connector power
or data role was changed when a device was plugged to the
connector, the driver does not get any indication about
that. The port will show wrong roles if that happens.
To fix the issue, always checking the data and power role
together with a connector change event.
Heikki Krogerus [Thu, 21 Jun 2018 13:43:18 +0000 (16:43 +0300)]
usb: typec: ucsi: acpi: Workaround for cache mode issue
This fixes an issue where the driver fails with an error:
ioremap error for 0x3f799000-0x3f79a000, requested 0x2, got 0x0
On some platforms the UCSI ACPI mailbox SystemMemory
Operation Region may be setup before the driver has been
loaded. That will lead into the driver failing to map the
mailbox region, as it has been already marked as write-back
memory. acpi_os_ioremap() for x86 uses ioremap_cache()
unconditionally.
When the issue happens, the embedded controller has a
pending query event for the UCSI notification right after
boot-up which causes the operation region to be setup before
UCSI driver has been loaded.
The fix is to notify acpi core that the driver is about to
access memory region which potentially overlaps with an
operation region right before mapping it.
acpi_release_memory() will check if the memory has already
been setup (mapped) by acpi core, and deactivate it (unmap)
if it has. The driver is then able to map the memory with
ioremap_nocache() and set the memtype to uncached for the
region.
Heikki Krogerus [Thu, 21 Jun 2018 13:43:17 +0000 (16:43 +0300)]
acpi: Add helper for deactivating memory region
Sometimes memory resource may be overlapping with
SystemMemory Operation Region by design, for example if the
memory region is used as a mailbox for communication with a
firmware in the system. One occasion of such mailboxes is
USB Type-C Connector System Software Interface (UCSI).
With regions like that, it is important that the driver is
able to map the memory with the requirements it has. For
example, the driver should be allowed to map the memory as
non-cached memory. However, if the operation region has been
accessed before the driver has mapped the memory, the memory
has been marked as write-back by the time the driver is
loaded. That means the driver will fail to map the memory
if it expects non-cached memory.
To work around the problem, introducing helper that the
drivers can use to temporarily deactivate (unmap)
SystemMemory Operation Regions that overlap with their
IO memory.
Ajay Gupta [Thu, 21 Jun 2018 13:19:45 +0000 (16:19 +0300)]
usb: xhci: increase CRS timeout value
Some controllers take almost 55ms to complete controller
restore state (CRS).
There is no timeout limit mentioned in xhci specification so
fixing the issue by increasing the timeout limit to 100ms
Dongjiu Geng [Thu, 21 Jun 2018 13:19:43 +0000 (16:19 +0300)]
usb: xhci: remove the code build warning
Initialize the 'err' variate to remove the build warning,
the warning is shown as below:
drivers/usb/host/xhci-tegra.c: In function 'tegra_xusb_mbox_thread':
drivers/usb/host/xhci-tegra.c:552:6: warning: 'err' may be used uninitialized in this function [-Wuninitialized]
drivers/usb/host/xhci-tegra.c:482:6: note: 'err' was declared here
Zhengjun Xing [Thu, 21 Jun 2018 13:19:42 +0000 (16:19 +0300)]
xhci: Fix kernel oops in trace_xhci_free_virt_device
commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
set dev->udev pointer to NULL in xhci_free_dev(), it will cause kernel
panic in trace_xhci_free_virt_device. This patch reimplement the trace
function trace_xhci_free_virt_device, remove dev->udev dereference and
added more useful parameters to show in the trace function,it also makes
sure dev->udev is not NULL before calling trace_xhci_free_virt_device.
This issue happened when xhci-hcd trace is enabled and USB devices hot
plug test. Original use-after-free patch went to stable so this needs so
be applied there as well.
Mathias Nyman [Thu, 21 Jun 2018 13:19:41 +0000 (16:19 +0300)]
xhci: Fix perceived dead host due to runtime suspend race with event handler
Don't rely on event interrupt (EINT) bit alone to detect pending port
change in resume. If no change event is detected the host may be suspended
again, oterwise roothubs are resumed.
There is a lag in xHC setting EINT. If we don't notice the pending change
in resume, and the controller is runtime suspeded again, it causes the
event handler to assume host is dead as it will fail to read xHC registers
once PCI puts the controller to D3 state.
[ 268.520969] xhci_hcd: xhci_resume: starting port polling.
[ 268.520985] xhci_hcd: xhci_hub_status_data: stopping port polling.
[ 268.521030] xhci_hcd: xhci_suspend: stopping port polling.
[ 268.521040] xhci_hcd: // Setting command ring address to 0x349bd001
[ 268.521139] xhci_hcd: Port Status Change Event for port 3
[ 268.521149] xhci_hcd: resume root hub
[ 268.521163] xhci_hcd: port resume event for port 3
[ 268.521168] xhci_hcd: xHC is not running.
[ 268.521174] xhci_hcd: handle_port_status: starting port polling.
[ 268.596322] xhci_hcd: xhci_hc_died: xHCI host controller not responding, assume dead
The EINT lag is described in a additional note in xhci specs 4.19.2:
"Due to internal xHC scheduling and system delays, there will be a lag
between a change bit being set and the Port Status Change Event that it
generated being written to the Event Ring. If SW reads the PORTSC and
sees a change bit set, there is no guarantee that the corresponding Port
Status Change Event has already been written into the Event Ring."
Merge tag 'fixes-for-v4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
usb: fixes for v4.18-rc1
First set of fixes for the current -rc cycle. The main parts being
warnings of different kinds being fixed. We're also adding support for
Intel'l Icelake devices on dwc3-pci.c.
It might prevent the machine from boot. It would wait for enough
randomness at the very beginning of kernel_init(). But there is
basically nothing running in parallel that would help to produce
any randomness.
Takashi Iwai [Mon, 25 Jun 2018 09:13:59 +0000 (11:13 +0200)]
ALSA: seq: Fix UBSAN warning at SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT ioctl
The kernel may spew a WARNING with UBSAN undefined behavior at
handling ALSA sequencer ioctl SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT:
UBSAN: Undefined behaviour in sound/core/seq/seq_clientmgr.c:2007:14
signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x122/0x1c8 lib/dump_stack.c:113
ubsan_epilogue+0x12/0x86 lib/ubsan.c:159
handle_overflow+0x1c2/0x21f lib/ubsan.c:190
__ubsan_handle_add_overflow+0x2a/0x31 lib/ubsan.c:198
snd_seq_ioctl_query_next_client+0x1ac/0x1d0 sound/core/seq/seq_clientmgr.c:2007
snd_seq_ioctl+0x264/0x3d0 sound/core/seq/seq_clientmgr.c:2144
....
It happens only when INT_MAX is passed there, as we're incrementing it
unconditionally. So the fix is trivial, check the value with
INT_MAX. Although the bug itself is fairly harmless, it's better to
fix it so that fuzzers won't hit this again later.
Takashi Iwai [Mon, 25 Jun 2018 09:09:11 +0000 (11:09 +0200)]
ALSA: timer: Fix UBSAN warning at SNDRV_TIMER_IOCTL_NEXT_DEVICE ioctl
The kernel may spew a WARNING about UBSAN undefined behavior at
handling ALSA timer ioctl SNDRV_TIMER_IOCTL_NEXT_DEVICE:
UBSAN: Undefined behaviour in sound/core/timer.c:1524:19
signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x122/0x1c8 lib/dump_stack.c:113
ubsan_epilogue+0x12/0x86 lib/ubsan.c:159
handle_overflow+0x1c2/0x21f lib/ubsan.c:190
__ubsan_handle_add_overflow+0x2a/0x31 lib/ubsan.c:198
snd_timer_user_next_device sound/core/timer.c:1524 [inline]
__snd_timer_user_ioctl+0x204d/0x2520 sound/core/timer.c:1939
snd_timer_user_ioctl+0x67/0x95 sound/core/timer.c:1994
....
It happens only when a value with INT_MAX is passed, as we're
incrementing it unconditionally. So the fix is trivial, check the
value with INT_MAX. Although the bug itself is fairly harmless, it's
better to fix it so that fuzzers won't hit this again later.
Hui Wang [Mon, 25 Jun 2018 06:40:56 +0000 (14:40 +0800)]
ALSA: hda/realtek - Fix the problem of two front mics on more machines
We have 3 more Lenovo machines, they all have 2 front mics on them,
so they need the fixup to change the location for one of two mics.
Among these 3 Lenovo machines, one of them has the same pin cfg as the
machine with subid 0x17aa3138, so use the pin cfg table to apply fixup
for them. The rest machines don't share the same pin cfg, so far use
the subid to apply fixup for them.
2) Fix bpf instruction alignment on powerpc et al., from Eric Dumazet.
3) Don't ignore IFLA_MTU attribute when creating new ipvlan links. From
Xin Long.
4) Fix use after free in AF_PACKET, from Eric Dumazet.
5) Mis-matched RTNL unlock in xen-netfront, from Ross Lagerwall.
6) Fix VSOCK loopback on big-endian, from Claudio Imbrenda.
7) Missing RX buffer offset correction when computing DMA addresses in
mvneta driver, from Antoine Tenart.
8) Fix crashes in DCCP's ccid3_hc_rx_send_feedback, from Eric Dumazet.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (34 commits)
sfc: make function efx_rps_hash_bucket static
strparser: Corrected typo in documentation.
qmi_wwan: add support for the Dell Wireless 5821e module
cxgb4: when disabling dcb set txq dcb priority to 0
net_sched: remove a bogus warning in hfsc
net: dccp: switch rx_tstamp_last_feedback to monotonic clock
net: dccp: avoid crash in ccid3_hc_rx_send_feedback()
net: Remove depends on HAS_DMA in case of platform dependency
MAINTAINERS: Add file patterns for dsa device tree bindings
net: mscc: make sparse happy
net: mvneta: fix the Rx desc DMA address in the Rx path
Documentation: e1000: Fix docs build error
Documentation: e100: Fix docs build error
Documentation: e1000: Use correct heading adornment
Documentation: e100: Use correct heading adornment
ipv6: mcast: fix unsolicited report interval after receiving querys
vhost_net: validate sock before trying to put its fd
VSOCK: fix loopback on big-endian systems
net: ethernet: ti: davinci_cpdma: make function cpdma_desc_pool_create static
xen-netfront: Update features after registering netdev
...
Viresh Kumar [Wed, 20 Jun 2018 06:15:37 +0000 (11:45 +0530)]
PM / Domains: Rename opp_node to np
The DT node passed here isn't necessarily an OPP node, as this routine
can also be used for cases where the "required-opps" property is present
directly in the device's node. Rename it.
Dan Carpenter [Thu, 21 Jun 2018 08:06:41 +0000 (11:06 +0300)]
cpufreq: qcom-kryo: Fix error handling in probe()
We should return if get_cpu_device() fails or it leads to a NULL
dereference. Also dev_pm_opp_of_get_opp_desc_node() returns NULL on
error, it never returns error pointers.
In __xfs_ag_resv_init we incorrectly calculate the amount by which to
decrease fdblocks when reserving blocks for the rmapbt. Because rmapbt
allocations do not decrease fdblocks, we must decrease fdblocks by the
entire size of the requested reservation in order to achieve our goal of
always having enough free blocks to satisfy an rmapbt expansion.
This is in contrast to the refcountbt/finobt, which /do/ subtract from
fdblocks whenever they allocate a block. For this allocation type we
preserve the existing behavior where we decrease fdblocks only by the
requested reservation minus the size of the existing tree.
This fixes the problem where the available block counts reported by
statfs change across a remount if there had been an rmapbt size change
since mount time.
Darrick J. Wong [Fri, 22 Jun 2018 06:26:58 +0000 (23:26 -0700)]
xfs: ensure post-EOF zeroing happens after zeroing part of a file
If a user asks us to zero_range part of a file, the end of the range is
EOF, and not aligned to a page boundary, invoke writeback of the EOF
page to ensure that the post-EOF part of the page is zeroed. This
ensures that we don't expose stale memory contents via mmap, if in a
clumsy manner.
Found by running generic/127 when it runs zero_range and mapread at EOF
one after the other.
Darrick J. Wong [Fri, 22 Jun 2018 06:26:58 +0000 (23:26 -0700)]
xfs: fix off-by-one error in xfs_rtalloc_query_range
In commit 8ad560d2565e6 ("xfs: strengthen rtalloc query range checks")
we strengthened the input parameter checks in the rtbitmap range query
function, but introduced an off-by-one error in the process. The call
to xfs_rtfind_forw deals with the high key being rextents, but we clamp
the high key to rextents - 1. This causes the returned results to stop
one block short of the end of the rtdev, which is incorrect.
Darrick J. Wong [Fri, 22 Jun 2018 06:26:57 +0000 (23:26 -0700)]
xfs: fix uninitialized field in rtbitmap fsmap backend
Initialize the extent count field of the high key so that when we use
the high key to synthesize an 'unknown owner' record (i.e. used space
record) at the end of the queried range we have a field with which to
compute rm_blockcount. This is not strictly necessary because the
synthesizer never uses the rm_blockcount field, but we can shut up the
static code analysis anyway.
Darrick J. Wong [Fri, 22 Jun 2018 06:26:57 +0000 (23:26 -0700)]
xfs: recheck reflink state after grabbing ILOCK_SHARED for a write
The reflink iflag could have changed since the earlier unlocked check,
so if we got ILOCK_SHARED for a write and but we're now a reflink inode
we have to switch to ILOCK_EXCL and relock.
This helps us avoid blowing lock assertions in things like generic/166:
Darrick J. Wong [Fri, 22 Jun 2018 06:26:57 +0000 (23:26 -0700)]
xfs: don't allow insert-range to shift extents past the maximum offset
Zorro Lang reports that generic/485 blows an assert on a filesystem with
512 byte blocks. The test tries to fallocate a post-eof extent at the
maximum file size and calls insert range to shift the extents right by
two blocks. On a 512b block filesystem this causes startoff to overflow
the 54-bit startoff field, leading to the assert.
Therefore, always check the rightmost extent to see if it would overflow
prior to invoking the insert range machinery.
Darrick J. Wong [Fri, 22 Jun 2018 06:26:56 +0000 (23:26 -0700)]
xfs: don't trip over negative free space in xfs_reserve_blocks
If we somehow end up with a filesystem that has fewer free blocks than
the blocks set aside to avoid ENOSPC deadlocks, it's possible that the
free space calculation in xfs_reserve_blocks will spit out a negative
number (because percpu_counter_sum returns s64). We fail to notice
this negative number and set fdblks_delta to it. Now we increment
fdblocks(!) and the unsigned type of m_resblks means that we end up
setting a ridiculously huge m_resblks reservation.
Avoid this comedy of errors by detecting the negative free space and
returning -ENOSPC.
Darrick J. Wong [Fri, 22 Jun 2018 06:26:55 +0000 (23:26 -0700)]
xfs: allow empty transactions while frozen
In commit e89c041338ed6ef ("xfs: implement the GETFSMAP ioctl") we
created the ability to obtain empty transactions. These transactions
have no log or block reservations and therefore can't modify anything.
Since they're also NO_WRITECOUNT they can run while the fs is frozen,
so we don't need to WARN_ON about that usage.
Paul Burton [Sun, 24 Jun 2018 16:33:22 +0000 (09:33 -0700)]
MIPS: Add ksig argument to rseq_{signal_deliver,handle_notify_resume}
Commit 784e0300fe9f ("rseq: Avoid infinite recursion when delivering
SIGSEGV") added a new ksig argument to the rseq_signal_deliver() &
rseq_handle_notify_resume() functions, and was merged in v4.18-rc2.
Meanwhile MIPS support for restartable sequences was also merged in
v4.18-rc2 with commit 9ea141ad5471 ("MIPS: Add support for restartable
sequences"), and therefore didn't get updated for the API change.
This results in build failures like the following:
CC arch/mips/kernel/signal.o
arch/mips/kernel/signal.c: In function 'handle_signal':
arch/mips/kernel/signal.c:804:22: error: passing argument 1 of
'rseq_signal_deliver' from incompatible pointer type
[-Werror=incompatible-pointer-types]
rseq_signal_deliver(regs);
^~~~
In file included from ./include/linux/context_tracking.h:5,
from arch/mips/kernel/signal.c:12:
./include/linux/sched.h:1811:56: note: expected 'struct ksignal *' but
argument is of type 'struct pt_regs *'
static inline void rseq_signal_deliver(struct ksignal *ksig,
~~~~~~~~~~~~~~~~^~~~
arch/mips/kernel/signal.c:804:2: error: too few arguments to function
'rseq_signal_deliver'
rseq_signal_deliver(regs);
^~~~~~~~~~~~~~~~~~~
Fix this by adding the ksig argument as was done for other architectures
in commit 784e0300fe9f ("rseq: Avoid infinite recursion when delivering
SIGSEGV").
Hans de Goede [Mon, 18 Jun 2018 16:09:36 +0000 (18:09 +0200)]
iio: imu: inv_mpu6050: Fix probe() failure on older ACPI based machines
Commit 5ec6486daa98 ("iio:imu: inv_mpu6050: support more interrupt types")
causes inv_mpu_core_probe() to fail if the IRQ does not have a
trigger-type setup.
This happens on machines where the mpu6050 is enumerated through ACPI and
an older Interrupt type ACPI resource is used for the interrupt, rather
then a GpioInt type type, causing the mpu6050 driver to no longer work
there. This happens on e.g. the Asus T100TA.
This commits makes the mpu6050 fallback to the old IRQF_TRIGGER_RISING
default if the irq-type is not setup, fixing this.
Signed-off-by: Hans de Goede <[email protected]> Fixes: 5ec6486daa98 ("iio:imu: inv_mpu6050: support more interrupt types") Reviewed-by: Martin Kelly <[email protected]> Reviewed-by: Jean-Baptiste Maneyrol <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
Phil Reid [Tue, 5 Jun 2018 06:15:10 +0000 (14:15 +0800)]
iio: buffer: fix the function signature to match implementation
linux/iio/buffer-dma.h was not updated to when length was changed to
unsigned int.
Fixes: c043ec1ca5ba ("iio:buffer: make length types match kfifo types") Signed-off-by: Phil Reid <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
Leonard Crestez [Thu, 7 Jun 2018 18:52:50 +0000 (21:52 +0300)]
iio: mma8452: Fix ignoring MMA8452_INT_DRDY
Interrupts are ignored if no event bit is set in the status status
register and this breaks the buffer interface. No data is shown when
running "iio_generic_buffer -n mma8451 -a" and interrupt counts go
crazy.
Fix by not returning IRQ_NONE if DRDY is set.
Fixes: 605f72de137a ("iio: accel: mma8452: improvements to handle
multiple events")
Colin Ian King [Wed, 30 May 2018 18:19:36 +0000 (19:19 +0100)]
iio: tsl2x7x/tsl2772: avoid potential division by zero
It may be possible for tsl2772_get_lux to return a zero lux value
and hence a division by zero can occur when lux_val is zero. Check
for this case and return -ERANGE to avoid the division by zero.
Detected by CoverityScan, CID#1469484 ("Division or modulo by zero")
Linus Torvalds [Sun, 24 Jun 2018 12:29:15 +0000 (20:29 +0800)]
Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Thomas Gleixner:
"A pile of perf updates:
Kernel side:
- Remove an incorrect warning in uprobe_init_insn() when
insn_get_length() fails. The error return code is handled at the
call site.
- Move the inline keyword to the right place in the perf ringbuffer
code to address a W=1 build warning.
Tooling:
perf stat:
- Fix metric column header display alignment
- Improve error messages for default attributes, providing better
output for error in command line.
- Add --interval-clear option, to provide a 'watch' like printing
perf script:
- Show hw-cache events too
perf c2c:
- Fix data dependency problem in layout of 'struct c2c_hist_entry'
Core:
- Do not blindly assume that 'struct perf_evsel' can be obtained via
a straight forward container_of() as there are call sites which
hand in a plain 'struct hist' which is not part of a container.
- Fix error index in the PMU event parser, so that error messages can
point to the problematic token"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/core: Move the inline keyword at the beginning of the function declaration
uprobes/x86: Remove incorrect WARN_ON() in uprobe_init_insn()
perf script: Show hw-cache events
perf c2c: Keep struct hist_entry at the end of struct c2c_hist_entry
perf stat: Add event parsing error handling to add_default_attributes
perf stat: Allow to specify specific metric column len
perf stat: Fix metric column header display alignment
perf stat: Use only color_fprintf call in print_metric_only
perf stat: Add --interval-clear option
perf tools: Fix error index for pmu event parser
perf hists: Reimplement hists__has_callchains()
perf hists browser gtk: Use hist_entry__has_callchains()
perf hists: Make hist_entry__has_callchains() work with 'perf c2c'
perf hists: Save the callchain_size in struct hist_entry
Linus Torvalds [Sun, 24 Jun 2018 12:18:19 +0000 (20:18 +0800)]
Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull rseq fixes from Thomas Gleixer:
"A pile of rseq related fixups:
- Prevent infinite recursion when delivering SIGSEGV
- Remove the abort of rseq critical section on fork() as syscalls
inside rseq critical sections are explicitely forbidden. So no
point in doing the abort on the child.
- Align the rseq structure on 32 bytes in the ARM selftest code.
- Fix file permissions of the test script"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
rseq: Avoid infinite recursion when delivering SIGSEGV
rseq/cleanup: Do not abort rseq c.s. in child on fork()
rseq/selftests/arm: Align 'struct rseq_cs' on 32 bytes
rseq/selftests: Make run_param_test.sh executable
Linus Torvalds [Sun, 24 Jun 2018 12:16:17 +0000 (20:16 +0800)]
Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull EFI fixes from Thomas Gleixner:
"Two fixlets for the EFI maze:
- Properly zero variables to prevent an early boot hang on EFI mixed
mode systems
- Fix the fallout of merging the 32bit and 64bit variants of EFI PCI
related code which ended up chosing the 32bit variant of the actual
EFi call invocation which leads to failures on 64bit"
* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi/x86: Fix incorrect invocation of PciIo->Attributes()
efi/libstub/tpm: Initialize efi_physical_addr_t vars to zero for mixed mode
Linus Torvalds [Sun, 24 Jun 2018 12:06:42 +0000 (20:06 +0800)]
Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull core fixes from Thomas Gleixner:
"Two tiny fixes:
- Add the missing machine_real_restart() to objtools noreturn list so
it stops complaining
- Fix a trivial comment typo"
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
kernel.h: Fix a typo in comment
objtool: Add machine_real_restart() to the noreturn list
Linus Torvalds [Sun, 24 Jun 2018 11:59:52 +0000 (19:59 +0800)]
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"A set of fixes for x86:
- Make Xen PV guest deal with speculative store bypass correctly
- Address more fallout from the 5-Level pagetable handling. Undo an
__initdata annotation to avoid section mismatch and malfunction
when post init code would touch the freed variable.
- Handle exception fixup in math_error() before calling notify_die().
The reverse call order incorrectly triggers notify_die() listeners
for soemthing which is handled correctly at the site which issues
the floating point instruction.
- Fix an off by one in the LLC topology calculation on AMD
- Handle non standard memory block sizes gracefully un UV platforms
- Plug a memory leak in the microcode loader
- Sanitize the purgatory build magic
- Add the x86 specific device tree bindings directory to the x86
MAINTAINER file patterns"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mm: Fix 'no5lvl' handling
Revert "x86/mm: Mark __pgtable_l5_enabled __initdata"
x86/CPU/AMD: Fix LLC ID bit-shift calculation
MAINTAINERS: Add file patterns for x86 device tree bindings
x86/microcode/intel: Fix memleak in save_microcode_patch()
x86/platform/UV: Add kernel parameter to set memory block size
x86/platform/UV: Use new set memory block size function
x86/platform/UV: Add adjustable set memory block size function
x86/build: Remove unnecessary preparation for purgatory
Revert "kexec/purgatory: Add clean-up for purgatory directory"
x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
x86: Call fixup_exception() before notify_die() in math_error()
Linus Torvalds [Sun, 24 Jun 2018 11:48:30 +0000 (19:48 +0800)]
Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 pti fixes from Thomas Gleixner:
"Two small updates for the speculative distractions:
- Make it more clear to the compiler that array_index_mask_nospec()
is not subject for optimizations. It's not perfect, but ...
- Don't report XEN PV guests as vulnerable because their mitigation
state depends on the hypervisor. Report unknown and refer to the
hypervisor requirement"
* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/spectre_v1: Disable compiler optimizations over array_index_mask_nospec()
x86/pti: Don't report XenPV as vulnerable
Linus Torvalds [Sun, 24 Jun 2018 11:36:16 +0000 (19:36 +0800)]
Merge branch 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fixes from Thomas Gleixner:
"A set of fixes and updates for the locking code:
- Prevent lockdep from updating irq state within its own code and
thereby confusing itself.
- Buid fix for older GCCs which mistreat anonymous unions
- Add a missing lockdep annotation in down_read_non_onwer() which
causes up_read_non_owner() to emit a lockdep splat
- Remove the custom alpha dec_and_lock() implementation which is
incorrect in terms of ordering and use the generic one.
The remaining two commits are not strictly fixes. They provide irqsave
variants of atomic_dec_and_lock() and refcount_dec_and_lock(). These
are required to merge the relevant updates and cleanups into different
maintainer trees for 4.19, so routing them into mainline without
actual users is the sanest approach.
They should have been in -rc1, but last weekend I took the liberty to
just avoid computers in order to regain some mental sanity"
* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking/qspinlock: Fix build for anonymous union in older GCC compilers
locking/lockdep: Do not record IRQ state within lockdep code
locking/rwsem: Fix up_read_non_owner() warning with DEBUG_RWSEMS
locking/refcounts: Implement refcount_dec_and_lock_irqsave()
atomic: Add irqsave variant of atomic_dec_and_lock()
alpha: Remove custom dec_and_lock() implementation
Linus Torvalds [Sun, 24 Jun 2018 11:22:19 +0000 (19:22 +0800)]
Merge branch 'ras-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull ras fixes from Thomas Gleixner:
"A set of fixes for RAS/MCE:
- Improve the error message when the kernel cannot recover from a MCE
so the maximum amount of information gets provided.
- Individually check MCE recovery features on SkyLake CPUs instead of
assuming none when the CAPID0 register does not advertise the
general ability for recovery.
- Prevent MCE to output inconsistent messages which first show an
error location and then claim that the source is unknown.
- Prevent overwriting MCi_STATUS in the attempt to gather more
information when a fatal MCE has alreay been detected. This leads
to empty status values in the printout and failing to react
promptly on the fatal event"
* 'ras-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mce: Fix incorrect "Machine check from unknown source" message
x86/mce: Do not overwrite MCi_STATUS in mce_no_way_out()
x86/mce: Check for alternate indication of machine check recovery on Skylake
x86/mce: Improve error message when kernel cannot recover
Linus Torvalds [Sun, 24 Jun 2018 11:16:42 +0000 (19:16 +0800)]
Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fixes from Thomas Gleixner:
"A small set of fixes for time(r) related issues:
- Fix a long standing conversion issue in jiffies_to_msecs() for odd
HZ values like 1024 or 1200 which resulted in returning 0 for small
jiffies values due to rounding down.
- Use the proper CONFIG symbol in the new Y2038 safe compat code for
posix-timers. Not yet a visible breakage, but this will immediately
trigger when the architecture support for the new interfaces is
merged.
- Return an error code in the STM32 clocksource driver on failure
instead of success.
- Remove the redundant and stale irq disabled check in the posix cpu
timer code. The check is at the wrong place anyway and lockdep
already covers it via the sighand lock locking coverage"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
time: Make sure jiffies_to_msecs() preserves non-zero time periods
posix-timers: Fix nanosleep_copyout() for CONFIG_COMPAT_32BIT_TIME
clocksource/drivers/stm32: Fix error return code
posix-cpu-timers: Remove lockdep_assert_irqs_disabled()
Linus Torvalds [Sun, 24 Jun 2018 11:01:18 +0000 (19:01 +0800)]
Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Thomas Gleixner:
"A set of fixes mostly for the ARM/GIC world:
- Fix the MSI affinity handling in the ls-scfg irq chip driver so it
updates and uses the effective affinity mask correctly
- Prevent binding LPIs to offline CPUs and respect the Cavium erratum
which requires that LPIs which belong to an offline NUMA node are
not bound to a CPU on a different NUMA node.
- Free only the amount of allocated interrupts in the GIC-V2M driver
instead of trying to free log2(nrirqs).
- Prevent emitting SYNC and VSYNC targetting non existing interrupt
collections in the GIC-V3 ITS driver
- Ensure that the GIV-V3 interrupt redistributor is correctly
reprogrammed on CPU hotplug
- Remove a stale unused helper function"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqdesc: Delete irq_desc_get_msi_desc()
irqchip/gic-v3-its: Fix reprogramming of redistributors on CPU hotplug
irqchip/gic-v3-its: Only emit VSYNC if targetting a valid collection
irqchip/gic-v3-its: Only emit SYNC if targetting a valid collection
irqchip/gic-v3-its: Don't bind LPI to unavailable NUMA node
irqchip/gic-v2m: Fix SPI release on error path
irqchip/ls-scfg-msi: Fix MSI affinity handling
genirq/debugfs: Add missing IRQCHIP_SUPPORTS_LEVEL_MSI debug
Linus Torvalds [Sun, 24 Jun 2018 09:19:42 +0000 (17:19 +0800)]
Merge tag 'mips_fixes_4.18_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS fixes from Paul Burton:
"A few MIPS fixes for 4.18:
- a GPIO device name fix for a regression in v4.15-rc1.
- an errata workaround for the BCM5300X platform.
- a fix to ftrace function graph tracing, broken for a long time with
the fix applying cleanly back as far as v3.17.
- addition of read barriers to in{b,w,l,q}() functions, matching
behavior of other architectures & mirroring the equivalent addition
to read{b,w,l,q} in v4.17-rc2.
Plus changes to wire up new syscalls introduced in the 4.18 cycle:
- Restartable sequences support is added, including MIPS support in
the selftests.
- io_pgetevents is wired up"
* tag 'mips_fixes_4.18_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: Wire up io_pgetevents syscall
rseq/selftests: Implement MIPS support
MIPS: Wire up the restartable sequences (rseq) syscall
MIPS: Add syscall detection for restartable sequences
MIPS: Add support for restartable sequences
MIPS: io: Add barrier after register read in inX()
mips: ftrace: fix static function graph tracing
MIPS: BCM47XX: Enable 74K Core ExternalSync for PCIe erratum
MIPS: pb44: Fix i2c-gpio GPIO descriptor table
Ard Biesheuvel [Sat, 23 Jun 2018 21:19:03 +0000 (23:19 +0200)]
efi/x86: Fix incorrect invocation of PciIo->Attributes()
The following commit:
2c3625cb9fa2 ("efi/x86: Fold __setup_efi_pci32() and __setup_efi_pci64() into one function")
... merged the two versions of __setup_efi_pciXX(), without taking into
account that the 32-bit version used a rather dodgy trick to pass an
immediate 0 constant as argument for a uint64_t parameter.
The issue is caused by the fact that on x86, UEFI protocol method calls
are redirected via struct efi_config::call(), which is a variadic function,
and so the compiler has to infer the types of the parameters from the
arguments rather than from the prototype.
As the 32-bit x86 calling convention passes arguments via the stack,
passing the unqualified constant 0 twice is the same as passing 0ULL,
which is why the 32-bit code in __setup_efi_pci32() contained the
following call:
status = efi_early->call(pci->attributes, pci,
EfiPciIoAttributeOperationGet, 0, 0,
&attributes);
to invoke this UEFI protocol method:
typedef
EFI_STATUS
(EFIAPI *EFI_PCI_IO_PROTOCOL_ATTRIBUTES) (
IN EFI_PCI_IO_PROTOCOL *This,
IN EFI_PCI_IO_PROTOCOL_ATTRIBUTE_OPERATION Operation,
IN UINT64 Attributes,
OUT UINT64 *Result OPTIONAL
);
After the merge, we inadvertently ended up with this version for both
32-bit and 64-bit builds, breaking the latter.
So replace the two zeroes with the explicitly typed constant 0ULL,
which works as expected on both 32-bit and 64-bit builds.
Wilfried tested the 64-bit build, and I checked the generated assembly
of a 32-bit build with and without this patch, and they are identical.
qmi_wwan: add support for the Dell Wireless 5821e module
This module exposes two USB configurations: a QMI+AT capable setup on
USB config #1 and a MBIM capable setup on USB config #2.
By default the kernel will choose the MBIM capable configuration as
long as the cdc_mbim driver is available. This patch adds support for
the QMI port in the secondary configuration.
Ganesh Goudar [Sat, 23 Jun 2018 14:58:26 +0000 (20:28 +0530)]
cxgb4: when disabling dcb set txq dcb priority to 0
When we are disabling DCB, store "0" in txq->dcb_prio
since that's used for future TX Work Request "OVLAN_IDX"
values. Setting non zero priority upon disabling DCB
would halt the traffic.
ARM: Always build secure_cntvoff.S on ARM V7 to fix shmobile !SMP build
If CONFIG_SMP=n, building a kernel for R-Car Gen2 fails with:
arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init':
setup-rcar-gen2.c:(.init.text+0x30): undefined reference to `secure_cntvoff_init'
Indeed, on R-Car Gen2 SoCs, secure_cntvoff_init() is not only needed for
secondary CPUs, but also for the boot CPU. This is most visible on SoCs
with Cortex A7 cores (e.g. R-Car E2, cfr. commit 9ce3fa6816c2fb59 ("ARM:
shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794")),
but Cortex A15 is affected, too.
Fix this by always providing secure_cntvoff_init() when building for ARM
V7.
Reported-by: Arnd Bergmann <[email protected]> Fixes: 7c607944bc657616 ("ARM: smp: Add initialization of CNTVOFF") Fixes: cad160ed0a94927e ("ARM: shmobile: Convert file to use cntvoff") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
Linus Torvalds [Sat, 23 Jun 2018 22:33:54 +0000 (06:33 +0800)]
Merge tag 'for-linus-20180623' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
- Further timeout fixes. We aren't quite there yet, so expect another
round of fixes for that to completely close some of the IRQ vs
completion races. (Christoph/Bart)
- Set of NVMe fixes from the usual suspects, mostly error handling
- Two off-by-one fixes (Dan)
- Another bdi race fix (Jan)
- Fix nbd reconfigure with NBD_DISCONNECT_ON_CLOSE (Doron)
* tag 'for-linus-20180623' of git://git.kernel.dk/linux-block:
blk-mq: Fix timeout handling in case the timeout handler returns BLK_EH_DONE
bdi: Fix another oops in wb_workfn()
lightnvm: Remove depends on HAS_DMA in case of platform dependency
nvme-pci: limit max IO size and segments to avoid high order allocations
nvme-pci: move nvme_kill_queues to nvme_remove_dead_ctrl
nvme-fc: release io queues to allow fast fail
nbd: Add the nbd NBD_DISCONNECT_ON_CLOSE config flag.
block: sed-opal: Fix a couple off by one bugs
blk-mq-debugfs: Off by one in blk_mq_rq_state_name()
nvmet: reset keep alive timer in controller enable
nvme-rdma: don't override opts->queue_size
nvme-rdma: Fix command completion race at error recovery
nvme-rdma: fix possible free of a non-allocated async event buffer
nvme-rdma: fix possible double free condition when failing to create a controller
Revert "block: Add warning for bi_next not NULL in bio_endio()"
block: fix timeout changes for legacy request drivers
Linus Torvalds [Sat, 23 Jun 2018 22:31:54 +0000 (06:31 +0800)]
Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
- Fix use after free in chtls
- Fix RBP breakage in sha3
- Fix use after free in hwrng_unregister
- Fix overread in morus640
- Move sleep out of kernel_neon in arm64/aes-blk
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
hwrng: core - Always drop the RNG in hwrng_unregister()
crypto: morus640 - Fix out-of-bounds access
crypto: don't optimize keccakf()
crypto: arm64/aes-blk - fix and move skcipher_walk_done out of kernel_neon_begin, _end
crypto: chtls - use after free in chtls_pt_recvmsg()
Linus Torvalds [Sat, 23 Jun 2018 22:23:28 +0000 (06:23 +0800)]
Merge tag 'trace-v4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"This contains a few fixes and a clean up.
- a bad merge caused an "endif" to go in the wrong place in
scripts/Makefile.build
- softirq tracing fix for tracing that corrupts lockdep and causes a
false splat
- histogram documentation typo fixes
- fix a bad memory reference when passing in no filter to the filter
code
- simplify code by using the swap macro instead of open coding the
swap"
* tag 'trace-v4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix SKIP_STACK_VALIDATION=1 build due to bad merge with -mrecord-mcount
tracing: Fix some errors in histogram documentation
tracing: Use swap macro in update_max_tr
softirq: Reorder trace_softirqs_on to prevent lockdep splat
tracing: Check for no filter when processing event filters
Olof Johansson [Sat, 23 Jun 2018 17:24:23 +0000 (10:24 -0700)]
ARM: multi_v7_defconfig: renormalize based on recent additions
The defconfig has drifted over time, as Kconfig entries have changed order
or default values. Several maintainers ended up running 'savedefconfig'
themselves which caused a cascade of conflicts. Let's do it once and
for all in our tree before -rc2 instead.
Olof Johansson [Sat, 23 Jun 2018 17:24:23 +0000 (10:24 -0700)]
arm64: defconfig: renormalize based on recent additions
The defconfig has drifted over time, as Kconfig entries have changed order
or default values. Several maintainers ended up running 'savedefconfig'
themselves which caused a cascade of conflicts. Let's do it once and
for all in our tree before -rc2 instead.
Olof Johansson [Sat, 23 Jun 2018 17:21:45 +0000 (10:21 -0700)]
Merge tag 'arm-soc/for-4.18/maintainers-arm64-fixes' of https://github.com/Broadcom/stblinux into fixes
This pull request contains Broadcom ARM64-based SoCs MAINTAINERS file
fixes for 4.18, please pull the following:
- Florian fixes the entry for the Northstar2 SoCs which was somehow lost
during a directory move. He also adds an entry for the Stingray SoCs
which was missing from the day files were added
* tag 'arm-soc/for-4.18/maintainers-arm64-fixes' of https://github.com/Broadcom/stblinux:
MAINTAINERS: Update Broadcom iProc entry with Stingray
MAINAINTERS: Corrected Broadcom Northstar2 entry
Olof Johansson [Sat, 23 Jun 2018 17:17:38 +0000 (10:17 -0700)]
Merge tag 'imx-fixes-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes
i.MX fixes for 4.18:
- Fix i.MX6SX PCIe MSI interrupt number, so that MSI IRQs can be
properly propagated to the upstream interrupt controller.
- Fix GPCv2 MIPI/PCIe/USB_HSIC's PGC offset. The values in Reference
Manual are incorrect.
- Correct SDMA setting for i.MX6Q SPI5 device to fix the issue, that
the SPI controller RX FIFO was not empty after a DMA transfer, and
the driver gets stuck in the next PIO transfer when reading one word
more than expected.
* tag 'imx-fixes-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: imx6sx: fix irq for pcie bridge
soc: imx: gpcv2: correct PGC offset
ARM: dts: imx6q: Use correct SDMA script for SPI5 core
Olof Johansson [Sat, 23 Jun 2018 17:16:55 +0000 (10:16 -0700)]
Merge tag 'renesas-fixes-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
Renesas ARM Based SoC Fixes for v4.18
Make PM domain initialization more robust in Renesas R-Car SYSC driver.
This resolves a regression due to re-parenting of PM domains by 086b399965a7ee7e ("soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}").
* tag 'renesas-fixes-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
soc: renesas: rcar-sysc: Make PM domain initialization more robust
Linus Torvalds [Sat, 23 Jun 2018 13:13:05 +0000 (21:13 +0800)]
Merge tag 'powerpc-4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
- a fix for hugetlb with 4K pages, broken by our recent changes for
split PMD PTL.
- set the correct assembler machine type on e500mc, needed since
binutils 2.26 introduced two forms for the "wait" instruction.
- a fix for potential missed TLB flushes with MADV_[FREE|DONTNEED] etc.
and THP on Power9 Radix.
- three fixes to try and make our panic handling more robust by hard
disabling interrupts, and not marking stopped CPUs as offline because
they haven't been properly offlined.
- three other minor fixes.
Thanks to: Aneesh Kumar K.V, Michael Jeanson, Nicholas Piggin.
* tag 'powerpc-4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/mm/hash/4k: Free hugetlb page table caches correctly.
powerpc/64s/radix: Fix radix_kvm_prefetch_workaround paca access of not possible CPU
powerpc/64s: Fix build failures with CONFIG_NMI_IPI=n
powerpc/64: hard disable irqs on the panic()ing CPU
powerpc: smp_send_stop do not offline stopped CPUs
powerpc/64: hard disable irqs in panic_smp_self_stop
powerpc/64s: Fix DT CPU features Power9 DD2.1 logic
powerpc/64s/radix: Fix MADV_[FREE|DONTNEED] TLB flush miss problem with THP
powerpc/e500mc: Set assembler machine type to e500mc
Linus Torvalds [Sat, 23 Jun 2018 13:07:43 +0000 (21:07 +0800)]
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Catalin Marinas:
- clear buffers allocated with FORCE_CONTIGUOUS explicitly until the
CMA code honours __GFP_ZERO
- notrace annotation for secondary_start_kernel()
- use early_param() instead of __setup() for "kpti=" as it is needed
for the cpufeature callback remapping swapper to non-global mappings
- ensure writes to swapper are ordered wrt subsequent cache maintenance
in the kpti non-global remapping code
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: mm: Ensure writes to swapper are ordered wrt subsequent cache maintenance
arm64: kpti: Use early_param for kpti= command-line option
arm64: make secondary_start_kernel() notrace
arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag
Linus Torvalds [Sat, 23 Jun 2018 12:59:00 +0000 (20:59 +0800)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Radim Krčmář:
"ARM:
- Lazy FPSIMD switching fixes
- Really disable compat ioctls on architectures that don't want it
- Disable compat on arm64 (it was never implemented...)
- Rely on architectural requirements for GICV on GICv3
- Detect bad alignments in unmap_stage2_range
x86:
- Add nested VM entry checks to avoid broken error recovery path
- Minor documentation fix"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: fix KVM_CAP_HYPERV_TLBFLUSH paragraph number
kvm: vmx: Nested VM-entry prereqs for event inj.
KVM: arm64: Prevent KVM_COMPAT from being selected
KVM: Enforce error in ioctl for compat tasks when !KVM_COMPAT
KVM: arm/arm64: add WARN_ON if size is not PAGE_SIZE aligned in unmap_stage2_range
KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
KVM: arm64/sve: Fix SVE trap restoration for non-current tasks
KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
arm64: Introduce sysreg_clear_set()
KVM: arm/arm64: Drop resource size check for GICV window
Linus Torvalds [Sat, 23 Jun 2018 12:44:11 +0000 (20:44 +0800)]
Merge tag 'for-linus-4.18-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fixes from Juergen Gross:
"This contains the following fixes/cleanups:
- the removal of a BUG_ON() which wasn't necessary and which could
trigger now due to a recent change
- a correction of a long standing bug happening very rarely in Xen
dom0 when a hypercall buffer from user land was not accessible by
the hypervisor for very short periods of time due to e.g. page
migration or compaction
- usage of EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL() in a
Xen-related driver (no breakage possible as using those symbols
without others already exported via EXPORT-SYMBOL_GPL() wouldn't
make any sense)
- a simplification for Xen PVH or Xen ARM guests
- some additional error handling for callers of xenbus_printf()"
* tag 'for-linus-4.18-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen: Remove unnecessary BUG_ON from __unbind_from_irq()
xen: add new hypercall buffer mapping device
xen/scsiback: add error handling for xenbus_printf
scsi: xen-scsifront: add error handling for xenbus_printf
xen/grant-table: Export gnttab_{alloc|free}_pages as GPL
xen: add error handling for xenbus_printf
xen: share start flags between PV and PVH
__pgtable_l5_enabled marked as __initdata, but cpu_init() is not __init.
It's fixable: early code can be isolated into a separate translation unit,
but such change collides with other work in the area. That's too much
hassle to save 4 bytes of memory.
Return __pgtable_l5_enabled back to be __ro_after_init.
The ETF input should be connected to the funnel output, and the ETF
output should be connected to the replicator input. The labels are wrong
and these got swapped:
Warning (graph_endpoint): /soc/funnel@821000/ports/port@8/endpoint: graph connection to node '/soc/etf@825000/ports/port@1/endpoint' is not bidirectional
Warning (graph_endpoint): /soc/replicator@824000/ports/port@2/endpoint: graph connection to node '/soc/etf@825000/ports/port@0/endpoint' is not bidirectional
arm64: dts: apq8096-db820c: disable uart0 by default
Access to UART0 is disabled by bootloaders. By leaving it enabled by
default would reboot the board.
Disable this for now, this would alteast give a board which boots.
Cong Wang [Fri, 22 Jun 2018 21:33:16 +0000 (14:33 -0700)]
net_sched: remove a bogus warning in hfsc
In update_vf():
cftree_remove(cl);
update_cfmin(cl->cl_parent);
the cl_cfmin of cl->cl_parent is intentionally updated to 0
when that parent only has one child. And if this parent is
root qdisc, we could end up, in hfsc_schedule_watchdog(),
that we can't decide the next schedule time for qdisc watchdog.
But it seems safe that we can just skip it, as this watchdog is
not always scheduled anyway.
Thanks to Marco for testing all the cases, nothing is broken.
Casey Schaufler [Fri, 22 Jun 2018 17:54:45 +0000 (10:54 -0700)]
Smack: Mark inode instant in smack_task_to_inode
Smack: Mark inode instant in smack_task_to_inode
/proc clean-up in commit 1bbc55131e59bd099fdc568d3aa0b42634dbd188
resulted in smack_task_to_inode() being called before smack_d_instantiate.
This resulted in the smk_inode value being ignored, even while present
for files in /proc/self. Marking the inode as instant here fixes that.
net: Remove depends on HAS_DMA in case of platform dependency
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
projects / linux.git / log