Searched hist:"4 f23c764f42ca84426a7a83b037f295c276bff8d" (Results 1 – 2 of 2) sorted by relevance
| /titanic_44/usr/src/uts/common/fs/zfs/ |
| H A D | zfs_dir.c | diff 4f23c764f42ca84426a7a83b037f295c276bff8d Fri Jul 08 15:05:13 CEST 2016 Arne Jansen <jansen@webgods.de> This commit fixes https://www.illumos.org/issues/6779.
Chronology of the events:
1. we have an empty directory
2. the filesystem is nearly out of quota
3. a snapshot prevents any space from being freed
4. a remote clients calls opendir via nfs4
5. the same client removes the directory
6. the client proceeds with readdir --> boom.
During 4, the client obtains a FH for the directory.
During 5, the directory entry gets removed, the inode is added to the
unlinked set and z_unlinked is set.
Then the inode contents is deleted (dmu_free_long_range).
Deletion of the inode itself fails because the fs ran out of space exactly
at this moment. The inode is left in the unlinked set, the znode is freed.
During 6, the readdir of the client instantiates a new znode for the (empty)
inode, this time with z_unlinked unset.
During zap read, the contents of the empty file is interpreted as a fatzap,
which leads to the crash.
This patch addresses the problem twofold:
1. when instantiating a znode, set z_unlinked when z_links == 0
2. mark the deletion of the inode as netfree (in zfs_rmnode).
refs #3026
(cherry picked from commit 67738a4fd5331c5c62b9fead7a7739afa2476cf9)
|
| H A D | zfs_znode.c | diff 4f23c764f42ca84426a7a83b037f295c276bff8d Fri Jul 08 15:05:13 CEST 2016 Arne Jansen <jansen@webgods.de> This commit fixes https://www.illumos.org/issues/6779.
Chronology of the events:
1. we have an empty directory
2. the filesystem is nearly out of quota
3. a snapshot prevents any space from being freed
4. a remote clients calls opendir via nfs4
5. the same client removes the directory
6. the client proceeds with readdir --> boom.
During 4, the client obtains a FH for the directory.
During 5, the directory entry gets removed, the inode is added to the
unlinked set and z_unlinked is set.
Then the inode contents is deleted (dmu_free_long_range).
Deletion of the inode itself fails because the fs ran out of space exactly
at this moment. The inode is left in the unlinked set, the znode is freed.
During 6, the readdir of the client instantiates a new znode for the (empty)
inode, this time with z_unlinked unset.
During zap read, the contents of the empty file is interpreted as a fatzap,
which leads to the crash.
This patch addresses the problem twofold:
1. when instantiating a znode, set z_unlinked when z_links == 0
2. mark the deletion of the inode as netfree (in zfs_rmnode).
refs #3026
(cherry picked from commit 67738a4fd5331c5c62b9fead7a7739afa2476cf9)
|