Why don't you send a patch? -----Original Message----- From: Peng Tao [mailto:bergwolf@xxxxxxxxx] Sent: Thursday, August 07, 2014 7:52 AM To: Christoph Hellwig Cc: Trond Myklebust; linuxnfs; faibish, sorin Subject: Re: [PATCH 08/17] pnfs/blocklayout: reject pnfs blocksize larger than page size On Thu, Aug 7, 2014 at 7:25 PM, Christoph Hellwig <hch@xxxxxx> wrote: > On Thu, Aug 07, 2014 at 06:43:14PM +0800, Peng Tao wrote: >> So this kills EMC server support. > > Given the state the code claiming support for any server is a large > exaggeration.. > >> Can you please share what kind of >> badly deadlock you saw with large block size support? > > The read-modify write code (which I'll remove later) can lock arbitary > numbers of additional pages from the writeback back code without doing > a trylock, which is required for doing this in page writeback. Note > that it's not a deadlock, but I can also trivіally corrupt data in > those pages as it doesn't lock against them, you just need a race > window where it's modified after writeback has been started for a > large extents, which isn't too hard to hit with tools like fsstress. > Is it bl_find_get_zeroing_page() you are concerning about? I was hoping page flags can tell if some other threads are flushing the same page. And the extra page is always locked before readin or zeroed, after which the page is marked uptodate before unlocking. So the problem is that a page that is being written back gets modified by a new writer, is it correct? How about marking it writeback before unlocking in bl_find_get_zeroing_page()? That should keep new writers from modifying it concurrently. ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
