Age | Commit message (Collapse) | Author | Files | Lines |
|
If we ignore the error we'll hit a null dereference a little later.
Reported-by: [email protected]
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
As gte_current_cred() cannot return an error,
this test is not necessary.
It hasn't been necessary for years, but it wasn't so obvious
before.
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
If a reply has been processed but the RPC is later retransmitted
anyway, the req->rl_reply field still contains the only pointer to
the old rpcrdma rep. When the next reply comes in, the reply handler
will stomp on the rl_reply field, leaking the old rep.
A trace event is added to capture such leaks.
This problem seems to be worsened by the restructuring of the RPC
Call path in v4.20. Fully addressing this issue will require at
least a re-architecture of the disconnect logic, which is not
appropriate during -rc.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Original commit (e4648aa4f98a "NFS recover from destination server
reboot for copies") used memcmp() and then it was changed to use
nfs4_stateid_match_other() but that function returns opposite of
memcmp. As the result, recovery can't find the copy leading
to copy hanging.
Fixes: 80f42368868e ("NFSv4: Split out NFS v4.2 copy completion functions")
Fixes: cb7a8384dc02 ("NFS: Split out the body of nfs4_reclaim_open_state")
Signed-of-by: Olga Kornievskaia <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Defensive clean up. Don't set frwr->fr_mr until we know that the
scatterlist allocation has succeeded.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Make a note of the function's dependency on an earlier ib_drain_qp.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Since commit 7c8d9e7c8863 ("xprtrdma: Move Receive posting to
Receive handler"), rpcrdma_ep_post is no longer responsible for
posting Receive buffers. Update the documenting comment to reflect
this change.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Commit f2877623082b ("xprtrdma: Chain Send to FastReg WRs") was
written before commit ce5b37178283 ("xprtrdma: Replace all usage of
"frmr" with "frwr""), but was merged afterwards. Thus it still
refers to FRMR and MWs.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Clean up some warnings observed when building with "make W=1".
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Clean up, no functional change is expected.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
These symbolic values were not being displayed in string form.
TRACE_DEFINE_ENUM was missing in many cases. It also turns out that
__print_symbolic wants an unsigned long in the first field...
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
These are rare, but can be helpful at tracking down DMAR and other
problems.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Name them "trace_xprtrdma_op_*" so they can be easily enabled as a
group. No trace point is added where the generic layer already has
observability.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
The mr_map trace points were capturing information about the previous
use of the MR rather than about the segment that was just mapped.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
The chunk-related trace points capture nearly the same information
as the MR-related trace points.
Also, rename them so globbing can be used to enable or disable
these trace points more easily.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Clean up. The last use of these fields was in commit 173b8f49b3af
("xprtrdma: Demote "connect" log messages") .
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Clean up: Remove dprintk() call sites that report rare or impossible
errors. Leave a few that display high-value low noise status
information.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Clean up: There's little chance of contention between the use of
rb_lock and rb_reqslock, so merge the two. This avoids having to
take both in some (possibly future) cases.
Transport tear-down is already serialized, thus there is no need for
locking at all when destroying rpcrdma_reqs.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
For better observability of parsing errors, return the error code
generated in the decoders to the upper layer consumer.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Since commit ffe1f0df5862 ("rpcrdma: Merge svcrdma and xprtrdma
modules into one"), the forward and backchannel components are part
of the same kernel module. A separate request_module() call in the
backchannel code is no longer necessary.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Commit 431f6eb3570f ("SUNRPC: Add a label for RPC calls that require
allocation on receive") didn't update similar logic in rpc_rdma.c.
I don't think this is a bug, per-se; the commit just adds more
careful checking for broken upper layer behavior.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Having to specify "proto=rdma,port=20049" is cumbersome.
RFC 8267 Section 6.3 requires NFSv4 clients to use "the alternative
well-known port number", which is 20049. Make the use of the well-
known port number automatic, just as it is for NFS/TCP and port
2049.
For NFSv2/3, Section 4.2 allows clients to simply choose 20049 as
the default or use rpcbind. I don't know of an NFS/RDMA server
implementation that registers it's NFS/RDMA service with rpcbind,
so automatically choosing 20049 seems like the better choice. The
other widely-deployed NFS/RDMA client, Solaris, also uses 20049
as the default port.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Place the associated RPC transaction's XID in the upper 32 bits of
each RDMA segment's rdma_offset field. There are two reasons to do
this:
- The R_key only has 8 bits that are different from registration to
registration. The XID adds more uniqueness to each RDMA segment to
reduce the likelihood of a software bug on the server reading from
or writing into memory it's not supposed to.
- On-the-wire RDMA Read and Write requests do not otherwise carry
any identifier that matches them up to an RPC. The XID in the
upper 32 bits will act as an eye-catcher in network captures.
Suggested-by: Tom Talpey <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Clean up: Now that there is only FRWR, there is no need for a memory
registration switch. The indirect calls to the memreg operations can
be replaced with faster direct calls.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
FMR is not supported on most recent RDMA devices. It is also less
secure than FRWR because an FMR memory registration can expose
adjacent bytes to remote reading or writing. As discussed during the
RDMA BoF at LPC 2018, it is time to remove support for FMR in the
NFS/RDMA client stack.
Note that NFS/RDMA server-side uses either local memory registration
or FRWR. FMR is not used.
There are a few Infiniband/RoCE devices in the kernel tree that do
not appear to support MEM_MGT_EXTENSIONS (FRWR), and therefore will
not support client-side NFS/RDMA after this patch. These are:
- mthca
- qib
- hns (RoCE)
Users of these devices can use NFS/TCP on IPoIB instead.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Some devices advertise a large max_fast_reg_page_list_len
capability, but perform optimally when MRs are significantly smaller
than that depth -- probably when the MR itself is no larger than a
page.
By default, the RDMA R/W core API uses max_sge_rd as the maximum
page depth for MRs. For some devices, the value of max_sge_rd is
1, which is also not optimal. Thus, when max_sge_rd is larger than
1, use that value. Otherwise use the value of the
max_fast_reg_page_list_len attribute.
I've tested this with CX-3 Pro, FastLinq, and CX-5 devices. It
reproducibly improves the throughput of large I/Os by several
percent.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
With certain combinations of krb5i/p, MR size, and r/wsize, I/O can
fail with EMSGSIZE. This is because the calculated value of
ri_max_segs (the max number of MRs per RPC) exceeded
RPCRDMA_MAX_HDR_SEGS, which caused Read or Write list encoding to
walk off the end of the transport header.
Once that was addressed, the ro_maxpages result has to be corrected
to account for the number of MRs needed for Reply chunks, which is
2 MRs smaller than a normal Read or Write chunk.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Transport disconnect processing does a "wake pending tasks" at
various points.
Suppose an RPC Reply is being processed. The RPC task that Reply
goes with is waiting on the pending queue. If a disconnect wake-up
happens before reply processing is done, that reply, even if it is
good, is thrown away, and the RPC has to be sent again.
This window apparently does not exist for socket transports because
there is a lock held while a reply is being received which prevents
the wake-up call until after reply processing is done.
To resolve this, all RPC replies being processed on an RPC-over-RDMA
transport have to complete before pending tasks are awoken due to a
transport disconnect.
Callers that already hold the transport write lock may invoke
->ops->close directly. Others use a generic helper that schedules
a close when the write lock can be taken safely.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
After thinking about this more, and auditing other kernel ULP imple-
mentations, I believe that a DISCONNECT cm_event will occur after a
fatal QP event. If that's the case, there's no need for an explicit
disconnect in the QP event handler.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
To address a connection-close ordering problem, we need the ability
to drain the RPC completions running on rpcrdma_receive_wq for just
one transport. Give each transport its own RPC completion workqueue,
and drain that workqueue when disconnecting the transport.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
Clean up: Divide the work cleanly:
- rpcrdma_wc_receive is responsible only for RDMA Receives
- rpcrdma_reply_handler is responsible only for RPC Replies
- the posted send and receive counts both belong in rpcrdma_ep
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
The recovery case in frwr_op_unmap_sync needs to DMA unmap each MR.
frwr_release_mr does not DMA-unmap, but the recycle worker does.
Fixes: 61da886bf74e ("xprtrdma: Explicitly resetting MRs is ... ")
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
While chasing yet another set of DMAR fault reports, I noticed that
the frwr recycler conflates whether or not an MR has been DMA
unmapped with frwr->fr_state. Actually the two have only an indirect
relationship. It's in fact impossible to guess reliably whether the
MR has been DMA unmapped based on its fr_state field, especially as
the surrounding code and its assumptions have changed over time.
A better approach is to track the DMA mapping status explicitly so
that the recycler is less brittle to unexpected situations, and
attempts to DMA-unmap a second time are prevented.
Signed-off-by: Chuck Lever <[email protected]>
Cc: [email protected] # v4.20
Signed-off-by: Anna Schumaker <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull IOMMU updates from Joerg Roedel:
- Page table code for AMD IOMMU now supports large pages where smaller
page-sizes were mapped before. VFIO had to work around that in the
past and I included a patch to remove it (acked by Alex Williamson)
- Patches to unmodularize a couple of IOMMU drivers that would never
work as modules anyway.
- Work to unify the the iommu-related pointers in 'struct device' into
one pointer. This work is not finished yet, but will probably be in
the next cycle.
- NUMA aware allocation in iommu-dma code
- Support for r8a774a1 and r8a774c0 in the Renesas IOMMU driver
- Scalable mode support for the Intel VT-d driver
- PM runtime improvements for the ARM-SMMU driver
- Support for the QCOM-SMMUv2 IOMMU hardware from Qualcom
- Various smaller fixes and improvements
* tag 'iommu-updates-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (78 commits)
iommu: Check for iommu_ops == NULL in iommu_probe_device()
ACPI/IORT: Don't call iommu_ops->add_device directly
iommu/of: Don't call iommu_ops->add_device directly
iommu: Consolitate ->add/remove_device() calls
iommu/sysfs: Rename iommu_release_device()
dmaengine: sh: rcar-dmac: Use device_iommu_mapped()
xhci: Use device_iommu_mapped()
powerpc/iommu: Use device_iommu_mapped()
ACPI/IORT: Use device_iommu_mapped()
iommu/of: Use device_iommu_mapped()
driver core: Introduce device_iommu_mapped() function
iommu/tegra: Use helper functions to access dev->iommu_fwspec
iommu/qcom: Use helper functions to access dev->iommu_fwspec
iommu/of: Use helper functions to access dev->iommu_fwspec
iommu/mediatek: Use helper functions to access dev->iommu_fwspec
iommu/ipmmu-vmsa: Use helper functions to access dev->iommu_fwspec
iommu/dma: Use helper functions to access dev->iommu_fwspec
iommu/arm-smmu: Use helper functions to access dev->iommu_fwspec
ACPI/IORT: Use helper functions to access dev->iommu_fwspec
iommu: Introduce wrappers around dev->iommu_fwspec
...
|
|
Pull dmaengine updates from Vinod Koul:
"This includes a new driver, removes R-Mobile APE6 as it is no longer
used, sprd cyclic dma support, last batch of dma_slave_config
direction removal and random updates to bunch of drivers.
Summary:
- New driver for UniPhier MIO DMA controller
- Remove R-Mobile APE6 support
- Sprd driver updates and support for cyclic link-list
- Remove dma_slave_config direction usage from rest of drivers
- Minor updates to dmatest, dw-dmac, zynqmp and bcm dma drivers"
* tag 'dmaengine-4.21-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (48 commits)
dmaengine: qcom_hidma: convert to DEFINE_SHOW_ATTRIBUTE
dmaengine: pxa: remove DBGFS_FUNC_DECL()
dmaengine: mic_x100_dma: convert to DEFINE_SHOW_ATTRIBUTE
dmaengine: amba-pl08x: convert to DEFINE_SHOW_ATTRIBUTE
dmaengine: Documentation: Add documentation for multi chan testing
dmaengine: dmatest: Add transfer_size parameter
dmaengine: dmatest: Add alignment parameter
dmaengine: dmatest: Use fixed point div to calculate iops
dmaengine: dmatest: Add support for multi channel testing
dmaengine: rcar-dmac: Document R8A774C0 bindings
dt-bindings: dmaengine: usb-dmac: Add binding for r8a774c0
dmaengine: zynqmp_dma: replace spin_lock_bh with spin_lock_irqsave
dmaengine: sprd: Add me as one of the module authors
dmaengine: sprd: Support DMA 2-stage transfer mode
dmaengine: sprd: Support DMA link-list cyclic callback
dmaengine: sprd: Set cur_desc as NULL when free or terminate one dma channel
dmaengine: sprd: Fix the last link-list configuration
dmaengine: sprd: Get transfer residue depending on the transfer direction
dmaengine: sprd: Remove direction usage from struct dma_slave_config
dmaengine: dmatest: fix a small memory leak in dmatest_func()
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux
Pull kgdb updates from Daniel Thompson:
"Mostly clean ups although while Doug's was chasing down a odd lockdep
warning he also did some work to improved debugger resilience when
some CPUs fail to respond to the round up request.
The main changes are:
- Fixing a lockdep warning on architectures that cannot use an NMI
for the round up plus related changes to make CPU round up and all
CPU backtrace more resilient.
- Constify the arch ops tables
- A couple of other small clean ups
Two of the three patchsets here include changes that spill over into
arch/. Changes in the arch space are relatively narrow in scope (and
directly related to kgdb). Didn't get comprehensive acks but all
impacted maintainers were Cc:ed in good time"
* tag 'kgdb-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux:
kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops
mips/kgdb: prepare arch_kgdb_ops for constness
kdb: use bool for binary state indicators
kdb: Don't back trace on a cpu that didn't round up
kgdb: Don't round up a CPU that failed rounding up before
kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
kgdb: Remove irq flags from roundup
|
|
Pull OpenRISC update from Stafford Horne:
"Just one change for 4.21: Update comments for name change or32 -> or1k
from Geert Uytterhoeven"
* tag 'for-linus' of git://github.com/openrisc/linux:
openrisc: Fix broken paths to arch/or32
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"Subsystem:
- new %ptR printk format
- rename core files
- allow registration of multiple nvmem devices
New driver:
- i.MX system controller RTC
Driver updates:
- abx80x: handle voltage ioctls, correct binding doc
- m41t80: correct month in alarm reads
- pcf85363: add pcf85263 support
- pcf8523: properly handle battery low flag
- s3c: limit alarm to one year in the future as ALMYEAR is broken
- sun6i: rework clock output binding"
* tag 'rtc-4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (54 commits)
rtc: rename core files
rtc: nvmem: fix possible use after free
rtc: add i.MX system controller RTC support
dt-bindings: fsl: scu: add rtc binding
rtc: pcf2123: Add Microcrystal rv2123
rtc: class: reimplement devm_rtc_device_register
rtc: enforce rtc_timer_init private_data type
rtc: abx80x: Implement RTC_VL_READ,CLR ioctls
rtc: pcf85363: Add support for NXP pcf85263 rtc
dt-bindings: rtc: pcf85363: Document pcf85263 real-time clock
rtc: pcf8523: don't return invalid date when battery is low
dt-bindings: rtc: use a generic node name for ds1307
PM: Switch to use %ptR
m68k/mac: Switch to use %ptR
Input: hp_sdc_rtc - Switch to use %ptR
rtc: tegra: Switch to use %ptR
rtc: s5m: Switch to use %ptR
rtc: s3c: Switch to use %ptR
rtc: rx8025: Switch to use %ptR
rtc: rx6110: Switch to use %ptR
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control updates from Linus Walleij:
"We have no core changes but lots of incremental development in drivers
all over the place: Renesas, NXP, Mediatek and Actions Semiconductor
keep churning out new SoCs.
I have some subtree maintainers for Renesas and Intel helping out to
keep down the load, it's been working smoothly (Samsung also have a
subtree but it was not used this cycle.)
New drivers:
- NXP (ex Freescale) i.MX 8 QXP SoC driver.
- Mediatek MT6797 SoC driver.
- Mediatek MT7629 SoC driver.
- Actions Semiconductor S700 SoC driver.
- Renesas RZ/A2 SoC driver.
- Allwinner sunxi suniv F1C100 SoC driver.
- Qualcomm PMS405 PMIC driver.
- Microsemi Ocelot Jaguar2 SoC driver.
Improvements:
- Some RT improvements (using raw spinlocks where appropriate).
- A lot of new pin sets on the Renesas PFC pin controllers.
- GPIO hogs now work on the Qualcomm SPMI/SSBI pin controller GPIO
chips, and Xway.
- Major modernization of the Intel pin control drivers.
- STM32 pin control driver will now synchronize usage of pins with
another CPU using a hardware spinlock"
* tag 'pinctrl-v4.21-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (145 commits)
dt-bindings: arm: fsl-scu: add imx8qm pinctrl support
pinctrl: freescale: Break dependency on SOC_IMX8MQ for i.MX8MQ
pinctrl: imx-scu: Depend on IMX_SCU
pinctrl: ocelot: Add dependency on HAS_IOMEM
pinctrl: ocelot: add MSCC Jaguar2 support
pinctrl: bcm: ns: support updated DT binding as syscon subnode
dt-bindings: pinctrl: bcm4708-pinmux: rework binding to use syscon
MAINTAINERS: merge at91 pinctrl entries
pinctrl: imx8qxp: break the dependency on SOC_IMX8QXP
pinctrl: uniphier: constify uniphier_pinctrl_socdata
pinctrl: mediatek: improve Kconfig dependencies
pinctrl: msm: mark PM functions as __maybe_unused
dt-bindings: pinctrl: sunxi: Add supply properties
pinctrl: meson: meson8b: add the missing GPIO_GROUPs for BOOT and CARD
pinctrl: meson: meson8: add the missing GPIO_GROUPs for BOOT and CARD
pinctrl: meson: meson8: rename the "gpio" function to "gpio_periphs"
pinctrl: meson: meson8: rename the "gpio" function to "gpio_periphs"
pinctrl: meson: meson8b: fix the GPIO function for the GPIOAO pins
pinctrl: meson: meson8: fix the GPIO function for the GPIOAO pins
pinctrl: sh-pfc: Make pinmux_cfg_reg.var_field_width[] variable-length
...
|
|
git://www.linux-watchdog.org/linux-watchdog
Pull watchdog updates from Wim Van Sebroeck:
- add TQ-Systems TQMX86 watchdog driver
- add Qualcomm PM8916 watchdog driver
- w83627hf_wdt: add quirk for Inves system
- renesas_wdt: several improvements and document r8a774c0 support
- mena21_wdt, mtx-1: Convert to use GPIO descriptor
- bcm281xx, ie6xx_wdt: convert to DEFINE_SHOW_ATTRIBUTE
- documentation: add PM usage and kernel-api: don't reference removed functions
- update bindings for MT7629 SoC
- several small fixes
* tag 'linux-watchdog-4.21-rc1' of git://www.linux-watchdog.org/linux-watchdog: (22 commits)
watchdog: tqmx86: Add watchdog driver for the IO controller
dt-bindings: watchdog: renesas-wdt: Document r8a774c0 support
watchdog: docs: kernel-api: don't reference removed functions
watchdog: add documentation for PM usage
watchdog: mtx-1: Convert to use GPIO descriptor
watchdog: mena21_wdt: Convert to GPIO descriptors
dt-bindings: watchdog: Add Qualcomm PM8916 watchdog
watchdog: Add pm8916 watchdog driver
dt-bindings: watchdog: update bindings for MT7629 SoC
watchdog: renesas_wdt: don't keep timer value during suspend/resume
watchdog: ie6xx_wdt: convert to DEFINE_SHOW_ATTRIBUTE
watchdog: bcm281xx: convert to DEFINE_SHOW_ATTRIBUTE
watchdog: asm9260_wdt: make array mode_name static, shrinks object size
watchdog/hpwdt: Update driver version.
watchdog/hpwdt: Do not claim unsupported hardware
watchdog/hpwdt: Exclude via blacklist
Watchdog: remove outdated comment
watchdog: w83627hf_wdt: Add quirk for Inves system
watchdog: cpwd: add of_node_put()
watchdog: renesas_wdt: don't set divider while watchdog is running
...
|
|
We need to check the return value of match_token() for Opt_err before
doing anything with it.
[ Not only did the old "-1" value for Opt_err cause problems for the
__test_and_set_bit(), as fixed in commit 94c13f66e13c ("security:
don't use a negative Opt_err token index"), but accessing
"args[0].from" is invalid for the Opt_err case, as pointed out by Eric
later. - Linus ]
Reported-by: [email protected]
Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
Signed-off-by: Eric Biggers <[email protected]>
Cc: [email protected] # 4.20
Signed-off-by: Linus Torvalds <[email protected]>
|
|
For HNAE3_DOWN_CLIENT calling hns3_nic_net_stop(), HNAE3_UP_CLIENT
should call hns3_nic_net_open(), since if the number of queue or
the map of TC has is changed before HHAE3_UP_CLIENT is called,
it will cause problem.
Also the HNS3_NIC_STATE_RESETTING flag needs to be cleared before
hns3_nic_net_open() called, and set it back while hns3_nic_net_open()
failed.
Fixes: bb6b94a896d4 ("net: hns3: Add reset interface implementation in client")
Signed-off-by: Huazhong Tan <[email protected]>
Signed-off-by: Yunsheng Lin <[email protected]>
Signed-off-by: Peng Li <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
KMSAN detected read beyond end of buffer in vti and sit devices when
passing truncated packets with PF_PACKET. The issue affects additional
ip tunnel devices.
Extend commit 76c0ddd8c3a6 ("ip6_tunnel: be careful when accessing the
inner header") and commit ccfec9e5cb2d ("ip_tunnel: be careful when
accessing the inner header").
Move the check to a separate helper and call at the start of each
ndo_start_xmit function in net/ipv4 and net/ipv6.
Minor changes:
- convert dev_kfree_skb to kfree_skb on error path,
as dev_kfree_skb calls consume_skb which is not for error paths.
- use pskb_network_may_pull even though that is pedantic here,
as the same as pskb_may_pull for devices without llheaders.
- do not cache ipv6 hdrs if used only once
(unsafe across pskb_may_pull, was more relevant to earlier patch)
Reported-by: syzbot <[email protected]>
Signed-off-by: Willem de Bruijn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The BPF flow dissector expects either skb->sk or skb->dev set on
all skbs. Delay flow dissection until after skb->dev is set.
This requires calling from within an rcu read-side critical section.
That is fine, see also the call from tun_xdp_one.
Fixes: d0e13a1488ad ("flow_dissector: lookup netns by skb->sk if skb->dev is NULL")
Reported-by: Christian Borntraeger <[email protected]>
Signed-off-by: Willem de Bruijn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
__ptr_ring_swap_queue() tries to move pointers from the old
ring to the new one, but it forgets to check if ->producer
is beyond the new size at the end of the operation. This leads
to an out-of-bound access in __ptr_ring_produce() as reported
by syzbot.
Reported-by: [email protected]
Fixes: 5d49de532002 ("ptr_ring: resize support")
Cc: "Michael S. Tsirkin" <[email protected]>
Cc: John Fastabend <[email protected]>
Cc: Jason Wang <[email protected]>
Signed-off-by: Cong Wang <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This essentially reverts the commits
c337104b1a16 ("ALSA: HD-Audio: SKL+: abort probe if DSP is present
and Skylake driver selected")
and
d82b51c855a2 ("ALSA: HD-Audio: SKL+: force HDaudio legacy or SKL+
driver selection")
for the path of legacy HD-audio controller (snd-hda-intel).
The automatic DSP detection and skip of binding with the legacy driver
caused regressions on several machines like Dell XPS13. They give the
PCI class 0x40380 indicating the availability of DSP while they don't
work with ASoC SKL driver (yet).
As the support of ASoC driver for such devices isn't available, it's
better to revert the whole DSP-detection-and-skip behavior of the
legacy driver, so that we can get the old good driver working on such
devices.
The pci_binding option for ASoC SKL driver is still kept so that it
can work without blacklisting.
Fixes: c337104b1a16 ("ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver selected")
Reported-by: Linus Torvalds <[email protected]>
Reported-by: Hans de Goede <[email protected]>
Reported-by: Azat Khuzhin <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
In kfree, the NULL check is done.
Signed-off-by: Zhu Yanjun <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
add document and examples for below counters:
TcpExtTCPOFOQueue
TcpExtTCPOFODrop
TcpExtTCPOFOMerge
TcpExtPAWSActive
TcpExtPAWSEstab
TcpExtTCPACKSkippedSynRecv
TcpExtTCPACKSkippedPAWS
TcpExtTCPACKSkippedSeq
TcpExtTCPACKSkippedFinWait2
TcpExtTCPACKSkippedTimeWait
TcpExtTCPACKSkippedChallenge
Signed-off-by: yupeng <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Al Viro mentioned (Message-ID
<[email protected]>)
that there is probably a race condition
lurking in accesses of sk_stamp on 32-bit machines.
sock->sk_stamp is of type ktime_t which is always an s64.
On a 32 bit architecture, we might run into situations of
unsafe access as the access to the field becomes non atomic.
Use seqlocks for synchronization.
This allows us to avoid using spinlocks for readers as
readers do not need mutual exclusion.
Another approach to solve this is to require sk_lock for all
modifications of the timestamps. The current approach allows
for timestamps to have their own lock: sk_stamp_lock.
This allows for the patch to not compete with already
existing critical sections, and side effects are limited
to the paths in the patch.
The addition of the new field maintains the data locality
optimizations from
commit 9115e8cd2a0c ("net: reorganize struct sock for better data
locality")
Note that all the instances of the sk_stamp accesses
are either through the ioctl or the syscall recvmsg.
Signed-off-by: Deepa Dinamani <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
As a simple fix, just print the correct map type.
Signed-off-by: Xiaozhou Liu <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
|