Re: general protection fault in perf_misc_flags
On Sat, Sep 19, 2020 at 1:08 PM Borislav Petkov wrote: > > On Sat, Sep 19, 2020 at 01:32:14AM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:92ab97ad Merge tag 'sh-for-5.9-part2' of git://git.libc.or.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1069669b90 > > kernel config: https://syzkaller.appspot.com/x/.config?x=cd992d74d6c7e62 > > dashboard link: https://syzkaller.appspot.com/bug?extid=ce179bc99e64377c24bc > > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ > > c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+ce179bc99e64377c2...@syzkaller.appspotmail.com > > > > general protection fault, probably for non-canonical address > > 0x518084501e28: [#1] PREEMPT SMP KASAN > > KASAN: maybe wild-memory-access in range > > [0xfffaac042280f140-0xfffaac042280f147] > > CPU: 0 PID: 17449 Comm: syz-executor.5 Not tainted 5.9.0-rc5-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:perf_misc_flags+0x125/0x150 arch/x86/events/core.c:2638 > > Code: e4 48 83 e6 03 41 0f 94 c4 31 ff e8 95 fa 73 00 bb 02 00 00 00 4c 29 > > e3 49 81 c6 90 00 00 00 4c 89 f0 48 c1 e8 00 00 00 00 38 <00> 74 08 4c 89 > > f7 e8 40 c0 b3 00 41 8b 06 83 e0 08 48 c1 e0 0b 48 > > Hmm, so converting this back to opcodes with decodecode gives: > > Code: e4 48 83 e6 03 41 0f 94 c4 31 ff e8 95 fa 73 00 bb 02 00 00 00 4c 29 e3 > 49 81 c6 90 00 00 00 4c 89 f0 48 c1 e8 00 00 00 00 38 <00> 74 08 4c 89 f7 e8 > 40 c0 b3 00 41 8b 06 83 e0 08 48 c1 e0 0b 48 > All code > >0: e4 48 in $0x48,%al >2: 83 e6 03and$0x3,%esi >5: 41 0f 94 c4 sete %r12b >9: 31 ff xor%edi,%edi >b: e8 95 fa 73 00 callq 0x73faa5 > 10: bb 02 00 00 00 mov$0x2,%ebx > 15: 4c 29 e3sub%r12,%rbx > 18: 49 81 c6 90 00 00 00add$0x90,%r14 > 1f: 4c 89 f0mov%r14,%rax > 22: 48 c1 e8 00 shr$0x0,%rax > 26: 00 00 add%al,(%rax) > 28: 00 38 add%bh,(%rax) > 2a:* 00 74 08 4c add%dh,0x4c(%rax,%rcx,1)<-- > trapping instruction > 2e: 89 f7 mov%esi,%edi > 30: e8 40 c0 b3 00 callq 0xb3c075 > 35: 41 8b 06mov(%r14),%eax > 38: 83 e0 08and$0x8,%eax > 3b: 48 c1 e0 0b shl$0xb,%rax > 3f: 48 rex.W > > and those ADDs before the rIP look real strange. Just as if something > wrote 4 bytes of 0s there. And building your config with clang-10 gives > around that area: > > 8101177c: 48 83 e6 03 and$0x3,%rsi > 81011780: 41 0f 94 c4 sete %r12b > 81011784: 31 ff xor%edi,%edi > 81011786: e8 05 c9 73 00 callq 8174e090 > <__sanitizer_cov_trace_const_cmp8> > 8101178b: bb 02 00 00 00 mov$0x2,%ebx > 81011790: 4c 29 e3sub%r12,%rbx > 81011793: 49 81 c6 90 00 00 00add$0x90,%r14 > 8101179a: 4c 89 f0mov%r14,%rax > 8101179d: 48 c1 e8 03 shr$0x3,%rax > 810117a1: 42 80 3c 38 00 cmpb $0x0,(%rax,%r15,1) > 810117a6: 74 08 je 810117b0 > > 810117a8: 4c 89 f7mov%r14,%rdi > 810117ab: e8 20 75 b3 00 callq 81b48cd0 > <__asan_report_load8_noabort> > 810117b0: 41 8b 06mov(%r14),%eax > 810117b3: 83 e0 08and$0x8,%eax > 810117b6: 48 c1 e0 0b shl$0xb,%rax > > and I can pretty much follow it instruction by instruction until I reach > that SHR. Your SHR is doing a shift by 0 bytes and that already looks > suspicious. > > After it, your output has a bunch of suspicious ADDs and mine has a CMP; > JE instead. And that looks really strange too. > > Could it be that something has scribbled in guest memory and corrupted > that area, leading to that strange discrepancy in the opcodes? Hi Boris, Memory corruption is definitely possible. There are hundreds of known bugs that can potentially lead to silent memory corruptions, and some observed to lead to silent memory corruptions. However, these tend to produce crash signatures with 1-2 crashes. While this has 6 and they look similar and all happened on the only instance that uses clang. So my
Re: [PATCH v2] dm: Call proper helper to determine dax support
On Fri, 18 Sep 2020 at 11:18, Dan Williams wrote:
>
> From: Jan Kara
>
> DM was calling generic_fsdax_supported() to determine whether a device
> referenced in the DM table supports DAX. However this is a helper for "leaf"
> device drivers so that
> they don't have to duplicate common generic checks. High level code
> should call dax_supported() helper which that calls into appropriate
> helper for the particular device. This problem manifested itself as
> kernel messages:
>
> dm-3: error: dax access failed (-95)
>
> when lvm2-testsuite run in cases where a DM device was stacked on top of
> another DM device.
>
> Fixes: 7bf7eac8d648 ("dax: Arrange for dax_supported check to span multiple
> devices")
> Cc:
> Tested-by: Adrian Huang
> Signed-off-by: Jan Kara
> Acked-by: Mike Snitzer
> Signed-off-by: Dan Williams
> ---
> Changes since v1 [1]:
> - Add missing dax_read_lock() around dax_supported()
>
> [1]: http://lore.kernel.org/r/20200916151445.450-1-j...@suse.cz
>
> drivers/dax/super.c |4
> drivers/md/dm-table.c | 10 +++---
> include/linux/dax.h | 11 +--
> 3 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index e5767c83ea23..b6284c5cae0a 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -325,11 +325,15 @@ EXPORT_SYMBOL_GPL(dax_direct_access);
> bool dax_supported(struct dax_device *dax_dev, struct block_device *bdev,
> int blocksize, sector_t start, sector_t len)
> {
> + if (!dax_dev)
> + return false;
> +
> if (!dax_alive(dax_dev))
> return false;
>
> return dax_dev->ops->dax_supported(dax_dev, bdev, blocksize, start,
> len);
> }
> +EXPORT_SYMBOL_GPL(dax_supported);
arm build error while building with allmodconfig.
../drivers/dax/super.c:325:6: error: redefinition of ‘dax_supported’
325 | bool dax_supported(struct dax_device *dax_dev, struct
block_device *bdev,
| ^
In file included from ../drivers/dax/super.c:16:
../include/linux/dax.h:162:20: note: previous definition of
‘dax_supported’ was here
162 | static inline bool dax_supported(struct dax_device *dax_dev,
|^
make[3]: *** [../scripts/Makefile.build:283: drivers/dax/super.o] Error 1
Reported-by: Naresh Kamboju
Ref:
https://builds.tuxbuild.com/IO690jFQDp0qP9zFuWBqpA/build.log
Re: [PATCH 3/3] exfat: replace memcpy with structure assignment
2020-09-15 19:23 GMT-07:00, Sungjong Seo : >> Use structure assignment instead of memcpy. >> >> Signed-off-by: Tetsuhiro Kohada > > Acked-by: Sungjong Seo Applied. Thanks for your patch!
Re: [PATCH 4/4] perf test: Add expand cgroup event test
On Fri, Sep 18, 2020 at 10:52 PM Jiri Olsa wrote:
>
> On Wed, Sep 16, 2020 at 03:31:29PM +0900, Namhyung Kim wrote:
>
> SNIP
>
> > +++ b/tools/perf/tests/tests.h
> > @@ -123,6 +123,7 @@ const char *test__pfm_subtest_get_desc(int subtest);
> > int test__pfm_subtest_get_nr(void);
> > int test__parse_metric(struct test *test, int subtest);
> > int test__pe_file_parsing(struct test *test, int subtest);
> > +int test__expand_cgroup_events(struct test *test, int subtest);
> >
> > bool test__bp_signal_is_supported(void);
> > bool test__bp_account_is_supported(void);
> > diff --git a/tools/perf/util/cgroup.c b/tools/perf/util/cgroup.c
> > index a1bf345a770b..eeffa08251b5 100644
> > --- a/tools/perf/util/cgroup.c
> > +++ b/tools/perf/util/cgroup.c
> > @@ -52,7 +52,7 @@ static struct cgroup *evlist__find_cgroup(struct evlist
> > *evlist, const char *str
> > return NULL;
> > }
>
>
> could you please put the do_open change below into separate patch?
Ok, will do.
Thanks
Namhyung
> >
> > -static struct cgroup *cgroup__new(const char *name)
> > +static struct cgroup *cgroup__new(const char *name, bool do_open)
> > {
> > struct cgroup *cgroup = zalloc(sizeof(*cgroup));
> >
> > @@ -62,9 +62,14 @@ static struct cgroup *cgroup__new(const char *name)
> > cgroup->name = strdup(name);
> > if (!cgroup->name)
> > goto out_err;
> > - cgroup->fd = open_cgroup(name);
> > - if (cgroup->fd == -1)
> > - goto out_free_name;
> > +
> > + if (do_open) {
> > + cgroup->fd = open_cgroup(name);
> > + if (cgroup->fd == -1)
> > + goto out_free_name;
> > + } else {
> > + cgroup->fd = -1;
> > + }
> > }
> >
> > return cgroup;
> > @@ -80,7 +85,7 @@ struct cgroup *evlist__findnew_cgroup(struct evlist
> > *evlist, const char *name)
> > {
> > struct cgroup *cgroup = evlist__find_cgroup(evlist, name);
> >
> > - return cgroup ?: cgroup__new(name);
> > + return cgroup ?: cgroup__new(name, true);
> > }
> >
> > static int add_cgroup(struct evlist *evlist, const char *str)
> > @@ -202,7 +207,7 @@ int parse_cgroups(const struct option *opt, const char
> > *str,
> > }
> >
> > int evlist__expand_cgroup(struct evlist *evlist, const char *str,
> > - struct rblist *metric_events)
> > + struct rblist *metric_events, bool open_cgroup)
> > {
> > struct evlist *orig_list, *tmp_list;
> > struct evsel *pos, *evsel, *leader;
> > @@ -240,7 +245,7 @@ int evlist__expand_cgroup(struct evlist *evlist, const
> > char *str,
> > if (!name)
> > break;
> >
> > - cgrp = cgroup__new(name);
> > + cgrp = cgroup__new(name, open_cgroup);
> > free(name);
> > if (cgrp == NULL)
> > break;
> > diff --git a/tools/perf/util/cgroup.h b/tools/perf/util/cgroup.h
> > index eea6df8ee373..162906f3412a 100644
> > --- a/tools/perf/util/cgroup.h
> > +++ b/tools/perf/util/cgroup.h
> > @@ -26,7 +26,7 @@ struct rblist;
> >
> > struct cgroup *evlist__findnew_cgroup(struct evlist *evlist, const char
> > *name);
> > int evlist__expand_cgroup(struct evlist *evlist, const char *cgroups,
> > - struct rblist *metric_events);
> > + struct rblist *metric_events, bool open_cgroup);
> >
> > void evlist__set_default_cgroup(struct evlist *evlist, struct cgroup
> > *cgroup);
> >
> > --
> > 2.28.0.618.gf4bc123cb7-goog
> >
>
Re: [PATCH 1/3] exfat: remove useless directory scan in exfat_add_entry()
2020-09-15 19:22 GMT-07:00, Sungjong Seo : >> There is nothing in directory just created, so there is no need to scan. >> >> Signed-off-by: Tetsuhiro Kohada > > Acked-by: Sungjong Seo Applied. Thanks for your patch!
Re: [PATCH] s390/vfio-ap: fix unregister GISC when KVM is already gone results in OOPS
On 18.09.20 19:02, Tony Krowiak wrote:
> Attempting to unregister Guest Interruption Subclass (GISC) when the
> link between the matrix mdev and KVM has been removed results in the
> following:
>
>"Kernel panic -not syncing: Fatal exception: panic_on_oops"
I think the full backtrace would be better in case someone runs into this
and needs to compare this patch to its oops. This also makes it easier to
understand the fix.
>
> This patch fixes this bug by verifying the matrix mdev and KVM are still
> linked prior to unregistering the GISC.
>
> Signed-off-by: Tony Krowiak
Do we need a Fixes tag and cc stable?
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index e0bde8518745..847a88642644 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -119,11 +119,15 @@ static void vfio_ap_wait_for_irqclear(int apqn)
> */
> static void vfio_ap_free_aqic_resources(struct vfio_ap_queue *q)
> {
> - if (q->saved_isc != VFIO_AP_ISC_INVALID && q->matrix_mdev)
So we already check for q->matrix_mdev here
> - kvm_s390_gisc_unregister(q->matrix_mdev->kvm, q->saved_isc);
> - if (q->saved_pfn && q->matrix_mdev)
and here
> - vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
> - >saved_pfn, 1);
> + if (q->matrix_mdev) {
> + if (q->saved_isc != VFIO_AP_ISC_INVALID && q->matrix_mdev->kvm)
and this is the
only
new check? Cant we just add this condition to the first if?
> + kvm_s390_gisc_unregister(q->matrix_mdev->kvm,
> + q->saved_isc);
> + if (q->saved_pfn)
> + vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
> + >saved_pfn, 1);
> + }
> +
> q->saved_pfn = 0;
> q->saved_isc = VFIO_AP_ISC_INVALID;
> }
>
Re: [PATCH 3/4] perf tools: Copy metric events properly when expand cgroups
On Fri, Sep 18, 2020 at 10:45 PM Jiri Olsa wrote:
>
> On Wed, Sep 16, 2020 at 03:31:28PM +0900, Namhyung Kim wrote:
>
> SNIP
>
> > + free(new_expr);
> > + return -ENOMEM;
> > + }
> > +
> > + memcpy(new_expr->metric_refs,
> > old_expr->metric_refs,
> > +nr * alloc_size);
> > + } else {
> > + new_expr->metric_refs = NULL;
> > + }
> > +
> > + /* calculate number of metric_events */
> > + for (nr = 0; old_expr->metric_events[nr]; nr++)
> > + continue;
> > + alloc_size = sizeof(*new_expr->metric_events);
> > + new_expr->metric_events = calloc(nr + 1, alloc_size);
> > + if (!new_expr->metric_events) {
> > + free(new_expr->metric_refs);
> > + free(new_expr);
> > + return -ENOMEM;
> > + }
> > +
> > + /* copy evsel in the same position */
> > + for (idx = 0; idx < nr; idx++) {
> > + evsel = old_expr->metric_events[idx];
> > + evsel = evlist__get_evsel(evlist, evsel->idx);
>
> this probably won't happen, but evlist__get_evsel can return NULL
Hmm.. yeah, it should not happen. Anyway I'll check the result.
Thanks
Namhyung
>
> > + new_expr->metric_events[idx] = evsel;
> > + }
> > +
> > + list_add(_expr->nd, _me->head);
> > + }
> > + }
> > + return 0;
> > +}
>
> SNIP
>
Re: [PATCH 2/4] perf stat: Add --for-each-cgroup option
On Fri, Sep 18, 2020 at 10:34 PM Jiri Olsa wrote:
>
> On Wed, Sep 16, 2020 at 03:31:27PM +0900, Namhyung Kim wrote:
>
> SNIP
>
> > +int evlist__expand_cgroup(struct evlist *evlist, const char *str)
> > +{
> > + struct evlist *orig_list, *tmp_list;
> > + struct evsel *pos, *evsel, *leader;
> > + struct cgroup *cgrp = NULL;
> > + const char *p, *e, *eos = str + strlen(str);
> > + int ret = -1;
> > +
> > + if (evlist->core.nr_entries == 0) {
> > + fprintf(stderr, "must define events before cgroups\n");
> > + return -EINVAL;
> > + }
> > +
> > + orig_list = evlist__new();
> > + tmp_list = evlist__new();
> > + if (orig_list == NULL || tmp_list == NULL) {
> > + fprintf(stderr, "memory allocation failed\n");
> > + return -ENOMEM;
> > + }
> > +
> > + /* save original events and init evlist */
> > + perf_evlist__splice_list_tail(orig_list, >core.entries);
> > + evlist->core.nr_entries = 0;
> > +
> > + for (;;) {
> > + p = strchr(str, ',');
> > + e = p ? p : eos;
> > +
> > + /* allow empty cgroups, i.e., skip */
> > + if (e - str) {
> > + /* termination added */
> > + char *name = strndup(str, e - str);
> > + if (!name)
> > + break;
> > +
> > + cgrp = cgroup__new(name);
> > + free(name);
> > + if (cgrp == NULL)
> > + break;
> > + } else {
> > + cgrp = NULL;
> > + }
> > +
> > + leader = NULL;
> > + evlist__for_each_entry(orig_list, pos) {
> > + evsel = evsel__clone(pos);
>
> missing check on evsel == NULL
Will check.
Thanks
Namhyung
> > + cgroup__put(evsel->cgrp);
> > + evsel->cgrp = cgroup__get(cgrp);
> > +
> > + if (evsel__is_group_leader(pos))
> > + leader = evsel;
> > + evsel->leader = leader;
> > +
> > + evlist__add(tmp_list, evsel);
> > + }
> > + /* cgroup__new() has a refcount, release it here */
> > + cgroup__put(cgrp);
> > + nr_cgroups++;
> > +
> > + perf_evlist__splice_list_tail(evlist,
> > _list->core.entries);
> > + tmp_list->core.nr_entries = 0;
> > +
> > + if (!p) {
> > + ret = 0;
> > + break;
> > + }
> > + str = p+1;
> > + }
> > + evlist__delete(orig_list);
> > + evlist__delete(tmp_list);
> > +
> > + return ret;
> > +}
>
> SNIP
>
Re: [PATCH 1/4] perf evsel: Add evsel__clone() function
Hi Jiri,
On Fri, Sep 18, 2020 at 10:31 PM Jiri Olsa wrote:
>
> On Wed, Sep 16, 2020 at 03:31:26PM +0900, Namhyung Kim wrote:
>
> SNIP
>
> > +struct evsel *evsel__clone(struct evsel *orig)
> > +{
> > + struct evsel *evsel;
> > + struct evsel_config_term *pos, *tmp;
> > +
> > + BUG_ON(orig->core.fd);
> > + BUG_ON(orig->counts);
> > + BUG_ON(orig->priv);
> > + BUG_ON(orig->per_pkg_mask);
> > +
> > + /* cannot handle BPF objects for now */
> > + if (orig->bpf_obj)
> > + return NULL;
> > +
> > + evsel = evsel__new(>core.attr);
> > + if (evsel == NULL)
> > + return NULL;
> > +
> > + evsel->core.cpus = perf_cpu_map__get(orig->core.cpus);
> > + evsel->core.own_cpus = perf_cpu_map__get(orig->core.own_cpus);
> > + evsel->core.threads = perf_thread_map__get(orig->core.threads);
> > + evsel->core.nr_members = orig->core.nr_members;
> > + evsel->core.system_wide = orig->core.system_wide;
> > +
> > + if (orig->name)
> > + evsel->name = strdup(orig->name);
> > + if (orig->group_name)
> > + evsel->group_name = strdup(orig->group_name);
> > + if (orig->pmu_name)
> > + evsel->pmu_name = strdup(orig->pmu_name);
> > + if (orig->filter)
> > + evsel->filter = strdup(orig->filter);
>
> we should check those strdup results
ok.
>
> > + evsel->cgrp = cgroup__get(orig->cgrp);
> > + evsel->tp_format = orig->tp_format;
> > + evsel->handler = orig->handler;
> > + evsel->leader = orig->leader;
> > +
> > + evsel->max_events = orig->max_events;
> > + evsel->tool_event = orig->tool_event;
> > + evsel->unit = orig->unit;
> > + evsel->scale = orig->scale;
> > + evsel->snapshot = orig->snapshot;
> > + evsel->per_pkg = orig->per_pkg;
> > + evsel->percore = orig->percore;
> > + evsel->precise_max = orig->precise_max;
> > + evsel->use_uncore_alias = orig->use_uncore_alias;
> > + evsel->is_libpfm_event = orig->is_libpfm_event;
> > +
> > + evsel->exclude_GH = orig->exclude_GH;
> > + evsel->sample_read = orig->sample_read;
> > + evsel->auto_merge_stats = orig->auto_merge_stats;
> > + evsel->collect_stat = orig->collect_stat;
> > + evsel->weak_group = orig->weak_group;
>
> so all those evsel's members are possibly defined in parse time right?
> perhaps we should separate them in the struct? and make some note about
> evsel__clone function that new members should be considered for copy
> in evsel__close.. or something like that
Sounds good.
>
> > +
> > + list_for_each_entry(pos, >config_terms, list) {
> > + tmp = malloc(sizeof(*tmp));
> > + if (tmp == NULL) {
> > + evsel__delete(evsel);
> > + evsel = NULL;
> > + break;
> > + }
> > +
> > + *tmp = *pos;
> > + if (tmp->free_str) {
> > + tmp->val.str = strdup(pos->val.str);
> > + if (tmp->val.str == NULL) {
> > + evsel__delete(evsel);
> > + evsel = NULL;
> > + free(tmp);
> > + break;
> > + }
> > + }
> > + list_add_tail(>list, >config_terms);
> > + }
>
> could this go in separate function? copy_terms
Will do.
Thanks
Namhyung
>
> > +
> > + return evsel;
> > +}
> > +
> > /*
> > * Returns pointer with encoded error via interface.
> > */
> > diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
> > index 35e3f6d66085..507c31d6a389 100644
> > --- a/tools/perf/util/evsel.h
> > +++ b/tools/perf/util/evsel.h
> > @@ -169,6 +169,7 @@ static inline struct evsel *evsel__new(struct
> > perf_event_attr *attr)
> > return evsel__new_idx(attr, 0);
> > }
> >
> > +struct evsel *evsel__clone(struct evsel *orig);
> > struct evsel *evsel__newtp_idx(const char *sys, const char *name, int idx);
> >
> > /*
> > --
> > 2.28.0.618.gf4bc123cb7-goog
> >
>
Re: KASAN: use-after-free Read in btrfs_scan_one_device
syzbot has found a reproducer for the following issue on: HEAD commit:325d0eab Merge branch 'akpm' (patches from Andrew) git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1512df5390 kernel config: https://syzkaller.appspot.com/x/.config?x=6a8a2ae52ed737db dashboard link: https://syzkaller.appspot.com/bug?extid=582e66e5edf36a22c7b0 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12366f8b90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14e6929b90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+582e66e5edf36a22c...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in btrfs_printk+0x3eb/0x435 fs/btrfs/super.c:245 Read of size 8 at addr 8880878e06a8 by task syz-executor225/7068 CPU: 1 PID: 7068 Comm: syz-executor225 Not tainted 5.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d6/0x29e lib/dump_stack.c:118 print_address_description+0x66/0x620 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report+0x132/0x1d0 mm/kasan/report.c:530 btrfs_printk+0x3eb/0x435 fs/btrfs/super.c:245 device_list_add+0x1a88/0x1d60 fs/btrfs/volumes.c:943 btrfs_scan_one_device+0x196/0x490 fs/btrfs/volumes.c:1359 btrfs_mount_root+0x48f/0xb60 fs/btrfs/super.c:1634 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x88/0x270 fs/super.c:1547 fc_mount fs/namespace.c:978 [inline] vfs_kern_mount+0xc9/0x160 fs/namespace.c:1008 btrfs_mount+0x33c/0xae0 fs/btrfs/super.c:1732 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x88/0x270 fs/super.c:1547 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x179d/0x29e0 fs/namespace.c:3192 do_mount fs/namespace.c:3205 [inline] __do_sys_mount fs/namespace.c:3413 [inline] __se_sys_mount+0x126/0x180 fs/namespace.c:3390 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x44840a Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 cd a2 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 aa a2 fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:7ffedfffd608 EFLAGS: 0293 ORIG_RAX: 00a5 RAX: ffda RBX: 7ffedfffd670 RCX: 0044840a RDX: 2000 RSI: 2100 RDI: 7ffedfffd630 RBP: 7ffedfffd630 R08: 7ffedfffd670 R09: R10: R11: 0293 R12: 001a R13: 0004 R14: 0003 R15: 0003 Allocated by task 6945: kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461 kmalloc_node include/linux/slab.h:577 [inline] kvmalloc_node+0x81/0x110 mm/util.c:574 kvmalloc include/linux/mm.h:757 [inline] kvzalloc include/linux/mm.h:765 [inline] btrfs_mount_root+0xd0/0xb60 fs/btrfs/super.c:1613 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x88/0x270 fs/super.c:1547 fc_mount fs/namespace.c:978 [inline] vfs_kern_mount+0xc9/0x160 fs/namespace.c:1008 btrfs_mount+0x33c/0xae0 fs/btrfs/super.c:1732 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x88/0x270 fs/super.c:1547 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x179d/0x29e0 fs/namespace.c:3192 do_mount fs/namespace.c:3205 [inline] __do_sys_mount fs/namespace.c:3413 [inline] __se_sys_mount+0x126/0x180 fs/namespace.c:3390 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 6945: kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track+0x3d/0x70 mm/kasan/common.c:56 kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0xdd/0x110 mm/kasan/common.c:422 __cache_free mm/slab.c:3418 [inline] kfree+0x113/0x200 mm/slab.c:3756 deactivate_locked_super+0xa7/0xf0 fs/super.c:335 btrfs_mount_root+0x72b/0xb60 fs/btrfs/super.c:1678 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x88/0x270 fs/super.c:1547 fc_mount fs/namespace.c:978 [inline] vfs_kern_mount+0xc9/0x160 fs/namespace.c:1008 btrfs_mount+0x33c/0xae0 fs/btrfs/super.c:1732 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x88/0x270 fs/super.c:1547 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x179d/0x29e0 fs/namespace.c:3192 do_mount fs/namespace.c:3205 [inline] __do_sys_mount fs/namespace.c:3413 [inline] __se_sys_mount+0x126/0x180 fs/namespace.c:3390 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at 8880878e which belongs
[PATCH v3] memory: dfl-emif: add the DFL EMIF private feature driver
This driver is for the EMIF private feature implemented under FPGA
Device Feature List (DFL) framework. It is used to expose memory
interface status information as well as memory clearing control.
The purpose of memory clearing block is to zero out all private memory
when FPGA is to be reprogrammed. This gives users a reliable method to
prevent potential data leakage.
Signed-off-by: Xu Yilun
Signed-off-by: Russ Weight
---
v2: Adjust the position of this driver in Kconfig.
Improves the name of the Kconfig option.
Change the include dfl-bus.h to dfl.h, cause the previous patchset
renames the file.
Some minor fixes and comment improvement.
v3: Adjust the position of the driver in Makefile.
---
.../ABI/testing/sysfs-bus-dfl-devices-emif | 25 +++
drivers/memory/Kconfig | 9 +
drivers/memory/Makefile| 2 +
drivers/memory/dfl-emif.c | 207 +
4 files changed, 243 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
create mode 100644 drivers/memory/dfl-emif.c
diff --git a/Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
b/Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
new file mode 100644
index 000..56f97dc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
@@ -0,0 +1,25 @@
+What: /sys/bus/dfl/devices/dfl_dev.X/infX_cal_fail
+Date: Sep 2020
+KernelVersion: 5.10
+Contact: Xu Yilun
+Description: Read-only. It indicates if the calibration failed on this
+ memory interface. "1" for calibration failure, "0" for OK.
+ Format: %u
+
+What: /sys/bus/dfl/devices/dfl_dev.X/infX_init_done
+Date: Sep 2020
+KernelVersion: 5.10
+Contact: Xu Yilun
+Description: Read-only. It indicates if the initialization completed on
+ this memory interface. "1" for initialization complete, "0"
+ for not yet.
+ Format: %u
+
+What: /sys/bus/dfl/devices/dfl_dev.X/infX_clear
+Date: Sep 2020
+KernelVersion: 5.10
+Contact: Xu Yilun
+Description: Write-only. Writing "1" to this file will zero out all memory
+ data in this memory interface. Writing of other values is
+ invalid.
+ Format: %u
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 00e013b..2495bc4 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -137,6 +137,15 @@ config TI_EMIF_SRAM
sequence so this driver provides several relocatable PM functions
for the SoC PM code to use.
+config FPGA_DFL_EMIF
+ tristate "FPGA DFL EMIF Driver"
+ depends on FPGA_DFL && HAS_IOMEM
+ help
+ This driver is for the EMIF private feature implemented under
+ FPGA Device Feature List (DFL) framework. It is used to expose
+ memory interface status information as well as memory clearing
+ control.
+
config MVEBU_DEVBUS
bool "Marvell EBU Device Bus Controller"
default y if PLAT_ORION
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index e71cf7b..bc7663e 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -28,6 +28,8 @@ obj-$(CONFIG_STM32_FMC2_EBI) += stm32-fmc2-ebi.o
obj-$(CONFIG_SAMSUNG_MC) += samsung/
obj-$(CONFIG_TEGRA_MC) += tegra/
obj-$(CONFIG_TI_EMIF_SRAM) += ti-emif-sram.o
+obj-$(CONFIG_FPGA_DFL_EMIF)+= dfl-emif.o
+
ti-emif-sram-objs := ti-emif-pm.o ti-emif-sram-pm.o
AFLAGS_ti-emif-sram-pm.o :=-Wa,-march=armv7-a
diff --git a/drivers/memory/dfl-emif.c b/drivers/memory/dfl-emif.c
new file mode 100644
index 000..0799d53
--- /dev/null
+++ b/drivers/memory/dfl-emif.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DFL device driver for EMIF private feature
+ *
+ * Copyright (C) 2020 Intel Corporation, Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FME_FEATURE_ID_EMIF0x9
+
+#define EMIF_STAT 0x8
+#define EMIF_STAT_INIT_DONE_SFT0
+#define EMIF_STAT_CALC_FAIL_SFT8
+#define EMIF_STAT_CLEAR_BUSY_SFT 16
+#define EMIF_CTRL 0x10
+#define EMIF_CTRL_CLEAR_EN_SFT 0
+#define EMIF_CTRL_CLEAR_EN_MSK GENMASK_ULL(3, 0)
+
+#define EMIF_POLL_INVL 1 /* us */
+#define EMIF_POLL_TIMEOUT 500 /* us */
+
+struct dfl_emif {
+ struct device *dev;
+ void __iomem *base;
+ spinlock_t lock;/* Serialises access to EMIF_CTRL reg */
+};
+
+struct emif_attr {
+ struct device_attribute attr;
+ u32 shift;
+ u32 index;
+};
+
+#define to_emif_attr(dev_attr) \
+ container_of(dev_attr, struct emif_attr, attr)
+
+static ssize_t emif_state_show(struct device
[PATCH v3] add the FPGA Device Feature List (DFL) EMIF support
The driver supports the EMIF controller on Intel Programmable Acceleration Card (PAC). The controller manages the on-board memory of the PCIe card. Hi Moritz: I have sent 2 versions of the patch to Krzysztof who maintains the drivers/memory folder. And because this patch depends on the previous fpga patchset "Modularization of DFL private feature drivers" & "add dfl bus support to MODULE_DEVICE_TABLE()", it cannot be applied independently to Krzysztof's branch until next cycle. So he suggests, "please send a v3 of this patch with the fix above and let's apply it via Moritz's tree." So could you help do that? After it got the acked-by from Krzysztof. Thanks, Yilun Xu Yilun (1): memory: dfl-emif: add the DFL EMIF private feature driver .../ABI/testing/sysfs-bus-dfl-devices-emif | 25 +++ drivers/memory/Kconfig | 9 + drivers/memory/Makefile| 2 + drivers/memory/dfl-emif.c | 207 + 4 files changed, 243 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices-emif create mode 100644 drivers/memory/dfl-emif.c -- 2.7.4
Re: [PATCH v2 0/6] tools/bootconfig: Add boot-time tracing script
Hi Steve, Can you also merge this series to tracing tree? Thank you, On Sat, 15 Aug 2020 23:01:00 +0900 Masami Hiramatsu wrote: > Hi, > > This is the 2nd version of the series to introduce scripts for the > boot-time tracing. In this version, I just updated 4/6 according to > Steve's comment. > > Previous series is here: > > https://lkml.kernel.org/r/159704847064.175360.3292152056631660862.stgit@devnote2 > > > Thank you, > > --- > > Masami Hiramatsu (6): > tools/bootconfig: Show bootconfig compact tree from bootconfig file > tools/bootconfig: Add list option > tools/bootconfig: Make all functions static > tools/bootconfig: Add a script to generate ftrace shell-command from > bootconfig > tools/bootconfig: Add a script to generates bootconfig from ftrace > tools/bootconfig: Add --init option for bconf2ftrace.sh > > > MAINTAINERS |1 > tools/bootconfig/main.c | 147 +- > tools/bootconfig/scripts/bconf2ftrace.sh | 199 > tools/bootconfig/scripts/ftrace.sh | 109 + > tools/bootconfig/scripts/ftrace2bconf.sh | 244 > ++ > tools/bootconfig/scripts/xbc.sh | 57 +++ > 6 files changed, 715 insertions(+), 42 deletions(-) > create mode 100755 tools/bootconfig/scripts/bconf2ftrace.sh > create mode 100644 tools/bootconfig/scripts/ftrace.sh > create mode 100755 tools/bootconfig/scripts/ftrace2bconf.sh > create mode 100644 tools/bootconfig/scripts/xbc.sh > > -- > Masami Hiramatsu (Linaro) -- Masami Hiramatsu
[PATCH] drivers:staging:comedi:comedi.h: Fixed typos in comments
Removed repeated words "the" and "in"
Signed-off-by: James Browning
---
drivers/staging/comedi/comedi.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/comedi.h b/drivers/staging/comedi/comedi.h
index 09a940066c0e..b5d00a006dbb 100644
--- a/drivers/staging/comedi/comedi.h
+++ b/drivers/staging/comedi/comedi.h
@@ -680,7 +680,7 @@ struct comedi_rangeinfo {
* value of 1 volt.
*
* The only defined flag value is %RF_EXTERNAL (%0x100), indicating that the
- * the range needs to be multiplied by an external reference.
+ * range needs to be multiplied by an external reference.
*/
struct comedi_krange {
int min;
@@ -970,7 +970,7 @@ enum i8254_mode {
* major reasons exist why this caused major confusion for users:
* 1) The register values are _NOT_ in user documentation, but rather in
* arcane locations, such as a few register programming manuals that are
- * increasingly hard to find and the NI MHDDK (comments in in example
code).
+ * increasingly hard to find and the NI MHDDK (comments in example code).
* There is no one place to find the various valid values of the registers.
* 2) The register values are _NOT_ completely consistent. There is no way
to
* gain any sense of intuition of which values, or even enums one should
use
--
2.25.1
Re: [PATCH v2 3/3] ARM: dts: add Plymovent M2M board
On Sun, Sep 13, 2020 at 12:49:45PM +0800, Shawn Guo wrote: > On Fri, Sep 11, 2020 at 08:03:12AM +0200, Marco Felsch wrote: > > On 20-09-11 07:09, Oleksij Rempel wrote: > > > Plymovent M2M is a control interface produced for the Plymovent filter > > > systems. > > > > > > Signed-off-by: David Jander > > > Signed-off-by: Oleksij Rempel > > > --- > > > arch/arm/boot/dts/Makefile | 1 + > > > arch/arm/boot/dts/imx6dl-plym2m.dts | 394 > > > 2 files changed, 395 insertions(+) > > > create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts > > > > > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > > > index 4572db3fa5ae..3c3811fd8613 100644 > > > --- a/arch/arm/boot/dts/Makefile > > > +++ b/arch/arm/boot/dts/Makefile > > > @@ -455,6 +455,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \ > > > imx6dl-pico-hobbit.dtb \ > > > imx6dl-pico-nymph.dtb \ > > > imx6dl-pico-pi.dtb \ > > > + imx6dl-plym2m.dtb \ > > > imx6dl-prtrvt.dtb \ > > > imx6dl-prtvt7.dtb \ > > > imx6dl-rex-basic.dtb \ > > > diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts > > > b/arch/arm/boot/dts/imx6dl-plym2m.dts > > > new file mode 100644 > > > index ..4f96e05aa03f > > > --- /dev/null > > > +++ b/arch/arm/boot/dts/imx6dl-plym2m.dts > > > @@ -0,0 +1,394 @@ > > > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT > > > +// SPDX-FileCopyrightText: 2014 Protonic Holland > > > +// SPDX-FileCopyrightText: 2020 Oleksij Rempel , > > > Pengutronix > > ^ > > @shawn: I saw a few patches adding these tags. Are they used in the near > > future? > > I'm not sure. I haven't seen this in Documentation/process/license-rules.rst, > nor the discussion around this. Hi Shawn, is it a no go? Should I send a patch with old style copyright text? Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
linux-next: manual merge of the usb tree with the pci tree
Hi all,
Today's linux-next merge of the usb tree got a conflict in:
drivers/pci/controller/pcie-brcmstb.c
between commit:
1cf1b0a6dd95 ("PCI: brcmstb: Add bcm7278 register info")
from the pci tree and commit:
f48cc509c935 ("Revert "PCI: brcmstb: Wait for Raspberry Pi's firmware when
present"")
from the usb tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/pci/controller/pcie-brcmstb.c
index 6e7aa82a54a3,bac63d04297f..
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@@ -1213,8 -929,6 +1211,7 @@@ static int brcm_pcie_probe(struct platf
{
struct device_node *np = pdev->dev.of_node, *msi_np;
struct pci_host_bridge *bridge;
- struct device_node *fw_np;
+ const struct pcie_cfg_data *data;
struct brcm_pcie *pcie;
int ret;
pgpbvxL7Tffh0.pgp
Description: OpenPGP digital signature
KMSAN: uninit-value in hsr_fill_frame_info
Hello, syzbot found the following issue on: HEAD commit:c5a13b33 kmsan: clang-format core git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=13ef204b90 kernel config: https://syzkaller.appspot.com/x/.config?x=20f149ad694ba4be dashboard link: https://syzkaller.appspot.com/bug?extid=e267bed19bfc5478fb33 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1015be7390 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1185669b90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e267bed19bfc5478f...@syzkaller.appspotmail.com hsr0: VLAN not yet supported = BUG: KMSAN: uninit-value in hsr_fill_frame_info+0x3d3/0x570 net/hsr/hsr_forward.c:457 CPU: 1 PID: 8700 Comm: syz-executor512 Not tainted 5.9.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:122 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:219 hsr_fill_frame_info+0x3d3/0x570 net/hsr/hsr_forward.c:457 fill_frame_info net/hsr/hsr_forward.c:520 [inline] hsr_forward_skb+0xc63/0x2610 net/hsr/hsr_forward.c:537 hsr_dev_xmit+0x133/0x230 net/hsr/hsr_device.c:220 __netdev_start_xmit include/linux/netdevice.h:4634 [inline] netdev_start_xmit include/linux/netdevice.h:4648 [inline] xmit_one+0x3cf/0x750 net/core/dev.c:3561 dev_hard_start_xmit net/core/dev.c:3577 [inline] __dev_queue_xmit+0x3aad/0x4470 net/core/dev.c:4136 dev_queue_xmit+0x4b/0x60 net/core/dev.c:4169 packet_snd net/packet/af_packet.c:2989 [inline] packet_sendmsg+0x8542/0x9a80 net/packet/af_packet.c:3014 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] __sys_sendto+0x9dc/0xc80 net/socket.c:1992 __do_sys_sendto net/socket.c:2004 [inline] __se_sys_sendto+0x107/0x130 net/socket.c:2000 __x64_sys_sendto+0x6e/0x90 net/socket.c:2000 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x443d79 Code: e8 8c 07 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 bb 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffdeb5a7c88 EFLAGS: 0246 ORIG_RAX: 002c RAX: ffda RBX: 0003 RCX: 00443d79 RDX: RSI: RDI: 0004 RBP: 7ffdeb5a7ca0 R08: 2000 R09: 0014 R10: R11: 0246 R12: 7ffdeb5a7cb0 R13: R14: R15: Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:143 [inline] kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:126 kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:80 slab_alloc_node mm/slub.c:2907 [inline] __kmalloc_node_track_caller+0x9aa/0x12f0 mm/slub.c:4511 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0x35f/0xb30 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1094 [inline] alloc_skb_with_frags+0x1f2/0xc10 net/core/skbuff.c:5771 sock_alloc_send_pskb+0xc83/0xe50 net/core/sock.c:2348 packet_alloc_skb net/packet/af_packet.c:2837 [inline] packet_snd net/packet/af_packet.c:2932 [inline] packet_sendmsg+0x6abb/0x9a80 net/packet/af_packet.c:3014 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] __sys_sendto+0x9dc/0xc80 net/socket.c:1992 __do_sys_sendto net/socket.c:2004 [inline] __se_sys_sendto+0x107/0x130 net/socket.c:2000 __x64_sys_sendto+0x6e/0x90 net/socket.c:2000 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 = --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: RE: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
Hi Ben On Sun, Sep 20, 2020 at 4:16 PM Ben Levinsky wrote: > > Hi All, > > > -Original Message- > > From: Wendy Liang > > Sent: Friday, September 18, 2020 6:53 PM > > To: Michael Auchter > > Cc: Ben Levinsky ; punit1.agra...@toshiba.co.jp; > > devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux- > > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: RE: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 > > remoteproc driver > > > > HI Michael, Ben, Punit, > > > > On Fri, Sep 18, 2020 at 12:08 PM Michael Auchter > > wrote: > > > > > > Hey Ben, > > > > > > On Fri, Sep 18, 2020 at 06:01:19PM +, Ben Levinsky wrote: > > > > Hi Michael, Punit, > > > > > > > > > -Original Message- > > > > > From: Michael Auchter > > > > > Sent: Friday, September 18, 2020 9:07 AM > > > > > To: Ben Levinsky > > > > > Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; > > linux- > > > > > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > > > > > Subject: Re: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 > > > > > remoteproc driver > > > > > > > > > > On Thu, Sep 17, 2020 at 10:50:42PM +, Ben Levinsky wrote: > > > > > > In addition to device tree, is there particular linker script you > > > > > > use > > > > > > for your R5 application? For example with OCM? As presently this > > > > > > driver only has DDR and TCM as supported regions to load into > > > > > > > > > > The firmware is being loaded to TCM. > > > > > > > > > > I'm able to use this driver to load and run my firmware on both R5 > > > > > cores, but only after I change the incorrect: > > > > > > > > > > rpu_mode = lockstep_mode > > > > > > > > > > assignment to: > > > > > > > > > > rpu_mode = lockstep_mode ? PM_RPU_MODE_LOCKSTEP > > > > > : PM_RPU_MODE_SPLIT; > > > > There was a point raised by Punit that as "it is possible to set R5 to > > > > operatore in split or lock-step mode dynamically" which is true and > > > > can be done via sysfs and the Xilinx firmware kernel code. > > > > > > I'm not familiar with this, and don't see an obvious way to do this > > > (from looking at drivers/firmware/xilinx/). Can you point me to this > > > code? > > > > [Ben Levinsky] A way to do this, though it seems later comments show it is > not an implementation to pursue, is use the RPU configuration API and present > it via sysfs interface a la > https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842232/Zynq+UltraScale+MPSoC+Power+Management+-+Linux+Kernel#ZynqUltraScale%EF%BC%8BMPSoCPowerManagement-LinuxKernel-EnableClock > > > > A suggestion that might clean up the driver so that the whole > > > > rpu_mode, tcm_mode configuration can be simplified and pulled out of > > > > the driver: > > > > - as Punit suggested, remove the lockstep-mode property > > > > - the zynqmp_remoteproc_r5 driver ONLY loads firmware and does > > start/stop. > > > > - the zynqmp_remoteproc_r5 driver does not configure and memory > > regions or the RPU. Let the Xilinx firmware sysfs interface handle this. > > > > > > I don't think this is a good approach. > [Ben Levinsky] ok, noted. Can keep the configuration but still as wendy said > just have lockstep property to denote lockstep mode in RPU and otherwise be > split, for simplicity? > > [Wendy] The TCMs are presented differently in the system depending on > > if RPU is in > > lockstep or split mode. > > > > Not sure if it is allowed to list TCMs registers properties for both > > split mode and lockstep > > mode in the same device node. > > > > Even though, driver can have this information in the code, but I feel > > the device tree is a > > better place for this information. > > And also for predefined shared memories, you will need to know the RPU > > op mode ahead, > > so that you can specify which shared memories belong to which RPU. > > > > To dynamic setup the RPU mode, besides sysfs, setup, if remoteproc can > > support > > device tree overlay, the RPUs can be described with dtbo and loaded at > > runtime. > > > > Just want to understand the case which needs to set RPU mode at runtime? > > I think testing can be one case. > > > [Ben Levinsky] for testing, so far it has been r50/1 split and r5 lockstep [Wendy] I tried to understand the need to change the RPU mode at runtime. What I can think of is for testing purposes. Thanks, Wendy > > Best Regards, > > Wendy > > > > > - How will someone know to configure the RPU mode and TCM mode via > > sysfs? > > > - What happens when someone changes the RPU mode after remoteproc > > has > > > already booted some firmware on it? > > > - What if the kernel is the one booting the R5, not the user? > > > > > > Split vs. lockstep, IMO, needs to be specified as part of the device > > > tree, and this driver needs to handle configuring the RPU mode and TCM > > > modes appropriately. > > > > [Ben Levinsky] Ok, as Wendy suggested would instead the presence of a
Re: RE: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
Hi Ben, On Sun, Sep 20, 2020 at 4:16 PM Ben Levinsky wrote: > > Hi All, > > > -Original Message- > > From: Wendy Liang > > Sent: Friday, September 18, 2020 6:53 PM > > To: Michael Auchter > > Cc: Ben Levinsky ; punit1.agra...@toshiba.co.jp; > > devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux- > > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: RE: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 > > remoteproc driver > > > > HI Michael, Ben, Punit, > > > > On Fri, Sep 18, 2020 at 12:08 PM Michael Auchter > > wrote: > > > > > > Hey Ben, > > > > > > On Fri, Sep 18, 2020 at 06:01:19PM +, Ben Levinsky wrote: > > > > Hi Michael, Punit, > > > > > > > > > -Original Message- > > > > > From: Michael Auchter > > > > > Sent: Friday, September 18, 2020 9:07 AM > > > > > To: Ben Levinsky > > > > > Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; > > linux- > > > > > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > > > > > Subject: Re: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 > > > > > remoteproc driver > > > > > > > > > > On Thu, Sep 17, 2020 at 10:50:42PM +, Ben Levinsky wrote: > > > > > > In addition to device tree, is there particular linker script you > > > > > > use > > > > > > for your R5 application? For example with OCM? As presently this > > > > > > driver only has DDR and TCM as supported regions to load into > > > > > > > > > > The firmware is being loaded to TCM. > > > > > > > > > > I'm able to use this driver to load and run my firmware on both R5 > > > > > cores, but only after I change the incorrect: > > > > > > > > > > rpu_mode = lockstep_mode > > > > > > > > > > assignment to: > > > > > > > > > > rpu_mode = lockstep_mode ? PM_RPU_MODE_LOCKSTEP > > > > > : PM_RPU_MODE_SPLIT; > > > > There was a point raised by Punit that as "it is possible to set R5 to > > > > operatore in split or lock-step mode dynamically" which is true and > > > > can be done via sysfs and the Xilinx firmware kernel code. > > > > > > I'm not familiar with this, and don't see an obvious way to do this > > > (from looking at drivers/firmware/xilinx/). Can you point me to this > > > code? > > > > [Ben Levinsky] A way to do this, though it seems later comments show it is > not an implementation to pursue, is use the RPU configuration API and present > it via sysfs interface a la > https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842232/Zynq+UltraScale+MPSoC+Power+Management+-+Linux+Kernel#ZynqUltraScale%EF%BC%8BMPSoCPowerManagement-LinuxKernel-EnableClock > > > > A suggestion that might clean up the driver so that the whole > > > > rpu_mode, tcm_mode configuration can be simplified and pulled out of > > > > the driver: > > > > - as Punit suggested, remove the lockstep-mode property > > > > - the zynqmp_remoteproc_r5 driver ONLY loads firmware and does > > start/stop. > > > > - the zynqmp_remoteproc_r5 driver does not configure and memory > > regions or the RPU. Let the Xilinx firmware sysfs interface handle this. > > > > > > I don't think this is a good approach. > [Ben Levinsky] ok, noted. Can keep the configuration but still as wendy said > just have lockstep property to denote lockstep mode in RPU and otherwise be > split, for simplicity? > > [Wendy] The TCMs are presented differently in the system depending on > > if RPU is in > > lockstep or split mode. > > > > Not sure if it is allowed to list TCMs registers properties for both > > split mode and lockstep > > mode in the same device node. > > > > Even though, driver can have this information in the code, but I feel > > the device tree is a > > better place for this information. > > And also for predefined shared memories, you will need to know the RPU > > op mode ahead, > > so that you can specify which shared memories belong to which RPU. > > > > To dynamic setup the RPU mode, besides sysfs, setup, if remoteproc can > > support > > device tree overlay, the RPUs can be described with dtbo and loaded at > > runtime. > > > > Just want to understand the case which needs to set RPU mode at runtime? > > I think testing can be one case. > > > [Ben Levinsky] for testing, so far it has been r50/1 split and r5 lockstep > > Best Regards, > > Wendy > > > > > - How will someone know to configure the RPU mode and TCM mode via > > sysfs? > > > - What happens when someone changes the RPU mode after remoteproc > > has > > > already booted some firmware on it? > > > - What if the kernel is the one booting the R5, not the user? > > > > > > Split vs. lockstep, IMO, needs to be specified as part of the device > > > tree, and this driver needs to handle configuring the RPU mode and TCM > > > modes appropriately. > > > > [Ben Levinsky] Ok, as Wendy suggested would instead the presence of a > "lockstep=mode" property indicate lockstep mode and otherwise imply split > mode? > > > Split vs. lockstep already necessitates
Re: [PATCH 2/2] drivers:staging:comedi:comedi.h Fixed typo in comment
On Sun, Sep 20, 2020 at 09:14:49PM -0700, James Browning wrote: > Removed repeated word "in" > > Signed-off-by: James Browning > --- > drivers/staging/comedi/comedi.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) You sent two different patches that did different things, yet had the same exact subject line, which isn't ok. Why not just merge them into the same patch? thanks, greg k-h
Re: [PATCH] mmap_lock: add tracepoints around lock acquisition
On Fri, Sep 18, 2020 at 2:13 AM Axel Rasmussen wrote:
>
> The goal of these tracepoints is to be able to debug lock contention
> issues. This lock is acquired on most (all?) mmap / munmap / page fault
> operations, so a multi-threaded process which does a lot of these can
> experience significant contention.
>
> We trace just before we start acquisition, when the acquisition returns
> (whether it succeeded or not), and when the lock is released (or
> downgraded). The events are broken out by lock type (read / write).
>
> The events are also broken out by memcg path. For container-based
> workloads, users often think of several processes in a memcg as a single
> logical "task", so collecting statistics at this level is useful.
>
> These events *do not* include latency bucket information, which means
> for a proper latency histogram users will need to use BPF instead of
> event histograms. The benefit we get from this is simpler code.
>
> This patch is a no-op if the Kconfig option is not enabled. If it is,
> tracepoints are still disabled by default (configurable at runtime);
> the only fixed cost here is un-inlining a few functions. As best as
> I've been able to measure, the overhead this introduces is a small
> fraction of 1%. Actually hooking up the tracepoints to BPF introduces
> additional overhead, depending on exactly what the BPF program is
> collecting.
Are there any methods to avoid un-inlining these wrappers ?
For example,
// include/linux/mmap_lock.h
void mmap_lock_start_trace_wrapper();
void mmap_lock_acquire_trace_wrapper();
static inline void mmap_write_lock(struct mm_struct *mm)
{
mmap_lock_start_trace_wrapper();
down_write(>mmap_lock);
mmap_lock_acquire_trace_wrapper();
}
// mm/mmap_lock.c
void mmap_lock_start_trace_wrapper()
{
trace_mmap_lock_start();
}
void mmap_lock_start_trace_wrapper()
{
trace_mmap_lock_acquired();
}
> ---
> include/linux/mmap_lock.h| 28 +++-
> include/trace/events/mmap_lock.h | 73 ++
> mm/Kconfig | 17 +++
> mm/Makefile | 1 +
> mm/mmap_lock.c | 224 +++
> 5 files changed, 342 insertions(+), 1 deletion(-)
> create mode 100644 include/trace/events/mmap_lock.h
> create mode 100644 mm/mmap_lock.c
>
> diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
> index 0707671851a8..d12aa2ff6c05 100644
> --- a/include/linux/mmap_lock.h
> +++ b/include/linux/mmap_lock.h
> @@ -1,11 +1,35 @@
> #ifndef _LINUX_MMAP_LOCK_H
> #define _LINUX_MMAP_LOCK_H
>
> +#include
> +#include
> #include
> +#include
> +#include
>
> #define MMAP_LOCK_INITIALIZER(name) \
> .mmap_lock = __RWSEM_INITIALIZER((name).mmap_lock),
>
> +#ifdef CONFIG_MMAP_LOCK_STATS
> +
> +void mmap_init_lock(struct mm_struct *mm);
> +void mmap_write_lock(struct mm_struct *mm);
> +void mmap_write_lock_nested(struct mm_struct *mm, int subclass);
> +int mmap_write_lock_killable(struct mm_struct *mm);
> +bool mmap_write_trylock(struct mm_struct *mm);
> +void mmap_write_unlock(struct mm_struct *mm);
> +void mmap_write_downgrade(struct mm_struct *mm);
> +void mmap_read_lock(struct mm_struct *mm);
> +int mmap_read_lock_killable(struct mm_struct *mm);
> +bool mmap_read_trylock(struct mm_struct *mm);
> +void mmap_read_unlock(struct mm_struct *mm);
> +bool mmap_read_trylock_non_owner(struct mm_struct *mm);
> +void mmap_read_unlock_non_owner(struct mm_struct *mm);
> +void mmap_assert_locked(struct mm_struct *mm);
> +void mmap_assert_write_locked(struct mm_struct *mm);
> +
> +#else /* !CONFIG_MMAP_LOCK_STATS */
> +
> static inline void mmap_init_lock(struct mm_struct *mm)
> {
> init_rwsem(>mmap_lock);
> @@ -63,7 +87,7 @@ static inline void mmap_read_unlock(struct mm_struct *mm)
>
> static inline bool mmap_read_trylock_non_owner(struct mm_struct *mm)
> {
> - if (down_read_trylock(>mmap_lock)) {
> + if (mmap_read_trylock(mm)) {
> rwsem_release(>mmap_lock.dep_map, _RET_IP_);
> return true;
> }
> @@ -87,4 +111,6 @@ static inline void mmap_assert_write_locked(struct
> mm_struct *mm)
> VM_BUG_ON_MM(!rwsem_is_locked(>mmap_lock), mm);
> }
>
> +#endif /* CONFIG_MMAP_LOCK_STATS */
> +
> #endif /* _LINUX_MMAP_LOCK_H */
> diff --git a/include/trace/events/mmap_lock.h
> b/include/trace/events/mmap_lock.h
> new file mode 100644
> index ..549c662e6ed8
> --- /dev/null
> +++ b/include/trace/events/mmap_lock.h
> @@ -0,0 +1,73 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM mmap_lock
> +
> +#if !defined(_TRACE_MMAP_LOCK_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_MMAP_LOCK_H
> +
> +#include
> +#include
> +
> +struct mm_struct;
> +
> +DECLARE_EVENT_CLASS(
> + mmap_lock_template,
> +
> + TP_PROTO(struct mm_struct *mm, const char *memcg_path, u64 duration,
> + bool write, bool success),
> +
> + TP_ARGS(mm,
Re: [PATCH v5 14/17] NTB: Add support for EPF PCI-Express Non-Transparent Bridge
On 9/20/20 9:52 PM, Kishon Vijay Abraham I wrote: > Hi Randy, > > On 18/09/20 9:45 pm, Randy Dunlap wrote: >> On 9/17/20 11:42 PM, Kishon Vijay Abraham I wrote: >>> diff --git a/drivers/ntb/hw/epf/Kconfig b/drivers/ntb/hw/epf/Kconfig >>> new file mode 100644 >>> index ..6197d1aab344 >>> --- /dev/null >>> +++ b/drivers/ntb/hw/epf/Kconfig >>> @@ -0,0 +1,6 @@ >>> +config NTB_EPF >>> + tristate "Generic EPF Non-Transparent Bridge support" >>> + depends on m >>> + help >>> + This driver supports EPF NTB on configurable endpoint. >>> + If unsure, say N. >> >> Hi, >> Why is this driver restricted to 'm' (loadable module)? >> I.e., it cannot be builtin. > > I'm trying to keep all the host side PCI drivers corresponding to the > devices configured using endpoint function drivers as modules and also > not populate MODULE_DEVICE_TABLE() to prevent auto-loading. > > The different endpoint function drivers (right now only pci-epf-test.c > and pci-epf-ntb.c) can use the same device ID and vendorID for > configuring the endpoint devices. So on the host side, it's possible an > un-intended PCI driver can be bound to the device. So in-order to give > users the flexibility of deciding the driver to be bound, I'm trying to > keep it as modules. (Some driver like NTB also uses class code > PCI_CLASS_MEMORY_RAM for binding a driver in addition to deviceID and > vendorID but it need not be the case for all the drivers.) Thanks for the explanation. -- ~Randy
Re: WARNING in tracepoint_add_func
syzbot has found a reproducer for the following issue on:
HEAD commit:325d0eab Merge branch 'akpm' (patches from Andrew)
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16992c8190
kernel config: https://syzkaller.appspot.com/x/.config?x=b12e84189082991c
dashboard link: https://syzkaller.appspot.com/bug?extid=721aa903751db87aa244
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17c797b590
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10569c0390
The issue was bisected to:
commit 58956317c8de52009d1a38a721474c24aef74fe7
Author: David Ahern
Date: Fri Dec 7 20:24:57 2018 +
neighbor: Improve garbage collection
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=146ba85390
final oops: https://syzkaller.appspot.com/x/report.txt?x=166ba85390
console output: https://syzkaller.appspot.com/x/log.txt?x=126ba85390
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+721aa903751db87aa...@syzkaller.appspotmail.com
Fixes: 58956317c8de ("neighbor: Improve garbage collection")
[ cut here ]
WARNING: CPU: 1 PID: 6872 at kernel/tracepoint.c:243
tracepoint_add_func+0x254/0x880 kernel/tracepoint.c:243
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 6872 Comm: syz-executor482 Not tainted 5.9.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x198/0x1fd lib/dump_stack.c:118
panic+0x382/0x7fb kernel/panic.c:231
__warn.cold+0x20/0x4b kernel/panic.c:600
report_bug+0x1bd/0x210 lib/bug.c:198
handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234
exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254
asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
RIP: 0010:tracepoint_add_func+0x254/0x880 kernel/tracepoint.c:243
Code: 44 24 20 48 8b 5b 08 80 38 00 0f 85 6b 05 00 00 48 8b 44 24 08 48 3b 58
08 0f 85 2d ff ff ff 41 bc ef ff ff ff e8 ec 62 fe ff <0f> 0b e8 e5 62 fe ff 44
89 e0 48 83 c4 38 5b 5d 41 5c 41 5d 41 5e
RSP: :c900060f7ac0 EFLAGS: 00010293
RAX: RBX: c9e76000 RCX: 8177dc72
RDX: 888096766000 RSI: 8177dcd4 RDI: 8880a6b2ec48
RBP: 8213fae0 R08: R09: 8a0c176b
R10: 000a R11: R12: ffef
R13: 0002 R14: dc00 R15: 8880a6b2ec10
tracepoint_probe_register_prio kernel/tracepoint.c:315 [inline]
tracepoint_probe_register+0x9c/0xe0 kernel/tracepoint.c:335
__bpf_probe_register kernel/trace/bpf_trace.c:1950 [inline]
bpf_probe_register+0x16c/0x1d0 kernel/trace/bpf_trace.c:1955
bpf_raw_tracepoint_open+0x34e/0xb20 kernel/bpf/syscall.c:2741
__do_sys_bpf+0x1b2f/0x4c60 kernel/bpf/syscall.c:4220
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4415a9
Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
8b 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffc28dd5d08 EFLAGS: 0246 ORIG_RAX: 0141
RAX: ffda RBX: RCX: 004415a9
RDX: 0010 RSI: 2040 RDI: 0011
RBP: 00010308 R08: 004002c8 R09: 004002c8
R10: 0004 R11: 0246 R12: 004023c0
R13: 00402450 R14: R15:
Kernel Offset: disabled
Rebooting in 86400 seconds..
Re: [PATCH v5 14/17] NTB: Add support for EPF PCI-Express Non-Transparent Bridge
Hi Randy, On 18/09/20 9:45 pm, Randy Dunlap wrote: > On 9/17/20 11:42 PM, Kishon Vijay Abraham I wrote: >> diff --git a/drivers/ntb/hw/epf/Kconfig b/drivers/ntb/hw/epf/Kconfig >> new file mode 100644 >> index ..6197d1aab344 >> --- /dev/null >> +++ b/drivers/ntb/hw/epf/Kconfig >> @@ -0,0 +1,6 @@ >> +config NTB_EPF >> +tristate "Generic EPF Non-Transparent Bridge support" >> +depends on m >> +help >> + This driver supports EPF NTB on configurable endpoint. >> + If unsure, say N. > > Hi, > Why is this driver restricted to 'm' (loadable module)? > I.e., it cannot be builtin. I'm trying to keep all the host side PCI drivers corresponding to the devices configured using endpoint function drivers as modules and also not populate MODULE_DEVICE_TABLE() to prevent auto-loading. The different endpoint function drivers (right now only pci-epf-test.c and pci-epf-ntb.c) can use the same device ID and vendorID for configuring the endpoint devices. So on the host side, it's possible an un-intended PCI driver can be bound to the device. So in-order to give users the flexibility of deciding the driver to be bound, I'm trying to keep it as modules. (Some driver like NTB also uses class code PCI_CLASS_MEMORY_RAM for binding a driver in addition to deviceID and vendorID but it need not be the case for all the drivers.) Thanks Kishon
[PATCH v2 2/2] vfio/pci: Don't regenerate vconfig for all BARs if !bardirty
Now we regenerate vconfig for all the BARs via vfio_bar_fixup(), every time
any offset of any of them are read. Though BARs aren't re-read regularly,
the regeneration can be avoid if no BARs had been written since they were
last read, in which case the vdev->bardirty is false.
Let's predicate the vfio_bar_fixup() on the bardirty so that it can return
immediately if !bardirty.
Suggested-by: Alex Williamson
Signed-off-by: Zenghui Yu
---
* From v1:
- Per Alex's suggestion, let vfio_bar_fixup() test vdev->bardirty to
avoid doing work if bardirty is false, instead of removing it entirely.
- Rewrite the commit message.
drivers/vfio/pci/vfio_pci_config.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index d98843feddce..5e02ba07e8e8 100644
--- a/drivers/vfio/pci/vfio_pci_config.c
+++ b/drivers/vfio/pci/vfio_pci_config.c
@@ -467,6 +467,9 @@ static void vfio_bar_fixup(struct vfio_pci_device *vdev)
__le32 *vbar;
u64 mask;
+ if (!vdev->bardirty)
+ return;
+
vbar = (__le32 *)>vconfig[PCI_BASE_ADDRESS_0];
for (i = 0; i < PCI_STD_NUM_BARS; i++, vbar++) {
--
2.19.1
[PATCH v2 1/2] vfio/pci: Remove redundant declaration of vfio_pci_driver
It was added by commit 137e5531351d ("vfio/pci: Add sriov_configure
support") but duplicates a forward declaration earlier in the file.
Remove it.
Signed-off-by: Zenghui Yu
Reviewed-by: Cornelia Huck
---
* From v1:
- Clarify the commit message per Alex's suggestion.
- Add Cornelia's R-b tag.
drivers/vfio/pci/vfio_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 1ab1f5cda4ac..da68e2f86622 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1862,7 +1862,6 @@ static const struct vfio_device_ops vfio_pci_ops = {
static int vfio_pci_reflck_attach(struct vfio_pci_device *vdev);
static void vfio_pci_reflck_put(struct vfio_pci_reflck *reflck);
-static struct pci_driver vfio_pci_driver;
static int vfio_pci_bus_notifier(struct notifier_block *nb,
unsigned long action, void *data)
--
2.19.1
kernel v5.9-rc6 not compiling
Hi. I've been building kernels weekly since 1996. Never had one not build before today. v5.9-rc6 does not compile. Error: AR drivers/gpu/built-in.a make: *** [Makefile:1784: drivers] Error 2 CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC drivers/dax/super.o drivers/dax/super.c:325:6: error: redefinition of ‘dax_supported’ 325 | bool dax_supported(struct dax_device *dax_dev, struct block_device *bdev, | ^ In file included from drivers/dax/super.c:16: ./include/linux/dax.h:162:20: note: previous definition of ‘dax_supported’ was here 162 | static inline bool dax_supported(struct dax_device *dax_dev, | ^ make[2]: *** [scripts/Makefile.build:283: drivers/dax/super.o] Error 1 make[1]: *** [scripts/Makefile.build:500: drivers/dax] Error 2 make: *** [Makefile:1784: drivers] Error 2 sed: can't read modules.order: No such file or directory make: *** [Makefile:1416: _modinst_] Error 2 sh ./arch/x86/boot/install.sh 5.9.0-rc6 arch/x86/boot/bzImage \ System.map "/boot" *** Missing file: arch/x86/boot/bzImage *** You need to run "make" before "make install". make[1]: *** [arch/x86/boot/Makefile:160: install] Error 1 make: *** [arch/x86/Makefile:274: install] Error 2 You may need to edit your /etc/default/grub file ... so its not like I'm stuck, I can pick any of a number of old kernels from the bootloader. And I've had a lot of rc kernels over the years that would build, but weren't finished (occasionally I would get an oops in dmesg). Again pick another kernel from the bootloader, preferrably a more stable non-rc one. But I don't think I've ever had a kernel not compile before. I'm waiting for the nouveau drivers to firm up, but DAX is page cache for ext2/3/4 file systems (and I use ext4). Hopefully my report is useful. Thank you.
Re: let import_iovec deal with compat_iovecs as well
On Sat, Sep 19, 2020 at 02:24:10PM +, David Laight wrote: > I thought about that change while writing my import_iovec() => iovec_import() > patch - and thought that the io_uring code would (as usual) cause grief. > > Christoph - did you see those patches? No.
Re: [PATCH v5 12/17] PCI: endpoint: Add EP function driver to provide NTB functionality
Hi Randy, On 18/09/20 9:47 pm, Randy Dunlap wrote: > On 9/17/20 11:42 PM, Kishon Vijay Abraham I wrote: >> diff --git a/drivers/pci/endpoint/functions/Kconfig >> b/drivers/pci/endpoint/functions/Kconfig >> index 8820d0f7ec77..55ac7bb2d469 100644 >> --- a/drivers/pci/endpoint/functions/Kconfig >> +++ b/drivers/pci/endpoint/functions/Kconfig >> @@ -12,3 +12,15 @@ config PCI_EPF_TEST >> for PCI Endpoint. >> >> If in doubt, say "N" to disable Endpoint test driver. >> + >> +config PCI_EPF_NTB >> +tristate "PCI Endpoint NTB driver" >> +depends on PCI_ENDPOINT >> +help >> + Select this configuration option to enable the NTB driver >> + for PCI Endpoint. NTB driver implements NTB controller >> + functionality using multiple PCIe endpoint instances. It >> + can support NTB endpoint function devices created using >> + device tree. > > Indent help text with one tab + 2 spaces... > according to coding-style.rst. Okay, will fix this. Thanks Kishon
Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
On Sun, Sep 20, 2020 at 12:14:49PM -0700, Andy Lutomirski wrote: > I wonder if this is really quite cast in stone. We could also have > FMODE_SHITTY_COMPAT and set that when a file like this is *opened* in > compat mode. Then that particular struct file would be read and > written using the compat data format. The change would be > user-visible, but the user that would see it would be very strange > indeed. > > I don't have a strong opinion as to whether that is better or worse > than denying io_uring access to these things, but at least it moves > the special case out of io_uring. open could have happened through an io_uring thread a well, so I don't see how this would do anything but move the problem to a different place. > > --Andy ---end quoted text---
[PATCH v4 4/4] Bluetooth: Add toggle to switch off interleave scan
This patch add a configurable parameter to switch off the interleave
scan feature.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
---
Changes in v4:
- Set EnableAdvMonInterleaveScan default to Disable
- Fix 80 chars limit in mgmt_config.c
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 1 +
net/bluetooth/hci_request.c | 3 ++-
net/bluetooth/mgmt_config.c | 5 +
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 179350f869fdb..c3253f1cac0c2 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -363,6 +363,7 @@ struct hci_dev {
__u32 clock;
__u16 advmon_allowlist_duration;
__u16 advmon_no_filter_duration;
+ __u16 enable_advmon_interleave_scan;
__u16 devid_source;
__u16 devid_vendor;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 6c8850149265a..d5769ae682893 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3595,6 +3595,7 @@ struct hci_dev *hci_alloc_dev(void)
/* The default values will be chosen in the future */
hdev->advmon_allowlist_duration = 300;
hdev->advmon_no_filter_duration = 500;
+ hdev->enable_advmon_interleave_scan = 0x; /* Default to disable */
hdev->sniff_max_interval = 800;
hdev->sniff_min_interval = 80;
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 1fcf6736811e4..bb38e1dead68f 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -500,7 +500,8 @@ static void __hci_update_background_scan(struct hci_request
*req)
if (hci_dev_test_flag(hdev, HCI_LE_SCAN))
hci_req_add_le_scan_disable(req, false);
- if (!update_adv_monitor_scan_state(hdev)) {
+ if (!hdev->enable_advmon_interleave_scan ||
+ !update_adv_monitor_scan_state(hdev)) {
hci_req_add_le_passive_scan(req);
bt_dev_dbg(hdev, "%s starting background scanning",
hdev->name);
diff --git a/net/bluetooth/mgmt_config.c b/net/bluetooth/mgmt_config.c
index 2d3ad288c78ac..34585ab4680b5 100644
--- a/net/bluetooth/mgmt_config.c
+++ b/net/bluetooth/mgmt_config.c
@@ -69,6 +69,7 @@ int read_def_system_config(struct sock *sk, struct hci_dev
*hdev, void *data,
def_le_autoconnect_timeout),
HDEV_PARAM_U16(0x001d, advmon_allowlist_duration),
HDEV_PARAM_U16(0x001e, advmon_no_filter_duration),
+ HDEV_PARAM_U16(0x001f, enable_advmon_interleave_scan),
};
struct mgmt_rp_read_def_system_config *rp = (void *)params;
@@ -142,6 +143,7 @@ int set_def_system_config(struct sock *sk, struct hci_dev
*hdev, void *data,
case 0x001b:
case 0x001d:
case 0x001e:
+ case 0x001f:
if (len != sizeof(u16)) {
bt_dev_warn(hdev, "invalid length %d, exp %zu
for type %d",
len, sizeof(u16), type);
@@ -261,6 +263,9 @@ int set_def_system_config(struct sock *sk, struct hci_dev
*hdev, void *data,
case 0x0001e:
hdev->advmon_no_filter_duration = TLV_GET_LE16(buffer);
break;
+ case 0x0001f:
+ hdev->enable_advmon_interleave_scan =
TLV_GET_LE16(buffer);
+ break;
default:
bt_dev_warn(hdev, "unsupported parameter %u", type);
break;
--
2.28.0.681.g6f77f65b4e-goog
[PATCH v4 3/4] Bluetooth: Handle active scan case
This patch adds code to handle the active scan during interleave
scan. The interleave scan will be canceled when users start active scan,
and it will be restarted after active scan stopped.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
---
(no changes since v1)
net/bluetooth/hci_request.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index d9082019b6386..1fcf6736811e4 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -3085,8 +3085,10 @@ static int active_scan(struct hci_request *req, unsigned
long opt)
* running. Thus, we should temporarily stop it in order to set the
* discovery scanning parameters.
*/
- if (hci_dev_test_flag(hdev, HCI_LE_SCAN))
+ if (hci_dev_test_flag(hdev, HCI_LE_SCAN)) {
hci_req_add_le_scan_disable(req, false);
+ cancel_interleave_scan(hdev);
+ }
/* All active scans will be done with either a resolvable private
* address (when privacy feature has been enabled) or non-resolvable
--
2.28.0.681.g6f77f65b4e-goog
[PATCH v4 2/4] Bluetooth: Handle system suspend resume case
This patch adds code to handle the system suspension during interleave
scan. The interleave scan will be canceled when the system is going to
sleep, and will be restarted after waking up.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
Reviewed-by: Abhishek Pandit-Subedi
Reviewed-by: Miao-chen Chou
---
(no changes since v1)
net/bluetooth/hci_request.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 89443b48d90ce..d9082019b6386 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1081,6 +1081,9 @@ void hci_req_add_le_passive_scan(struct hci_request *req)
filter_policy |= 0x02;
if (hdev->suspended) {
+ /* Block suspend notifier on response */
+ set_bit(SUSPEND_SCAN_ENABLE, hdev->suspend_tasks);
+
window = hdev->le_scan_window_suspend;
interval = hdev->le_scan_int_suspend;
} else if (hci_is_le_conn_scanning(hdev)) {
@@ -1167,10 +1170,8 @@ static void hci_req_config_le_suspend_scan(struct
hci_request *req)
hci_req_add_le_scan_disable(req, false);
/* Configure params and enable scanning */
- hci_req_add_le_passive_scan(req);
+ __hci_update_background_scan(req);
- /* Block suspend notifier on response */
- set_bit(SUSPEND_SCAN_ENABLE, req->hdev->suspend_tasks);
}
static void cancel_adv_timeout(struct hci_dev *hdev)
@@ -1282,8 +1283,10 @@ void hci_req_prepare_suspend(struct hci_dev *hdev, enum
suspended_state next)
hci_req_add(, HCI_OP_WRITE_SCAN_ENABLE, 1, _scan);
/* Disable LE passive scan if enabled */
- if (hci_dev_test_flag(hdev, HCI_LE_SCAN))
+ if (hci_dev_test_flag(hdev, HCI_LE_SCAN)) {
+ cancel_interleave_scan(hdev);
hci_req_add_le_scan_disable(, false);
+ }
/* Mark task needing completion */
set_bit(SUSPEND_SCAN_DISABLE, hdev->suspend_tasks);
--
2.28.0.681.g6f77f65b4e-goog
[PATCH v4 1/4] Bluetooth: Interleave with allowlist scan
This patch implements the interleaving between allowlist scan and
no-filter scan. It'll be used to save power when at least one monitor is
registered and at least one pending connection or one device to be
scanned for.
The durations of the allowlist scan and the no-filter scan are
controlled by MGMT command: Set Default System Configuration. The
default values are set randomly for now.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
---
Changes in v4:
- Rebase to bluetooth-next/master (previous 2 patches are applied)
- Fix over 80 chars limit in mgmt_config.c
- Set EnableAdvMonInterleaveScan default to Disable
Changes in v3:
- Remove 'Bluez' prefix
Changes in v2:
- remove 'case 0x001c' in mgmt_config.c
include/net/bluetooth/hci_core.h | 10 +++
net/bluetooth/hci_core.c | 4 +
net/bluetooth/hci_request.c | 137 +--
net/bluetooth/mgmt_config.c | 10 +++
4 files changed, 153 insertions(+), 8 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 9873e1c8cd163..179350f869fdb 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -361,6 +361,8 @@ struct hci_dev {
__u8ssp_debug_mode;
__u8hw_error_code;
__u32 clock;
+ __u16 advmon_allowlist_duration;
+ __u16 advmon_no_filter_duration;
__u16 devid_source;
__u16 devid_vendor;
@@ -542,6 +544,14 @@ struct hci_dev {
struct delayed_work rpa_expired;
bdaddr_trpa;
+ enum {
+ ADV_MONITOR_SCAN_NONE,
+ ADV_MONITOR_SCAN_NO_FILTER,
+ ADV_MONITOR_SCAN_ALLOWLIST
+ } adv_monitor_scan_state;
+
+ struct delayed_work interleave_adv_monitor_scan;
+
#if IS_ENABLED(CONFIG_BT_LEDS)
struct led_trigger *power_led;
#endif
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index f30a1f5950e15..6c8850149265a 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3592,6 +3592,10 @@ struct hci_dev *hci_alloc_dev(void)
hdev->cur_adv_instance = 0x00;
hdev->adv_instance_timeout = 0;
+ /* The default values will be chosen in the future */
+ hdev->advmon_allowlist_duration = 300;
+ hdev->advmon_no_filter_duration = 500;
+
hdev->sniff_max_interval = 800;
hdev->sniff_min_interval = 80;
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index d2b06f5c93804..89443b48d90ce 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -378,6 +378,57 @@ void __hci_req_write_fast_connectable(struct hci_request
*req, bool enable)
hci_req_add(req, HCI_OP_WRITE_PAGE_SCAN_TYPE, 1, );
}
+static void start_interleave_scan(struct hci_dev *hdev)
+{
+ hdev->adv_monitor_scan_state = ADV_MONITOR_SCAN_NO_FILTER;
+ queue_delayed_work(hdev->req_workqueue,
+ >interleave_adv_monitor_scan, 0);
+}
+
+static bool is_interleave_scanning(struct hci_dev *hdev)
+{
+ return hdev->adv_monitor_scan_state != ADV_MONITOR_SCAN_NONE;
+}
+
+static void cancel_interleave_scan(struct hci_dev *hdev)
+{
+ bt_dev_dbg(hdev, "%s cancelling interleave scan", hdev->name);
+
+ cancel_delayed_work_sync(>interleave_adv_monitor_scan);
+
+ hdev->adv_monitor_scan_state = ADV_MONITOR_SCAN_NONE;
+}
+
+/* Return true if interleave_scan is running after exiting this function,
+ * otherwise, return false
+ */
+static bool update_adv_monitor_scan_state(struct hci_dev *hdev)
+{
+ if (!hci_is_adv_monitoring(hdev) ||
+ (list_empty(>pend_le_conns) &&
+list_empty(>pend_le_reports))) {
+ if (is_interleave_scanning(hdev)) {
+ /* If the interleave condition no longer holds, cancel
+* the existed interleave scan.
+*/
+ cancel_interleave_scan(hdev);
+ }
+ return false;
+ }
+
+ if (!is_interleave_scanning(hdev)) {
+ /* If there is at least one ADV monitors and one pending LE
+* connection or one device to be scanned for, we should
+* alternate between allowlist scan and one without any filters
+* to save power.
+*/
+ start_interleave_scan(hdev);
+ bt_dev_dbg(hdev, "%s starting interleave scan", hdev->name);
+ }
+
+ return true;
+}
+
/* This function controls the background scanning based on hdev->pend_le_conns
* list. If there are pending LE connection we start the background scanning,
* otherwise we stop it.
@@ -449,9 +500,11 @@ static void __hci_update_background_scan(struct
hci_request *req)
if (hci_dev_test_flag(hdev, HCI_LE_SCAN))
[PATCH 2/2] drivers:staging:comedi:comedi.h Fixed typo in comment
Removed repeated word "in"
Signed-off-by: James Browning
---
drivers/staging/comedi/comedi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/comedi.h b/drivers/staging/comedi/comedi.h
index 3bc74bea830d..b5d00a006dbb 100644
--- a/drivers/staging/comedi/comedi.h
+++ b/drivers/staging/comedi/comedi.h
@@ -970,7 +970,7 @@ enum i8254_mode {
* major reasons exist why this caused major confusion for users:
* 1) The register values are _NOT_ in user documentation, but rather in
* arcane locations, such as a few register programming manuals that are
- * increasingly hard to find and the NI MHDDK (comments in in example
code).
+ * increasingly hard to find and the NI MHDDK (comments in example code).
* There is no one place to find the various valid values of the registers.
* 2) The register values are _NOT_ completely consistent. There is no way
to
* gain any sense of intuition of which values, or even enums one should
use
--
2.25.1
[PATCH 1/2] drivers:staging:comedi:comedi.h Fixed typo in comment
Removed repeated "the".
Signed-off-by: James Browning
---
drivers/staging/comedi/comedi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/comedi.h b/drivers/staging/comedi/comedi.h
index 09a940066c0e..3bc74bea830d 100644
--- a/drivers/staging/comedi/comedi.h
+++ b/drivers/staging/comedi/comedi.h
@@ -680,7 +680,7 @@ struct comedi_rangeinfo {
* value of 1 volt.
*
* The only defined flag value is %RF_EXTERNAL (%0x100), indicating that the
- * the range needs to be multiplied by an external reference.
+ * range needs to be multiplied by an external reference.
*/
struct comedi_krange {
int min;
--
2.25.1
[RFC PATCH] arm64: dts: mt8183: Add arm,no-tick-in-suspend
The armv8-timer on MT8183 (kukui family) actually ticks in suspend,
but its precision is so low (measured 400+ ppm -- 35 seconds/day)
that it's actually better to use a fallback option (RTC).
Signed-off-by: Nicolas Boichat
---
We asked MTK if there is anything that can be done to make the
archtimer more precise in suspend, but that does not seem to
be possible.
Ideally we'd like a arm,tick-in-suspend-but-use-something-else-if-possible
property, but the rating in [1] cannot be used, as the RTC
fallback is handled separately [2].
I don't know if this kind of issues happened in the past, one
possible compromise is to add the option to kukui board only,
since we _know_ there is an RTC there (which, technically, may
not be the case on every single MT8183 platform).
A more complete solution would involved quite a bit of
refactoring in the timekeeping/rtc framework.
[1] https://elixir.bootlin.com/linux/v5.8/source/kernel/time/clocksource.c#L486
[2] https://elixir.bootlin.com/linux/v5.8/source/kernel/time/timekeeping.c#L1693
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index f9b60e3d085c..ebcb2309017d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -219,6 +219,7 @@ timer {
,
,
;
+ arm,no-tick-in-suspend;
};
soc {
--
2.28.0.681.g6f77f65b4e-goog
linux-next: build failure after merge of the iommu tree
Hi all,
After merging the iommu tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/msm_iommu.c: In function 'msm_iommu_pagetable_unmap':
drivers/gpu/drm/msm/msm_iommu.c:46:2: error: implicit declaration of function
'iommu_flush_tlb_all'; did you mean 'iommu_flush_iotlb_all'?
[-Werror=implicit-function-declaration]
46 | iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
| ^~~
| iommu_flush_iotlb_all
Caused by commit
aae4c8e27bd7 ("iommu: Rename iommu_tlb_* functions to iommu_iotlb_*")
interacting with commit
b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
from the drm-msm tree.
I have applied the following merge fix patch. Someone will need to tell
Linus about this fix up when the trees get merged.
From: Stephen Rothwell
Date: Mon, 21 Sep 2020 14:04:14 +1000
Subject: [PATCH] merge fix upt for iommu_flush_iotlb_all() rename
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/msm/msm_iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 3a83ffdb3b90..22ac7c692a81 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -43,7 +43,7 @@ static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu, u64
iova,
size -= 4096;
}
- iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
+ iommu_flush_iotlb_all(to_msm_iommu(pagetable->parent)->domain);
return (unmapped == size) ? 0 : -EINVAL;
}
@@ -199,7 +199,7 @@ struct msm_mmu *msm_iommu_pagetable_create(struct msm_mmu
*parent)
/*
* TODO we would like each set of page tables to have a unique ASID
-* to optimize TLB invalidation. But iommu_flush_tlb_all() will
+* to optimize TLB invalidation. But iommu_flush_iotlb_all() will
* end up flushing the ASID used for TTBR1 pagetables, which is not
* what we want. So for now just use the same ASID as TTBR1.
*/
--
2.28.0
--
Cheers,
Stephen Rothwell
pgptBqbiEedHY.pgp
Description: OpenPGP digital signature
[PATCH] mm/mempolicy: remove or narrow the lock on current
It is not necessary to hold the lock of current when setting nodemask of
a new policy.
Signed-off-by: Wei Yang
---
mm/mempolicy.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 906adc58d86f..3fde772ef5ef 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -875,13 +875,12 @@ static long do_set_mempolicy(unsigned short mode,
unsigned short flags,
goto out;
}
- task_lock(current);
ret = mpol_set_nodemask(new, nodes, scratch);
if (ret) {
- task_unlock(current);
mpol_put(new);
goto out;
}
+ task_lock(current);
old = current->mempolicy;
current->mempolicy = new;
if (new && new->mode == MPOL_INTERLEAVE)
@@ -1324,9 +1323,7 @@ static long do_mbind(unsigned long start, unsigned long
len,
NODEMASK_SCRATCH(scratch);
if (scratch) {
mmap_write_lock(mm);
- task_lock(current);
err = mpol_set_nodemask(new, nmask, scratch);
- task_unlock(current);
if (err)
mmap_write_unlock(mm);
} else
--
2.20.1 (Apple Git-117)
Re: PROBLEM: 5.9.0-rc6 fails to compile due to 'redefinition of ‘dax_supported’'
On 9/20/20 7:25 PM, Stuart Little wrote:
An update on this: I've done a bisect, with the following result.
--- cut here ---
e2ec5128254518cae320d5dc631b71b94160f663 is the first bad commit
commit e2ec5128254518cae320d5dc631b71b94160f663
Author: Jan Kara
Date: Sun Sep 20 08:54:42 2020 -0700
dm: Call proper helper to determine dax support
DM was calling generic_fsdax_supported() to determine whether a device
referenced in the DM table supports DAX. However this is a helper for
"leaf" device drivers so that
they don't have to duplicate common generic checks. High level code
should call dax_supported() helper which that calls into appropriate
helper for the particular device. This problem manifested itself as
kernel messages:
dm-3: error: dax access failed (-95)
when lvm2-testsuite run in cases where a DM device was stacked on top of
another DM device.
Fixes: 7bf7eac8d648 ("dax: Arrange for dax_supported check to span multiple devices")
Cc:
Tested-by: Adrian Huang
Signed-off-by: Jan Kara
Acked-by: Mike Snitzer
Reported-by: kernel test robot
Link:
https://lore.kernel.org/r/160061715195.13131.5503173247632041975.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
drivers/dax/super.c | 4
drivers/md/dm-table.c | 10 +++---
include/linux/dax.h | 22 --
3 files changed, 31 insertions(+), 5 deletions(-)
--- end ---
Confirm that reverting this patch, 5.9-rc6 compiles OK ...
RG.
[PATCH] clk: clk-prima2: fix return value check in prima2_clk_init()
In case of error, the function clk_register() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Xu Wang
---
drivers/clk/sirf/clk-prima2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sirf/clk-prima2.c b/drivers/clk/sirf/clk-prima2.c
index 45dcbc9e0302..d17b345f4d2d 100644
--- a/drivers/clk/sirf/clk-prima2.c
+++ b/drivers/clk/sirf/clk-prima2.c
@@ -134,7 +134,7 @@ static void __init prima2_clk_init(struct device_node *np)
for (i = pll1; i < maxclk; i++) {
prima2_clks[i] = clk_register(NULL, prima2_clk_hw_array[i]);
- BUG_ON(!prima2_clks[i]);
+ BUG_ON(IS_ERR(prima2_clks[i]));
}
clk_register_clkdev(prima2_clks[cpu], NULL, "cpu");
clk_register_clkdev(prima2_clks[io], NULL, "io");
--
2.17.1
Re: [PATCH v2 2/2] ARM: support PHYS_OFFSET minimum aligned at 64KiB boundary
On 2020/9/17 22:00, Ard Biesheuvel wrote: > On Tue, 15 Sep 2020 at 22:06, Russell King - ARM Linux admin > wrote: >> >> On Tue, Sep 15, 2020 at 09:16:15PM +0800, Zhen Lei wrote: >>> Currently, only support the kernels where the base of physical memory is >>> at a 16MiB boundary. Because the add/sub instructions only contains 8bits >>> unrotated value. But we can use one more "add/sub" instructions to handle >>> bits 23-16. The performance will be slightly affected. >>> >>> Since most boards meet 16 MiB alignment, so add a new configuration >>> option ARM_PATCH_PHYS_VIRT_RADICAL (default n) to control it. Say Y if >>> anyone really needs it. >>> >>> All r0-r7 (r1 = machine no, r2 = atags or dtb, in the start-up phase) are >>> used in __fixup_a_pv_table() now, but the callee saved r11 is not used in >>> the whole head.S file. So choose it. >>> >>> Because the calculation of "y = x + __pv_offset[63:24]" have been done, >>> so we only need to calculate "y = y + __pv_offset[23:16]", that's why >>> the parameters "to" and "from" of __pv_stub() and __pv_add_carry_stub() >>> in the scope of CONFIG_ARM_PATCH_PHYS_VIRT_RADICAL are all passed "t" >>> (above y). >>> >>> Signed-off-by: Zhen Lei >>> --- >>> arch/arm/Kconfig | 18 +- >>> arch/arm/include/asm/memory.h | 16 +--- >>> arch/arm/kernel/head.S| 25 +++-- >>> 3 files changed, 49 insertions(+), 10 deletions(-) >>> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >>> index e00d94b16658765..19fc2c746e2ce29 100644 >>> --- a/arch/arm/Kconfig >>> +++ b/arch/arm/Kconfig >>> @@ -240,12 +240,28 @@ config ARM_PATCH_PHYS_VIRT >>> kernel in system memory. >>> >>> This can only be used with non-XIP MMU kernels where the base >>> - of physical memory is at a 16MB boundary. >>> + of physical memory is at a 16MiB boundary. >>> >>> Only disable this option if you know that you do not require >>> this feature (eg, building a kernel for a single machine) and >>> you need to shrink the kernel to the minimal size. >>> >>> +config ARM_PATCH_PHYS_VIRT_RADICAL >>> + bool "Support PHYS_OFFSET minimum aligned at 64KiB boundary" >>> + default n >> >> Please drop the "default n" - this is the default anyway. >> >>> @@ -236,6 +243,9 @@ static inline unsigned long __phys_to_virt(phys_addr_t >>> x) >>>* in place where 'r' 32 bit operand is expected. >>>*/ >>> __pv_stub((unsigned long) x, t, "sub", __PV_BITS_31_24); >>> +#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_RADICAL >>> + __pv_stub((unsigned long) t, t, "sub", __PV_BITS_23_16); >> >> t is already unsigned long, so this cast is not necessary. >> >> I've been debating whether it would be better to use "movw" for this >> for ARMv7. In other words: >> >> movwtmp, #16-bit >> adds%Q0, %1, tmp, lsl #16 >> adc %R0, %R0, #0 >> >> It would certainly be less instructions, but at the cost of an >> additional register - and we'd have to change the fixup code to >> know about movw. >> >> Thoughts? >> > > Since LPAE implies v7, we can use movw unconditionally, which is nice. > > There is no need to use an additional temp register, as we can use the > register holding the high word. (There is no need for the mov_hi macro > to be separate) > > 0: movw%R0, #low offset >> 16 >adds%Q0, %1, %R0, lsl #16 > 1: mov %R0, #high offset >adc %R0, %R0, #0 >.pushsection .pv_table,"a" >.long 0b, 1b >.popsection > > The only problem is distinguishing the two mov instructions from each The #high offset can also consider use movw, it just save two bytes in the thumb2 scenario. We can store different imm16 value for high_offset and low_offset, so that we can distinguish them in __fixup_a_pv_table(). This will make the final implementation of the code look more clear and consistent, especially THUMB2. Let me try it. > other, but that should not be too hard I think. > > . >
[PATCH v7 4/7] perf util: Link stream pair
In previous patch, we have created an evsel_streams for one event,
and top N hottest streams will be saved in a stream array in
evsel_streams.
This patch compares total streams among two evsel_streams.
Once two streams are fully matched, they will be linked as
a pair. From the pair, we can know which streams are matched.
Signed-off-by: Jin Yao
---
v7:
- Rename functions with 'stream__' prefix.
v6:
- Rebase to perf/core
v5:
- Remove enum stream_type
v4:
- New patch in v4.
tools/perf/util/stream.c | 40
tools/perf/util/stream.h | 4
2 files changed, 44 insertions(+)
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index e1c7d6c6126b..0d6a7452320a 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -175,3 +175,43 @@ struct evsel_streams *evsel_streams__entry(struct
evlist_streams *els,
return NULL;
}
+
+static struct stream *stream__callchain_match(struct stream *base_stream,
+ struct evsel_streams *es_pair)
+{
+ for (int i = 0; i < es_pair->nr_streams; i++) {
+ struct stream *pair_stream = _pair->streams[i];
+
+ if (callchain_cnode_matched(base_stream->cnode,
+ pair_stream->cnode)) {
+ return pair_stream;
+ }
+ }
+
+ return NULL;
+}
+
+static struct stream *stream__match(struct stream *base_stream,
+ struct evsel_streams *es_pair)
+{
+ return stream__callchain_match(base_stream, es_pair);
+}
+
+static void stream__link(struct stream *base_stream, struct stream
*pair_stream)
+{
+ base_stream->pair_cnode = pair_stream->cnode;
+ pair_stream->pair_cnode = base_stream->cnode;
+}
+
+void evsel_streams__match(struct evsel_streams *es_base,
+ struct evsel_streams *es_pair)
+{
+ for (int i = 0; i < es_base->nr_streams; i++) {
+ struct stream *base_stream = _base->streams[i];
+ struct stream *pair_stream;
+
+ pair_stream = stream__match(base_stream, es_pair);
+ if (pair_stream)
+ stream__link(base_stream, pair_stream);
+ }
+}
diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
index f01335677479..cb131f41f5b1 100644
--- a/tools/perf/util/stream.h
+++ b/tools/perf/util/stream.h
@@ -6,6 +6,7 @@
struct stream {
struct callchain_node *cnode;
+ struct callchain_node *pair_cnode;
};
struct evsel_streams {
@@ -30,4 +31,7 @@ struct evlist_streams *evlist__create_streams(struct evlist
*evlist,
struct evsel_streams *evsel_streams__entry(struct evlist_streams *els,
int evsel_idx);
+void evsel_streams__match(struct evsel_streams *es_base,
+ struct evsel_streams *es_pair);
+
#endif /* __PERF_STREAM_H */
--
2.17.1
[PATCH v7 7/7] perf diff: Support hot streams comparison
This patch enables perf-diff with "--stream" option. "--stream": Enable hot streams comparison Now let's see example. perf record -b ... Generate perf.data.old with branch data perf record -b ... Generate perf.data with branch data perf diff --stream [ Matched hot streams ] hot chain pair 1: cycles: 1, hits: 27.77% cycles: 1, hits: 9.24% --- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 hot chain pair 2: cycles: 34, hits: 20.06%cycles: 27, hits: 16.98% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 __random_r random_r.c:357 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 __random random.c:288 rand rand.c:27 rand rand.c:27 rand rand.c:26 rand rand.c:26 rand@pltrand@plt rand@pltrand@plt compute_flag div.c:25 compute_flag div.c:25 compute_flag div.c:22 compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:40 main div.c:40 main div.c:39 main div.c:39 hot chain pair 3: cycles: 9, hits: 4.48% cycles: 6, hits: 4.51% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 [ Hot streams in old perf data only ] hot chain 1: cycles: 18, hits: 6.75% -- __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 rand rand.c:27 rand rand.c:26 rand@plt rand@plt compute_flag div.c:25 compute_flag div.c:22 main div.c:40 hot chain 2: cycles: 29, hits: 2.78% -- compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:39 [ Hot streams in new perf data only ] hot chain 1: cycles: 4, hits: 4.54% -- main div.c:42 compute_flag div.c:28 hot chain 2: cycles: 5, hits: 3.51% -- main div.c:39 main div.c:44 main div.c:42 compute_flag div.c:28 Signed-off-by: Jin Yao --- v7: - Use new struct evlist_streams in data__file. - Free the streams in data__free. v6: - Rebase to perf/core v5: - Remove enum stream_type - Rebase to perf/core v4: - Remove the "--before" and "--after" options since they are for source line based comparison. In this patchset, we will not support source line based
[PATCH v7 6/7] perf util: Report hot streams
We show the streams separately. They are divided into different sections.
1. "Matched hot streams"
2. "Hot streams in old perf data only"
3. "Hot streams in new perf data only".
For each stream, we report the cycles and hot percent (hits%).
For example,
cycles: 2, hits: 4.08%
--
main div.c:42
compute_flag div.c:28
Signed-off-by: Jin Yao
---
v7:
- Rename functions with 'evsel_streams__' prefix
v6:
- Rebase to perf/core
v5:
- Rebase to perf/core
v4:
- Remove "Hot chains in old perf data but source line changed
in new perf data"
tools/perf/util/callchain.c | 13
tools/perf/util/callchain.h | 2 +
tools/perf/util/stream.c| 123
tools/perf/util/stream.h| 3 +
4 files changed, 141 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 4f824bfcc072..1b60985690bb 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1699,3 +1699,16 @@ u64 callchain_total_hits(struct hists *hists)
return chain_hits;
}
+
+s64 callchain_avg_cycles(struct callchain_node *cnode)
+{
+ struct callchain_list *chain;
+ s64 cycles = 0;
+
+ list_for_each_entry(chain, >val, list) {
+ if (chain->srcline && chain->branch_count)
+ cycles += chain->cycles_count / chain->branch_count;
+ }
+
+ return cycles;
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index ac5bea9c1eb7..5824134f983b 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -305,4 +305,6 @@ bool callchain_cnode_matched(struct callchain_node
*base_cnode,
u64 callchain_total_hits(struct hists *hists);
+s64 callchain_avg_cycles(struct callchain_node *cnode);
+
#endif /* __PERF_CALLCHAIN_H */
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index 47c5956b3378..4bd5e5a00aa5 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -217,3 +217,126 @@ void evsel_streams__match(struct evsel_streams *es_base,
stream__link(base_stream, pair_stream);
}
}
+
+static void print_callchain_pair(struct stream *base_stream, int idx,
+struct evsel_streams *es_base,
+struct evsel_streams *es_pair)
+{
+ struct callchain_node *base_cnode = base_stream->cnode;
+ struct callchain_node *pair_cnode = base_stream->pair_cnode;
+ struct callchain_list *base_chain, *pair_chain;
+ char buf1[512], buf2[512], cbuf1[256], cbuf2[256];
+ char *s1, *s2;
+ double pct;
+
+ printf("\nhot chain pair %d:\n", idx);
+
+ pct = (double)base_cnode->hit / (double)es_base->streams_hits;
+ scnprintf(buf1, sizeof(buf1), "cycles: %ld, hits: %.2f%%",
+ callchain_avg_cycles(base_cnode), pct * 100.0);
+
+ pct = (double)pair_cnode->hit / (double)es_pair->streams_hits;
+ scnprintf(buf2, sizeof(buf2), "cycles: %ld, hits: %.2f%%",
+ callchain_avg_cycles(pair_cnode), pct * 100.0);
+
+ printf("%35s\t%35s\n", buf1, buf2);
+
+ printf("%35s\t%35s\n",
+ "---",
+ "--");
+
+ pair_chain = list_first_entry(_cnode->val,
+ struct callchain_list,
+ list);
+
+ list_for_each_entry(base_chain, _cnode->val, list) {
+ if (_chain->list == _cnode->val)
+ return;
+
+ s1 = callchain_list__sym_name(base_chain, cbuf1, sizeof(cbuf1),
+ false);
+ s2 = callchain_list__sym_name(pair_chain, cbuf2, sizeof(cbuf2),
+ false);
+
+ scnprintf(buf1, sizeof(buf1), "%35s\t%35s", s1, s2);
+ printf("%s\n", buf1);
+ pair_chain = list_next_entry(pair_chain, list);
+ }
+}
+
+static void print_stream_callchain(struct stream *stream, int idx,
+ struct evsel_streams *es, bool pair)
+{
+ struct callchain_node *cnode = stream->cnode;
+ struct callchain_list *chain;
+ char buf[512], cbuf[256], *s;
+ double pct;
+
+ printf("\nhot chain %d:\n", idx);
+
+ pct = (double)cnode->hit / (double)es->streams_hits;
+ scnprintf(buf, sizeof(buf), "cycles: %ld, hits: %.2f%%",
+ callchain_avg_cycles(cnode), pct * 100.0);
+
+ if (pair) {
+ printf("%35s\t%35s\n", "", buf);
+ printf("%35s\t%35s\n",
+ "", "--");
+ } else {
+ printf("%35s\n", buf);
+ printf("%35s\n", "--");
+ }
+
+ list_for_each_entry(chain, >val, list) {
+ s =
[PATCH v7 0/7] perf: Stream comparison
Sometimes, a small change in a hot function reducing the cycles of this function, but the overall workload doesn't get faster. It is interesting where the cycles are moved to. What it would like is to diff before/after streams. The stream is the branch history which is aggregated by the branch records from perf samples. For example, the callchains aggregated from the branch records. By browsing the hot stream, we can understand the hot code path. By browsing the hot streams, we can understand the hot code path. By comparing the cycles variation of same streams between old perf data and new perf data, we can understand if the cycles are moved to other codes. The before stream is the stream in perf.data.old. The after stream is the stream in perf.data. Diffing before/after streams compares top N hottest streams between two perf data files. If all entries of one stream in perf.data.old are fully matched with all entries of another stream in perf.data, we think two streams are matched, otherwise the streams are not matched. For example, cycles: 1, hits: 26.80% cycles: 1, hits: 27.30% -- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 The above streams are matched and we can see for the same streams the cycles (1) are equal and the callchain hit percents are slightly changed (26.80% vs. 27.30%). That's expected. Now let's see example. perf record -b ... Generate perf.data.old with branch data perf record -b ... Generate perf.data with branch data perf diff --stream [ Matched hot streams ] hot chain pair 1: cycles: 1, hits: 27.77% cycles: 1, hits: 9.24% --- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 hot chain pair 2: cycles: 34, hits: 20.06%cycles: 27, hits: 16.98% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 __random_r random_r.c:357 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 __random random.c:288 rand rand.c:27 rand rand.c:27 rand rand.c:26 rand rand.c:26 rand@pltrand@plt rand@pltrand@plt compute_flag div.c:25 compute_flag div.c:25 compute_flag div.c:22 compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:40 main div.c:40 main div.c:39 main div.c:39 hot chain pair 3: cycles: 9, hits: 4.48% cycles: 6, hits: 4.51% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 [ Hot streams in old perf data only ] hot chain 1: cycles: 18, hits: 6.75% -- __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 rand rand.c:27 rand rand.c:26 rand@plt rand@plt compute_flag div.c:25 compute_flag div.c:22 main div.c:40 hot chain 2: cycles: 29,
[PATCH v7 5/7] perf util: Calculate the sum of total streams hits
We have used callchain_node->hit to measure the hot level of one
stream. This patch calculates the sum of hits of total streams.
Thus in next patch, we can use following formula to report hot
percent for one stream.
hot percent = callchain_node->hit / sum of total hits
Signed-off-by: Jin Yao
---
v7:
- No change
v6:
- Rebase to perf/core
v5:
- Rebase to perf/core
v4:
- No functional change.
v2:
- Combine the variable decl line with its initial assignment
in total_callchain_hits().
tools/perf/util/callchain.c | 32
tools/perf/util/callchain.h | 3 +++
tools/perf/util/stream.c| 2 ++
tools/perf/util/stream.h| 1 +
4 files changed, 38 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index d356e73c5622..4f824bfcc072 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1667,3 +1667,35 @@ bool callchain_cnode_matched(struct callchain_node
*base_cnode,
return match;
}
+
+static u64 count_callchain_hits(struct hist_entry *he)
+{
+ struct rb_root *root = >sorted_chain;
+ struct rb_node *rb_node = rb_first(root);
+ struct callchain_node *node;
+ u64 chain_hits = 0;
+
+ while (rb_node) {
+ node = rb_entry(rb_node, struct callchain_node, rb_node);
+ chain_hits += node->hit;
+ rb_node = rb_next(rb_node);
+ }
+
+ return chain_hits;
+}
+
+u64 callchain_total_hits(struct hists *hists)
+{
+ struct rb_node *next = rb_first_cached(>entries);
+ u64 chain_hits = 0;
+
+ while (next) {
+ struct hist_entry *he = rb_entry(next, struct hist_entry,
+rb_node);
+
+ chain_hits += count_callchain_hits(he);
+ next = rb_next(>rb_node);
+ }
+
+ return chain_hits;
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index ad27fc8c7948..ac5bea9c1eb7 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -13,6 +13,7 @@ struct ip_callchain;
struct map;
struct perf_sample;
struct thread;
+struct hists;
#define HELP_PAD "\t\t\t\t"
@@ -302,4 +303,6 @@ void callchain_param_setup(u64 sample_type);
bool callchain_cnode_matched(struct callchain_node *base_cnode,
struct callchain_node *pair_cnode);
+u64 callchain_total_hits(struct hists *hists);
+
#endif /* __PERF_CALLCHAIN_H */
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index 0d6a7452320a..47c5956b3378 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -121,6 +121,8 @@ static void init_hot_callchain(struct hists *hists, struct
evsel_streams *es)
update_hot_callchain(he, es);
next = rb_next(>rb_node);
}
+
+ es->streams_hits = callchain_total_hits(hists);
}
static int evlist__init_callchain_streams(struct evlist *evlist,
diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
index cb131f41f5b1..a61072eda64d 100644
--- a/tools/perf/util/stream.h
+++ b/tools/perf/util/stream.h
@@ -14,6 +14,7 @@ struct evsel_streams {
int nr_streams_max;
int nr_streams;
int evsel_idx;
+ u64 streams_hits;
};
struct evlist_streams {
--
2.17.1
[PATCH v7 2/7] perf util: Get the evsel_streams by evsel_idx
In previous patch, we have created evsel_streams array
This patch returns the specified evsel_streams according to the
evsel_idx.
Signed-off-by: Jin Yao
---
v7:
- Rename functions:
evsel_streams__entry
v6:
- Rebase to perf/core
v5:
- Rebase to perf/core
v4:
- Rename the patch from 'perf util: Return per-event callchain
streams' to 'perf util: Get the evsel_streams by evsel_idx'
tools/perf/util/stream.c | 13 +
tools/perf/util/stream.h | 3 +++
2 files changed, 16 insertions(+)
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index 31efe4ae0f55..e1c7d6c6126b 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -162,3 +162,16 @@ struct evlist_streams *evlist__create_streams(struct
evlist *evlist,
return els;
}
+
+struct evsel_streams *evsel_streams__entry(struct evlist_streams *els,
+ int evsel_idx)
+{
+ struct evsel_streams *es = els->ev_streams;
+
+ for (int i = 0; i < els->nr_evsel; i++) {
+ if (es[i].evsel_idx == evsel_idx)
+ return [i];
+ }
+
+ return NULL;
+}
diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
index 35bc64df554c..f01335677479 100644
--- a/tools/perf/util/stream.h
+++ b/tools/perf/util/stream.h
@@ -27,4 +27,7 @@ void evlist_streams__delete(struct evlist_streams *els);
struct evlist_streams *evlist__create_streams(struct evlist *evlist,
int nr_streams_max);
+struct evsel_streams *evsel_streams__entry(struct evlist_streams *els,
+ int evsel_idx);
+
#endif /* __PERF_STREAM_H */
--
2.17.1
[PATCH v7 3/7] perf util: Compare two streams
Stream is the branch history which is aggregated by the branch
records from perf samples. Now we support the callchain as
stream.
If the callchain entries of one stream are fully matched with
the callchain entries of another stream, we think two streams
are matched.
For example,
cycles: 1, hits: 26.80% cycles: 1, hits: 27.30%
--- ---
main div.c:39 main div.c:39
main div.c:44 main div.c:44
Above two streams are matched (we don't consider the case that
source code is changed).
The matching logic is, compare the chain string first. If it's not
matched, fallback to dso address comparison.
Signed-off-by: Jin Yao
---
v7:
- No change
v6:
- Rebase to perf/core
v5:
- Remove enum stream_type
- Rebase to perf/core
v4:
- Remove original source line comparison code.
tools/perf/util/callchain.c | 54 +
tools/perf/util/callchain.h | 4 +++
2 files changed, 58 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 2775b752f2fa..d356e73c5622 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1613,3 +1613,57 @@ void callchain_param_setup(u64 sample_type)
callchain_param.record_mode = CALLCHAIN_FP;
}
}
+
+static bool chain_match(struct callchain_list *base_chain,
+ struct callchain_list *pair_chain)
+{
+ enum match_result match;
+
+ match = match_chain_strings(base_chain->srcline,
+ pair_chain->srcline);
+ if (match != MATCH_ERROR)
+ return match == MATCH_EQ;
+
+ match = match_chain_dso_addresses(base_chain->ms.map,
+ base_chain->ip,
+ pair_chain->ms.map,
+ pair_chain->ip);
+
+ return match == MATCH_EQ;
+}
+
+bool callchain_cnode_matched(struct callchain_node *base_cnode,
+struct callchain_node *pair_cnode)
+{
+ struct callchain_list *base_chain, *pair_chain;
+ bool match = false;
+
+ pair_chain = list_first_entry(_cnode->val,
+ struct callchain_list,
+ list);
+
+ list_for_each_entry(base_chain, _cnode->val, list) {
+ if (_chain->list == _cnode->val)
+ return false;
+
+ if (!base_chain->srcline || !pair_chain->srcline) {
+ pair_chain = list_next_entry(pair_chain, list);
+ continue;
+ }
+
+ match = chain_match(base_chain, pair_chain);
+ if (!match)
+ return false;
+
+ pair_chain = list_next_entry(pair_chain, list);
+ }
+
+ /*
+* Say chain1 is ABC, chain2 is ABCD, we consider they are
+* not fully matched.
+*/
+ if (pair_chain && (_chain->list != _cnode->val))
+ return false;
+
+ return match;
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index fe36a9e5ccd1..ad27fc8c7948 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -298,4 +298,8 @@ int callchain_branch_counts(struct callchain_root *root,
u64 *abort_count, u64 *cycles_count);
void callchain_param_setup(u64 sample_type);
+
+bool callchain_cnode_matched(struct callchain_node *base_cnode,
+struct callchain_node *pair_cnode);
+
#endif /* __PERF_CALLCHAIN_H */
--
2.17.1
[PATCH v7 1/7] perf util: Create streams
We define the stream is the branch history which is aggregated by
the branch records from perf samples. For example, the callchains
aggregated from the branch records are considered as streams.
By browsing the hot stream, we can understand the hot code path.
Now we only support the callchain for stream. For measuring the
hot level for a stream, we use the callchain_node->hit, higher
is hotter.
There may be many callchains sampled so we only focus on the top
N hottest callchains. N is a user defined parameter or predefined
default value (nr_streams_max).
This patch creates an evsel_streams array per event, and saves
the top N hottest streams in a stream array.
So now we can get the per-event top N hottest streams.
Signed-off-by: Jin Yao
---
v7:
- Create a new struct evlist_streams.
- Rename functions with appropriate prefix
v6:
- Rebase to perf/core
v5:
- Remove enum stram_type
- Rebase to perf/core
v4:
- Refactor the code
- Rename patch name from 'perf util: Create streams for managing
top N hottest callchains' to 'perf util: Create streams'
v2:
- Use zfree in free_evsel_streams().
tools/perf/util/Build| 1 +
tools/perf/util/stream.c | 164 +++
tools/perf/util/stream.h | 30 +++
3 files changed, 195 insertions(+)
create mode 100644 tools/perf/util/stream.c
create mode 100644 tools/perf/util/stream.h
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index cd5e41960e64..6ffdf833cd51 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -101,6 +101,7 @@ perf-y += call-path.o
perf-y += rwsem.o
perf-y += thread-stack.o
perf-y += spark.o
+perf-y += stream.o
perf-$(CONFIG_AUXTRACE) += auxtrace.o
perf-$(CONFIG_AUXTRACE) += intel-pt-decoder/
perf-$(CONFIG_AUXTRACE) += intel-pt.o
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
new file mode 100644
index ..31efe4ae0f55
--- /dev/null
+++ b/tools/perf/util/stream.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Compare and figure out the top N hottest streams
+ * Copyright (c) 2020, Intel Corporation.
+ * Author: Jin Yao
+ */
+
+#include
+#include
+#include
+#include "debug.h"
+#include "hist.h"
+#include "sort.h"
+#include "stream.h"
+#include "evlist.h"
+
+static void evsel_streams__delete(struct evsel_streams *es, int nr_evsel)
+{
+ for (int i = 0; i < nr_evsel; i++)
+ zfree([i].streams);
+
+ free(es);
+}
+
+void evlist_streams__delete(struct evlist_streams *els)
+{
+ evsel_streams__delete(els->ev_streams, els->nr_evsel);
+ free(els);
+}
+
+static struct evlist_streams *evlist_streams__new(int nr_evsel,
+ int nr_streams_max)
+{
+ struct evlist_streams *els;
+ struct evsel_streams *es;
+
+ els = zalloc(sizeof(*els));
+ if (!els)
+ return NULL;
+
+ es = calloc(nr_evsel, sizeof(struct evsel_streams));
+ if (!es) {
+ free(els);
+ return NULL;
+ }
+
+ for (int i = 0; i < nr_evsel; i++) {
+ struct evsel_streams *s = [i];
+
+ s->streams = calloc(nr_streams_max, sizeof(struct stream));
+ if (!s->streams)
+ goto err;
+
+ s->nr_streams_max = nr_streams_max;
+ s->evsel_idx = -1;
+ }
+
+ els->ev_streams = es;
+ els->nr_evsel = nr_evsel;
+ return els;
+
+err:
+ evsel_streams__delete(es, nr_evsel);
+ return NULL;
+}
+
+/*
+ * The cnodes with high hit number are hot callchains.
+ */
+static void evsel_streams__set_hot_cnode(struct evsel_streams *es,
+struct callchain_node *cnode)
+{
+ int i, idx = 0;
+ u64 hit;
+
+ if (es->nr_streams < es->nr_streams_max) {
+ i = es->nr_streams;
+ es->streams[i].cnode = cnode;
+ es->nr_streams++;
+ return;
+ }
+
+ /*
+* Considering a few number of hot streams, only use simple
+* way to find the cnode with smallest hit number and replace.
+*/
+ hit = (es->streams[0].cnode)->hit;
+ for (i = 1; i < es->nr_streams; i++) {
+ if ((es->streams[i].cnode)->hit < hit) {
+ hit = (es->streams[i].cnode)->hit;
+ idx = i;
+ }
+ }
+
+ if (cnode->hit > hit)
+ es->streams[idx].cnode = cnode;
+}
+
+static void update_hot_callchain(struct hist_entry *he,
+struct evsel_streams *es)
+{
+ struct rb_root *root = >sorted_chain;
+ struct rb_node *rb_node = rb_first(root);
+ struct callchain_node *cnode;
+
+ while (rb_node) {
+ cnode = rb_entry(rb_node, struct callchain_node, rb_node);
+ evsel_streams__set_hot_cnode(es, cnode);
+ rb_node =
[rcu:rcu/next] BUILD SUCCESS ec179933e2502ebd3cbc31eac42a64d00e0e9c07
defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a005-20200920 x86_64 randconfig-a003-20200920 x86_64 randconfig-a004-20200920 x86_64 randconfig-a002-20200920 x86_64 randconfig-a006-20200920 x86_64 randconfig-a001-20200920 i386 randconfig-a002-20200920 i386 randconfig-a006-20200920 i386 randconfig-a003-20200920 i386 randconfig-a004-20200920 i386 randconfig-a005-20200920 i386 randconfig-a001-20200920 i386 randconfig-a002-20200921 i386 randconfig-a006-20200921 i386 randconfig-a003-20200921 i386 randconfig-a004-20200921 i386 randconfig-a005-20200921 i386 randconfig-a001-20200921 i386 randconfig-a012-20200920 i386 randconfig-a014-20200920 i386 randconfig-a016-20200920 i386 randconfig-a013-20200920 i386 randconfig-a011-20200920 i386 randconfig-a015-20200920 riscvnommu_k210_defconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a011-20200920 x86_64 randconfig-a013-20200920 x86_64 randconfig-a014-20200920 x86_64 randconfig-a015-20200920 x86_64 randconfig-a012-20200920 x86_64 randconfig-a016-20200920 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] net: unix: remove redundant assignment to variable 'err'
After commit 37ab4fa7844a ("net: unix: allow bind to fail on mutex lock"),
the assignment to err is redundant. So remove it.
Signed-off-by: Jing Xiangfeng
---
net/unix/af_unix.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 92784e51ee7d..eb82bdc6cf7c 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -878,7 +878,6 @@ static int unix_autobind(struct socket *sock)
if (err)
return err;
- err = 0;
if (u->addr)
goto out;
--
2.17.1
[PATCH drm/hisilicon 3/3] drm/hisilicon: Releasing Resources in the Destroy callback Function
Rewrite the desrtoy callback function to release resources.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index e84d381..f1541ff 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -47,6 +47,14 @@ static enum drm_mode_status
hibmc_connector_mode_valid(struct drm_connector *con
return MODE_OK;
}
+static void hibmc_connector_destroy(struct drm_connector *connector)
+{
+ struct hibmc_connector *hibmc_connector = to_hibmc_connector(connector);
+
+ i2c_del_adapter(_connector->adapter);
+ drm_connector_cleanup(connector);
+}
+
static const struct drm_connector_helper_funcs
hibmc_connector_helper_funcs = {
.get_modes = hibmc_connector_get_modes,
@@ -55,7 +63,7 @@ static const struct drm_connector_helper_funcs
static const struct drm_connector_funcs hibmc_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = drm_connector_cleanup,
+ .destroy = hibmc_connector_destroy,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
--
2.7.4
[PATCH drm/hisilicon 0/3] support reading resolutions from EDID
patch #1 add a new file to implements i2c adapters, #2 read the resolution from the edid, if that fails, set the resolution to fixed. patch #3 update the destroy callback function to release the i2c adapters. Tian Tao (3): drm/hisilicon: Support i2c driver algorithms for bit-shift adapters drm/hisilicon: Features to support reading resolutions from EDID drm/hisilicon: Releasing Resources in the Destroy callback Function drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 21 - drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c | 98 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 45 +-- 4 files changed, 157 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c -- 2.7.4
[PATCH drm/hisilicon 2/3] drm/hisilicon: Features to support reading resolutions from EDID
Use drm_get_edid to get the resolution, if that fails, set it to
a fixed resolution.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 35
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index 376a05d..e84d381 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -20,13 +20,24 @@
static int hibmc_connector_get_modes(struct drm_connector *connector)
{
- int count;
+ int count = 0;
+ void *edid;
+ struct hibmc_connector *hibmc_connector = to_hibmc_connector(connector);
+
+ edid = drm_get_edid(connector, _connector->adapter);
+ if (edid) {
+ drm_connector_update_edid_property(connector, edid);
+ count = drm_add_edid_modes(connector, edid);
+ }
- count = drm_add_modes_noedid(connector,
+ if (!edid || count == 0) {
+ count = drm_add_modes_noedid(connector,
connector->dev->mode_config.max_width,
connector->dev->mode_config.max_height);
- drm_set_preferred_mode(connector, 1024, 768);
+ drm_set_preferred_mode(connector, 1024, 768);
+ }
+ kfree(edid);
return count;
}
@@ -77,10 +88,19 @@ static const struct drm_encoder_funcs hibmc_encoder_funcs =
{
int hibmc_vdac_init(struct hibmc_drm_private *priv)
{
struct drm_device *dev = priv->dev;
+ struct hibmc_connector *hibmc_connector = >connector;
struct drm_encoder *encoder = >encoder;
- struct drm_connector *connector = >connector;
+ struct drm_connector *connector = _connector->base;
int ret;
+ hibmc_connector->dev = dev;
+
+ ret = hibmc_ddc_create(hibmc_connector);
+ if (ret) {
+ drm_err(dev, "failed to create connector: %d\n", ret);
+ return ret;
+ }
+
encoder->possible_crtcs = 0x1;
ret = drm_encoder_init(dev, encoder, _encoder_funcs,
DRM_MODE_ENCODER_DAC, NULL);
@@ -91,12 +111,15 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
drm_encoder_helper_add(encoder, _encoder_helper_funcs);
- ret = drm_connector_init(dev, connector, _connector_funcs,
-DRM_MODE_CONNECTOR_VGA);
+ ret = drm_connector_init_with_ddc(dev, connector,
+ _connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ _connector->adapter);
if (ret) {
drm_err(dev, "failed to init connector: %d\n", ret);
return ret;
}
+
drm_connector_helper_add(connector, _connector_helper_funcs);
drm_connector_attach_encoder(connector, encoder);
--
2.7.4
[PATCH drm/hisilicon 1/3] drm/hisilicon: Support i2c driver algorithms for bit-shift adapters
Adding driver implementation to support i2c driver algorithms for
bit-shift adapters, so hibmc will using the interface provided by
drm to read edid.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/Makefile| 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 21 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c | 98 +
3 files changed, 119 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
index f991327..684ef79 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
-hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_ttm.o
+hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_ttm.o
hibmc_drm_i2c.o
obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 197485e..1b2edb3 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -14,11 +14,24 @@
#ifndef HIBMC_DRM_DRV_H
#define HIBMC_DRM_DRV_H
+#include
+#include
+#include
+
+#include
#include
#include
struct drm_device;
+struct hibmc_connector {
+ struct drm_connector base;
+ struct drm_device *dev;
+
+ struct i2c_adapter adapter;
+ struct i2c_algo_bit_data bit_data;
+};
+
struct hibmc_drm_private {
/* hw */
void __iomem *mmio;
@@ -31,10 +44,15 @@ struct hibmc_drm_private {
struct drm_plane primary_plane;
struct drm_crtc crtc;
struct drm_encoder encoder;
- struct drm_connector connector;
+ struct hibmc_connector connector;
bool mode_config_initialized;
};
+static inline struct hibmc_connector *to_hibmc_connector(struct drm_connector
*connector)
+{
+ return container_of(connector, struct hibmc_connector, base);
+}
+
void hibmc_set_power_mode(struct hibmc_drm_private *priv,
unsigned int power_mode);
void hibmc_set_current_gate(struct hibmc_drm_private *priv,
@@ -47,6 +65,7 @@ int hibmc_mm_init(struct hibmc_drm_private *hibmc);
void hibmc_mm_fini(struct hibmc_drm_private *hibmc);
int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
+int hibmc_ddc_create(struct hibmc_connector *connector);
extern const struct drm_mode_config_funcs hibmc_mode_funcs;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
new file mode 100644
index 000..0506846
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Hisilicon Hibmc SoC drm driver
+ *
+ * Based on the bochs drm driver.
+ *
+ * Copyright (c) 2016 Huawei Limited.
+ *
+ * Author:
+ * Tian Tao
+ */
+
+#include
+#include
+
+#include
+#include
+
+#include "hibmc_drm_drv.h"
+
+#define GPIO_DATA 0x0802A0
+#define GPIO_DATA_DIRECTION0x0802A4
+
+#define GPIO_SCL_MASK 0x1
+#define GPIO_SDA_MASK 0x2
+
+static void hibmc_set_i2c_signal(void *data, u32 mask, int value)
+{
+ struct hibmc_connector *hibmc_connector = data;
+ struct hibmc_drm_private *priv = hibmc_connector->dev->dev_private;
+ u32 tmp_dir = readl(priv->mmio + GPIO_DATA_DIRECTION);
+
+ if (value) {
+ tmp_dir &= ~mask;
+ writel(tmp_dir, priv->mmio + GPIO_DATA_DIRECTION);
+ } else {
+ u32 tmp_data = readl(priv->mmio + GPIO_DATA);
+
+ tmp_data &= ~mask;
+ writel(tmp_data, priv->mmio + GPIO_DATA);
+
+ tmp_dir |= mask;
+ writel(tmp_dir, priv->mmio + GPIO_DATA_DIRECTION);
+ }
+}
+
+static int hibmc_get_i2c_signal(void *data, u32 mask)
+{
+ struct hibmc_connector *hibmc_connector = data;
+ struct hibmc_drm_private *priv = hibmc_connector->dev->dev_private;
+ u32 tmp_dir = readl(priv->mmio + GPIO_DATA_DIRECTION);
+
+ if ((tmp_dir & mask) != mask) {
+ tmp_dir &= ~mask;
+ writel(tmp_dir, priv->mmio + GPIO_DATA_DIRECTION);
+ }
+
+ return (readl(priv->mmio + GPIO_DATA) & mask) ? 1 : 0;
+}
+
+static void hibmc_ddc_setsda(void *data, int state)
+{
+ hibmc_set_i2c_signal(data, GPIO_SDA_MASK, state);
+}
+
+static void hibmc_ddc_setscl(void *data, int state)
+{
+ hibmc_set_i2c_signal(data, GPIO_SCL_MASK, state);
+}
+
+static int hibmc_ddc_getsda(void *data)
+{
+ return hibmc_get_i2c_signal(data, GPIO_SDA_MASK);
+}
+
+static int hibmc_ddc_getscl(void *data)
+{
+ return hibmc_get_i2c_signal(data, GPIO_SCL_MASK);
+}
+
+int hibmc_ddc_create(struct hibmc_connector *connector)
+{
+
linux-next: build warning after merge of the drm-msm tree
Hi all,
After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from include/linux/bitops.h:5,
from include/linux/kernel.h:12,
from include/linux/ascii85.h:11,
from drivers/gpu/drm/msm/adreno/adreno_gpu.c:9:
drivers/gpu/drm/msm/adreno/adreno_gpu.c: In function
'adreno_iommu_create_address_space':
include/linux/bits.h:36:11: warning: right shift count is negative
[-Wshift-count-negative]
36 | (~UL(0) >> (BITS_PER_LONG - 1 - (h
| ^~
include/linux/bits.h:38:31: note: in expansion of macro '__GENMASK'
38 | (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
| ^
drivers/gpu/drm/msm/adreno/adreno_gpu.c:212:11: note: in expansion of macro
'GENMASK'
212 | start & GENMASK(48, 0), size);
| ^~~
Introduced by commit
e3c64c7221f6 ("drm/msm: Set the global virtual address range from the IOMMU
domain")
--
Cheers,
Stephen Rothwell
pgpqQ5FnkSfcH.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the drm-msm tree with the drm tree
Hi all,
Today's linux-next merge of the drm-msm tree got a conflict in:
drivers/gpu/drm/msm/msm_iommu.c
between commit:
7690a33f22ab ("drm: msm: fix common struct sg_table related issues")
from the drm tree and commit:
e3c64c7221f6 ("drm/msm: Set the global virtual address range from the IOMMU
domain")
from the drm-msm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/msm/msm_iommu.c
index 6c31e65834c6,697cc0a059d6..
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@@ -36,7 -231,11 +231,11 @@@ static int msm_iommu_map(struct msm_mm
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
+ /* The arm-smmu driver expects the addresses to be sign extended */
+ if (iova & BIT_ULL(48))
+ iova |= GENMASK_ULL(63, 49);
+
- ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
+ ret = iommu_map_sgtable(iommu->domain, iova, sgt, prot);
WARN_ON(!ret);
return (ret == len) ? 0 : -EINVAL;
pgpzlWulBX2Tk.pgp
Description: OpenPGP digital signature
RE: [EXT] Re: [PATCH v6 0/3] Add 802.1AD protocol support for dsa switch and ocelot driver
> You're going to have to update every single SWITCHDEV_PORT_ADD_OBJ > handler and subsequent helpers to check the validate the protocol value. > > You also are going to have to make sure that every instantiated > switchdev_obj_port_vlan object initializes the vlan protocol field properly. > > Basically, now that this structure has a new member, everything that operates > on that object must be updated to handle the new protocol value. > > And I do mean everything. > > You can't just add the protocol handling to the locations you care about for > bridging and DSA. > > You also have to more fully address the feedback given by Vladimir in patch > #3. > Are the expectations on the user side a Linux based expectation, or one > specific > about how this ASIC is expected to behave by default. It is very unclear what > you are talking about when you say customer and ISP etc. > Hi David, Thanks for your comments. I understand your concerns, I will review the code. Generally, the packets from customer port will have only C-TAG, but the packets form ISP port will have both S-TAG and C-TAG. For ocelot switch, these two ports have different register config. Thanks hongbo
linux-next: manual merge of the drm-msm tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-msm tree got a conflict in:
drivers/gpu/drm/msm/adreno/adreno_gpu.c
between commit:
df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
from Linus' tree and commit:
2fb7487aaf71 ("drm/msm: Get rid of the REG_ADRENO offsets")
from the drm-msm tree.
I fixed it up (I just used the latter) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpIWQcLJR1yj.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] arm64/mm: Enable color zero pages
Hi Robin, On 9/17/20 8:22 PM, Robin Murphy wrote: On 2020-09-17 04:35, Gavin Shan wrote: On 9/16/20 6:28 PM, Will Deacon wrote: On Wed, Sep 16, 2020 at 01:25:23PM +1000, Gavin Shan wrote: This enables color zero pages by allocating contigous page frames for it. The number of pages for this is determined by L1 dCache (or iCache) size, which is probbed from the hardware. * Add cache_total_size() to return L1 dCache (or iCache) size * Implement setup_zero_pages(), which is called after the page allocator begins to work, to allocate the contigous pages needed by color zero page. * Reworked ZERO_PAGE() and define __HAVE_COLOR_ZERO_PAGE. Signed-off-by: Gavin Shan --- arch/arm64/include/asm/cache.h | 22 arch/arm64/include/asm/pgtable.h | 9 ++-- arch/arm64/kernel/cacheinfo.c | 34 +++ arch/arm64/mm/init.c | 35 arch/arm64/mm/mmu.c | 7 --- 5 files changed, 98 insertions(+), 9 deletions(-) diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h index a4d1b5f771f6..420e9dde2c51 100644 --- a/arch/arm64/include/asm/cache.h +++ b/arch/arm64/include/asm/cache.h @@ -39,6 +39,27 @@ #define CLIDR_LOC(clidr) (((clidr) >> CLIDR_LOC_SHIFT) & 0x7) #define CLIDR_LOUIS(clidr) (((clidr) >> CLIDR_LOUIS_SHIFT) & 0x7) +#define CSSELR_TND_SHIFT 4 +#define CSSELR_TND_MASK (UL(1) << CSSELR_TND_SHIFT) +#define CSSELR_LEVEL_SHIFT 1 +#define CSSELR_LEVEL_MASK (UL(7) << CSSELR_LEVEL_SHIFT) +#define CSSELR_IND_SHIFT 0 +#define CSSERL_IND_MASK (UL(1) << CSSELR_IND_SHIFT) + +#define CCSIDR_64_LS_SHIFT 0 +#define CCSIDR_64_LS_MASK (UL(7) << CCSIDR_64_LS_SHIFT) +#define CCSIDR_64_ASSOC_SHIFT 3 +#define CCSIDR_64_ASSOC_MASK (UL(0x1F) << CCSIDR_64_ASSOC_SHIFT) +#define CCSIDR_64_SET_SHIFT 32 +#define CCSIDR_64_SET_MASK (UL(0xFF) << CCSIDR_64_SET_SHIFT) + +#define CCSIDR_32_LS_SHIFT 0 +#define CCSIDR_32_LS_MASK (UL(7) << CCSIDR_32_LS_SHIFT) +#define CCSIDR_32_ASSOC_SHIFT 3 +#define CCSIDR_32_ASSOC_MASK (UL(0x3FF) << CCSIDR_32_ASSOC_SHIFT) +#define CCSIDR_32_SET_SHIFT 13 +#define CCSIDR_32_SET_MASK (UL(0x7FFF) << CCSIDR_32_SET_SHIFT) I don't think we should be inferring cache structure from these register values. The Arm ARM helpfully says: | You cannot make any inference about the actual sizes of caches based | on these parameters. so we need to take the topology information from elsewhere. Yeah, I also noticed the statement in the spec. However, the L1 cache size figured out from above registers are matching with "lscpu" on the machine where I did my tests. Note "lscpu" depends on sysfs entries whose information is retrieved from ACPI (PPTT) table. The number of cache levels are partially retrieved from system register (clidr_el1). It's doable to retrieve the L1 cache size from ACPI (PPTT) table. I'll change accordingly in v2 if this enablement is really needed. More clarify is provided below. But before we get into that, can you justify why we need to do this at all, please? Do you have data to show the benefit of adding this complexity? Initially, I found it's the missed feature which has been enabled on mips/s390. Currently, all read-only anonymous VMAs are backed up by same zero page. It means all reads to these VMAs are cached by same set of cache, but still multiple ways if supported. So it would be nice to have multiple zero pages to back up these read-only anonymous VMAs, so that the reads on them can be cached by multiple sets (multiple ways still if supported). It's overall beneficial to the performance. Is this a concern for true PIPT caches, or is it really just working around a pathological case for alias-detecting VIPT caches? I think it's definitely a concern for PIPT caches. However, I'm not sure about VIPT caches because I failed to understand how it works from ARM8-A spec. If I'm correct, the index of VIPT cache line is still determined by the physical address and the number of sets is another limitation? For example, two virtual addresses (v1) and (v2) are translated to same physical address (p1), there is still one cache line (from particular set) for them. If so, this should helps in terms of performance. However, I'm not sure I understood VIPT caches correctly because there is one statement in the ARM8-A spec as below. It seems (v1) and (v2) can be backed by two different cache line from one particular set. The only architecturally-guaranteed way to invalidate all aliases of a PA from a VIPT instruction cache is to invalidate the entire instruction cache. Unfortunately, I didn't find a machine where the size of cache set is larger than page size. So I had one experiment as indication how L1 data cache miss affects the overall performance: L1 data cache size: 32KB L1 data cache line size: 64
[GIT PULL] ARM: soc: TI driver updates for v5.10
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/drivers_soc_for_5.10 for you to fetch changes up to dcca7a97c6bfff2a7a18b928a0b9bf215cc8f4f5: Add missing '#' to fix schema errors: (2020-09-20 19:36:37 -0700) ARM: soc: TI driver updates for v5.10 Consist of: - Add Ring accelerator support for AM65x - Add TI PRUSS platform driver and enable it on available platforms - Extend PRUSS driver for CORECLK_MUX/IEPCLK_MUX support - UDMA rx ring pair fix - Add socinfo entry for J7200 Grygorii Strashko (2): soc: ti: k3: ringacc: add am65x sr2.0 support bindings: soc: ti: soc: ringacc: remove ti,dma-ring-reset-quirk Grzegorz Jaszczyk (3): dt-bindings: soc: ti: Add TI PRUSS bindings dt-bindings: soc: ti: Update TI PRUSS bindings regarding clock-muxes soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX Krzysztof Kozlowski (1): Add missing '#' to fix schema errors: Peter Ujfalusi (2): soc: ti: k3-socinfo: Add entry for J7200 dmaengine: ti: k3-udma-glue: Fix parameters for rx ring pair request Qinglang Miao (1): soc: ti: Convert to DEFINE_SHOW_ATTRIBUTE Suman Anna (6): soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCs soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs soc: ti: pruss: Enable support for ICSSG subsystems on K3 J721E SoCs Tero Kristo (2): soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one firmware: ti_sci: allow frequency change for disabled clocks by default .../devicetree/bindings/soc/ti/k3-ringacc.yaml | 6 - .../devicetree/bindings/soc/ti/ti,pruss.yaml | 439 + drivers/dma/ti/k3-udma-glue.c | 2 +- drivers/firmware/ti_sci.c | 6 +- drivers/soc/ti/Kconfig | 11 + drivers/soc/ti/Makefile| 1 + drivers/soc/ti/k3-ringacc.c| 33 +- drivers/soc/ti/k3-socinfo.c| 1 + drivers/soc/ti/knav_dma.c | 16 +- drivers/soc/ti/knav_qmss_queue.c | 14 +- drivers/soc/ti/pruss.c | 354 + drivers/soc/ti/ti_sci_pm_domains.c | 251 ++-- include/linux/pruss_driver.h | 54 +++ 13 files changed, 1021 insertions(+), 167 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml create mode 100644 drivers/soc/ti/pruss.c create mode 100644 include/linux/pruss_driver.h
Re: [PATCH v2] add the FPGA Device Feature List (DFL) EMIF support
On Sun, Sep 20, 2020 at 06:22:05PM +0200, Krzysztof Kozlowski wrote: > On Wed, Sep 16, 2020 at 01:37:01PM +0800, Xu Yilun wrote: > > The patchsets "Modularization of DFL private feature drivers" & "add dfl > > bus support to MODULE_DEVICE_TABLE()" are all queued to linux-next. So > > there is no dependency now. > > What do you mean there is no dependency? The DFL is required here and it > won't compile without these patches: Sorry, actually I mean the dependencies have been queued to linux-next. I didn't realize patch dependency problems across maintainer's trees. I'll try to contact Moritz if this patch could be applied via his tree. Thanks, Yilun > > CC drivers/memory/dfl-emif.o > ../drivers/memory/dfl-emif.c:10:10: fatal error: linux/fpga/dfl.h: No such > file or directory > #include > ^~ > compilation terminated. > > This simply cannot go in without dependency. > > I described in your v1 submission what is needed here: > "Anyway I will need a stable tag with mentioned dependencies or this > will wait for the next cycle." > > Best regards, > Krzysztof
[PATCH 3/4] dt-bindings: usb: Add Intel Keem Bay USB controller bindings
Binding description for Intel Keem Bay USB controller.
Signed-off-by: Wan Ahmad Zainie
---
.../bindings/usb/intel,keembay-dwc3.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
diff --git a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
new file mode 100644
index ..dd32c10ce6c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/intel,keembay-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Keem Bay DWC3 USB controller
+
+maintainers:
+ - Wan Ahmad Zainie
+
+properties:
+ compatible:
+const: intel,keembay-dwc3
+
+ clocks:
+maxItems: 4
+
+ clock-names:
+items:
+ - const: async_master
+ - const: ref
+ - const: alt_ref
+ - const: suspend
+
+ ranges: true
+
+ '#address-cells':
+enum: [ 1, 2 ]
+
+ '#size-cells':
+enum: [ 1, 2 ]
+
+# Required child node:
+
+patternProperties:
+ "^dwc3@[0-9a-f]+$":
+type: object
+description:
+ A child node must exist to represent the core DWC3 IP block.
+ The content of the node is defined in dwc3.txt.
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#define KEEM_BAY_A53_AUX_USB
+#define KEEM_BAY_A53_AUX_USB_REF
+#define KEEM_BAY_A53_AUX_USB_ALT_REF
+#define KEEM_BAY_A53_AUX_USB_SUSPEND
+
+usb {
+ compatible = "intel,keembay-dwc3";
+ clocks = <_clk KEEM_BAY_A53_AUX_USB>,
+ <_clk KEEM_BAY_A53_AUX_USB_REF>,
+ <_clk KEEM_BAY_A53_AUX_USB_ALT_REF>,
+ <_clk KEEM_BAY_A53_AUX_USB_SUSPEND>;
+ clock-names = "async_master", "ref", "alt_ref", "suspend";
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ dwc3@3400 {
+compatible = "snps,dwc3";
+reg = <0x3400 0x1>;
+interrupts = ;
+dr_mode = "peripheral";
+ };
+};
--
2.17.1
[PATCH 2/4] phy: intel: Add Keem Bay USB PHY support
Add support for USB PHY on Intel Keem Bay SoC.
Signed-off-by: Wan Ahmad Zainie
---
drivers/phy/intel/Kconfig | 12 +
drivers/phy/intel/Makefile| 1 +
drivers/phy/intel/phy-intel-keembay-usb.c | 319 ++
3 files changed, 332 insertions(+)
create mode 100644 drivers/phy/intel/phy-intel-keembay-usb.c
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
index 58ec695c92ec..914710660557 100644
--- a/drivers/phy/intel/Kconfig
+++ b/drivers/phy/intel/Kconfig
@@ -14,6 +14,18 @@ config PHY_INTEL_KEEMBAY_EMMC
To compile this driver as a module, choose M here: the module
will be called phy-keembay-emmc.ko.
+config PHY_INTEL_KEEMBAY_USB
+ tristate "Intel Keem Bay USB PHY driver"
+ depends on (OF && ARM64) || COMPILE_TEST
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select REGMAP_MMIO
+ help
+ Choose this option if you have an Intel Keem Bay SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called phy-keembay-usb.ko.
+
config PHY_INTEL_LGM_COMBO
bool "Intel Lightning Mountain ComboPHY driver"
depends on X86 || COMPILE_TEST
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
index a5e0af5ccd75..14550981a707 100644
--- a/drivers/phy/intel/Makefile
+++ b/drivers/phy/intel/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_PHY_INTEL_KEEMBAY_EMMC) += phy-intel-keembay-emmc.o
+obj-$(CONFIG_PHY_INTEL_KEEMBAY_USB)+= phy-intel-keembay-usb.o
obj-$(CONFIG_PHY_INTEL_LGM_COMBO) += phy-intel-lgm-combo.o
obj-$(CONFIG_PHY_INTEL_LGM_EMMC) += phy-intel-lgm-emmc.o
diff --git a/drivers/phy/intel/phy-intel-keembay-usb.c
b/drivers/phy/intel/phy-intel-keembay-usb.c
new file mode 100644
index ..3db88e765656
--- /dev/null
+++ b/drivers/phy/intel/phy-intel-keembay-usb.c
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay USB PHY driver
+ * Copyright (C) 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* USS (USB Subsystem) clock control registers */
+#define USS_CPR_CLK_EN 0x00
+#define USS_CPR_CLK_SET0x04
+#define USS_CPR_CLK_CLR0x08
+#define USS_CPR_RST_EN 0x10
+#define USS_CPR_RST_SET0x14
+#define USS_CPR_RST_CLR0x18
+
+/* USS clock/reset bit fields */
+#define USS_CPR_PHY_TSTBIT(6)
+#define USS_CPR_LOW_JITBIT(5)
+#define USS_CPR_CORE BIT(4)
+#define USS_CPR_SUSPENDBIT(3)
+#define USS_CPR_ALT_REFBIT(2)
+#define USS_CPR_REFBIT(1)
+#define USS_CPR_SYSBIT(0)
+#define USS_CPR_MASK 0x7f
+
+/* USS APB slave registers */
+#define USS_USB_CTRL_CFG0 0x10
+#define VCC_RESET_N_MASK BIT(31)
+
+#define USS_USB_PHY_CFG0 0x30
+#define POR_MASK BIT(15)
+#define PHY_RESET_MASKBIT(14)
+#define PHY_REF_USE_PAD_MASK BIT(5)
+
+#define USS_USB_PHY_CFG6 0x64
+#define PHY0_SRAM_EXT_LD_DONE_MASKBIT(23)
+
+#define USS_USB_PARALLEL_IF_CTRL 0xa0
+#define USB_PHY_CR_PARA_SEL_MASK BIT(2)
+
+#define USS_USB_TSET_SIGNALS_AND_GLOB 0xac
+#define USB_PHY_CR_PARA_CLK_EN_MASK BIT(7)
+
+#define USS_USB_STATUS_REG 0xb8
+#define PHY0_SRAM_INIT_DONE_MASK BIT(3)
+
+#define USS_USB_TIEOFFS_CONSTANTS_REG1 0xc0
+#define IDDQ_ENABLE_MASK BIT(10)
+
+struct keembay_usb_phy {
+ struct device *dev;
+ struct regmap *regmap_cpr;
+ struct regmap *regmap_slv;
+};
+
+static const struct regmap_config keembay_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static int keembay_usb_clocks_on(struct keembay_usb_phy *priv)
+{
+ int ret;
+
+ /* Enable USB subsystem clocks */
+ ret = regmap_update_bits(priv->regmap_cpr, USS_CPR_CLK_SET,
+USS_CPR_MASK, USS_CPR_MASK);
+ if (ret) {
+ dev_err(priv->dev, "error clock set: %d\n", ret);
+ return ret;
+ }
+
+ ret = regmap_update_bits(priv->regmap_cpr, USS_CPR_RST_SET,
+USS_CPR_MASK, USS_CPR_MASK);
+ if (ret) {
+ dev_err(priv->dev, "error reset set: %d\n", ret);
+ return ret;
+ }
+
+ /*
+* Clear IDDQ enable bit ensuring all analog blocks are powered
+* up in USB2.0 PHY.
+*/
+ ret = regmap_update_bits(priv->regmap_slv,
+USS_USB_TIEOFFS_CONSTANTS_REG1,
+IDDQ_ENABLE_MASK,
+FIELD_PREP(IDDQ_ENABLE_MASK, 0));
+ if (ret) {
+ dev_err(priv->dev, "error iddq
[PATCH 4/4] usb: dwc3: of-simple: Add compatible string for Intel Keem Bay platform
Add compatible string to use this generic glue layer to support
Intel Keem Bay platform's dwc3 controller.
Signed-off-by: Wan Ahmad Zainie
---
drivers/usb/dwc3/dwc3-of-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index 2816e4a9813a..e62ecd22b3ed 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -177,6 +177,7 @@ static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "sprd,sc9860-dwc3" },
{ .compatible = "allwinner,sun50i-h6-dwc3" },
{ .compatible = "hisilicon,hi3670-dwc3" },
+ { .compatible = "intel,keembay-dwc3" },
{ /* Sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
--
2.17.1
[PATCH 0/4] phy: intel: Add Keem Bay USB PHY support
Hi. Intel Keem Bay USB subsystem incorporates DesignWare USB3.1 controller, an USB3.1 (Gen1/2) PHY and an USB2.0 PHY. It is a Dual Role Device (DRD), operating as either a USB host or a USB device. The patchset is tested on Keem Bay EVM. Thank you. Best regards, Zainie Wan Ahmad Zainie (4): dt-bindings: phy: Add Intel Keem Bay USB PHY bindings phy: intel: Add Keem Bay USB PHY support dt-bindings: usb: Add Intel Keem Bay USB controller bindings usb: dwc3: of-simple: Add compatible string for Intel Keem Bay platform .../bindings/phy/intel,phy-keembay-usb.yaml | 44 +++ .../bindings/usb/intel,keembay-dwc3.yaml | 77 + drivers/phy/intel/Kconfig | 12 + drivers/phy/intel/Makefile| 1 + drivers/phy/intel/phy-intel-keembay-usb.c | 319 ++ drivers/usb/dwc3/dwc3-of-simple.c | 1 + 6 files changed, 454 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml create mode 100644 Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml create mode 100644 drivers/phy/intel/phy-intel-keembay-usb.c -- 2.17.1
[PATCH 1/4] dt-bindings: phy: Add Intel Keem Bay USB PHY bindings
Binding description for Intel Keem Bay USB PHY.
Signed-off-by: Wan Ahmad Zainie
---
.../bindings/phy/intel,phy-keembay-usb.yaml | 44 +++
1 file changed, 44 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml
b/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml
new file mode 100644
index ..a217bb8ac5bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,phy-keembay-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Keem Bay USB PHY bindings
+
+maintainers:
+ - Wan Ahmad Zainie
+
+properties:
+ compatible:
+const: intel,keembay-usb-phy
+
+ reg:
+items:
+ - description: USB APB CPR (clock, power, reset) register
+ - description: USB APB slave register
+
+ reg-names:
+items:
+ - const: cpr-apb-base
+ - const: slv-apb-base
+
+ '#phy-cells':
+const: 0
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+usb-phy@2040 {
+ compatible = "intel,keembay-usb-phy";
+ reg = <0x2040 0x1c>,
+<0x2048 0xd0>;
+ reg-names = "cpr-apb-base", "slv-apb-base";
+ #phy-cells = <0>;
+};
--
2.17.1
Re: [PATCH -next v2] soc: ti: Convert to DEFINE_SHOW_ATTRIBUTE
On 9/18/20 7:52 PM, Qinglang Miao wrote: Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Qinglang Miao --- v2: based on linux-next(20200917), and can be applied to mainline cleanly now. Applied. Thanks !! Regards, Santosh
linux-next: manual merge of the crypto tree with Linus' tree
Hi all,
Today's linux-next merge of the crypto tree got a conflict in:
drivers/crypto/Kconfig
between commit:
bfe8fe939a04 ("crypto: sa2ul - add Kconfig selects to fix build error")
from Linus' tree and commit:
61f033ba18c3 ("crypto: sa2ul - Select CRYPTO_AUTHENC")
from the crypto tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/crypto/Kconfig
index 52a9b7cf6576,c2950127def6..
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@@ -873,9 -873,7 +873,10 @@@ config CRYPTO_DEV_SA2U
select CRYPTO_AES
select CRYPTO_AES_ARM64
select CRYPTO_ALGAPI
+ select CRYPTO_AUTHENC
+ select CRYPTO_SHA1
+ select CRYPTO_SHA256
+ select CRYPTO_SHA512
select HW_RANDOM
select SG_SPLIT
help
pgpVueXVVSglx.pgp
Description: OpenPGP digital signature
撤回: [PATCH] [v2] nvme: use correct upper limit for tag in nvme_handle_cqe()
tianxianting (RD) 将撤回邮件“[PATCH] [v2] nvme: use correct upper limit for tag in nvme_handle_cqe()”。
RE: [PATCH] [v2] nvme: use correct upper limit for tag in nvme_handle_cqe()
Hi Keith,
I found an extreme case,
in function blk_mq_alloc_map_and_requests(), it will adjust tagset depth by
'set->queue_depth >>= 1' if there is no enough memory for rqs.
If this happens, the real available number of tags(nr_tags) is much smaller
than nvmeq->q_depth.
So the judgement "if (unlikely(cqe->command_id >= nvmeq->q_depth))" in
nvme_handle_cqe() is really
meaningless.
I figured out a new patch, which replaces the meaningless judgement by checking
whether the returned
req is null, if it is null, directly return.
Would you please spare several minutes to review below new patch? thanks
https://lkml.org/lkml/2020/9/20/400
-Original Message-
From: tianxianting (RD)
Sent: Saturday, September 19, 2020 11:15 AM
To: 'Keith Busch'
Cc: ax...@fb.com; h...@lst.de; s...@grimberg.me;
linux-n...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: RE: [PATCH] [v2] nvme: use correct upper limit for tag in
nvme_handle_cqe()
Hi Keith,
Thanks a lot for your comments,
I will try to figure out a safe fix for this issue, then for you review:)
-Original Message-
From: Keith Busch [mailto:kbu...@kernel.org]
Sent: Saturday, September 19, 2020 3:21 AM
To: tianxianting (RD)
Cc: ax...@fb.com; h...@lst.de; s...@grimberg.me;
linux-n...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [v2] nvme: use correct upper limit for tag in
nvme_handle_cqe()
On Fri, Sep 18, 2020 at 06:44:20PM +0800, Xianting Tian wrote:
> @@ -940,7 +940,9 @@ static inline void nvme_handle_cqe(struct nvme_queue
> *nvmeq, u16 idx)
> struct nvme_completion *cqe = >cqes[idx];
> struct request *req;
>
> - if (unlikely(cqe->command_id >= nvmeq->q_depth)) {
> + if (unlikely(cqe->command_id >=
> + nvmeq->qid ? nvmeq->dev->tagset.queue_depth :
> + nvmeq->dev->admin_tagset.queue_depth)) {
Both of these values are set before blk_mq_alloc_tag_set(), so you still have a
race. The interrupt handler probably just shouldn't be registered with the
queue before the tagset is initialized since there can't be any work for the
handler to do before that happens anyway.
The controller is definitely broken, though, and will lead to unavoidable
corruption if it's really behaving this way.
Re: PROBLEM: 5.9.0-rc6 fails to compile due to 'redefinition of ‘dax_supported’'
An update on this: I've done a bisect, with the following result.
--- cut here ---
e2ec5128254518cae320d5dc631b71b94160f663 is the first bad commit
commit e2ec5128254518cae320d5dc631b71b94160f663
Author: Jan Kara
Date: Sun Sep 20 08:54:42 2020 -0700
dm: Call proper helper to determine dax support
DM was calling generic_fsdax_supported() to determine whether a device
referenced in the DM table supports DAX. However this is a helper for
"leaf" device drivers so that
they don't have to duplicate common generic checks. High level code
should call dax_supported() helper which that calls into appropriate
helper for the particular device. This problem manifested itself as
kernel messages:
dm-3: error: dax access failed (-95)
when lvm2-testsuite run in cases where a DM device was stacked on top of
another DM device.
Fixes: 7bf7eac8d648 ("dax: Arrange for dax_supported check to span multiple
devices")
Cc:
Tested-by: Adrian Huang
Signed-off-by: Jan Kara
Acked-by: Mike Snitzer
Reported-by: kernel test robot
Link:
https://lore.kernel.org/r/160061715195.13131.5503173247632041975.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
drivers/dax/super.c | 4
drivers/md/dm-table.c | 10 +++---
include/linux/dax.h | 22 --
3 files changed, 31 insertions(+), 5 deletions(-)
--- end ---
On Sun, Sep 20, 2020 at 09:03:59PM -0400, Stuart Little wrote:
> I am trying to compile for an x86_64 machine (Intel(R) Core(TM) i7-7500U CPU
> @ 2.70GHz). The config file I am currently using is at
>
> https://termbin.com/xin7
>
> The build for 5.9.0-rc6 fails with the following errors:
>
> --- cut here ---
>
> drivers/dax/super.c:325:6: error: redefinition of ‘dax_supported’
> 325 | bool dax_supported(struct dax_device *dax_dev, struct block_device
> *bdev,
> | ^
> In file included from drivers/dax/super.c:16:
> ./include/linux/dax.h:162:20: note: previous definition of ‘dax_supported’
> was here
> 162 | static inline bool dax_supported(struct dax_device *dax_dev,
> |^
> CC lib/memregion.o
> CC [M] drivers/gpu/drm/drm_gem_vram_helper.o
> make[2]: *** [scripts/Makefile.build:283: drivers/dax/super.o] Error 1
> make[1]: *** [scripts/Makefile.build:500: drivers/dax] Error 2
> make[1]: *** Waiting for unfinished jobs
>
> --- end ---
>
> That's earlier on, and then later, at the end of the (failed) build:
>
> make: *** [Makefile:1784: drivers] Error 2
>
> The full build log is at
>
> https://termbin.com/ihxj
>
> but I do not see anything else amiss. 5.9.0-rc5 built fine last week.
Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW
Hi, Rob sir:
Sorry to bother you, may I have your review comment for the binding
part?
Appreciated.
On Thu, 2020-09-10 at 12:31 +0800, Hector Yuan wrote:
> From: "Hector.Yuan"
>
> Add devicetree bindings for MediaTek HW driver.
>
> Signed-off-by: Hector.Yuan
> ---
> .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141
>
> 1 file changed, 141 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> new file mode 100644
> index 000..118a163
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> @@ -0,0 +1,141 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek's CPUFREQ Bindings
> +
> +maintainers:
> + - Hector Yuan
> +
> +description:
> + CPUFREQ HW is a hardware engine used by MediaTek
> + SoCs to manage frequency in hardware. It is capable of controlling
> frequency
> + for multiple clusters.
> +
> +properties:
> + compatible:
> +const: "mediatek,cpufreq-hw"
> +
> + reg:
> +minItems: 1
> +maxItems: 2
> +description: |
> + Addresses and sizes for the memory of the HW bases in each frequency
> domain.
> +
> + reg-names:
> +items:
> + - const: "freq-domain0"
> + - const: "freq-domain1"
> +description: |
> + Frequency domain name. i.e.
> + "freq-domain0", "freq-domain1".
> +
> + "#freq-domain-cells":
> +const: 1
> +description: |
> + Number of cells in a freqency domain specifier.
> +
> + mtk-freq-domain:
> +maxItems: 1
> +description: |
> + Define this cpu belongs to which frequency domain. i.e.
> + cpu0-3 belong to frequency domain0,
> + cpu4-6 belong to frequency domain1.
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - "#freq-domain-cells"
> +
> +examples:
> + - |
> +cpus {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +cpu0: cpu@0 {
> +device_type = "cpu";
> +compatible = "arm,cortex-a55";
> +enable-method = "psci";
> +mtk-freq-domain = <_hw 0>;
> +reg = <0x000>;
> +};
> +
> +cpu1: cpu@1 {
> +device_type = "cpu";
> +compatible = "arm,cortex-a55";
> +enable-method = "psci";
> +mtk-freq-domain = <_hw 0>;
> +reg = <0x100>;
> +};
> +
> +cpu2: cpu@2 {
> +device_type = "cpu";
> +compatible = "arm,cortex-a55";
> +enable-method = "psci";
> +mtk-freq-domain = <_hw 0>;
> +reg = <0x200>;
> +};
> +
> +cpu3: cpu@3 {
> +device_type = "cpu";
> +compatible = "arm,cortex-a55";
> +enable-method = "psci";
> +mtk-freq-domain = <_hw 0>;
> +reg = <0x300>;
> +};
> +
> +cpu4: cpu@4 {
> +device_type = "cpu";
> +compatible = "arm,cortex-a55";
> +enable-method = "psci";
> +mtk-freq-domain = <_hw 1>;
> +reg = <0x400>;
> +};
> +
> +cpu5: cpu@5 {
> +device_type = "cpu";
> +compatible = "arm,cortex-a55";
> +enable-method = "psci";
> +mtk-freq-domain = <_hw 1>;
> +reg = <0x500>;
> +};
> +
> +cpu6: cpu@6 {
> +device_type = "cpu";
> +compatible = "arm,cortex-a75";
> +enable-method = "psci";
> +mtk-freq-domain = <_hw 1>;
> +reg = <0x600>;
> +};
> +
> +cpu7: cpu@7 {
> +device_type = "cpu";
> +compatible = "arm,cortex-a75";
> +enable-method = "psci";
> +mtk-freq-domain = <_hw 1>;
> +reg = <0x700>;
> +};
> +};
> +
> +/* ... */
> +
> +soc {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +cpufreq_hw: cpufreq@11bc00 {
> +compatible = "mediatek,cpufreq-hw";
> +reg = <0 0x11bc10 0 0x8c>,
> + <0 0x11bca0 0 0x8c>;
> +reg-names = "freq-domain0", "freq-domain1";
> +#freq-domain-cells = <1>;
> +};
> +};
> +
> +
> +
> +
Re: [PATCH 14/18] drm/exynos: Consolidate IOMMU mapping code
20. 8. 21. 오전 12:08에 Robin Murphy 이(가) 쓴 글:
> Now that arch/arm is wired up for default domains and iommu-dma, we can
> consolidate the shared mapping code onto the generic IOMMU API version,
> and retire the arch-specific implementation.
>
> Signed-off-by: Robin Murphy
>
> ---
> This is a cheeky revert of 07dc3678bacc ("drm/exynos: Fix cleanup of
> IOMMU related objects"), plus removal of the remaining arm_iommu_*
> references on top.
Thanks for cleanup.
Acked-by: Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 5 +-
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 5 +-
> drivers/gpu/drm/exynos/exynos_drm_dma.c | 61 +++
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 +-
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 5 +-
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +-
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 5 +-
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 5 +-
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 5 +-
> drivers/gpu/drm/exynos/exynos_drm_scaler.c| 6 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 7 +--
> 11 files changed, 29 insertions(+), 86 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 1f79bc2a881e..8428ae12dfa5 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -55,7 +55,6 @@ static const char * const decon_clks_name[] = {
> struct decon_context {
> struct device *dev;
> struct drm_device *drm_dev;
> - void*dma_priv;
> struct exynos_drm_crtc *crtc;
> struct exynos_drm_plane planes[WINDOWS_NR];
> struct exynos_drm_plane_config configs[WINDOWS_NR];
> @@ -645,7 +644,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
>
> decon_clear_channels(ctx->crtc);
>
> - return exynos_drm_register_dma(drm_dev, dev, >dma_priv);
> + return exynos_drm_register_dma(drm_dev, dev);
> }
>
> static void decon_unbind(struct device *dev, struct device *master, void
> *data)
> @@ -655,7 +654,7 @@ static void decon_unbind(struct device *dev, struct
> device *master, void *data)
> decon_atomic_disable(ctx->crtc);
>
> /* detach this sub driver from iommu mapping if supported. */
> - exynos_drm_unregister_dma(ctx->drm_dev, ctx->dev, >dma_priv);
> + exynos_drm_unregister_dma(ctx->drm_dev, ctx->dev);
> }
>
> static const struct component_ops decon_component_ops = {
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index f2d87a7445c7..e7b58097ccdc 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -40,7 +40,6 @@
> struct decon_context {
> struct device *dev;
> struct drm_device *drm_dev;
> - void*dma_priv;
> struct exynos_drm_crtc *crtc;
> struct exynos_drm_plane planes[WINDOWS_NR];
> struct exynos_drm_plane_config configs[WINDOWS_NR];
> @@ -128,13 +127,13 @@ static int decon_ctx_initialize(struct decon_context
> *ctx,
>
> decon_clear_channels(ctx->crtc);
>
> - return exynos_drm_register_dma(drm_dev, ctx->dev, >dma_priv);
> + return exynos_drm_register_dma(drm_dev, ctx->dev);
> }
>
> static void decon_ctx_remove(struct decon_context *ctx)
> {
> /* detach this sub driver from iommu mapping if supported. */
> - exynos_drm_unregister_dma(ctx->drm_dev, ctx->dev, >dma_priv);
> + exynos_drm_unregister_dma(ctx->drm_dev, ctx->dev);
> }
>
> static u32 decon_calc_clkdiv(struct decon_context *ctx,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c
> b/drivers/gpu/drm/exynos/exynos_drm_dma.c
> index 58b89ec11b0e..fd5f9bcf1857 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
> @@ -14,19 +14,6 @@
>
> #include "exynos_drm_drv.h"
>
> -#if defined(CONFIG_ARM_DMA_USE_IOMMU)
> -#include
> -#else
> -#define arm_iommu_create_mapping(...)({ NULL; })
> -#define arm_iommu_attach_device(...) ({ -ENODEV; })
> -#define arm_iommu_release_mapping(...) ({ })
> -#define arm_iommu_detach_device(...) ({ })
> -#define to_dma_iommu_mapping(dev) NULL
> -#endif
> -
> -#if !defined(CONFIG_IOMMU_DMA)
> -#define iommu_dma_init_domain(...) ({ -EINVAL; })
> -#endif
>
> #define EXYNOS_DEV_ADDR_START0x2000
> #define EXYNOS_DEV_ADDR_SIZE 0x4000
> @@ -58,7 +45,7 @@ static inline void clear_dma_max_seg_size(struct device
> *dev)
> * mapping.
> */
> static int drm_iommu_attach_device(struct drm_device *drm_dev,
> - struct device *subdrv_dev, void **dma_priv)
> +
[PATCH] nvme: replace meaningless judgement by checking whether req is null
We met a crash issue when hot-insert a nvme device, blk_mq_tag_to_rq()
returned null(req=null), then crash happened in nvme_end_request():
req = blk_mq_tag_to_rq();
struct nvme_request *rq = nvme_req(req); //rq = req + 1
rq->result = result; <==crash here!!!
[ 1124.256246] nvme nvme5: pci function :e1:00.0
[ 1124.256323] nvme :e1:00.0: enabling device ( -> 0002)
[ 1125.720859] nvme nvme5: 96/0/0 default/read/poll queues
[ 1125.732483] nvme5n1: p1 p2 p3
[ 1125.788049] BUG: unable to handle kernel NULL pointer dereference at
0130
[ 1125.788054] PGD 0 P4D 0
[ 1125.788057] Oops: 0002 [#1] SMP NOPTI
[ 1125.788059] CPU: 50 PID: 0 Comm: swapper/50 Kdump: loaded Tainted: G
--- -t -
4.18.0-147.el8.x86_64 #1
[ 1125.788065] RIP: 0010:nvme_irq+0xe8/0x240 [nvme]
[ 1125.788068] RSP: 0018:916b8ec83ed0 EFLAGS: 00010813
[ 1125.788069] RAX: RBX: 918ae9211b00 RCX:
[ 1125.788070] RDX: 400b RSI: RDI:
[ 1125.788071] RBP: 918ae887 R08: 0004 R09:
918ae887
[ 1125.788072] R10: R11: R12:
[ 1125.788073] R13: 0001 R14: R15:
0001
[ 1125.788075] FS: () GS:916b8ec8()
knlGS:
[ 1125.788075] CS: 0010 DS: ES: CR0: 80050033
[ 1125.788076] CR2: 0130 CR3: 001768f0 CR4:
00340ee0
[ 1125.788077] Call Trace:
[ 1125.788080]
[ 1125.788085] __handle_irq_event_percpu+0x40/0x180
[ 1125.788087] handle_irq_event_percpu+0x30/0x80
[ 1125.788089] handle_irq_event+0x36/0x53
[ 1125.788090] handle_edge_irq+0x82/0x190
[ 1125.788094] handle_irq+0xbf/0x100
[ 1125.788098] do_IRQ+0x49/0xd0
[ 1125.788100] common_interrupt+0xf/0xf
The analysis of the possible cause of above crash as below.
According to the test for io queues, in nvme_pci_enable(), 'dev->q_depth'
is set to 1024; in nvme_create_io_queues()->nvme_alloc_queue(),
'nvmeq->q_depth' is set to 'dev->q_depth'; in nvme_dev_add(),
'dev->tagset.queue_depth' is set to 1023:
dev->tagset.queue_depth = min_t(unsigned int, dev->q_depth,
BLK_MQ_MAX_DEPTH) - 1;
So we got below values for multiple depth:
dev->q_depth= 1024
dev->tagset.queue_depth = 1023
nvmeq->q_depth = 1024
In blk_mq_alloc_rqs(), it allocated 1023(dev->tagset.queue_depth) rqs for
one hw queue. In nvme_alloc_queue(), it allocated 1024(nvmeq->q_depth)
cqes for nvmeq->cqes[]. When process cqe in nvme_handle_cqe(), it get it
by:
struct nvme_completion *cqe = >cqes[idx];
We also added below prints in nvme_handle_cqe() and blk_mq_tag_to_rq():
static inline void nvme_handle_cqe(struct nvme_queue *nvmeq, u16 idx)
{
volatile struct nvme_completion *cqe = >cqes[idx];
struct request *req;
//debug print
dev_warn(nvmeq->dev->ctrl.device,
"command_id %d completed on queue %d, nvmeq q_depth %d,
nvme tagset q_depth %d, admin q_depth %d\n",
cqe->command_id, le16_to_cpu(cqe->sq_id),
nvmeq->q_depth, nvmeq->dev->tagset.queue_depth,
nvmeq->dev->admin_tagset.queue_depth);
if (unlikely(cqe->command_id >= nvmeq->q_depth)) {
dev_warn(nvmeq->dev->ctrl.device,
"invalid id %d completed on queue %d\n",
cqe->command_id, le16_to_cpu(cqe->sq_id));
return;
}
... ...
req = blk_mq_tag_to_rq(nvme_queue_tagset(nvmeq),
cqe->command_id);
... ...
}
struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags,unsigned int
tag)
{
//debug print
printk("tag, nr_tags:%d %d\n", tag, tags->nr_tags);
if (tag < tags->nr_tags) {
prefetch(tags->rqs[tag]);
return tags->rqs[tag];
}
return NULL;
}
According to the output, we know the max tag number(nr_tags) is 1023, but
nvmeq->q_depth is 1024 and nvmeq->cqes[] has 1024 cqes. So if command_id
(tag) is 1023, the judgement "if (unlikely(cqe->command_id >= nvmeq->q_depth))"
in nvme_handle_cqe() is useless, we will get a null pointer, which is
returned by blk_mq_tag_to_rq():
[ 16.649973] nvme nvme0: command_id 968 completed on queue 13,
nvmeq q_depth 1024,
[PATCH] mm: remove unused alloc_page_vma_node()
No one use this macro anymore.
Also fix code style of policy_node().
Signed-off-by: Wei Yang
---
include/linux/gfp.h | 2 --
mm/mempolicy.c | 3 +--
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 67a0774e080b..e83cc7f5a2fc 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -560,8 +560,6 @@ extern struct page *alloc_pages_vma(gfp_t gfp_mask, int
order,
#define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0)
#define alloc_page_vma(gfp_mask, vma, addr)\
alloc_pages_vma(gfp_mask, 0, vma, addr, numa_node_id(), false)
-#define alloc_page_vma_node(gfp_mask, vma, addr, node) \
- alloc_pages_vma(gfp_mask, 0, vma, addr, node, false)
extern unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order);
extern unsigned long get_zeroed_page(gfp_t gfp_mask);
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index eddbe4e56c73..906adc58d86f 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1885,8 +1885,7 @@ nodemask_t *policy_nodemask(gfp_t gfp, struct mempolicy
*policy)
}
/* Return the node id preferred by the given mempolicy, or the given id */
-static int policy_node(gfp_t gfp, struct mempolicy *policy,
- int nd)
+static int policy_node(gfp_t gfp, struct mempolicy *policy, int nd)
{
if (policy->mode == MPOL_PREFERRED && !(policy->flags & MPOL_F_LOCAL))
nd = policy->v.preferred_node;
--
2.20.1 (Apple Git-117)
Re: [PATCH 03/14] dpaa2-eth: drop double zeroing
From: Julia Lawall Date: Sun, 20 Sep 2020 13:26:15 +0200 > sg_init_table zeroes its first argument, so the allocation of that argument > doesn't have to. > > the semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ > expression x,n,flags; > @@ > > x = > - kcalloc > + kmalloc_array > (n,sizeof(struct scatterlist),flags) > ... > sg_init_table(x,n) > // > > Signed-off-by: Julia Lawall Applied.
Re: [PATCH 07/14] RDS: drop double zeroing
From: Julia Lawall Date: Sun, 20 Sep 2020 13:26:19 +0200 > sg_init_table zeroes its first argument, so the allocation of that argument > doesn't have to. > > the semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ > expression x,n,flags; > @@ > > x = > - kcalloc > + kmalloc_array > (n,sizeof(*x),flags) > ... > sg_init_table(x,n) > // > > Signed-off-by: Julia Lawall Applied.
[PATCH net-next] net: use in_softirq() to indicate the NAPI context in napi_consume_skb()
When napi_consume_skb() is called in the tx desc cleaning process,
it is usually in the softirq context(BH disabled, or are processing
softirqs), but it may also be in the task context, such as in the
netpoll or loopback selftest process.
Currently napi_consume_skb() uses non-zero budget to indicate the
NAPI context, the driver writer may provide the wrong budget when
tx desc cleaning function is reused for both NAPI and non-NAPI
context, see [1].
So this patch uses in_softirq() to indicate the NAPI context, which
doesn't necessarily mean in NAPI context, but it shouldn't care if
NAPI context or not as long as it runs in softirq context or with BH
disabled, then _kfree_skb_defer() will push the skb to the particular
cpu' napi_alloc_cache atomically.
[1] https://lkml.org/lkml/2020/9/15/38
Signed-off-by: Yunsheng Lin
---
note that budget parameter is not removed in this patch because it
involves many driver changes, we can remove it in separate patch if
this patch is accepted.
---
net/core/skbuff.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index e077447..03d0d28 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -895,8 +895,10 @@ void __kfree_skb_defer(struct sk_buff *skb)
void napi_consume_skb(struct sk_buff *skb, int budget)
{
- /* Zero budget indicate non-NAPI context called us, like netpoll */
- if (unlikely(!budget)) {
+ /* called by non-softirq context, which usually means non-NAPI
+* context, like netpoll.
+*/
+ if (unlikely(!in_softirq())) {
dev_consume_skb_any(skb);
return;
}
--
2.8.1
[PATCH] fsl: imx-audmix : Use devm_kcalloc() instead of devm_kzalloc()
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "devm_kcalloc".
Signed-off-by: Xu Wang
---
sound/soc/fsl/imx-audmix.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index 202fb8950078..cbdc0a2c09c5 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -185,20 +185,20 @@ static int imx_audmix_probe(struct platform_device *pdev)
return -ENOMEM;
priv->num_dai = 2 * num_dai;
- priv->dai = devm_kzalloc(>dev, priv->num_dai *
+ priv->dai = devm_kcalloc(>dev, priv->num_dai,
sizeof(struct snd_soc_dai_link), GFP_KERNEL);
if (!priv->dai)
return -ENOMEM;
priv->num_dai_conf = num_dai;
- priv->dai_conf = devm_kzalloc(>dev, priv->num_dai_conf *
+ priv->dai_conf = devm_kcalloc(>dev, priv->num_dai_conf,
sizeof(struct snd_soc_codec_conf),
GFP_KERNEL);
if (!priv->dai_conf)
return -ENOMEM;
priv->num_dapm_routes = 3 * num_dai;
- priv->dapm_routes = devm_kzalloc(>dev, priv->num_dapm_routes *
+ priv->dapm_routes = devm_kcalloc(>dev, priv->num_dapm_routes,
sizeof(struct snd_soc_dapm_route),
GFP_KERNEL);
if (!priv->dapm_routes)
@@ -208,7 +208,7 @@ static int imx_audmix_probe(struct platform_device *pdev)
struct snd_soc_dai_link_component *dlc;
/* for CPU/Codec/Platform x 2 */
- dlc = devm_kzalloc(>dev, 6 * sizeof(*dlc), GFP_KERNEL);
+ dlc = devm_kcalloc(>dev, 6, sizeof(*dlc), GFP_KERNEL);
if (!dlc) {
dev_err(>dev, "failed to allocate dai_link\n");
return -ENOMEM;
--
2.17.1
Re: [RFC v5 0/5] Add support length of each segment in the segcblist (breaks TREE04)
On Sun, Sep 20, 2020 at 09:21:47PM -0400, Joel Fernandes (Google) wrote:
>
> NOTE: I marked as RFC since TREE 04 fails even though TREE03 passes. I don't
> see any RCU errors in the counters, however when shutdown thread tries to
> shutdown the system, it hangs when trying to shutdown the rcu_barrier thread.
Looks like if I restore the logic of setting the segcb_list ->len field from
the callers of extract_done_cbs(), then TREE04 issues go away. I am inclined
to do that considering this series, for what it is trying to do, does not
really need to optimize that logic (can be done later).
With the below diff on top of this series, TREE04 passes. I will await any
other review comments before posting another series.. meanwhile, will pass
it through the grinders..
---8<---
diff --git a/include/linux/rcu_segcblist.h b/include/linux/rcu_segcblist.h
index 319a565f6ecb..d462ae5e340a 100644
--- a/include/linux/rcu_segcblist.h
+++ b/include/linux/rcu_segcblist.h
@@ -76,7 +76,6 @@ struct rcu_segcblist {
#endif
u8 enabled;
u8 offloaded;
- u8 invoking;
};
#define RCU_SEGCBLIST_INITIALIZER(n) \
diff --git a/kernel/rcu/rcu_segcblist.c b/kernel/rcu/rcu_segcblist.c
index ec9a609a461b..3c82c016feb1 100644
--- a/kernel/rcu/rcu_segcblist.c
+++ b/kernel/rcu/rcu_segcblist.c
@@ -388,7 +388,6 @@ void rcu_segcblist_extract_done_cbs(struct rcu_segcblist
*rsclp,
if (rsclp->tails[i] == rsclp->tails[RCU_DONE_TAIL])
WRITE_ONCE(rsclp->tails[i], >head);
rcu_segcblist_set_seglen(rsclp, RCU_DONE_TAIL, 0);
- rcu_segcblist_add_len(rsclp, -(rclp->len));
}
/*
@@ -452,7 +451,17 @@ void rcu_segcblist_extract_pend_cbs(struct rcu_segcblist
*rsclp,
WRITE_ONCE(rsclp->tails[i], rsclp->tails[RCU_DONE_TAIL]);
rcu_segcblist_set_seglen(rsclp, i, 0);
}
- rcu_segcblist_add_len(rsclp, -(rclp->len));
+}
+
+/*
+ * Insert counts from the specified rcu_cblist structure in the
+ * specified rcu_segcblist structure.
+ */
+void rcu_segcblist_insert_count(struct rcu_segcblist *rsclp,
+ struct rcu_cblist *rclp)
+{
+ rcu_segcblist_add_len(rsclp, rclp->len);
+ rclp->len = 0;
}
/*
@@ -476,7 +485,6 @@ void rcu_segcblist_insert_done_cbs(struct rcu_segcblist
*rsclp,
break;
rclp->head = NULL;
rclp->tail = >head;
- rcu_segcblist_add_len(rsclp, rclp->len);
}
/*
@@ -492,7 +500,6 @@ void rcu_segcblist_insert_pend_cbs(struct rcu_segcblist
*rsclp,
rcu_segcblist_add_seglen(rsclp, RCU_NEXT_TAIL, rclp->len);
WRITE_ONCE(*rsclp->tails[RCU_NEXT_TAIL], rclp->head);
WRITE_ONCE(rsclp->tails[RCU_NEXT_TAIL], rclp->tail);
- rcu_segcblist_add_len(rsclp, rclp->len);
}
/*
@@ -637,9 +644,12 @@ void rcu_segcblist_merge(struct rcu_segcblist *dst_rsclp,
rcu_cblist_init();
rcu_cblist_init();
+ rcu_segcblist_set_len(src_rsclp, 0);
rcu_segcblist_extract_done_cbs(src_rsclp, );
rcu_segcblist_extract_pend_cbs(src_rsclp, );
+ rcu_segcblist_insert_count(dst_rsclp, );
+ rcu_segcblist_insert_count(dst_rsclp, );
rcu_segcblist_insert_done_cbs(dst_rsclp, );
rcu_segcblist_insert_pend_cbs(dst_rsclp, );
diff --git a/kernel/rcu/rcu_segcblist.h b/kernel/rcu/rcu_segcblist.h
index c2dc08a9b020..15c10d30f88c 100644
--- a/kernel/rcu/rcu_segcblist.h
+++ b/kernel/rcu/rcu_segcblist.h
@@ -40,33 +40,14 @@ static inline bool rcu_segcblist_empty(struct rcu_segcblist
*rsclp)
return !READ_ONCE(rsclp->head);
}
-static inline void rcu_segcblist_set_invoking(struct rcu_segcblist *rsclp)
-{
- WRITE_ONCE(rsclp->invoking, 1);
-}
-
-static inline void rcu_segcblist_reset_invoking(struct rcu_segcblist *rsclp)
-{
- WRITE_ONCE(rsclp->invoking, 0);
-}
-
/* Return number of callbacks in segmented callback list. */
static inline long rcu_segcblist_n_cbs(struct rcu_segcblist *rsclp)
{
- long ret;
#ifdef CONFIG_RCU_NOCB_CPU
- ret = atomic_long_read(>len);
+ return atomic_long_read(>len);
#else
- ret = READ_ONCE(rsclp->len);
+ return READ_ONCE(rsclp->len);
#endif
-
- /*
-* An invoking list should not appear empty. This is required
-* by rcu_barrier().
-*/
- if (ret)
- return ret;
- return (READ_ONCE(rsclp->invoking) ? 1 : 0);
}
/*
@@ -112,6 +93,8 @@ void rcu_segcblist_extract_done_cbs(struct rcu_segcblist
*rsclp,
struct rcu_cblist *rclp);
void rcu_segcblist_extract_pend_cbs(struct rcu_segcblist *rsclp,
struct rcu_cblist *rclp);
+void rcu_segcblist_insert_count(struct rcu_segcblist *rsclp,
+ struct rcu_cblist *rclp);
void rcu_segcblist_insert_done_cbs(struct rcu_segcblist *rsclp,
struct rcu_cblist *rclp);
void rcu_segcblist_insert_pend_cbs(struct
Re: [PATCH] net: phy: realtek: Replace 2.5Gbps name from RTL8125 to RTL8226
From: 劉偉權 Date: Mon, 21 Sep 2020 01:55:23 + > Hi Andrew, > Thanks...understood... This is a top-post. Andrew said to not top-post, and you said you understand this. If you understand it, please stop top-posting. Thank you.
[PATCH -next 4/5] mm/kmemleak-test: use %px instead of %p in print
From: Wei Yongjun
Real addresses are used for diagnose issues.
Convert %p with %px to print kernel addresses.
Signed-off-by: Wei Yongjun
Signed-off-by: Chen Jun
---
mm/kmemleak-test.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/mm/kmemleak-test.c b/mm/kmemleak-test.c
index e19279ff6aa3..75fe1b8c3226 100644
--- a/mm/kmemleak-test.c
+++ b/mm/kmemleak-test.c
@@ -40,25 +40,25 @@ static int __init kmemleak_test_init(void)
pr_info("Kmemleak testing\n");
/* make some orphan objects */
- pr_info("kmalloc(32) = %p\n", kmalloc(32, GFP_KERNEL));
- pr_info("kmalloc(32) = %p\n", kmalloc(32, GFP_KERNEL));
- pr_info("kmalloc(1024) = %p\n", kmalloc(1024, GFP_KERNEL));
- pr_info("kmalloc(1024) = %p\n", kmalloc(1024, GFP_KERNEL));
- pr_info("kmalloc(2048) = %p\n", kmalloc(2048, GFP_KERNEL));
- pr_info("kmalloc(2048) = %p\n", kmalloc(2048, GFP_KERNEL));
- pr_info("kmalloc(4096) = %p\n", kmalloc(4096, GFP_KERNEL));
- pr_info("kmalloc(4096) = %p\n", kmalloc(4096, GFP_KERNEL));
+ pr_info("kmalloc(32) = %px\n", kmalloc(32, GFP_KERNEL));
+ pr_info("kmalloc(32) = %px\n", kmalloc(32, GFP_KERNEL));
+ pr_info("kmalloc(1024) = %px\n", kmalloc(1024, GFP_KERNEL));
+ pr_info("kmalloc(1024) = %px\n", kmalloc(1024, GFP_KERNEL));
+ pr_info("kmalloc(2048) = %px\n", kmalloc(2048, GFP_KERNEL));
+ pr_info("kmalloc(2048) = %px\n", kmalloc(2048, GFP_KERNEL));
+ pr_info("kmalloc(4096) = %px\n", kmalloc(4096, GFP_KERNEL));
+ pr_info("kmalloc(4096) = %px\n", kmalloc(4096, GFP_KERNEL));
#ifndef CONFIG_MODULES
- pr_info("kmem_cache_alloc(files_cachep) = %p\n",
+ pr_info("kmem_cache_alloc(files_cachep) = %px\n",
kmem_cache_alloc(files_cachep, GFP_KERNEL));
- pr_info("kmem_cache_alloc(files_cachep) = %p\n",
+ pr_info("kmem_cache_alloc(files_cachep) = %px\n",
kmem_cache_alloc(files_cachep, GFP_KERNEL));
#endif
- pr_info("vmalloc(64) = %p\n", vmalloc(64));
- pr_info("vmalloc(64) = %p\n", vmalloc(64));
- pr_info("vmalloc(64) = %p\n", vmalloc(64));
- pr_info("vmalloc(64) = %p\n", vmalloc(64));
- pr_info("vmalloc(64) = %p\n", vmalloc(64));
+ pr_info("vmalloc(64) = %px\n", vmalloc(64));
+ pr_info("vmalloc(64) = %px\n", vmalloc(64));
+ pr_info("vmalloc(64) = %px\n", vmalloc(64));
+ pr_info("vmalloc(64) = %px\n", vmalloc(64));
+ pr_info("vmalloc(64) = %px\n", vmalloc(64));
/*
* Add elements to a list. They should only appear as orphan
@@ -66,7 +66,7 @@ static int __init kmemleak_test_init(void)
*/
for (i = 0; i < 10; i++) {
elem = kzalloc(sizeof(*elem), GFP_KERNEL);
- pr_info("kzalloc(sizeof(*elem)) = %p\n", elem);
+ pr_info("kzalloc(sizeof(*elem)) = %px\n", elem);
if (!elem)
return -ENOMEM;
INIT_LIST_HEAD(>list);
@@ -75,7 +75,7 @@ static int __init kmemleak_test_init(void)
for_each_possible_cpu(i) {
per_cpu(kmemleak_test_pointer, i) = kmalloc(129, GFP_KERNEL);
- pr_info("kmalloc(129) = %p\n",
+ pr_info("kmalloc(129) = %px\n",
per_cpu(kmemleak_test_pointer, i));
}
--
2.25.0
[PATCH -next 5/5] mm/kmemleak-test: Add a test case for alloc_percpu
After insmod kmemleak-test.ko, a leaking for alloc_percpu will be
reported as below:
kmemleak: alloc_percpu(sizeof(*elem)) = 7dfdd26a2c40
:
:
unreferenced object 0x7dfdd26a2c40 (size 8):
comm "insmod", pid 183, jiffies 4294905864 (age 40.520s)
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00
backtrace:
[<(ptrval)>] pcpu_alloc+0x3ec/0x8c8
[<(ptrval)>] __alloc_percpu+0x18/0x28
[<(ptrval)>] 0x88df525c
[<(ptrval)>] do_one_initcall+0x60/0x1d8
[<(ptrval)>] do_init_module+0x58/0x1d0
[<(ptrval)>] load_module+0x1d8c/0x23d0
[<(ptrval)>] __do_sys_finit_module+0xdc/0xf8
[<(ptrval)>] __arm64_sys_finit_module+0x20/0x30
[<(ptrval)>] el0_svc_common.constprop.3+0x68/0x170
[<(ptrval)>] do_el0_svc+0x24/0x90
[<(ptrval)>] el0_sync_handler+0x13c/0x1a8
[<(ptrval)>] el0_sync+0x158/0x180
Signed-off-by: Wei Yongjun
Signed-off-by: Chen Jun
---
mm/kmemleak-test.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/kmemleak-test.c b/mm/kmemleak-test.c
index 75fe1b8c3226..8f3e4a60166b 100644
--- a/mm/kmemleak-test.c
+++ b/mm/kmemleak-test.c
@@ -79,6 +79,9 @@ static int __init kmemleak_test_init(void)
per_cpu(kmemleak_test_pointer, i));
}
+ pr_info("alloc_percpu(sizeof(*elem)) = %px\n",
+ alloc_percpu(sizeof(*elem)));
+
return 0;
}
module_init(kmemleak_test_init);
--
2.25.0
[PATCH -next 0/5] mm/kmemleak：support for percpu memory leak detect
Currently the reporting of the percpu chunks leaking problem are not supported. This patch set introduce this feature. PATCH 1-2 do some cleanup to current kmemleak. PATCH 3 make percpu memleak works. PATCH 4-5 add test case for percpu memleak detector. Following links are some real cases detected by it: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71e843295c680898959b22dc877ae3839cc22470 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=667e57da358f61b6966e12e925a69e42d912e8bb *** BLURB HERE *** Chen Jun (1): mm/kmemleak-test: Add a test case for alloc_percpu Wei Yongjun (4): mm/kmemleak: make create_object return void mm/kmemleak: skip update_checksum for OBJECT_NO_SCAN objects mm/kmemleak: Add support for percpu memory leak detect mm/kmemleak-test: use %px instead of %p in print mm/kmemleak-test.c | 37 -- mm/kmemleak.c | 79 +- 2 files changed, 84 insertions(+), 32 deletions(-) -- 2.25.0
[PATCH -next 2/5] mm/kmemleak: skip update_checksum for OBJECT_NO_SCAN objects
From: Wei Yongjun
Objects marked with OBJECT_NO_SCAN are never scanned.
So there is no need to update checksum for them.
Signed-off-by: Wei Yongjun
Signed-off-by: Chen Jun
---
mm/kmemleak.c | 4
1 file changed, 4 insertions(+)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index b3f603fd9fc3..c09c6b59eda6 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1166,6 +1166,10 @@ static bool update_checksum(struct kmemleak_object
*object)
{
u32 old_csum = object->checksum;
+ /* always return false for not scan object */
+ if (object->flags & OBJECT_NO_SCAN)
+ return false;
+
kasan_disable_current();
kcsan_disable_current();
object->checksum = crc32(0, (void *)object->pointer, object->size);
--
2.25.0
[PATCH -next 3/5] mm/kmemleak: Add support for percpu memory leak detect
From: Wei Yongjun
Currently the reporting of the percpu chunks leaking problem
are not supported. This patch introduces this function.
Since __percpu pointer is not pointing directly to the actual chunks,
this patch creates an object for __percpu pointer, but marks it as no
scan block, only check whether this pointer is referenced by other
blocks.
Introduce two global variables, min_percpu_addr and max_percpu_addr,
to store the range of valid percpu pointer values, in order to
speed up pointer lookup when scanning blocks.
Signed-off-by: Wei Yongjun
Signed-off-by: Chen Jun
---
mm/kmemleak.c | 71 ++-
1 file changed, 59 insertions(+), 12 deletions(-)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index c09c6b59eda6..feedb72f06f2 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -170,6 +170,8 @@ struct kmemleak_object {
#define OBJECT_NO_SCAN (1 << 2)
/* flag set to fully scan the object when scan_area allocation failed */
#define OBJECT_FULL_SCAN (1 << 3)
+/* flag set to percpu ptr object */
+#define OBJECT_PERCPU (1 << 4)
#define HEX_PREFIX ""
/* number of bytes to print per line; must be 16 or 32 */
@@ -212,6 +214,9 @@ static int kmemleak_error;
/* minimum and maximum address that may be valid pointers */
static unsigned long min_addr = ULONG_MAX;
static unsigned long max_addr;
+/* minimum and maximum address that may be valid percpu pointers */
+static unsigned long min_percpu_addr = ULONG_MAX;
+static unsigned long max_percpu_addr;
static struct task_struct *scan_thread;
/* used to avoid reporting of recently allocated objects */
@@ -283,6 +288,9 @@ static void hex_dump_object(struct seq_file *seq,
const u8 *ptr = (const u8 *)object->pointer;
size_t len;
+ if (object->flags & OBJECT_PERCPU)
+ ptr = this_cpu_ptr((void __percpu *)object->pointer);
+
/* limit the number of lines to HEX_MAX_LINES */
len = min_t(size_t, object->size, HEX_MAX_LINES * HEX_ROW_SIZE);
@@ -563,17 +571,32 @@ static int __save_stack_trace(unsigned long *trace)
return stack_trace_save(trace, MAX_TRACE, 2);
}
+static void __update_address_range(struct kmemleak_object *object)
+{
+ unsigned long ptr = object->pointer;
+ size_t size = object->size;
+ unsigned long untagged_ptr;
+
+ if (object->flags & OBJECT_PERCPU) {
+ min_percpu_addr = min(min_percpu_addr, ptr);
+ max_percpu_addr = max(max_percpu_addr, ptr + size);
+ } else {
+ untagged_ptr = (unsigned long)kasan_reset_tag((void *)ptr);
+ min_addr = min(min_addr, untagged_ptr);
+ max_addr = max(max_addr, untagged_ptr + size);
+ }
+}
+
/*
* Create the metadata (struct kmemleak_object) corresponding to an allocated
* memory block and add it to the object_list and object_tree_root.
*/
-static void create_object(unsigned long ptr, size_t size, int min_count,
- gfp_t gfp)
+static void __create_object(unsigned long ptr, size_t size, int min_count,
+ unsigned int obj_flags, gfp_t gfp)
{
unsigned long flags;
struct kmemleak_object *object, *parent;
struct rb_node **link, *rb_parent;
- unsigned long untagged_ptr;
object = mem_pool_alloc(gfp);
if (!object) {
@@ -587,7 +610,7 @@ static void create_object(unsigned long ptr, size_t size,
int min_count,
INIT_HLIST_HEAD(>area_list);
raw_spin_lock_init(>lock);
atomic_set(>use_count, 1);
- object->flags = OBJECT_ALLOCATED;
+ object->flags = OBJECT_ALLOCATED | obj_flags;
object->pointer = ptr;
object->size = size;
object->excess_ref = 0;
@@ -619,9 +642,7 @@ static void create_object(unsigned long ptr, size_t size,
int min_count,
raw_spin_lock_irqsave(_lock, flags);
- untagged_ptr = (unsigned long)kasan_reset_tag((void *)ptr);
- min_addr = min(min_addr, untagged_ptr);
- max_addr = max(max_addr, untagged_ptr + size);
+ __update_address_range(object);
link = _tree_root.rb_node;
rb_parent = NULL;
while (*link) {
@@ -651,6 +672,19 @@ static void create_object(unsigned long ptr, size_t size,
int min_count,
raw_spin_unlock_irqrestore(_lock, flags);
}
+static void create_object(unsigned long ptr, size_t size, int min_count,
+ gfp_t gfp)
+{
+ __create_object(ptr, size, min_count, 0, gfp);
+}
+
+static void create_object_percpu(unsigned long ptr, size_t size, int min_count,
+gfp_t gfp)
+{
+ __create_object(ptr, size, min_count, OBJECT_PERCPU | OBJECT_NO_SCAN,
+ gfp);
+}
+
/*
* Mark the object as not allocated and schedule RCU freeing via put_object().
*/
@@ -912,10 +946,12 @@ void __ref kmemleak_alloc_percpu(const void __percpu
*ptr, size_t size,
*
[PATCH -next 1/5] mm/kmemleak: make create_object return void
From: Wei Yongjun
No user cares about the return value of create_object,
so make it return void.
Signed-off-by: Wei Yongjun
Signed-off-by: Chen Jun
---
mm/kmemleak.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index c0014d3b91c1..b3f603fd9fc3 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -567,8 +567,8 @@ static int __save_stack_trace(unsigned long *trace)
* Create the metadata (struct kmemleak_object) corresponding to an allocated
* memory block and add it to the object_list and object_tree_root.
*/
-static struct kmemleak_object *create_object(unsigned long ptr, size_t size,
-int min_count, gfp_t gfp)
+static void create_object(unsigned long ptr, size_t size, int min_count,
+ gfp_t gfp)
{
unsigned long flags;
struct kmemleak_object *object, *parent;
@@ -579,7 +579,7 @@ static struct kmemleak_object *create_object(unsigned long
ptr, size_t size,
if (!object) {
pr_warn("Cannot allocate a kmemleak_object structure\n");
kmemleak_disable();
- return NULL;
+ return;
}
INIT_LIST_HEAD(>object_list);
@@ -640,7 +640,6 @@ static struct kmemleak_object *create_object(unsigned long
ptr, size_t size,
*/
dump_object_info(parent);
kmem_cache_free(object_cache, object);
- object = NULL;
goto out;
}
}
@@ -650,7 +649,6 @@ static struct kmemleak_object *create_object(unsigned long
ptr, size_t size,
list_add_tail_rcu(>object_list, _list);
out:
raw_spin_unlock_irqrestore(_lock, flags);
- return object;
}
/*
--
2.25.0
Re: [PATCH RFC 2/4] mm/page_alloc: place pages to tail in __putback_isolated_page()
On Fri, Sep 18, 2020 at 09:27:23AM +0200, David Hildenbrand wrote: >On 18.09.20 04:07, Wei Yang wrote: >> On Wed, Sep 16, 2020 at 08:34:09PM +0200, David Hildenbrand wrote: >>> __putback_isolated_page() already documents that pages will be placed to >>> the tail of the freelist - this is, however, not the case for >>> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be >>> the case for all existing users. >>> >>> This change affects two users: >>> - free page reporting >>> - page isolation, when undoing the isolation. >>> >>> This behavior is desireable for pages that haven't really been touched >>> lately, so exactly the two users that don't actually read/write page >>> content, but rather move untouched pages. >>> >>> The new behavior is especially desirable for memory onlining, where we >>> allow allocation of newly onlined pages via undo_isolate_page_range() >>> in online_pages(). Right now, we always place them to the head of the >> >> The code looks good, while I don't fully understand the log here. >> >> undo_isolate_page_range() is used in __offline_pages and alloc_contig_range. >> I >> don't connect them with online_pages(). Do I miss something? > >Yeah, please look at -mm / -next instead. See > >https://lkml.kernel.org/r/20200819175957.28465-11-da...@redhat.com > Thanks, I get the point. > >-- >Thanks, > >David / dhildenb -- Wei Yang Help you, Help me
RE: [PATCH] net: phy: realtek: Replace 2.5Gbps name from RTL8125 to RTL8226
Hi Andrew, Thanks...understood... B.R. Willy Original Message- From: Andrew Lunn Sent: Friday, September 18, 2020 10:01 PM To: 劉偉權 Cc: hkallwe...@gmail.com; da...@davemloft.net; li...@armlinux.org.uk; k...@kernel.org; Ryan Kao ; net...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: phy: realtek: Replace 2.5Gbps name from RTL8125 to RTL8226 On Fri, Sep 18, 2020 at 09:02:43AM +, 劉偉權 wrote: > Hi Andrew, > Thanks for your information. Should I do any modifications to make this patch > be applied? Please do not to post. And wrap your text to about 75 characters. Since i think you are new to posting to netdev, we tend to be generous to start with, and allow minor process errors. But we do expect you to learn from what we say, and watch other patches on netdev, so that future patches do follow the processes. So please get [PATCH v] correct in your next patches, include a summary of what has changed between versions, etc. I guess David will accept this patch. If not, he will tell you why and what you need to improve. Andrew --Please consider the environment before printing this e-mail.
RE: [PATCH V2 1/2] bindings: media: gpio-ir-receiver: add linux,autosuspend-period property
> -Original Message- > From: Joakim Zhang > Sent: 2020年9月19日 2:17 > To: mche...@kernel.org; robh...@kernel.org; s...@mess.org > Cc: linux-me...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; dl-linux-imx > Subject: [PATCH V2 1/2] bindings: media: gpio-ir-receiver: add > linux,autosuspend-period property > > Add linux,autosuspend-period property for gpio ir receiver. Some cpuidle > systems wake from idle may take a bit long time, for such case, need disable > cpuidle temporarily. > > Signed-off-by: Joakim Zhang > --- > ChangeLogs: > V1->V2: > * New add. > --- > Documentation/devicetree/bindings/media/gpio-ir-receiver.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > index 58261fb7b408..ef802d5fd1f6 100644 > --- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt > @@ -7,6 +7,8 @@ Required properties: > Optional properties: > - linux,rc-map-name: see rc.txt file in the same > directory. > +- linux,autosuspend-period: autosuspend delay time, > + the unit is milisecond. > > Example node: > > @@ -14,4 +16,5 @@ Example node: > compatible = "gpio-ir-receiver"; > gpios = < 19 1>; > linux,rc-map-name = "rc-rc6-mce"; > + linux,autosuspend-period = 125; Sorry for this, should be linux,autosuspend-period = <125>; Please review the driver part first, will fix it in next version. Best Regards, Joakim Zhang > }; > -- > 2.17.1
[RFC v5 1/5] rcu/tree: Make rcu_do_batch count how many callbacks were executed
Currently, rcu_do_batch() depends on the unsegmented callback list's len field
to know how many CBs are executed. This fields counts down from 0 as CBs are
dequeued. It is possible that all CBs could not be run because of reaching
limits in which case the remaining unexecuted callbacks are requeued in the
CPU's segcblist.
The number of callbacks that were not requeued are then the negative count (how
many CBs were run) stored in the rcl->len which has been counting down on every
dequeue. This negative count is then added to the per-cpu segmented callback
list's to correct its count.
Such a design works against future efforts to track the length of each segment
of the segmented callback list. The reason is because
rcu_segcblist_extract_done_cbs() will be populating the unsegmented callback
list's length field (rcl->len) during extraction.
Also, the design of counting down from 0 is confusing and error-prone IMHO.
This commit therefore explicitly counts have many callbacks were executed in
rcu_do_batch() itself, and uses that to update the per-CPU segcb list's ->len
field, without relying on the negativity of rcl->len.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcu_segcblist.c | 2 +-
kernel/rcu/rcu_segcblist.h | 1 +
kernel/rcu/tree.c | 9 -
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/rcu_segcblist.c b/kernel/rcu/rcu_segcblist.c
index 2d2a6b6b9dfb..bb246d8c6ef1 100644
--- a/kernel/rcu/rcu_segcblist.c
+++ b/kernel/rcu/rcu_segcblist.c
@@ -95,7 +95,7 @@ static void rcu_segcblist_set_len(struct rcu_segcblist
*rsclp, long v)
* This increase is fully ordered with respect to the callers accesses
* both before and after.
*/
-static void rcu_segcblist_add_len(struct rcu_segcblist *rsclp, long v)
+void rcu_segcblist_add_len(struct rcu_segcblist *rsclp, long v)
{
#ifdef CONFIG_RCU_NOCB_CPU
smp_mb__before_atomic(); /* Up to the caller! */
diff --git a/kernel/rcu/rcu_segcblist.h b/kernel/rcu/rcu_segcblist.h
index 5c293afc07b8..b90725f81d77 100644
--- a/kernel/rcu/rcu_segcblist.h
+++ b/kernel/rcu/rcu_segcblist.h
@@ -76,6 +76,7 @@ static inline bool rcu_segcblist_restempty(struct
rcu_segcblist *rsclp, int seg)
}
void rcu_segcblist_inc_len(struct rcu_segcblist *rsclp);
+void rcu_segcblist_add_len(struct rcu_segcblist *rsclp, long v);
void rcu_segcblist_init(struct rcu_segcblist *rsclp);
void rcu_segcblist_disable(struct rcu_segcblist *rsclp);
void rcu_segcblist_offload(struct rcu_segcblist *rsclp);
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 7623128d0020..50af465729f4 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2427,7 +2427,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
rcu_segcblist_is_offloaded(>cblist);
struct rcu_head *rhp;
struct rcu_cblist rcl = RCU_CBLIST_INITIALIZER(rcl);
- long bl, count;
+ long bl, count = 0;
long pending, tlimit = 0;
/* If no callbacks are ready, just return. */
@@ -2472,6 +2472,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
for (; rhp; rhp = rcu_cblist_dequeue()) {
rcu_callback_t f;
+ count++;
debug_rcu_head_unqueue(rhp);
rcu_lock_acquire(_callback_map);
@@ -2485,9 +2486,8 @@ static void rcu_do_batch(struct rcu_data *rdp)
/*
* Stop only if limit reached and CPU has something to do.
-* Note: The rcl structure counts down from zero.
*/
- if (-rcl.len >= bl && !offloaded &&
+ if (count >= bl && !offloaded &&
(need_resched() ||
(!is_idle_task(current) && !rcu_is_callbacks_kthread(
break;
@@ -2510,7 +2510,6 @@ static void rcu_do_batch(struct rcu_data *rdp)
local_irq_save(flags);
rcu_nocb_lock(rdp);
- count = -rcl.len;
rdp->n_cbs_invoked += count;
trace_rcu_batch_end(rcu_state.name, count, !!rcl.head, need_resched(),
is_idle_task(current), rcu_is_callbacks_kthread());
@@ -2518,7 +2517,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
/* Update counts and requeue any remaining callbacks. */
rcu_segcblist_insert_done_cbs(>cblist, );
smp_mb(); /* List handling before counting for rcu_barrier(). */
- rcu_segcblist_insert_count(>cblist, );
+ rcu_segcblist_add_len(>cblist, -count);
/* Reinstate batch limit if we have worked down the excess. */
count = rcu_segcblist_n_cbs(>cblist);
--
2.28.0.681.g6f77f65b4e-goog
[RFC v5 0/5] Add support length of each segment in the segcblist (breaks TREE04)
NOTE: I marked as RFC since TREE 04 fails even though TREE03 passes. I don't see any RCU errors in the counters, however when shutdown thread tries to shutdown the system, it hangs when trying to shutdown the rcu_barrier thread. My suspicion is this is becaues I broke rcu_barrier() however I can't figure out how/where. I added a patch in this series that could fix it, but it still does not alleviate TREE04's issues. I also have a feeling this issue is related to nocb mode. This is required for several usecases identified. One of them being tracing how the segmented callback list changes. Tracing this has identified issues in RCU code in the past. >From Paul: Another use case is of course more accurately determining whether a given CPU's large pile of callbacks can be best served by making grace periods go faster, invoking callbacks more vigorously, or both. It should also be possible to simplify some of the callback handling a bit, given that some of the unnatural acts are due to there having been no per-batch counts. Revision history: v5: Various changes, bug fixes. Discovery of rcu_barrier issue. v4: Restructured rcu_do_batch() and segcblist merging to avoid issues. Fixed minor nit from Davidlohr. v1->v3: minor nits. (https://lore.kernel.org/lkml/20200719034210.2382053-1-j...@joelfernandes.org/) Joel Fernandes (Google) (5): rcu/tree: Make rcu_do_batch count how many callbacks were executed rcu/segcblist: Add counters to segcblist datastructure rcu: Fix rcu_barrier() breakage from earlier patch rcu/trace: Add tracing for how segcb list changes rcu/segcblist: Remove useless rcupdate.h include include/linux/rcu_segcblist.h | 3 + include/trace/events/rcu.h| 25 + kernel/rcu/rcu_segcblist.c| 174 +++--- kernel/rcu/rcu_segcblist.h| 33 +-- kernel/rcu/srcutree.c | 1 - kernel/rcu/tree.c | 22 +++-- 6 files changed, 192 insertions(+), 66 deletions(-) -- 2.28.0.681.g6f77f65b4e-goog
[RFC v5 5/5] rcu/segcblist: Remove useless rcupdate.h include
Signed-off-by: Joel Fernandes (Google) --- kernel/rcu/rcu_segcblist.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/rcu/rcu_segcblist.c b/kernel/rcu/rcu_segcblist.c index 72b284f965aa..13f8f181521d 100644 --- a/kernel/rcu/rcu_segcblist.c +++ b/kernel/rcu/rcu_segcblist.c @@ -10,7 +10,6 @@ #include #include #include -#include #include "rcu_segcblist.h" #include "rcu.h" -- 2.28.0.681.g6f77f65b4e-goog
[RFC v5 3/5] rcu: Fix rcu_barrier() breakage from earlier patch
This patch is split up because I'm not sure about the patch, and also because
it does not fix the issue I am seeing with TREE04. :-(. Though it does fix the
theoretical issue I was considering, with rcu_barrier.
The previous patch breaks rcu_barrier (in theory at least). This is because
rcu_barrier() may skip queuing a callback and return too early. Fix it by
storing
state to indicate that callbacks are being invoked and the callback list should
not appear as non-empty. This is a terrible hack, however it still does not fix
TREE04.
Signed-off-by: Joel Fernandes (Google)
---
include/linux/rcu_segcblist.h | 1 +
kernel/rcu/rcu_segcblist.h| 23 +--
kernel/rcu/tree.c | 4
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/include/linux/rcu_segcblist.h b/include/linux/rcu_segcblist.h
index d462ae5e340a..319a565f6ecb 100644
--- a/include/linux/rcu_segcblist.h
+++ b/include/linux/rcu_segcblist.h
@@ -76,6 +76,7 @@ struct rcu_segcblist {
#endif
u8 enabled;
u8 offloaded;
+ u8 invoking;
};
#define RCU_SEGCBLIST_INITIALIZER(n) \
diff --git a/kernel/rcu/rcu_segcblist.h b/kernel/rcu/rcu_segcblist.h
index 7f4e02bbb806..78949e125364 100644
--- a/kernel/rcu/rcu_segcblist.h
+++ b/kernel/rcu/rcu_segcblist.h
@@ -40,14 +40,33 @@ static inline bool rcu_segcblist_empty(struct rcu_segcblist
*rsclp)
return !READ_ONCE(rsclp->head);
}
+static inline void rcu_segcblist_set_invoking(struct rcu_segcblist *rsclp)
+{
+ WRITE_ONCE(rsclp->invoking, 1);
+}
+
+static inline void rcu_segcblist_reset_invoking(struct rcu_segcblist *rsclp)
+{
+ WRITE_ONCE(rsclp->invoking, 0);
+}
+
/* Return number of callbacks in segmented callback list. */
static inline long rcu_segcblist_n_cbs(struct rcu_segcblist *rsclp)
{
+ long ret;
#ifdef CONFIG_RCU_NOCB_CPU
- return atomic_long_read(>len);
+ ret = atomic_long_read(>len);
#else
- return READ_ONCE(rsclp->len);
+ ret = READ_ONCE(rsclp->len);
#endif
+
+ /*
+* An invoking list should not appear empty. This is required
+* by rcu_barrier().
+*/
+ if (ret)
+ return ret;
+ return READ_ONCE(rsclp->invoking) ? 1 : 0;
}
/*
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index ab4d4e9ff549..23fb6d7b6d4a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2461,6 +2461,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
}
trace_rcu_batch_start(rcu_state.name,
rcu_segcblist_n_cbs(>cblist), bl);
+ rcu_segcblist_set_invoking(>cblist);
rcu_segcblist_extract_done_cbs(>cblist, );
if (offloaded)
rdp->qlen_last_fqs_check = rcu_segcblist_n_cbs(>cblist);
@@ -2517,6 +2518,9 @@ static void rcu_do_batch(struct rcu_data *rdp)
/* Update counts and requeue any remaining callbacks. */
rcu_segcblist_insert_done_cbs(>cblist, );
+ smp_mb();
+ rcu_segcblist_reset_invoking(>cblist);
+
/* Reinstate batch limit if we have worked down the excess. */
count = rcu_segcblist_n_cbs(>cblist);
if (rdp->blimit >= DEFAULT_MAX_RCU_BLIMIT && count <= qlowmark)
--
2.28.0.681.g6f77f65b4e-goog
[RFC v5 4/5] rcu/trace: Add tracing for how segcb list changes
Track how the segcb list changes before/after acceleration, during
queuing and during dequeuing.
This has proved useful to discover an optimization to avoid unwanted GP
requests when there are no callbacks accelerated. The overhead is minimal as
each segment's length is now stored in the respective segment.
Signed-off-by: Joel Fernandes (Google)
---
include/trace/events/rcu.h | 25 +
kernel/rcu/rcu_segcblist.c | 34 ++
kernel/rcu/rcu_segcblist.h | 5 +
kernel/rcu/tree.c | 9 +
4 files changed, 73 insertions(+)
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index 155b5cb43cfd..7b84df3c95df 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -505,6 +505,31 @@ TRACE_EVENT_RCU(rcu_callback,
__entry->qlen)
);
+TRACE_EVENT_RCU(rcu_segcb,
+
+ TP_PROTO(const char *ctx, int *cb_count, unsigned long *gp_seq),
+
+ TP_ARGS(ctx, cb_count, gp_seq),
+
+ TP_STRUCT__entry(
+ __field(const char *, ctx)
+ __array(int, cb_count, 4)
+ __array(unsigned long, gp_seq, 4)
+ ),
+
+ TP_fast_assign(
+ __entry->ctx = ctx;
+ memcpy(__entry->cb_count, cb_count, 4 * sizeof(int));
+ memcpy(__entry->gp_seq, gp_seq, 4 * sizeof(unsigned
long));
+ ),
+
+ TP_printk("%s cb_count: (DONE=%d, WAIT=%d, NEXT_READY=%d,
NEXT=%d) "
+ "gp_seq: (DONE=%lu, WAIT=%lu, NEXT_READY=%lu,
NEXT=%lu)", __entry->ctx,
+ __entry->cb_count[0], __entry->cb_count[1],
__entry->cb_count[2], __entry->cb_count[3],
+ __entry->gp_seq[0], __entry->gp_seq[1],
__entry->gp_seq[2], __entry->gp_seq[3])
+
+);
+
/*
* Tracepoint for the registration of a single RCU callback of the special
* kvfree() form. The first argument is the RCU type, the second argument
diff --git a/kernel/rcu/rcu_segcblist.c b/kernel/rcu/rcu_segcblist.c
index 314799426c2d..72b284f965aa 100644
--- a/kernel/rcu/rcu_segcblist.c
+++ b/kernel/rcu/rcu_segcblist.c
@@ -13,6 +13,7 @@
#include
#include "rcu_segcblist.h"
+#include "rcu.h"
/* Initialize simple callback list. */
void rcu_cblist_init(struct rcu_cblist *rclp)
@@ -344,6 +345,39 @@ void rcu_segcblist_extract_done_cbs(struct rcu_segcblist
*rsclp,
rcu_segcblist_add_len(rsclp, -(rclp->len));
}
+/*
+ * Return how many CBs each segment along with their gp_seq values.
+ *
+ * This function is O(N) where N is the number of callbacks. Only used from
+ * tracing code which is usually disabled in production.
+ */
+#ifdef CONFIG_RCU_TRACE
+static void rcu_segcblist_countseq(struct rcu_segcblist *rsclp,
+int cbcount[RCU_CBLIST_NSEGS],
+unsigned long gpseq[RCU_CBLIST_NSEGS])
+{
+ int i;
+
+ for (i = 0; i < RCU_CBLIST_NSEGS; i++)
+ cbcount[i] = 0;
+
+ for (i = 0; i < RCU_CBLIST_NSEGS; i++) {
+ cbcount[i] = rcu_segcblist_get_seglen(rsclp, i);
+ gpseq[i] = rsclp->gp_seq[i];
+ }
+}
+
+void trace_rcu_segcb_list(struct rcu_segcblist *rsclp, char *context)
+{
+ int cbs[RCU_CBLIST_NSEGS];
+ unsigned long gps[RCU_CBLIST_NSEGS];
+
+ rcu_segcblist_countseq(rsclp, cbs, gps);
+
+ trace_rcu_segcb(context, cbs, gps);
+}
+#endif
+
/*
* Extract only those callbacks still pending (not yet ready to be
* invoked) from the specified rcu_segcblist structure and place them in
diff --git a/kernel/rcu/rcu_segcblist.h b/kernel/rcu/rcu_segcblist.h
index 78949e125364..ca2a403591e4 100644
--- a/kernel/rcu/rcu_segcblist.h
+++ b/kernel/rcu/rcu_segcblist.h
@@ -120,3 +120,8 @@ void rcu_segcblist_advance(struct rcu_segcblist *rsclp,
unsigned long seq);
bool rcu_segcblist_accelerate(struct rcu_segcblist *rsclp, unsigned long seq);
void rcu_segcblist_merge(struct rcu_segcblist *dst_rsclp,
struct rcu_segcblist *src_rsclp);
+#ifdef CONFIG_RCU_TRACE
+void trace_rcu_segcb_list(struct rcu_segcblist *rsclp, char *context);
+#else
+#define trace_rcu_segcb_list(...)
+#endif
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 23fb6d7b6d4a..3afb0e4daca6 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1492,6 +1492,8 @@ static bool rcu_accelerate_cbs(struct rcu_node *rnp,
struct rcu_data *rdp)
if (!rcu_segcblist_pend_cbs(>cblist))
return false;
+ trace_rcu_segcb_list(>cblist, "SegCbPreAcc");
+
/*
* Callbacks are often registered with incomplete grace-period
* information. Something about the fact that getting exact
@@ -1512,6 +1514,8 @@ static bool rcu_accelerate_cbs(struct rcu_node *rnp,
struct rcu_data *rdp)
else
trace_rcu_grace_period(rcu_state.name, gp_seq_req,
[RFC v5 2/5] rcu/segcblist: Add counters to segcblist datastructure
Add counting of segment lengths of segmented callback list.
This will be useful for a number of things such as knowing how big the
ready-to-execute segment have gotten. The immediate benefit is ability
to trace how the callbacks in the segmented callback list change.
Also this patch remove hacks related to using donecbs's ->len field as a
temporary variable to save the segmented callback list's length. This is not
needed any more.
Signed-off-by: Joel Fernandes (Google)
---
include/linux/rcu_segcblist.h | 2 +
kernel/rcu/rcu_segcblist.c| 137 +-
kernel/rcu/rcu_segcblist.h| 4 -
kernel/rcu/srcutree.c | 1 -
kernel/rcu/tree.c | 2 -
5 files changed, 88 insertions(+), 58 deletions(-)
diff --git a/include/linux/rcu_segcblist.h b/include/linux/rcu_segcblist.h
index b36afe7b22c9..d462ae5e340a 100644
--- a/include/linux/rcu_segcblist.h
+++ b/include/linux/rcu_segcblist.h
@@ -69,8 +69,10 @@ struct rcu_segcblist {
unsigned long gp_seq[RCU_CBLIST_NSEGS];
#ifdef CONFIG_RCU_NOCB_CPU
atomic_long_t len;
+ atomic_long_t seglen[RCU_CBLIST_NSEGS];
#else
long len;
+ long seglen[RCU_CBLIST_NSEGS];
#endif
u8 enabled;
u8 offloaded;
diff --git a/kernel/rcu/rcu_segcblist.c b/kernel/rcu/rcu_segcblist.c
index bb246d8c6ef1..314799426c2d 100644
--- a/kernel/rcu/rcu_segcblist.c
+++ b/kernel/rcu/rcu_segcblist.c
@@ -88,6 +88,62 @@ static void rcu_segcblist_set_len(struct rcu_segcblist
*rsclp, long v)
#endif
}
+/* Get the length of a segment of the rcu_segcblist structure. */
+static long rcu_segcblist_get_seglen(struct rcu_segcblist *rsclp, int seg)
+{
+#ifdef CONFIG_RCU_NOCB_CPU
+ return atomic_long_read(>seglen[seg]);
+#else
+ return READ_ONCE(rsclp->seglen[seg]);
+#endif
+}
+
+/* Set the length of a segment of the rcu_segcblist structure. */
+static void rcu_segcblist_set_seglen(struct rcu_segcblist *rsclp, int seg,
long v)
+{
+#ifdef CONFIG_RCU_NOCB_CPU
+ atomic_long_set(>seglen[seg], v);
+#else
+ WRITE_ONCE(rsclp->seglen[seg], v);
+#endif
+}
+
+/* Return number of callbacks in a segment of the segmented callback list. */
+static void rcu_segcblist_add_seglen(struct rcu_segcblist *rsclp, int seg,
long v)
+{
+#ifdef CONFIG_RCU_NOCB_CPU
+ smp_mb__before_atomic(); /* Up to the caller! */
+ atomic_long_add(v, >seglen[seg]);
+ smp_mb__after_atomic(); /* Up to the caller! */
+#else
+ smp_mb(); /* Up to the caller! */
+ WRITE_ONCE(rsclp->seglen[seg], rsclp->seglen[seg] + v);
+ smp_mb(); /* Up to the caller! */
+#endif
+}
+
+/* Move from's segment length to to's segment. */
+static void rcu_segcblist_move_seglen(struct rcu_segcblist *rsclp, int from,
int to)
+{
+ long len;
+
+ if (from == to)
+ return;
+
+ len = rcu_segcblist_get_seglen(rsclp, from);
+ if (!len)
+ return;
+
+ rcu_segcblist_add_seglen(rsclp, to, len);
+ rcu_segcblist_set_seglen(rsclp, from, 0);
+}
+
+/* Increment segment's length. */
+static void rcu_segcblist_inc_seglen(struct rcu_segcblist *rsclp, int seg)
+{
+ rcu_segcblist_add_seglen(rsclp, seg, 1);
+}
+
/*
* Increase the numeric length of an rcu_segcblist structure by the
* specified amount, which can be negative. This can cause the ->len
@@ -119,26 +175,6 @@ void rcu_segcblist_inc_len(struct rcu_segcblist *rsclp)
rcu_segcblist_add_len(rsclp, 1);
}
-/*
- * Exchange the numeric length of the specified rcu_segcblist structure
- * with the specified value. This can cause the ->len field to disagree
- * with the actual number of callbacks on the structure. This exchange is
- * fully ordered with respect to the callers accesses both before and after.
- */
-static long rcu_segcblist_xchg_len(struct rcu_segcblist *rsclp, long v)
-{
-#ifdef CONFIG_RCU_NOCB_CPU
- return atomic_long_xchg(>len, v);
-#else
- long ret = rsclp->len;
-
- smp_mb(); /* Up to the caller! */
- WRITE_ONCE(rsclp->len, v);
- smp_mb(); /* Up to the caller! */
- return ret;
-#endif
-}
-
/*
* Initialize an rcu_segcblist structure.
*/
@@ -149,8 +185,10 @@ void rcu_segcblist_init(struct rcu_segcblist *rsclp)
BUILD_BUG_ON(RCU_NEXT_TAIL + 1 != ARRAY_SIZE(rsclp->gp_seq));
BUILD_BUG_ON(ARRAY_SIZE(rsclp->tails) != ARRAY_SIZE(rsclp->gp_seq));
rsclp->head = NULL;
- for (i = 0; i < RCU_CBLIST_NSEGS; i++)
+ for (i = 0; i < RCU_CBLIST_NSEGS; i++) {
rsclp->tails[i] = >head;
+ rcu_segcblist_set_seglen(rsclp, i, 0);
+ }
rcu_segcblist_set_len(rsclp, 0);
rsclp->enabled = 1;
}
@@ -245,6 +283,7 @@ void rcu_segcblist_enqueue(struct rcu_segcblist *rsclp,
struct rcu_head *rhp)
{
rcu_segcblist_inc_len(rsclp);
+ rcu_segcblist_inc_seglen(rsclp, RCU_NEXT_TAIL);
smp_mb(); /* Ensure counts are updated before callback is enqueued.
[PATCH v2 net-next] net: phy: realtek: enable ALDPS to save power for RTL8211F
Enable ALDPS(Advanced Link Down Power Saving) to save power when
link down.
Signed-off-by: Jisheng Zhang
---
Since v1:
- add what does ALDPS mean.
- replace magic number 0x18 with RTL8211F_PHYCR1 macro.
drivers/net/phy/realtek.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 95dbe5e8e1d8..4bf54cded48a 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -27,11 +27,16 @@
#define RTL821x_EXT_PAGE_SELECT0x1e
#define RTL821x_PAGE_SELECT0x1f
+#define RTL8211F_PHYCR10x18
#define RTL8211F_INSR 0x1d
#define RTL8211F_TX_DELAY BIT(8)
#define RTL8211F_RX_DELAY BIT(3)
+#define RTL8211F_ALDPS_PLL_OFF BIT(1)
+#define RTL8211F_ALDPS_ENABLE BIT(2)
+#define RTL8211F_ALDPS_XTAL_OFFBIT(12)
+
#define RTL8211E_TX_DELAY BIT(1)
#define RTL8211E_RX_DELAY BIT(2)
#define RTL8211E_MODE_MII_GMII BIT(3)
@@ -178,8 +183,12 @@ static int rtl8211f_config_init(struct phy_device *phydev)
{
struct device *dev = >mdio.dev;
u16 val_txdly, val_rxdly;
+ u16 val;
int ret;
+ val = RTL8211F_ALDPS_ENABLE | RTL8211F_ALDPS_PLL_OFF |
RTL8211F_ALDPS_XTAL_OFF;
+ phy_modify_paged_changed(phydev, 0xa43, RTL8211F_PHYCR1, val, val);
+
switch (phydev->interface) {
case PHY_INTERFACE_MODE_RGMII:
val_txdly = 0;
--
2.28.0
[PATCH -next] mtd: rawnand: remove redundant dev_err call in cadence_nand_dt_probe
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Liu Shixin
---
drivers/mtd/nand/raw/cadence-nand-controller.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/raw/cadence-nand-controller.c
b/drivers/mtd/nand/raw/cadence-nand-controller.c
index db29e5e512df..b46786cd53e0 100644
--- a/drivers/mtd/nand/raw/cadence-nand-controller.c
+++ b/drivers/mtd/nand/raw/cadence-nand-controller.c
@@ -2980,18 +2980,14 @@ static int cadence_nand_dt_probe(struct platform_device
*ofdev)
dev_info(cdns_ctrl->dev, "IRQ: nr %d\n", cdns_ctrl->irq);
cdns_ctrl->reg = devm_platform_ioremap_resource(ofdev, 0);
- if (IS_ERR(cdns_ctrl->reg)) {
- dev_err(>dev, "devm_ioremap_resource res 0 failed\n");
+ if (IS_ERR(cdns_ctrl->reg))
return PTR_ERR(cdns_ctrl->reg);
- }
res = platform_get_resource(ofdev, IORESOURCE_MEM, 1);
cdns_ctrl->io.dma = res->start;
cdns_ctrl->io.virt = devm_ioremap_resource(>dev, res);
- if (IS_ERR(cdns_ctrl->io.virt)) {
- dev_err(cdns_ctrl->dev, "devm_ioremap_resource res 1 failed\n");
+ if (IS_ERR(cdns_ctrl->io.virt))
return PTR_ERR(cdns_ctrl->io.virt);
- }
dt->clk = devm_clk_get(cdns_ctrl->dev, "nf_clk");
if (IS_ERR(dt->clk))
--
2.25.1
