Home
release-team@conference.openafs.org
Friday, December 11, 2020< ^ >
yadayada has set the subject to: openafs release team
Room Configuration
Room Occupants

GMT+0
[12:25:16] mbarbosa joins the room
[12:44:16] mbarbosa leaves the room
[12:52:24] mbarbosa joins the room
[16:43:49] meffie joins the room
[16:51:23] kaduk@jabber.openafs.org/barnowl joins the room
[16:57:14] yadayada joins the room
[17:00:17] <kaduk@jabber.openafs.org/barnowl> greetings
[17:00:18] <meffie> good afternoon
[17:00:46] <yadayada> hi all
[17:00:55] <mvita2> hello
[17:02:19] wiesand joins the room
[17:02:39] <wiesand> Hello
[17:02:58] <kaduk@jabber.openafs.org/barnowl> It is friday.
[17:03:13] <wiesand> Indeed.
[17:04:17] <wiesand> So, after the last meeting I pulled up a couple more changes…
[17:05:11] cwills joins the room
[17:05:21] <cwills> Hello all
[17:06:50] <wiesand> There could be an interesting showdown between the auth-catchup stack (https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_8_x+topic:auth-catchup), and maybe even just parts of it,  and the sole 14461.
[17:07:11] <wiesand> I'm undecided, and do need your input.
[17:08:23] <wiesand> What's left on my wish list is aklog and FBSD. Any late additions?
[17:10:02] <wiesand> If not, any news then? How are we doing w.r.t. the latest Linux 5.10 rc?
[17:10:27] <kaduk@jabber.openafs.org/barnowl> 14461 seems quite unimportant compared to the collective auth-catchup
stack.  I would actually mostly expect `git cherry-pick` to find the
right file if one tries to cherry-pick 14213 again after the
auth-catchup changes are merged
[17:10:27] <meffie> i'm not sure why we are trying to pull up the auth refactoring changes to stable.
[17:11:11] <meffie> but i guess it is to avoid code skew.
[17:11:35] <kaduk@jabber.openafs.org/barnowl> I am seeing a memory-leak fix (possibly in the non-error path?) and
the "bosserver shouldn't crash when there's no local config dires"
patch, in the auth-catchup stack
[17:11:40] <meffie> and to eventually retire the 'mkdir /usr/vice/etc' in the bosserver
[17:12:07] <kaduk@jabber.openafs.org/barnowl> Er, wait, 14459 is in the auth-catchup stack and 14461 is
cherry-picking the same thing.
[17:12:16] <kaduk@jabber.openafs.org/barnowl> So is the question just "do the stack" vs "do the one thing"?
[17:13:58] <wiesand> Mike: Because you put 14213 on the 1.8.7 wish list,  and it's either moving that change from a no longer existing file to a different one (making code skew and thus later pullups much worse), or biting the bullet and taking on that stack.
[17:15:01] <meffie> i see.
[17:15:50] <cwills> Latest master & 1.8.x built cleanly against linux-5.10-rc7+
[17:16:20] <wiesand> Ben: yes. As the comments should point out, it's either that single, simple, but really dirty pullup, or that huge stack of "almost entirely clean pullups".
[17:16:45] <wiesand> Cheyenne: Thanks
[17:18:26] <wiesand> To simply say it again, I'm undecided and will need your help here.
[17:18:31] <yadayada> @cwill did you got below error on 5.9
[17:18:32] <yadayada> 339:12: error: incompatible type for argument 1 of ‘set_fs’
  339 |     set_fs(get_ds());
      |            ^~~~~~~~
[17:18:50] <yadayada> openafs-1.8.5/src/afs/LINUX/osi_compat.h:339:12: error: incompatible type for argument 1 of ‘set_fs’
  339 |     set_fs(get_ds());
      |            ^~~~~~~~
[17:19:15] <yadayada> I am having 5.9.10-100.fc32.x86_64
[17:19:24] <cwills> There should be a patch for that
[17:19:58] <yadayada> I tried searching for it but didn;t get
[17:20:15] <cwills> Let me look...
[17:20:21] <yadayada> ok
[17:23:16] <kaduk@jabber.openafs.org/barnowl> My own sense is leaning towards the whole auth-catchup stack, but I
want to hear what Mike thinks.
The wholesale "remove DUX/OSF" gives me a bit of pause, but perhaps
not too much
[17:23:19] <cwills> Picked up with 1.8.x gerrit 14267
[17:24:26] <kaduk@jabber.openafs.org/barnowl> Hmm, though I guess 14453 is changing a struct in the public header,
which is not so great
[17:25:38] <meffie> i dont think it is worth pulling up all of those refactoring changes to the stable branch. i think andrew agreed in gerrit 14461
[17:27:45] <kaduk@jabber.openafs.org/barnowl> It seems like we have our answer, then.
[17:28:46] <wiesand> 14461 is not carrying a single "code review +1" though…
[17:29:50] <kaduk@jabber.openafs.org/barnowl> That's easy to fix
[17:29:52] <wiesand> but I'll gladly merge that and abandon the stack if that's what the experts consider most expedient
[17:32:27] <meffie> i do think so. sorry for all that mess.
[17:33:05] <meffie> (this bug was found during code reviews of those changes, which is how this all happened.)
[17:33:35] <meffie> desk check, as mark vitale would say
[17:33:50] <mvita2> heh - I been name checked
[17:34:12] <wiesand> dont't be sorry - that's why we have these meetings and the code review process after all
[17:37:41] <wiesand> So, 14461 it shall be. I *may* leave the "Remove DUX/OSF" change up for review but will abandon the rest of the stack.
[17:38:00] <wiesand> Anything else on 1.8.x to discuss today?
[17:38:33] <yadayada> Thanks @cwill for pointing out the gerrit.  Recently I have seen one interesting issue using LSM with OpenAFS I want to discuss on that
[17:38:40] <yadayada> https://www.spinics.net/lists/linux-security-module/msg39079.html
[17:38:49] <meffie> did i ask about 14417?
[17:39:04] <meffie> it has been merged on master now.
[17:39:34] <meffie> oh, i see the 1.8.x version of it.
[17:39:53] <wiesand> :)
[17:40:53] <cwills> 14451
[17:41:07] <meffie> (added a comment on 14414, to point to the pullup. thanks!)
[17:41:33] <kaduk@jabber.openafs.org/barnowl> That LSM post is an interesting scenario.
Is there some analogous AFS situation where we are trying to write to
a file "from the driver"?
[17:41:42] <yadayada> This happens when kernel calls dput during process is exiting. Problem is when control comes to AFS task->fs becomes NULL by kernel as part of cleanup. Since we call dentry_open for cachefiles it trigger LSM (Linux security Module) falcon to do some access checks. But since task->fs is NULL LSM didn;t expect that and it crashes the kernel. I am still looking into but looks we are breaking protocol with LSM
[17:43:03] <mvita2> hmmm
[17:43:13] <kaduk@jabber.openafs.org/barnowl> This seems somewhat related to the issues that were fixed by ...
[17:43:29] <kaduk@jabber.openafs.org/barnowl> https://gerrit.openafs.org/13751
[17:44:37] <kaduk@jabber.openafs.org/barnowl> Which is already on the 1.8.x branch (as 14082) but not in a release
yet
[17:44:43] <kaduk@jabber.openafs.org/barnowl> if I am reading things correctly
[17:45:09] <yadayada> yes looks it touches same code segment which I was referring to. Let me try this patch. Thanks Ben
[17:45:44] <kaduk@jabber.openafs.org/barnowl> you're welcome
[17:45:58] <kaduk@jabber.openafs.org/barnowl> Also thanks to jhutz for tracking down the actual places to change
[17:47:09] <mvita2> agreed that 13751 should help
[17:48:19] <yadayada> Right since this change can avoid kernel crashes I think it should be pulled in release, may be next one
[17:48:44] <kaduk@jabber.openafs.org/barnowl> That is the plan :)
[17:52:42] <wiesand> 14082 is headed for 1.8.7pre1
[17:53:01] <kaduk@jabber.openafs.org/barnowl> I guess that we are done with 1.8.x stuff then?
[17:53:25] <meffie> i have nothing more.
[17:53:27] <wiesand> Seems so.
[17:53:53] <kaduk@jabber.openafs.org/barnowl> Not too much news from my side this week -- I merged a few things as
they came in, and have been looking at the rx/restart-hang stack that
leads into the rx-mmsg stack
[17:54:15] <kaduk@jabber.openafs.org/barnowl> I did want to ask people about the "add vos argument to send queries
to sync-site" change, though
[17:54:33] <kaduk@jabber.openafs.org/barnowl> (14044)
[17:55:07] <kaduk@jabber.openafs.org/barnowl> I'm not really sure what to read into jaltman's adding then removing a
+2 and adding more comments
[17:56:18] <meffie> not sure
[17:57:10] <kaduk@jabber.openafs.org/barnowl> The point about making assumptions about credentials usability across
services may require some further thought
[17:57:39] <kaduk@jabber.openafs.org/barnowl> But I'm not entirely sure how soon I could get a chance to do that
thinking, and this change is at the bottom of the whole stack (why?)
[17:57:45] <meffie> i dont think that patch was meant to give an authoritative answer to which site is the current sync site, just a best effort to get the current sync site to avoid a delay
[17:59:03] <kaduk@jabber.openafs.org/barnowl> Perhaps yet another cli flag rename is in our future, then...
but I don't think that alleviates the concerns about using credentials
across services
[18:00:07] <meffie> it's been a while since i thought about this change, i could be remembering wrong.
[18:01:51] <meffie> ah, andrew explains the use case: "the motivation for this is that "stale" ubik reads can cause issues for a site's scripts for volume management automation. one step of a process may create a volume, and the next step tries to lookup some information for that volume very soon afterwards; if we happen to hit a site that it out of date, it'll (correctly) return a VL_NOENT error, which looks like a normal permanent error."
[18:02:48] <meffie> so, we have a script that does a vos create, followed by a vos listvldb --name.
[18:03:24] <mvita2> this exposure can happen whenever the pace of RPCs from a vos operation exceeds the pace at which ubik can propagate updates
[18:03:45] <meffie> yes, and the data has not been propagated yet
[18:03:49] <kaduk@jabber.openafs.org/barnowl> agreed
[18:04:54] <kaduk@jabber.openafs.org/barnowl> The part I think will require most thought is the way that we're
adding new VOTE_ calls as part of servicing what is logically a VL_
operation
[18:05:55] <kaduk@jabber.openafs.org/barnowl> As Jeff notes, we might ideally want VOTE_ to be limited to just rxgk
(though IIRC this is hard because a lot of the voting stuff uses abort
packets which aren't protected?)
[18:06:18] <mvita2> yup, vote replies are rx aborts
[18:06:31] <mvita2> VOTE_Beacon replies, to be precise
[18:07:39] <mvita2> for the other VOTE_ rpcs , aborts would be unusual
[18:08:32] <meffie> maybe not bother with the votes at all, just send the db read to all the servers and hope one comes back with an answer :)
[18:08:52] <mvita2> oh.  dear.
[18:09:10] <meffie> brute force!
[18:09:38] <mvita2> et tu, brute?
[18:10:34] <kaduk@jabber.openafs.org/barnowl> If the new flag is just supposed to be best-effort and we have to fall
back to the default behavior if there's some kind of credentials
mismatch/error, maybe that risk is tolerable.  I'm not sure yet...
[18:11:10] <meffie> sounds reasonable. thanks ben!
[18:11:50] <wiesand> An other topics to discuss today?
[18:11:57] <kaduk@jabber.openafs.org/barnowl> On a completely different topic, I will note (since we do
periodically mention it as a 1.8.x desideratum) that IIUC the FBSD
stack is blocked on some prepreocessor-reindent changes.  I pinged
Andrew on the first change, but may end up just making the fixes
myself.
[18:12:41] <meffie> ok thanks
[18:13:41] <kaduk@jabber.openafs.org/barnowl> Oh, and I saw some activity on the audit-pipe change; it sounded like
maybe it was going to need a new rev?
[18:13:45] <wiesand> Hmm, car to translate that for a dummy like me? Does that mean simply pulling up FBSD changes makes no sense right now?
[18:14:20] <kaduk@jabber.openafs.org/barnowl> There are some FBSD changes already on master, that are good to pull
up.
[18:14:45] <kaduk@jabber.openafs.org/barnowl> I don't think I can merge any additional ones to master until these
whitespace changes are ready (unless I rebase around themm)
[18:15:07] <wiesand> Ok, thanks.
[18:15:51] <wiesand> https://en.wikipedia.org/wiki/Whitespace_(programming_language)
[18:16:14] <meffie> oh, that's just evil!
[18:16:36] <kaduk@jabber.openafs.org/barnowl> Yeah, my instinctive reaction is "AAAAAAAAAAAAAAAAAAAAAAAAAAAA"
[18:17:03] <kaduk@jabber.openafs.org/barnowl> Hmm, I see that one of the bigsur changes has a +1 but the other two
do not.  Is there anything useful to say about those patches at the
moment?
[18:17:39] <meffie> i think we just need more reviewers?
[18:17:54] <kaduk@jabber.openafs.org/barnowl> ok
[18:18:18] <meffie> i'll see if we can do some reviews.
[18:18:40] <meffie> i believe yadav was still testing too?
[18:18:44] <kaduk@jabber.openafs.org/barnowl> thanks!
[18:18:49] <yadayada> I have done testing of latest changes for Bigsur and things seems fine. But I do have some extra changes for latest sdk
[18:19:07] <meffie> thank you yadayada
[18:19:23] <yadayada> I will create gerrit soon. Mainly we support i386 and x86_64 but looks latest sdk has deprecated support for i386
[18:20:03] <kaduk@jabber.openafs.org/barnowl> i386 is going out; arm64 is coming in...
[18:20:26] <yadayada> yeah we need to remove i386  that for DARWIN atleast
[18:22:24] <meffie> motion to adjourn?
[18:22:30] <kaduk@jabber.openafs.org/barnowl> SGTM
[18:22:54] <yadayada> nothig from my side
[18:23:04] <meffie> thanks all, have a safe weekend.
[18:23:06] <wiesand> "SGTM"?
[18:23:15] <meffie> sounds good to me
[18:23:28] <meffie> like rtfm read the find manual
[18:23:41] <wiesand> me idiot be
[18:23:46] <mvita2> "but someone else must approve"
[18:23:55] <kaduk@jabber.openafs.org/barnowl> mvita2: nice one ;)
[18:24:06] <mvita2> BSEMA
[18:24:07] <meffie> ;)
[18:24:26] <wiesand> Let's adjourn then. Please stay safe!
[18:24:36] <kaduk@jabber.openafs.org/barnowl> Thanks everyone.  Have a good weekend!
[18:24:38] <mvita2> have a good weekend
[18:24:42] <yadayada> Thanks all
[18:25:02] meffie leaves the room
[18:25:05] wiesand leaves the room
[18:25:46] mbarbosa leaves the room
[18:26:12] mbarbosa joins the room
[18:28:15] <cwills> take care everyone
[18:39:09] cwills leaves the room
[18:55:11] yadayada leaves the room
[20:11:44] kaduk@jabber.openafs.org/barnowl leaves the room
[21:40:56] mbarbosa leaves the room