2024年9月20日 02:58,Boqun Feng wrote:
>
> On Thu, Sep 19, 2024 at 09:57:12PM +0800, Alan Huang wrote:
> [...]
>>>
>>> I think you're right. (Although the node will be eventually deleted at
>>> cleanup_hazptr_context(), however there could be a lo
2024年9月19日 15:10,Boqun Feng wrote:
>
> On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
>> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>>
>>> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
>>> *tree,
>>> +
2024年9月19日 15:10,Boqun Feng wrote:
>
> On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
>> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>>
>>> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
>>> *tree,
>>> +
2024年9月19日 15:10,Boqun Feng wrote:
>
> On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
>> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>>
>>> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
>>> *tree,
>>> +
2024年9月17日 22:33,Boqun Feng wrote:
>
> Hazard pointers [1] provide a way to dynamically distribute refcounting
> and can be used to improve the scalability of refcounting without
> significant space cost.
>
> Hazard pointers are similar to RCU: they build the synchronization
> between two part,
* Li, Fei1 (fei1...@intel.com) wrote:
> > -Original Message-
> > From: Dr. David Alan Gilbert
> > Sent: Friday, July 19, 2024 1:44 AM
> > To: Li, Fei1
> > Cc: linux-kernel@vger.kernel.org; virtualizat...@lists.linux.dev
> > Subject: Re: [PA
* Fei Li (fei1...@intel.com) wrote:
> On 2024-05-18 at 00:12:46 +, Dr. David Alan Gilbert wrote:
> > * li...@treblig.org (li...@treblig.org) wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > It doesn't look like this was ever used.
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> It doesn't look like this was ever used.
>
> Build tested only.
>
> Signed-off-by: Dr. David Alan Gilbert
Ping
> ---
> drivers/virt/acrn/irqfd.c | 2 --
> 1 f
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> Commit 8788ca164eb4b ("ftrace: Remove the legacy _ftrace_direct API")
> stopped setting the 'ftrace_direct_func_count' variable, but left
> it around. Clean it u
:
>
> /proc/2821/net/dev_snmp6/eth0
>
> This looks exactly like something coming from userspace and making it
> into /proc, so the filter function doesn't belong to kernel/module/internal.h
You mean like:
[24180.292204] tuxthe: renamed from tuxthe🐧
root@dalek:/home/dg# ls /sys/class/net/
enp5s0 lo tuxthe tuxthe🐧 tuxthe🖊 virbr0 virbr1
?
Dave
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
would be good to confirm.
> Signed-off-by: Masami Hiramatsu (Google)
Reviewed-by: Alan Maguire
> ---
> include/linux/btf.h| 24 +
> kernel/bpf/btf.c | 115 +
On 04/10/2023 22:43, Steven Rostedt wrote:
> On Wed, 4 Oct 2023 22:35:07 +0100
> Alan Maguire wrote:
>
>> One thing we've heard from some embedded folks [1] is that having
>> kernel BTF loadable as a separate module (rather than embedded in
>> vmlinux) would h
n the to-do list?
Not necessarily for this particular use-case (since there are
complications with trace data as you describe), but just trying to make
sure we can remove barriers to BTF adoption where possible.
Thanks!
Alan
[1]
https://lore.kernel.org/bpf/CAHBbfcUkr6fTm2X9GNsFNqV75fTG=a
--
You might mention that this is essentially a reversion of commit
d18dcfe9860e ("USB: gadgetfs: Fix race between mounting and
unmounting").
Alan Stern
> drivers/usb/gadget/legacy/inode.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/usb/ga
06,6 +406,7 @@ static const struct usb_device_id usb_quirk_list[] = {
>
> /* Realtek hub in Dell WD19 (Type-C) */
> { USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
> + { USB_DEVICE(0x0bda, 0x5487), .driver_info = USB_QUIRK_RESET_RESUME },
>
>
On Tue, Apr 20, 2021 at 03:14:56PM +0800, Chris Chiu wrote:
> On Mon, Apr 19, 2021 at 10:19 PM Alan Stern wrote:
> >
> > On Mon, Apr 19, 2021 at 01:11:38AM -0400, Chris Chiu wrote:
> > > Sorry that I didn't make myself clear. I found that if I applied
> >
y: Colin Ian King
> ---
Acked-by: Alan Stern
> drivers/usb/storage/datafab.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/usb/storage/datafab.c b/drivers/usb/storage/datafab.c
> index 588818483f4b..bcc4a2fad863 100644
> --- a/drivers/usb/storage/datafab
> expect the runtime PM to work for all devices connected to the hub either.
> Is that right? If what I proposed in the patch can not get better
> result than existing
> quirk, I think using the RESET_RESUME would be a better option. Any
> suggestions?
Try the RESET_RESUME quirk and see how well it works with runtime
suspend.
Alan Stern
bind
> callback.
>
> To fix this, move the synchronize_irq() emulation code to dummy_pullup
> so that it runs before unbind. Also, add a comment explaining why it is
> necessary to have it there.
>
> Suggested-by: Alan Stern
> Reported-by: syzbot+eb4674092e6cc8d9e
On Sat, Apr 17, 2021 at 02:48:22PM +0800, liulongfang wrote:
> On 2021/4/16 23:20, Alan Stern wrote:
> > On Fri, Apr 16, 2021 at 10:03:21AM +0800, liulongfang wrote:
> >> The current method is an improved method of the above patch.
> >> This patch just make it skip re
On Fri, Apr 16, 2021 at 10:35:20PM +0530, Anirudh Rayabharam wrote:
> On Fri, Apr 16, 2021 at 11:27:34AM -0400, Alan Stern wrote:
> > Actually, I wanted to move this emulation code into a new subroutine and
> > then call that subroutine from _both_ places. Would you like to writ
On Fri, Apr 16, 2021 at 09:24:30AM +0800, Chris Chiu wrote:
> On Fri, Apr 16, 2021 at 2:46 AM Alan Stern wrote:
> >
> > On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> > > One thing worth mentioning here, I never hit the hub_ext_port_status -71
> > >
On Fri, Apr 16, 2021 at 09:21:12AM +0200, Dmitry Vyukov wrote:
> On Thu, Apr 15, 2021 at 10:59 PM Alan Stern wrote:
> >
> > On Tue, Apr 13, 2021 at 07:11:11PM +0200, Dmitry Vyukov wrote:
> > > Yes, this is possible:
> > > http://bit.do/syzbot#syzkaller-reproducers
On Fri, Apr 16, 2021 at 11:10:35AM +0530, Anirudh Rayabharam wrote:
> On Tue, Apr 13, 2021 at 12:13:11PM -0400, Alan Stern wrote:
> > Maybe we can test this reasoning by putting a delay just before the call
> > to dum->driver->setup. That runs in the timer handler, so it
On Fri, Apr 16, 2021 at 10:03:21AM +0800, liulongfang wrote:
> On 2021/4/15 22:43, Alan Stern wrote:
> > On Thu, Apr 15, 2021 at 08:22:38PM +0800, Longfang Liu wrote:
> >> When the number of ports on the USB hub is 0, skip the registration
> >> operation of the USB
On Tue, Apr 13, 2021 at 07:11:11PM +0200, Dmitry Vyukov wrote:
> On Tue, Apr 13, 2021 at 6:57 PM Alan Stern wrote:
> >
> > On Tue, Apr 13, 2021 at 06:47:47PM +0200, Dmitry Vyukov wrote:
> > > On Tue, Apr 13, 2021 at 6:13 PM Alan Stern
> > > wrote:
> > >
t; I don't know how to SetPortFeature() with setting the status change bit only.
You can't. Only the hub itself can set the wPortChange bits.
> Or maybe it's just some kind of timing issue of the
> idle/suspend/resume signaling.
Not timing. It's because you woke the system up from the attached
keyboard.
Alan Stern
t actually do what the
description says. The patch doesn't remove the call to usb_add_hcd
for the USB-3 bus. If you simply skipped that call (and the
corresponding call to usb_remove_hcd) when there are no
ports on the root hub, none of the stuff in this patch would be needed.
Alan Stern
&
Arnd has already looked at this:
https://marc.info/?t=15882824021&r=1&w=2
I thought we had arrived at an acceptable (though not great) solution,
but he never posted any finished patches. :-(
Alan Stern
> UBSAN: array-index-out-of-bounds in drivers/usb/host/ehci-hub.c:893:16
- else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)
- status = set_port_feature(hub->hdev, port1,
- USB_PORT_FEAT_SUSPEND);
- else {
+ else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)
{
+ if (hub->hdev->quirks & USB_QUIRK_NO_SUSPEND)
+ status = -EIO;
+ else
+ status = set_port_feature(hub->hdev, port1,
+ USB_PORT_FEAT_SUSPEND);
+ } else {
really_suspend = false;
status = 0;
}
But I would prefer to find a way to make port suspend actually work,
instead of giving up on it.
Alan Stern
On Tue, Apr 13, 2021 at 06:47:47PM +0200, Dmitry Vyukov wrote:
> On Tue, Apr 13, 2021 at 6:13 PM Alan Stern wrote:
> > Hopefully this patch will make the race a lot more likely to occur. Is
> > there any way to tell syzkaller to test it, despite the fact that
> > syzkaller d
ze_irq emulation code in dummy_pullup.
Maybe we can test this reasoning by putting a delay just before the call
to dum->driver->setup. That runs in the timer handler, so it's not a
good place to delay, but it may be okay just for testing purposes.
Hopefully this patch will make the
On Tue, Apr 13, 2021 at 03:52:14PM +0800, Chris Chiu wrote:
> On Mon, Apr 12, 2021 at 11:12 PM Alan Stern wrote:
> >
> > On Mon, Apr 12, 2021 at 11:00:06PM +0800, chris.c...@canonical.com wrote:
> > > The USB_PORT_FEAT_SUSPEND is not really necessary due to the
> >
hdev, port1,
> - USB_PORT_FEAT_SUSPEND);
> + if (udev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND)
You should test hub->hdev->quirks, here, not udev->quirks. The quirk
belongs to the Realtek hub, not to the device that's plugged into the
hub.
Alan Stern
for a root hub,
> we can fix it easily without affect other root hub
>
> Signed-off-by: Chunfeng Yun
Acked-by: Alan Stern
> ---
> drivers/usb/core/hub.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/core/hub.h b/driv
spend some time figuring out what is really going wrong. I have already
explained why this patch is not the right thing to do.
You have to determine why the poweroff callback in hcd-pci.c (which
points to hcd_pci_suspend) isn't getting called. That's the real
explanation for your pr
controller of Kunpeng920 needs to skip
> the read operation of the SBRN register.
>
> Signed-off-by: Longfang Liu
> ---
Acked-by: Alan Stern
> Changes in v4:
> - Modify the code implementation.
>
> Changes in v3:
> - Fix some code style issues.
>
t, along with an associated lookup
routine, when there are only two entries. The total amount of code will
be smaller if you just add a check for the Kunpeng920 controller to
the existing check for the STMICRO controller.
Alan Stern
Saenz Julienne
wrote:
>
> Hi Alan,
>
> On Thu, 2021-04-01 at 11:23 -0400, Alan Cooper wrote:
> > Nicolas,
> >
> > Sorry, I just noticed this thread.
> > This is a known bug in some newer Arasan cores.
> > The problem happens when the difference between th
, it is verified by the stress test of sleep
> wake up in S4 mode for a long time that this problem no longer occurs.
Something else must be happeneing, something you don't understand.
Alan Stern
> Signed-off-by: Longfang Liu
> ---
> drivers/usb/core/hcd-pci.c | 7 ++-
>
On Wed, Mar 31, 2021 at 02:03:08PM -0700, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 416dacb819f59180e4d86a5550052033ebb6d72c
> Author: Alan Stern
> Date: Wed Aug 21 17:27:12 2019 +
>
> HID: hidraw: Fix invalid read in hidraw_ioctl
>
Nicolas,
Sorry, I just noticed this thread.
This is a known bug in some newer Arasan cores.
The problem happens when the difference between the core clock and the
bus clock is too great.
Limiting the clock to 200KHz minimum should be a good fix.
In my experience, it's only eMMC that needs the cloc
On Wed, Mar 31, 2021 at 08:20:56PM +0200, Maciej S. Szmigiero wrote:
> On 29.03.2021 17:22, Alan Stern wrote:
> > On Sat, Mar 27, 2021 at 04:55:20PM +0100, Maciej S. Szmigiero wrote:
> > > Hi,
> > >
> > > Is there any specific reason that URBs without U
On Tue, Mar 30, 2021 at 12:07:35PM +0300, Heikki Krogerus wrote:
> On Mon, Mar 29, 2021 at 02:49:46PM -0400, Alan Stern wrote:
> > On Mon, Mar 29, 2021 at 11:44:25AM +0300, Heikki Krogerus wrote:
> > > Introducing usb_for_each_port(). It works the same way as
> > > usb_
mutex_unlock(&usb_port_peer_mutex);
I have a feeling that it would be better to take and release this mutex
in usb_for_each_port (or its caller), so that it is held over the whole
loop.
Alan Stern
> +
> + return ret;
> +}
> +
> +/**
> + * usb_for_each_port - inter
On Mon, Mar 29, 2021 at 04:38:10PM +0800, liulongfang wrote:
> On 2021/3/26 23:28, Alan Stern wrote:
> > On Fri, Mar 26, 2021 at 04:54:56PM +0800, Longfang Liu wrote:
> >> When OHCI enters the S4 sleep state, the USB sleep process will call
> >> check_root_hub_sus
, that would be great.
Otherwise, I'll try to find time to work on it.
I would appreciate any effort you could make toward checking the code
in qh_completions(); I suspect that the checks it does involving
EHCI_LIST_END may not be right. At the very least, they should be
encapsulated in a macro so that they are easier to understand.
Alan Stern
least allow us to work around this problem:
In fact, as far as I know _all_ USB SD card readers send Media Changed
notifications on resume. Maybe there are some that don't, but I haven't
heard of any.
Alan Stern
+ clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> + spin_unlock_irqrestore(&ohci->lock, flags);
This is completely wrong. The hardware certainly remains accessible
when the root hub stops running. The HW_ACCESSIBLE flag should not be
cleared here.
And
On Thu, Mar 25, 2021 at 05:14:42PM +0200, Heikki Krogerus wrote:
> On Thu, Mar 25, 2021 at 10:41:09AM -0400, Alan Stern wrote:
> > On Thu, Mar 25, 2021 at 03:29:21PM +0300, Heikki Krogerus wrote:
> > > Introducing usb_for_each_port(). It works the same way as
> > > usb_
+ if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
Don't you need some sort of locking or refcounting here? What would
happen if this hub got removed while the routine was running?
Alan Stern
rmally.
>
> But you can not have a USB3 hub with no ports, isn't that against
> against the USB spec? How does this device pass the USB-IF
> certification?
>
> > thanks, therefore, in order to reduce the severity of the log,
> > we hope to lower the level of this log.
>
> You did not reduce the severity at all, everyone can still see it.
>
> Please try fixing your hardware :
Alternatively, you could change the xhci-hcd driver. Make it skip
registering the USB-3 root hub if that hub has no ports.
But don't change these log messages. They describe real errors, so they
should be actual error messages.
Alan Stern
On Mon, Mar 22, 2021 at 05:59:17PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-03-22 12:42:00 [-0400], Alan Stern wrote:
> > What happens on RT systems? Are they smart enough to avoid the whole
> > problem by enabling interrupts during _all_ callbacks?
>
> tl;dr: Yes.
;threadirqs").
What happens on RT systems? Are they smart enough to avoid the whole
problem by enabling interrupts during _all_ callbacks?
Alan Stern
hence it's
> okay to have a bit clunky workaround for it.
>
> Fixes: c3590c7656fb ("usb: host: ehci-tegra: Remove the driver")
> Reported-by: kernel test robot
> Signed-off-by: Dmitry Osipenko
Acked-by: Alan Stern
> ---
> drivers/usb/host/Kconfig | 1 +
&
On Wed, Mar 17, 2021 at 05:25:20PM +0900, taehyun cho wrote:
> On Mon, Mar 15, 2021 at 10:13:35AM -0400, Alan Stern wrote:
> > On Mon, Mar 15, 2021 at 04:43:17PM +0900, taehyun cho wrote:
> > > 'pm_runtime_set_active' sets a flag to describe rumtime status.
> > &
alls won't fix the error.
You need to determine why the parent platform device .usb isn't
active when the dwc3 probe and resume routines are called. It seems
likely that there is a bug in the platform device's driver.
Alan Stern
> Signed-off-by: taehyun cho
>
On Fri, Mar 12, 2021 at 07:26:31PM +0100, Sedat Dilek wrote:
> On Fri, Mar 12, 2021 at 7:05 PM Alan Stern wrote:
> > Although it's not conclusive, this log seems to indicate that ata_id
> > is the only program causing resets. Have you tried preventing the
> > ata_id
r, cmd 85, prog pool-udisksd
> [Fri Mar 12 18:36:50 2021] SCSI ioctl error, cmd 85, prog pool-udisksd
> [Fri Mar 12 18:36:50 2021] SCSI ioctl error, cmd 85, prog pool-udisksd
> [Fri Mar 12 18:36:50 2021] SCSI ioctl error, cmd 85, prog pool-udisksd
Although it's not conclusive, this log
On Tue, Mar 09, 2021 at 08:04:53PM -0800, Asutosh Das (asd) wrote:
> On 3/9/2021 7:14 PM, Alan Stern wrote:
> > On Tue, Mar 09, 2021 at 07:04:34PM -0800, Asutosh Das (asd) wrote:
> > > Hello
> > > I & Can (thanks CanG) debugged this further:
> > >
> &g
m_put_device() and starts a timer. And then driver_probe_device()
> invoked from __device_attach_async_helper context reduces the
> link->rpm_active to 1 thus enabling the supplier to suspend before the
> consumer suspends.
> I don't see a way around this. Please let me know if yo
On Mon, Mar 08, 2021 at 10:52:05AM +0800, Chunfeng Yun wrote:
> Add a new function to convert bInterval into the time expressed
> in 1us unit.
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: move kerneldoc next to function's definition suggested by Alan
> ---
> dri
On Sun, Mar 07, 2021 at 05:57:39PM +0100, Sedat Dilek wrote:
> On Sun, Mar 7, 2021 at 4:46 PM Alan Stern wrote:
> >
> > On Sat, Mar 06, 2021 at 09:49:00PM +0100, Sedat Dilek wrote:
> >
> > > For testing purposes, I stopped these systemd services:
n configure it so that it won't send
the problem-causing commands.
Alan Stern
at type of device already has a quirk entry built
into the kernel. You can find it by searching for "174c" in the kernel
source file drivers/usb/storage/unusual_devs.h.
> Thanks Alan for all the hints and tips in the topic "usb-storage and
> quirks" and your patience.
Yo
onsumers, it all goes back to normal, which is kind of expected. I tried
> resuming the consumer and the supplier is resumed and the supplier is
> suspended when all the consumers are suspended.
>
> Any pointers on this issue please?
>
> @Bart/@Alan - Do you've any pointer
On Fri, Mar 05, 2021 at 08:41:40PM +0100, Sedat Dilek wrote:
> On Fri, Mar 5, 2021 at 8:30 PM Alan Stern wrote:
> > Okay, that indicates the ATA commands are being sent not by the kernel
> > but by some program. I'm not sure how you can easily find out which
> > progra
st thing to do is turn them off one by one until
you find the one responsible.
Alan Stern
On Fri, Mar 05, 2021 at 08:05:49PM +0100, Sedat Dilek wrote:
> On Fri, Mar 5, 2021 at 5:07 PM Alan Stern wrote:
> > Don't worry about trying to decode the output. To me it looks like the
> > drive crashes and needs to be reset at times when the computer sends it
> >
On Fri, Mar 05, 2021 at 10:26:50AM -0800, Paul E. McKenney wrote:
> On Fri, Mar 05, 2021 at 04:41:49PM +0100, Björn Töpel wrote:
> > On 2021-03-05 16:36, Alan Stern wrote:
> > > On Fri, Mar 05, 2021 at 11:28:23AM +0100, Björn Töpel wrote:
> > > > From: Björn Töpel
On Fri, Mar 05, 2021 at 09:12:30AM +0800, Boqun Feng wrote:
> On Thu, Mar 04, 2021 at 11:11:42AM -0500, Alan Stern wrote:
> > Forget about local variables for the time being and just consider
> >
> > dep ; [Plain] ; rfi
> >
> > For example:
> >
>
On Fri, Mar 05, 2021 at 01:09:16PM +0100, Sedat Dilek wrote:
> On Mon, Mar 1, 2021 at 4:53 PM Alan Stern wrote:
> [ ... ]
> > You can use usbmon on bus 4 to record the USB traffic. It may indicate
> > why the resets occur.
> >
>
> Hi Alan,
>
> I followe
On Fri, Mar 05, 2021 at 11:28:23AM +0100, Björn Töpel wrote:
> From: Björn Töpel
>
> A misspelled invokation of git-grep, revealed that
---^
Smetimes my brain is a little slow... Do you confirm that this is a
joke?
Alan
the endpoint
> + * @speed: The speed that the endpoint works as
> + *
> + * Function returns the interval expressed in 1us unit for servicing
> + * endpoint for data transfers.
> + */
> +unsigned int usb_decode_interval(const struct usb_endpoint_descriptor *epd,
> + enum usb_device_speed speed);
As a general rule, I believe people expect to find the kerneldoc for a
function next to the function's definition, not next to the declaration
in a header file.
Alan Stern
On Thu, Mar 04, 2021 at 11:05:15AM -0800, Paul E. McKenney wrote:
> On Thu, Mar 04, 2021 at 10:35:24AM -0500, Alan Stern wrote:
> > On Wed, Mar 03, 2021 at 09:04:07PM -0800, Paul E. McKenney wrote:
> > > On Wed, Mar 03, 2021 at 10:21:01PM -0500, Alan Stern wrote:
> > > &
oesn't see any control
dependency. But CPUs do see control dependencies whenever there is a
conditional branch, whether the branch is taken or not, and so they will
never reorder B before A.
One last thing to think about: My original assessment or Björn's problem
wasn't right, because the dep in (dep ; rfi) doesn't include control
dependencies. Only data and address. So I believe that the LKMM
wouldn't consider A to be ordered before B in this example even if x
was nonzero.
Alan
On Wed, Mar 03, 2021 at 09:04:07PM -0800, Paul E. McKenney wrote:
> On Wed, Mar 03, 2021 at 10:21:01PM -0500, Alan Stern wrote:
> > On Wed, Mar 03, 2021 at 02:03:48PM -0800, Paul E. McKenney wrote:
> > > On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
>
On Wed, Mar 03, 2021 at 02:03:48PM -0800, Paul E. McKenney wrote:
> On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
> > On Wed, Mar 03, 2021 at 09:40:22AM -0800, Paul E. McKenney wrote:
> > > On Wed, Mar 03, 2021 at 12:12:21PM -0500, Alan Stern wrote:
> >
On Thu, Mar 04, 2021 at 09:26:31AM +0800, Boqun Feng wrote:
> On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
> > Which brings us back to the case of the
> >
> > dep ; rfi
> >
> > dependency relation, where the accesses in the middle are plain an
On Wed, Mar 03, 2021 at 06:37:36PM +0100, maranget wrote:
>
>
> > On 3 Mar 2021, at 18:12, Alan Stern wrote:
> >
> > On Tue, Mar 02, 2021 at 03:50:19PM -0800, Paul E. McKenney wrote:
> >> On Tue, Mar 02, 2021 at 04:14:46PM -0500, Alan Stern wrote:
> >
On Wed, Mar 03, 2021 at 09:40:22AM -0800, Paul E. McKenney wrote:
> On Wed, Mar 03, 2021 at 12:12:21PM -0500, Alan Stern wrote:
> > Local variables absolutely should be treated just like CPU registers, if
> > possible. In fact, the compiler has the option of keeping local
>
On Tue, Mar 02, 2021 at 03:50:19PM -0800, Paul E. McKenney wrote:
> On Tue, Mar 02, 2021 at 04:14:46PM -0500, Alan Stern wrote:
> > This result is wrong, apparently because of a bug in herd7. There
> > should be control dependencies from each of the two loads in P0 to each
ct them.
Maybe Luc can find some time to check whether this really is a bug and
if it is, fix it.
> In commit c7f2e3cd6c1f ("perf: Optimize ring-buffer write by depending
> on control dependencies") removes the corresponding smp_mb(), and also
> the circular buffer in circular-buffers.txt (pre commit 6c43c091bdc5
> ("documentation: Update circular buffer for
> load-acquire/store-release")) is missing the smp_mb() at the
> producer-side.
>
> I'm trying to wrap my head around why it's OK to remove the smp_mb()
> in the cases above? I'm worried that the current XDP socket ring
> implementation (which is missing smp_mb()) might be broken.
Because of the control dependencies, the smp_mb isn't needed. The
dependencies will order both of the stores after both of the loads.
Alan Stern
On Fri, Feb 26, 2021 at 06:53:52AM +0100, Christoph Hellwig wrote:
> On Thu, Feb 25, 2021 at 11:35:57AM -0500, Alan Stern wrote:
> > This thread seems to have fallen through the cracks. Maybe now would be
> > a good time to address the problem (since we originally planned to fix
l good.
>
> For the first time I used badblocks from e2fsprogs Debian package:
>
> root# LC_ALL=C badblocks -v -p 1 -s /dev/sdc -o
> badblocks-v-p-1-s_dev-sdc_$(uname -r).txt
> Checking blocks 0 to 976762583
> Checking for bad blocks (read-only test): done
> Pass completed, 0 bad blocks found. (0/0/0 errors)
>
> Good, there is no file-system corruption or badblocks or even a hardware
> damage.
>
> Anyway, feedback is much appreciated.
>
> Thanks.
You can use usbmon on bus 4 to record the USB traffic. It may indicate
why the resets occur.
Alan Stern
On Sat, Feb 27, 2021 at 11:38:08AM +0800, liulongfang wrote:
> On 2021/2/27 0:30, Alan Stern wrote:
> > On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote:
> >> Our current XHCI hardware controller has been customized to only
> >> support USB 2.0 ports. When us
hat sentence makes no sense at all. An EHCI controller device is a
piece of hardware. How can an xHCI driver, which is a piece of
software, create a piece of hardware?
Alan Stern
On Fri, Feb 26, 2021 at 02:13:36PM +0600, Sabyrzhan Tasbolatov wrote:
> On Thu, 25 Feb 2021 10:59:14 -0500, Alan Stern wrote:
> > Won't this cause silent errors?
>
> Agree. But there are already such as cases like in:
>
> // net/bluetooth/hidp/core.c
> st
This thread seems to have fallen through the cracks. Maybe now would be
a good time to address the problem (since we originally planned to fix
it in 5.11!).
The questions listed below are pretty self-contained, although the rest
of the discussion isn't. But I never received any answers.
> 0);
> + u32 len = ((report->size - 1) >> 3) + 1 + (report->id > 0);
> +
> + return len > HID_MAX_BUFFER_SIZE ? HID_MAX_BUFFER_SIZE : len;
Won't this cause silent errors?
How about instead just rejecting any device which includes a report
whose length is too big (along with an line in the system log explaining
what's wrong)?
Alan Stern
nández Rojas
> ---
> v2: change flag name and improve documentation as suggested by Alan Stern.
>
> drivers/usb/host/ehci-platform.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-platform.c
> b/drivers/usb/host/ehci-platform.c
> ind
On Tue, Feb 23, 2021 at 05:04:57PM +0100, Álvaro Fernández Rojas wrote:
> Hi Alan,
>
> > El 23 feb 2021, a las 16:54, Alan Stern
> > escribió:
> >
> > On Tue, Feb 23, 2021 at 04:50:04PM +0100, Álvaro Fernández Rojas wrote:
> >> Over-current reporting is
t how to use it.
When you say that the bcm63xx doesn't support over-current reporting,
what exactly do you mean? Do you mean that sometimes the hardware turns
on the over-current bit when an over-current isn't actually present? Or
do you mean something else?
Alan Stern
> +
>
On Tue, Feb 16, 2021 at 10:30:52AM +0900, Jung Daehwan wrote:
> Hello, Alan
>
> On Mon, Feb 15, 2021 at 12:41:45PM -0500, Alan Stern wrote:
> > On Mon, Feb 15, 2021 at 11:38:58AM +0900, Daehwan Jung wrote:
> > > It seems pm_runtime_put calls runtime_idle call
ou think it is better? The advantage of pm_runtime_put is that
it allows the suspend to occur at a later time in a workqueue thread, so
the caller doesn't have to wait for the device to go into suspend.
Alan Stern
> Signed-off-by: Daehwan Jung
> ---
> drivers/usb/dwc3/gadget.c
ging in kunit_log_append(), it might make
sense to #define __kunit_fail_current_test() instead, i.e.
#define __kunit_fail_current_test(file, line, fmt, ...) \
do {\
kunit_set_failure(current->kunit_test); \
kunit_err(current->kunit_test, "%s:%d: " fmt, \
##__VA_ARGS__); \
} while (0)
> > + if (!buffer)
> > + return;
> > +
> > + va_start(args, fmt);
> > + vsnprintf(buffer, len, fmt, args);
> > + va_end(args);
> > +
> > + kunit_err(current->kunit_test, "%s:%d: %s", file, line, buffer);
To get kunit_err() to work, we'd need to "static inline"
kunit_log_append(). It's not a trivial function, but on the plus
side it doesn't call any other exported kunit functions AFAICT.
So while any of the above suggestions aren't intended to block
Daniel's work, does the above seem reasonable for a follow-up
series to get UBSAN working with module-based KUnit? Thanks!
Alan
kerfuffle with applying them
> previously and the series was reverted.
>
> This revives the series but makes the kunit_fail_current_test() function
> take a format string and logs the file and line number of the failing
> code, addressing Alan Maguire's comments on the previous
On Tue, 9 Feb 2021, Daniel Latypov wrote:
> On Tue, Feb 9, 2021 at 9:26 AM Alan Maguire wrote:
> >
> > On Fri, 5 Feb 2021, Daniel Latypov wrote:
> >
> > > From: Uriel Guajardo
> > >
> > > Add a kunit_fail_current_test() function to fail the cur
On Fri, 5 Feb 2021, Daniel Latypov wrote:
> From: Uriel Guajardo
>
> Add a kunit_fail_current_test() function to fail the currently running
> test, if any, with an error message.
>
> This is largely intended for dynamic analysis tools like UBSAN and for
> fakes.
> E.g. say I had a fake ops stru
a0 drivers/usb/core/message.c:153
> go7007_usb_onboard_write_interrupt+0x26a/0x340
> drivers/media/usb/go7007/go7007-usb.c:735
It looks like the go7007 driver isn't very careful about checking that
the endpoints it uses have the right types. In particular, this bug was
caused by not checking that ep2 is a control endpoint (highly unusual to
have a control endpoint other than 0, but allowed).
Alan Stern
1 - 100 of 8836 matches
Mail list logo