Searched hist:ff44c6e36dc9dcc02652a1105b120bdf08cea9f7 (Results 1 – 3 of 3) sorted by relevance
/openbmc/linux/fs/btrfs/ |
H A D | extent_map.h | diff ff44c6e36dc9dcc02652a1105b120bdf08cea9f7 Fri Sep 14 11:59:20 CDT 2012 Josef Bacik <jbacik@fusionio.com> Btrfs: do not hold the write_lock on the extent tree while logging
Dave Sterba pointed out a sleeping while atomic bug while doing fsync. This is because I'm an idiot and didn't realize that rwlock's were spin locks, so we've been holding this thing while doing allocations and such which is not good. This patch fixes this by dropping the write lock before we do anything heavy and re-acquire it when it is done. We also need to take a ref on the em's in case their corresponding pages are evicted and mark them as being logged so that releasepage does not remove them and doesn't remove them from our local list. Thanks,
Reported-by: Dave Sterba <dave@jikos.cz> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
|
H A D | extent_map.c | diff ff44c6e36dc9dcc02652a1105b120bdf08cea9f7 Fri Sep 14 11:59:20 CDT 2012 Josef Bacik <jbacik@fusionio.com> Btrfs: do not hold the write_lock on the extent tree while logging
Dave Sterba pointed out a sleeping while atomic bug while doing fsync. This is because I'm an idiot and didn't realize that rwlock's were spin locks, so we've been holding this thing while doing allocations and such which is not good. This patch fixes this by dropping the write lock before we do anything heavy and re-acquire it when it is done. We also need to take a ref on the em's in case their corresponding pages are evicted and mark them as being logged so that releasepage does not remove them and doesn't remove them from our local list. Thanks,
Reported-by: Dave Sterba <dave@jikos.cz> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
|
H A D | tree-log.c | diff ff44c6e36dc9dcc02652a1105b120bdf08cea9f7 Fri Sep 14 11:59:20 CDT 2012 Josef Bacik <jbacik@fusionio.com> Btrfs: do not hold the write_lock on the extent tree while logging
Dave Sterba pointed out a sleeping while atomic bug while doing fsync. This is because I'm an idiot and didn't realize that rwlock's were spin locks, so we've been holding this thing while doing allocations and such which is not good. This patch fixes this by dropping the write lock before we do anything heavy and re-acquire it when it is done. We also need to take a ref on the em's in case their corresponding pages are evicted and mark them as being logged so that releasepage does not remove them and doesn't remove them from our local list. Thanks,
Reported-by: Dave Sterba <dave@jikos.cz> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
|