> But...suppose we have two racing OPEN calls. They're both in
> nfs4_get_vfs_file. One opens the file and succeeds and the other fails
> and ends up in out_put_access. At that point, you could end up
> clobbering the successful update to st_access_bmap from the other task,
> and we'd end up not
> But...suppose we have two racing OPEN calls. They're both in
> nfs4_get_vfs_file. One opens the file and succeeds and the other fails
> and ends up in out_put_access. At that point, you could end up
> clobbering the successful update to st_access_bmap from the other task,
> and we'd end up not
On Jun 8, 2016, at 1:22 PM, Jeff Layton wrote:
> On Wed, 2016-06-08 at 12:10 -0400, Oleg Drokin wrote:
>> On Jun 8, 2016, at 6:58 AM, Jeff Layton wrote:
>>
>>> A simple way to confirm that might be to convert all of the read locks
>>> on the st_rwsem to write locks. That will serialize all of
On Jun 8, 2016, at 1:22 PM, Jeff Layton wrote:
> On Wed, 2016-06-08 at 12:10 -0400, Oleg Drokin wrote:
>> On Jun 8, 2016, at 6:58 AM, Jeff Layton wrote:
>>
>>> A simple way to confirm that might be to convert all of the read locks
>>> on the st_rwsem to write locks. That will serialize all of
On Wed, 2016-06-08 at 12:10 -0400, Oleg Drokin wrote:
> On Jun 8, 2016, at 6:58 AM, Jeff Layton wrote:
>
> > A simple way to confirm that might be to convert all of the read locks
> > on the st_rwsem to write locks. That will serialize all of the open
> > operations and should prevent that
On Wed, 2016-06-08 at 12:10 -0400, Oleg Drokin wrote:
> On Jun 8, 2016, at 6:58 AM, Jeff Layton wrote:
>
> > A simple way to confirm that might be to convert all of the read locks
> > on the st_rwsem to write locks. That will serialize all of the open
> > operations and should prevent that
On Jun 8, 2016, at 6:58 AM, Jeff Layton wrote:
> A simple way to confirm that might be to convert all of the read locks
> on the st_rwsem to write locks. That will serialize all of the open
> operations and should prevent that particular race from occurring.
>
> If that works, we'd probably
On Jun 8, 2016, at 6:58 AM, Jeff Layton wrote:
> A simple way to confirm that might be to convert all of the read locks
> on the st_rwsem to write locks. That will serialize all of the open
> operations and should prevent that particular race from occurring.
>
> If that works, we'd probably
On Jun 8, 2016, at 6:58 AM, Jeff Layton wrote:
> On Tue, 2016-06-07 at 22:22 -0400, Oleg Drokin wrote:
>> On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
>>
> That said, this code is quite subtle. I'd need to look over it in more
> detail before I offer up any fixes. I'd also appreciate
On Jun 8, 2016, at 6:58 AM, Jeff Layton wrote:
> On Tue, 2016-06-07 at 22:22 -0400, Oleg Drokin wrote:
>> On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
>>
> That said, this code is quite subtle. I'd need to look over it in more
> detail before I offer up any fixes. I'd also appreciate
On Tue, 2016-06-07 at 22:22 -0400, Oleg Drokin wrote:
> On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
>
> > > > That said, this code is quite subtle. I'd need to look over it in more
> > > > detail before I offer up any fixes. I'd also appreciate it if anyone
> > > > else wants to sanity check
On Tue, 2016-06-07 at 22:22 -0400, Oleg Drokin wrote:
> On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
>
> > > > That said, this code is quite subtle. I'd need to look over it in more
> > > > detail before I offer up any fixes. I'd also appreciate it if anyone
> > > > else wants to sanity check
On Jun 7, 2016, at 10:22 PM, Oleg Drokin wrote:
>
> On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
>
That said, this code is quite subtle. I'd need to look over it in more
detail before I offer up any fixes. I'd also appreciate it if anyone
else wants to sanity check my analysis
On Jun 7, 2016, at 10:22 PM, Oleg Drokin wrote:
>
> On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
>
That said, this code is quite subtle. I'd need to look over it in more
detail before I offer up any fixes. I'd also appreciate it if anyone
else wants to sanity check my analysis
On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
>>> That said, this code is quite subtle. I'd need to look over it in more
>>> detail before I offer up any fixes. I'd also appreciate it if anyone
>>> else wants to sanity check my analysis there.
>>>
> Yeah, I think you're right. It's fine since
On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
>>> That said, this code is quite subtle. I'd need to look over it in more
>>> detail before I offer up any fixes. I'd also appreciate it if anyone
>>> else wants to sanity check my analysis there.
>>>
> Yeah, I think you're right. It's fine since
On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
> On Tue, 2016-06-07 at 19:39 -0400, Oleg Drokin wrote:
>> On Jun 7, 2016, at 4:04 PM, Jeff Layton wrote:
>>> So, the way this is supposed to work is that the stateids each hold a
>>> reference to the nfs4_file. They also take an fi_access reference
On Jun 7, 2016, at 8:03 PM, Jeff Layton wrote:
> On Tue, 2016-06-07 at 19:39 -0400, Oleg Drokin wrote:
>> On Jun 7, 2016, at 4:04 PM, Jeff Layton wrote:
>>> So, the way this is supposed to work is that the stateids each hold a
>>> reference to the nfs4_file. They also take an fi_access reference
On Tue, 2016-06-07 at 19:39 -0400, Oleg Drokin wrote:
> On Jun 7, 2016, at 4:04 PM, Jeff Layton wrote:
>
> >
> > On Tue, 2016-06-07 at 13:30 -0400, Oleg Drokin wrote:
> > >
> > > On Jun 7, 2016, at 1:10 PM, Jeff Layton wrote:
> > >
> > > >
> > > >
> > > > On Tue, 2016-06-07 at 11:37 -0400,
On Tue, 2016-06-07 at 19:39 -0400, Oleg Drokin wrote:
> On Jun 7, 2016, at 4:04 PM, Jeff Layton wrote:
>
> >
> > On Tue, 2016-06-07 at 13:30 -0400, Oleg Drokin wrote:
> > >
> > > On Jun 7, 2016, at 1:10 PM, Jeff Layton wrote:
> > >
> > > >
> > > >
> > > > On Tue, 2016-06-07 at 11:37 -0400,
On Jun 7, 2016, at 4:04 PM, Jeff Layton wrote:
> On Tue, 2016-06-07 at 13:30 -0400, Oleg Drokin wrote:
>> On Jun 7, 2016, at 1:10 PM, Jeff Layton wrote:
>>
>>>
>>> On Tue, 2016-06-07 at 11:37 -0400, Oleg Drokin wrote:
Hello!
I've been trying to better understand this
On Jun 7, 2016, at 4:04 PM, Jeff Layton wrote:
> On Tue, 2016-06-07 at 13:30 -0400, Oleg Drokin wrote:
>> On Jun 7, 2016, at 1:10 PM, Jeff Layton wrote:
>>
>>>
>>> On Tue, 2016-06-07 at 11:37 -0400, Oleg Drokin wrote:
Hello!
I've been trying to better understand this
On Tue, 2016-06-07 at 13:30 -0400, Oleg Drokin wrote:
> On Jun 7, 2016, at 1:10 PM, Jeff Layton wrote:
>
> >
> > On Tue, 2016-06-07 at 11:37 -0400, Oleg Drokin wrote:
> > >
> > > Hello!
> > >
> > > I've been trying to better understand this problem I was having where
> > > sometimes
> > >
On Tue, 2016-06-07 at 13:30 -0400, Oleg Drokin wrote:
> On Jun 7, 2016, at 1:10 PM, Jeff Layton wrote:
>
> >
> > On Tue, 2016-06-07 at 11:37 -0400, Oleg Drokin wrote:
> > >
> > > Hello!
> > >
> > > I've been trying to better understand this problem I was having where
> > > sometimes
> > >
On Jun 7, 2016, at 1:10 PM, Jeff Layton wrote:
> On Tue, 2016-06-07 at 11:37 -0400, Oleg Drokin wrote:
>> Hello!
>>
>>I've been trying to better understand this problem I was having where
>> sometimes
>>a formerly NFS-exported mountpoint becomes unmountable (after nfsd stop).
>>
>>
On Jun 7, 2016, at 1:10 PM, Jeff Layton wrote:
> On Tue, 2016-06-07 at 11:37 -0400, Oleg Drokin wrote:
>> Hello!
>>
>>I've been trying to better understand this problem I was having where
>> sometimes
>>a formerly NFS-exported mountpoint becomes unmountable (after nfsd stop).
>>
>>
On Tue, 2016-06-07 at 11:37 -0400, Oleg Drokin wrote:
> Hello!
>
> I've been trying to better understand this problem I was having where
> sometimes
> a formerly NFS-exported mountpoint becomes unmountable (after nfsd stop).
>
> I finally traced it to a leaked filedescriptor that was
On Tue, 2016-06-07 at 11:37 -0400, Oleg Drokin wrote:
> Hello!
>
> I've been trying to better understand this problem I was having where
> sometimes
> a formerly NFS-exported mountpoint becomes unmountable (after nfsd stop).
>
> I finally traced it to a leaked filedescriptor that was
Hello!
I've been trying to better understand this problem I was having where
sometimes
a formerly NFS-exported mountpoint becomes unmountable (after nfsd stop).
I finally traced it to a leaked filedescriptor that was allocated from
Hello!
I've been trying to better understand this problem I was having where
sometimes
a formerly NFS-exported mountpoint becomes unmountable (after nfsd stop).
I finally traced it to a leaked filedescriptor that was allocated from
30 matches
Mail list logo
