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
>
ine]
> port100_probe+0xd4f/0x1600 drivers/nfc/port100.c:1567
I don't understand this driver very well. It looks like the problem
stems from the fact that port100_send_frame_async() submits two URBs,
but port100_send_cmd_sync() only waits for one of them to complete. The
other URB may then still be active when the driver tries to reuse it.
Maybe someone who's more familiar with the port100 driver can fix the
problem.
Alan Stern
ee you used for building did not include
the declarations of usb_control_msg_{send|recv}().
It's hard to tell exactly what that tree does contain, because the
github.com links embedded in the web page you mention above don't work.
Alan Stern
verting everything
> over to a sane, and checkable, api and remove a bunch of wrapper
> functions as well.
Suggestion: _read and _send are not a natural pair. Consider instead
_read and _write. _recv and _send don't feel right either, because it
both cases the host sends the control message -- the difference lies
in who sends the data.
Alan Stern
uccinct, although it wouldn't fit every
usage. For example,
#define pm_do_callback(dev, method) \
(dev->driver && dev->driver->pm && dev->driver->pm->callback ? \
dev->driver->pm->callback(dev) : 0)
Then the usage is something like:
ret = pm_do_callback(dev, prepare);
Would this be an overall improvement?
Alan Stern
On Wed, 2 Jan 2019, Michael S. Tsirkin wrote:
> On Wed, Jan 02, 2019 at 04:36:40PM -0500, Alan Stern wrote:
> > On Wed, 2 Jan 2019, Michael S. Tsirkin wrote:
> >
> > > So as explained in Documentation/memory-barriers.txt e.g.
> > > a load followed by a st
e.g. smp_rmb is a nop.
This should be easy to fix with an architecture-specific override.
Alan Stern
> Sending out for early feedback/flames.
>
> Michael S. Tsirkin (4):
> include/linux/compiler*.h: fix OPTIMIZER_HIDE_VAR
> include/linux/compiler.h: allow memory operand
ol URBs. The DVB driver in question
uses bulk transfers.
xhci-hcd, on the other hand, does not use these tasklets (it doesn't
set the HCD_BH bit in the hc_driver's .flags member).
Alan Stern
st? The post says that the testing was done on an x86_64
machine.
> Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr
> Von: "Alan Stern"
> An: "Josef Griebichler"
> Cc: "Mauro Carvalho Chehab" , "Greg Kroah-Hartman"
> , linux-...@vger.kernel.
dditional tcp load on raspberry.
>
> Unfortunately there's no usbmon or tshark on libreelec so I can't provide
> further logs.
Can you try running the same test on an x86_64 system?
Alan Stern
eduling parameters if needed, to adjust for
> > such use-cases (it was not really an admin choice before).
>
> Can't the ksoftirq patch be modified to only apply to the networking
> IRQ handling? That sounds less risky of affecting unrelated subsystems[1].
That might work. Or mo
On Mon, 8 Jan 2018, Mauro Carvalho Chehab wrote:
> Em Sun, 7 Jan 2018 10:41:37 -0500 (EST)
> Alan Stern escreveu:
>
> > On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote:
> >
> > > > > It seems that the original patch were designed to solve some IRQ
> >
to revert the kernel logic to prioritize latency instead of
> throughput.
It can't be done without pervasive changes to the USB subsystem, which
I would greatly prefer to avoid. Besides, this wouldn't really solve
the problem. Decreasing the latency for one device will cause it to be
increased for others.
Alan Stern
la kernel that gets plenty of video glitches?
Overall, this may be a very difficult problem to solve. The
4cd13c21b207 commit was intended to improve throughput at the cost of
increased latency. But then what do you do when the latency becomes
too high for the video subsystem to handle?
Alan Stern
ll our problems by defining the generic version
> thusly:
>
> void spin_unlock_wait(spinlock_t *lock)
> {
> if (spin_trylock(lock))
> spin_unlock(lock);
> }
How could this possibly be a generic version of spin_unlock_wait()?
It does noth
On Thu, 6 Jul 2017, Peter Zijlstra wrote:
> On Thu, Jul 06, 2017 at 12:49:12PM -0400, Alan Stern wrote:
> > On Thu, 6 Jul 2017, Paul E. McKenney wrote:
> >
> > > On Thu, Jul 06, 2017 at 06:10:47PM +0200, Peter Zijlstra wrote:
> > > > On Thu, Jul 06, 2017 a
I
> am confused, but I am not seeing it for any of them.
If somebody really wants the full spin_unlock_wait semantics and
doesn't want to interfere with other CPUs, wouldn't synchronize_sched()
or something similar do the job? It wouldn't be as efficient as
lock+unlock, but it also wouldn't affect other CPUs.
Alan Stern
On Mon, 3 Jul 2017, Paul E. McKenney wrote:
> On Mon, Jul 03, 2017 at 10:39:49AM -0400, Alan Stern wrote:
> > On Sat, 1 Jul 2017, Manfred Spraul wrote:
> >
> > > As we want to remove spin_unlock_wait() and replace it with explicit
> > > spin_lock()/spin_u
ld mention that it pairs with the
smp_store_release() from an earlier invocation of
nf_conntrack_all_unlock().
(Alternatively, you could make nf_conntrack_all_unlock() do a
lock+unlock on all the locks in the array, just like
nf_conntrack_all_lock(). But of course, that would be a lot less
efficient.)
Alan Stern
f_conntrack_locks_all,
by (a) the read will always see the write.
Similarly for (2), since nf_conntrack_all_lock() acquires
nf_conntrack_locks_all_lock before writing to nf_conntrack_locks_all,
and since nf_conntrack_lock() reads nf_conntrack_locks_all before
releasing nf_conntr
hat nobody except me likes
> this primitive, but to me spin_unlock_wait() looks like synchronize_rcu(() and
> sometimes it makes sense.
If it looks like synchronize_rcu(), why not actually use
synchronize_rcu()?
Alan Stern
> Including this particular case. task_work_run() is going to flush/destroy the
> ->task_works list, so it needs to wait until all currently executing "readers"
> (task_work_cancel()'s which have started before ->task_works was updated) have
> completed.
roblem. I am open to suggestions
> for a better fix.
The proper approach is to keep the allocation as it is, but _before_
deallocating the buffer, make sure that the interrupt buffer won't be
accessed any more. This may involve calling usb_kill_urb(), or
synchronize_irq(), or something similar.
Alan Stern
On Thu, 10 Nov 2016, Kai-Heng Feng wrote:
> Hi,
>
> On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote:
> > Oliver Neukum writes:
> >
> >> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
> >>
> >>> These problems could very well be cause
On Tue, 8 Nov 2016, Bjørn Mork wrote:
> Alan Stern writes:
>
> > On Tue, 8 Nov 2016, Kai-Heng Feng wrote:
> >
> >> Hi,
> >>
> >> On Mon, Nov 7, 2016 at 7:02 PM, Oliver Neukum wrote:
> >> > On Fri, 2016-11-04 at 17:57 +0800, Kai-Heng
-2: config 1 has an invalid interface number: 13 but max is
1
[3.862255] usb 2-2: config 1 has no interface number 0
[3.862256] usb 2-2: config 1 has no interface number 1
...
[8.295180] usb 2-2: Disable of device-initiated U1 failed.
[8.295322] usb 2-2: Disable of device-initiated U2 failed.
I get the impression that the device won't work properly with runtime
PM at all.
Alan Stern
the PM usage
counter of a device before probing its interfaces.
Alan Stern
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/net/usb/usbnet.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> inde
On Tue, 22 Mar 2016, Oliver Neukum wrote:
> On Tue, 2016-03-22 at 10:21 -0400, Alan Stern wrote:
> > I don't see any point in resuming the device just in order to collect
> > operating statistics. If it was already suspended then it wasn't
> > operating, so
On Tue, 22 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 15:30 -0400, Alan Stern wrote:
> > On Mon, 21 Mar 2016, Oliver Neukum wrote:
> >
>
> > > We have an autosuspend timeout because we think that IO, if it will
> > > come at all, is likeliest
the autosuspend timeout. That's why I suggested making the
> > interval adjustable.
>
> What do you mean statistics interval?
> Interval calling ndo_get_stats64 or another thread/timer or else getting
> statistics?
The time between calls to ndo_get_stats64, since that's the routine
which queries the device.
Alan Stern
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 14:24 -0400, Alan Stern wrote:
> > On Mon, 21 Mar 2016, Oliver Neukum wrote:
> >
> > > On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
> > >
> > > > One possible solut
statistics interval to
the autosuspend timeout (or 0 if autosuspend is disabled) plus some
fixed value.
Alan Stern
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
>
> > One possible solution is to export a sysfs parameter to prevent
> > statistics collection (or more generally, to change the interval at
> > which it occurs).
>
ection (or more generally, to change the interval at
which it occurs).
But checking the runtime_auto flag is probably not a great idea. Even
if it isn't set, collecting statistics is likely to wait up a device
that otherwise would have remained suspended.
Perhaps the best solution is to collect the statistics only when the
device is not suspended or is about to suspend.
Alan Stern
On Thu, 24 Dec 2015, Oliver Neukum wrote:
> On Thu, 2015-12-24 at 10:14 -0500, Alan Stern wrote:
> > On Thu, 24 Dec 2015, Oliver Neukum wrote:
> >
> > > On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote:
>
> > > But you cannot keep that setting if the sys
On Thu, 24 Dec 2015, Oliver Neukum wrote:
> On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote:
>
> > I don't understand why the wakeup conditions are different. It seems
> > to me that the choice of which packets will generate a wakeup ought to
> > depend on the
n that should be true for both runtime suspend and system
suspend.
To put it another way, as far as the device is concerned a suspend is
just a suspend -- there's no different between a runtime suspend and a
system suspend.
Alan Stern
--
To unsubscribe from this list: send the line "unsubs
ontrol endpoint. And calls the existing
> usbnet_resume thereafter
You know, the USB core already issues a Set-Interface request on the
control endpoint whenever a reset-resume occurs (unless the interface
was using altsetting 0 beforehand). Issuing another Set-Interface
shouldn't make any dif
On Mon, 24 Aug 2015, Alan Stern wrote:
> On Mon, 24 Aug 2015, David Miller wrote:
>
> > From: Eugene Shatokhin
> > Date: Wed, 19 Aug 2015 14:59:01 +0300
> >
> > > So the following might be possible, although unlikely:
> > >
> > > CPU0
dn't find any mention of it in
Documentation/atomic_ops.txt.
In theory, an architecture could implement atomic bit operations using
a spinlock to insure atomicity. I don't know if any architectures do
this, but if they do then the scenario above could arise.
Alan Stern
--
To unsubscribe
On Tue, 4 Aug 2015, Uwe [iso-8859-1] Kleine-K�nig wrote:
> Hello,
>
> On Tue, Aug 04, 2015 at 10:20:55AM -0400, Alan Stern wrote:
> > In that case, adding a call pm_runtime_get_noresume() is the right
> > thing to do.
> Is this an ack for Lucas' patch?
Yes:
Acke
On Tue, 4 Aug 2015, Lucas Stach wrote:
> Am Montag, den 03.08.2015, 14:28 -0400 schrieb Alan Stern:
> > On Mon, 3 Aug 2015, Uwe [iso-8859-1] Kleine-Knig wrote:
> >
> > > Hello,
> > >
> > > I have no clue about runtime-pm, but I added a few
PM status to "active".
A call to pm_runtime_get_noresume() (or something similar) is necessary
to balance the call to pm_runtime_put_autosuspend() at the end of the
probe routine. Both the _get_ and the _put_ should be present or
neither should be.
For instance, an alternative way to a
On Thu, 21 May 2015, Takashi Iwai wrote:
> At Thu, 21 May 2015 11:26:17 -0400 (EDT),
> Alan Stern wrote:
> >
> > On Thu, 21 May 2015, Takashi Iwai wrote:
> >
> > > At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> > > Alan Stern wrote:
> > >
the kernel log will tell just what
happened.
On Thu, 21 May 2015, Takashi Iwai wrote:
> At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> Alan Stern wrote:
> >
> > On Thu, 21 May 2015, Takashi Iwai wrote:
> >
> > > Then avoiding the failed firmware is no solution, in
ing resume under certain
circumstances. A driver lacking a reset_resume callback is one of
those circumstances.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 1 Jan 2008, Greg KH wrote:
> On Mon, Dec 31, 2007 at 11:26:43AM -0800, Greg KH wrote:
> > On Mon, Dec 31, 2007 at 12:49:52PM -0500, Alan Stern wrote:
> > > On Sun, 30 Dec 2007, Greg KH wrote:
> > >
> > > > > It looks like Greg misused t
st enable CONFIG_DEBUGFS is USB_DEBUG is enabled and
> then simplify this logic a bunch at the same time.
Most distributions enable CONFIG_DEBUGFS by default, don't they? So
this problem only comes up when people make up their own configs.
Having USB_DEBUG enabled and DEBUGFS disabled seem
ges... And wondering how to properly elevate
> > this issue (prompt Greg about it, new thread, bug #, ...?)
It looks like Greg misused the debugfs API -- which is ironic, because
he wrote debugfs in the first place! :-)
Let me know if this patch fixes the problem. If it does, I'll subm
time I looked at the source code, that's what it did. I'll look
again... Yep, it still does. It checks to see if the timer routine is
currently running; if so then it waits a little while and tries again.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe
(if possible) to be sure that the timer won't run
> anymore?
> (Taking in the account the fact that it re-enables itself)
Use del_timer_sync(). It guarantees that when it returns, the timer
will be stopped and the timer routine will no longer be running on any
CPU.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
d don't re-enable the timer if it is set. Even
without any memory barriers, the timer routine won't iterate more than
once or twice.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
any security association?
Thanks for any answers. I may think up more questions later...
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
twork cable is unplugged.
Has any progress been made in this direction? If not, a natural approach
would be to start with a reference implementation in one driver which
could then be copied to other drivers.
Any suggestions?
Alan Stern
-
To unsubscribe from this list: send the line "u
53 matches
Mail list logo
