linux-kernel - Re: The bug of iput() removal from flusher thread?

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:	Mon, 19 Nov 2012 20:41:02 +0100
From:	Jan Kara <jack@...e.cz>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	Al Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: The bug of iput() removal from flusher thread?

On Mon 19-11-12 15:51:40, Jan Kara wrote:
> On Mon 19-11-12 17:56:22, OGAWA Hirofumi wrote:
> > OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> writes:
> > 
> > > Hi,
> > >
> > > In 169ebd90131b2ffca74bb2dbe7eeacd39fb83714 commit, writeback doesn't
> > > __iget()/iput() anymore.
> > >
> > > This means nobody moves the inode to lru list. I.e.
> > >
> > > 	new_inode()
> > > 	dirty_inode()
> > > 	iput_final()
> > > 		/* keep inode without adding lru */
> > > 	flush indoes
> > >         /* clean inode is not on lru */
> > >
> > > I noticed this situation in my FS though, I think the same bug is on all
> > > FSes of linus tree too, after this commit.
> > >
> > > Am I missing the something?
> > 
> > This seems to be reproducible by the following,
> > 
> > #!/bin/sh
> > 
> > for i in $(seq -w 1000); do
> > 	for j in $(seq -w 1000); do
> >         	for k in $(seq -w 1000); do
> >                 	mkdir -p $i/$j
> >                         echo $i/$j/$k > $i/$j/$k
> >                         echo 2 > /proc/sys/vm/drop_caches
> >                 done
> >         done
> > done
> > 
> > Some inodes never be reclaimed, and ls -l frees those inodes (stat(2)
> > does iget/iput).
>   So looking into the code I agree we won't put inode into the LRU when it
> is dirty or under writeback and after writeback is done it won't happen
> either. That's certainly a bug. But I have hard time reproducing your
> results because on my kernels even dcache doesn't get shrunk thus inodes
> are pinned in memory by it. Not sure what's going on yet but I'll
> investigate. Thanks for report!
  OK, that was just reclaim batching code standing in my way. After
figuring that out I could reproduce the issue and test my fix. It is
attached.
								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR

View attachment "0001-writeback-Put-unused-inodes-to-LRU-after-writeback-c.patch" of type "text/x-patch" (2703 bytes)