From: David Hinds <dhinds@sonic.net>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Worst recursion in the kernel
Date: Wed, 3 Dec 2003 10:07:09 -0800 [thread overview]
Message-ID: <20031203100709.B6625@sonic.net> (raw)
In-Reply-To: <20031203143122.GA6470@wohnheim.fh-wedel.de>
On Wed, Dec 03, 2003 at 03:31:22PM +0100, Jörn Engel wrote:
> Really bad code demand really rude words, sorry.
>
>
> After playing with stack checking again, I've found this little beauty
> in 2.6.0-test3: [1]
>
> WARNING: recursion detected:
> 20 read_cis_cache
> 36 pcmcia_get_tuple_data
> 308 read_tuple
> 448 pcmcia_validate_cis
> 12 readable
> 24 cis_readable
> 28 do_mem_probe
> 24 inv_probe
> 16 validate_mem
> 32 set_cis_map
> 28 read_cis_mem
> 284 verify_cis_cache
>
> Explanation:
> verify_cis_cache calls read_cis_mem, which calls set_cis_map, which
> call ..., which calls read_cis_cache, which finally calls
> verify_cis_cache again.
Err... no it doesn't. verify_cis_cache() is called from exactly one
place which is not in the list of functions here. I do not understand
how this recursion checking is being done but there's something weird
going on. set_cis_map() does not call any function on this list. I
think set_cis_map() should be setup_cis_mem().
> Most likely this recursion will never occur, as one of those calls can
> depends on circumstances that prohibit recursion, but semantic
> checking is a bitch for software and in this case even for humans.
> Put another way: THERE IS NO WAY TO MAKE SURE THIS WORKS.
Isn't that a bit strong a statement?
The semantics of the code goes like this. read_cis_mem() checks to
see if something has been done. If it hasn't been done, it leads to
validate_mem() which first does that thing, and then does some stuff
that leads to read_cis_mem() being called again. When read_cis_mem()
is reentered, it is guaranteed that the condition for recursion does
not exist.
Is that so complex as to be incomprehensible by a mere human? To
remove the apparent recursion seems to me to require duplicating a
fairly long code path, which is why I did it this way in the first
place. The stack usage of this code path is definitely something that
should be (and can be easily) fixed.
-- Dave
next prev parent reply other threads:[~2003-12-03 18:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-03 14:31 Worst recursion in the kernel Jörn Engel
2003-12-03 18:07 ` David Hinds [this message]
2003-12-03 19:04 ` Jörn Engel
2003-12-03 22:57 ` Russell King
2003-12-03 23:08 ` Mike Fedyk
2003-12-03 23:36 ` David Hinds
2003-12-04 14:14 ` Jörn Engel
2003-12-04 15:08 ` Martin Waitz
2003-12-04 18:40 ` Russell King
2003-12-04 18:46 ` Jörn Engel
2003-12-03 23:08 ` David Hinds
2003-12-04 13:47 ` Jörn Engel
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=20031203100709.B6625@sonic.net \
--to=dhinds@sonic.net \
--cc=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.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