On Mon, Jul 20, 2020 at 08:16:05PM +0200, Michal Hocko wrote:
> On Mon 20-07-20 13:48:12, Alan Stern wrote:
> > On Mon, Jul 20, 2020 at 07:45:30PM +0200, Michal Hocko wrote:
> > > On Mon 20-07-20 13:38:07, Alan Stern wrote:
> > > > On Mon, Jul 20, 2020 at 06:33:
On Mon, Jul 20, 2020 at 07:45:30PM +0200, Michal Hocko wrote:
> On Mon 20-07-20 13:38:07, Alan Stern wrote:
> > On Mon, Jul 20, 2020 at 06:33:55PM +0200, Michal Hocko wrote:
> > > On Mon 20-07-20 11:12:55, Alan Stern wrote:
> > > [...]
> > > >
On Mon, Jul 20, 2020 at 06:33:55PM +0200, Michal Hocko wrote:
> On Mon 20-07-20 11:12:55, Alan Stern wrote:
> [...]
> > sudo echo 'module usbcore =p' >/debug/dynamic_debug/control
> >
> > Then wait long enough for some interesting messages to appear in the
> >
say "unlock semantics"?
It's not as bad as all that; people do talk about acquiring and
releasing locks, and presumably you don't have any trouble understanding
those terms. In fact this usage is quite common -- and I believe it's
where the names "acquire semantics" and "release semantics" came from
originally.
Alan Stern
On Mon, Jul 20, 2020 at 04:32:13PM +0200, Michal Hocko wrote:
> On Mon 20-07-20 09:58:57, Alan Stern wrote:
> [...]
> > Can you provide the contents of /sys/kernel/debug/usb/devices and also a
>
> attached.
It looks like you've got just two devices, only one of which is
On Mon, Jul 20, 2020 at 11:33:20AM +1000, Dave Chinner wrote:
> On Sat, Jul 18, 2020 at 10:08:11AM -0400, Alan Stern wrote:
> > > This is one of the reasons that the LKMM documetnation is so damn
> > > difficult to read and understand: just understanding the vocabulary
&
81
> [<0>] process_one_work+0x1bd/0x2c6
> [<0>] worker_thread+0x19c/0x240
> [<0>] kthread+0x11b/0x123
> [<0>] ret_from_fork+0x22/0x30
>
> Is this something known or something I can give more information about?
> From a very quick look into the code it sounds as if the system wanted
> to suspend an USB device/controller but that keeps failing again and
> again.
Yes, that's what it looks like to me too. Or maybe the suspend succeeds
but then the device/controller immediately gets woken up again.
Can you provide the contents of /sys/kernel/debug/usb/devices and also a
usbmon trace showing a few rounds of this recurring activity? Perhaps a
section of the dmesg log with dynamic debugging enabled for the usbcore
module, as well.
Alan Stern
ikely), there is a distinct risk that people will supply
different mutexes or done variables for the invocations.
IMO a better approach would be to have a macro which, given a variable
name v, generates an actual init_once_v() function. Then code wanting
to use v would call init_once_v() first, with no danger of inconsistent
usage. You can fill in the details...
Alan Stern
s file), and the actual recipe itself should
await the development of a general and robust API.
Alan Stern
think it needs improvement and can give some specific details
about where it falls short, I would like to hear them.
Alan Stern
pendency (checking whether the pointer is
non-NULL). Control dependencies do not always ensure ordering
-- certainly not for reads, and depending on the compiler,
possibly not for some writes -- and therefore a load-acquire is
necessary.
Perhaps this is more wordy than you want, but it does get the important
ideas across.
Alan Stern
> Why do we have cmpxchg_release() anyway? Under what circumstances is
> cmpxchg() useful _without_ having release semantics?
To answer just the last question: cmpxchg() is useful for lock
acquisition, in which case it needs to have acquire semantics rather
than release semantics.
Alan Stern
On Fri, Jul 17, 2020 at 12:22:49PM -0400, Mathieu Desnoyers wrote:
> - On Jul 17, 2020, at 12:11 PM, Alan Stern st...@rowland.harvard.edu
> wrote:
>
> >> > I agree with Nick: A memory barrier is needed somewhere between the
> >> > assignment at 6 and the ret
as to ensure that it executes
after the IPI-induced memory barrier on CPU1. If it happened before
then we could still end up with r1 = 0. That's why the pairing matters.
I hope this helps your head get properly wrapped. :-)
Alan Stern
On Fri, Jul 17, 2020 at 09:39:25AM -0400, Mathieu Desnoyers wrote:
> - On Jul 16, 2020, at 5:24 PM, Alan Stern st...@rowland.harvard.edu wrote:
>
> > On Thu, Jul 16, 2020 at 02:58:41PM -0400, Mathieu Desnoyers wrote:
> >> - On Jul 16, 2020, at 12:03
ase above to:
... since we still need a load-acquire of the data on which
the other task performed a store-release.
Alan Stern
s say that a writes to X and 9
reads from X.
Then we have an instance of the Store Buffer pattern:
CPU0CPU1
a. Write X 6. Write rq->curr for user thread
c. smp_mb() 7. switch_to memory barrier
d. Read rq->curr9. Read X
In this pattern, the memory barriers make it impossible for both reads
to miss their corresponding writes. Since d does fail to read 6 (it
sees the earlier value stored by 4), 9 must read a.
The other guarantee you need is that g on CPU0 will observe anything
written by CPU1 in 1. This is easier to see, using the fact that 3 is a
memory barrier and d reads from 4.
Alan Stern
uct usbtest_dev *dev, struct
> usbtest_param_32 *param,
> if (param->sglen > MAX_SGLEN)
> return -EINVAL;
>
> + urbs = kcalloc(MAX_SGLEN, sizeof(*urbs), GFP_KERNEL);
Since you know at runtime how many URBs will be needed, why not use that
information? Change MAX_SGLEN to param->sglen.
Aside from that,
Acked-by: Alan Stern
Alan Stern
itting.
(Incidentally, the calls to usb_unlink_urb() in that routine are useless
and look very strange. The URB is already unlinked, since
mceusb_dev_recv() is the completion handler.)
Alan Stern
it in-kernel when/if we encounter a program using the
bpf_trace_printk() helper. With this approach, trace_printk()
is not used directly and no warning message appears.
This work was started by Steven (see Link) and finished by Alan; added
Steven's Signed-off-by with his permission.
Link: https
will not prevent tracing output from being logged
(Steven, patch 1)
- use "tp/raw_syscalls/sys_enter" and a usleep(1) to trigger events
in the selftest ensuring test runs faster (Andrii, patch 2)
[1] https://lore.kernel.org/r/20200628194334.6238b...@oasis.local.home
Alan Maguire (2):
bpf: use
Simple selftests that verifies bpf_trace_printk() returns a sensible
value and tracing messages appear.
Signed-off-by: Alan Maguire
Acked-by: Andrii Nakryiko
---
.../selftests/bpf/prog_tests/trace_printk.c| 75 ++
tools/testing/selftests/bpf/progs/trace_printk.c
, patch 1)
- use "tp/raw_syscalls/sys_enter" and a usleep(1) to trigger events
in the selftest ensuring test runs faster (Andrii, patch 2)
[1] https://lore.kernel.org/r/20200628194334.6238b...@oasis.local.home
Alan Maguire (2):
bpf: use dedicated bpf_trace_printk event instead of tr
it in-kernel when/if we encounter a program using the
bpf_trace_printk() helper. With this approach, trace_printk()
is not used directly and no warning message appears.
This work was started by Steven (see Link) and finished by Alan; added
Steven's Signed-off-by with his permission.
Link: https
Simple selftests that verifies bpf_trace_printk() returns a sensible
value and tracing messages appear.
Signed-off-by: Alan Maguire
---
.../selftests/bpf/prog_tests/trace_printk.c| 74 ++
tools/testing/selftests/bpf/progs/trace_printk.c | 21 ++
2 files changed
On Tue, 7 Jul 2020, Andrii Nakryiko wrote:
> On Fri, Jul 3, 2020 at 7:47 AM Alan Maguire wrote:
> >
> > The bpf helper bpf_trace_printk() uses trace_printk() under the hood.
> > This leads to an alarming warning message originating from trace
> > buffer allocation
On Tue, Jun 30, 2020 at 20:49:58PM -0400, Alan Stern wrote:
> On Tue, Jun 30, 2020 at 04:31:58PM -0700, Bart Van Assche wrote:
> > On 2020-06-30 12:38, Alan Stern wrote:
> > > Assume that BLK_MQ_REQ_PREEMPT is set in flags. Then where exactly
> > > does blk
it in-kernel when/if we encounter a program using the
bpf_trace_printk() helper. With this approach, trace_printk()
is not used directly and no warning message appears.
This work was started by Steven (see Link) and finished by Alan; added
Steven's Signed-off-by with his permission.
Link: https
://lore.kernel.org/r/20200628194334.6238b...@oasis.local.home
Alan Maguire (2):
bpf: use dedicated bpf_trace_printk event instead of trace_printk()
selftests/bpf: add selftests verifying bpf_trace_printk() behaviour
kernel/trace/Makefile | 2 +
kernel/trace
Simple selftest that verifies bpf_trace_printk() returns a sensible
value and tracing messages appear.
Signed-off-by: Alan Maguire
---
.../selftests/bpf/prog_tests/trace_printk.c| 71 ++
tools/testing/selftests/bpf/progs/trace_printk.c | 21 +++
2 files changed
7 +96,7 @@ static int ohci_platform_probe(struct platform_device *dev)
> struct ohci_hcd *ohci;
> int err, irq, clk = 0;
>
> - if (usb_disabled())
> + if (usb_disabled() || of_machine_is_compatible("rockchip,rk3288"))
> return -ENODEV;
>
> /*
> --
> 2.25.1
Acked-by: Alan Stern
Tue, Jun 30, 2020 at 06:02:43PM -0700, Atish Patra wrote:
> On Tue, Jun 30, 2020 at 5:52 PM Alan Kao wrote:
> >
> > On Mon, Jun 29, 2020 at 11:19:09AM +0800, Zong Li wrote:
> > > This patch set adds raw event support on RISC-V. In addition, we
> > > introduce
On Mon, Jun 29, 2020 at 11:19:09AM +0800, Zong Li wrote:
> This patch set adds raw event support on RISC-V. In addition, we
> introduce the DT mechanism to make our perf more generic and common.
>
> Currently, we set the hardware events by writing the mhpmeventN CSRs, it
> would raise an illegal
On Tue, Jun 30, 2020 at 04:31:58PM -0700, Bart Van Assche wrote:
> On 2020-06-30 12:38, Alan Stern wrote:
> > Assume that BLK_MQ_REQ_PREEMPT is set in flags. Then where exactly
> > does blk_queue_enter(q, flags) call blk_pm_request_resume(q)?
>
> Please take a loo
On Tue, Jun 30, 2020 at 12:23:12PM -0700, Bart Van Assche wrote:
> On 2020-06-30 11:02, Alan Stern wrote:
> > Right now there doesn't seem to be any mechanism for resuming the queue
> > if an REQ_PREEMPT request is added while the queue is suspended.
>
> I do not agree wit
On Tue, Jun 30, 2020 at 08:59:00AM -0700, Bart Van Assche wrote:
> On 2020-06-29 09:15, Alan Stern wrote:
> > Aha. Looking at this more closely, it's apparent that the code in
> > blk-core.c contains a logic bug: It assumes that if the BLK_MQ_REQ_PREEMPT
> > flag is set
gs 0x0 phys_seg 1 prio class 0
No way to tell from the log what caused this error.
> [ 372.560690] scsi_runtime_suspend
> [ 372.563968] scsi_runtime_suspend
> [ 372.567237] scsi_runtime_suspend
>
> thanks Alan for taking the time and trying to fix this! you're close.
> what is missing?
At this point I don't know.
Alan Stern
un 2020 15:51:50 +1000
> Subject: [PATCH] thunderbolt: merge fix for kunix_resource changes
>
> Signed-off-by: Stephen Rothwell
Thanks Stephen, resolution looks good to me! If you need it
Reviewed-by: Alan Maguire
Once the kunit and thunderbolt trees are merged there may
be some additional t
On Mon, Jun 29, 2020 at 09:56:49AM -0700, Bart Van Assche wrote:
> On 2020-06-29 09:15, Alan Stern wrote:
> > Aha. Looking at this more closely, it's apparent that the code in
> > blk-core.c contains a logic bug: It assumes that if the BLK_MQ_REQ_PREEMPT
> > flag is set
On Mon, Jun 29, 2020 at 11:42:59AM +0200, Martin Kepplinger wrote:
>
>
> On 26.06.20 17:44, Alan Stern wrote:
> > Martin's best approach would be to add some debugging code to find out why
> > blk_queue_enter() isn't calling bkl_pm_request_resume(), or why that c
On Sat, Jun 27, 2020 at 07:37:54PM -0700, Bart Van Assche wrote:
> On 2020-06-26 08:44, Alan Stern wrote:
> > On Fri, Jun 26, 2020 at 08:07:51AM -0700, Bart Van Assche wrote:
> >> As far as I know runtime power management support in the sd driver is
> >> working
sound/usb/line6/pcm.c:533
> toneport_init+0xdd/0x6b0 sound/usb/line6/toneport.c:419
> line6_probe+0xaa0/0x1330 sound/usb/line6/driver.c:809
It look like the cancel_delayed_work() in line6_disconnect() needs to be
cancel_delayed_work_sync(). Unfortunately we can't test this until syzbot
is able to reproduce the bug.
Alan Stern
> Bart.
Martin's best approach would be to add some debugging code to find out why
blk_queue_enter() isn't calling bkl_pm_request_resume(), or why that call
doesn't lead to pm_request_resume().
Alan Stern
On Fri, 26 Jun 2020, Petr Mladek wrote:
> On Tue 2020-06-23 13:07:07, Alan Maguire wrote:
> > printk supports multiple pointer object type specifiers (printing
> > netdev features etc). Extend this support using BTF to cover
> > arbitrary types. "%pT&q
struct gendisk *disk, fmode_t
> >> mode)
> >>
> >>SCSI_LOG_HLQUEUE(3, sd_printk(KERN_INFO, sdkp, "sd_release\n"));
> >>
> >> + scsi_autopm_put_device(sdev);
> >> +
> >>if (atomic_dec_return(>openers) == 0 &
er place to trace).
If it seems like it could be useful I could have a go at
porting the kprobe stuff to KUnit, as it helps expand the vocabulary
for what can be tested in kernel context; for example we can
also override return values for kernel functions to simulate errors.
Alan
tests verify we get 0 return value from bpf_trace_print()
using %pT format specifier with various modifiers/pointer
values.
Signed-off-by: Alan Maguire
---
.../selftests/bpf/prog_tests/trace_printk_btf.c| 45 +
.../selftests/bpf/progs/netif_receive_skb.c| 47
vmlinux BTF initialization can take time so it's best to do that
outside of printk context; otherwise the first printk() using %pT
will trigger BTF initialization.
Signed-off-by: Alan Maguire
---
lib/vsprintf.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/vsprintf.c b
te pointer values.
BTF_SHOW_UNSAFE - do not copy data to safe buffer before display.
BTF_SHOW_ZERO - show zeroed values (by default they are not shown).
Signed-off-by: Alan Maguire
---
include/linux/btf.h | 36 ++
kernel/bpf/btf.c| 966 ++-
es where overflow
is likely, the compact/no type names display modes may be used.
Signed-off-by: Alan Maguire
i
---
Documentation/core-api/printk-formats.rst | 17 ++
include/linux/btf.h | 3 +-
include/linux/printk.h| 16 +
lib/vsprintf.c
.
These changes add up to approximately 20,000 new tests covering
all enum, struct, union and typedefs in vmlinux BTF.
Individual tests are also added for int, char, struct, enum
and typedefs which verify output is as expected.
Signed-off-by: Alan Maguire
---
include/linux/btf.h | 3 +
kernel/bpf
Allow %pT[cNx0] format specifier for BTF-based display of data associated
with pointer. The unsafe data modifier 'u' - where the source data
is traversed without copying it to a safe buffer via probe_kernel_read() -
is not supported.
Signed-off-by: Alan Maguire
---
include/uapi/linux/bpf.h
ko - the version in the bpf-next
tree will induce a panic when running the fwnode_pointer() tests due
to a kobject issue; applying the patch in
https://lkml.org/lkml/2020/4/17/389
...resolved this issue for me.
Alan Maguire (8):
bpf: provide function to get vmlinux BTF information
bpf: move t
checkpatch complains about unknown format specifiers, so add
the BTF format specifier we will implement in a subsequent
patch to avoid errors.
Signed-off-by: Alan Maguire
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b
It will be used later for BTF printk() support
Signed-off-by: Alan Maguire
---
include/linux/bpf.h | 2 ++
kernel/bpf/verifier.c | 18 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 07052d4..a2ecebd 100644
of
> hardware is ready to support these operations.
This isn't needed. All UDC drivers must be able to support requests that
are larger than the maxpacket size.
Alan Stern
o "struct kunit_suite"?
So for the ext4 tests the "subsystem" would be "ext4" and the
name "inode" would specify the test area within that subsystem.
For the KUnit selftests, the subsystem would be "test"/"selftest".
Logging could utilize the subsystem definition to allow test
writers to use less redundant test names too. For example
the suite name logged could be constructed from the
subsystem + area values associated with the kunit_suite,
and individual test names could be shown as the
suite area + test_name.
Thanks!
Alan
n ch9.h instead of in usb.h.
> Thanks for Alan's suggestion.
Acked-by: Alan Stern
wrong; you need to do test_and_clear_bit(port1,
hub->child_usage_bits) before calling pm_runtime_put_sync(). Otherwise
the child_usage_bits value will get out of sync with the port's runtime
status.
Alan Stern
> +#define MAX_USB_STRING_LEN 126
This definition belongs in include/uapi/linux/usb/ch9.h (near the
definition of struct usb_string_descriptor) because it is part of the USB
standard rather than specific to the Linux USB stack.
Alan Stern
y, let's
> do the same for USB_PORT_FEAT_SUSPEND and bus suspend case.
>
> This is particularly useful for USB2 devices, which may take a very long
> time to switch USB2 LPM on and off.
Have these two patches been tested with a variety of USB-2.0 and USB-2.1
devices?
Alan Stern
Don't clean the file path to empty.
> + */
> + if (curlun->cdrom == 1 && count == 1)
> + return count;
> +
> + /*
> + * WORKAROUND: Should be closed the fsg lun for virtual cd-rom,
> + * when switch to other usb functions.
That is not a grammatical English sentence.
> + * Use the special keyword "off", because the init can
> + * not parse the char '\n' in rc file and write into the sysfs.
> + */
> + if (count == 3 &&
> + buf[0] == 'o' && buf[1] == 'f' && buf[2] == 'f' &&
> + fsg_lun_is_open(curlun))
> + ((char *) buf)[0] = 0;
This seems like another bug fix that has no connection with BICR.
Alan Stern
> +
> /* Remove a trailing newline */
> if (count > 0 && buf[count-1] == '\n')
> ((char *) buf)[count-1] = 0;/* Ugh! */
> --
> 2.18.0
;
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> --
> 2.26.2
Acked-by: Alan Stern
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Fri, 5 Jun 2020 11:22:24 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Alex Williamson (alex.william...@redhat.com) wrote:
> > > On Wed, 3 Jun 2020 01:24:43 -0400
> > > Yan Zhao wrote:
>
> > > > On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> > > > > On Wed, 29 Apr 2020 20:39:50 -0400
> > > > > Yan Zhao wrote:
> > > > >
> > > > > > On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Al
1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
> index 98ada1a3425c..bae88893ee8e 100644
> --- a/drivers/usb/misc/usbtest.c
> +++ b/drivers/usb/misc/usbtest.c
> @@ -2873,6 +2873,7 @@ static void usbtest_disconnect(struct usb_interface
> *intf)
>
> usb_set_intfdata(intf, NULL);
> dev_dbg(>dev, "disconnect\n");
> + kfree(dev->buf);
> kfree(dev);
> }
>
> --
> 2.24.1
Aside from that one issue,
Acked-by: Alan Stern
of UML so can be
useful to do if running under UML is failing. When tests are built-in
they will execute on boot, and modules will automatically execute
associated tests when loaded. Test results can be collected from
/sys/kernel/debug/kunit//results. For more details see
"KUnit on non-UML architectures" in :doc:`usage`.
Reviewed-by: Alan Maguire
he way to fix the
problem is not to change this one location. Instead, you should modify
the driver so that us->iobuf is not stored in DMA memory.
Alan Stern
use a "match-by-name" callback.
If an attempt to add a resource with a name that already exists
is made kunit_add_named_resource() will return -EEXIST.
Signed-off-by: Alan Maguire
Reviewed-by: Brendan Higgins
---
include/kunit/test.h | 54 +++
tried moving to
kunit_[action]_resource() as the format of function names
for consistency and readability.
[1] https://lkml.org/lkml/2020/2/26/1286
Signed-off-by: Alan Maguire
Reviewed-by: Brendan Higgins
---
include/kunit/test.h | 156 +-
l
for non-named resource (Brendan, patch 2)
Alan Maguire (2):
kunit: generalize kunit_resource API beyond allocated resources
kunit: add support for named resources
Alan Maguire (2):
kunit: generalize kunit_resource API beyond allocated resources
kunit: add support for named res
ify
CONFIG_KUNIT=m and CONFIG_STATS_FS_TEST=m, and testing would
simply be a case of "modprobe"ing the stats fs module and collecting
results in /sys/kernel/debug/kunit/ (rather
than running kunit.py). Are you relying on unexported internals in
the the tests that would prevent building them as a module?
Thanks!
Alan
On Mon, May 25, 2020 at 05:28:33AM +, Rick Mark wrote:
> Hey Alan
>
> You and other previously rejected a patch I submitted 13 months ago
Nobody rejected your patch. We pointed out problems with it, and we
asked you to take a second look and provide more information. You never
ffice. And if there wasn't
> the trailing store, smp_store_release() would suffice.
But that wasn't the context in the litmus test. The context was:
smp_wmb();
smp_store_release();
spin_unlock();
smp_store_release();
That certainly looks like a lot more ordering than is really needed.
Alan
Indeed, it looks like one or the other of those is redundant (depending
on the context).
Also, what use is a spinlock that is accessed in only one thread?
Finally, I doubt that these tests belong under tools/memory-model.
Shouldn't they go under the new Documentation/ directory for litmus
tests? And shouldn't the patch update a README file?
Alan
On Wed, May 20, 2020 at 03:21:44PM -0400, Rik van Riel wrote:
> On Wed, 2020-05-20 at 12:38 -0400, Alan Stern wrote:
> > On Wed, May 20, 2020 at 07:26:57AM -0400, Rik van Riel wrote:
> > > After a few more weeks of digging, I have come to the tentative
> > > conclusion
Greg, Alan,
The other 4 related patches were accepted into usb-next and I just
realized that this one didn't make it. This patch will not fix the
"insmod out of order" issue, but will help our controllers work with
some poorly behaved USB devices when the drivers are builtin.
Thanks
"halted" state. But obviously
this isn't what you're talking about.)
> - how should the USB sound driver recover from these
> occasional and/or one-off errors? stop the sound
> stream, or try to reinitialize the device and start
> recording again?
As far as I know, it should do its best to continue (perhaps fill in
missing data with zeros).
Alan Stern
> I am willing to write patches and can test with my
> setup, but both the sound code and the USB code are
> new to me so I would like to know what direction I
> should go in :)
s to
deal with it. It cost me time to figure it out when I had an application
that needed a region larger than 4GB. I figured the most I could do about
it is to raise the issue by adding a warning.
Regards,
Alan
On Mon, May 18, 2020 at 03:57:49PM +0100, Qais Yousef wrote:
> > For both this patch and the 3/3 patch (ehci-platform):
> >
> > Acked-by: Alan Stern
>
> Thanks Alan. Did this make it through to any tree? I don't see it on next, nor
> on Linus. But it could be queued
; > \
> > + }
> > \
> > + } while (0)
> > +
> > +#define btf_show_type_values(show, fmt, ...)
> > \
> > + do {
> > \
> > + btf_show(show, "%s%s" fmt "%s%s", btf_show_indent(show),
> > \
> > +btf_show_name(show),
> > \
> > +__VA_ARGS__, btf_show_delim(show),
> > \
> > +btf_show_newline(show));
> > \
> > + if (show->state.depth > show->state.depth_shown)
> > \
> > + show->state.depth_shown = show->state.depth;
> > \
> > + } while (0)
> > +
> [...]
> >
> > static int btf_array_check_member(struct btf_verifier_env *env,
> > @@ -2104,28 +2489,87 @@ static void btf_array_log(struct btf_verifier_env
> > *env,
> > array->type, array->index_type, array->nelems);
> > }
> >
> > -static void btf_array_seq_show(const struct btf *btf, const struct btf_type
> > *t,
> > - u32 type_id, void *data, u8 bits_offset,
> > - struct seq_file *m)
> > +static void __btf_array_show(const struct btf *btf, const struct btf_type
> > *t,
> > +u32 type_id, void *data, u8 bits_offset,
> > +struct btf_show *show)
> > {
> >const struct btf_array *array = btf_type_array(t);
> >const struct btf_kind_operations *elem_ops;
> >const struct btf_type *elem_type;
> > - u32 i, elem_size, elem_type_id;
> > + u32 i, elem_size = 0, elem_type_id;
> > + u16 encoding = 0;
> >
> > elem_type_id = array->type;
> > - elem_type = btf_type_id_size(btf, _type_id, _size);
> > + elem_type = btf_type_skip_modifiers(btf, elem_type_id, NULL);
> > + if (elem_type && btf_type_has_size(elem_type))
> > + elem_size = elem_type->size;
> > +
> > + if (elem_type && btf_type_is_int(elem_type)) {
> > + u32 int_type = btf_type_int(elem_type);
> > +
> > + encoding = BTF_INT_ENCODING(int_type);
> > +
> > + /*
> > +* BTF_INT_CHAR encoding never seems to be set for
> > +* char arrays, so if size is 1 and element is
> > +* printable as a char, we'll do that.
> > +*/
> > + if (elem_size == 1) > + encoding =
> > BTF_INT_CHAR;
>
> Some char array may be printable and some may not be printable,
> how did you differentiate this?
>
I should probably change the logic to ensure all chars
(before a \0) are printable. I'll do that for v2. We will always
have cases (e.g. the skb cb[] field) where the char[] is not
intended as a string, but I think the utility of showing them as
strings where possible is worthwhile.
Thanks again for reviewing!
Alan
y out an allocation associated with the attach,
but that's messy as it's possible run-time might determine the type for
display (and thus the amount of the buffer we need to copy safely).
Great news about LLVM support for __builtin_btf_type_id()!
Thanks!
Alan
On Sat, May 16, 2020 at 07:23:42AM +0800, Tang Bin wrote:
> Hi Alan & Colin：
>
> On 2020/5/16 1:21, Alan Stern wrote:
> > On Fri, May 15, 2020 at 05:54:53PM +0100, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > The comparison of
On Fri, May 15, 2020 at 06:26:04PM +0100, Colin Ian King wrote:
> On 15/05/2020 18:21, Alan Stern wrote:
> > On Fri, May 15, 2020 at 05:54:53PM +0100, Colin King wrote:
> >> From: Colin Ian King
> >>
> >> The comparison of hcd->irq to less than zero for
in Ian King
> ---
Thanks to Coverity for spotting this. Any reason why it didn't spot
exactly the same mistake in the ohci-da8xx.c driver?
Also, why wasn't the patch CC'ed for the stable series?
Alan Stern
On Wed, 13 May 2020, Yonghong Song wrote:
>
>
> On 5/11/20 10:56 PM, Alan Maguire wrote:
> > printk supports multiple pointer object type specifiers (printing
> > netdev features etc). Extend this support using BTF to cover
> > arbitrary types. "
On Wed, 13 May 2020, Alexei Starovoitov wrote:
> On Tue, May 12, 2020 at 06:56:38AM +0100, Alan Maguire wrote:
> > The printk family of functions support printing specific pointer types
> > using %p format specifiers (MAC addresses, IP addresses, etc). For
> > full deta
uggy before then coverity got
a false positive, so no change should be needed.
Alan Stern
> Signed-off-by: Stan Lu
> Signed-off-by: Macpaul Lin
> ---
> drivers/usb/gadget/function/u_serial.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/d
(and perhaps for some other drivers),
> that reasons about whether an endpoint has configurable address based
> on its name.
>
> Suggested-by: Alan Stern
> Signed-off-by: Andrey Konovalov
> ---
> drivers/usb/gadget/udc/dummy_hcd.c | 26 +-
&g
On Wed, May 13, 2020 at 1:46 PM Florian Fainelli wrote:
>
>
>
> On 5/13/2020 10:39 AM, Alan Stern wrote:
> > On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:
> >> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
> >>>
know, xhci-hcd will _never_ be loaded.
One thing that might be possible (although not all platforms may support
it) is if xhci-hcd could somehow disconnect all devices attached to a
peer port when it starts up. But that would be disruptive to any
devices that aren't USB-3.
We faced a very similar ordering problem between ehci-hcd and
[ou]hci-hcd many years ago, and we never found a good solution.
We did arrange the link order so that ehci-hcd precedes the others, and
we added a warning message to ehci-hcd which gets printed if the module
initialization routine runs after [ou]hci-hcd is loaded. Also, there
are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.
Alan Stern
TODO, etc). Plus a KUNIT_SKIPPED status could easily
progagate up from the tests to the plan result line
(all tests have status == SKIPPED => plan status = SKIPPED).
Would that work? Thanks!
Alan
> kunit_tool will parse this SKIP directive, and renders skipped tests in
> yellow and counts
test
>
> Since this test returned to tools/memory-model/, make sure that it is
> at least referenced from Documentation/litmus-tests/'s README.
>
> Co-developed-by: Joel Fernandes (Google)
> Co-developed-by: Akira Yokosawa
> [Alan: grammar nit]
> Suggested-by: Alan Stern
On Mon, May 11, 2020 at 3:51 PM Alan Stern wrote:
>
> On Mon, 11 May 2020, Al Cooper wrote:
>
> > Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver
> > was created instead of adding support to the existing ehci platform
> > driver because of the code r
t; +MP+onceassign+derefonce.litmus (moved to tools/memory-model/litmus-tests/)
> + Demonstrates that rcu_assign_pointer() and rcu_dereference() to
> + ensure that an RCU reader will not see pre-initialization garbage.
The grammar in this sentence is awful. Should the first "that" be
changed to "the use of"?
Alan
approach taken; early boot initialization is one
way to go here.
- may be useful to have a "print integers as hex" format modifier (Joe)
Important note: if running test_printf.ko - the version in the bpf-next
tree will induce a panic when running the fwnode_pointer() tests due
to a kobject i
checkpatch complains about unknown format specifiers, so add
the BTF format specifier we will implement in a subsequent
patch to avoid errors.
Signed-off-by: Alan Maguire
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b
ERO - show zeroed values (by default they are not shown).
Signed-off-by: Alan Maguire
---
include/linux/btf.h | 33 +++
kernel/bpf/btf.c| 759 +---
2 files changed, 690 insertions(+), 102 deletions(-)
diff --git a/include/linux/btf.h b/inc
.
These changes add up to approximately 20,000 new tests covering
all enum, struct, union and typedefs in vmlinux BTF.
Individual tests are also added for int, char, struct, enum
and typedefs which verify output is as expected.
Signed-off-by: Alan Maguire
---
include/linux/btf.h | 10 ++
kernel/bpf
It will be used later for BTF printk() support
Signed-off-by: Alan Maguire
---
include/linux/bpf.h | 2 ++
kernel/bpf/verifier.c | 18 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index cf4b6e4..de19a35 100644
401 - 500 of 20878 matches
Mail list logo
