Initial xhci_ring allocation has just been amended to assign a
monotonically increasing number to each ring segment.
However rings may be expanded after initial allocation.
So number newly inserted segments starting from the preceding segment in
the ring and renumber all segments succeeding the newly inserted ones.
This is not a fix because ring expansion currently isn't done on the
Event Ring and that's the only ring type using the segment number.
It's just in preparation for when either Event Ring expansion is added
or when other ring types start making use of the segment number.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20231019102924.2797346-7-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Users have reported log spam created by "Event Ring Full" xHC event
TRBs. These are caused by interrupt latency in conjunction with a very
busy set of devices on the bus. The errors are benign, but throughput
will suffer as the xHC will pause processing of transfers until the
Event Ring is drained by the kernel.
Commit dc0ffbea57 ("usb: host: xhci: update event ring dequeue pointer
on purpose") mitigated the issue by advancing the Event Ring Dequeue
Pointer already after half a segment has been processed. Nevertheless,
providing a larger Event Ring would be useful to cope with load peaks.
Expand the number of event TRB slots available by increasing the number
of Event Ring segments in the ERST.
Controllers have a hardware-defined limit as to the number of ERST
entries they can process, but with up to 32k it can be excessively high
(sec 5.3.4). So cap the actual number at 2 (configurable through the
ERST_MAX_SEGS macro), which seems like a reasonable quantity. It is
supported by any xHC because the limit in the HCSPARAMS2 register is
defined as a power of 2. Renesas uPD720201 and VIA VL805 controllers
do not support more than 2 ERST entries.
An alternative to increasing the number of Event Ring segments would be
an increase of the segment size. But that requires allocating multiple
contiguous pages, which may be impossible if memory is fragmented.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20231019102924.2797346-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When using more than one Event Ring segment (ERSTSZ > 1), software shall
set the DESI bits in the ERDP register to the number of the segment to
which the upper ERDP bits are pointing. The xHC may use the DESI bits
as a shortcut to determine whether it needs to check for an Event Ring
Full condition: If it's enqueueing events in a different segment, it
need not compare its internal Enqueue Pointer with the Dequeue Pointer
in the upper bits of the ERDP register (sec 5.5.2.3.3).
Not setting the DESI bits correctly can result in the xHC enqueueing
events past the Dequeue Pointer. On Renesas uPD720201 host controllers,
incorrect DESI bits cause an interrupt storm. For comparison, VIA VL805
host controllers do not exhibit such problems. Perhaps they do not take
advantage of the optimization afforded by the DESI bits.
To fix the issue, assign the segment number to each struct xhci_segment
in xhci_segment_alloc(). When advancing the Dequeue Pointer in
xhci_update_erst_dequeue(), write the segment number to the DESI bits.
On driver probe, set the DESI bits to zero in xhci_set_hc_event_deq() as
processing starts in segment 0. Likewise on driver teardown, clear the
DESI bits to zero in xhci_free_interrupter() when clearing the upper
bits of the ERDP register. Previously those functions (incorrectly)
treated the DESI bits as if they're declared RsvdP.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20231019102924.2797346-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The next_trb() helper relies on a link TRB at the end of a ring segment
to know a segment ends. This works well with transfer rings that use
link trbs, but not with event rings.
Event rings segments are always filled by host to segment size
before moving to next segment. It does not use link TRBs
Check for both link trb and full segment in next_trb() helper to
support event rings.
Useful if several interrupters with several event rings are supported.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20231019102924.2797346-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With several xhci controllers active at the same time its hard to
keep track of ports without knowing bus number
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20231019102924.2797346-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We want to trace other port structure members than just port number
so pass entire port structure as parameter instead of just port number.
Dig the port number from the port structure.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20231019102924.2797346-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The fpga core currently assumes that all manager, bridge, and region
devices have a parent device associated with a driver that can be used
to take the module's refcount. This behavior causes the fpga test suites
to crash with a null-ptr-deref since parent fake devices do not have a
driver. This patch disables all fpga KUnit test suites when loadable
module support is enabled until the fpga core is fixed. Test suites
can still be run using the KUnit default UML kernel.
Signed-off-by: Marco Pagani <marpagan@redhat.com>
Acked-by: Xu Yilun <yilun.xu@intel.com>
Fixes: ccbc1c3021 ("fpga: add an initial KUnit suite for the FPGA Manager")
Link: https://lore.kernel.org/r/20231018163814.100803-1-marpagan@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vme_check_window() uses printk() for logging error message. This
leads to the following checkpatch warning:
WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then
dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
Use dev_err() instead. Pass VME bridge device to vme_check_window() so
that the error message can be logged with the bridge device context.
Signed-off-by: Soumya Negi <soumya.negi97@gmail.com>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/221344ede933b1d9e6c31310b0f4dbb8be809c86.1697763267.git.soumya.negi97@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't check for empty bridge device & resource in vme_alloc_consistent()
& vme_free_consistent() since they can not be NULL. Both the VME bridge
device and the VME resource that are used in these functions are set at
probe time.
Signed-off-by: Soumya Negi <soumya.negi97@gmail.com>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/049bbedf458e8ac40f3dfff9c9b25dce89f5b642.1697763267.git.soumya.negi97@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't log error message in find_bridge(). The printk() triggers a
checkpatch warning:
WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then
dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
It can't be replaced by dev_err() & using pr_err() is not helpful as it
doesn't give much context to the user. It is better to remove it.
Signed-off-by: Soumya Negi <soumya.negi97@gmail.com>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/028725ebbc522f73c39f5b1ec4cc2bdbdf588971.1697763267.git.soumya.negi97@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace function names in message strings with __func__ to fix
all checkpatch warnings like:
WARNING: Prefer using '"%s...", __func__' to using 'vme_lm_get',
this function's name, in a string
Signed-off-by: Soumya Negi <soumya.negi97@gmail.com>
Acked-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/db4ad6b878c4bb08fd5d15cf4a9287d7bb8c30df.1697763267.git.soumya.negi97@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vme.c uses printk() to log messages. To improve and standardize message
formatting, use logging mechanisms dev_err()/dev_warn() instead. Retain
the printk log levels of the messages during replacement.
Issue found by checkpatch.pl
Signed-off-by: Soumya Negi <soumya.negi97@gmail.com>
Acked-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/a36a0b839f9c21efe1f2df6f9272ae882fd04fb8.1697763267.git.soumya.negi97@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drops variable ret as it is unused in the code. This therefore modifies
the return type of program_mode_registers() to void from int since the
return value is being ignored in all function calls. This improves code
readability and maintainability.
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dorcas AnonoLitunya <anonolitunya@gmail.com>
Link: https://lore.kernel.org/r/20231019101348.22076-3-anonolitunya@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function snd_bcm2835_new_ctl() is declared but not defined.
Its definition was removed 1 year ago in the
commit 143b67f19b ("staging: bcm2835-audio: remove compat ALSA card")
Signed-off-by: Calvince Otieno <calvncce@gmail.com>
Link: https://lore.kernel.org/r/ZTDap2d5X7eXXPo2@lab-ubuntu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Checkpatch suggests using strscpy() instead of strcpy().
The advantages of strscpy() are that it always adds a NUL terminator
and prevents read/write overflows if the source string is not properly
terminated.
strcpy() lacks built-in bounds checking for the destination buffer,
making it susceptible to buffer overflows. These overflows can lead
to various unpredictable behaviors.
In this specific context, both strscpy and strcpy performs the same
operation without any functional difference.
The reason for this equivalence is that the driver_name string "vme_fake"
is shorter than the size of the fake_bridge->name array which is defined
as 16 characters (struct vme_bridge {char name[VMENAMSIZ];...}). Thus,
there is no risk of buffer overflow in either case. VMENAMSIZ variable
holds a constant value of 16 (#define VMENAMSIZ 16)
The null-terminated "vme_fake" string
(static const char driver_name[] = "vme_fake";) can be safely copied into
fake_bridge->name using either strscpy or strcpy.
While using strscpy() does not address any bugs, it is considered a better
practice and aligns with checkpatch recommendations.
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Calvince Otieno <calvncce@gmail.com>
Link: https://lore.kernel.org/r/ZTDS2H48JBUTiwZi@lab-ubuntu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drop MODULE_ALIAS in favour of MODULE_DEVICE_TABLE as the module
alias should be picked from there.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Link: https://lore.kernel.org/r/20231019090128.430297-4-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drop MODULE_ALIAS in favour of MODULE_DEVICE_TABLE as the module
alias should be dropped from there.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Link: https://lore.kernel.org/r/20231019090128.430297-3-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
VC04 has now a independent bus vchiq_bus to register its devices.
However, the module auto-loading for bcm2835-audio and bcm2835-camera
currently happens through MODULE_ALIAS() macro specified explicitly.
The correct way to auto-load a module, is when the alias is picked
out from MODULE_DEVICE_TABLE(). In order to get there, we need to
introduce vchiq_device_id and add relevant entries in file2alias.c
infrastructure so that aliases can be generated. This patch targets
adding vchiq_device_id and do_vchiq_entry, in order to
generate those alias using the /script/mod/file2alias.c.
Going forward the MODULE_ALIAS() from bcm2835-camera and bcm2835-audio
will be dropped, in favour of MODULE_DEVICE_TABLE being used there.
The alias format for vchiq_bus devices will be "vchiq:<dev_name>".
Adjust the vchiq_bus_uevent() to reflect that.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Link: https://lore.kernel.org/r/20231019090128.430297-2-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As per device_register() documentation, this kfree() on error path will
crash. The call to put_device() is all that is needed here to free the
memory.
Fixes: 027e5703de ("staging: vc04_services: vchiq_arm: Add new bus type and device type")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/20231018055228.825524-1-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
No significant improvements have been done to this driver since commit
a7c3ddf29a ("staging: qlge: clean up debugging code in the QL_ALL_DUMP
ifdef land") in January 2021. The driver should not stay in staging
forever. Since it has been abandoned by the vendor and no one has stepped
up to maintain it, delete it.
If some users manifest themselves, the driver will be restored to
drivers/net/ as suggested in the linked message.
Link: https://lore.kernel.org/netdev/20231019074237.7ef255d7@kernel.org/
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Cc: Manish Chopra <manishc@marvell.com>
Cc: Coiby Xu <coiby.xu@gmail.com>
Signed-off-by: Benjamin Poirier <benjamin.poirier@gmail.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20231020124457.312449-3-benjamin.poirier@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Update TODO file to reflect the changes that have been done:
* multiple functions were renamed to have the "qlge_" prefix in commit
f8c047be54 ("staging: qlge: use qlge_* prefix to avoid namespace
clashes with other qlogic drivers")
* a redundant memset() was removed in commit 953b940093 ("staging: qlge:
Initialize devlink health dump framework")
* the loop boundary in ql(ge)_alloc_rx_buffers() was updated in commit
e4c911a73c ("staging: qlge: Remove rx_ring.type")
* pci_enable_msi() was replaced in commit 4eab532dca ("staging:
qlge/qlge_main.c: Replace depracated MSI API.")
* pci_dma_* were replaced in commit e955a071b9 ("staging: qlge: replace
deprecated apis pci_dma_*")
* the while loops were rewritten in commit 41e1bf811a ("Staging: qlge:
Rewrite two while loops as simple for loops")
* indentation was fixed in commit 0eb79fd1e9 ("staging: qlge: cleanup
indent in qlge_main.c")
I also slipped in one new TODO item, naughty me!
Signed-off-by: Benjamin Poirier <benjamin.poirier@gmail.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20231020124457.312449-2-benjamin.poirier@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is quite a large set of changes but mostly due to API cleanups and
in driver specific ways rather than due to anything subsystem wide.
Highlights include:
- Standardisation of API prefixes on snd_soc_, removing asoc_.
- GPIO API usage improvements.
- Support for HDA patches.
- Lots of work on SOF, including crash dump support.
- Support for AMD platforms with es83xx, Awinc AT87390, many Intel
platforms, many Mediatek platforms, Qualcomm SM6115, Richtek RTQ9128
and Texas Instruments TAS575x.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmUy6X8ACgkQJNaLcl1U
h9Cv7Qf+PO4ucl/rFITWAp2Ta9fw7Z5J6UCiXiR54TPgAiLJrpKSi3rbYTXjO90Y
1NNOdoMKr109zdOpdSZI7EX0GgWQbGbdB40nxESdTcojAloRH0jt4RaF7G7B7+86
b8PGlVPLLV/4zFf9f2gpEKPcKhRRRKYOBIEB+amfjWpdXVrqPD3zS/S16Q3Hn4Gy
Fx9b9X/lVDG9uqJomHpunEdViZjkm5CCNzdyAhHH99afiqSe//pevx6/FpzAHyng
AZgE9Yfq4Xw4pdzDdGVfYC+L1GZiHIDRzsusz6aPA5nrMhSn0ru8PMGtmQQTzyhb
PLYw0OW8cWymfqwal8wrNGJfSZ8IGA==
=lN5P
-----END PGP SIGNATURE-----
Merge tag 'asoc-v6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v6.7
This is quite a large set of changes but mostly due to API cleanups and
in driver specific ways rather than due to anything subsystem wide.
Highlights include:
- Standardisation of API prefixes on snd_soc_, removing asoc_.
- GPIO API usage improvements.
- Support for HDA patches.
- Lots of work on SOF, including crash dump support.
- Support for AMD platforms with es83xx, Awinc AT87390, many Intel
platforms, many Mediatek platforms, Qualcomm SM6115, Richtek RTQ9128
and Texas Instruments TAS575x.
[ the merge conflicts around SOF Intel HD-audio and CS35L41 subcodec
drivers are resolved here -- tiwai ]
When a programming status desc is encountered on the rx_ring,
next_to_process is bumped along with cleaned_count but next_to_clean is
not. This causes I40E_DESC_UNUSED() macro to misbehave resulting in
overwriting whole ring with new buffers.
Update next_to_clean to point to next_to_process on seeing a programming
status desc if not in the middle of handling a multi-frag packet. Also,
bump cleaned_count only for such case as otherwise next_to_clean buffer
may be returned to hardware on reaching clean_threshold.
Fixes: e9031f2da1 ("i40e: introduce next_to_process to i40e_ring")
Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Reported-by: hq.dev+kernel@msdfc.xyz
Reported by: Solomon Peachy <pizza@shaftnet.org>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217678
Tested-by: hq.dev+kernel@msdfc.xyz
Tested by: Indrek Järve <incx@dustbite.net>
Signed-off-by: Tirthendu Sarkar <tirthendu.sarkar@intel.com>
Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/r/20231019203852.3663665-1-jacob.e.keller@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The 'ethtool_convert_link_mode_to_legacy_u32' method does not allow us to
advertise 2500M speed support and TP (twisted pair) properly. Convert to
'ethtool_link_ksettings_test_link_mode' to advertise supported speed and
eliminate ambiguity.
Fixes: 8c5ad0dae9 ("igc: Add ethtool support")
Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Suggested-by: Vitaly Lifshits <vitaly.lifshits@intel.com>
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://lore.kernel.org/r/20231019203641.3661960-1-jacob.e.keller@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect chinfo.name to be NUL-terminated based on its use with format
strings and sprintf:
rpmsg/rpmsg_char.c
165: dev_err(dev, "failed to open %s\n", eptdev->chinfo.name);
368: return sprintf(buf, "%s\n", eptdev->chinfo.name);
... and with strcmp():
| static struct rpmsg_endpoint *qcom_glink_create_ept(struct rpmsg_device *rpdev,
| rpmsg_rx_cb_t cb,
| void *priv,
| struct rpmsg_channel_info
| chinfo)
| ...
| const char *name = chinfo.name;
| ...
| if (!strcmp(channel->name, name))
Since chinfo is initialized as such (just above the strscpy()):
| struct rpmsg_channel_info chinfo = {
| .src = rpwwan->rpdev->src,
| .dst = RPMSG_ADDR_ANY,
| };
... we know other members are zero-initialized. This means no
NUL-padding is required (as any NUL-byte assignments are redundant).
Considering the above, a suitable replacement is `strscpy` due to the
fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20231019-strncpy-drivers-net-wwan-rpmsg_wwan_ctrl-c-v2-1-ecf9b5a39430@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
1) tbl->gc_thresh1, tbl->gc_thresh2, tbl->gc_thresh3 and tbl->gc_interval
can be written from sysfs.
2) tbl->last_flush is read locklessly from neigh_alloc()
3) tbl->proxy_queue.qlen is read locklessly from neightbl_fill_info()
4) neightbl_fill_info() reads cpu stats that can be changed concurrently.
Fixes: c7fb64db00 ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20231019122104.1448310-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Under memory stress conditions, tcp_sendmsg_locked()
might call sk_stream_wait_memory(), thus releasing the socket lock.
If a fresh skb has been allocated prior to this,
we should not leave it in the write queue otherwise
tcp_write_xmit() could panic.
This apparently does not happen often, but a future change
in __sk_mem_raise_allocated() that Shakeel and others are
considering would increase chances of being hurt.
Under discussion is to remove this controversial part:
/* Fail only if socket is _under_ its sndbuf.
* In this case we cannot block, so that we have to fail.
*/
if (sk->sk_wmem_queued + size >= sk->sk_sndbuf) {
/* Force charge with __GFP_NOFAIL */
if (memcg_charge && !charged) {
mem_cgroup_charge_skmem(sk->sk_memcg, amt,
gfp_memcg_charge() | __GFP_NOFAIL);
}
return 1;
}
Fixes: fdfc5c8594 ("tcp: remove empty skb from write queue in error cases")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Link: https://lore.kernel.org/r/20231019112457.1190114-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
check the value of 'ret' after call 'devlink_info_version_stored_put'.
Signed-off-by: Su Hui <suhui@nfschina.com>
Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
Link: https://lore.kernel.org/r/20231019083351.1526484-1-suhui@nfschina.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Inexact, we may reject some not-overflowing values incorrectly, but
they'll be on the order of exabytes allowed anyways.
This fixes divide error crash on x86 if bps_limit is not configured or
is set too high in the rare case that jiffy_elapsed is greater than HZ.
Fixes: e8368b57c0 ("blk-throttle: use calculate_io/bytes_allowed() for throtl_trim_slice()")
Fixes: 8d6bbaada2 ("blk-throttle: prevent overflow while calculating wait time")
Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20231020223617.2739774-1-khazhy@google.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20231009172923.2457844-19-robh@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect ac->name to be NUL-terminated based on its usage with format
strings:
surface_charger.c:
190: ac->psy_desc.name = ac->name;
...
power_supply_core.c:
174: dev_dbg(&psy->dev, "%s: Found supply : %s\n",
175: psy->desc->name, epsy->desc->name);
Moreover, NUL-padding is not required as ac is already zero-allocated
before being passed to spwr_ac_init():
surface_charger.c:
240: ac = devm_kzalloc(&sdev->dev, sizeof(*ac), GFP_KERNEL);
241: if (!ac)
242: return -ENOMEM;
243:
244: spwr_ac_init(ac, sdev, p->registry, p->name);
... this means any future NUL-byte assignments (like the ones that
strncpy() does) are redundant.
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Let's also opt for the more idiomatic strscpy() usage of:
(dest, src, sizeof(dest))
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-surface_charger-c-v1-1-93ddbf668e10@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect bat->name to be NUL-terminated based on its usage with
strcmp():
power_supply_core.c:
445: return strcmp(psy->desc->name, name) == 0;
... and also by the manual `... - 1` for the length argument of the
original strncpy() invocation.
Furthermore, no NUL-padding is needed as bat is zero-allocated before
calling spwr_battery_init():
826: bat = devm_kzalloc(&sdev->dev, sizeof(*bat), GFP_KERNEL);
827: if (!bat)
828: return -ENOMEM;
829:
830: spwr_battery_init(bat, sdev, p->registry, p->name);
... this means any further NUL-byte assignments (like the ones that
strncpy() does) are redundant.
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Let's also opt to use the more idiomatic strscpy() usage of:
(dest, src, sizeof(dest)).
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-surface_battery-c-v2-1-29ed16b2caf1@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect cm->psy_name_buf to be NUL-terminated based on its usage with
format strings:
1522: cm->charger_psy_desc.name = cm->psy_name_buf;
...
1587: dev_err(&pdev->dev, "Cannot register charger-manager with name \"%s\"\n",
1587: cm->charger_psy_desc.name);
Moreover, NUL-padding is not required as `cm` is already zero-allocated
and thus any future NUL-byte assignments (like what strncpy() will do)
are redundant:
1437: cm = devm_kzalloc(&pdev->dev, sizeof(*cm), GFP_KERNEL);
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Let's also opt for the more idiomatic strscpy() usage of:
strscpy(dest, src, sizeof(dest)).
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-charger-manager-c-v1-1-698f73bcad2a@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect bq2515x->model_name to be NUL-terminated based on its usage with
sysfs_emit and format strings:
val->strval is assigned to bq2515x->model_name in
bq2515x_mains_get_property():
| val->strval = bq2515x->model_name;
... then in power_supply_sysfs.c we use value.strval with a format string:
| ret = sysfs_emit(buf, "%s\n", value.strval);
we assigned value.strval via:
| ret = power_supply_get_property(psy, psp, &value);
... which invokes psy->desc->get_property():
| return psy->desc->get_property(psy, psp, val);
with bq2515x_mains_get_property():
| static const struct power_supply_desc bq2515x_mains_desc = {
...
| .get_property = bq2515x_mains_get_property,
Moreover, no NUL-padding is required as bq2515x is zero-allocated in
bq2515x_charger.c:
| bq2515x = devm_kzalloc(dev, sizeof(*bq2515x), GFP_KERNEL);
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Let's also opt to use the more idiomatic strscpy() usage of (dest, src,
sizeof(dest)) as this more closely ties the destination buffer and the
length.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Similar-to: https://lore.kernel.org/all/20231020-strncpy-drivers-power-supply-bq24190_charger-c-v1-1-e896223cb795@google.com/
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-bq2515x_charger-c-v1-1-46664c6edf78@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect bdi->model_name to be NUL-terminated based on its usage with
sysfs_emit and format strings:
val->strval is assigned to bdi->model_name in
bq24190_charger_get_property():
1186 | val->strval = bdi->model_name;
... then in power_supply_sysfs.c we use value.strval with a format string:
311 | ret = sysfs_emit(buf, "%s\n", value.strval);
we assigned value.strval via:
285 | ret = power_supply_get_property(psy, psp, &value);
... which invokes psy->desc->get_property():
1210 | return psy->desc->get_property(psy, psp, val);
with bq24190_charger_get_property():
1320 | static const struct power_supply_desc bq24190_charger_desc = {
...
1325 | .get_property = bq24190_charger_get_property,
Moreover, no NUL-padding is required as bdi is zero-allocated in
bq24190_charger.c:
1798 | bdi = devm_kzalloc(dev, sizeof(*bdi), GFP_KERNEL);
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20231020-strncpy-drivers-power-supply-bq24190_charger-c-v1-1-e896223cb795@google.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
- Fix regression in reading scale and unit files from sysfs for PMU
events, so that we can use that info to pretty print instead of
printing raw numbers:
# perf stat -e power/energy-ram/,power/energy-gpu/ sleep 2
Performance counter stats for 'system wide':
1.64 Joules power/energy-ram/
0.20 Joules power/energy-gpu/
2.001228914 seconds time elapsed
#
# grep -m1 "model name" /proc/cpuinfo
model name : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
#
- The small llvm.cpp file used to check if the llvm devel files are present was
incorrectly deleted when removing the BPF event in 'perf trace', put it back
as it is also used by tools/bpf/bpftool, that uses llvm routines to do
disassembly of BPF object files.
- Fix use of addr_location__exit() in dlfilter__object_code(), making sure that
it is only used to pair a previous addr_location__init() call.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQR2GiIUctdOfX2qHhGyPKLppCJ+JwUCZTKh5AAKCRCyPKLppCJ+
J/g/AP0f6SNyHJz21JzDTzyjXAeSdMzKwic0LXv+kATQy31HJAD+Kf7UKQieUeZB
fxvp60aKyFN8IVIgpYiAjZMS3k9XPAY=
=N7Gv
-----END PGP SIGNATURE-----
Merge tag 'perf-tools-fixes-for-v6.6-2-2023-10-20' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools
Pull perf tools fixes from Arnaldo Carvalho de Melo:
- Fix regression in reading scale and unit files from sysfs for PMU
events, so that we can use that info to pretty print instead of
printing raw numbers:
# perf stat -e power/energy-ram/,power/energy-gpu/ sleep 2
Performance counter stats for 'system wide':
1.64 Joules power/energy-ram/
0.20 Joules power/energy-gpu/
2.001228914 seconds time elapsed
#
# grep -m1 "model name" /proc/cpuinfo
model name : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
#
- The small llvm.cpp file used to check if the llvm devel files are
present was incorrectly deleted when removing the BPF event in 'perf
trace', put it back as it is also used by tools/bpf/bpftool, that
uses llvm routines to do disassembly of BPF object files.
- Fix use of addr_location__exit() in dlfilter__object_code(), making
sure that it is only used to pair a previous addr_location__init()
call.
* tag 'perf-tools-fixes-for-v6.6-2-2023-10-20' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools:
tools build: Fix llvm feature detection, still used by bpftool
perf dlfilter: Add a test for object_code()
perf dlfilter: Fix use of addr_location__exit() in dlfilter__object_code()
perf pmu: Fix perf stat output with correct scale and unit
This Kselftest update for Linux 6.6-rc7 consists of one single fix
to assert check in user_events abi_test to properly check bit value
on Big Endian architectures. The current code treats the bit values
as Little Endian and the check fails on Big Endian.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPZKym/RZuOCGeA/kCwJExA0NQxwFAmUytR4ACgkQCwJExA0N
QxzjoQ/+MWgtyggLZo/dP+qJ7AU+tG08YXWWuh99lkSxVs3xHvwl2EGaYf1PXN9c
ZUXb/KGfls8G4tv20KU2+/uSRSirkf+CFLN6HaBBG+2cun8o0KpHlVKGfmvRjb13
ZUX8UQJ5u9kTSTqV7gCxVbemV5iOhTazuwVQ1Aq7wFL6e/0oL4eolbgNP0ub76vy
UsZl9j/8pFhtVfdqRJqorKQ9H5RgvW7CCmobkUruGJoXg7jFuFdeqXtS4U1ziyJT
g42LtXuC053KrEnEmhj1EadZC4E1eXadffssanfyWolAXjRD3N+2vLYasJOiGDAO
mT111kQLaRNvZLJBULlrnWITkbVOhfE9Cxu14idxvdLShQiUO8kRCjoN2TbLZ2ET
n7u/4anHBu99ljO6uZVNe7JY5ZrwaM1o7Myvk9eOVRe4WKkgOXJKUM3lfwvfMK8Q
sEWvfBY04gL5y697DDiQvJ4g0fRwwnoadpHFvJTJX977H5C8/c750YZw/Emuip9D
zxyHGEVtncM6awbHP8bGBgg2f6XISWKs5qvzrwLmdXx42oi0VjU4z+cEVOUSx/rY
K+B+LVzcdYc/6UhjQzmylNBUs5CO7K6D05/tes07QaZ1MCCyw3b+DAR+LJn2U2+C
Y3+x/kQT16abMIIpTM8qVWqxswvaFSyZ+5hCkVrAsYwkM1fpB4c=
=PJhV
-----END PGP SIGNATURE-----
Merge tag 'linux_kselftest_active-fixes-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
Pull Kselftest fix from Shuah Khan:
"One single fix to assert check in user_events abi_test to properly
check bit value on Big Endian architectures. The code treated the bit
values as Little Endian and the check failed on Big Endian"
* tag 'linux_kselftest_active-fixes-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
selftests/user_events: Fix abi_test for BE archs
Hou Tao says:
====================
bpf: Fixes for per-cpu kptr
From: Hou Tao <houtao1@huawei.com>
Hi,
The patchset aims to fix the problems found in the review of per-cpu
kptr patch-set [0]. Patch #1 moves pcpu_lock after the invocation of
pcpu_chunk_addr_search() and it is a micro-optimization for
free_percpu(). The reason includes it in the patch is that the same
logic is used in newly-added API pcpu_alloc_size(). Patch #2 introduces
pcpu_alloc_size() for dynamic per-cpu area. Patch #2 and #3 use
pcpu_alloc_size() to check whether or not unit_size matches with the
size of underlying per-cpu area and to select a matching bpf_mem_cache.
Patch #4 fixes the freeing of per-cpu kptr when these kptrs are freed by
map destruction. The last patch adds test cases for these problems.
Please see individual patches for details. And comments are always
welcome.
Change Log:
v3:
* rebased on bpf-next
* patch 2: update API document to note that pcpu_alloc_size() doesn't
support statically allocated per-cpu area. (Dennis)
* patch 1 & 2: add Acked-by from Dennis
v2: https://lore.kernel.org/bpf/20231018113343.2446300-1-houtao@huaweicloud.com/
* add a new patch "don't acquire pcpu_lock for pcpu_chunk_addr_search()"
* patch 2: change type of bit_off and end to unsigned long (Andrew)
* patch 2: rename the new API as pcpu_alloc_size and follow 80-column convention (Dennis)
* patch 5: move the common declaration into bpf.h (Stanislav, Alxei)
v1: https://lore.kernel.org/bpf/20231007135106.3031284-1-houtao@huaweicloud.com/
[0]: https://lore.kernel.org/bpf/20230827152729.1995219-1-yonghong.song@linux.dev
====================
Link: https://lore.kernel.org/r/20231020133202.4043247-1-houtao@huaweicloud.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Add the following 3 test cases for bpf memory allocator:
1) Do allocation in bpf program and free through map free
2) Do batch per-cpu allocation and per-cpu free in bpf program
3) Do per-cpu allocation in bpf program and free through map free
For per-cpu allocation, because per-cpu allocation can not refill timely
sometimes, so test 2) and test 3) consider it is OK for
bpf_percpu_obj_new_impl() to return NULL.
Signed-off-by: Hou Tao <houtao1@huawei.com>
Link: https://lore.kernel.org/r/20231020133202.4043247-8-houtao@huaweicloud.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
The following warning was reported when running "./test_progs -t
test_bpf_ma/percpu_free_through_map_free":
------------[ cut here ]------------
WARNING: CPU: 1 PID: 68 at kernel/bpf/memalloc.c:342
CPU: 1 PID: 68 Comm: kworker/u16:2 Not tainted 6.6.0-rc2+ #222
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Workqueue: events_unbound bpf_map_free_deferred
RIP: 0010:bpf_mem_refill+0x21c/0x2a0
......
Call Trace:
<IRQ>
? bpf_mem_refill+0x21c/0x2a0
irq_work_single+0x27/0x70
irq_work_run_list+0x2a/0x40
irq_work_run+0x18/0x40
__sysvec_irq_work+0x1c/0xc0
sysvec_irq_work+0x73/0x90
</IRQ>
<TASK>
asm_sysvec_irq_work+0x1b/0x20
RIP: 0010:unit_free+0x50/0x80
......
bpf_mem_free+0x46/0x60
__bpf_obj_drop_impl+0x40/0x90
bpf_obj_free_fields+0x17d/0x1a0
array_map_free+0x6b/0x170
bpf_map_free_deferred+0x54/0xa0
process_scheduled_works+0xba/0x370
worker_thread+0x16d/0x2e0
kthread+0x105/0x140
ret_from_fork+0x39/0x60
ret_from_fork_asm+0x1b/0x30
</TASK>
---[ end trace 0000000000000000 ]---
The reason is simple: __bpf_obj_drop_impl() does not know the freeing
field is a per-cpu pointer and it uses bpf_global_ma to free the
pointer. Because bpf_global_ma is not a per-cpu allocator, so ksize() is
used to select the corresponding cache. The bpf_mem_cache with 16-bytes
unit_size will always be selected to do the unmatched free and it will
trigger the warning in free_bulk() eventually.
Because per-cpu kptr doesn't support list or rb-tree now, so fix the
problem by only checking whether or not the type of kptr is per-cpu in
bpf_obj_free_fields(), and using bpf_global_percpu_ma to these kptrs.
Signed-off-by: Hou Tao <houtao1@huawei.com>
Link: https://lore.kernel.org/r/20231020133202.4043247-7-houtao@huaweicloud.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
For bpf_global_percpu_ma, the pointer passed to bpf_mem_free_rcu() is
allocated by kmalloc() and its size is fixed (16-bytes on x86-64). So
no matter which cache allocates the dynamic per-cpu area, on x86-64
cache[2] will always be used to free the per-cpu area.
Fix the unbalance by checking whether the bpf memory allocator is
per-cpu or not and use pcpu_alloc_size() instead of ksize() to
find the correct cache for per-cpu free.
Signed-off-by: Hou Tao <houtao1@huawei.com>
Link: https://lore.kernel.org/r/20231020133202.4043247-5-houtao@huaweicloud.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
With pcpu_alloc_size() in place, check whether or not the size of
the dynamic per-cpu area is matched with unit_size.
Signed-off-by: Hou Tao <houtao1@huawei.com>
Link: https://lore.kernel.org/r/20231020133202.4043247-4-houtao@huaweicloud.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Introduce pcpu_alloc_size() to get the size of the dynamic per-cpu
area. It will be used by bpf memory allocator in the following patches.
BPF memory allocator maintains per-cpu area caches for multiple area
sizes and its free API only has the to-be-freed per-cpu pointer, so it
needs the size of dynamic per-cpu area to select the corresponding cache
when bpf program frees the dynamic per-cpu pointer.
Acked-by: Dennis Zhou <dennis@kernel.org>
Signed-off-by: Hou Tao <houtao1@huawei.com>
Link: https://lore.kernel.org/r/20231020133202.4043247-3-houtao@huaweicloud.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Stable Fix:
* Fix a pNFS hang in nfs4_evict_inode()
Bugfixes:
* Force update of suid/sgid bits after an NFS v4.2 ALLOCATE op
* Fix a potential oops in nfs_inode_remove_request()
* Check the validity of the layout pointer in ff_layout_mirror_prepare_stats()
* Fix incorrectly marking the pNFS MDS with USE_PNFS_DS in some cases
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEnZ5MQTpR7cLU7KEp18tUv7ClQOsFAmUy4cAACgkQ18tUv7Cl
QOstABAAtK5pXSbzXXQY1IIVIxgIT9tGRMPwd+IVUwL0qRIhTqGkiax6UuZVH9id
NxrTQFrrxC4np2X4atYdC4LggOqx6wcdNLQ9oJ56zULHUtycgjqCSjFrKbA3nFa6
tn4EccPvKzjsmsbJW1rCq97XIRqZY1XotjDA3MR72YSnsOncdoLr6ng6virjOxWe
t8K8WS4tScD0kwvclQLpsEDSFEEdjTYORdS3RVXVz4crM45gikmTI7bSyZ4vc0lT
TafhFYMjcHUNyKF8MP0DguYSGTtHxCHuM/0yYZw0ZiqLdZeT7Pk/GVecV6qmMD9W
REkidcFLV53RR4qjUvL0HuM71/cX+yfwGaj6e8nZg5b7s1pJB46IG58ZmQaPwyzP
n9/zxZHIRrNSkj6e+cwFpgpz7v7wjTOsXVUqBLE9q0Rsm71L8TuzW0G/lghY8tE+
TZ4rMVlZnypFybELmEgoRXRZa0G41SeQmKYNMv+wJIwpNyxbKkI3FgpAx0A4RuyP
prYK4S55GxqKiOrP22USHRpvkhxdzeIkmnPGuy/A04VYaVJwANjUI0w0SAgg1/Oj
iNLjvO80wIL7d3fRLpjcjiQ2DtVt63WcnMgR0dV138959vh9CKAF7u7xVdW4Zsk7
cO5/WAFR5cUh2veswsi69+oivXweP57pi0XWmiJamKKckS/PPuQ=
=Z3lY
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-6.6-4' of git://git.linux-nfs.org/projects/anna/linux-nfs
Pull NFS client fixes from Anna Schumaker:
"Stable Fix:
- Fix a pNFS hang in nfs4_evict_inode()
Fixes:
- Force update of suid/sgid bits after an NFS v4.2 ALLOCATE op
- Fix a potential oops in nfs_inode_remove_request()
- Check the validity of the layout pointer in ff_layout_mirror_prepare_stats()
- Fix incorrectly marking the pNFS MDS with USE_PNFS_DS in some cases"
* tag 'nfs-for-6.6-4' of git://git.linux-nfs.org/projects/anna/linux-nfs:
NFSv4.1: fixup use EXCHGID4_FLAG_USE_PNFS_DS for DS server
pNFS/flexfiles: Check the layout validity in ff_layout_mirror_prepare_stats
pNFS: Fix a hang in nfs4_evict_inode()
NFS: Fix potential oops in nfs_inode_remove_request()
nfs42: client needs to strip file mode's suid/sgid bit after ALLOCATE op
