linux-kernel - Re: bug in RLIMIT

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-prev] [day] [month] [year] [list]

Message-Id: <20070428224743.6D12A1801A4@magilla.sf.frob.com>
Date:	Sat, 28 Apr 2007 15:47:43 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	"Miguel Freitas" <mfreitas@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: bug in RLIMIT_SIGPENDING

I don't think there is any reason to think the accounting is wrong.  The
accounted number of queue entries is 1.  The -1 (~0ul) displayed is the
maximum for your process, which is RLIM_INFINITY.

Nothing in what you've reported so far points positively towards a signals
issue per se.  First, you should see if you simply have a livelock
situation.  That is, your signal handler is running many times and never
letting fork complete.  Try setting the itimer to a much larger value like
one second, and see if the problem still occurs.  If not, you may just be
having timer signals going off too fast to finish a fork in between.  If
this is the case and it seems like fork should not take as long as it does,
then you can look into how long fork is really taking and why.

If in fact your signal handler does not run many times, then the issue is
stranger.

Thanks,
Roland
-
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/