[illumos-gate] 17042 cxgbe leaks tx_dhdl array -- Patrick Mooney <pmooney⊙pc>

Hello. I am having an issue with gmake on illumos. Here's what's happening; I started a build using gmake on OpenIndiana (GNU Make 4.3), and ran the build side-by-side on Ubuntu (GNU Make 4.3, also). Ubuntu proceeds with the build, while OI returns an error "Badly formed macro assignment". I looked the Makefile and the first error was on a line

showing *VALUE ?= $(VALUE)*. I changed this to *VALUE = $(VALUE)* and it proceeds to the next line with a *?=*. Changing the whole file like this passes and the Makefile runs... I can't find anything that would suggest this discrepancy in behavior online. Has anyone else ran into this issue?

are you sure you're running GNU make and not Solaris make? because that sounds like what Solaris make would do if given a GNU makefile

you don't have $MAKE set anywhere do you?

Yes, illumos make doesn't support ?=, and would print that message if it saw it

Yes, I am using gmake. $MAKE is not set

so somehow it's run our make and not gmake

that often happens if someone wrote a recursively makefile, but called 'make' for the subdirectories, not $(MAKE)

oh yeah, good point

the easiest workaround on openindiana is probably to put /usr/gnu/bin first in your path, while running the make

Thanks alanc richlowe

This appears to be the case. I put /usr/gnu/bin first in the path and there's no more Makefile error

hrm...

it looks like a lot of our section 1 man pages include paths, while most everyone else I've checked does not

aside from instances where it matters (e.g. xpg4/6 versions), do we care?

(e.g. the usual use of mandoc you'll end up without it since it uses the .Nm value from the name section for the rest of the man page

jbk: I think we qualify the path when the program is [a] not in /usr/bin, or [b] there is more than one program (e.g., an xpg4 and a regular variant), or [c] there is a shell built-in and an actual program

so, e.g., there are paths in ls(1), but not in grep(1) any longer since unification

There might be some outliers that get qualified anyway, but I suppose one could argue those could become unqualified, as long as there is only one program and it's in /usr/bin

[illumos-gate] 17062 kernel thinks lwp0 has a usable FPU save area when it doesn't -- Andy Fiddaman <illumos⊙fn>

Good evening. Did we recently (between February 2024 and now) change the default brand permissions? My Zone now gets EACCESS to /def/ipf

Good evening. Did we recently (between February 2024 and now) change the default brand permissions? My Zone now gets EACCESS to /dev/ipf

or could that be drift between the zone and host?

I don't remember anything changing there.

ppriv debugging might give more specific information about missing privileges (ppriv -e -D $cmd)

I usually use GZ-managed firewall for my zones these days, but I'm pretty sure you can combine both.

andyf well the GZ is the router for all but the Zones have public IP's

at least some NAT zones do

sommerfeld that just gets me 'Permission denied setting zone: /etc/ipf/ipf.conf'

You can still create a set of GZ-managed ipf rules for a zone, with `ipf -G<zone>` - they aren't visible from within the zone so it's good for ones that are less trusted. The zone can define its own set on top of that. Not related to your problem, I don't know what's happening there.

so if I load the rules with -Gzone it would load the into the zone?

They're two separate things, the rules controlled by the GZ and the rules controlled by the zone itself.

"into the zone" isn't really a thing there

Does truss show anything, which system call is returning EPERM?

ioctl(4, _IOWRN('r', 97, 68), 0x004238E0)       Err#13 EACCES

Which is just after open("/dev/ipf", O_RDWR)                        = 4

At least it means you have the device in the zone, just no permissions for some reason. Do you get the same if you try and enable the firewall? - ipf -E

andyf so host is back. ipf -E works but not -F apparently.

buuut since I have an empty firewall anyway I can just leave off the flush

`-F` complaining it can't flush rules from the GZ?

(a complete guess)

well i zlogin to the zone and then run ipf -F

danmcd: my fix for the rsync alloca() issue was a bit more extensive: RsyncProject/rsync #712 (though our official builds didn't hit it because they link against our popt package instead of the bundled copy in rsync)

the rsync problems were all in rsyncd right?

Heh heh, yeah that'll work.

Malicious servers can cause clients to send other things. There were 6 CVes.

Though that problem isn't as bad as the rsyncd side of things were.

Don't forget, unless your distro does something weird, "rsyncd" isn't a binary, you just run "rsync --daemon" or some such.

(It took me hours to get my head wrapped around that this week. :( )

yeah, I was meaning areas-of-function wise, not specifically

(precisely because it's all rsync under the hood, and hard to describe otherwise, yeah)

3.4.1 is out now btw

3.4.0 broke -H -.-

oh, I use that.

not often, but.

at least it broke it in an obvious way (the exceution fails immediately)