Branch next
Tag:V2.6-dev.20
NOTE: This merge includes an ntirpc pullup, please update your submodule.
Release Highlights
* ntirpc pullup to fix a leak
* fixes to resolve export refcounting
* gsh_export_removeexport needs to set up an op_ctx
* fix various double free, use after free, memort l
>From Frank Filz :
Frank Filz has uploaded this change for review. (
https://review.gerrithub.io/391022
Change subject: Cleanup export refcounts, especially in DBUS show_exports
..
Cleanup export refcounts, especially in DBUS
>From Frank Filz :
Frank Filz has uploaded this change for review. (
https://review.gerrithub.io/391016
Change subject: Add export refcount debugging
..
Add export refcount debugging
Change-Id: Iefcde64e10119bec1f644894a57f19
>From Frank Filz :
Frank Filz has uploaded this change for review. (
https://review.gerrithub.io/391009
Change subject: Fix release of host_prefix in client_match
..
Fix release of host_prefix in client_match
It was getting u
fsal_export should probably be set anywhere gsh_export is set.
Daniel
On 12/07/2017 07:54 PM, Frank Filz wrote:
Stacked FSALs often depend on op_ctx->fsal_export being set.
We also have lots of FSAL methods that take the fsal_export as a parameter.
I wonder if we would be better off removing
I'm on the opposite end. I'm not in favor of passing op_ctx needlessly
to every function in Ganesha.
Any useful threading system must have some form of TLS.
Daniel
On 12/08/2017 10:13 AM, Matt Benjamin wrote:
I'd like to see this use of TLS as a "hidden parameter" replaced
regardless. It ha
I run NULL semi-regularly. The last time I ran it was a couple of
months ago, so something may have crept in. I'll try again.
That said, the code in that callpath looks correct.
Daniel
On 12/08/2017 05:46 AM, LUCAS Patrice wrote:
Hi,
Does anyone recently test the FSAL_NULL stackable FSAL
I'd like to see this use of TLS as a "hidden parameter" replaced
regardless. It has been a source of bugs, and locks us into a
pthreads execution model I think needlessly.
Matt
On Fri, Dec 8, 2017 at 10:07 AM, Frank Filz wrote:
>> On 12/7/17 7:54 PM, Frank Filz wrote:
>> > Stacked FSALs often d
Frank Filz wrote on Fri, Dec 08, 2017 at 07:07:08AM -0800:
> > Now that we know every single thread local storage access involves a hidden
> > lock/unlock sequence in glibc "magically" invoked by the linker, it would be
> > better to remove as many TLS references as possible!
> >
> > After all, to
> On 12/7/17 7:54 PM, Frank Filz wrote:
> > Stacked FSALs often depend on op_ctx->fsal_export being set.
> >
> > We also have lots of FSAL methods that take the fsal_export as a
> parameter.
> >
> The latter sounds better.
>
> Now that we know every single thread local storage access involves a hi
Hi,
Does anyone recently test the FSAL_NULL stackable FSAL ?
Before using it as example of coding a stackable FSAL, I simply tried to
use FSAL_NULL over FSAL_VFS and I got the following segmentation fault
when running cthon04 basic test7 ('link and rename').
Best regards,
Patrice
Progra
>From Kinglong Mee :
Kinglong Mee has uploaded this change for review. (
https://review.gerrithub.io/390939
Change subject: FSAL_GLUSTER: close fd without setting credentials at
handle_release()
..
FSAL_GLUSTER: close fd with
On 12/7/17 7:54 PM, Frank Filz wrote:
Stacked FSALs often depend on op_ctx->fsal_export being set.
We also have lots of FSAL methods that take the fsal_export as a parameter.
The latter sounds better.
Now that we know every single thread local storage access involves a
hidden lock/unlock sequ
13 matches
Mail list logo
