On Mon, 2012-03-19 at 14:40 +0100, Jan Zelený wrote:
> > On Mon, 2012-03-19 at 10:21 +0100, Jan Zelený wrote:
> > > > > responder/nss/nsssrv_mmap_cache.c:220
> > > > > - this condition is unnecessarry because of the condition on line 208
> > > >
> > > > Can you post the actual code snippest, if I
> On Mon, 2012-03-19 at 10:21 +0100, Jan Zelený wrote:
> > > > responder/nss/nsssrv_mmap_cache.c:220
> > > > - this condition is unnecessarry because of the condition on line 208
> > >
> > > Can you post the actual code snippest, if I understand what you mean I
> > > think I have line numbers off
On Mon, 2012-03-19 at 10:21 +0100, Jan Zelený wrote:
> > > responder/nss/nsssrv_mmap_cache.c:220
> > > - this condition is unnecessarry because of the condition on line 208
> >
> > Can you post the actual code snippest, if I understand what you mean I
> > think I have line numbers off by 1 ... but
> On Fri, 2012-03-16 at 14:25 +0100, Jan Zelený wrote:
> > > On Thu, 2012-01-12 at 11:49 -0500, Simo Sorce wrote:
> > > > On Tue, 2012-01-10 at 14:33 -0500, Simo Sorce wrote:
> > > > > On Tue, 2012-01-10 at 10:15 -0500, Simo Sorce wrote:
> > > > > > > Sure, we can talk about it. I'm looking at it f
> On Thu, 2012-01-12 at 11:49 -0500, Simo Sorce wrote:
> > On Tue, 2012-01-10 at 14:33 -0500, Simo Sorce wrote:
> > > On Tue, 2012-01-10 at 10:15 -0500, Simo Sorce wrote:
> > > > > Sure, we can talk about it. I'm looking at it from the users'
> > > > > perspectives, who I think would generally expe
On Tue, 2012-01-10 at 14:33 -0500, Simo Sorce wrote:
> On Tue, 2012-01-10 at 10:15 -0500, Simo Sorce wrote:
> > > Sure, we can talk about it. I'm looking at it from the users'
> > > perspectives, who I think would generally expect (and be alright
> > with)
> > > the fast cache being emptied on serv
On Tue, 2012-01-10 at 12:56 -0500, Dmitri Pal wrote:
> On 01/10/2012 11:26 AM, Simo Sorce wrote:
> > On Tue, 2012-01-10 at 10:59 -0500, Dmitri Pal wrote:
> >
> >> As there any SELinux implication with this feature?
> > I guess you mean the whole work not the email you quoted.
>
> Yes. Sorry. It ju
On 01/10/2012 11:26 AM, Simo Sorce wrote:
> On Tue, 2012-01-10 at 10:59 -0500, Dmitri Pal wrote:
>
>> As there any SELinux implication with this feature?
> I guess you mean the whole work not the email you quoted.
Yes. Sorry. It just occurred to me as I looked that email and I did not
have time to
On Tue, 2012-01-10 at 10:59 -0500, Dmitri Pal wrote:
> As there any SELinux implication with this feature?
I guess you mean the whole work not the email you quoted.
In that case the answer is yes, clients must be allowed to access the
files we create, but that is similar to the requirement to all
On 01/10/2012 10:17 AM, Simo Sorce wrote:
> On Tue, 2012-01-10 at 10:49 +0100, Jan Zelený wrote:
>
>> I also have one cosmetic proposal for patch #0009:
>>
>> 1) On line 452 use MC_ALIGN64 instead of (n_elem + 7) & (~7)
> The reason I did not use MC_ALIGN64 is that I thought it would be
> confusing
On Tue, 2012-01-10 at 10:49 +0100, Jan Zelený wrote:
> I also have one cosmetic proposal for patch #0009:
>
> 1) On line 452 use MC_ALIGN64 instead of (n_elem + 7) & (~7)
The reason I did not use MC_ALIGN64 is that I thought it would be
confusing as n_elem is not a pointer but a counter.
I'll ch
On Mon, 2012-01-09 at 20:29 -0500, Stephen Gallagher wrote:
> On Mon, 2012-01-09 at 18:24 -0500, Simo Sorce wrote:
> > Not sure what race condition is there.
> >
> > sssd_nss is the only thing that can create/manipulate that file, in what
> > case do you see a race condition ?
> >
>
> If filesy
> On Mon, 2012-01-09 at 18:24 -0500, Simo Sorce wrote:
> > On Mon, 2012-01-09 at 16:30 -0500, Stephen Gallagher wrote:
> > > On Tue, 2012-01-03 at 18:00 -0500, Simo Sorce wrote:
> > > > >From [PATCH 0/0] A shared memory cache to perform better:
> > > > 0/4: Actual memory cache implementation
> > >
On Mon, 2012-01-09 at 18:24 -0500, Simo Sorce wrote:
> On Mon, 2012-01-09 at 16:30 -0500, Stephen Gallagher wrote:
> > On Tue, 2012-01-03 at 18:00 -0500, Simo Sorce wrote:
> > > >From [PATCH 0/0] A shared memory cache to perform better:
> > >
> > > 0/4: Actual memory cache implementation
> > > The
On Mon, 2012-01-09 at 18:24 -0500, Simo Sorce wrote:
> > I will review the other patches tomorrow.
>
> Thanks!
Oh btw I just found a bug in the client libs that would cause
libnss_sss.so to reopen the fast cache file at every operation until it
ran out of file descriptors, oops :-)
New patch at
On Mon, 2012-01-09 at 16:30 -0500, Stephen Gallagher wrote:
> On Tue, 2012-01-03 at 18:00 -0500, Simo Sorce wrote:
> > >From [PATCH 0/0] A shared memory cache to perform better:
> >
> > 0/4: Actual memory cache implementation
> > These is the bulk of the work, these patches are still a bit rough a
On Tue, 2012-01-03 at 18:00 -0500, Simo Sorce wrote:
> >From [PATCH 0/0] A shared memory cache to perform better:
>
> 0/4: Actual memory cache implementation
> These is the bulk of the work, these patches are still a bit rough at
> the edges, grep for FIXMEs and TODOs and you'll see some plumbing
17 matches
Mail list logo
