Cross-checked with msm-4.14 and msm-5.15 tags. The change does not exist
as a separate commit and is squashed into the initial import.
Change-Id: Ib3defedf0fbd5b7cdccdfba26383313ff05b4ef0
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Cross-checked with msm-5.15 tag. The change does not exist as a separate
commit and is squashed into the initial import.
Change-Id: Ie922c512d7ea24661d3179cfd156ab8eb6fcc363
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
fs/crypto/policy.c:656:4: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
656 | return 0;
| ^
fs/crypto/policy.c:654:3: note: previous statement is here
654 | if (!strcmp(boot, SDHCI) && !strcmp(file_system_type, "f2fs"))
| ^
1 error generated.
Change-Id: I14c5d8aec6ff611be24548dd228ee0264c72ab38
drivers/platform/msm/usb_bam.c:1158:4: error: misleading indentation; statement is not part of the previous 'else' [-Werror,-Wmisleading-indentation]
1158 | spin_unlock(&ctx->usb_bam_lock);
| ^
drivers/platform/msm/usb_bam.c:1156:3: note: previous statement is here
1156 | else
| ^
drivers/platform/msm/usb_bam.c:1279:4: error: misleading indentation; statement is not part of the previous 'else' [-Werror,-Wmisleading-indentation]
1279 | spin_unlock(&ctx->usb_bam_lock);
| ^
drivers/platform/msm/usb_bam.c:1277:3: note: previous statement is here
1277 | else
| ^
2 errors generated.
Change-Id: Iff4ccebdbb25d8294f74ebdb7f9053a5f6b1da85
Fix an out of order definition of MODULE_DEVICE_TABLE, add missing
brackets to fix a suspect indentation warning and mark an
implcit switch fall through.
Fixes: 377c69bf3e72 ("crypto: msm: Add QTI crypto drivers")
Change-Id: Ic0dedbada33fd2e5c692e5f0d64fd0e7b7afb5f1
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Fix the following warning from gcc 7.4.1 with -Werror enabled:
drivers/crypto/msm/qce50.c:4668:28: error: ‘~’ on a boolean expression
[-Werror=bool-operation]
pce_dev->cadence_flag = ~pce_dev->cadence_flag;
drivers/crypto/msm/qce50.c:4668:28: note: did you mean to use logical not?.
Fixes: 377c69bf3e72 ("crypto: msm: Add QTI crypto drivers")
Change-Id: Ic0dedbad73c49d059d68d9412009b74583d33154
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
This flag is specific to clang, where it is only used by the 32-bit and
64-bit ARM backends. In certain situations, the presence of this flag
will cause a warning, as shown by commit 6580c5c18fb3 ("um: clang: Strip
out -mno-global-merge from USER_CFLAGS").
Since commit 61163efae0 ("kbuild: LLVMLinux: Add Kbuild support for
building kernel with Clang") that added this flag back in 2014, there
have been quite a few changes to the GlobalMerge pass in LLVM. Building
several different ARCH=arm and ARCH=arm64 configurations with LLVM 11
(minimum) and 15 (current main version) with this flag removed (i.e.,
with the default of '-mglobal-merge') reveals no modpost warnings, so it
is likely that the issue noted in the comment is no longer relevant due
to changes in LLVM or modpost, meaning this flag can be removed.
If any new warnings show up that are a result of the removal of this
flag, it can be added back under arch/arm{,64}/Makefile to avoid
warnings on other architectures.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: David Gow <davidgow@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
(cherry picked from commit cf300b83c793c25c6b485fdaf7a4447d8ea4c655)
Change-Id: Ice39a960619319828b83c8091798fe383395a2b0
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
This reverts commit f3fda57f6a.
Unnecessary with Clang 6.0+.
Change-Id: I6f29ca050566e9027e51605e64bf6893602344ef
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
scripts/mkcompile_h runs $(CC) just for getting the version string.
Reuse CONFIG_CC_VERSION_TEXT for optimization.
For GCC, this slightly changes the version string. I do not think it
is a big deal as we do not have the defined format for LINUX_COMPILER.
In fact, the recent commit 4831f7ad6c569 ("kbuild: mkcompile_h:
Include $LD version in /proc/version") added the linker version.
Bug: 168274246
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
(cherry picked from commit 9a950154668729a472d17b8e307d92e7c60f45f7)
Signed-off-by: Mars Lin <marslin@google.com>
Change-Id: I66bac5b44bf764e7c0e432ae17bcdf06d79c96d0
Commit 21c54b7747 ("kconfig: show compiler version text in the top
comment") added the environment variable, CC_VERSION_TEXT in the comment
of the top Kconfig file. It can detect the compiler update, and invoke
the syncconfig because all environment variables referenced in Kconfig
files are recorded in include/config/auto.conf.cmd
This commit makes it a CONFIG option in order to ensure the full rebuild
when the compiler is updated.
This works like follows:
include/config/kconfig.h contains "CONFIG_CC_VERSION_TEXT" in the comment
block.
The top Makefile specifies "-include $(srctree)/include/linux/kconfig.h"
to guarantee it is included from all kernel source files.
fixdep parses every source file and all headers included from it,
searching for words prefixed with "CONFIG_". Then, fixdep finds
CONFIG_CC_VERSION_TEXT in include/config/kconfig.h and adds
include/config/cc/version/text.h into every .*.cmd file.
When the compiler is updated, syncconfig is invoked because init/Kconfig
contains the reference to the environment variable CC_VERTION_TEXT.
CONFIG_CC_VERSION_TEXT is updated to the new version string, and
include/config/cc/version/text.h is touched.
In the next rebuild, Make will rebuild every files since the timestamp
of include/config/cc/version/text.h is newer than that of target.
Bug: 168274246
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
(cherry picked from commit 8b59cd81dc5e724eaea283fa6006985891c7bff4)
Signed-off-by: Mars Lin <marslin@google.com>
Change-Id: Ie52bb8e33b95d0e97998024d28c0d8d7caf8aa59
After r372664 in clang, the IF_ASSIGN macro causes a couple hundred
warnings along the lines of:
kernel/trace/trace_output.c:1331:2: warning: converting the enum
constant to a boolean [-Wint-in-bool-context]
kernel/trace/trace.h:409:3: note: expanded from macro
'trace_assign_type'
IF_ASSIGN(var, ent, struct ftrace_graph_ret_entry,
^
kernel/trace/trace.h:371:14: note: expanded from macro 'IF_ASSIGN'
WARN_ON(id && (entry)->type != id); \
^
264 warnings generated.
This warning can catch issues with constructs like:
if (state == A || B)
where the developer really meant:
if (state == A || state == B)
This is currently the only occurrence of the warning in the kernel
tree across defconfig, allyesconfig, allmodconfig for arm32, arm64,
and x86_64. Add the implicit '!= 0' to the WARN_ON statement to fix
the warnings and find potential issues in the future.
Link: 28b38c277a
Link: https://github.com/ClangBuiltLinux/linux/issues/686
Link: http://lkml.kernel.org/r/20190926162258.466321-1-natechancellor@gmail.com
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: Ie386f06316743073363f974e7539d43ff769b91c
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Currently, while parsing scan RNR Ie data is moved to
next neighbor_ap_info_field after parsing the current
neighbor_ap_info_field. But in last iteration pointer may
try to access invalid data if (uint8_t *)ie + rnr_ie_len + 2)
bytes are less than sizeof neighbor_ap_info_field and same
is the case with tbtt_length access.
Fix is to add a length check of data + next data size to be parsed
< (uint8_t *)ie + rnr_ie_len + 2) instead of adding a validation
of data length only.
CRs-Fixed: 3710080
Change-Id: I05e5a9a02f0f4f9bc468db894588e676f0a248c0
The passed in pointer in kgsl_count_hw_fences() can be a
kgsl_mem_entry pointer. This gets cross dereferenced to
a kgsl_drawobj_sync_event pointer and causes a NULL pointer
dereference. To avoid this cross dereference, decouple the two
paths and call kgsl_count_hw_fences() only in the appropriate
path.
Change-Id: I1088a0b67f1f82a20ddc94c94cbdd31a44b18da6
Signed-off-by: Harshdeep Dhatt <quic_hdhatt@quicinc.com>
Changes in 4.19.318
asm-generic: Move common compat types to asm-generic/compat.h
media: dvb: as102-fe: Fix as10x_register_addr packing
media: dvb-usb: dib0700_devices: Add missing release_firmware()
IB/core: Implement a limit on UMAD receive List
drm/amd/display: Skip finding free audio for unknown engine_id
media: dw2102: Don't translate i2c read into write
sctp: prefer struct_size over open coded arithmetic
firmware: dmi: Stop decoding on broken entry
Input: ff-core - prefer struct_size over open coded arithmetic
net: dsa: mv88e6xxx: Correct check for empty list
media: dvb-frontends: tda18271c2dd: Remove casting during div
media: s2255: Use refcount_t instead of atomic_t for num_channels
media: dvb-frontends: tda10048: Fix integer overflow
i2c: i801: Annotate apanel_addr as __ro_after_init
powerpc/64: Set _IO_BASE to POISON_POINTER_DELTA not 0 for CONFIG_PCI=n
orangefs: fix out-of-bounds fsid access
powerpc/xmon: Check cpu id in commands "c#", "dp#" and "dx#"
jffs2: Fix potential illegal address access in jffs2_free_inode
s390/pkey: Wipe sensitive data on failure
tcp: take care of compressed acks in tcp_add_reno_sack()
tcp: tcp_mark_head_lost is only valid for sack-tcp
tcp: add ece_ack flag to reno sack functions
net: tcp better handling of reordering then loss cases
UPSTREAM: tcp: fix DSACK undo in fast recovery to call tcp_try_to_open()
tcp_metrics: validate source addr length
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
selftests: fix OOM in msg_zerocopy selftest
selftests: make order checking verbose in msg_zerocopy selftest
inet_diag: Initialize pad field in struct inet_diag_req_v2
nilfs2: fix inode number range checks
nilfs2: add missing check for inode numbers on directory entries
mm: optimize the redundant loop of mm_update_owner_next()
Bluetooth: Fix incorrect pointer arithmatic in ext_adv_report_evt
can: kvaser_usb: Explicitly initialize family in leafimx driver_info struct
fsnotify: Do not generate events for O_PATH file descriptors
Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes
drm/amdgpu/atomfirmware: silence UBSAN warning
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
media: dw2102: fix a potential buffer overflow
i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
nilfs2: fix incorrect inode allocation from reserved inodes
drm/i915: make find_fw_domain work on intel_uncore
tcp: fix incorrect undo caused by DSACK of TLP retransmit
net: lantiq_etop: add blank line after declaration
net: ethernet: lantiq_etop: fix double free in detach
ppp: reject claimed-as-LCP but actually malformed packets
ARM: davinci: Convert comma to semicolon
USB: serial: option: add Telit generic core-dump composition
USB: serial: option: add Telit FN912 rmnet compositions
USB: serial: option: add Fibocom FM350-GL
USB: serial: option: add support for Foxconn T99W651
USB: serial: option: add Netprisma LCUK54 series modules
USB: serial: option: add Rolling RW350-GL variants
USB: Add USB_QUIRK_NO_SET_INTF quirk for START BP-850k
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
hpet: Support 32-bit userspace
libceph: fix race between delayed_work() and ceph_monc_stop()
tcp: refactor tcp_retransmit_timer()
net: tcp: fix unexcepted socket die when snd_wnd is 0
tcp: use signed arithmetic in tcp_rtx_probe0_timed_out()
tcp: avoid too many retransmit packets
SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
nilfs2: fix kernel bug on rename operation of broken directory
i2c: rcar: bring hardware to known state when probing
Linux 4.19.318
Change-Id: I6d2646a308c3f44976d00ee372e87568c3e40c23
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 97a9063518f198ec0adb2ecb89789de342bb8283 upstream.
If a TCP socket is using TCP_USER_TIMEOUT, and the other peer
retracted its window to zero, tcp_retransmit_timer() can
retransmit a packet every two jiffies (2 ms for HZ=1000),
for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.
The fix is to make sure tcp_rtx_probe0_timed_out() takes
icsk->icsk_user_timeout into account.
Before blamed commit, the socket would not timeout after
icsk->icsk_user_timeout, but would use standard exponential
backoff for the retransmits.
Also worth noting that before commit e89688e3e978 ("net: tcp:
fix unexcepted socket die when snd_wnd is 0"), the issue
would last 2 minutes instead of 4.
Fixes: b701a99e43 ("tcp: Add tcp_clamp_rto_to_user_timeout() helper to improve accuracy")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Reviewed-by: Jon Maxwell <jmaxwell37@gmail.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://patch.msgid.link/20240710001402.2758273-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 36534d3c54537bf098224a32dc31397793d4594d upstream.
Due to timer wheel implementation, a timer will usually fire
after its schedule.
For instance, for HZ=1000, a timeout between 512ms and 4s
has a granularity of 64ms.
For this range of values, the extra delay could be up to 63ms.
For TCP, this means that tp->rcv_tstamp may be after
inet_csk(sk)->icsk_timeout whenever the timer interrupt
finally triggers, if one packet came during the extra delay.
We need to make sure tcp_rtx_probe0_timed_out() handles this case.
Fixes: e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Menglong Dong <imagedong@tencent.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Link: https://lore.kernel.org/r/20240607125652.1472540-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e89688e3e97868451a5d05b38a9d2633d6785cd4 upstream.
In tcp_retransmit_timer(), a window shrunk connection will be regarded
as timeout if 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX'. This is not
right all the time.
The retransmits will become zero-window probes in tcp_retransmit_timer()
if the 'snd_wnd==0'. Therefore, the icsk->icsk_rto will come up to
TCP_RTO_MAX sooner or later.
However, the timer can be delayed and be triggered after 122877ms, not
TCP_RTO_MAX, as I tested.
Therefore, 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX' is always true
once the RTO come up to TCP_RTO_MAX, and the socket will die.
Fix this by replacing the 'tcp_jiffies32' with '(u32)icsk->icsk_timeout',
which is exact the timestamp of the timeout.
However, "tp->rcv_tstamp" can restart from idle, then tp->rcv_tstamp
could already be a long time (minutes or hours) in the past even on the
first RTO. So we double check the timeout with the duration of the
retransmission.
Meanwhile, making "2 * TCP_RTO_MAX" as the timeout to avoid the socket
dying too soon.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Link: https://lore.kernel.org/netdev/CADxym3YyMiO+zMD4zj03YPM3FBi-1LHi6gSD2XT8pyAMM096pg@mail.gmail.com/
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0d580fbd2db084a5c96ee9c00492236a279d5e0f upstream.
It appears linux-4.14 stable needs a backport of commit
88f8598d0a30 ("tcp: exit if nothing to retransmit on RTO timeout")
Since tcp_rtx_queue_empty() is not in pre 4.15 kernels,
let's refactor tcp_retransmit_timer() to only use tcp_rtx_queue_head()
I will provide to stable teams the squashed patches.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c7b2fe4c9cc1d3b1186d1c5606627ecf0de883 upstream.
The way the delayed work is handled in ceph_monc_stop() is prone to
races with mon_fault() and possibly also finish_hunting(). Both of
these can requeue the delayed work which wouldn't be canceled by any of
the following code in case that happens after cancel_delayed_work_sync()
runs -- __close_session() doesn't mess with the delayed work in order
to avoid interfering with the hunting interval logic. This part was
missed in commit b5d91704f5 ("libceph: behave in mon_fault() if
cur_mon < 0") and use-after-free can still ensue on monc and objects
that hang off of it, with monc->auth and monc->monmap being
particularly susceptible to quickly being reused.
To fix this:
- clear monc->cur_mon and monc->hunting as part of closing the session
in ceph_monc_stop()
- bail from delayed_work() if monc->cur_mon is cleared, similar to how
it's done in mon_fault() and finish_hunting() (based on monc->hunting)
- call cancel_delayed_work_sync() after the session is closed
Cc: stable@vger.kernel.org
Link: https://tracker.ceph.com/issues/66857
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a368ecde8a5055b627749b09c6218ef793043e47 upstream.
Syzbot has identified a bug in usbcore (see the Closes: tag below)
caused by our assumption that the reserved bits in an endpoint
descriptor's bEndpointAddress field will always be 0. As a result of
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
other routines as well) may believe that two descriptors are for
distinct endpoints, even though they have the same direction and
endpoint number. This can lead to confusion, including the bug
identified by syzbot (two descriptors with matching endpoint numbers
and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress
when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1
specs say these bits are "Reserved, reset to zero".) This requires us
to make a copy of the descriptor earlier in usb_parse_endpoint() and
use the copy instead of the original when checking for duplicates.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: syzbot+8693a0bb9c10b554272a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/0000000000003d868e061bc0f554@google.com/
Fixes: 0a8fd13462 ("USB: fix problems with duplicate endpoint addresses")
CC: Oliver Neukum <oneukum@suse.com>
CC: stable@vger.kernel.org
Link: https://lore.kernel.org/r/205a5edc-7fef-4159-b64a-80374b6b101a@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6d3c721e686ea6c59e18289b400cc95c76e927e0 upstream.
Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
`if (str[0 - 1] == '\n') followed closely by an OOB write in the form
`str[0 - 1] = '\0'`.
There is already a validating check to catch strings that are too long.
Let's supply an additional check for invalid strings that are too short.
Signed-off-by: Lee Jones <lee@kernel.org>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20240705074339.633717-1-lee@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 4c46625bb586a741b8d0e6bdbddbcb2549fa1d36 ]
This patch adds a missing line after the declaration and
fixes the checkpatch warning:
WARNING: Missing a blank line after declarations
+ int desc;
+ for (desc = 0; desc < LTQ_DESC_NUM; desc++)
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://lore.kernel.org/r/20211228220031.71576-1-olek2@wp.pl
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stable-dep-of: e1533b6319ab ("net: ethernet: lantiq_etop: fix double free in detach")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0ec986ed7bab6801faed1440e8839dcc710331ff ]
Loss recovery undo_retrans bookkeeping had a long-standing bug where a
DSACK from a spurious TLP retransmit packet could cause an erroneous
undo of a fast recovery or RTO recovery that repaired a single
really-lost packet (in a sequence range outside that of the TLP
retransmit). Basically, because the loss recovery state machine didn't
account for the fact that it sent a TLP retransmit, the DSACK for the
TLP retransmit could erroneously be implicitly be interpreted as
corresponding to the normal fast recovery or RTO recovery retransmit
that plugged a real hole, thus resulting in an improper undo.
For example, consider the following buggy scenario where there is a
real packet loss but the congestion control response is improperly
undone because of this bug:
+ send packets P1, P2, P3, P4
+ P1 is really lost
+ send TLP retransmit of P4
+ receive SACK for original P2, P3, P4
+ enter fast recovery, fast-retransmit P1, increment undo_retrans to 1
+ receive DSACK for TLP P4, decrement undo_retrans to 0, undo (bug!)
+ receive cumulative ACK for P1-P4 (fast retransmit plugged real hole)
The fix: when we initialize undo machinery in tcp_init_undo(), if
there is a TLP retransmit in flight, then increment tp->undo_retrans
so that we make sure that we receive a DSACK corresponding to the TLP
retransmit, as well as DSACKs for all later normal retransmits, before
triggering a loss recovery undo. Note that we also have to move the
line that clears tp->tlp_high_seq for RTO recovery, so that upon RTO
we remember the tp->tlp_high_seq value until tcp_init_undo() and clear
it only afterward.
Also note that the bug dates back to the original 2013 TLP
implementation, commit 6ba8a3b19e ("tcp: Tail loss probe (TLP)").
However, this patch will only compile and work correctly with kernels
that have tp->tlp_retrans, which was added only in v5.8 in 2020 in
commit 76be93fc0702 ("tcp: allow at most one TLP probe per flight").
So we associate this fix with that later commit.
Fixes: 76be93fc0702 ("tcp: allow at most one TLP probe per flight")
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Kevin Yang <yyd@google.com>
Link: https://patch.msgid.link/20240703171246.1739561-1-ncardwell.sw@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 93aef9eda1cea9e84ab2453fcceb8addad0e46f1 upstream.
If the bitmap block that manages the inode allocation status is corrupted,
nilfs_ifile_create_inode() may allocate a new inode from the reserved
inode area where it should not be allocated.
Previous fix commit d325dc6eb763 ("nilfs2: fix use-after-free bug of
struct nilfs_root"), fixed the problem that reserved inodes with inode
numbers less than NILFS_USER_INO (=11) were incorrectly reallocated due to
bitmap corruption, but since the start number of non-reserved inodes is
read from the super block and may change, in which case inode allocation
may occur from the extended reserved inode area.
If that happens, access to that inode will cause an IO error, causing the
file system to degrade to an error state.
Fix this potential issue by adding a wraparound option to the common
metadata object allocation routine and by modifying
nilfs_ifile_create_inode() to disable the option so that it only allocates
inodes with inode numbers greater than or equal to the inode number read
in "nilfs->ns_first_ino", regardless of the bitmap status of reserved
inodes.
Link: https://lkml.kernel.org/r/20240623051135.4180-4-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: Hillf Danton <hdanton@sina.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
