> I just posted a new patch for this, please have a look and test it.
>
> Kind regards
> Uffe
I tested your new patch and it works.
Reviewed-and-tested-by: Al Cooper
Thanks
Al
On Tue, Jan 26, 2021 at 4:55 AM Ulf Hansson wrote:
>
> On Mon, 25 Jan 2021 at 18:40, Florian Fainelli wrote:
> >
>
- that one could stand to be
cleaned up as well.
For instance, how about putting the HAS_DMA part into a separate line,
since it's unrelated to the other stuff? And the rest looks like it
could be changed to:
depends on USB_EHCI_HCD || USB_GADGET
although that probably isn't quite valid. Still, can't it be changed to
something simpler than
(USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && !USB_GADGET) ||
(!USB_EHCI_HCD && USB_GADGET)
?
Alan Stern
On Thu, 21 Jan 2021, Andrii Nakryiko wrote:
> On Wed, Jan 20, 2021 at 10:56 PM Andrii Nakryiko
> wrote:
> >
> > On Sun, Jan 17, 2021 at 2:22 PM Alan Maguire
> > wrote:
> > >
> > > Add a BTF dumper for typed data, so that the user can dump
nline int usb_gadget_frame_number(struct usb_gadget *gadget)
> { return 0; }
Don't you also need an entry for the case where CONFIG_USB_GADGET isn't
enabled?
Alan Stern
driver will get invalid memory accesses if
fsg_unbind returns too early. fsg will be deallocated, but
fsg_set_interface will continue to use it. This patch completely
ignores that issue.
Was there any real reason for writing this patch? Does it solve a
real-world problem? Did you encounter a situation where the wait_event
call would wait for more than 1/4 second?
Alan Stern
ID interception if required */
> svm_check_invpcid(svm);
>
> + if (nested && guest_cpuid_has(vcpu, X86_FEATURE_SVM)) {
> + best = kvm_find_cpuid_entry(vcpu, 0x800A, 0);
> + best->edx |= (1 << 28);
> + }
> +
> /* F
BTF type data dumping will use them in later patches, and they
are useful generally when handling BTF data.
Signed-off-by: Alan Maguire
---
tools/lib/bpf/btf.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
index 1237bcd
6744073709551615,
},
},
...
Signed-off-by: Alan Maguire
---
tools/lib/bpf/btf.h | 17 +
tools/lib/bpf/btf_dump.c | 974 +++
tools/lib/bpf/libbpf.map | 5 +
3 files changed, 996 insertions(+)
diff --git a/tools/lib/bpf/btf.h b/tools/lib
sues found in it should be fixed there or vice versa;
mirroring the tests should help with this also
(Andrii)
[1]
https://lore.kernel.org/bpf/1610386373-24162-1-git-send-email-alan.magu...@oracle.com/T/#t
Alan Maguire (4):
libbpf: add btf_has_size() and btf_int() inlines
libbpf: make skip_mods_an
Test various type data dumping operations by comparing expected
format with the dumped string; an snprintf-style printf function
is used to record the string dumped.
Signed-off-by: Alan Maguire
---
tools/testing/selftests/bpf/prog_tests/btf_dump.c | 233 ++
1 file changed
btf_dump.c will need it for type-based data display.
Signed-off-by: Alan Maguire
---
tools/lib/bpf/libbpf.c | 4 +---
tools/lib/bpf/libbpf_internal.h | 2 ++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 2abbc38
urb_suitable_for_idt(urb) ||
> + (usb_endpoint_xfer_control(>ep->desc)))
> return 0;
Would this affect the map/unmap operations for the DATA packets in a
control transfer, along with the SETUP packet?
Alan Stern
blems) anywhere?
>So far I haven't actually seen any patches, which means that it's not
>coming back.
But with a few pertinent patches, it might come back, perhaps?
[ ]
Linus
--
Alan Mackenzie (Nuremberg, Germany).
On Mon, 11 Jan 2021, Andrii Nakryiko wrote:
> On Mon, Jan 11, 2021 at 9:34 AM Alan Maguire wrote:
> > Currently the only "show" function for userspace is to write the
> > representation of the typed data to a string via
> >
> > LIBBPF_API int
> > btf__s
On Tue, Jan 12, 2021 at 09:20:10PM -0800, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit c318840fb2a42ce25febc95c4c19357acf1ae5ca
> Author: Alan Stern
> Date: Wed Dec 30 16:20:44 2020 +
>
> USB: Gadget: dummy-hcd: Fix shift-out-of-boun
* Axel Rasmussen (axelrasmus...@google.com) wrote:
> On Mon, Jan 11, 2021 at 3:58 AM Dr. David Alan Gilbert
> wrote:
> >
> > * Axel Rasmussen (axelrasmus...@google.com) wrote:
> > > This feature allows userspace to intercept "minor" faults. By "minor&qu
skb_id);
else
btf__snprintf(btf, buf, sizeof(buf), skb_id, skb, 0);
Suggested-by: Alexei Starovoitov
Signed-off-by: Alan Maguire
---
include/linux/btf.h | 121 +---
include/linux/btf_common.h | 286 +
kernel/bpf/Makefile |2 +-
kernel/
Test btf__snprintf with various base/kernel types and ensure
display is as expected; tests are identical to those in snprintf_btf
test save for the fact these run in userspace rather than BPF program
context.
Signed-off-by: Alan Maguire
---
.../selftests/bpf/prog_tests/snprintf_btf_user.c
format. The test closely mirrors
the BPF program associated with the snprintf_btf.c; in this case
however the string representations are verified in userspace rather
than in BPF program context.
Alan Maguire (2):
bpf: share BTF "show" implementation between kernel and libbpf
selftests
>
> so, when the driver goes to sleep and changes the system state to
> suspend, the interrupt flag needs to be cleared.
>
> Signed-off-by: Longfang Liu
Acked-by: Alan Stern
> ---
>
> Changes in v2:
> - updated cleared registers
>
> drivers/usb/host/ehci-hub.c | 4 ++
range;
> #define UFFDIO_REGISTER_MODE_MISSING ((__u64)1<<0)
> #define UFFDIO_REGISTER_MODE_WP ((__u64)1<<1)
> +#define UFFDIO_REGISTER_MODE_MINOR ((__u64)1<<2)
> __u64 mode;
>
> /*
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index a2602969873d..0ba8f2f5a4ae 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4377,6 +4377,37 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
> }
> }
>
> + /* Check for page in userfault range. */
> + if (!new_page && userfaultfd_minor(vma)) {
> + u32 hash;
> + struct vm_fault vmf = {
> + .vma = vma,
> + .address = haddr,
> + .flags = flags,
> + /*
> + * Hard to debug if it ends up being used by a callee
> + * that assumes something about the other uninitialized
> + * fields... same as in memory.c
> + */
> + };
> +
> + unlock_page(page);
> +
> + /*
> + * hugetlb_fault_mutex and i_mmap_rwsem must be dropped before
> + * handling userfault. Reacquire after handling fault to make
> + * calling code simpler.
> + */
> +
> + hash = hugetlb_fault_mutex_hash(mapping, idx);
> + mutex_unlock(_fault_mutex_table[hash]);
> + i_mmap_unlock_read(mapping);
> + ret = handle_userfault(, VM_UFFD_MINOR);
> + i_mmap_lock_read(mapping);
> + mutex_lock(_fault_mutex_table[hash]);
> + goto out;
> + }
> +
> /*
>* If we are going to COW a private mapping later, we examine the
>* pending reservations for this page now. This will ensure that
> --
> 2.29.2.729.g45daf8777d-goog
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
a follow-up patch series.
>
> Axel Rasmussen (2):
> userfaultfd: add minor fault registration mode
> userfaultfd: add UFFDIO_CONTINUE ioctl
>
> fs/proc/task_mmu.c | 1 +
> fs/userfaultfd.c | 143 ++++---
> incl
ported any problems caused by
that patch, so adding it to the stable branches should be safe enough.
> What do you think?
We could even do both. That would help if, for example, somebody
decided to set ohci_hcd.distrust_firmware=true explicitly.
Greg, in the meantime can we have commit c4
ut these subsystems to evaluate this. Can you
take a look at it?
Thank,
Alan Stern
needed for compilation anyhow.
[1]
https://lore.kernel.org/netdev/1461512707-23058-1-git-send-email-mikko.rapeli__34748.27880641$1462831734$gmane$o...@iki.fi/
Fixes: f6f3bac08ff9 ("tools/bpf: bpftool: add net support")
Signed-off-by: Alan Maguire
---
tools/bpf/bpftool/net.c | 1 -
1
On Tue, 5 Jan 2021, Cong Wang wrote:
> On Mon, Jan 4, 2021 at 7:29 AM Alan Maguire wrote:
> >
> > BPF Type Format (BTF) provides a description of kernel data structures
> > and of the types kernel functions utilize as arguments and return values.
> >
>
p "ip_send_skb(skb->dev == 0, skb)"
...as this will be evaluated before the skb is stringified,
and we potentially avoid that operation if the predicate fails.
The same is _not_ true however in the stash case; for
ksnoop "ip_send_skb(skb, return!=0)"
...we must collect
On Tue, Dec 29, 2020 at 08:33:39AM -0800, syzbot wrote:
> > #syz test: upstream e37b12e4
>
> "upstream" does not look like a valid git repo address.
I thought syzbot had been changed to recognize "upstream" as a valid
repo name.
Alan Stern
#syz test: https://git
003
> RBP: 006ce018 R08: R09: 004002e0
> R10: 000f R11: 0246 R12: 00401bb0
> R13: 00401c40 R14: R15:
> ====
The cause is pret
* Kalra, Ashish (ashish.ka...@amd.com) wrote:
> Hello Dave,
>
> On Dec 18, 2020, at 1:40 PM, Dr. David Alan Gilbert
> wrote:
>
> * Ashish Kalra (ashish.ka...@amd.com) wrote:
> On Fri, Dec 11, 2020 at 10:55:42PM +, Ashish Kalra wrote:
> Hello All,
>
> On T
> [ 56.197148] page_enc_status_hc invoked, gpa = 1f005000, npages = 1, enc =
> 1
> [ 56.222679] page_enc_status_hc invoked, gpa = 1e83b000, npages = 1, enc = > 0
> [ 56.222691] page_enc_status_hc invoked, gpa = 1e839000, npages = 1, enc = > 0
> [ 56.222707] page_enc_status_hc invoked, gpa = 1e83b000, npages = 1, enc =
> 1
> [ 56.222720] page_enc_status_hc invoked, gpa = 1e839000, npages = 1, enc =
> 1
> [ 56.313747] page_enc_status_hc invoked, gpa = 1e5eb000, npages = 1, enc = > 0
> [ 56.313771] page_enc_status_hc invoked, gpa = 1e5e9000, npages = 1, enc = > 0
> [ 56.313789] page_enc_status_hc invoked, gpa = 1e5eb000, npages = 1, enc =
> 1
> [ 56.313803] page_enc_status_hc invoked, gpa = 1e5e9000, npages = 1, enc =
> 1
> [ 56.459276] page_enc_status_hc invoked, gpa = 1d767000, npages = 100, enc
> = 0
> [ 56.459428] page_enc_status_hc invoked, gpa = 1e501000, npages = 1, enc =
> 1
> [ 56.460037] page_enc_status_hc invoked, gpa = 1d767000, npages = 100, enc
> = 1
> [ 56.460216] page_enc_status_hc invoked, gpa = 1e501000, npages = 1, enc = > 0
> [ 56.460299] page_enc_status_hc invoked, gpa = 1d767000, npages = 100, enc
> = 0
> [ 56.460448] page_enc_status_hc invoked, gpa = 1e501000, npages = 1, enc =
> 1
> As can be observed here, all guest MMIO ranges are initially setup as
> shared, and those are all contigious guest page ranges.
>
> After that the encryption status hypercalls are invoked when DMA gets
> triggered during disk i/o while booting the guest ... here again the
> guest page ranges are contigious, though mostly single page is touched
> and a lot of page re-use is observed.
>
> So a range-based list/structure will be a "good" fit for such usage
> scenarios.
It seems surprisingly common to flick the same pages back and forth between
encrypted and clear for quite a while; why is this?
Dave
> Thanks,
> Ashish
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
IA Tegra SoCs. The controllers are EHCI compliant.
It doesn't really make sense to say "... the driver was removed..."
and then in the next paragraph say "This driver enables...". You
should change the second paragraph to begin: "Enable support for...".
That's a minor matter, though, and you can easily fix it in the next
patch version. Everything else is okay.
Acked-by: Alan Stern
Alan Stern
On Wed, Dec 16, 2020 at 08:09:51PM +0300, Dmitry Osipenko wrote:
> 16.12.2020 19:45, Alan Stern пишет:
> > On Tue, Dec 15, 2020 at 11:21:12PM +0300, Dmitry Osipenko wrote:
> >> The ChipIdea driver now provides USB2 host mode support for NVIDIA Tegra
> >> SoCs. The ehci-t
the internal USB Host Controllers
> - found in NVIDIA Tegra SoCs. The controllers are EHCI compliant.
For people upgrading from earlier kernel versions, do you think it
would help to add a pointer here telling them which Kconfig option
they need to enable now in order to get this functionality?
Alan Stern
unwanted effects.
--
Alan Modra
Australia Development Lab, IBM
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 9270e1a744f8ed953009b0e94b26ed0912d9ec1c
Gitweb:
https://git.kernel.org/tip/9270e1a744f8ed953009b0e94b26ed0912d9ec1c
Author:Alan Stern
AuthorDate:Sat, 03 Oct 2020 21:40:22 -04:00
Committer
re
which might select CONFIG_EHCI_BIG_ENDIAN_MMIO, as used in ehci.h.
Otherwise we're left in the unfortunate position of having to provide
definitions for these functions, but _only_ on architectures that don't
already make their own definitions -- basically an impossible task.
Alan Stern
fore the queue is unfrozen.
> > */
> > - if ((pm && q->rpm_status != RPM_SUSPENDED) ||
> > - !blk_queue_pm_only(q)) {
> > + if ((pm && !rq_suspended(q)) || !blk_queue_pm_only(q))
> > success = true;
> > - } else {
> > + else
> > percpu_ref_put(>q_usage_counter);
> > - }
> > }
> > rcu_read_unlock();
Yes, that certainly is the proper fix. It's all to easy to miss these
issues that depend on your kernel configuration.
Bart, can you fold it into a new version of the patch?
Alan Stern
On Tue, Dec 08, 2020 at 11:04:25AM -0500, Alan Stern wrote:
> On Tue, Dec 08, 2020 at 03:53:16AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:08a02f95 USB: add RESET_RESUME quirk for Snapscan 12
: () GS:8881f6a0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f557af47550 CR3: 0001090f3000 CR4: 001506f0
> DR0: DR1: DR2:
> DR3: 000
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Mon, 7 Dec 2020 at 16:44, Dr. David Alan Gilbert
> wrote:
> > * Steven Price (steven.pr...@arm.com) wrote:
> > > Sorry, I know I simplified it rather by saying it's similar to protected
> > > VM.
> > >
it is for QEMU to deal with (3) without
> the overhead of bounce buffers. Ideally there'd already be a wrapper for
> guest memory accesses and that could just be wrapped with setting TCO during
> the access. I suspect the actual situation is more complex though, and I'm
> hoping Haibo's investigations will help us understand this.
>
> Thanks,
>
> Steve
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
On Sun, Dec 06, 2020 at 06:24:05PM +0700, Bui Quang Minh wrote:
> On Sat, Dec 05, 2020 at 10:15:11AM -0500, Alan Stern wrote:
> > On Sat, Dec 05, 2020 at 07:47:01PM +0700, Minh Bùi Quang wrote:
> > > Vào Th 6, 4 thg 12, 2020 vào lúc 23:12 Alan Stern
> >
ot everyone will
have llvm12). Does that seem reasonable?
With the additional few minor changes on top of Andrii's patch,
the use of __builtin_btf_type_id() worked perfectly. Thanks!
Alan
On Sat, Dec 05, 2020 at 07:47:01PM +0700, Minh Bùi Quang wrote:
> Vào Th 6, 4 thg 12, 2020 vào lúc 23:12 Alan Stern
> đã viết:
> > Does this initialization end up using less memory than an explicit
> > memset() call?
>
> You mean speed?
No, I mean memory space.
auditing example in
Documentation/RCU/listRCU.rst ; and as such we can eliminate
the lock and use list_del_rcu()/call_rcu() on module removal,
and list_add_rcu() for module addition.
Signed-off-by: Alan Maguire
---
kernel/bpf/btf.c | 31 +--
1 file changed, 17 insertions
t net_device".
Currently the tests take the messy approach of determining object
and type ids for the relevant module/function; __builtin_btf_type_id()
supports object ids by returning a 64-bit value, but need to find a good
way to determine if that support is present.
Signed-off-by: Alan M
the object id
specifies the module the type is in, or if no such id is
found in the module list, we fall back to vmlinux.
Signed-off-by: Alan Maguire
---
include/linux/btf.h| 12
include/uapi/linux/bpf.h | 13 +++--
kernel/bpf/btf.c
be supported
directly in the BPF program via __builtin_btf_type_id(); but
I need to determine a good test to determine if that builtin
supports object ids.
Changes since RFC
- add patch to remove module mutex
- modify to use obj_id instead of module name as identifier
in "struct btf_ptr" (And
C];
> + struct dummy *dum[MAX_NUM_UDC] = {};
>
> if (usb_disabled())
> return -ENODEV;
Acked-by: Alan Stern
Does this initialization end up using less memory than an explicit
memset() call?
Alan Stern
> 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
30bc00f0>] hub_event+0x144a/0x20d0 drivers/usb/core/hub.c:5590
> [<e89e69ae>] process_one_work+0x27d/0x590 kernel/workqueue.c:2272
> [<63d76c23>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2418
> [<a311ec69>] kthread+0x178/0x1b0 kernel/kthread.c:292
> [<690c42fe>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
#syz dup: memory leak in hub_event
Alan Stern
t; break;
> + case KVM_HC_PAGE_ENC_STATUS:
> + ret = -KVM_ENOSYS;
> + if (kvm_x86_ops.page_enc_status_hc)
> + ret = kvm_x86_ops.page_enc_status_hc(vcpu->kvm,
> + a0, a1, a2);
> + break;
> default:
> ret = -KVM_ENOSYS;
> break;
> diff --git a/include/uapi/linux/kvm_para.h b/include/uapi/linux/kvm_para.h
> index 8b86609849b9..847b83b75dc8 100644
> --- a/include/uapi/linux/kvm_para.h
> +++ b/include/uapi/linux/kvm_para.h
> @@ -29,6 +29,7 @@
> #define KVM_HC_CLOCK_PAIRING 9
> #define KVM_HC_SEND_IPI 10
> #define KVM_HC_SCHED_YIELD 11
> +#define KVM_HC_PAGE_ENC_STATUS 12
>
> /*
> * hypercalls use architecture specific
> --
> 2.17.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
->in_urb || !dev->out_urb) {
> > nfc_err(>dev, "Could not allocate USB URBs\n");
>
> How does this solve a warning in the USB core about a string descriptor
> error?
Greg, you misread the bug report. The problem wasn't the string
descriptor read error; it was URB submitted while active.
More to the point, adding __GFP_ZERO to the usb_alloc_urb call won't fix
anything, because usb_alloc_urb calls usb_init_urb, which already does a
memset.
Alan Stern
t;? Or is one of the two sizes *always* the smaller
> > one?
I assume you're referring to code in the uas driver. There the value of
dev is meaningless as far as DMA is concerned. Only sysdev matters.
Alan Stern
> > On Tue, 1 Dec 2020 at 02:19, Hans de Goede wrote:
> > >
> > &
t; >>> It's merely a moving of comment moving for/and a no-behavioral-change
> >>> adaptation for the reversion.>
> >>
> >> IMHO the revert of the troublesome commit and the other/new changes really
> >> should be 2 separate commits. But I will let Alan and Greg ha
On Fri, Nov 27, 2020 at 10:29:03AM +0800, liulongfang wrote:
> On 2020/11/27 0:08, Alan Stern Wrote:
> > On Thu, Nov 26, 2020 at 11:34:33AM +0800, Longfang Liu wrote:
> >> The system goes to suspend when using USB audio player. This causes
> >> the USB device conti
the interrupt status
register, so why do you use it here?
> +
> ehci_handle_start_intr_unlinks(ehci);
> ehci_handle_intr_unlinks(ehci);
> end_free_itds(ehci);
Alan Stern
ero wrote:
> Thanks Alan
> I just spent some more time investigating and playing with different patches,
> locks, mutexes, and sleeps, and I think I see exactly what's happening now.
> I now understand why it:
> A) seems to happen randomly during uvc start_stream
> B) affects mu
protected memory
in things like SEV.
Dave
> thanks
> -- PMM
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
On Mon, Nov 23, 2020 at 09:23:53AM +0800, Can Guo wrote:
> Hi Alan,
>
> On 2020-11-21 00:35, Alan Stern wrote:
> > On Fri, Nov 20, 2020 at 12:37:22AM -0800, Can Guo wrote:
> > > Runtime resume is handled by runtime PM framework, no need to forcibly
> > > set runti
On Sat, Nov 21, 2020 at 09:00:02AM -0800, Bart Van Assche wrote:
> On 11/20/20 8:35 AM, Alan Stern wrote:
> > On Fri, Nov 20, 2020 at 12:37:22AM -0800, Can Guo wrote:
> >> Runtime resume is handled by runtime PM framework, no need to forcibly
> >> set runtime PM status
t; #syz test: upstream 4d02da97
>
> "upstream" does not look like a valid git repo address.
Okay, Andrey. If "upstream" is not accepted as a valid git repo
address, why does syzkaller list it on the "git tree:" line? It seems
to me that syzkaller should be willing to accept as input anything it
produces as output.
And what repo should I put here?
Alan Stern
dbb0>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
This looks like a reference is being taken but not released. Hard to
tell where it's happening, though. Let's try to narrow it down.
Alan Stern
#syz test: upstream 4d02da97
Index: usb-devel/drivers/media/usb/gspca/gspca.c
=
of a
__user pointer are minimal, since doing so does not leak any kernel
information. So %px would work, but tools like checkpatch.pl don't like
it.
Should a new specifier be added? If not, should we simply use %px?
Alan Stern
On Fri, Nov 20, 2020 at 05:32:44PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 20, 2020 at 11:15:19AM -0500, Alan Stern wrote:
> > > Perhaps you might want to add a comment here so that people will not
> > > keep making this same mistake when they run auto-checkers
e back into low-power mode.
Alan Stern
> Cc: Stanley Chu
> Cc: Bart Van Assche
> Cc: Alan Stern
> Signed-off-by: Can Guo
> ---
>
> Changes since v1:
> - Incorporated Bart's comments
>
> ---
> drivers/scsi/scsi_pm.c | 24 +---
> 1
e this read to complete
> > > > > the command? Lots of hardware is that way, so be very careful about
> > > > > this. Did you test it?
> > > >
> > > > I have tested this patch on Mediatek's platform, and not sure if it
> > > > will affect other vendors' platforms.
> > > >
> > > > Dear Bin:
> > > >
> > > > Does this patch will affect other vendors' platforms?
> > >
> > > The hardware specs will answer this question, what do they say about
> > > this read?
> >
> > Sorry, I didn't seen the comment on the hardware specs indicate that
> > devctl register needs to read once to take effect.
>
> Perhaps you might want to add a comment here so that people will not
> keep making this same mistake when they run auto-checkers on the
> codebase?
A better change would be
- devctl = musb_readb(mbase, MUSB_DEVCTL);
+ (void) musb_readb(mbase, MUSB_DEVCTL);
and eliminate the unused variable. Then there wouldn't be any compiler
warning.
Alan Stern
gt; > >
> > > The help text for this config options says that e200 is used in 55xx,
> > > and there *is* an -me5500 GAS flag (which probably does this same
> > > thing, too). But is any of this tested, or useful, or wanted?
> > >
> > >
On Sat, 14 Nov 2020, Yonghong Song wrote:
>
>
> On 11/14/20 8:04 AM, Alexei Starovoitov wrote:
> > On Fri, Nov 13, 2020 at 10:59 PM Andrii Nakryiko
> > wrote:
> >>
> >> On Fri, Nov 13, 2020 at 10:11 AM Alan Maguire
> >> wrote:
> >>>
lly
for vmlinux + module BTF, where the latter is much smaller.
Use btf__get_nr_types() instead.
Fixes: ba451366bf44 ("libbpf: Implement basic split BTF support")
Signed-off-by: Alan Maguire
---
tools/lib/bpf/btf.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --gi
net_device".
Signed-off-by: Alan Maguire
---
.../selftests/bpf/prog_tests/snprintf_btf_mod.c| 96 ++
tools/testing/selftests/bpf/progs/btf_ptr.h| 1 +
tools/testing/selftests/bpf/progs/veth_stats_rx.c | 73
3 files changed, 170 insertions(+)
cr
bpf_snprintf_btf and bpf_seq_printf_btf use a "struct btf_ptr *"
argument that specifies type information about the type to
be displayed. Augment this information to include a module
name, allowing such display to support module types.
Signed-off-by: Alan Maguire
---
include/l
lly
for vmlinux + module BTF, where the latter is much smaller.
Use btf__get_nr_types() instead.
Signed-off-by: Alan Maguire
---
tools/lib/bpf/btf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
index 2d0d064..0fccf4b 100
of a module-specific type id will fail
in patch 3.
Patch 3 is a selftest that uses veth (when built as a
module) and a kprobe to display both a module-specific
and kernel-specific type; both are arguments to veth_stats_rx().
Alan Maguire (3):
bpf: add module support to btf disp
.
This sort of error (config->interface[i] == NULL) is what you expect to
see if a driver tries to carry out I/O to a device that has been
unplugged and that it has been unbound from.
Alan Stern
is NULL in usb_ifnum_to_if
> [ 145.995907] WARNING: CPU: 31 PID: 5617 at drivers/usb/core/usb.c:289
> usb_ifnum_to_if+0x58/0x80
You removed the most important part of the log message! What appears
below this point?
In fact, you should just post the entire log (or put it on a server
somewhere and post a URL).
Alan Stern
; to 0 in those paths. That makes clang-analyzer happy.
>
> Proposal was discussed in this mail thread:
>
> Link:
> https://lore.kernel.org/linux-usb/alpine.DEB.2.21.202146110.13119@felia/
>
> Signed-off-by: Lukas Bulwahn
> ---
> applies cleanly on current master a
lid for config to be NULL at this
point. But it is not valid for dev to be NULL. If dev is NULL then
there is a bug in the caller.
Alan Stern
device found
> and usb is crashed with trace in dmesg.
The whole point of asking you to try out that change was to see the
trace in dmesg. What does it say?
Alan Stern
onsistent
> with the atomic_t api, which it is built on top of.
If Sequence Numbers are subject to wraparound then they aren't reliable.
Given that they aren't reliable, why use atomic instructions at all?
Why not just use plain regular integers with READ_ONCE and WRITE_ONCE?
Alan Stern
es etc and BTF generation seemed to work
fine for modules during kernel build).
For the "bpftool btf show" functionality, feel free to add
Tested-by: Alan Maguire
Thanks!
Alan
On Fri, Nov 06, 2020 at 01:04:13PM -0800, Paul E. McKenney wrote:
> On Fri, Nov 06, 2020 at 03:40:08PM -0500, Alan Stern wrote:
> > Is it really true that data dependencies are so easily destroyed? I
> > would expect that a true "semantic" dependency (i.e., one whe
On Fri, Nov 06, 2020 at 11:59:12AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 06, 2020 at 02:23:51PM -0500, Alan Stern wrote:
> > On Fri, Nov 06, 2020 at 10:04:46AM -0800, Paul E. McKenney wrote:
> > > On Fri, Nov 06, 2020 at 11:59:30AM -0500, Alan Stern wrote:
> > > &
On Fri, Nov 06, 2020 at 10:04:46AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 06, 2020 at 11:59:30AM -0500, Alan Stern wrote:
> > > + See also "Control Dependency".
> >
> > There should also be an entry for "Data Dependency", linked from here
> &g
x1640/0x1680 lib/kobject_uevent.c:608
>
> You gave it a device with a buffer that was "too small", and it rejected
> it.
>
> Which, aside from the huge warning message, is to be expected, so I
> don't think this is really a bug here.
The issue is that syzbot thinks "WARNING" indicates a problem in the
kernel. If the problem is really in the device then the message should
say "Warning" instead (not all caps).
Alan Stern
u_dereference.txt
> + for more information.
> +
> + See also "Control Dependency".
There should also be an entry for "Data Dependency", linked from here
and from Control Dependency.
> +Marked Access: An access to a variable that uses an special function or
> + macro such as "r1 = READ_ONCE()" or "smp_store_release(, 1)".
How about "r1 = READ_ONCE(x)"?
Alan
ulmck: Apply Akira Yokosawa file-placement feedback. ]
> [ paulmck: Apply Alan Stern feedback. ]
> [ paulmck: Apply self-review feedback. ]
> Signed-off-by: Paul E. McKenney
> ---
> diff --git a/tools/memory-model/Documentation/README
> b/tools/memory-model/Documentation/READ
> +}
> +
> static const struct tegra_ehci_soc_config tegra30_soc_config = {
> .has_hostpc = true,
> };
> @@ -431,6 +505,11 @@ static int tegra_ehci_probe(struct platform_device *pdev)
> goto cleanup_hcd_create;
> }
>
> + err = devm_tegra_ehci_init_opp_table(>dev);
> + if (err)
> + return dev_err_probe(>dev, err,
> + "Failed to initialize OPP\n");
Why log a second error message? Just return err.
Alan Stern
On Tue, Nov 03, 2020 at 11:02:25AM -0800, Wesley Cheng wrote:
>
>
> On 10/28/2020 6:07 PM, Alan Stern wrote:
> >> --- a/drivers/usb/dwc3/gadget.c
> >> +++ b/drivers/usb/dwc3/gadget.c
> >> @@ -1995,6 +1995,11 @@ static int dwc3_gadget_pullup(struct usb_gadget *
elling mistakes in commit.
> > 2.Revised resumes are added for easy tracing.
>
> You forgot to address Al Viro's review comments :(
You also might want to fix the type in the Subject line ("marco" instead
of "macro").
Alan Stern
f_mass_storage.c:2202 [inline]
> handle_exception drivers/usb/gadget/function/f_mass_storage.c:2426 [inline]
> fsg_main_thread+0x12c7/0x59f1
> drivers/usb/gadget/function/f_mass_storage.c:2466
> kthread+0x374/0x480 kernel/kthread.c:291
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Is this reproducible? Can you test patches?
Alan Stern
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
return 0;
> + }
Isn't this racy? What happens if the controller was active but a
runtime suspend occurs right here?
Alan Stern
> +
> is_on = !!is_on;
>
> /*
> @@ -2050,6 +2055,7 @@ static int dwc3_gadget_pullup(struct
On Tue, 27 Oct 2020, Greg Kroah-Hartman wrote:
> From: Alan Maguire
>
> [ Upstream commit eb58bbf2e5c7917aa30bf8818761f26bbeeb2290 ]
>
> bpf iter size increase to PAGE_SIZE << 3 means overflow tests assuming
> page size need to be bumped also.
>
Alexei can correc
err = -ENODEV;
> - goto cleanup_phy;
> + if (irq < 0) {
> + err = irq;
> + goto cleanup_phy;
> }
>
> otg_set_host(u_phy->otg, >self);
Acked-by: Alan Stern
The "if (!irq)" statement occurs at least one other driver in this
directory. Would you like to submit a patch for ehci-xilinx-of.c as
well?
Alan Stern
sb_remove_hcd(hcd);
> iounmap(hcd->regs);
> @@ -309,7 +309,7 @@ static int ehci_hcd_msp_drv_remove(struc
> {
> struct usb_hcd *hcd = platform_get_drvdata(pdev);
>
> - usb_hcd_msp_remove(hcd, pdev);
> + usb_hcd_msp_remove(hcd);
>
> /* free TWI GPIO USB_HOST_DEV pin */
> gpio_free(MSP_PIN_USB0_HOST_DEV);
Acked-by: Alan Stern
like irq handlers to both
> + * drivers except that the callbacks are invoked from soft interrupt
> + * context.
> */
> static void dummy_timer(struct timer_list *t)
> {
For dummy-hcd.c:
Acked-by: Alan Stern
...@vger.kernel.org
> ---
> V2: Fixup the comments according to review (Alan)
> ---
> drivers/usb/core/buffer.c |6 --
> drivers/usb/core/hcd-pci.c |6 --
> drivers/usb/core/hcd.c | 26 +-
> drivers/usb/core/hub.c |3 ++-
>
ndrzej Siewior
> Signed-off-by: Thomas Gleixner
> Acked-by: Krzysztof Kozlowski
>
>
>
101 - 200 of 20878 matches
Mail list logo
