From: Ingo Molnar <mingo@kernel.org>
To: Sasha Levin <sashal@kernel.org>
Cc: torvalds@linux-foundation.org, peterz@infradead.org,
linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH v4 00/14] liblockdep fixes for 5.9-rc1
Date: Thu, 6 Aug 2020 10:09:41 +0200 [thread overview]
Message-ID: <20200806080941.GA1697074@gmail.com> (raw)
In-Reply-To: <20200805001043.3331907-1-sashal@kernel.org>
* Sasha Levin <sashal@kernel.org> wrote:
> Hi Linus,
>
> Please consider applying these patches for liblockdep, or alternatively
> pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux.git tags/liblockdep-fixes-040820
>
> The patches fix up compilation and functionality of liblockdep on 5.8,
> they were tested using liblockdep's internal testsuite.
>
> I was unable to get the x86 folks to pull these fixes for the past few
> months:
So the primary reason I didn't pull is that liblockdep was permanently
build-broken from February 2019 to around February 2020, despite me
pinging you multiple times about it.
> - https://lkml.org/lkml/2020/2/17/1089
This pull request still said that if fixes "most of" liblockdep, not
"all of", which is the benchmark really after such a long series of
breakage.
> - https://lkml.org/lkml/2020/4/18/817
This still said "most of".
> - https://lkml.org/lkml/2020/6/22/1262
Same 'most of' verbiage.
> Which is why this pull request ends up going straight to you.
So at this point I think we need to ask whether it's worth it: are
there any actual users of liblockdep, besides the testcases in
liblockdep itself? I see there's a 'liblockdep-dev' package for
Debian, but not propagated to Ubuntu or other popular variants AFAICS.
Also, could you please specify whether all bugs are fixed or just
'most'?
> Sasha Levin (14):
> tools headers: Add kprobes.h header
> tools headers: Add rcupdate.h header
> tools/kernel.h: extend with dummy RCU functions
> tools bitmap: add bitmap_andnot definition
> tools/lib/lockdep: add definition required for IRQ flag tracing
> tools bitmap: add bitmap_clear definition
> tools/lib/lockdep: Hook up vsprintf, find_bit, hweight libraries
> tools/lib/lockdep: Enable building with CONFIG_TRACE_IRQFLAGS
> tools/lib/lockdep: New stacktrace API
> tools/lib/lockdep: call lockdep_init_task on init
> tools/lib/lockdep: switch to using lockdep_init_map_waits
> tools/kernel.h: hide noinstr
> tools/lib/lockdep: explicitly declare lockdep_init_task()
> tools/kernel.h: hide task_struct.hardirq_chain_key
Style nits, please use consistent titles for patches:
- First word should be capitalized consistently, instead of mismash
of lower case mixed with upper case.
- First word should preferably be a verb, i.e. "Add new stacktrace
API stubs", not "New stacktrace API"
Also, please always check linux-next whether there's some new upstream
changes that liblockdep needs to adapt to. Right now there's a new
build breakage even with all your fixes applied:
thule:~/tip/tools/lib/lockdep> make
CC common.o
In file included from ../../include/linux/lockdep.h:24,
from common.c:5:
../../include/linux/../../../include/linux/lockdep.h:13:10: fatal error: linux/lockdep_types.h: No such file or directory
13 | #include <linux/lockdep_types.h>
| ^~~~~~~~~~~~~~~~~~~~~~~
At which point we need to step back and analyze the development model:
this comparatively high rate of breakage derives from the unorthodox
direct coupling of a kernel subsystem to a user-space library.
The solution for that would be to use the method how perf syncs to
kernel space headers, by maintaining a 100% copy in tools/include/ and
having automatic mechanism that warns about out of sync headers but
doesn't break functionality.
See tools/perf/check-headers.sh for details.
I believe this same half-automated sync-on-upstream-changes model
could be used for liblockdep as well, i.e. lets copy kernel/lockdep.c
and lockdep*.h over to tools/lib/lockdep/, and reuse the perf header
syncing method to keep it synchronized from that point on.
That would result in a far more maintainable liblockdep end result
IMO?
Thanks,
Ingo
next prev parent reply other threads:[~2020-08-06 11:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-05 0:10 [PATCH v4 00/14] liblockdep fixes for 5.9-rc1 Sasha Levin
2020-08-05 0:10 ` [PATCH v4 01/14] tools headers: Add kprobes.h header Sasha Levin
2020-08-05 0:10 ` [PATCH v4 02/14] tools headers: Add rcupdate.h header Sasha Levin
2020-08-05 0:10 ` [PATCH v4 03/14] tools/kernel.h: extend with dummy RCU functions Sasha Levin
2020-08-05 0:10 ` [PATCH v4 04/14] tools bitmap: add bitmap_andnot definition Sasha Levin
2020-08-05 0:10 ` [PATCH v4 05/14] tools/lib/lockdep: add definition required for IRQ flag tracing Sasha Levin
2020-08-05 0:10 ` [PATCH v4 06/14] tools bitmap: add bitmap_clear definition Sasha Levin
2020-08-05 0:10 ` [PATCH v4 07/14] tools/lib/lockdep: Hook up vsprintf, find_bit, hweight libraries Sasha Levin
2020-08-05 0:10 ` [PATCH v4 08/14] tools/lib/lockdep: Enable building with CONFIG_TRACE_IRQFLAGS Sasha Levin
2020-08-05 0:10 ` [PATCH v4 09/14] tools/lib/lockdep: New stacktrace API Sasha Levin
2020-08-05 0:10 ` [PATCH v4 10/14] tools/lib/lockdep: call lockdep_init_task on init Sasha Levin
2020-08-05 0:10 ` [PATCH v4 11/14] tools/lib/lockdep: switch to using lockdep_init_map_waits Sasha Levin
2020-08-05 0:10 ` [PATCH v4 12/14] tools/kernel.h: hide noinstr Sasha Levin
2020-08-05 0:10 ` [PATCH v4 13/14] tools/lib/lockdep: explicitly declare lockdep_init_task() Sasha Levin
2020-08-05 0:10 ` [PATCH v4 14/14] tools/kernel.h: hide task_struct.hardirq_chain_key Sasha Levin
2020-08-06 8:09 ` Ingo Molnar [this message]
2020-08-07 22:25 ` [PATCH v4 00/14] liblockdep fixes for 5.9-rc1 Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200806080941.GA1697074@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sashal@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).