@delphij , @cperciva (or anybody else from security) can you please sign-off this one before it gets in?

LGTM. Colin?

looks good to me (in principle), and I like this approach. I'm not build system savvy so I'd like dim to sign-off this one.

The changes look good. I'd split them in multiple patches/commit, more or less following the structure you outlined in the summary, but thanks for sending out a single one so we can have the whole picture.
IIRC there were objections to change ticks from 32-bits to 64-bits so you may want to ask feedback from a more general audience.
Other than that, I'm fine with (a splitted version of this) getting in.

Sounds sensible.

Can't comment on license issues and related tho.

LGTM. Feel free to ship (maybe John wants to comment further as he's been touching gdb recently)

The patch looks very good to me and thanks for undertaking this effort.
About SDT I don't disagree with them but *exclusively* seems a little bit too much, lots of people rely on KTR for tracing (me included) and it seems to be a more lighweight solution than Dtrace if you need limited capabilities.

In HEAD now.

Robert,
an added (somewhat related) note.
SCTP has already its own sockbuf(s) and this makes integration very hackish in the tree. IIRC glebius experienced this himself while working on sendfile(), and I'm pretty sure rrs@ is kind of familiar with the problem. Introducing a better abstraction for sockbuf might help with this.

Mainly for consistency at this point with whatever else it's used in the stack.

I plan to commit this in two days or such, so if there are objections, please raise them.

I plan to commit this in two days or such, so if there are objections, please raise them.

Updated removing the last place where this was used. I was not certain about it before so I previously left it as-is, but it looks like in this case order doesn't matter considering we're holding the socket buffer lock across the two calls.

Drop this revision after discussion on the mailing list.

Abandoned in favour of a different approach

This looks good to me modulo mav's last round of comments.

LGTM

unsetenv is not used anywhere in the kernel -- just in the loader. As you may see the loader code was unchanged.
Do you have an alternative to handle the whole thing in your mind?

Committed (r270227)

Committed (r270221)

bde@ accepted this revision privately.

Bruce Evans reviewed this privately.
Let's copy his comment here:

committed

Updated after comments from Kostik/Robert.
Peter, do you mind to give this a spin before it gets in? I tested that a bit and found no issue -- but it would be great if the patch could be stress tested a bit more.