Switch to DuckDuckGo Search
   August 30, 2019  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >

Toggle Join/Part | bottom
[00:04:20] *** jellydonut <jellydonut!~quassel@s91904424.blix.com> has quit IRC (Ping timeout: 248 seconds)
[00:04:44] *** phyre__ <phyre__!~phyre___@> has joined #illumos
[00:09:36] *** user888 <user888!~user888@pool-74-105-193-56.nwrknj.fios.verizon.net> has joined #illumos
[00:20:33] <andyf> It doesn't look like us public people can download attachments from tickets
[00:21:29] <LeftWing> Someone should really implement that for bugview!
[00:26:51] <richlowe> https://gist.github.com/richlowe/3ed6db3bb20304fefd5762f01a9c6f46
[00:27:00] <richlowe> it's just the saveargs dump test modified to check for push/mov
[00:27:13] <richlowe> though it shouldn't check for mov, based on what was said earlier.
[00:27:51] <richlowe> it really should be tidied and made into a real test.
[00:29:00] <richlowe> (so should the saveargs dump, if maybe the type info can be used to cut down on the false positives?)
[00:30:20] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has joined #illumos
[00:33:58] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 244 seconds)
[00:36:19] *** phyre__ <phyre__!~phyre___@> has quit IRC (Ping timeout: 268 seconds)
[00:39:00] <jbk> jlevon: i don't know how i missed that (-fshrink-wrap) this morning when i was looking at the optimizatino options
[00:41:46] <jlevon> me too
[00:47:17] *** gwr <gwr!~gwr@> has joined #illumos
[01:01:55] <gwr> Hey, just wondering: Could smatch be used instead of BSD-style "linker warnings" to warn about undesireable calls to gets(3c) or sprintf(3c) etc?
[01:03:25] <jlevon> yes, pretty easily
[01:05:02] <jlevon> is there a reason you'd prefer smatch to a deprecated attribute though?
[01:05:34] <gwr> Seems like it might be a bit more expedient
[01:06:41] <richlowe> the deprecated attribute is easier
[01:06:48] <richlowe> (that's not doing it in the linker)
[01:07:00] <gwr> oh? a marking for the compiler?
[01:07:06] <jlevon> yes
[01:07:12] <jlevon> it's a gcc attribute
[01:07:24] <gwr> that's interesting. didn't know about that.
[01:07:27] <jlevon> either way we'd have a LOT of sprintf to turn back off again
[01:07:31] <gwr> (or didn't remember:)
[01:07:52] <gwr> I just did a quick search for gets and that one doesn't look too bad.
[01:08:10] <gwr> around 50 "real" hits.
[01:08:38] <jlevon> 50. gotta love a legacy code base
[01:09:05] <gwr> oh. sprintf is maybe 1000 (sigh)
[01:09:13] <richlowe> I did mention that there's basically nothing we can enforce here that we don't violate, heavily, ourselves. :)
[01:09:21] <gwr> yeah, just wondering.
[01:09:27] <richlowe> (if you're going to search strcat/strcpy next, hold your nose) :)
[01:09:30] <gwr> not raising my hand for this just yet :)
[01:10:51] <gwr> Well, so there maybe some smarter checks that something like smatch might be able to do could allow those that have limited size outputs like "%d" and such.
[01:11:17] <LeftWing> It seems like with some amount of effort we can make smatch checks that do pretty specific flexible things
[01:11:22] <rmustacc> The recent approach that was calledo ut in git was pretty interesting.
[01:11:26] <gwr> No idea how hard that might be to implement.
[01:11:35] <rmustacc> I'd basically opt to bringin in stricter code that warns on all of the buffer things.
[01:11:55] <rmustacc> I dislike relying on analysis of saying the sprintf is probably ok because it's just a %d as it makes it harder to reason about and easier for someone to break in the future.
[01:12:21] <rmustacc> But the git way of a header that basically bans certain functions and at least making it something that we force onto new stuff may be something to think about.
[01:12:31] <gwr> Agree, just trying to think of ways to make small steps in a useful direction.
[01:12:44] <rmustacc> Yup, was just trying to suggest another opt-in way.
[01:12:58] <LeftWing> Yeah it'd be good to first have a way that new code can no longer make the mistake(s)
[01:13:14] <rmustacc> Which makes it much easier to say, I'm working on something new and doesn't require one to force us to fix everything at once.
[01:13:57] <gwr> So what does that look like? A bunch of new -Wno-bad-buffer-stuff to exempt legacy code?
[01:14:24] <rmustacc> Well git did it with a header file that basically banned functions.
[01:14:35] <LeftWing> And they include that header file in new code?
[01:14:38] <rmustacc> And you just make sure that gets included for software.
[01:14:45] <rmustacc> They did it that way.
[01:14:59] <gwr> Ah, so opt-in by including the "cleanliness" pill.
[01:15:07] <LeftWing> #include <sys/mothermayi.h>
[01:15:07] <jlevon> I don't see the point of banning when we can add attributes and do it that way
[01:15:27] <rmustacc> Yeah, that's another way to approach it.
[01:15:27] <jlevon> more makefile churn but
[01:15:53] <rmustacc> While things like strcpy, gets, etc. may be obvious. There may be other things which folks probably shouldn't use.
[01:16:04] <rmustacc> But aren't deprecated from a unix/sus perspective.
[01:17:06] <jlevon> it'd have to be an osnet-build time thing only not system headers
[01:17:14] <rmustacc> Ah, gotcha.
[01:17:21] <rmustacc> Makes sense.
[01:17:44] <jlevon> basically something ccopmile.h turns into a real attribute if something is set.
[01:17:56] <gwr> I care more about some things than others: Kernel (a lot) libraries (some), ordinary commands (not so much)
[01:18:16] <rmustacc> jlevon: Makes sense.
[01:18:41] <rmustacc> I'm actually more paranoid of suid programs and libraries than say a random device driver.
[01:18:42] <gwr> So to me that favors something like warning levels.
[01:18:56] <gwr> "you looking at me?"
[01:19:00] <gwr> :)
[01:19:03] <rmustacc> No.
[01:19:09] <rmustacc> Things like file, snoop, etc.
[01:19:14] <rmustacc> Anything that parses user input.
[01:19:21] <gwr> having just undone one of those :)
[01:19:21] <rmustacc> Programs that root runs that don't drop privs.
[01:19:47] <gwr> good point
[01:20:05] <gwr> about popular admin cmds
[01:20:34] <LeftWing> Anything that ever touches potentially untrusted input
[01:20:37] <LeftWing> e.g., mailx
[01:20:57] <rmustacc> But the real solution to those is different, imho.
[01:21:11] <rmustacc> Or rather, the more important thing is to drop privs from them so when you run file as root it doesn't have PRIV_SYS_DEVICES
[01:21:22] <rmustacc> Like OpenBSD pledge.
[01:21:27] <LeftWing> Yeah that kind of hardening is a good idea
[01:21:37] <rmustacc> So, probably not worth getting too distracted with that from the header path.
[01:21:48] <LeftWing> There are many possible projects here!
[01:21:52] <arekinath> the worst mistakes the kernel makes are usually in framework or syscall code rather than drivers -- things that userland can reach pretty easily
[01:22:06] <rmustacc> Yeah
[01:22:06] <arekinath> it depends on your threat model though
[01:24:03] <rmustacc> jlevon: Was your thought basically start with a list and exempt things that are broken to prevent new things, or?
[01:24:12] <gwr> Is there a good list of "bad" functions? Just curious to get some data about where we stand.
[01:24:28] <arekinath> stuff like int overflow and signed type confusion, toctou bounds checks, use-after-free of nested resources on complex ioctl interfaces are kind of the bread and butter of userland-kernel exploits, much more than bad use of string functions in the kernel
[01:24:36] <arekinath> just because the kernel has less reason to use string functions, in general
[01:24:49] <rmustacc> gwr: I'd start with string / I/O functions that don't have array bounds.
[01:24:50] <jlevon> rmustacc: well something like we did with gcc options, but hopefully pushed down a bit further.
[01:24:59] <arekinath> but in userland strings are the game
[01:25:00] <arekinath> :P
[01:25:21] <rmustacc> gwr: So start with gets(), strcpy(), sprintf(), etc.
[01:25:23] <jlevon> there is still a depressing amount of string parsing lurking kernel side though.
[01:25:37] * jlevon disappears
[01:26:21] <rmustacc> The other class of common things in this bucket are non-reentrant functions. Like use strtok() and not strtok_r().
[01:29:08] <gwr> https://groups.google.com/forum/#!topic/vim_dev/O5elkUimoBI
[01:29:16] <rmustacc> gwr: Of course, strcat(), stpcpy(), vsprintf(),
[01:29:19] <gwr> Nice example of warnings from OpenBSD.
[01:29:27] <gwr> their warning recommend alternatives.
[01:30:20] <arekinath> yeah, though it works so well for them in a context where existing compiler warning rates are pretty low and they're working to address them all the time
[01:31:00] <arekinath> (like, as I understand it they were pretty close to warning clean in most of base before they put those in)
[01:32:21] <gwr> Anyone know if those warnings come from header declaration stuff? or linker stuff? or what
[01:32:24] <rmustacc> I think the challenge is just how to introduce it given some pretty grotty existing code.
[01:32:36] <rmustacc> that all looks like the compiler and probably pragmas.
[01:33:57] <rmustacc> But I'll see if I can find something.
[01:34:03] <gwr> I don't see it in the FreeBSD headers (on our OpenGrock) Do they have that stuff like OpenBSD?
[01:34:14] <rmustacc> Can't say.
[01:34:24] <rmustacc> Ah, nevermind. They're doing it based on the linker.
[01:34:34] <rmustacc> I misread how it was implemented.
[01:34:46] <rmustacc> It wouldn't be too hard to prototype something like that for ld.
[01:34:59] <rmustacc> If you wanted to see something.
[01:36:26] <gwr> Ok, so if one did that in the linker, would we still have ways to enable (or disable) the warnings in the various places we care more (or less) about?
[01:36:45] <rmustacc> Probably?
[01:37:13] <LeftWing> I would expect it would be something you'd toggle through LDFLAGS then?
[01:37:20] <rmustacc> Yes.
[01:37:23] <gwr> Would this be something like an optional linker map that causes some symbols to generate warnings?
[01:37:31] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has quit IRC (Remote host closed the connection)
[01:37:37] <LeftWing> Some kind of "-z" thing maybe?
[01:37:43] <rmustacc> In essence, yes.
[01:38:00] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has joined #illumos
[01:38:21] <gwr> I like that idea of being able to specify such things in a mapfile.
[01:38:54] <gwr> but maybe that's not what they're for...
[01:39:08] <rmustacc> Not exactly, but configurability is probably important.
[01:39:17] <gwr> Just slightly concerned about building in a list somewhere.
[01:39:31] <rmustacc> So, in terms of what OpenBSD does is that they leverage the .gnu.warning capability.
[01:39:37] <rmustacc> So see this definition http://src.illumos.org/source/xref/openbsd-src/sys/arch/amd64/include/cdefs.h#17
[01:39:52] <rmustacc> And this example of its usage: http://src.illumos.org/source/xref/openbsd-src/lib/libc/stdio/sprintf.c#41
[01:40:13] <rmustacc> gwr: Building in a list somewhere in what sense? Like building a hardcoded list in a binary artifact?
[01:40:46] <gwr> yeah, something not easy to change.
[01:41:19] <gwr> Or, I'm thinking one might want different "bad" lists for different programs or link environments
[01:41:35] <rmustacc> Yeah, I understand.
[01:41:40] <rmustacc> Makes senes.
[01:43:16] <gwr> So the __warn_references() macro doesn't seem all that "high-tech", is it? Just dump stuff in a special section?
[01:43:25] <gwr> I guess the linker needs to know about it though.
[01:44:16] <gwr> Oh, so those macros get expanded when building their libc, for example.
[01:44:29] <gwr> So there's some more "magic" around for this.
[01:44:35] <gwr> (ld I guess)
[01:44:54] <gwr> Thanks for the pointers.
[01:46:30] <rmustacc> That magic is something that gld understands so when other software tries to reference it, it creates that.
[01:47:25] <richlowe> as I said to Gordon via email, I'd want to put it in .SUNW_syminfo
[01:49:11] <rmustacc> richlowe: I'm not sure I'd want to build it in at first, tbh.
[01:49:31] <richlowe> building in the association with the symbol seems fine
[01:49:43] <richlowe> whether the default behaviour is "warning", "error" or "ignore" seems more what you'd worry about?
[01:49:54] <rmustacc> Well, the set of symbols is probably also the case.
[01:50:36] <richlowe> it also has the benefit of actually knowing it's the symbol being bound to.
[01:51:07] <rmustacc> Yeah. That's true. An alternative is something like feeding in a list of qualified banned symbols at link time.
[01:51:21] <rmustacc> As an argument. So you could say libc.so.1`gets()
[01:51:23] <richlowe> I think you'd have to add a new top-level mapfile section to do that there
[01:51:31] <richlowe> which does seem the natural place to do it
[01:51:57] <rmustacc> Probably. Depends on if the amount of configurability I'm thinking of is really worthwhile.
[01:52:22] <rmustacc> For example, saying you should always use the '_r' versions of functions.
[01:52:51] <LeftWing> Except for like readdir_r
[01:53:51] <rmustacc> I mean, a lot of single-threaded stuff still gets that wrong after a bad refactoring. :/
[01:54:19] <richlowe> that's heading far more into things we'd like to know, than things we'd like to ship for others to know
[01:54:31] <rmustacc> Right, I agree.
[01:54:41] <richlowe> if you just want _us_ to check, you can do that with grep :)
[01:54:49] <rmustacc> I wouldn't want others to know that stuff, since it's just me being persnickety.
[01:55:02] <richlowe> or the gcc attribute (unless I missed someone saying that wouldn't work)
[01:55:04] <rmustacc> richlowe: This started with gwr only being worried about the 'us' case.
[01:55:18] <richlowe> right, if you're only worried about us, do it with the compiler as John discussed.
[01:55:20] <richlowe> or smatch
[01:55:21] <richlowe> or grep
[01:55:32] <rmustacc> And from there the question is would we care about different things for different sets.
[01:55:50] <richlowe> it's probably the age old "utter shit" and "we hope it's less shit" groups.
[01:56:23] <rmustacc> Well, trying to also assume me maybe saying we shouldn't use functions blah isn't always going to be universal.
[01:57:01] <richlowe> the ones that are universal are by far the more important, though?
[01:57:07] <rmustacc> Yeah.
[01:57:28] *** gwr <gwr!~gwr@> has quit IRC (Quit: This computer has gone to sleep)
[02:46:18] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has quit IRC (Quit: aszeszo)
[02:57:06] *** gwr <gwr!~gwr@> has joined #illumos
[03:00:11] <gwr> BTW, grep hits ton's of false positives for "gets".
[03:01:07] *** user888 <user888!~user888@pool-74-105-193-56.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 246 seconds)
[03:09:16] *** user888 <user888!~user888@pool-74-105-193-56.nwrknj.fios.verizon.net> has joined #illumos
[03:20:00] *** ed209 <ed209!~ed209@> has quit IRC (Remote host closed the connection)
[03:20:07] *** ed209 <ed209!~ed209@> has joined #illumos
[03:27:58] *** user888 <user888!~user888@pool-74-105-193-56.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 245 seconds)
[03:28:51] <richlowe> I'm guessing your regexp isn't so tight?
[03:29:01] <richlowe> '\<gets(' should be fine
[03:31:50] <gwr> BTW, smatch already checks sprintf buffer sizes, and many other such things.
[04:04:34] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[04:28:58] *** gwr <gwr!~gwr@> has quit IRC (Quit: This computer has gone to sleep)
[04:54:45] *** user888 <user888!~user888@pool-74-105-193-56.nwrknj.fios.verizon.net> has joined #illumos
[05:12:44] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[07:39:16] <tsoome> oo, I smell more cleanups coming:)
[07:47:41] *** kev009 <kev009!~kev009@ip72-222-200-117.ph.ph.cox.net> has quit IRC (Remote host closed the connection)
[07:48:51] *** phyre__ <phyre__!~phyre___@> has joined #illumos
[07:50:44] *** kev009 <kev009!~kev009@ip72-222-200-117.ph.ph.cox.net> has joined #illumos
[07:59:13] *** phyre__ <phyre__!~phyre___@> has quit IRC (Ping timeout: 245 seconds)
[08:13:06] *** user888 <user888!~user888@pool-74-105-193-56.nwrknj.fios.verizon.net> has quit IRC (Quit: Leaving)
[08:36:42] *** alanc <alanc!~alanc@> has quit IRC (Remote host closed the connection)
[08:37:09] *** alanc <alanc!~alanc@> has joined #illumos
[08:41:33] *** dopplergange <dopplergange!~dop@> has quit IRC (Quit: ZNC 1.7.3 - https://znc.in)
[08:41:55] *** dopplergange <dopplergange!~dop@> has joined #illumos
[08:52:25] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has quit IRC (Quit: No Ping reply in 180 seconds.)
[08:53:32] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has joined #illumos
[09:22:37] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: tsoome)
[09:32:05] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has quit IRC (Quit: No Ping reply in 180 seconds.)
[09:33:12] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has joined #illumos
[09:59:38] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[10:05:22] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[10:14:25] *** andy_js <andy_js!~andy@> has joined #illumos
[10:19:57] <mnowak_> can someone remove these two spammers, please? https://www.illumos.org/users/7071 & https://www.illumos.org/users/7082
[10:32:49] *** man_u <man_u!~manu@manu2.gandi.net> has joined #illumos
[10:58:39] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[10:59:29] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Remote host closed the connection)
[10:59:56] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[11:07:32] *** merzo <merzo!~merzo@155-87-203-46.pool.ukrtel.net> has joined #illumos
[11:21:08] *** jellydonut <jellydonut!~quassel@s91904426.blix.com> has joined #illumos
[11:27:09] *** merzo <merzo!~merzo@155-87-203-46.pool.ukrtel.net> has quit IRC (Ping timeout: 258 seconds)
[11:33:40] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has joined #illumos
[11:38:34] *** jimklimov <jimklimov!~jimklimov@ip-86-49-243-242.net.upcbroadband.cz> has quit IRC (Read error: Connection reset by peer)
[11:53:14] *** jimklimov <jimklimov!~jimklimov@ip-86-49-243-242.net.upcbroadband.cz> has joined #illumos
[11:54:06] <andyf> oh, there is still a NULL pointer issue in gate :)
[12:01:19] <tsoome> wot?
[12:01:25] <andyf> when building with openssl 1.1
[12:01:26] <tsoome> where, why?
[12:01:32] <tsoome> a.
[12:01:33] <andyf> I'll push to RB
[12:01:45] <andyf> simple fix at least
[12:02:03] <tsoome> most of them are
[12:04:48] <andyf> https://illumos.org/rb/r/2275/
[12:06:59] <andyf> I will fix up the whitespace nits too..
[12:10:13] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Remote host closed the connection)
[12:10:41] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[12:16:38] *** merzo <merzo!~merzo@> has joined #illumos
[12:20:00] *** ed209 <ed209!~ed209@> has quit IRC (Remote host closed the connection)
[12:20:07] *** ed209 <ed209!~ed209@> has joined #illumos
[12:23:44] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (*.net *.split)
[12:23:44] *** kev009 <kev009!~kev009@ip72-222-200-117.ph.ph.cox.net> has quit IRC (*.net *.split)
[12:23:45] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has quit IRC (*.net *.split)
[12:23:45] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (*.net *.split)
[12:28:53] *** echelog-1 <echelog-1!~echelog-1@> has joined #illumos
[12:29:03] *** jrick <jrick!~jrick@unaffiliated/jrick> has joined #illumos
[12:29:05] *** ikonia <ikonia!~irc@unaffiliated/ikonia> has joined #illumos
[12:29:08] *** m4rley <m4rley!~m4rley@> has joined #illumos
[12:29:14] *** nahamu <nahamu!~nahamu@> has joined #illumos
[12:29:25] *** dlg <dlg!~dlg@toy.eait.uq.edu.au> has joined #illumos
[12:29:40] *** PMT <PMT!~PMT@pool-100-33-69-155.nycmny.fios.verizon.net> has joined #illumos
[12:30:12] *** kkantor <kkantor!~kkantor@c-24-118-59-107.hsd1.mn.comcast.net> has joined #illumos
[12:32:12] *** jimklimov <jimklimov!~jimklimov@ip-86-49-243-242.net.upcbroadband.cz> has joined #illumos
[12:35:58] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has quit IRC (Ping timeout: 268 seconds)
[12:38:41] *** deejam <deejam!deejam@irc.nathanic.org> has joined #illumos
[12:40:15] *** eau <eau!~eau@unaffiliated/eau> has joined #illumos
[12:40:35] *** yomisei <yomisei!~void@ip4d16bf2b.dynamic.kabel-deutschland.de> has joined #illumos
[12:54:41] *** eki <eki!~eki@dsl-hkibng41-567327-143.dhcp.inet.fi> has quit IRC (Quit: leaving)
[12:57:46] <gitomat> [illumos-gate] 11585 ::scalehrtime could be more precise -- Bryan Cantrill <bryan at joyent dot com>
[13:01:14] *** eki <eki!~eki@dsl-hkibng41-567327-143.dhcp.inet.fi> has joined #illumos
[13:24:13] *** merzo <merzo!~merzo@> has quit IRC (Ping timeout: 245 seconds)
[13:25:49] *** merzo <merzo!~merzo@> has joined #illumos
[13:41:51] <jlevon> good news so far on -fno-shrink-wrap
[13:43:23] <tsoome> there is some light afterall?:)
[13:43:45] <jlevon> gcc is still a little cheeky tbh
[13:59:29] *** wonko <wonko!~quassel@2600:1700:5ee7:1c80::6d2> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
[14:12:45] *** wonko <wonko!~quassel@2600:1700:5ee7:1c80::6d2> has joined #illumos
[14:21:00] <sjorge> Is there a way to query our smbsrv implementation for current open connections and locks?
[14:21:06] <sjorge> like smbstatus does fro samb?
[14:21:26] <sjorge> jlevon I just read your last message in the most brittish accent my brain could pull of :/
[14:27:19] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[14:29:16] <jlevon> sjorge: I dread to think
[14:56:53] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[15:14:43] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has quit IRC (Ping timeout: 246 seconds)
[15:16:01] *** wl_ <wl_!~wl_@cpe-108-167-5-46.neb.res.rr.com> has joined #illumos
[15:20:06] *** phyre__ <phyre__!~phyre___@> has joined #illumos
[15:49:12] <andyf> jlevon why not come to FOSDEM next year and sjorge can stop imagining
[15:49:58] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has joined #illumos
[15:50:12] <jlevon> yeah maybe
[15:58:23] <jbk> heh
[15:58:46] <andyf> I'll just keep imagining a Manchester accent
[16:01:12] <jbk> it's funny given how much smaller great britain is compared to north america, yet it has far more accents that are far more distinct than the ones in the US & Canada
[16:02:12] <jlevon> andyf: well I'm a tyke but I don't sound like a yorkshire man either. probably.
[16:04:11] <andyf> jlevon, I live in Yorkshire but am from the North East.. lost most of my accent though
[16:04:35] <jlevon> ah another county traitor
[16:04:51] <andyf> No roses involved for me though :p
[16:04:56] <jlevon> yeah I'm worse
[16:08:52] <andyf> jbk - it keeps people guessing. I once went to an Irish bar in Washington that was staffed entirely by Scottish staff.. they said that the locals can't tell
[16:09:09] <jlevon> heh
[16:10:15] <jbk> oh i'm sure they can't
[16:11:14] <jbk> at my first job, one of my coworkers was from Rhodesia (hasn't changed names before he moved)... _no_ one could ever place his accent
[16:13:08] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Ping timeout: 258 seconds)
[16:13:36] *** wonko <wonko!~quassel@2600:1700:5ee7:1c80::6d2> has quit IRC (Quit: No Ping reply in 180 seconds.)
[16:14:54] *** wonko <wonko!~quassel@2600:1700:5ee7:1c80::6d2> has joined #illumos
[16:15:19] <jbk> which was rather amusing to us
[16:16:12] <jbk> customers though he was British, Australian, etc.
[16:16:27] <andyf> I can understand that :)
[16:17:12] <andyf> You have a distinctive accent, which reminds me I need to listen to the August OpenZFS call
[16:18:18] <jbk> heh.. some of my friends around here like to tease me about it (and not even over my lack of use of 'yall' or 'all yall' :P)
[16:24:45] <jbk> which usually prompts me to deliberately over-exaggerate it and sound like one of the super fans :)
[16:28:13] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[16:33:11] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[16:33:37] <Kurlon> Bootloader broke fully on my test box, bah.
[16:37:52] *** papertigers <papertigers!~papertige@pool-72-75-249-69.bflony.fios.verizon.net> has joined #illumos
[16:43:24] *** kamog <kamog!~kamog@> has joined #illumos
[16:46:33] *** gwr <gwr!~gwr@> has joined #illumos
[16:59:12] *** jimklimov <jimklimov!~jimklimov@ip-86-49-243-242.net.upcbroadband.cz> has quit IRC (Quit: Leaving.)
[17:11:39] *** daleg <daleg!~daleg@pool-173-73-232-244.washdc.fios.verizon.net> has quit IRC ()
[17:26:05] *** gwr <gwr!~gwr@> has quit IRC (Quit: This computer has gone to sleep)
[17:34:31] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[17:47:49] <richlowe> andyf: was it the bar with the surprisingly varied scarf collection?
[17:49:16] <richlowe> jlevon: a little cheeky how?
[17:49:50] <jlevon> still putting stuff before the prologue
[17:49:57] <jlevon> just, hopefully, nothing that matters much
[17:50:12] <richlowe> well, that's still going to upset dtrace?
[17:50:30] <jlevon> no
[17:50:36] <jlevon> no branches
[17:50:52] <jlevon> and, from the spot checks I did, nothing that would break args[] either (which makes sense)
[17:51:03] <richlowe> and fbt:::entry is fine with not being at sym+0?
[17:51:48] <jlevon> yes
[17:52:13] <jlevon> I don't remember that code being like that, but it is, and was
[17:54:23] *** gwr <gwr!~gwr@> has joined #illumos
[17:56:02] *** KungFuJesus <KungFuJesus!~adamstyli@> has joined #illumos
[17:56:19] <KungFuJesus> how long before we see the vectorized checksum and parity calculations in Illumos' ZFS?
[17:59:09] <richlowe> I mean, the obvious answer if you want it soon is to do it?
[18:07:23] <KungFuJesus> probably - does illumos have a an API access vector registers in the kernel safely?
[18:07:36] <KungFuJesus> s/a//g
[18:07:43] <jbk> not currently, but I thought there was some work to create an api for doing so
[18:08:11] <KungFuJesus> FreeBSD does, it's needed to use AES-NI
[18:08:58] <jbk> though even there, we'd probably want to think about the implementation -- e.g. using AVX512 can cause undesired impacts on other things running
[18:10:38] <richlowe> In the places we do it, we do it by hand.
[18:10:48] <richlowe> rmustacc was looking at fixing that to be better
[18:10:51] <richlowe> but doing it by hand is still possible
[18:11:18] *** Yogurt <Yogurt!~Yogurt@c-73-189-45-147.hsd1.ca.comcast.net> has joined #illumos
[18:11:35] <tsoome> we do need that API anyhow for other purposes too
[18:11:46] <tsoome> so it is only question of time….
[18:15:22] <richlowe> Sure, I'm not against it at all, just saying I don't think there's a need to wait for it
[18:23:58] *** man_u <man_u!~manu@manu2.gandi.net> has quit IRC (Quit: man_u)
[18:33:36] *** jzu_ <jzu_!~jussi@pupu.jus.si> has quit IRC (Quit: moimoi)
[18:35:54] *** jzu_ <jzu_!~jussi@pupu.jus.si> has joined #illumos
[18:37:25] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 244 seconds)
[18:53:18] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[19:10:43] <KungFuJesus> For some CPUs, the clock cycle penalty for AVX512 is not nearly as bad (e.g. the HEDT CPUs)
[19:11:31] <KungFuJesus> from the looks of it, the impact is pretty massive for RAIDZ3: http://wiki.lustre.org/images/a/a1/LUG2016D1_Vectorized-ZFS-RAIDZ_Gvozden-Neskovic.pdf
[19:23:36] <gitomat> [illumos-gate] 11538 i86pc: unix should always build dboot as 32-bit -- Toomas Soome <tsoome at me dot com>
[19:57:45] *** kamog <kamog!~kamog@> has left #illumos
[20:07:17] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC ()
[20:07:27] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[20:08:04] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Client Quit)
[20:08:13] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[20:08:51] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Client Quit)
[20:09:02] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[20:09:39] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Client Quit)
[20:09:51] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[20:10:26] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Client Quit)
[20:10:36] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[20:10:57] *** Teknix <Teknix!~pds@> has quit IRC (Read error: No route to host)
[20:11:14] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Client Quit)
[20:11:24] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[20:12:02] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Client Quit)
[20:12:12] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[20:12:49] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Client Quit)
[20:13:06] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has joined #illumos
[20:13:36] *** _alhazred <_alhazred!~Alex@mobile-access-bcee0a-247.dhcp.inet.fi> has quit IRC (Client Quit)
[20:17:29] *** Teknix <Teknix!~pds@> has joined #illumos
[20:30:02] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Ping timeout: 245 seconds)
[20:39:13] *** phyre__ <phyre__!~phyre___@> has quit IRC (Ping timeout: 245 seconds)
[20:43:48] *** wacki <wacki!~wacki@i577B851D.versanet.de> has joined #illumos
[20:44:22] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Remote host closed the connection)
[20:54:11] *** Yogurt <Yogurt!~Yogurt@c-73-189-45-147.hsd1.ca.comcast.net> has quit IRC (Remote host closed the connection)
[21:05:01] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[21:09:42] *** Yogurt <Yogurt!~Yogurt@c-73-189-45-147.hsd1.ca.comcast.net> has joined #illumos
[21:13:58] *** Yogurt <Yogurt!~Yogurt@c-73-189-45-147.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 244 seconds)
[21:18:00] *** jellydonut <jellydonut!~quassel@s91904426.blix.com> has quit IRC (Quit: jellydonut)
[21:23:14] *** gwr <gwr!~gwr@> has quit IRC (Quit: This computer has gone to sleep)
[21:28:22] *** gwr <gwr!~gwr@> has joined #illumos
[21:33:45] <KungFuJesus> is the dnlc on the server leveraged by NFS clients, or is that something that the NFS clients maintain themselves?
[21:42:16] <jbk> i thought the dnls was global (i.e. for the entire filesystem name space on the system)
[21:42:21] <jbk> but i could be mistaken
[21:44:24] <KungFuJesus> yeah but I thought NFS presented vnodes at the VFS layer, and the clients maintained their own name cache. I could be wrong about that, htough
[21:47:01] <KungFuJesus> though*
[21:47:02] *** wacki <wacki!~wacki@i577B851D.versanet.de> has left #illumos
[21:56:55] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[22:20:01] *** ed209 <ed209!~ed209@> has quit IRC (Remote host closed the connection)
[22:20:08] *** ed209 <ed209!~ed209@> has joined #illumos
[22:20:44] *** jlinnosa <jlinnosa!~jsl@mustakaapu.kyla.fi> has quit IRC (Quit: leaving)
[22:26:06] <jeffpc> IIRC, dnlc is global
[22:26:10] <jeffpc> and optional
[22:26:16] <jeffpc> so, a fs doesn't have to use it
[22:26:47] <jeffpc> but it'd be kinda silly not to use it
[22:40:21] <KungFuJesus> tsoome: https://github.com/illumos/illumos-gate/commit/9e59ac1c9bffd2ba0d7192da3c5f7d1c3444991a did this recompile the bootloader as 32 bit?
[22:40:52] <KungFuJesus> would you have any reason to believe a reboot following an image-update with pkg would hang on the bootloader with the spinning cursor because of this?
[22:41:02] <KungFuJesus> I'm getting a blinking cursor, but it stopped spinning, watching it over IPMI
[22:41:46] <tsoome> this is kernel
[22:42:07] <tsoome> also, bios bootloader is only 32-bit
[22:42:21] <KungFuJesus> https://imgur.com/a/dWajABn
[22:42:32] <KungFuJesus> hmm, them I'm really not certain what's going on here
[22:42:59] <KungFuJesus> went from 3ee4fc2aa6 to latest
[22:43:35] <tsoome> um, it fails to stop counting disks
[22:43:47] <tsoome> but why…
[22:43:56] <KungFuJesus> there are exactly 24 disks
[22:44:03] <KungFuJesus> well 25, but it's zero indexed
[22:44:17] <tsoome> lik, there actually are?
[22:44:20] <tsoome> like*
[22:44:21] <KungFuJesus> yes
[22:44:24] <tsoome> ou
[22:44:38] <KungFuJesus> they're connected to a multipathed backplane
[22:44:51] <jeffpc> heh, that's always fun
[22:45:35] <KungFuJesus> :(, crap, it's like an hour drive away and I'm about to hit labor day weekend. It's not a production system but it's going to be something we're going to be doing a ton of testing on come tuesday
[22:47:00] <tsoome> there are no loader updates since 3ee4fc2aa6
[22:47:22] <tsoome> 3ee4fc2aa6 is 11552 Want a more modern nawk(1) right?
[22:47:28] <KungFuJesus> hmmmm
[22:47:56] <KungFuJesus> yes
[22:48:00] <tsoome> reboot not resetting the system properly?
[22:48:08] <tsoome> bios update?
[22:48:24] <KungFuJesus> I haven't updated the BIOS, I can try
[22:48:33] <KungFuJesus> I mean, it rebooted cleanly, just didn't come back up cleanly
[22:49:01] <tsoome> layout of rpool?
[22:49:07] <KungFuJesus> single nvme disk
[22:49:49] <KungFuJesus> (970 Evo)
[22:49:54] <tsoome> I’d test reset/power cycle
[22:53:24] <KungFuJesus> looks like BIOS and firmware is on the latest
[22:54:56] <tsoome> uefi boot?
[22:54:59] <KungFuJesus> yes
[22:55:52] <tsoome> in that case, I’d check uefi boot and avoid bios:)
[22:56:27] <KungFuJesus> oh wait, bootloader does both with an MBR compatibility shim?
[22:56:50] <tsoome> your instance is bios version:)
[22:57:23] <KungFuJesus> right, but if I tell it to try to boot as UEFI, will it work in a hybrid fashion?
[22:57:30] <tsoome> but for uefi boot you need to copy /boot/loader64.efi to ESP /assuming you havve ESP/
[22:57:57] <tsoome> no, no hybrid, the binaries are different
[23:00:15] <KungFuJesus> :-/. How would I attempt to fix this come tuesday?
[23:00:46] <tsoome> what distro is it?
[23:00:53] <KungFuJesus> openindiana hipster
[23:01:01] <tsoome> recent install?
[23:01:04] <KungFuJesus> yes
[23:01:20] <tsoome> then it likely has ESP, just without pcfs
[23:01:57] <KungFuJesus> if it's not FAT, then what will it be?
[23:02:03] <tsoome> mkfs -F pcfs -o fat=32 /dev/rdsk/cXtYd0s0
[23:02:12] <tsoome> just blank
[23:02:41] <tsoome> it may be there is already fs on it:)
[23:03:08] <tsoome> cant recall if installer will create it or not
[23:04:36] <KungFuJesus> then simply copy the bootloader to that partition and it should be bootable?
[23:04:58] *** merzo <merzo!~merzo@> has quit IRC (Ping timeout: 268 seconds)
[23:05:26] <tsoome> no, mount it, then mkdir <mntpnt>/efi/boot, and cp /boot/loader64.efi <mntpnt>/efi/boot/bootx64.efi
[23:07:01] <KungFuJesus> ok, I'll try that first and see where it gets me
[23:07:28] <tsoome> we do not do secure boot, so it needs to be switched off.
[23:07:33] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 245 seconds)
[23:07:41] <KungFuJesus> yeah I think that's off by default with this board
[23:11:06] <tsoome> of course it would be nice to know what it is doing there, but it is pita to debug remote host
[23:18:57] <KungFuJesus> tsoome: ahhh you know this might have been my first reboot since a zpool upgrade rpool
[23:32:07] *** neirac <neirac!~cneir@> has joined #illumos
[23:38:13] *** gwr <gwr!~gwr@> has quit IRC (Quit: This computer has gone to sleep)
[23:38:31] <KungFuJesus> tsoome: any reason to believe a zpool upgrade between 04/09 (the installed rpool) and the latest would cause a boot failure?
[23:38:57] *** gwr <gwr!~gwr@> has joined #illumos
[23:39:07] <KungFuJesus> sorry, 04/19
[23:39:39] <KungFuJesus> I'm trying the same thing in a VM to see if I can reproduce the issue
[23:47:40] *** rzezeski <rzezeski!uid151901@gateway/web/irccloud.com/x-jlprvmliwcaizhem> has quit IRC (Quit: Connection closed for inactivity)
[23:50:36] *** gwr <gwr!~gwr@> has quit IRC (Quit: This computer has gone to sleep)
[23:54:08] *** merzo <merzo!~merzo@212-37-133-95.pool.ukrtel.net> has joined #illumos

   August 30, 2019  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >