[04:51:44] --- Jeffrey Altman has left: Disconnected
[04:55:18] --- Jeffrey Altman has become available
[05:29:56] --- meffie has become available
[06:08:11] --- Marc Dionne has become available
[06:30:33] --- deason has become available
[06:35:35] --- wiesand has become available
[06:36:21] <wiesand> test
[06:44:25] <wiesand> Hi Marc! Could I bother you to look at gerrit 10596?
[06:45:25] <Marc Dionne> Hi Stephan - sure
[06:47:52] <Marc Dionne> the text looks ok to me at first reading
[06:50:03] <wiesand> Thanks.
[06:52:20] <Marc Dionne> but I assume that's something you won't merge until we get close to the final 1.6.6 release
[06:53:25] <wiesand> Why not? I think it's not bad to have current release notes with the prereleases.
[06:55:38] <Marc Dionne> that's fine, but if you're merging updates for each pre-release, might be interesting to be more specific about that in the commit title and message ?
[06:56:51] --- squinney has become available
[06:58:02] <wiesand> better?
[06:58:57] <Marc Dionne> yes, thanks
[07:00:10] <wiesand> Any news regarding Linux 3.13? (I think rc4 is current?)
[07:00:39] <Marc Dionne> i knew you'd ask that.. ;)  Just tested 1.6 head this morning on current rc4+, works fine
[07:01:09] <wiesand> Great, thanks.
[07:01:46] <wiesand> I should have a RHEL7 beta test system soon.
[07:03:07] <Marc Dionne> yeah it would be good to have people testing with rhel7.  as 6.5 has shown, hard to predict what they do with their kernels..
[07:04:12] <Marc Dionne> i have a bit more info about that other problem seen on 6.5, if you want to hear that now
[07:04:25] <wiesand> Right. I also remember the IMA issue in early RHEL6 beta...
[07:05:59] <wiesand> We're not exactly a crowd today... and Jeffrey can't actually be here - he's travelling ;-)
[07:06:59] <wiesand> Anyway, any ideas what went wrong in https://lists.openafs.org/pipermail/openafs-info/2013-December/040327.html ?
[07:09:02] <wiesand> Taking that as a "no".
[07:09:10] <Marc Dionne> no - but it's not clear exactly what he's running and if it's a sane configuration
[07:09:53] <deason> (sorry, not paying attention here, in a meeting)
[07:10:54] <wiesand> My client doesn't even show your presence... just Marc. Jeffrey and Stephen.
[07:11:01] <wiesand> Is anyone else actually here?
[07:11:13] <meffie> yes
[07:11:24] <Marc Dionne> i see Andrew and also Ben in the list
[07:11:49] <wiesand> Ah. Does anyone see Derrick?
[07:11:59] <meffie> i see 3 shadow's
[07:12:25] <wiesand> Good, thanks.
[07:12:51] <meffie> (looks like 3 different barnowl's)
[07:12:58] <wiesand> So let's talk about pre2. I'd really like to get it out this week.
[07:13:05] <wiesand> And if possible, today.
[07:13:35] <Marc Dionne> 10578 needs merging
[07:13:35] <meffie> ok
[07:14:27] <wiesand> Yes, 10578, and 10541/2/3/8/9.
[07:14:50] <wiesand> And 10344 and 10596.
[07:15:31] <wiesand> Quite a few of those had no review at all, though I tried to poke, and it wasn't yesterday.
[07:16:19] --- shadow@gmail.com/barnowlECEA8F00 has become available
[07:16:24] <shadow@gmail.com/barnowlECEA8F00> this time?
[07:16:28] <deason> okay, I'm "here" now :)
[07:16:43] <wiesand> Welcome Derrick and Andrew :)
[07:17:18] <shadow@gmail.com/barnowlECEA8F00> i get messages 4 times now. i was trying to figure out how to make
myself unjoin 4 times but none of the tricks worked. i dunno
[07:17:26] <deason> 10548 still has an unresolved question I'd like to hear someone provide some kind of answer for
[07:19:20] <wiesand> I'm not really an expert here - but I think while compiler may ignore "inline" it's not allowed to ignore "static"?
[07:19:57] <deason> yes
[07:20:15] <shadow@gmail.com/barnowlECEA8F00> 10548: will what work? it's... just inlining what the macro was. will
the underlying code which was already there work? i was dubious but it
was the same a couple places in xnu, so i figured i'd play along
[07:20:34] <deason> no, see
[07:20:53] <deason> the macro will definitely not have this problem, since it will expand to kauth_whatever(&avc->foo)
[07:21:11] <Marc Dionne> does look a bit fishy to me..
[07:21:20] <deason> but if you pass avc->foo to our function, and in that function it does kauth_whatever(&argument), the adress-of the argument isn't necessarily thr same as the address-of the thing you passed in
[07:21:41] <deason> even if it's not called as a regular function, I don't think the semantics guarantee that the address-of is the same
[07:21:56] <deason> but I don't know why it needs the address-of, so I don't know if that really matters
[07:22:27] <deason> imo, it's os x, so it's your monkeys
[07:22:31] <shadow@gmail.com/barnowlECEA8F00> oh. sorry, i misunderstood what you were getting at
[07:23:42] <deason> (that is, in that function impl, &X could be a stack-allocated address, at least in theory)
[07:24:00] <wiesand> Right, it's darwin only, and there it's needed (or some replacement).
[07:24:07] <shadow@gmail.com/barnowlECEA8F00> the code in question only comes into play when we're storing a core
into afs (the CCore case in StoreOnLastReference) so it's unlikely to
even come into play on macos
[07:24:22] <shadow@gmail.com/barnowlECEA8F00> that is, this code path has probably been exerised never
[07:24:35] <deason> well, the alternative is to fix the macro
[07:24:46] <deason> it comes into play never? we never store cores into /afs on o s x?
[07:24:50] <deason> er, os x
[07:24:55] <shadow@gmail.com/barnowlECEA8F00> (remember macos generally either does not leave a core, or if it does,
typically uses /cores)
[07:25:27] <shadow@gmail.com/barnowlECEA8F00> the os helpfully tries to deal with cores for you, leaving either
*only* a crash report for you, or storing the cores "aside"
[07:25:59] <deason> so I presume they go directly to /cores; not into cwd and then copied out or something
[07:26:08] <deason> and "typically" or "always"?
[07:26:19] <shadow@gmail.com/barnowlECEA8F00> well, typically you just don't get a core
[07:27:32] <wiesand> merged 10543
[07:27:50] <shadow@gmail.com/barnowlECEA8F00> but istr you have to actively take an action (configure the OS in a
way not exposed to the user) to get cores not in /cores; and if /cores
doesn't exist, a reporting process gets the core via mach ipc,
analyses, and discards it. 
[07:28:00] <deason> okay, well, it's up to you, I've said what I wanted to say
[07:28:04] <shadow@gmail.com/barnowlECEA8F00> mind, i last looked at that a while ago but there is no indication
it's changed
[07:28:29] <shadow@gmail.com/barnowlECEA8F00> i'd say merge it so we can build for now, and drop something in RT so
we do something more sensible with it at some point
[07:29:13] <deason> well, I could try to submit something else that would build if you want
[07:30:03] <shadow@gmail.com/barnowlECEA8F00> if you want to go ahead; i'd still suggest we merge this and take
whatever else for the next pre or for final (since it's one platform
only it will be easy to test)
[07:30:22] <shadow@gmail.com/barnowlECEA8F00> and that way stephan can have his pre now and we don't need to worry
about testing, and it will work with whatever clang you have
[07:30:35] <shadow@gmail.com/barnowlECEA8F00> (fsvo "you")
[07:30:42] <deason> or just not worry for this release and just fix it for "the future"
[07:31:06] <wiesand> You mean not merge it for 1.6.6?
[07:31:14] <deason> well, don't block for it
[07:31:19] <wiesand> Ken said it's required.
[07:31:21] <deason> er, that is
[07:31:25] <deason> I mean, don't block for the "other fix"
[07:31:28] <deason> merge this one for now
[07:31:34] <wiesand> Ok.
[07:32:36] <wiesand> merged 10548
[07:33:13] <wiesand> 10549 is DARWIN only too.
[07:33:39] <shadow@gmail.com/barnowlECEA8F00> it's required or at least there is no guarantee you can get a version
of clang for which it is not required
[07:34:25] <deason> I +1'd it just because it's moving an include around, so if it breaks, it should break during build :)
[07:34:34] <wiesand> merged 10549
[07:35:29] <wiesand> Any objections to 10541/2?
[07:36:34] <wiesand> merged 10541
[07:37:00] <wiesand> merged 10542
[07:37:31] <meffie> ok
[07:37:51] <wiesand> merged 10578
[07:38:12] <deason> not quite :)
[07:38:21] <wiesand> no ;-)
[07:38:31] <meffie> oh.
[07:38:48] <deason> you're re-pushing, I assume?
[07:39:06] <wiesand> Who?
[07:39:14] <deason> you, wiesand
[07:39:30] <wiesand> Ok, working
[07:39:39] <deason> oh, if you're not, I can, or marc or whatnot
[07:40:15] <Marc Dionne> yup, just needs to be clear so we don't step on each other's toes
[07:41:33] <wiesand> repushed
[07:42:32] <wiesand> merged 10596
[07:43:33] <deason> er, were we waiting for 10594?
[07:43:53] <deason> oh, that was merged
[07:44:04] <wiesand> Yes, but on master.
[07:44:43] <wiesand> 10594 isn't exactly about a new problem.
[07:45:03] <wiesand> We've had to build policy modules for this since EL5.
[07:46:03] <wiesand> I'd leave this for pre3 or 1.6.7 - unless you want to press for it?
[07:46:20] <deason> I was worried about places that may not realize they are hitting it
[07:46:36] <meffie> yeah it is annoying and not obvious.
[07:46:48] <deason> well, it's pretty small... (if others agree it is small)
[07:47:43] <deason> and well, the problem is new to me; I hadn't heard any reports about this before last week :)
[07:47:59] <Marc Dionne> btw i can't see a mainline kernel where sock_create has 5 arguments - i'm guessing it was a redhatism that was merged as sock_create_kern instead
[07:48:44] <meffie> since the manifestation is "afs is slow" it's not obvious what is going on.
[07:49:13] <wiesand> There's an avc: denied message.
[07:49:42] <Marc Dionne> but not everyone probably watches those carefully
[07:49:49] <deason> in the case where this manifested last week, it didn't result in audit messages
[07:49:55] <deason> unless you disable the "dontaudit" rules
[07:50:20] <meffie> yep
[07:50:25] <deason> but that has perhaps changed over time
[07:50:54] <wiesand> Maybe. The problem has existed since ~forever.
[07:51:32] <meffie> must be on of those annoyances that existing sites have learned to cope with.
[07:52:18] <wiesand> It's not that terrible. It's just the first access that's delayed by a couple of seconds. Then it's ok for a while.
[07:52:29] <deason> yeah, but I think rhel defaulting to selinux enforcing I think is new
[07:52:37] <deason> and/or more stuff is covered under the default 'targeted' policy
[07:53:00] <deason> well, that may depend on the case; in the manifestation we saw, it was impacting all the time; it's just whenever you hit non-cached stuff
[07:53:00] <meffie> good points.
[07:53:09] <deason> but I said I wouldn't push for it, so I'll shut up
[07:54:07] <wiesand> I don't see +1s yet. And I assume that waiting for those will delay pre2 until January.
[07:54:58] <wiesand> NB I think it will have to be rebased
[07:55:28] <wiesand> unless I merge it before 10578 and rebase that again...
[07:56:10] <wiesand> acinclude.m4 is a real bottleneck in that respect
[07:56:25] <deason> well, that was the idea, that this would be small enough that we could get agreement during this meeting, and not have to delay pre2
[07:56:37] <deason> if that doesn't happen, then just leave it out for now
[07:56:39] <Marc Dionne> seems fairly low risk, but it does use a different code path within the kernel, so i might be more comfortable if this had been exercised more
[07:57:18] <wiesand> If we can get agreement, fine. But I think Marc has a valid point.
[07:58:18] <deason> okay, that's fine
[07:58:29] <shadow@gmail.com/barnowlECEA8F00> yeah. i'm slightly nervous. it won't get much play in this pre
[07:58:40] <deason> (well, I would say that having it in the pre is how you get it exercised... :)
[07:59:17] <wiesand> I'm also slightly afraid of opening another can of worms with all those patched vendor kernels out there.
[08:01:58] <wiesand> merged 10578
[08:03:49] <wiesand> Ok, I'd really like to wait with 10598. Sorry.
[08:04:23] <deason> yeah, that's fine
[08:04:39] <deason> anything else? there are the couple whitspace/comment-change ones
[08:04:59] <wiesand> They''re trivial but not important.
[08:05:10] <deason> 10597, 10544, maybe 10473?
[08:05:39] <wiesand> The last one we really need is 10344.
[08:05:59] <deason> well, if they get merged, the list gets to be smaller :)
[08:06:52] <wiesand> merged 10544
[08:07:12] <Marc Dionne> there is the issue with rh 6.5 and McAfee, for shich we found a workaround, and i'm wondering if it might be worth adding something in the release notes/news
[08:09:34] <Marc Dionne> it's only 1 case (so it might not even be a general problem), but this user had to disable anti-virus scanning on the disk cache, otherwise the selinux(enforcing)+McAfee+6.5 kernel gives access denied opening cache files
[08:09:38] <wiesand> Well, it's not due to a change in openafs, is it?
[08:10:33] <wiesand> The workaround is disabling anti-virus on the cache?
[08:10:37] <Marc Dionne> no, but if there's a configuration change users can do to avoid openafs being non functional in some config, it might be useful to document
[08:10:46] <Marc Dionne> yes
[08:11:09] <Marc Dionne> (no to the first question about not being due to a change in openafs)
[08:11:26] <wiesand> Is it new with the RHEL 6.5 kernel?
[08:12:09] <Marc Dionne> yes, apparently before 6.5 everything was ok
[08:13:02] <wiesand> Ok, I can fit that in with the existing bullet for that kernel.
[08:14:14] <wiesand> But would rather not have another NEWS change right now.
[08:14:19] <wiesand> I can also mention it in the announcement.
[08:14:25] <Marc Dionne> i would just word it very conditionally - for instance it may only affect certain version of McAfee, etc..
[08:15:06] <meffie> sounds like something that should be posted on openafs-info?
[08:15:31] <wiesand> Right.
[08:15:43] <Marc Dionne> maybe not worth mentioning unless someone else sees it - the combination might not be very common
[08:15:57] <deason> would there ever be a way to get around it? can we dentry_open with "kernel" creds instead of just saving the startup creds?
[08:16:53] <Marc Dionne> sounds more like a bug than something we would need (or be able to) work around in our code
[08:17:52] <Marc Dionne> for instance the problem does not occur if selinux is permissive, but there's no avc logged
[08:18:01] <deason> just wondering
[08:19:05] <deason> that sounds exactly like the sock_create_kern thing we just saw last week; where we needed to 'semodule -DB' to see the AVCs
[08:19:43] <deason> but sorry sorry, getting off-topic
[08:19:45] <Marc Dionne> maybe - although he did see the denials from the second dentry_open that's done when the first one fails
[08:22:35] <wiesand> merged 10344, building tarballs...
[08:27:31] <wiesand> uploading
[08:27:51] --- meffie has left
[08:29:16] <wiesand> Marc, the RELNOTES going up there have a paragraph about the antivirus problem.
[08:29:55] <wiesand> upload complete
[08:30:59] <wiesand> Let's wait with the tag until we had some smoke tests?
[08:32:00] <wiesand> But building could start.
[08:34:01] --- Jeffrey Altman has left: Disconnected
[08:34:28] <wiesand> Ok, I'll write the minutes, smoke test the tarballs, and then start working on 1.6.5.2.
[08:34:40] <wiesand> Anything else for today?
[08:36:23] <wiesand> Andrew: could you get some details to me regarding the SELinux problem you encountered? I'd like to check it's really the same problem that has existed for years.
[08:38:01] <deason> as in, how to reproduce it? or just what it looked like when we saw it?
[08:38:11] --- squinney has left
[08:38:36] <wiesand> Both would be useful.
[08:40:06] <deason> well, as mentioned in the commit message, you see accesses be "slow", and the resends and 'sendFailed' counters go up; I don't think there are many things that can cause the sendFailed counter to increase
[08:40:06] --- Jeffrey Altman has become available
[08:40:36] <deason> an easy way to reproduce it in the targeted policy is to mark a user login to be associated with guest_r under
[08:40:47] <deason> and then just have them try to access uncached items
[08:41:10] <wiesand> Ok, will try that.
[08:41:13] <deason> (er, I'm not sure what that trailing "under" was supposed to be for)
[08:41:54] <wiesand> I guess this was the last meeting this year :)
[08:42:24] <Marc Dionne> yeah next week we'll all be doing something else... :)
[08:43:10] <wiesand> I'll probably hanging out here anyway, but wouldn't expect many of you to ;-)
[08:44:01] <wiesand> So, thanks a lot for all your help today and throughout the year! Happy holidays!
[08:44:38] <wiesand> Bye.
[08:44:49] --- wiesand has left
[08:48:49] --- Marc Dionne has left
[14:03:07] --- Jeffrey Altman has left: Replaced by new connection
[14:03:08] --- Jeffrey Altman has become available
[16:22:52] --- deason has left