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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 25 Aug 2015 14:38:00 +0800
From:	Chao Yu <chao2.yu@...sung.com>
To:	Jaegeuk Kim <jaegeuk@...nel.org>
Cc:	linux-f2fs-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: RE: [f2fs-dev] [PATCH 2/2] f2fs: fix to release inode correctly

Hi Jaegeuk,

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk@...nel.org]
> Sent: Tuesday, August 25, 2015 6:53 AM
> To: Chao Yu
> Cc: linux-kernel@...r.kernel.org; linux-f2fs-devel@...ts.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 2/2] f2fs: fix to release inode correctly
> 
> Hi Chao,
> 
> On Mon, Aug 24, 2015 at 09:54:23AM -0700, Jaegeuk Kim wrote:
> > On Mon, Aug 24, 2015 at 05:40:45PM +0800, Chao Yu wrote:
> > > In following call stack, if unfortunately we lose all chances to truncate
> > > inode page in remove_inode_page, eventually we will add the nid allocated
> > > previously into free nid cache, this nid is with NID_NEW status and with
> > > NEW_ADDR in its blkaddr pointer:
> > >
> > >  - f2fs_create
> > >   - f2fs_add_link
> > >    - __f2fs_add_link
> > >     - init_inode_metadata
> > >      - new_inode_page
> > >       - new_node_page
> > >        - set_node_addr(, NEW_ADDR)
> > >      - f2fs_init_acl   failed
> > >      - remove_inode_page  failed
> > >   - handle_failed_inode
> > >    - remove_inode_page  failed
> > >    - iput
> > >     - f2fs_evict_inode
> > >      - remove_inode_page  failed
> > >      - alloc_nid_failed   cache a nid with valid blkaddr: NEW_ADDR
> 
> Unfortunately, this couldn't fix my bug case.

Another thing I note is that: we do not cover free_nid_list_lock with build_lock,
so when we are building free nid cache, we can change the status of free nid
cache, so I guess it is one possible suspect who cause our nid issue.

And, could you share me the information for reproducing the nid reallocation
issue? So I can reproduce in my environment for invistigating.

> I'm still struggling to find out something tho.
> Meanwhile, let's stay with both of the patches.

OK.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ