Age | Commit message (Collapse) | Author | Files | Lines |
|
Andrey Konovalov reported a possible out-of-bounds problem for a USB interface
association descriptor. He writes:
It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION
descriptor. It's only checked that the size is >= 2 in
usb_parse_configuration(), so find_iad() might do out-of-bounds access
to intf_assoc->bInterfaceCount.
And he's right, we don't check for crazy descriptors of this type very well, so
resolve this problem. Yet another issue found by syzkaller...
Reported-by: Andrey Konovalov <[email protected]>
Tested-by: Andrey Konovalov <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Extend the container size to 0x2000 to include the gpio controller at
offset 0x1040.
While at it, add start address notation to the gpio node name to match
its 'offset' property.
Fixes: 63dac0f4924b ("arm64: dts: marvell: add gpio support for Armada
7K/8K")
Cc: <[email protected]>
Signed-off-by: Baruch Siach <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
|
|
Add a maintainers entry for the Macchiatobin board.
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
|
|
If NO_DMA=y:
warning: (IPMMU_VMSA && ARM_SMMU && ARM_SMMU_V3 && QCOM_IOMMU) selects IOMMU_IO_PGTABLE_LPAE which has unmet direct dependencies (IOMMU_SUPPORT && HAS_DMA && (ARM || ARM64 || COMPILE_TEST && !GENERIC_ATOMIC64))
and
drivers/iommu/io-pgtable-arm.o: In function `__arm_lpae_sync_pte':
io-pgtable-arm.c:(.text+0x206): undefined reference to `bad_dma_ops'
drivers/iommu/io-pgtable-arm.o: In function `__arm_lpae_free_pages':
io-pgtable-arm.c:(.text+0x6a6): undefined reference to `bad_dma_ops'
drivers/iommu/io-pgtable-arm.o: In function `__arm_lpae_alloc_pages':
io-pgtable-arm.c:(.text+0x812): undefined reference to `bad_dma_ops'
io-pgtable-arm.c:(.text+0x81c): undefined reference to `bad_dma_ops'
io-pgtable-arm.c:(.text+0x862): undefined reference to `bad_dma_ops'
drivers/iommu/io-pgtable-arm.o: In function `arm_lpae_run_tests':
io-pgtable-arm.c:(.init.text+0x86): undefined reference to `alloc_io_pgtable_ops'
io-pgtable-arm.c:(.init.text+0x47c): undefined reference to `free_io_pgtable_ops'
drivers/iommu/qcom_iommu.o: In function `qcom_iommu_init_domain':
qcom_iommu.c:(.text+0x1ce): undefined reference to `alloc_io_pgtable_ops'
drivers/iommu/qcom_iommu.o: In function `qcom_iommu_domain_free':
qcom_iommu.c:(.text+0x754): undefined reference to `free_io_pgtable_ops'
QCOM_IOMMU selects IOMMU_IO_PGTABLE_LPAE, which bypasses its dependency
on HAS_DMA. Make QCOM_IOMMU depend on HAS_DMA to fix this.
Fixes: 0ae349a0f33fb040 ("iommu/qcom: Add qcom_iommu")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
|
|
This is unused, and conflicts with the definition that we'll add for XPFO.
Signed-off-by: Tycho Andersen <[email protected]>
Reviewed-by: Julien Grall <[email protected]>
CC: Boris Ostrovsky <[email protected]>
CC: Juergen Gross <[email protected]>
CC: Stefano Stabellini <[email protected]>
Signed-off-by: Boris Ostrovsky <[email protected]>
|
|
WARN_ON_ONCE(pi_test_sn(&vmx->pi_desc)) in kvm_vcpu_trigger_posted_interrupt()
intends to detect the violation of invariant that VT-d PI notification
event is not suppressed when vcpu is in the guest mode. Because the
two checks for the target vcpu mode and the target suppress field
cannot be performed atomically, the target vcpu mode may change in
between. If that does happen, WARN_ON_ONCE() here may raise false
alarms.
As the previous patch fixed the real invariant breaker, remove this
WARN_ON_ONCE() to avoid false alarms, and document the allowed cases
instead.
Signed-off-by: Haozhong Zhang <[email protected]>
Reported-by: "Ramamurthy, Venkatesh" <[email protected]>
Reported-by: Dan Williams <[email protected]>
Reviewed-by: Paolo Bonzini <[email protected]>
Fixes: 28b835d60fcc ("KVM: Update Posted-Interrupts Descriptor when vCPU is preempted")
Signed-off-by: Radim Krčmář <[email protected]>
|
|
In kvm_vcpu_trigger_posted_interrupt() and pi_pre_block(), KVM
assumes that PI notification events should not be suppressed when the
target vCPU is not blocked.
vmx_update_pi_irte() sets the SN field before changing an interrupt
from posting to remapping, but it does not check the vCPU mode.
Therefore, the change of SN field may break above the assumption.
Besides, I don't see reasons to suppress notification events here, so
remove the changes of SN field to avoid race condition.
Signed-off-by: Haozhong Zhang <[email protected]>
Reported-by: "Ramamurthy, Venkatesh" <[email protected]>
Reported-by: Dan Williams <[email protected]>
Reviewed-by: Paolo Bonzini <[email protected]>
Fixes: 28b835d60fcc ("KVM: Update Posted-Interrupts Descriptor when vCPU is preempted")
Signed-off-by: Radim Krčmář <[email protected]>
|
|
Routine check_cr_write() will trigger emulator_get_cpuid()->
kvm_cpuid() to get maxphyaddr, and NULL is passed as values
for ebx/ecx/edx. This is problematic because kvm_cpuid() will
dereference these pointers.
Fixes: d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical address width.")
Reported-by: Jim Mattson <[email protected]>
Signed-off-by: Yu Zhang <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Reviewed-by: Jim Mattson <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
|
|
I ran into a build error on x86:
drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function 'decon_conf_irq':
drivers/gpu/drm/exynos/exynos5433_drm_decon.c:706:2: error: implicit declaration of function 'irq_set_status_flags'; did you mean 'dquot_state_flag'? [-Werror=implicit-function-declaration]
irq_set_status_flags(irq, IRQ_NOAUTOEN);
Adding the missing include fixes the error.
Fixes: b37d53a0382c ("drm/exynos/decon5433: move TE handling to DECON")
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Commit 7d902c05b480 ("drm: Nuke drm_atomic_helper_connector_dpms")
removed drm_atomic_helper_connector_dpms() helper saying that it was a dead
code. It was however indirectly used by Exynos DRM driver for implementing
suspend/resume support. To fix this regression (after that patch Exynos DRM
suspend/resume functions became no-ops and hardware fails to suspend),
this patch rewrites them with drm_atomic_helper_suspend/resume() helpers.
Fixes: 7d902c05b480 ("drm: Nuke drm_atomic_helper_connector_dpms")
Signed-off-by: Marek Szyprowski <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Commit 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()")
replaced unsafe drm_for_each_connector() with drm_for_each_connector_iter()
and removed surrounding drm_modeset_lock calls. However, that lock was
there not only to protect unsafe drm_for_each_connector(), but it was also
required to be held by the dpms code which was called from the loop body.
This patch restores those drm_modeset_lock calls to fix broken suspend
and resume of Exynos DRM subsystem in v4.13 kernel.
Fixes: 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()")
CC: [email protected] # v4.13
Signed-off-by: Marek Szyprowski <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
Building with gcc-4.6 results in this warning due to
dmar_table_print_dmar_entry being inlined as in newer compiler versions:
WARNING: vmlinux.o(.text+0x5c8bee): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry()
The function dmar_walk_remapping_entries() references
the function __init dmar_table_print_dmar_entry().
This is often because dmar_walk_remapping_entries lacks a __init
annotation or the annotation of dmar_table_print_dmar_entry is wrong.
This removes the __init annotation to avoid the warning. On compilers
that don't show the warning today, this should have no impact since the
function gets inlined anyway.
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
|
|
parisc:allmodconfig, xtensa:allmodconfig, and possibly others generate
the following Kconfig warning.
warning: (IPMMU_VMSA && ARM_SMMU && ARM_SMMU_V3 && QCOM_IOMMU) selects
IOMMU_IO_PGTABLE_LPAE which has unmet direct dependencies (IOMMU_SUPPORT &&
HAS_DMA && (ARM || ARM64 || COMPILE_TEST && !GENERIC_ATOMIC64))
IOMMU_IO_PGTABLE_LPAE depends on (COMPILE_TEST && !GENERIC_ATOMIC64),
so any configuration option selecting it needs to have the same dependencies.
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
|
|
Add the USB device id for the ELV TFD500 data logger.
Signed-off-by: Andreas Engel <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
|
|
gcc-7 notices that the pin_table is an array of 16-bit numbers,
but fails to take the following range check into account:
drivers/gpio/gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt':
drivers/gpio/gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=]
sprintf(ev_name, "_%c%02X",
^~~~
drivers/gpio/gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535]
sprintf(ev_name, "_%c%02X",
^~~~~~~~~
drivers/gpio/gpiolib-acpi.c:206:3: note: 'sprintf' output between 5 and 7 bytes into a destination of size 5
sprintf(ev_name, "_%c%02X",
^~~~~~~~~~~~~~~~~~~~~~~~~~~
agpio->triggering == ACPI_EDGE_SENSITIVE ? 'E' : 'L',
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pin);
~~~~
As suggested by Andy, this changes the format string to have a fixed length.
Since modifying the range check did not help, I also opened a bug against
gcc, see link below.
Fixes: 0d1c28a449c6 ("gpiolib-acpi: Add ACPI5 event model support to gpio.")
Cc: Andy Shevchenko <[email protected]>
Link: https://patchwork.kernel.org/patch/9840801/
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82123
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
IRQ_DOMAIN_HIERARCHY is not user-configurable, but supposed to be
selected by drivers that need IRQ domain hierarchy support.
GPIO_THUNDERX is the only user of "depends on IRQ_DOMAIN_HIERARCHY".
This means, we can not enable GPIO_THUNDERX unless other drivers
select IRQ_DOMAIN_HIERARCHY elsewhere. This is odd. Flip the logic.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: David Daney <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
When adding GPIO support for the cp2105, the mentioned commit by Martyn
Welch introduced a query for the part number of the chip. Unfortunately
the driver aborts probing when this query fails, so currently the driver
can not be used with chips not supporting this query.
I have a data cable for Siemens mobile phones (ID 10ab:10c5) where this
is the case.
With this patch the driver can be bound even if the part number can not
be queried.
Fixes: cf5276ce7867 ("USB: serial: cp210x: Adding GPIO support for CP2105")
Signed-off-by: Sebastian Frei <[email protected]>
[ johan: amend commit message; shorten error message and demote to
warning; drop unnecessary move of usb_set_serial_data() ]
Cc: stable <[email protected]> # 4.9
Signed-off-by: Johan Hovold <[email protected]>
|
|
DRIVER_ATTR is no longer in use, and driver authors should be using
DRIVER_ATTR_RW() or DRIVER_ATTR_RO() or DRIVER_ATTR_WO() instead in
order to always get the permissions correct. So remove it so that no
one can use it anymore.
Acked-by: Alan Tull <[email protected]>
Reviewed-by: Moritz Fischer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
It's better to be explicit and use the DRIVER_ATTR_RW() macro when
defining a driver's sysfs file.
This is part of a series to drop DRIVER_ATTR() from the tree entirely.
Cc: [email protected]
Reviewed-by: Moritz Fischer <[email protected]>
Acked-by: Alan Tull <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
This reverts commit 36ae3c0a36b7456432fedce38ae2f7bd3e01a563.
The commit broke compilation on !CONFIG_HAVE_KVM_IRQ_ROUTING. Also,
there may be cases with CONFIG_HAVE_KVM_IRQ_ROUTING, where larger
gsi values make sense.
As the commit was meant as an early indicator to user space that
something is wrong, reverting just restores the previous behavior
where overly large values are ignored when encountered (without
any direct feedback).
Reported-by: Abdul Haleem <[email protected]>
Signed-off-by: Jan H. Schönherr <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
|
|
The check for the _SEGMENT_ENTRY_PROTECT bit in gup_huge_pmd() is the
wrong way around. It must not be set for write==1, and not be checked for
write==0. Fix this similar to how it was fixed for ptes long time ago in
commit 25591b070336 ("[S390] fix get_user_pages_fast").
One impact of this bug would be unnecessarily using the gup slow path for
write==0 on r/w mappings. A potentially more severe impact would be that
gup_huge_pmd() will succeed for write==1 on r/o mappings.
Cc: <[email protected]>
Signed-off-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Commit 227be799c39a ("s390/mm: uninline pmdp_xxx functions from pgtable.h")
inadvertently changed the behavior of pmdp_invalidate(), so that it now
clears the pmd instead of just marking it as invalid. Fix this by restoring
the original behavior.
A possible impact of the misbehaving pmdp_invalidate() would be the
MADV_DONTNEED races (see commits ced10803 and 58ceeb6b), although we
should not have any negative impact on the related dirty/young flags,
since those flags are not set by the hardware on s390.
Fixes: 227be799c39a ("s390/mm: uninline pmdp_xxx functions from pgtable.h")
Cc: <[email protected]> # v4.6+
Signed-off-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
In some situations we don't receive notification from firmware that
a previously unusable channelpath is usable again.
Schedule recovery for devices that return from path verification
without using all potentially usable paths. The recovery thread will
periodically trigger a path verification on the affected devices.
Signed-off-by: Sebastian Ott <[email protected]>
Suggested-by: Peter Oberparleiter <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Fix these warnings found by sparse:
drivers/s390/block/scm_blk.c:257:24: warning: incorrect type in assignment (different base types)
drivers/s390/block/scm_blk.c:257:24: expected int [signed] <noident>
drivers/s390/block/scm_blk.c:257:24: got restricted blk_status_t [usertype] error
drivers/s390/block/scm_blk.c:420:33: warning: incorrect type in argument 2 (different base types)
drivers/s390/block/scm_blk.c:420:33: expected restricted blk_status_t [usertype] error
drivers/s390/block/scm_blk.c:420:33: got int [signed] <noident>
Signed-off-by: Sebastian Ott <[email protected]>
Reported-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
There are several problems with commit 10377ba7673d ("net: systemport:
Support 64bit statistics", first one got fixed in 7095c973453e ("net:
systemport: Fix 64-bit stats deadlock").
The second problem is that this specific code updates the
stats64.tx_{packets,bytes} from ndo_get_stats64() and that is what we
are returning to ethtool -S. If we are not running a tool that involves
calling ndo_get_stats64(), then we won't get updated ethtool stats.
The solution to this is to update the stats from both call sites,
factoring that into a specific function, While at it, don't just check
the sizeof() but also the type of the statistics in order to use the
64-bit stats seqlock.
Fixes: 10377ba7673d ("net: systemport: Support 64bit statistics")
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
It seems we have to be more careful in napi_complete_done()
use. This patch is not a revert, as it seems we can
avoid bug that Ville reported by moving the napi_complete_done()
test in the spinlock section.
Many thanks to Ville for detective work and all tests.
Fixes: 617f01211baf ("8139too: use napi_complete_done()")
Reported-by: Ville Syrjälä <[email protected]>
Tested-by: Ville Syrjälä <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When fixing things to avoid ambiguous cases I had a thinko
and included SIGPOLL/SIGIO in with all of the other signals
that have signal specific si_codes. Which is completely wrong.
Fix that.
Reported-by: Vince Weaver <[email protected]>
Signed-off-by: "Eric W. Biederman" <[email protected]>
|
|
Fujitsu-Siemens Lifebook S6120 misdetects the cable type for some
drives. The problematic one in this case is an mSATA SSD hooked up via a
mSATA->PATA bridge. With regular hard disks the detection seems to work
correctly.
Strangely an older Lifebook model (S6020) detects the cable as 80c
with the mSATA SSD, even if using the exact same flex cable.
Cc: Tejun Heo <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
|
|
Clean up workqueue.rst:
- fix minor typos
- put '@' after `` instead of preceding them (one place)
- use "CPU" instead of "cpu" in text consistently
- quote one function name
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: Florian Mickler <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
|
|
Maurice reports:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
IP: holder_class_store+0x253/0x2b0 [libnvdimm]
...while trying to reconfigure an NVDIMM-N namespace into 'sector' /
'btt' mode. The crash points to this line:
(gdb) li *(holder_class_store+0x253)
0x7773 is in holder_class_store (drivers/nvdimm/namespace_devs.c:1420).
1415 for (i = 0; i < nd_region->ndr_mappings; i++) {
1416 struct nd_mapping *nd_mapping = &nd_region->mapping[i];
1417 struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
1418 struct nd_namespace_index *nsindex;
1419
1420 nsindex = to_namespace_index(ndd, ndd->ns_current);
...where we are failing because ndd is NULL due to NVDIMM-N dimms not
supporting labels.
Long story short, default to the BTTv1 format in the label-less /
NVDIMM-N case.
Fixes: 14e494542636 ("libnvdimm, btt: BTT updates for UEFI 2.7 format")
Cc: <[email protected]>
Cc: Vishal Verma <[email protected]>
Reported-by: Maurice A. Saldivar <[email protected]>
Tested-by: Maurice A. Saldivar <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
|
|
remove tcp_may_send_now and tcp_snd_test that are no longer used
Fixes: 840a3cbe8969 ("tcp: remove forward retransmit feature")
Signed-off-by: Yuchung Cheng <[email protected]>
Signed-off-by: Neal Cardwell <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Improve coverage of NVDIMM-N test scenarios by providing a test bus
incapable of label operations.
Signed-off-by: Dan Williams <[email protected]>
|
|
If bpf_map_precharge_memlock in dev_map_alloc, -ENOMEM is returned
regardless of the actual error produced by bpf_map_precharge_memlock.
Fix it by passing on the error returned by bpf_map_precharge_memlock.
Also return -EINVAL instead of -ENOMEM if the page count overflow check
fails.
This makes dev_map_alloc match the behavior of other bpf maps' alloc
functions wrt. return values.
Signed-off-by: Tobias Klauser <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Check for ingress-only qdisc for flower offload, as other qdiscs
are not supported for flower offload.
Suggested-by: Jiri Pirko <[email protected]>
Signed-off-by: Sathya Perla <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
We copy a local resource structure into a list, but only
initialize some of its members, as pointed out by gcc-4.4:
drivers/acpi/acpi_watchdog.c: In function 'acpi_watchdog_init':
drivers/acpi/acpi_watchdog.c:105: error: 'res.child' may be used uninitialized in this function
drivers/acpi/acpi_watchdog.c:105: error: 'res.sibling' may be used uninitialized in this function
drivers/acpi/acpi_watchdog.c:105: error: 'res.parent' may be used uninitialized in this function
drivers/acpi/acpi_watchdog.c:105: error: 'res.desc' may be used uninitialized in this function
drivers/acpi/acpi_watchdog.c:105: error: 'res.name' may be used uninitialized in this function
Newer compilers can presumably optimize the uninitialized access
away entirely and don't warn at all, but rely on the kzalloc()
to zero the structure first. This adds an explicit initialization
to force consistent behavior.
Fixes: 058dfc767008 (ACPI / watchdog: Add support for WDAT hardware watchdog)
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
Fix ASCII art in Documentation/networking/switchdev.txt:
Change non-ASCII "spaces" to ASCII spaces.
Change 2 erroneous '+' characters in ASCII art to '-' (at the '*'
characters below):
line 32:
+--+----+----+----+-*--+----+---+ +-----+-----+
line 41:
+--------------+---*------------+
Signed-off-by: Randy Dunlap <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
this script, edited from Linux Advanced Routing and Traffic Control guide
tc q a dev en0 root handle 1: htb default a
tc c a dev en0 parent 1: classid 1:1 htb rate 6mbit burst 15k
tc c a dev en0 parent 1:1 classid 1:a htb rate 5mbit ceil 6mbit burst 15k
tc c a dev en0 parent 1:1 classid 1:b htb rate 1mbit ceil 6mbit burst 15k
tc f a dev en0 parent 1:0 prio 1 $clsname $clsargs classid 1:b
ping $address -c1
tc -s c s dev en0
classifies traffic to 1:b or 1:a, depending on whether the packet matches
or not the pattern $clsargs of filter $clsname. However, when $clsname is
'matchall', a systematic crash can be observed in htb_classify(). HTB and
classful qdiscs don't assign initial value to struct tcf_result, but then
they expect it to contain valid values after filters have been run. Thus,
current 'matchall' ignores the TCA_MATCHALL_CLASSID attribute, configured
by user, and makes HTB (and classful qdiscs) dereference random pointers.
By assigning head->res to *res in mall_classify(), before the actions are
invoked, we fix this crash and enable TCA_MATCHALL_CLASSID functionality,
that had no effect on 'matchall' classifier since its first introduction.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1460213
Reported-by: Jiri Benc <[email protected]>
Fixes: b87f7936a932 ("net/sched: introduce Match-all classifier")
Signed-off-by: Davide Caratti <[email protected]>
Acked-by: Yotam Gigi <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
If ipv6 has been disabled from cmdline since kernel started, it makes
no sense to allow users to create any ip6 tunnel. Otherwise, it could
some potential problem.
Jianlin found a kernel crash caused by this in ip6_gre when he set
ipv6.disable=1 in grub:
[ 209.588865] Unable to handle kernel paging request for data at address 0x00000080
[ 209.588872] Faulting instruction address: 0xc000000000a3aa6c
[ 209.588879] Oops: Kernel access of bad area, sig: 11 [#1]
[ 209.589062] NIP [c000000000a3aa6c] fib_rules_lookup+0x4c/0x260
[ 209.589071] LR [c000000000b9ad90] fib6_rule_lookup+0x50/0xb0
[ 209.589076] Call Trace:
[ 209.589097] fib6_rule_lookup+0x50/0xb0
[ 209.589106] rt6_lookup+0xc4/0x110
[ 209.589116] ip6gre_tnl_link_config+0x214/0x2f0 [ip6_gre]
[ 209.589125] ip6gre_newlink+0x138/0x3a0 [ip6_gre]
[ 209.589134] rtnl_newlink+0x798/0xb80
[ 209.589142] rtnetlink_rcv_msg+0xec/0x390
[ 209.589151] netlink_rcv_skb+0x138/0x150
[ 209.589159] rtnetlink_rcv+0x48/0x70
[ 209.589169] netlink_unicast+0x538/0x640
[ 209.589175] netlink_sendmsg+0x40c/0x480
[ 209.589184] ___sys_sendmsg+0x384/0x4e0
[ 209.589194] SyS_sendmsg+0xd4/0x140
[ 209.589201] SyS_socketcall+0x3e0/0x4f0
[ 209.589209] system_call+0x38/0xe0
This patch is to return -EOPNOTSUPP in ip6_tunnel_init if ipv6 has been
disabled from cmdline.
Reported-by: Jianlin Shi <[email protected]>
Signed-off-by: Xin Long <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
To clear Speed Selection in MDIO control register(0x10),
ie, clear bits 6 and 13 to zero while keeping other bits same.
Before AND operation,The Mask value has to be perform with bitwise NOT
operation (ie, ~ operator)
This patch clears current speed selection before writing the
new speed settings to gmii2rgmii converter
Fixes: f411a6160bd4 ("net: phy: Add gmiitorgmii converter support")
Signed-off-by: Fahad Kunnathadi <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Commit 1bf6ad622b9b ("drm/vblank: drop the mode argument from
drm_calc_vbltimestamp_from_scanoutpos") removed the use of in_vbl, but
did not remove the local variable. Do so now.
Fixes: 1bf6ad622b9b ("drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Ville Syrjälä <[email protected]>
(cherry picked from commit e01e71fc49d4c95090a04f898a3fe788c652a04b)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Min brightness value from vbt was missing for CNP platform.
This setting have to refer backlight ic spec to restrict
min backlight output. Without this restriction, driver would
allow to configure lower brightness value and violate
backlight ic requirement.
Fixes: 4c9f7086ac6d ("drm/i915/cnp: Backlight support for CNP.")
Cc: Jani Nikula <[email protected]>
Signed-off-by: Shawn Lee <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit f44e354f857f207cd361269c5e38e1f96e0b616c)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This reverts commit bbdf0b2ff32a ("drm/i915/bxt: Disable device ready
before shutdown command").
Disable device ready before shutdown command was added previously to
avoid a split screen issue seen on dual link DSI panels. As of now, dual
link is not supported and will need some rework in the upstream
code. For single link DSI panels, the change is not required. This will
cause failure in sending SHUTDOWN packet during disable. Hence reverting
the change. Will handle the change as part of dual link enabling in
upstream.
Fixes: bbdf0b2ff32a ("drm/i915/bxt: Disable device ready before shutdown command")
Cc: <[email protected]> # v4.12+
Signed-off-by: Uma Shankar <[email protected]>
Signed-off-by: Vidya Srinivas <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 33c8d8870c67faf3161898a56af98ac3c1c71450)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Min brightness value from vbt was missing for BXT platform.
This setting have to refer backlight ic spec to restrict
min backlight output. Without this restriction, driver would
allow to configure lower brightness value and violate
backlight ic requirement.
Fixes: 0fb890c01349 ("drm/i915/bxt: BLC implementation")
Cc: Jani Nikula <[email protected]>
Cc: Cooper Chiou <[email protected]>
Cc: Gary C Wang <[email protected]>
Signed-off-by: Shawn Lee <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit c3881128cb672cf484a52fbb36b5daa9044d9168)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
We should go through the error handling path to decrease the
'framebuffer_references' as done everywhere else in this function.
Fixes: 2e2adb05736c ("drm/i915: Add render decompression support")
Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 37875d6b3af702425ce292de81b77faf94766616)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Looking at our virtual PCI device, we can see surprising Region 4 and Region 5.
00:10.0 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 06) (prog-if 00 [VGA controller])
....
Region 0: Memory at 140000000 (64-bit, non-prefetchable) [size=16M]
Region 2: Memory at 180000000 (64-bit, prefetchable) [size=1G]
Region 4: Memory at <ignored> (32-bit, non-prefetchable)
Region 5: Memory at <ignored> (32-bit, non-prefetchable)
Expansion ROM at febd6000 [disabled] [size=2K]
The fact is that we only implemented BAR0 and BAR2. Surprising Region 4 and
Region 5 are shown because we report their size as 0xffffffff. They should
report size 0 instead.
BTW, the physical GPU has a PIO BAR. GVTg hasn't implemented PIO access, so
we ignored this BAR for vGPU device.
v2: fix BAR size value calculation.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458032
Signed-off-by: Changbin Du <[email protected]>
Cc: [email protected]
Signed-off-by: Zhenyu Wang <[email protected]>
(cherry picked from commit f1751362d6357a90bc6e53176cec715ff2dbed74)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Now in ip6gre_header before packing the ipv6 header, it skb_push t->hlen
which only includes encap_hlen + tun_hlen. It means greh and inner header
would be over written by ipv6 stuff and ipv6h might have no chance to set
up.
Jianlin found this issue when using remote any on ip6_gre, the packets he
captured on gre dev are truncated:
22:50:26.210866 Out ethertype IPv6 (0x86dd), length 120: truncated-ip6 -\
8128 bytes missing!(flowlabel 0x92f40, hlim 0, next-header Options (0) \
payload length: 8192) ::1:2000:0 > ::1:0:86dd: HBH [trunc] ip-proto-128 \
8184
It should also skb_push ipv6hdr so that ipv6h points to the right position
to set ipv6 stuff up.
This patch is to skb_push hlen + sizeof(*ipv6h) and also fix some indents
in ip6gre_header.
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Reported-by: Jianlin Shi <[email protected]>
Signed-off-by: Xin Long <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
If TX rates are specified during mesh join, the channel must
also be specified. Check the channel pointer to avoid a null
pointer dereference if it isn't.
Reported-by: Jouni Malinen <[email protected]>
Fixes: 8564e38206de ("cfg80211: add checks for beacon rate, extend to mesh")
Signed-off-by: Johannes Berg <[email protected]>
|
|
include/linux/fs.h and include/uapi/linux/fs.h deal with much more than
just file locking. Move them to the "FILESYSTEMS (VFS and
infrastructure)" section of the MAINTAINERS file so that the first
suggestion from get_maintainer.pl isn't the file locking maintainers,
which has caused some confusion.
Cc: J. Bruce Fields <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>
Acked-by: Jeff Layton <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
|
|
While trying an ESP transport mode encryption for UDPv6 packets of
datagram size 1436 with MTU 1500, checksum error was observed in
the secondary fragment.
This error occurs due to the UDP payload checksum being missed out
when computing the full checksum for these packets in
udp6_hwcsum_outgoing().
Fixes: d39d938c8228 ("ipv6: Introduce udpv6_send_skb()")
Signed-off-by: Subash Abhinov Kasiviswanathan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The multiple_kprobes test case fails to check for KPROBE_EVENT support.
Add the check to prevent a false test result.
Signed-off-by: Thomas Meyer <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
Acked-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|