=== Guest49128 is now known as fmasi
=== davmor2_ is now known as davmor2
=== lool- is now known as lool
[10:32] <mork> anyone here?
[10:51] <apw> yes ... not you, but yes
[10:53] <davmor2> mork This is Awson 
[10:57] <apw> heh
=== gmb` is now known as gmb
[12:59] <apw> smb, so i think the ip6_hold locking there is still ok, but you seem to have a point about RCU on the second existing caller.
[12:59] <apw> smb, i've replied on the mail thread with my reasoning
[13:00] <smb> apw, Hm, I just read one reply which seemed to concern only the locking
[13:00] <smb> Ah here comes number 2
[13:00] <apw> smb, yeah that was to tim's query.
[13:04] <rtg> I've kind of lost the thread on that patch. On the other hand. the author has not replied in 2 weeks, so maybe nobody really cares ?
[13:04] <smb> apw, Yeah ok looking at it that way it should be safe through holding that reference in the timer case. But the unlocked function is also called from those two changing functions now
[13:06] <smb> rtg, it could be that ipv6 is still rather rarely cared about (except by apw maybe... ;)) 
[13:06] <apw> i don't really know why anyone would bother to switch that option, let alone care about it admittedly incorrectly dropping the addresses and putting them back
[13:07] <apw> i also will note that in the current kerenel it doesn't drop the addresses at all as you might be using them, and ismply lets them expire naturally
[13:08] <rtg> apw, I'm inclined to just let it die unless someone who cares appears.
[13:08] <apw> rtg, tend to agree.  i suspect that the fix is safe, for non-lowlatency kernels just because rcu lock is baslically a noop
[13:09] <smb> I would agree especially since I have the feeling the locking / ref-counting is not right
[13:09] <rtg> alright, consider it ignored
[13:11] <smb> apw, Should we care to add a note abotu that in the bug report?
[13:12] <apw> smb, i think you just volunteered
[13:12] <smb> apw, And with we I mean you, so the comment is parsable and not accidentally rude
[13:18] <apw> damn you
[13:26] <apw> ok done, though i was terse :)
[13:26] <smb> apw, at least not _accidentally_ rude. :D
=== tyhicks` is now known as tyhicks
[14:55] <tseliot> rtg: I've just uploaded a fixed nvidia 173. I think all my packages should ready now
[14:55] <rtg> tseliot, thanks
=== bdmurray_ is now known as bdmurray
=== chiluk` is now known as chiluk
[15:56] <arges> If I do this: echo '<2>testing' | sudo tee /dev/kmsg  ... I should expect a priority 2 message exposed via 'dmesg -r' right?
[16:00] <arges> rtg: bug 1274444
[16:00] <ubot5> bug 1274444 in linux (Ubuntu) "echo string to /dev/kmsg fails to appear on /var/log/syslog" [Medium,In progress] https://launchpad.net/bugs/1274444
[16:05] <pkern> The ABI guarantee is that an old version of the module works with a new kernel of the same ABI. Is that actually true with precise w/ lts-trusty -> trusty upgrade? Does the newly built kernel (higher version) share the same ABI?
[16:06] <rtg> pkern, nope, different toolchain
[16:07] <infinity> Changing toolchain shouldn't (usually) change ABI, though.
[16:07] <infinity> But I guess we also don't attempt to test/verify that lts == master.
[16:08] <sforshee> smb: since you're an skb expert now would you mind giving http://paste.ubuntu.com/7727065/ a review?
[16:08] <sforshee> I think you looked at it once before, but I made a couple of changes
[16:09] <smb> sforshee, Sure (though I would never dare to call me anything near an expert when it comes to that skb stuff)
[16:10] <sforshee> smb: well, more expert than me at least
[16:10] <smb> sforshee, Huh, I am not the one that writes patches for it. :)
[16:11] <pkern> rtg, infinity: So that breaks the upgrade assumption and does not trigger dkms rebuilds?
[16:57] <infinity> pkern: Quite possibly, yeah.  I'd be willing to bet the ABI doesn't actually change, but we definitely don't test for the truth of that.
[16:57] <infinity> pkern: For in-archive dkms modules, they'd tend to be upgraded too, so it might just be self-solving, depending on apt ordering, but local modules wouldn't be so lucky.
[16:58] <infinity> pkern: Possibly too late to think about clever hacks and workaround for precise->trusty, but perhaps worth a long, hard think for trusty->16.04
[17:16] <pkern> infinity: Yeah, it's a local module that had some trouble.
[18:37] <mjg59> Anyone know when overlayfs got xattr support in Ubuntu?
[18:40] <rtg> apw, ^
[20:08] <apw> mjg59, at least precise
[20:11] <mjg59> apw: Ok. So it's some other layer that's giving me EOPNOTSUPP on lsetxattr().
[20:11] <mjg59> (sigh selinux)
[22:38] <hans109h> Just a reminder that it would be nice if the fix in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981 was packaged into a commit....please...
[22:38] <ubot5> Ubuntu bug 1313981 in linux (Ubuntu) "Kernel disabling serial port ttyS0 on boot" [Medium,Confirmed]
[22:41] <infinity> apw: ^-- Looks like you have the most recent context on this.