Sekhar Nori [Mon, 3 Apr 2017 12:04:28 +0000 (17:34 +0530)]
net: ethernet: ti: cpsw: fix race condition during open()
TI's cpsw driver handles both OF and non-OF case for phy
connect. Unfortunately of_phy_connect() returns NULL on
error while phy_connect() returns ERR_PTR().
To handle this, cpsw_slave_open() overrides the return value
from phy_connect() to make it NULL or error.
This leaves a small window, where cpsw_adjust_link() may be
invoked for a slave while slave->phy pointer is temporarily
set to -ENODEV (or some other error) before it is finally set
to NULL.
_cpsw_adjust_link() only handles the NULL case, and an oops
results when ERR_PTR() is seen by it.
Note that cpsw_adjust_link() checks PHY status for each
slave whenever it is invoked. It can so happen that even
though phy_connect() for a given slave returns error,
_cpsw_adjust_link() is still called for that slave because
the link status of another slave changed.
Fix this by using a temporary pointer to store return value
of {of_}phy_connect() and do a one-time write to slave->phy.
Merge tag 'drm-fixes-for-v4.11-rc6' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"This is just mostly stuff that missed rc5, from vmwgfx and msm
drivers"
* tag 'drm-fixes-for-v4.11-rc6' of git://people.freedesktop.org/~airlied/linux:
drm/msm: Make sure to detach the MMU during GPU cleanup
drm/msm/hdmi: redefinitions of macros not required
drm/msm/mdp5: Update SSPP_MAX value
drm/msm/dsi: Fix bug in dsi_mgr_phy_enable
drm/msm: Don't allow zero sized buffer objects
drm/msm: Fix wrong pointer check in a5xx_destroy
drm/msm: adreno: fix build error without debugfs
drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl()
drm/vmwgfx: Remove getparam error message
drm/ttm: Avoid calling drm_ht_remove from atomic context
drm/ttm, drm/vmwgfx: Relax permission checking when opening surfaces
drm/vmwgfx: avoid calling vzalloc with a 0 size in vmw_get_cap_3d_ioctl()
drm/vmwgfx: NULL pointer dereference in vmw_surface_define_ioctl()
drm/vmwgfx: Type-check lookups of fence objects
Fixes: f1f39f911027 ("l2tp: auto load type modules") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Take a reference on the sessions returned by l2tp_session_find_nth()
(and rename it l2tp_session_get_nth() to reflect this change), so that
caller is assured that the session isn't going to disappear while
processing it.
For procfs and debugfs handlers, the session is held in the .start()
callback and dropped in .show(). Given that pppol2tp_seq_session_show()
dereferences the associated PPPoL2TP socket and that
l2tp_dfs_seq_session_show() might call pppol2tp_show(), we also need to
call the session's .ref() callback to prevent the socket from going
away from under us.
Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts") Fixes: 0ad6614048cf ("l2tp: Add debugfs files for dumping l2tp debug info") Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
The "regs" value is a virtual address, exposing internal information,
hence stop printing it. The (useful) physical address is already
printed as part of the device name.
Fixes: fd1159318e55e901 ("can: add Renesas R-Car CAN driver") Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Sergei Shtylyov <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
Dave Gerlach [Thu, 30 Mar 2017 19:58:18 +0000 (14:58 -0500)]
ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer
Starting from commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM
states at probe error and driver unbind") pm_runtime core now changes
device runtime_status back to after RPM_SUSPENDED after a probe defer.
Certain OMAP devices make use of "ti,no-idle-on-init" flag which causes
omap_device_enable to be called during the BUS_NOTIFY_ADD_DEVICE event
during probe, along with pm_runtime_set_active.
This call to pm_runtime_set_active typically will prevent a call to
pm_runtime_get in a driver probe function from re-enabling the
omap_device. However, in the case of a probe defer that happens before
the driver probe function is able to run, such as a missing pinctrl
states defer, pm_runtime_reinit will set the device as RPM_SUSPENDED and
then once driver probe is actually able to run, pm_runtime_get will see
the device as suspended and call through to the omap_device layer,
attempting to enable the already enabled omap_device and causing errors
like this:
omap-gpmc 50000000.gpmc: omap_device: omap_device_enable() called from
invalid state 1
omap-gpmc 50000000.gpmc: use pm_runtime_put_sync_suspend() in driver?
We can avoid this error by making sure the pm_runtime status of a device
matches the omap_device state before a probe attempt. By extending the
omap_device bus notifier to act on the BUS_NOTIFY_BIND_DRIVER event we
can check if a device is enabled in omap_device but with a pm_runtime
status of RPM_SUSPENDED and once again mark the device as RPM_ACTIVE to
avoid a second incorrect call to omap_device_enable.
Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") Tested-by: Franklin S Cooper Jr. <[email protected]> Signed-off-by: Dave Gerlach <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
Philipp Zabel [Fri, 5 Feb 2016 12:41:39 +0000 (13:41 +0100)]
reset: add exported __reset_control_get, return NULL if optional
Rename the internal __reset_control_get/put functions to
__reset_control_get/put_internal and add an exported
__reset_control_get equivalent to __of_reset_control_get
that takes a struct device parameter.
This avoids the confusing call to __of_reset_control_get in
the non-DT case and fixes the devm_reset_control_get_optional
function to return NULL if RESET_CONTROLLER is enabled but
dev->of_node == NULL.
L2 was running with uninitialized PML fields which led to incomplete
dirty bitmap logging. This manifested as all kinds of subtle erratic
behavior of the nested guest.
Fixes: 843e4330573c ("KVM: VMX: Add PML support in VMX") Signed-off-by: Ladi Prosek <[email protected]> Signed-off-by: Radim Krčmář <[email protected]>
Jan Beulich [Tue, 4 Apr 2017 12:27:22 +0000 (06:27 -0600)]
xenbus: remove transaction holder from list before freeing
After allocation the item is being placed on the list right away.
Consequently it needs to be taken off the list before freeing in the
case xenbus_dev_request_and_reply() failed, as in that case the
callback (xenbus_dev_queue_reply()) is not being called (and if it
was called, it should do both).
Fix a crash from dereferencing a NULL dw_pcie_ops pointer. For example,
on ARTPEC-6:
Unable to handle kernel NULL pointer dereference at virtual address 00000004
pgd = c0204000
[00000004] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-next-20170321 #1
Hardware name: Axis ARTPEC-6 Platform
task: db098000 task.stack: db096000
PC is at dw_pcie_writel_dbi+0x2c/0xd0
Prior to 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into
host-only and core structures"), every driver had a struct pcie_host_ops
with function pointers, typically used as:
if (pp->ops->readl_rc)
return pp->ops->readl_rc(...);
442ec4c04d12 split struct pcie_host_ops into two pieces: struct
dw_pcie_host_ops and struct dw_pcie_ops, so the above became:
if (pci->ops->readl_dbi)
return pci->ops->readl_dbi(...);
But pcie-artpec6.c and pcie-designware-plat.c don't need the dw_pcie_ops
pointers and didn't supply a pci->ops struct, which leads to NULL pointer
dereferences.
Supply an empty struct dw_pcie_ops to avoid the NULL pointer dereferences.
[bhelgaas: changelog] Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into host-only and core structures") Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]> Acked-by: Joao Pinto <[email protected]>
Paul Mackerras [Tue, 4 Apr 2017 04:56:05 +0000 (14:56 +1000)]
powerpc: Don't try to fix up misaligned load-with-reservation instructions
In the past, there was only one load-with-reservation instruction,
lwarx, and if a program attempted a lwarx on a misaligned address, it
would take an alignment interrupt and the kernel handler would emulate
it as though it was lwzx, which was not really correct, but benign since
it is loading the right amount of data, and the lwarx should be paired
with a stwcx. to the same address, which would also cause an alignment
interrupt which would result in a SIGBUS being delivered to the process.
We now have 5 different sizes of load-with-reservation instruction. Of
those, lharx and ldarx cause an immediate SIGBUS by luck since their
entries in aligninfo[] overlap instructions which were not fixed up, but
lqarx overlaps with lhz and will be emulated as such. lbarx can never
generate an alignment interrupt since it only operates on 1 byte.
To straighten this out and fix the lqarx case, this adds code to detect
the l[hwdq]arx instructions and return without fixing them up, resulting
in a SIGBUS being delivered to the process.
This is a fix that prevents translation exception errors
on valid page tables for the instruction-exection-protection
support. This feature was added during the 4.11 merge window.
We have to remove an old check that would trigger if the
change-recording override is not available (e.g. edat1 disabled
via cpu model).
Christoffer Dall [Tue, 21 Mar 2017 21:05:22 +0000 (22:05 +0100)]
KVM: arm/arm64: vgic: Fix GICC_PMR uaccess on GICv3 and clarify ABI
As an oversight, for GICv2, we accidentally export the GICC_PMR register
in the format of the GICH_VMCR.VMPriMask field in the lower 5 bits of a
word, meaning that userspace must always use the lower 5 bits to
communicate with the KVM device and must shift the value left by 3
places to obtain the actual priority mask level.
Since GICv3 supports the full 8 bits of priority masking in the ICH_VMCR,
we have to fix the value we export when emulating a GICv2 on top of a
hardware GICv3 and exporting the emulated GICv2 state to userspace.
Take the chance to clarify this aspect of the ABI.
Christoffer Dall [Sat, 18 Mar 2017 12:56:56 +0000 (13:56 +0100)]
KVM: arm64: Ensure LRs are clear when they should be
We currently have some code to clear the list registers on GICv3, but we
never call this code, because the caller got nuked when removing the old
vgic. We also used to have a similar GICv2 part, but that got lost in
the process too.
Let's reintroduce the logic for GICv2 and call the logic when we
initialize the use of hypervisors on the CPU, for example when first
loading KVM or when exiting a low power state.
kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd
In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
unmap_stage2_range() on the entire memory range for the guest. This could
cause problems with other callers (e.g, munmap on a memslot) trying to
unmap a range. And since we have to unmap the entire Guest memory range
holding a spinlock, make sure we yield the lock if necessary, after we
unmap each PUD range.
Victor Kamensky [Tue, 4 Apr 2017 05:51:01 +0000 (22:51 -0700)]
arm64: mm: unaligned access by user-land should be received as SIGBUS
After 52d7523 (arm64: mm: allow the kernel to handle alignment faults on
user accesses) commit user-land accesses that produce unaligned exceptions
like in case of aarch32 ldm/stm/ldrd/strd instructions operating on
unaligned memory received by user-land as SIGSEGV. It is wrong, it should
be reported as SIGBUS as it was before 52d7523 commit.
Changed do_bad_area function to take signal and code parameters out of esr
value using fault_info table, so in case of do_alignment_fault fault
user-land will receive SIGBUS. Wrapped access to fault_info table into
esr_to_fault_info function.
Cc: <[email protected]> Fixes: 52d7523 (arm64: mm: allow the kernel to handle alignment faults on user accesses) Signed-off-by: Victor Kamensky <[email protected]> Signed-off-by: Will Deacon <[email protected]>
Keith Busch [Mon, 3 Apr 2017 19:25:53 +0000 (15:25 -0400)]
irq/affinity: Fix CPU spread for unbalanced nodes
The irq_create_affinity_masks routine is responsible for assigning a
number of interrupt vectors to CPUs. The optimal assignemnet will spread
requested vectors to all CPUs, with the fewest CPUs sharing a vector.
The algorithm may fail to assign some vectors to any CPUs if a node's
CPU count is lower than the average number of vectors per node. These
vectors are unusable and create an un-optimal spread.
Recalculate the number of vectors to assign at each node iteration by using
the remaining number of vectors and nodes to be assigned, not exceeding the
number of CPUs in that node. This will guarantee that every CPU is assigned
at least one vector.
Markus Trippelsdorf reported that after commit dcb17d22e1c2 ("tcp: warn
on bogus MSS and try to amend it") the kernel started logging the
warning for a NIC driver that doesn't even support GRO.
It was diagnosed that it was possibly caused on connections that were
using TCP Timestamps but some packets lacked the Timestamps option. As
we reduce rcv_mss when timestamps are used, the lack of them would cause
the packets to be bigger than expected, although this is a valid case.
As this warning is more as a hint, getting a clean-cut on the
threshold is probably not worth the execution time spent on it. This
patch thus alleviates the false-positives with 2 quick checks: by
accounting for the entire TCP option space and also checking against the
interface MTU if it's available.
These changes, specially the MTU one, might mask some real positives,
though if they are really happening, it's possible that sooner or later
it will be triggered anyway.
Merge tag 'xtensa-20170403' of git://github.com/jcmvbkbc/linux-xtensa
Pull Xtensa fixes from Max Filippov:
- make __pa work with uncached KSEG addresses, it fixes DMA memory
mmapping and DMA debug
- fix torn stack dump output
- wire up statx syscall
* tag 'xtensa-20170403' of git://github.com/jcmvbkbc/linux-xtensa:
xtensa: wire up statx system call
xtensa: fix stack dump output
xtensa: make __pa work with uncached KSEG addresses
Dave Airlie [Tue, 4 Apr 2017 00:13:40 +0000 (10:13 +1000)]
Merge branch 'msm-fixes-4.11-rc6' of git://people.freedesktop.org/~robclark/linux into drm-fixes
misc msm fixes.
* 'msm-fixes-4.11-rc6' of git://people.freedesktop.org/~robclark/linux:
drm/msm: Make sure to detach the MMU during GPU cleanup
drm/msm/hdmi: redefinitions of macros not required
drm/msm/mdp5: Update SSPP_MAX value
drm/msm/dsi: Fix bug in dsi_mgr_phy_enable
drm/msm: Don't allow zero sized buffer objects
drm/msm: Fix wrong pointer check in a5xx_destroy
drm/msm: adreno: fix build error without debugfs
Xin Long [Sat, 1 Apr 2017 09:15:59 +0000 (17:15 +0800)]
sctp: check for dst and pathmtu update in sctp_packet_config
This patch is to move sctp_transport_dst_check into sctp_packet_config
from sctp_packet_transmit and add pathmtu check in sctp_packet_config.
With this fix, sctp can update dst or pathmtu before appending chunks,
which can void dropping packets in sctp_packet_transmit when dst is
obsolete or dst's mtu is changed.
This patch is also to improve some other codes in sctp_packet_config.
It updates packet max_size with gso_max_size, checks for dst and
pathmtu, and appends ecne chunk only when packet is empty and asoc
is not NULL.
It makes sctp flush work better, as we only need to set up them once
for one flush schedule. It's also safe, since asoc is NULL only when
the packet is created by sctp_ootb_pkt_new in which it just gets the
new dst, no need to do more things for it other than set packet with
transport's pathmtu.
Simon Horman [Mon, 3 Apr 2017 19:42:58 +0000 (15:42 -0400)]
flow dissector: correct size of storage for ARP
The last argument to __skb_header_pointer() should be a buffer large
enough to store struct arphdr. This can be a pointer to a struct arphdr
structure. The code was previously using a pointer to a pointer to
struct arphdr.
By my counting the storage available both before and after is 8 bytes on
x86_64.
Without PCI_HOST_COMMON support enabled, we get a link error:
drivers/pci/dwc/built-in.o: In function `hisi_pcie_map_bus':
pcie-hisi.c:(.text+0x8860): undefined reference to `pci_ecam_map_bus'
drivers/pci/dwc/built-in.o: In function `hisi_pcie_almost_ecam_probe':
pcie-hisi.c:(.text+0x88b4): undefined reference to `pci_host_common_probe'
Add an explicit 'select', as the other users have.
SZ_16M PEM resource size includes PEM-specific register and its children
resources. Reservation of the whole SZ_16M range leads to child device
driver failure when pcieport driver is requesting resources:
pcieport 0004:1f:00.0: can't enable device: BAR 0 [mem 0x87e0c0f00000-0x87e0c0ffffff 64bit] not claimed
So we cannot reserve full 16M here and instead we want to reserve
PEM-specific register only which is SZ_64K.
At the end increase PEM resource to SZ_16M since this is what
thunder_pem_init() call expects for proper initialization.
Fixes: 9abb27c7594a ("PCI: thunder-pem: Add legacy firmware support for Cavium ThunderX host controller") Signed-off-by: Tomasz Nowicki <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> CC: [email protected] # v4.10+
Jordan Crouse [Mon, 6 Feb 2017 17:39:29 +0000 (10:39 -0700)]
drm/msm: Make sure to detach the MMU during GPU cleanup
We should be detaching the MMU before destroying the address
space. To do this cleanly, the detach has to happen in
adreno_gpu_cleanup() because it needs access to structs
in adreno_gpu.c. Plus it is better symmetry to have
the attach and detach at the same code level.
Archit Taneja [Fri, 17 Mar 2017 03:39:48 +0000 (09:09 +0530)]
drm/msm/mdp5: Update SSPP_MAX value
'SSPP_MAX + 1' is the max number of hwpipes that can be present on a
MDP5 platform. Recently, 2 new cursor hwpipes were added, which
caused overflows in arrays that used SSPP_MAX to represent the number
of elements. Update the SSPP_MAX value to incorporate the extra
hwpipes.
Archit Taneja [Thu, 16 Feb 2017 10:59:04 +0000 (16:29 +0530)]
drm/msm/dsi: Fix bug in dsi_mgr_phy_enable
A recent commit introduces a bug in dsi_mgr_phy_enable. In the non
dual DSI mode, we reset the mdsi (master DSI) PHY. This isn't right
since master and slave DSI exist only in dual DSI mode. For the normal
mode of operation, we should simply reset the PHY of the DSI device
(i.e. msm_dsi) corresponding to the current bridge.
Usage of the wrong DSI pointer also resulted in a static checker
warning. That too is resolved with this fix.
CPU: 1 PID: 2323 Comm: drm-api-test Tainted: G W 4.9.0-rc4-00906-g693af44 #213
Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
task: ffff8000d7353400 task.stack: ffff8000d7720000
PC is at drm_mm_insert_node_generic+0x258/0x2f0
LR is at drm_vma_offset_add+0x4c/0x70
Zero sized buffers serve no appreciable value to the user so disallow
them at create time.
Arnd Bergmann [Mon, 13 Mar 2017 16:43:48 +0000 (17:43 +0100)]
drm/msm: adreno: fix build error without debugfs
The newly added a5xx support fails to build when debugfs is diabled:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs' has no member named 'show'
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:11: error: 'a5xx_show' undeclared here (not in a function); did you mean 'a5xx_irq'?
Darrick J. Wong [Mon, 3 Apr 2017 19:22:39 +0000 (12:22 -0700)]
xfs: fix kernel memory exposure problems
Fix a memory exposure problems in inumbers where we allocate an array of
structures with holes, fail to zero the holes, then blindly copy the
kernel memory contents (junk and all) into userspace.
xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files
When punching past EOF on XFS, fallocate(mode=PUNCH_HOLE|KEEP_SIZE) will
round the file size up to the nearest multiple of PAGE_SIZE:
calvinow@vm-disks/generic-xfs-1 ~$ dd if=/dev/urandom of=test bs=2048 count=1
calvinow@vm-disks/generic-xfs-1 ~$ stat test
Size: 2048 Blocks: 8 IO Block: 4096 regular file
calvinow@vm-disks/generic-xfs-1 ~$ fallocate -n -l 2048 -o 2048 -p test
calvinow@vm-disks/generic-xfs-1 ~$ stat test
Size: 4096 Blocks: 8 IO Block: 4096 regular file
Commit 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes") replaced
xfs_zero_remaining_bytes() with calls to iomap helpers. The new helpers
don't enforce that [pos,offset) lies strictly on [0,i_size) when being
called from xfs_free_file_space(), so by "leaking" these ranges into
xfs_zero_range() we get this buggy behavior.
Fix this by reintroducing the checks xfs_zero_remaining_bytes() did
against i_size at the bottom of xfs_free_file_space().
Darrick J. Wong [Mon, 3 Apr 2017 19:22:20 +0000 (12:22 -0700)]
xfs: rework the inline directory verifiers
The inline directory verifiers should be called on the inode fork data,
which means after iformat_local on the read side, and prior to
ifork_flush on the write side. This makes the fork verifier more
consistent with the way buffer verifiers work -- i.e. they will operate
on the memory buffer that the code will be reading and writing directly.
Furthermore, revise the verifier function to return -EFSCORRUPTED so
that we don't flood the logs with corruption messages and assert
notices. This has been a particular problem with xfs/348, which
triggers the XFS_WANT_CORRUPTED_RETURN assertions, which halts the
kernel when CONFIG_XFS_DEBUG=y. Disk corruption isn't supposed to do
that, at least not in a verifier.
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Martin Schwidefsky:
"Four bug fixes, two of them for stable:
- avoid initrd corruptions in the kernel decompressor
- prevent inconsistent dumps if the boot CPU does not have address
zero
- fix the new pkey interface added with the merge window for 4.11
- a fix for a fix, another issue with user copy zero padding"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/uaccess: get_user() should zero on failure (again)
s390/pkey: Fix wrong handling of secure key with old MKVP
s390/smp: fix ipl from cpu with non-zero address
s390/decompressor: fix initrd corruption caused by bss clear
Merge tag 'iio-fixes-for-4.11d' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
4th set of IIO fixes for the 4.12 cycle.
core
- fix IIO_VAL_FRACTIONAL_LOG2 handling for negative values.
bmg160
- reset chip on probe to avoid a failure on some systems
cros_ec
- return type correctly when reading raw and calibbias data.
hid-sensor-accel
- fix a duplicate scan index error due to wrong number of channels
for gravity sensor.
hid-sensors
- ensure a get_feature is always done before the first set feature to
avoid issues with wrong cached values.
st-pressure
- initalize lps22hb boot time to avoid giving stale data.
Heiko Carstens [Fri, 31 Mar 2017 10:50:48 +0000 (12:50 +0200)]
KVM: s390: remove change-recording override support
Change-recording override (CO) was never implemented in any
machine. According to the architecture it is unpredictable if a
translation-specification exception will be recognized if the bit is
set and EDAT1 does not apply.
Therefore the easiest solution is to simply ignore the bit.
This also fixes commit cd1836f583d7 ("KVM: s390:
instruction-execution-protection support"). A guest may enable
instruction-execution-protection (IEP) but not EDAT1. In such a case
the guest_translate() function (arch/s390/kvm/gaccess.c) will report a
specification exception on pages that have the IEP bit set while it
should not.
It might make sense to add full IEP support to guest_translate() and
the GACC_IFETCH case. However, as far as I can tell the GACC_IFETCH
case is currently only used after an instruction was executed in order
to fetch the failing instruction. So there is no additional problem
*currently*.
David Howells [Fri, 31 Mar 2017 17:32:17 +0000 (18:32 +0100)]
statx: Include a mask for stx_attributes in struct statx
Include a mask in struct stat to indicate which bits of stx_attributes the
filesystem actually supports.
This would also be useful if we add another system call that allows you to
do a 'bulk attribute set' and pass in a statx struct with the masks
appropriately set to say what you want to set.
David Howells [Fri, 31 Mar 2017 17:32:10 +0000 (18:32 +0100)]
statx: Reserve the top bit of the mask for future struct expansion
Reserve the top bit of the mask for future expansion of the statx struct
and give an error if statx() sees it set. All the other bits are ignored
if we see them set but don't support the bit; we just clear the bit in the
returned mask.
David Howells [Fri, 31 Mar 2017 17:31:56 +0000 (18:31 +0100)]
ext4: Add statx support
Return enhanced file attributes from the Ext4 filesystem. This includes
the following:
(1) The inode creation time (i_crtime) as stx_btime, setting STATX_BTIME.
(2) Certain FS_xxx_FL flags are mapped to stx_attribute flags.
This requires that all ext4 inodes have a getattr call, not just some of
them, so to this end, split the ext4_getattr() function and only call part
of it where appropriate.
Eric Biggers [Fri, 31 Mar 2017 17:31:48 +0000 (18:31 +0100)]
statx: optimize copy of struct statx to userspace
I found that statx() was significantly slower than stat(). As a
microbenchmark, I compared 10,000,000 invocations of fstat() on a tmpfs
file to the same with statx() passed a NULL path:
$ time ./stat_benchmark
real 0m1.464s
user 0m0.275s
sys 0m1.187s
$ time ./statx_benchmark
real 0m5.530s
user 0m0.281s
sys 0m5.247s
statx is expected to be a little slower than stat because struct statx
is larger than struct stat, but not by *that* much. It turns out that
most of the overhead was in copying struct statx to userspace, mostly in
all the stac/clac instructions that got generated for each __put_user()
call. (This was on x86_64, but some other architectures, e.g. arm64,
have something similar now too.)
stat() instead initializes its struct on the stack and copies it to
userspace with a single call to copy_to_user(). This turns out to be
much faster, and changing statx to do this makes it almost as fast as
stat:
$ time ./statx_benchmark
real 0m1.624s
user 0m0.270s
sys 0m1.354s
For zeroing the reserved fields, start by zeroing the full struct with
memset. This makes it clear that every byte copied to userspace is
initialized, even implicit padding bytes (though there are none
currently). In the scenarios I tested, it also performed the same as a
designated initializer. Manually initializing each field was still
slightly faster, but would have been more error-prone and less
verifiable.
Also rename statx_set_result() to cp_statx() for consistency with
cp_old_stat() et al., and make it noinline so that struct statx doesn't
add to the stack usage during the main portion of the syscall execution.
Eric Biggers [Fri, 31 Mar 2017 17:31:40 +0000 (18:31 +0100)]
statx: remove incorrect part of vfs_statx() comment
request_mask and query_flags are function arguments, not passed in
struct kstat. So remove the part of the comment which claims otherwise.
This was apparently left over from an earlier version of the statx
patch.
Eric Biggers [Fri, 31 Mar 2017 17:31:32 +0000 (18:31 +0100)]
statx: reject unknown flags when using NULL path
The statx() system call currently accepts unknown flags when called with
a NULL path to operate on a file descriptor. Left unchanged, this could
make it hard to introduce new query flags in the future, since
applications may not be able to tell whether a given flag is supported.
Fix this by failing the system call with EINVAL if any flags other than
KSTAT_QUERY_FLAGS are specified in combination with a NULL path.
Arguably, we could still permit known lookup-related flags such as
AT_SYMLINK_NOFOLLOW. However, that would be inconsistent with how
sys_utimensat() behaves when passed a NULL path, which seems to be the
closest precedent. And given that the NULL path case is (I believe)
mainly intended to be used to implement a wrapper function like fstatx()
that doesn't have a path argument, I think rejecting lookup-related
flags too is probably the best choice.
Make sure to reserve the boot memory for the flattened device tree.
Otherwise it might get overwritten, e.g. when initial_boot_params is
copied, leading to a corrupted FDT and a boot hang/crash:
bootconsole [early0] enabled
Early console on uart16650 initialized at 0xf8001600
OF: fdt: Error -11 processing FDT
Kernel panic - not syncing: setup_cpuinfo: No CPU found in devicetree!
---[ end Kernel panic - not syncing: setup_cpuinfo: No CPU found in devicetree!
Guenter Roeck says:
> I think I found the problem. In unflatten_and_copy_device_tree(), with added
> debug information:
>
> OF: fdt: initial_boot_params=c861e400, dt=c861f000 size=28874 (0x70ca)
>
> ... and then initial_boot_params is copied to dt, which results in corrupted
> fdt since the memory overlaps. Looks like the initial_boot_params memory
> is not reserved and (re-)allocated by early_init_dt_alloc_memory_arch().
net: ethernet: ti: cpsw: wake tx queues on ndo_tx_timeout
In case, if TX watchdog is fired some or all netdev TX queues will be
stopped and as part of recovery it is required not only to drain and
reinitailize CPSW TX channeles, but also wake up stoppted TX queues what
doesn't happen now and netdevice will stop transmiting data until
reopenned.
Hence, add netif_tx_wake_all_queues() call in .ndo_tx_timeout() to complete
recovery and restore TX path.
Merge tag 'dmaengine-fix-4.11-rc5' of git://git.infradead.org/users/vkoul/slave-dma
Pull dmaengine fixes from Vinod Koul:
"A couple of minor fixes for 4.11:
- array bound fix for __get_unmap_pool()
- cyclic period splitting for bcm2835"
* tag 'dmaengine-fix-4.11-rc5' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: Fix array index out of bounds warning in __get_unmap_pool()
dmaengine: bcm2835: Fix cyclic DMA period splitting
Xiubo Li [Fri, 31 Mar 2017 02:35:25 +0000 (10:35 +0800)]
tcmu: Skip Data-Out blocks before gathering Data-In buffer for BIDI case
For the bidirectional case, the Data-Out buffer blocks will always at
the head of the tcmu_cmd's bitmap, and before gathering the Data-In
buffer, first of all it should skip the Data-Out ones, or the device
supporting BIDI commands won't work.
iscsi-target: Drop work-around for legacy GlobalSAN initiator
Once upon a time back in 2009, a work-around was added to support
the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login
did not propose nor respond to MaxBurstLength, FirstBurstLength,
DefaultTime2Wait and DefaultTime2Retain keys.
The work-around in iscsi_check_proposer_for_optional_reply()
allowed the missing keys to be proposed, but did not require
waiting for a response before moving to full feature phase
operation. This allowed GlobalSAN v3.3 to work out-of-the
box, and for many years we didn't run into login interopt
issues with any other initiators..
Until recently, when Martin tried a QLogic 57840S iSCSI Offload
HBA on Windows 2016 which completed login, but subsequently
failed with:
Got unknown iSCSI OpCode: 0x43
The issue was QLogic MSFT side did not propose DefaultTime2Wait +
DefaultTime2Retain, so LIO proposes them itself, and immediately
transitions to full feature phase because of the GlobalSAN hack.
However, the QLogic MSFT side still attempts to respond to
DefaultTime2Retain + DefaultTime2Wait, even though LIO has set
ISCSI_FLAG_LOGIN_NEXT_STAGE3 + ISCSI_FLAG_LOGIN_TRANSIT
in last login response.
So while the QLogic MSFT side should have been proposing these
two keys to start, it was doing the correct thing per RFC-3720
attempting to respond to proposed keys before transitioning to
full feature phase.
All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541)
does correctly propose the four keys during login, making the
original work-around moot.
So in order to allow QLogic MSFT to run unmodified as-is, go
ahead and drop this long standing work-around.
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"This update provides:
- prevent KASLR from randomizing EFI regions
- restrict the usage of -maccumulate-outgoing-args and document when
and why it is required.
- make the Global Physical Address calculation for UV4 systems work
correctly.
- address a copy->paste->forgot-edit problem in the MCE exception
table entries.
- assign a name to AMD MCA bank 3, so the sysfs file registration
works.
- add a missing include in the boot code"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/boot: Include missing header file
x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs
x86/build: Mostly disable '-maccumulate-outgoing-args'
x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization
x86/mce: Fix copy/paste error in exception table entries
x86/platform/uv: Fix calculation of Global Physical Address
Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Thomas Gleixner:
"This update provides:
- make the scheduler clock switch to unstable mode smooth so the
timestamps stay at microseconds granularity instead of switching to
tick granularity.
- unbreak perf test tsc by taking the new offset into account which
was added in order to proveide better sched clock continuity
- switching sched clock to unstable mode runs all clock related
computations which affect the sched clock output itself from a work
queue. In case of preemption sched clock uses half updated data and
provides wrong timestamps. Keep the math in the protected context
and delegate only the static key switch to workqueue context.
- remove a duplicate header include"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/headers: Remove duplicate #include <linux/sched/debug.h> line
sched/clock: Fix broken stable to unstable transfer
sched/clock, x86/perf: Fix "perf test tsc"
sched/clock: Fix clear_sched_clock_stable() preempt wobbly
Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull EFI fix from Thomas Gleixner:
"Downgrade the missing ESRT header printk to warning level and remove a
useless error printk which just generates noise for no value"
* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi/esrt: Cleanup bad memory map log messages
Al Viro [Sat, 18 Feb 2017 01:16:34 +0000 (20:16 -0500)]
make skb_copy_datagram_msg() et.al. preserve ->msg_iter on error
Fixes the mess observed in e.g. rsync over a noisy link we'd been
seeing since last Summer. What happens is that we copy part of
a datagram before noticing a checksum mismatch. Datagram will be
resent, all right, but we want the next try go into the same place,
not after it...
All this family of primitives (copy/checksum and copy a datagram
into destination) is "all or nothing" sort of interface - either
we get 0 (meaning that copy had been successful) or we get an
error (and no way to tell how much had been copied before we ran
into whatever error it had been). Make all of them leave iterator
unadvanced in case of errors - all callers must be able to cope
with that (an error might've been caught before the iterator had
been advanced), it costs very little to arrange, it's safer for
callers and actually fixes at least one bug in said callers.
When system bootup without get sensor property, set sensor
property will be fail.
If no get_feature operation done before set_feature, the sensor
properties will all be the initialized value, which is not the
same with sensor real properties. When set sensor property it will
write back to sensor the changed perperty data combines with other
sensor properties data, it is not right and may be dangerous.
In order to get all sensor properties, choose to read one of the sensor
properties(no matter read any sensor peroperty, driver will get all
the peroperties and return the requested one).
iio: accel: hid-sensor-accel-3d: Fix duplicate scan index error
When both accel_3d and gravity sensor are present, iio_device_register()
fails with "Duplicate scan index" error.
The reason for this is setting of indio_dev->num_channels based on
accel_3d channel for both gravity and accel-3d sensor. But number of
channels are not same, so for gravity it is pointing to some invalid
memory and getting scan_index to compare which may match.
To fix this issue, set the indio_dev->num_channels correctly based on
the sensor type.
Nikolaus Schulz [Fri, 24 Mar 2017 12:41:51 +0000 (13:41 +0100)]
iio: core: Fix IIO_VAL_FRACTIONAL_LOG2 for negative values
Fix formatting of negative values of type IIO_VAL_FRACTIONAL_LOG2 by
switching from do_div(), which can't handle negative numbers, to
div_s64_rem(). Also use shift_right for shifting, which is safe with
negative values.
Shrirang Bagul [Thu, 30 Mar 2017 15:47:21 +0000 (23:47 +0800)]
iio: st_pressure: initialize lps22hb bootime
This patch initializes the bootime in struct st_sensor_settings for
lps22hb sensor. Without this, sensor channels read from sysfs always
report stale values.
David S. Miller [Sun, 2 Apr 2017 03:16:42 +0000 (20:16 -0700)]
Merge branch 'l2tp_session_find-fixes'
Guillaume Nault says:
====================
l2tp: fix usage of l2tp_session_find()
l2tp_session_find() doesn't take a reference on the session returned to
its caller. Virtually all l2tp_session_find() users are racy, either
because the session can disappear from under them or because they take
a reference too late. This leads to bugs like 'use after free' or
failure to notice duplicate session creations.
In some cases, taking a reference on the session is not enough. The
special callbacks .ref() and .deref() also have to be called in cases
where the PPP pseudo-wire uses the socket associated with the session.
Therefore, when looking up a session, we also have to pass a flag
indicating if the .ref() callback has to be called.
In the future, we probably could drop the .ref() and .deref() callbacks
entirely by protecting the .sock field of struct pppol2tp_session with
RCU, thus allowing it to be freed and set to NULL even if the L2TP
session is still alive.
====================
Guillaume Nault [Fri, 31 Mar 2017 11:02:30 +0000 (13:02 +0200)]
l2tp: take a reference on sessions used in genetlink handlers
Callers of l2tp_nl_session_find() need to hold a reference on the
returned session since there's no guarantee that it isn't going to
disappear from under them.
Relying on the fact that no l2tp netlink message may be processed
concurrently isn't enough: sessions can be deleted by other means
(e.g. by closing the PPPOL2TP socket of a ppp pseudowire).
l2tp_nl_cmd_session_delete() is a bit special: it runs a callback
function that may require a previous call to session->ref(). In
particular, for ppp pseudowires, the callback is l2tp_session_delete(),
which then calls pppol2tp_session_close() and dereferences the PPPOL2TP
socket. The socket might already be gone at the moment
l2tp_session_delete() calls session->ref(), so we need to take a
reference during the session lookup. So we need to pass the do_ref
variable down to l2tp_session_get() and l2tp_session_get_by_ifname().
Since all callers have to be updated, l2tp_session_find_by_ifname() and
l2tp_nl_session_find() are renamed to reflect their new behaviour.
Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Guillaume Nault [Fri, 31 Mar 2017 11:02:29 +0000 (13:02 +0200)]
l2tp: hold session while sending creation notifications
l2tp_session_find() doesn't take any reference on the returned session.
Therefore, the session may disappear while sending the notification.
Use l2tp_session_get() instead and decrement session's refcount once
the notification is sent.
Fixes: 33f72e6f0c67 ("l2tp : multicast notification to the registered listeners") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Guillaume Nault [Fri, 31 Mar 2017 11:02:27 +0000 (13:02 +0200)]
l2tp: fix duplicate session creation
l2tp_session_create() relies on its caller for checking for duplicate
sessions. This is racy since a session can be concurrently inserted
after the caller's verification.
Fix this by letting l2tp_session_create() verify sessions uniqueness
upon insertion. Callers need to be adapted to check for
l2tp_session_create()'s return code instead of calling
l2tp_session_find().
pppol2tp_connect() is a bit special because it has to work on existing
sessions (if they're not connected) or to create a new session if none
is found. When acting on a preexisting session, a reference must be
held or it could go away on us. So we have to use l2tp_session_get()
instead of l2tp_session_find() and drop the reference before exiting.
Fixes: d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support") Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Guillaume Nault [Fri, 31 Mar 2017 11:02:26 +0000 (13:02 +0200)]
l2tp: ensure session can't get removed during pppol2tp_session_ioctl()
Holding a reference on session is required before calling
pppol2tp_session_ioctl(). The session could get freed while processing the
ioctl otherwise. Since pppol2tp_session_ioctl() uses the session's socket,
we also need to take a reference on it in l2tp_session_get().
Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Guillaume Nault [Fri, 31 Mar 2017 11:02:25 +0000 (13:02 +0200)]
l2tp: fix race in l2tp_recv_common()
Taking a reference on sessions in l2tp_recv_common() is racy; this
has to be done by the callers.
To this end, a new function is required (l2tp_session_get()) to
atomically lookup a session and take a reference on it. Callers then
have to manually drop this reference.
Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Merge branch 'parisc-4.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc fixes from Helge Deller:
"Al Viro reported that - in case of read faults - our copy_from_user()
implementation may claim to have copied more bytes than it actually
did. In order to fix this bug and because of the way how gcc optimizes
register usage for inline assembly in C code, we had to replace our
pa_memcpy() function with a pure assembler implementation.
While fixing the memcpy bug we noticed some other issues with our
get_user() and put_user() functions, e.g. nested faults may return
wrong data. This is now fixed by a common fixup handler for
get_user/put_user in the exception handler which additionally makes
generated code smaller and faster.
The third patch is a trivial one-line fix for a patch which went in
during 4.11-rc and which avoids stalled CPU warnings after power
shutdown (for parisc machines which can't plug power off themselves).
Due to the rewrite of pa_memcpy() into assembly this patch got bigger
than what I wanted to have sent at this stage.
Those patches have been running in production during the last few days
on our debian build servers without any further issues"
* 'parisc-4.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Avoid stalled CPU warnings after system shutdown
parisc: Clean up fixup routines for get_user()/put_user()
parisc: Fix access fault handling in pa_memcpy()
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Thirteen small fixes: The hopefully final effort to get the lpfc nvme
kconfig problems sorted, there's one important sg fix (user can induce
read after end of buffer) and one minor enhancement (adding an extra
PCI ID to qedi). The rest are a set of minor fixes, which mostly occur
as user visible in error legs or on specific devices"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: ufs: remove the duplicated checking for supporting clkscaling
scsi: lpfc: fix building without debugfs support
scsi: lpfc: Fix PT2PT PRLI reject
scsi: hpsa: fix volume offline state
scsi: libsas: fix ata xfer length
scsi: scsi_dh_alua: Warn if the first argument of alua_rtpg_queue() is NULL
scsi: scsi_dh_alua: Ensure that alua_activate() calls the completion function
scsi: scsi_dh_alua: Check scsi_device_get() return value
scsi: sg: check length passed to SG_NEXT_CMD_LEN
scsi: ufshcd-platform: remove the useless cast in ERR_PTR/IS_ERR
scsi: qedi: Add PCI device-ID for QL41xxx adapters.
scsi: aacraid: Fix potential null access
scsi: qla2xxx: Fix crash in qla2xxx_eh_abort on bad ptr
* emailed patches from Andrew Morton <[email protected]>:
kasan: do not sanitize kexec purgatory
drivers/rapidio/devices/tsi721.c: make module parameter variable name unique
mm/hugetlb.c: don't call region_abort if region_chg fails
kasan: report only the first error by default
hugetlbfs: initialize shared policy as part of inode allocation
mm: fix section name for .data..ro_after_init
mm, hugetlb: use pte_present() instead of pmd_present() in follow_huge_pmd()
mm: workingset: fix premature shadow node shrinking with cgroups
mm: rmap: fix huge file mmap accounting in the memcg stats
mm: move mm_percpu_wq initialization earlier
mm: migrate: fix remove_migration_pte() for ksm pages
David S. Miller [Sat, 1 Apr 2017 20:31:15 +0000 (13:31 -0700)]
Merge tag 'mac80211-for-davem-2017-03-31' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
Two fixes:
* don't block netdev queues (indefinitely!) if mac80211
manages traffic queueing itself
* check wiphy registration before checking for ops
on resume, to avoid crash
====================
David S. Miller [Sat, 1 Apr 2017 19:36:38 +0000 (12:36 -0700)]
Merge branch 'bpf-map_value_adj-reg-types-fixes'
Daniel Borkmann says:
====================
BPF fixes on map_value_adj reg types
This set adds two fixes for map_value_adj register type in the
verifier and user space tests along with them for the BPF self
test suite. For details, please see individual patches.
====================
Daniel Borkmann [Fri, 31 Mar 2017 00:24:04 +0000 (02:24 +0200)]
bpf: add various verifier test cases for self-tests
Add a couple of test cases, for example, probing for xadd on a spilled
pointer to packet and map_value_adj register, various other map_value_adj
tests including the unaligned load/store, and trying out pointer arithmetic
on map_value_adj register itself. For the unaligned load/store, we need
to figure out whether the architecture has efficient unaligned access and
need to mark affected tests accordingly.
Daniel Borkmann [Fri, 31 Mar 2017 00:24:03 +0000 (02:24 +0200)]
bpf, verifier: fix rejection of unaligned access checks for map_value_adj
Currently, the verifier doesn't reject unaligned access for map_value_adj
register types. Commit 484611357c19 ("bpf: allow access into map value
arrays") added logic to check_ptr_alignment() extending it from PTR_TO_PACKET
to also PTR_TO_MAP_VALUE_ADJ, but for PTR_TO_MAP_VALUE_ADJ no enforcement
is in place, because reg->id for PTR_TO_MAP_VALUE_ADJ reg types is never
non-zero, meaning, we can cause BPF_H/_W/_DW-based unaligned access for
architectures not supporting efficient unaligned access, and thus worst
case could raise exceptions on some archs that are unable to correct the
unaligned access or perform a different memory access to the actual
requested one and such.
i) Unaligned load with !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
on r0 (map_value_adj):
For the PTR_TO_PACKET type, reg->id is initially zero when skb->data
was fetched, it later receives a reg->id from env->id_gen generator
once another register with UNKNOWN_VALUE type was added to it via
check_packet_ptr_add(). The purpose of this reg->id is twofold: i) it
is used in find_good_pkt_pointers() for setting the allowed access
range for regs with PTR_TO_PACKET of same id once verifier matched
on data/data_end tests, and ii) for check_ptr_alignment() to determine
that when not having efficient unaligned access and register with
UNKNOWN_VALUE was added to PTR_TO_PACKET, that we're only allowed
to access the content bytewise due to unknown unalignment. reg->id
was never intended for PTR_TO_MAP_VALUE{,_ADJ} types and thus is
always zero, the only marking is in PTR_TO_MAP_VALUE_OR_NULL that
was added after 484611357c19 via 57a09bf0a416 ("bpf: Detect identical
PTR_TO_MAP_VALUE_OR_NULL registers"). Above tests will fail for
non-root environment due to prohibited pointer arithmetic.
The fix splits register-type specific checks into their own helper
instead of keeping them combined, so we don't run into a similar
issue in future once we extend check_ptr_alignment() further and
forget to add reg->type checks for some of the checks.
Daniel Borkmann [Fri, 31 Mar 2017 00:24:02 +0000 (02:24 +0200)]
bpf, verifier: fix alu ops against map_value{, _adj} register types
While looking into map_value_adj, I noticed that alu operations
directly on the map_value() resp. map_value_adj() register (any
alu operation on a map_value() register will turn it into a
map_value_adj() typed register) are not sufficiently protected
against some of the operations. Two non-exhaustive examples are
provided that the verifier needs to reject:
from 6 to 9: R0=inv,min_value=0,max_value=0 R10=fp
9: (95) exit
processed 10 insns
Issue is, while min_value / max_value boundaries for the access
are adjusted appropriately, we change the pointer value in a way
that cannot be sufficiently tracked anymore from its origin.
Operations like BPF_{AND,OR,DIV,MUL,etc} on a destination register
that is PTR_TO_MAP_VALUE{,_ADJ} was probably unintended, in fact,
all the test cases coming with 484611357c19 ("bpf: allow access
into map value arrays") perform BPF_ADD only on the destination
register that is PTR_TO_MAP_VALUE_ADJ.
Only for UNKNOWN_VALUE register types such operations make sense,
f.e. with unknown memory content fetched initially from a constant
offset from the map value memory into a register. That register is
then later tested against lower / upper bounds, so that the verifier
can then do the tracking of min_value / max_value, and properly
check once that UNKNOWN_VALUE register is added to the destination
register with type PTR_TO_MAP_VALUE{,_ADJ}. This is also what the
original use-case is solving. Note, tracking on what is being
added is done through adjust_reg_min_max_vals() and later access
to the map value enforced with these boundaries and the given offset
from the insn through check_map_access_adj().
Tests will fail for non-root environment due to prohibited pointer
arithmetic, in particular in check_alu_op(), we bail out on the
is_pointer_value() check on the dst_reg (which is false in root
case as we allow for pointer arithmetic via env->allow_ptr_leaks).
Similarly to PTR_TO_PACKET, one way to fix it is to restrict the
allowed operations on PTR_TO_MAP_VALUE{,_ADJ} registers to 64 bit
mode BPF_ADD. The test_verifier suite runs fine after the patch
and it also rejects mentioned test cases.
Yi-Hung Wei [Thu, 30 Mar 2017 19:36:03 +0000 (12:36 -0700)]
openvswitch: Fix ovs_flow_key_update()
ovs_flow_key_update() is called when the flow key is invalid, and it is
used to update and revalidate the flow key. Commit 329f45bc4f19
("openvswitch: add mac_proto field to the flow key") introduces mac_proto
field to flow key and use it to determine whether the flow key is valid.
However, the commit does not update the code path in ovs_flow_key_update()
to revalidate the flow key which may cause BUG_ON() on execute_recirc().
This patch addresses the aforementioned issue.
Fixes: 329f45bc4f19 ("openvswitch: add mac_proto field to the flow key") Signed-off-by: Yi-Hung Wei <[email protected]> Acked-by: Jiri Benc <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Mark Brown [Thu, 30 Mar 2017 16:00:12 +0000 (17:00 +0100)]
net/faraday: Explicitly include linux/of.h and linux/property.h
This driver uses interfaces from linux/of.h and linux/property.h but
relies on implict inclusion of those headers which means that changes in
other headers could break the build, as happened in -next for arm today.
Add a explicit includes.
Merge tag 'usb-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes for 4.11-rc5.
The usual xhci fixes are here, as well as a fix for yet-another-bug-
found-by-KASAN, those developers are doing great stuff here.
And there's a phy build warning fix that showed up in 4.11-rc1.
All of these have been in linux-next with no reported issues"
* tag 'usb-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: phy: isp1301: Fix build warning when CONFIG_OF is disabled
xhci: Manually give back cancelled URB if we can't queue it for cancel
xhci: Set URB actual length for stopped control transfers
xhci: plat: Register shutdown for xhci_plat
USB: fix linked-list corruption in rh_call_control()
Merge tag 'tty-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are some small fixes for some serial drivers and Kconfig help
text for 4.11-rc5. Nothing major here at all, a few things resolving
reported bugs in some random serial drivers.
I don't think these made the last linux-next due to me getting to them
yesterday, but I am not sure, they might have snuck in. The patches
only affect drivers that the maintainers of sent me these patches for,
so we should be safe here :)"
* tag 'tty-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: pl011: fix earlycon work-around for QDF2400 erratum 44
serial: 8250_EXAR: fix duplicate Kconfig text and add missing help text
tty/serial: atmel: fix TX path in atmel_console_write()
tty/serial: atmel: fix race condition (TX+DMA)
serial: mxs-auart: Fix baudrate calculation
projects / linux.git / log