linux-kernel - NFS livelock / starvation ?

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]

Message-ID: <67029b170704160124y7bfcb535h8dfbeb1530446469@mail.gmail.com>
Date:	Mon, 16 Apr 2007 16:24:51 +0800
From:	"Zhou Yingchao" <yingchao.zhou@...il.com>
To:	akpm@....com.au, trond.myklebust@....uio.no, neilb@....unsw.edu.au,
	nfs@...ts.sourceforge.net
Cc:	linux-kernel@...r.kernel.org
Subject: NFS livelock / starvation ?

When we run a two nfs client and a nfs server in the following way, we
met a livelock / starvation condition.

MachineA        MachineB
 Client1             Client2
 Server

As shown in the figure, we run a client and server on one machine, and
run another client on another machine. When Client1 and Client2 make
many writes at the same time, the Client1's request is blocked until
Client2's writes finished.

We check the code, Client1 is blocked in generic_file_write-> ...
>balance_dirty_pages, balance_dirty_pages call writeback_inodes to
(only) flush data of the related fs.

In nfs, we found that the Server has enhanced its dirty_thresh. So in
the loop of writeback_inodes, Client1 has no data to write out, and
the condition "ns_reclaimable+wbs.nr_writeback<=dirty_thresh" will not
be true until Client2 finishes its write request to Server. So the
loop will only end after Client2 finished its write job.

The problem in this path is: why we write only pages of the related fs
in writeback_inodes but check the dirty thresh for total pages?

-- 
Yingchao Zhou
***********************************************
 Institute Of Computing Technology
 Chinese Academy of Sciences
***********************************************
-
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/