Please start the conversation this way next time.
> I call that a bug. You don't. Fine.
You made it sound like a data corrupter, a kernel crasher, and that
any bug against a kernel with that patch indicates my patch caused it.
There is an important distinction between "this is doing something
silly" and "this will scramble your disk and crash the kernel".
The latter is the conclusion several people came to.
And I wanted a clarification on this, nothing more.
I wanted this clarification from you _BECAUSE_ the original posting in
this thread saw data corruption which went away after reverting my
patch. But there is no possible connection between my patch and the
crashes he saw.
Many people have already concluded that "Linus says davem's patch is
crap so it must have been causing the corruptions of the original
reporter."
Like you and I, most people are lazy. And a lazy person is likely
to treat "bug goes away with reverting patch" plus "Linus says the
patch is crap" as "get rid of the patch, this'll fix the bug". And
that'll be the end of it, nobody will investigate the true cause of
the problem until it shows up again later for some different reason.
> But that code isn't coming anywhere _close_ to my tree until the two
> match. And I stand by my assertion that it should be reverted from Alans
> tree too.
I have no intent to ever submit that patch to your tree, I know it's
not the right way to solve this problem.
In fact I submitted that patch to you as an "[RFC]" a long time ago
and it fell on deaf ears. Or perhaps you happened to have laser eye
surgery that particular day, who knows. :-)
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/