From: Jeff Vanhoof <qjv001(a)motorola.com>
arm-smmu related crashes seen after a Missed ISOC interrupt when
no_interrupt=1 is used. This can happen if the hardware is still using
the data associated with a TRB after the usb_request's ->complete call
has been made. Instead of immediately releasing a request when a Missed
ISOC interrupt has occurred, this change will add logic to cancel the
request instead where it will eventually be released when the
END_TRANSFER command has completed. This logic is similar to some of the
cleanup done in dwc3_gadget_ep_dequeue.
Fixes: 6d8a019614f3 ("usb: dwc3: gadget: check for Missed Isoc from event status")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Jeff Vanhoof <qjv001(a)motorola.com>
Co-developed-by: Dan Vacura <w36195(a)motorola.com>
Signed-off-by: Dan Vacura <w36195(a)motorola.com>
---
V1 -> V3:
- no change, new patch in series
V3 -> V4:
- no change
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/gadget.c | 38 ++++++++++++++++++++++++++------------
2 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 8f9959ba9fd4..9b005d912241 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -943,6 +943,7 @@ struct dwc3_request {
#define DWC3_REQUEST_STATUS_DEQUEUED 3
#define DWC3_REQUEST_STATUS_STALLED 4
#define DWC3_REQUEST_STATUS_COMPLETED 5
+#define DWC3_REQUEST_STATUS_MISSED_ISOC 6
#define DWC3_REQUEST_STATUS_UNKNOWN -1
u8 epnum;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 079cd333632e..411532c5c378 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2021,6 +2021,9 @@ static void dwc3_gadget_ep_cleanup_cancelled_requests(struct dwc3_ep *dep)
case DWC3_REQUEST_STATUS_STALLED:
dwc3_gadget_giveback(dep, req, -EPIPE);
break;
+ case DWC3_REQUEST_STATUS_MISSED_ISOC:
+ dwc3_gadget_giveback(dep, req, -EXDEV);
+ break;
default:
dev_err(dwc->dev, "request cancelled with wrong reason:%d\n", req->status);
dwc3_gadget_giveback(dep, req, -ECONNRESET);
@@ -3402,21 +3405,32 @@ static bool dwc3_gadget_endpoint_trbs_complete(struct dwc3_ep *dep,
struct dwc3 *dwc = dep->dwc;
bool no_started_trb = true;
- dwc3_gadget_ep_cleanup_completed_requests(dep, event, status);
+ if (status == -EXDEV) {
+ struct dwc3_request *tmp;
+ struct dwc3_request *req;
- if (dep->flags & DWC3_EP_END_TRANSFER_PENDING)
- goto out;
+ if (!(dep->flags & DWC3_EP_END_TRANSFER_PENDING))
+ dwc3_stop_active_transfer(dep, true, true);
- if (!dep->endpoint.desc)
- return no_started_trb;
+ list_for_each_entry_safe(req, tmp, &dep->started_list, list)
+ dwc3_gadget_move_cancelled_request(req,
+ DWC3_REQUEST_STATUS_MISSED_ISOC);
+ } else {
+ dwc3_gadget_ep_cleanup_completed_requests(dep, event, status);
- if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
- list_empty(&dep->started_list) &&
- (list_empty(&dep->pending_list) || status == -EXDEV))
- dwc3_stop_active_transfer(dep, true, true);
- else if (dwc3_gadget_ep_should_continue(dep))
- if (__dwc3_gadget_kick_transfer(dep) == 0)
- no_started_trb = false;
+ if (dep->flags & DWC3_EP_END_TRANSFER_PENDING)
+ goto out;
+
+ if (!dep->endpoint.desc)
+ return no_started_trb;
+
+ if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
+ list_empty(&dep->started_list) && list_empty(&dep->pending_list))
+ dwc3_stop_active_transfer(dep, true, true);
+ else if (dwc3_gadget_ep_should_continue(dep))
+ if (__dwc3_gadget_kick_transfer(dep) == 0)
+ no_started_trb = false;
+ }
out:
/*
--
2.34.1
Similar to the rk817 codec alias that was missing, the rk817 charger
driver is missing a module alias as well. This absence prevents the
driver from autoprobing on OF systems when it is built as a module.
Add the right MODULE_ALIAS to fix this.
Fixes: 11cb8da0189b ("power: supply: Add charger driver for Rockchip RK817")
Cc: stable(a)vger.kernel.org
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas(a)gmail.com>
---
drivers/power/supply/rk817_charger.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/supply/rk817_charger.c b/drivers/power/supply/rk817_charger.c
index 1a2143641e66..76b991e112da 100644
--- a/drivers/power/supply/rk817_charger.c
+++ b/drivers/power/supply/rk817_charger.c
@@ -1211,3 +1211,4 @@ MODULE_DESCRIPTION("Battery power supply driver for RK817 PMIC");
MODULE_AUTHOR("Maya Matuszczyk <maccraft123mc(a)gmail.com>");
MODULE_AUTHOR("Chris Morgan <macromorgan(a)hotmail.com>");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:rk817-charger");
--
2.41.0
When upreving llvm I realised that kexec stopped working on my test
platform.
The reason seems to be that due to PGO there are multiple .text sections
on the purgatory, and kexec does not supports that.
Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org>
---
Changes in v7:
- Fix $SUBJECT of riscv patch
- Rename PGO as Profile-guided optimization
- Link to v6: https://lore.kernel.org/r/20230321-kexec_clang16-v6-0-a2255e81ab45@chromium…
Changes in v6:
- Replace linker script with Makefile rule. Thanks Nick
- Link to v5: https://lore.kernel.org/r/20230321-kexec_clang16-v5-0-5563bf7c4173@chromium…
Changes in v5:
- Add warning when multiple text sections are found. Thanks Simon!
- Add Fixes tag.
- Link to v4: https://lore.kernel.org/r/20230321-kexec_clang16-v4-0-1340518f98e9@chromium…
Changes in v4:
- Add Cc: stable
- Add linker script for x86
- Add a warning when the kernel image has overlapping sections.
- Link to v3: https://lore.kernel.org/r/20230321-kexec_clang16-v3-0-5f016c8d0e87@chromium…
Changes in v3:
- Fix initial value. Thanks Ross!
- Link to v2: https://lore.kernel.org/r/20230321-kexec_clang16-v2-0-d10e5d517869@chromium…
Changes in v2:
- Fix if condition. Thanks Steven!.
- Update Philipp email. Thanks Baoquan.
- Link to v1: https://lore.kernel.org/r/20230321-kexec_clang16-v1-0-a768fc2c7c4d@chromium…
---
Ricardo Ribalda (4):
kexec: Support purgatories with .text.hot sections
x86/purgatory: Remove PGO flags
powerpc/purgatory: Remove PGO flags
riscv/purgatory: Remove PGO flags
arch/powerpc/purgatory/Makefile | 5 +++++
arch/riscv/purgatory/Makefile | 5 +++++
arch/x86/purgatory/Makefile | 5 +++++
kernel/kexec_file.c | 14 +++++++++++++-
4 files changed, 28 insertions(+), 1 deletion(-)
---
base-commit: 58390c8ce1bddb6c623f62e7ed36383e7fa5c02f
change-id: 20230321-kexec_clang16-4510c23d129c
Best regards,
--
Ricardo Ribalda Delgado <ribalda(a)chromium.org>
When introducing support for processed channels I needed
to invert the expression:
if (!iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) ||
!iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE))
dev_err(dev, "source channel does not support raw/scale\n");
To the inverse, meaning detect when we can usse raw+scale
rather than when we can not. This was the result:
if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) ||
iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE))
dev_info(dev, "using raw+scale source channel\n");
Ooops. Spot the error. Yep old George Boole came up and bit me.
That should be an &&.
The current code "mostly works" because we have not run into
systems supporting only raw but not scale or only scale but not
raw, and I doubt there are few using the rescaler on anything
such, but let's fix the logic.
Cc: Liam Beguin <liambeguin(a)gmail.com>
Cc: stable(a)vger.kernel.org
Fixes: 53ebee949980 ("iio: afe: iio-rescale: Support processed channels")
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
drivers/iio/afe/iio-rescale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c
index 7e511293d6d1..dc426e1484f0 100644
--- a/drivers/iio/afe/iio-rescale.c
+++ b/drivers/iio/afe/iio-rescale.c
@@ -278,7 +278,7 @@ static int rescale_configure_channel(struct device *dev,
chan->ext_info = rescale->ext_info;
chan->type = rescale->cfg->type;
- if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) ||
+ if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) &&
iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE)) {
dev_info(dev, "using raw+scale source channel\n");
} else if (iio_channel_has_info(schan, IIO_CHAN_INFO_PROCESSED)) {
--
2.35.3
By abusing new methods of file descriptor transferal it is possible to
break the assumption that f_pos_lock doesn't need to be acquired when
the caller is single threaded and the file_count(file) is one aka when
the caller holds the only reference to the file.
The explanation has two parts. The first part is about a new io_uring
interface that isn't merged yet where I realized that only acquiring the
lock when multiple references to a file are held would be broken in some
circumstances. The second part illustrates that this assumption is
already broken by abusing another interface.
During review of the io_uring patchset for adding getdents support I
pointed out various problems in the locking assumptions that were made.
Effectively, the guts of __fdget_pos() were copied out and a trylock
scheme for f_pos_lock was introduced.
The approach overall is workable but the locking was wrong because it
copied the file_count(file) greater than one optimization that
__fdget_pos() had into io_uring. But this assumption is broken when
fixed file descriptors are used.
Short reminder of fixed files here via some C pseudo code:
T1 (still single threaded)
fd_register = open("/some/file") -----------------> f_count == 1
fd_fixed = io_uring_register_file(fd_register)
-> io_sqe_files_register(fd_register)
-> fget(fd_register) --------------------------> f_count == 2
-> io_fixed_file_set(fd_register)
close(fd_register);
-> close_fd(fd_register)
-> file = pick_file()
-> filp_close(file)
-> fput(file) ------------------------------> f_count == 1
The caller has now traded a regular file descriptor reference for a
fixed file reference. Such fixed files never use fget() again and thus
fully eliminate any fget()/fput() overhead.
However, for getdents f_pos_lock needs to be acquired as state may often
be kept that requires synchronization with seek and other concurrent
getdent requests.
Since io_uring is an asynchronous interface it is of course possible to
register multiple concurrent getdent calls that aren't synchronized by
io_uring as that's never done unless the user requests specific
chaining. And since the reference count for fixed files is always one
it's possible to create multiple racing getdent requests if locking is
conditional on file_count(file) being greater than one.
That wouldn't be a problem since io_uring can just unconditionally take
f_pos_lock and eliminate this problem for fixed files since they aren't
usable with the regular system call api.
However, while thinking about this I realized that a while ago the
file_count(file) greater than one optimization was already broken and
that concurrent read/write/getdents/seek calls are possible in the
regular system call api.
The pidfd_getfd() system call allows a caller with ptrace_may_access()
abilities on another process to steal a file descriptor from this
process. This system call is used by debuggers, container runtimes,
system call supervisors, networking proxies etc (cf. [1]-[3]). So while
it is a special interest system call it is used in common tools.
Via pidfd_getfd() it's possible to intercept syscalls such as
connect(2). For example, a container manager might want to rewrite the
connect(2) request to something other than the task intended for
security reasons or because the task lacks the necessary information
about the networking layout to connect to the right endpoint. In these
cases pidfd_getfd(2) can be used to retrieve a copy of the file
descriptor of the task and perform the connect(2) for it.
When used in combination with the seccomp notifier things are pretty
simple. The intercepted task itself is blocked in the seccomp code. That
code runs before the actual requested system call is performed. So the
task is blocked before any system call is performed. The seccomp
notifier will then notify the supervising process which holds the
seccomp notifier fd.
The supervisor can now call pidfd_getfd() while the target process is
blocked and steal the file descriptor. It can then perform whatever
operation it wants on that file descriptor and then tell seccomp to
either return a specific return value to the task once it is unblocked
or even continue the task using the SECCOMP_USER_NOTIF_FLAG_CONTINUE
flag.
One of the most useful things for pidfd_getfd() is that the target task
from which the caller is about to steal a file descriptor doesn't need
to be blocked or stopped. But that makes it possible for the target
process to be in the middle of a read/write/getdents/seek system call
while the caller is stealing the file on which that
read/write/getdents/seek was issued and issuing a concurrent
read/write/getdents/seek system call:
P1 P2
getdents(fd)
-> fdget_pos()
{
* @file->f_count == 1
* @current->files->count == 1
=> not taking @file->f_pos_lock
}
fd = pidfd_getfd(fd)
-> __pidfd_fget()
-> fget_task() ----> f_count = 2
-> receive_fd()
-> get_file() --> f_count = 3
-> fd_install()
-> fput() ---------> f_count = 2
getdents(fd)
-> fdget_pos()
{
* @file->f_count == 1
* @file->f_count == 2
=> taking @file->f_pos_lock and bumping @file->f_count = 3
}
-> vfs_readdir() -> vfs_readdir()
-> fdput() -> fdput()---------> f_count = 2
Although I'm not happy about it, I'm somewhat confident that this
analysis is correct but that the race is hard to hit in real life but
with some ingenuity it might be possible to make it more reliable.
However, I was lazy and introduced a luscious 10 second delay after
fdget_pos() succeeded into vfs_read() that was triggerable by passing -1
as the buffer size to the read() system call. I then used the very very
ugly program in [4] to enforce the order illustrated above. Lastly, I
wrote a bpftrace program which attached a kretfunc to __fdget_pos() and
a kfunc and a kretfunc to vfs_read(). The bpftrace program would only
trigger if the target file with a specific inode number was read:
Attaching 3 probes...
fdget_pos() on file pointer 0xffff8b3500d6a300: name(stealme) | i_ino(1591) | pid(9690) FDPUT_POS_UNLOCK(0), count(1) => mutex not acquired
vfs_read() on file pointer 0xffff8b3500d6a300: pid 9690 started reading from name(stealme) | i_ino(1591)
fdget_pos() on file pointer 0xffff8b3500d6a300: name(stealme) | i_ino(1591) | pid(9691) FDPUT_POS_UNLOCK(2), count(2) => mutex acquired
vfs_read() on file pointer 0xffff8b3500d6a300: pid 9691 started reading from name(stealme) | i_ino(1591)
vfs_read() on file pointer 0xffff8b3500d6a300: pid 9690 finished reading from name(stealme) | i_ino(1591)
vfs_read() on file pointer 0xffff8b3500d6a300: pid 9691 finished reading from name(stealme) | i_ino(1591)
I thought about various ways to fix this such as introducing some
mechanism to refuse pidfd_getfd() if the target process is in the middle
of an fdget_pos() protected system call with file count being one up to
just not caring about it at all. But it is pretty nasty to leave this
race open and it feels like something that'll bite us later anyway.
Plus, with io_uring having to acquire f_pos_lock unconditionally anyway
for getdents support I'm not sure that deviation in locking semantics
here is worth keeping. So remove the locking optimization for file count
being one. We'll see if this has a significant performance impact.
This survives xfstests and LTP.
Link: https://github.com/rr-debugger/rr [1]
Link: https://github.com/opencontainers/runc [2]
Link: https://brauner.io/2020/07/23/seccomp-notify.html [3]
Link: https://gist.github.com/brauner/599d31048c8adcb3aa0c537b76c89e12 [4]
Fixes: 8649c322f75c ("pid: Implement pidfd_getfd syscall")
Cc: stable(a)vger.kernel.org
Signed-off-by: Christian Brauner <brauner(a)kernel.org>
---
---
fs/file.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index 7893ea161d77..35c62b54c9d6 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -1042,10 +1042,8 @@ unsigned long __fdget_pos(unsigned int fd)
struct file *file = (struct file *)(v & ~3);
if (file && (file->f_mode & FMODE_ATOMIC_POS)) {
- if (file_count(file) > 1) {
- v |= FDPUT_POS_UNLOCK;
- mutex_lock(&file->f_pos_lock);
- }
+ v |= FDPUT_POS_UNLOCK;
+ mutex_lock(&file->f_pos_lock);
}
return v;
}
---
base-commit: 6eaae198076080886b9e7d57f4ae06fa782f90ef
change-id: 20230724-vfs-fdget_pos-c6540e3ed7d9
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> vmlinuz-6.3.7-200.fc38.x86_64 and vmlinuz-6.3.8-200.fc38.x86_64
>
> in the switch tv channel to another vlc stay blocked and and the loading of firmware newer ending. power must be switch to off.
> from dmesg:
>
> dvb-tuner-si2141-a10-01.fw
> dvb-demod-si2168-d60-01.fw
> firmware version: D 6.0.13
>
> restart of dvb modules is impossible, They stay working.
>
> kernel 6.3.5-200.fc38.x86_64 works OK. I don't how works kernel 6.3.6-200.fc38.x86_64
>
> this same error is in vmlinuz-6.3.5-200.fc38.x86_64 and earliers but there is the occurence accesptable.
>
> listing from 6.3.5 kernel:
>
> [ 3378.026035] si2168 7-0064: firmware version: D 6.0.13
> [ 3431.891579] si2168 7-0064: downloading firmware from file 'dvb-demod-si2168-d60-01.fw'
> [ 3434.037278] usb 1-4: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110
> [ 3434.037289] si2168 7-0064: firmware download failed -110
> [ 3436.085265] usb 1-4: dvb_usb_v2: usb_bulk_msg() failed=-110
>
> lsmod |grep dvb
> dvb_usb_dvbsky 32768 2
> dvb_usb_v2 57344 1 dvb_usb_dvbsky
> m88ds3103 49152 1 dvb_usb_dvbsky
> dvb_core 192512 3 dvb_usb_v2,m88ds3103,dvb_usb_dvbsky
> m
>
> modprobe -r dvb_usb_dvbsky
> modprobe: FATAL: Module dvb_usb_dvbsky is in use.
>
> ?????? The problem in dvb_usb_dvbsky or firmware ?????
>
> The answer from https://bugzilla.rpmfusion.org was:
>
> If it was working with previous kernel this is likely a kernel regression.
> please forward to the dvb sub-system maintainers.
>
> this problen insist a long time (years), but not too horible
See Bugzilla for the full thread and attached dmesg and lsusb.
Thorsten: The reporter can't perform bisection for he has problem
compiling his own vanilla kernel (see comment 8 on the Bugzilla
ticket, albeit with translated make(1) output). Can you take a look on
it?
Anyway, I'm adding it to regzbot (as stable-specific regression
for now):
#regzbot introduced: v6.3.5..v6.3.7 https://bugzilla.kernel.org/show_bug.cgi?id=217566
#regzbot title: switching TV channel causes VLC and firmware loading hang
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217566
--
An old man doll... just what I always wanted! - Clara
Hi Greg,
On 06.06.23 08:45, Greg KH wrote:
>>
>> Lino, it looks like this regression is caused by (backported) commit of yours.
>> Would you like to take a look on it?
>>
>> Anyway, telling regzbot:
>>
>> #regzbot introduced: 51162b05a44cb5
>
> There's some tpm backports to 5.15.y that were suspect and I'll look
> into reverting them and see if this was one of the ones that was on that
> list. Give me a few days...
>
Could you please consider to apply (mainline) commit 0c7e66e5fd69 ("tpm, tpm_tis: Request threaded
interrupt handler") to 5.15.y?
As Chris confirmed it fixes the regression caused by 51162b05a44cb5 ("tpm, tpm_tis: Claim locality
before writing interrupt registers").
Commit 0c7e66e5fd69 is also needed for 5.10.y, 6.1.y and 6.3.y.
Best regards,
Lino
From: Walter Chang <walter.chang(a)mediatek.com>
Due to the fact that the use of `writeq_relaxed()` to program CVAL is
not guaranteed to be atomic, it is necessary to disable the timer before
programming CVAL.
However, if the MMIO timer is already enabled and has not yet expired,
there is a possibility of unexpected behavior occurring: when the CPU
enters the idle state during this period, and if the CPU's local event
is earlier than the broadcast event, the following process occurs:
tick_broadcast_enter()
tick_broadcast_oneshot_control(TICK_BROADCAST_ENTER)
__tick_broadcast_oneshot_control()
___tick_broadcast_oneshot_control()
tick_broadcast_set_event()
clockevents_program_event()
set_next_event_mem()
During this process, the MMIO timer remains enabled while programming
CVAL. To prevent such behavior, disable timer explicitly prior to
programming CVAL.
Fixes: 8b82c4f883a7 ("clocksource/drivers/arm_arch_timer: Move MMIO timer programming over to CVAL")
Cc: stable(a)vger.kernel.org
Signed-off-by: Walter Chang <walter.chang(a)mediatek.com>
---
drivers/clocksource/arm_arch_timer.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index e733a2a1927a..7dd2c615bce2 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -792,6 +792,13 @@ static __always_inline void set_next_event_mem(const int access, unsigned long e
u64 cnt;
ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
+
+ /* Timer must be disabled before programming CVAL */
+ if (ctrl & ARCH_TIMER_CTRL_ENABLE) {
+ ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
+ arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
+ }
+
ctrl |= ARCH_TIMER_CTRL_ENABLE;
ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
--
2.18.0