YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
i think you forgot to add mutex_destroy.
otherwise, while eventually it should be fixed differently,
i think it's ok for now.
Indeed it will also be fixed by requireing LK_EXCLUSIVE on VOP_GETATTR,
but it is a bit more intrusive for a problem
On Fri, Aug 26, 2011 at 08:33:47AM +, YAMAMOTO Takashi wrote:
What happens if vn_lock(vp, LK_EXCLUSIVE|LK_RETRY) is called on a
LK_SHARED locked vnode? I would expect it to sleep until the shared lock
is released.
a recursive locking attempt is an error.
We have no way to upgrade a
On Fri, Aug 26, 2011 at 01:07:43AM +0200, Emmanuel Dreyfus wrote:
[...]
+*/
+ if ((locked = VOP_ISLOCKED(vp)) != LK_EXCLUSIVE)
+ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
You can't use VOP_ISLOCKED this way (it's basically there to be
used in KASSERT()): for ufs, this
On Fri, Aug 26, 2011 at 08:33:47AM +, YAMAMOTO Takashi wrote:
if we go this route, it's cleaner to use a puffs internal lock
I did it that way, and it seems to work fine.
--
Emmanuel Dreyfus
m...@netbsd.org
? sys/fs/puffs/puffs_vnops.c-debug
? sys/fs/puffs/puffs_vnops.c.ok1
?
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
+ rvap-va_size = MAX(rvap-va_size, vp-v_size);
+
couldn't it be a problem if the size of the file is shrinked by the server?
I am back to this simple fix, after the failure of attempts to avoid
uvm_vnp_setsize() calls
Emmanuel Dreyfus m...@netbsd.org wrote:
Keeping MAX(rvap-va_size, vp-v_size) in puffs_vnop_getattr() is simple
but it has a drawback with distributed filesystems: a client will not
notify that an open file was shrunk by another client. I think this is
better than deadlocks and data
Emmanuel Dreyfus m...@netbsd.org wrote:
+ rvap-va_size = MAX(rvap-va_size, vp-v_size);
I am back to this simple fix
Here is an alternative approach that works around the data corruption
bug, it seems much cleaner to me.
It does not address the crash on low memory
hi,
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
+ rvap-va_size = MAX(rvap-va_size, vp-v_size);
+
couldn't it be a problem if the size of the file is shrinked by the server?
I am back to this simple fix, after the failure of attempts to avoid
uvm_vnp_setsize()
hi,
Emmanuel Dreyfus m...@netbsd.org wrote:
+ rvap-va_size = MAX(rvap-va_size, vp-v_size);
I am back to this simple fix
Here is an alternative approach that works around the data corruption
bug, it seems much cleaner to me.
i don't think it fixes the problem as
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
i don't think it fixes the problem as VOPs can release the lock
before the completion of async PUFFS_VN_SETATTR.
It just prevents puffs_vnop_getattr to call uvm_vnp_setattr with a stall
value between the time dosetattr sends PUFFS_VN_SETATTR and
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
ioflush (syncer) is not a kernel thread responsible for freeing memory.
pagedaemon is.
i don't think syncer alone can deadlock with puffs.
Indeed it does not: there is at least a third thread involved. In a
typical case, ioflush sleeps awaiting
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
i don't think it fixes the problem as VOPs can release the lock
before the completion of async PUFFS_VN_SETATTR.
It just prevents puffs_vnop_getattr to call uvm_vnp_setattr with a stall
value between the time dosetattr sends PUFFS_VN_SETATTR
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
ioflush (syncer) is not a kernel thread responsible for freeing memory.
pagedaemon is.
i don't think syncer alone can deadlock with puffs.
Indeed it does not: there is at least a third thread involved. In a
typical case, ioflush sleeps
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
It just prevents puffs_vnop_getattr to call uvm_vnp_setattr with a stall
value between the time dosetattr sends PUFFS_VN_SETATTR and the time it
calls uvm_vnp_setattr. This is enough to work around the issue if the
file server does not
Emmanuel Dreyfus m...@netbsd.org wrote:
That code passes my test case for data corruption, and it does not hang
the kernel.
I spoke too fast, it is still able to deadlock. Here is ioflush
backtrace, while it is sleeping on km_getwait2
sleepq_block
mtsleep
uvm_wait
uvm_km_alloc
Emmanuel Dreyfus m...@netbsd.org wrote:
That code passes my test case for data corruption, and it does not hang
the kernel.
I spoke too fast, it is still able to deadlock.
I identified simple situations where the ioflush thread would enter
puffs_vnop_strategy and fail to request
Emmanuel Dreyfus m...@netbsd.org wrote:
Or just avoid uvm_vnp_setsize() calls?
I wonder is that does not open the door to situation where fsync
semantics gets broken, because of a skiped uvm_vnp_setsize().
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
We would have a PNODE_IN_RESIZE flag for struct pnode's pn_stat, set and
cleared in dosetattr(), and use vp-v_size on uvm_vnp_setsize() calls
when set? Or just avoid uvm_vnp_setsize() calls?
just avoid the calls.
There is a problem if two
Emmanuel Dreyfus m...@netbsd.org wrote:
Or just avoid uvm_vnp_setsize() calls?
I wonder is that does not open the door to situation where fsync
semantics gets broken, because of a skiped uvm_vnp_setsize().
nothing i can think of right now.
do you have a particular idea what semantics
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
do you have a particular idea what semantics might be broken?
Not sure, I am still searching.
Here is a current posible behaviour:
thread1 puffs_vnop_setattr dosetattr size1 SETATTR size1 sent
thread2 puffs_vnop_write uvm_vnp_setsize
hi,
On Fri, Aug 19, 2011 at 01:54:28PM +, Emmanuel Dreyfus wrote:
Here is my complete anlysis of the problem:
(snip)
your analysis seems to make a sense.
And here is a fix in puffs_vnop_getattr(). It was tested on netbsd-5 only so
far since the bug does not appear in -current. My
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
+ rvap-va_size = MAX(rvap-va_size, vp-v_size);
couldn't it be a problem if the size of the file is shrinked by the server?
In that case, ou client will not see the file being shrunk until it
forgets about it and looks it
hi,
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
+ rvap-va_size = MAX(rvap-va_size, vp-v_size);
couldn't it be a problem if the size of the file is shrinked by the server?
In that case, ou client will not see the file being shrunk until it
forgets about it and
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
alternatively, using puffs_msg_setcall, i think you can make GETATTR
reliably know if there's a pending SETATTR or not.
if there's a pending SETATTR, GETATTR can ignore a part of the reply
from the file server and returns the kernel's idea of the
hi,
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
alternatively, using puffs_msg_setcall, i think you can make GETATTR
reliably know if there's a pending SETATTR or not.
if there's a pending SETATTR, GETATTR can ignore a part of the reply
from the file server and returns the kernel's idea
On Fri, Aug 19, 2011 at 01:54:28PM +, Emmanuel Dreyfus wrote:
Here is my complete anlysis of the problem:
(snip)
And here is a fix in puffs_vnop_getattr(). It was tested on netbsd-5 only so
far since the bug does not appear in -current. My test case does not exhibit
the bug anymore on
26 matches
Mail list logo
