linux-kernel - Re: [RFC][PATCH 2/9] deadlock prevention core

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Aug 2006 16:44:01 -0700
From:	Daniel Phillips <phillips@...gle.com>
To:	Andrew Morton <akpm@...l.org>
CC:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	David Miller <davem@...emloft.net>, riel@...hat.com,
	tgraf@...g.ch, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Mike Christie <michaelc@...wisc.edu>
Subject: Re: [RFC][PATCH 2/9] deadlock prevention core

Andrew Morton wrote:
> ...in my earlier emails I asked a number of questions regarding
> whether existing facilities, queued patches or further slight kernel
> changes could provide a sufficient solution to these problems.  The answer
> may well be "no".  But diligence requires that we be able to prove that,
> and handwaving doesn't provide that proof, does it?

Hi Andrew,

I missed those questions about queued patches.  So far the closest we
have seen to anything relevant is Evgeniy's proposed network sub-allocater,
which just doesn't address the problem, as Peter and I have explained in
some detail, and the dirty page throttling machinery which is obviously
flawed in that it leaves a lot of room for corner cases that have to be
handled with more special purpose logic.  For example, what about kernel
users that just go ahead and use lots of slab without getting involved
in the dirty/mapped page accounting?  I don't know, maybe you will handle
that too, but then there will be another case that isn't handled, and so
on.  The dirty page throttling approach is just plain fragile by nature.

We already know we need to do reserve accounting for struct bio, so what
is the conceptual difficulty in extending that reasoning to struct
sk_buff, which is very nearly the same kind of beastie, performing very
nearly the same kind of function, and suffering very nearly the same kind
of problems we had in the block layer before mingo's mempool machinery
arrived?

Did I miss some other queued patch that bears on this?  And I am not sure
what handwaving you are referring to.

Note that we have not yet submitted this patch to the queue, just put
it up for comment.  This patch set is actually getting more elegant as
various individual artists get their flames in.  At some point it will
acquire a before-and-after test case as well, then we can realistically
compare it to the best of the alternate proposals.

Regards,

Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/