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

Date:	Fri, 18 Aug 2006 19:44:35 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Daniel Phillips <phillips@...gle.com>
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

On Fri, 18 Aug 2006 16:44:01 -0700
Daniel Phillips <phillips@...gle.com> wrote:

> handwaving

- The mmap(MAP_SHARED)-the-whole-world scenario should be fixed by
  mm-tracking-shared-dirty-pages.patch.  Please test it and if you are
  still able to demonstrate deadlocks, describe how, and why they
  are occurring.

- We expect that the lots-of-dirty-anon-memory-over-swap-over-network
  scenario might still cause deadlocks.  

  I assert that this can be solved by putting swap on local disks.  Peter
  asserts that this isn't acceptable due to disk unreliability.  I point
  out that local disk reliability can be increased via MD, all goes quiet.

  A good exposition which helps us to understand whether and why a
  significant proportion of the target user base still wishes to do
  swap-over-network would be useful.

- Assuming that exposition is convincing, I would ask that you determine
  at what level of /proc/sys/vm/min_free_kbytes the swap-over-network
  deadlock is no longer demonstrable.

If there are any remaining demonstrable deadlock scenarios, please describe
how they were created and, if possible, perform some analysis of them for
us.  sysrq-T and sysrq-M traces would be helpful.

Once we have this information in hand, we will be in a better position to
work out how to solve these problems.

Thanks.
-
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/