Thread (64 messages) 64 messages, 7 authors, 2022-03-10

Re: [PATCH 00/16] DEPT(Dependency Tracker)

From: Byungchul Park <hidden>
Date: 2022-02-19 10:35:16
Also in: dri-devel, linux-ext4, linux-fsdevel, linux-ide, linux-mm, lkml

On Thu, Feb 17, 2022 at 11:19:15PM -0500, Theodore Ts'o wrote:
On Thu, Feb 17, 2022 at 12:00:05PM -0500, Steven Rostedt wrote:
quoted
I personally believe that there's potential that this can be helpful and we
will want to merge it.

But, what I believe Ted is trying to say is, if you do not know if the
report is a bug or not, please do not ask the maintainers to determine it
for you. This is a good opportunity for you to look to see why your tool
reported an issue, and learn that subsystem. Look at if this is really a
bug or not, and investigate why.
I agree there's potential here, or I would have ignored the ext4 "bug
report".
I just checked this one. Appreciate it...
When we can get rid of the false positives, I think it should be
Of course, the false positives should be removed once it's found. I will
try my best to remove all of those on my own as much as possible.
However, thing is I can't see others than what I can see with my system.
merged; I'd just rather it not be merged until after the false
positives are fixed, since otherwise, someone well-meaning will start
using it with Syzkaller, and noise that maintainers need to deal with
(with people requesting reverts of two year old commits, etc) will
increase by a factor of ten or more.  (With Syzbot reproducers that
Agree.
set up random cgroups, IP tunnels with wiregaurd enabled, FUSE stress
testers, etc., that file system maintainers will be asked to try to
disentangle.)

So from a maintainer's perspective, false positives are highly
negative.  It may be that from some people's POV, one bug found and 20
false positive might still be "useful".  But if your tool gains a
reputation of not valuing maintainers' time, it's just going to make
us (or at least me :-) cranky, and it's going to be very hard to
Agree.
recover from perception.  So it's probably better to be very
conservative and careful in polishing it before asking for it to be
merged.
If it's true that there are too many false positives like 95%, then I'll
fix those fist for sure before asking to merge it. Let's see if so.

To kernel developers,

It'd be appreciated if you'd let us know if you can see real ones than
false positives in the middle of developing something in the kernel so
it's useful. Otherwise, it's hard to measure how many false positives it
reports and how valuable it is and so on...

Thanks,
Byungchul
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help