linux-kernel - Re: [PATCH] xfs: call xfs_idestroy_fork() in xfs

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:	Wed, 22 Apr 2015 16:28:38 -0400
From:	Waiman Long <waiman.long@...com>
To:	Brian Foster <bfoster@...hat.com>
CC:	Dave Chinner <david@...morbit.com>, xfs@....sgi.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] xfs: call xfs_idestroy_fork() in xfs_ilock() critical
 section

On 04/22/2015 03:11 PM, Brian Foster wrote:
> On Wed, Apr 22, 2015 at 01:33:41PM -0400, Waiman Long wrote:
>> The commit f7be2d7f594cbc ("xfs: push down inactive transaction
>> mgmt for truncate") refactored the xfs_inactive() function
>> in fs/xfs/xfs_inode.c.  However, it also moved the call to
>> xfs_idestroy_fork() from inside the xfs_ilock() critical section to
>> outside. That was causing memory corruption and strange failures like
>> deferencing NULL pointers in some circumstances.
>>
>> This patch moves the xfs_idestroy_fork() call back into an xfs_ilock()
>> critical section to avoid memory corruption problem.
>>
>> Signed-off-by: Waiman Long<Waiman.Long@...com>
>> ---
> Interesting... so from your previous mail we have an inactive/reclaim
> racing with an xfs_iflush_fork() of the attr fork, or something of that
> nature? Is there a specific reproducer or is it some kind of stress
> test?
>
> Good catch in any case, it looks like a deviation from the previous
> code...

I am not sure what kind of races are going on. I was running the AIM7 
workload for performance comparison purpose. I hit the error when 
running the disk workload with xfs filesystem. The smaller the ramdisk 
that I used, the easier it was to reproduce the error. I think I haven't 
run it for quite a while so I did not notice any problem or I might have 
just ignored it in some previous runs.

I did check some other call sites of xfs_idestroy_fork() and they are 
under xfs_ilock(). So I suppose it is not safe to call it outside of the 
critical section. This patch did indeed fix the problem that I saw when 
running the disk workload.

Cheers,
Longman


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