Hi Dave and list, I hit the following crash with the latest code drop that was pushed in yesterday while running test 177 in a loop, after 4-5 loops it crashed as follows: "<0>general protection faul
.... I think you'll find it's VN_DIRTY() here: 158 /* 159 * If we have to flush data or wait for I/O completion 160 * we need to drop the ilock that we currently hold. 161 * If we need to drop the lo
Might be betters as if (!igrab(inode)) { /* leave it to reclaim */ read_unlock(&pag->pag_ici_lock); continue; } read_unlock(&pag->pag_ici_lock); xfs_ilock(ip, lock_flags); which then also shows that
Dave Chinner wrote: Can you confirm that the xfs_inode has either the I_RECLAIM or I_RECLAIMABLE flag set on it when the panic occurred? If this is the case, then the patch below will probably fix it
Yes, saner and more consistent with other code to do it that way. Here's an updated patch that takes into account all this. it removes a fair chunk of code now.... Cheers, Dave. -- Dave Chinner david
Update below. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx XFS: avoid all reclaimable inodes in xfs_sync_inodes_ag If we are syncing data in xfs_sync_inodes_ag(), the VFS inode must still be ref
Dave Chinner wrote: Update below. Cheers, Dave. The original patch appeared to fix the issue, however the latest one Oops as follows: 177 553s ...BUG: unable to handle kernel NULL pointer dereference
Well, I think the problem dhould be obvious - it's the same as the first report - deferencing the linux inode without first having a refernce on it. FWIW, if you apply the "combine linux/xfs inode" p
Dave Chinner wrote: On Wed, Oct 15, 2008 at 03:50:48PM +1000, Peter Leckie wrote: Dave Chinner wrote: Update below. Cheers, Dave. The original patch appeared to fix the issue, however the latest one
- it's the same as the first report - deferencing the linux inode without first having a refernce on it. Yes it resolves the issue. I spoke to soon, Ooops as follows: <1>BUG: unable to handle kernel
.... Yes, or you could simply apply the "combine linux/XFS inode" patch series and then VFS_I(ip) will never, ever return NULL. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
This would be the correct fix for the current code, but can you please put in the Inode/XFS Inode unification patches? At least I have only QAed the whole patchkit, and from the issues here it seems
Christoph Hellwig wrote: On Thu, Oct 16, 2008 at 12:43:10PM +1000, Peter Leckie wrote: Adding the following resolved the issue however you may wish to solve it in another manner. @@ -102,7 +102,7 @@
Hey Dave I'll push it now, I assume it's ok to go in with out the check for a inode first as the combine linux/XFS inode patch is in. Thanks, Pete Dave Chinner wrote: Ping? Can this patch be applied
Hi Dave and list, I hit the following crash with the latest code drop that was pushed in yesterday while running test 177 in a loop, after 4-5 loops it crashed as follows: "<0>general protection faul
.... I think you'll find it's VN_DIRTY() here: 158 /* 159 * If we have to flush data or wait for I/O completion 160 * we need to drop the ilock that we currently hold. 161 * If we need to drop the lo
Might be betters as if (!igrab(inode)) { /* leave it to reclaim */ read_unlock(&pag->pag_ici_lock); continue; } read_unlock(&pag->pag_ici_lock); xfs_ilock(ip, lock_flags); which then also shows that