Thanks Franks. I merged your patch and now hitting another deadlock. Here
are the two threads:
This thread below holds the partition lock in 'read' mode and try to
acquire queue lock:
Thread 143 (Thread 0x7faf82f72700 (LWP 143573)):
#0 0x7fafd1c371bd in __lll_lock_wait () from /lib64/libpthr
From: Jeff Layton
There are two calls to do_delegation in the current code, but only one
is still "live". The other is commented out.
The live one will only be called if support_ex returns false. That will
result in the ->lock_op being called to request a delegation.
Most non-support_ex FSALs h
And on this end, we were hoping to have delegation support for the
FSAL_PROXY driver (NFS client side). Any thoughts on that?
> On Fri, 2017-05-19 at 11:55 +0530, Soumya Koduri wrote:
>> Hi,
>>
>> On 05/18/2017 08:04 PM, Yun-Chih Chen wrote:
>> > Hi, friends:
>> >
>> > I'm studying the affect of
On Fri, 2017-05-19 at 11:55 +0530, Soumya Koduri wrote:
> Hi,
>
> On 05/18/2017 08:04 PM, Yun-Chih Chen wrote:
> > Hi, friends:
> >
> > I'm studying the affect of NFSv4 on Linux. As far as I know, NFS
> > implemented in Linux kernel supports read delegation but not write
> > delegation. I wonde
Correct.
Matt
On Thu, Aug 3, 2017 at 10:44 AM, Daniel Gryniewicz wrote:
> I do not believe it's reorganizing code. I think the code in the first
> section is wrong, and the second version is needed.
>
> Once you've dec'd the refcount, you cannot access the pointer. At that
> point, another th
I do not believe it's reorganizing code. I think the code in the first
section is wrong, and the second version is needed.
Once you've dec'd the refcount, you cannot access the pointer. At that
point, another thread could deref and free, and you'd be left with freed
memory. You *must* stor
Daniel Gryniewicz wrote on Wed, Aug 02, 2017 at 10:16:39AM -0400:
> fortify sources does not work for me. It fails during cmake. Basic system
> libraries (such as -pthread) do not link.
Hm. There is a "problem", that FORTIFY_SOURCE requires optimizations, so
I had to add -O2... which in turn add
[root@simpson91 nfs4.0]# ./testserver.py 127.0.0.1:/testnfs/test40-v4
--maketree all
Got error: Connection closed
Sleeping for 120 seconds:
Normally, no connection closed. Same results at end, though.
Some runs, says that twice, and then hangs. Have to kill the connection,
^c and ^d do not wo
Hi,
Noticed something weird testing Bill's patch, turns out it's in next
already..
I'm having some weird behavior with nfs (still using 4.1
explicitely, it does not seem to happen with 4.0)
Setup is:
pseudo /
vfs export for /export
I'm mounting the pseudo / on /mnt: mount -t nfs -o vers=4.1 :
It's improperly reorganizing code.
===
Accessing freed memory at ==>
Logically, this couldn't happen!
int free_nfs_request(request_data_t *reqdata)
{
atomic_dec_uint32_t(&reqdata->r_d_refs);
LogDebug(COMPONENT_DISPATCH,
"%s: %p fd %d xp_refs %" PRIu32 " r_d_re
10 matches
Mail list logo
