Assert always true condition, instead of checking for it.

In D53612#1224147, @jamie wrote:

While I prefer the version I mentioned in the inline notes (it's a little less branchy), I'm also fine with the patch as originally given.

I do not object. tmpfs_mem_avail() is too naive without or with this augmentation.

This is still a bad code. It allows two threads to race to cause rctl idea of the proc ucred to be different from the actual curproc->p_ucred.

Fix attribution. Remove two articles.

Mention scope of intent.

Add note about valid contexts.

After this goes in, I will write the documentation for buf(9) and bio(9) BIO_EXTERR. This cannot be done in the same commit, because buf/bio layout are changed by exterr, which seems to prevent the merge into the stable branches (I did not decided yet).

In D53438#1223368, @markj wrote:

In D53438#1223367, @kib wrote:

In D53438#1223362, @markj wrote:

In D53438#1223311, @kib wrote:

The actions that are prevented by atomic_load_ptr() are basically arbitrary reloads of si_drv1 at places where the tp value is needed. Epoch, being fenced by compiler membar, already disallows that.

The flow of the code is:

epoch_enter();
load si_drv1 and check it
...
load si_drv1 and use it
...
epoch_exit();

so I don't see how epoch is relevant.

epoch_enter();
load si_drv1 into p and check it
...
tp = p;
...
epoch_exit();
use tp

The code was previously written like this:

NET_EPOCH_ENTER(et);
if (dev->si_drv1 == dev) {
        NET_EPOCH_EXIT(et);
        return (ENXIO);
}
...
tp = dev->si_drv1;
TUN_LOCK(tp);
...
NET_EPOCH_EXIT();

So what happens if tp == dev and we call TUN_LOCK(tp)?

In D53438#1223362, @markj wrote:

In D53438#1223311, @kib wrote:

The actions that are prevented by atomic_load_ptr() are basically arbitrary reloads of si_drv1 at places where the tp value is needed. Epoch, being fenced by compiler membar, already disallows that.

The flow of the code is:

epoch_enter();
load si_drv1 and check it
...
load si_drv1 and use it
...
epoch_exit();

so I don't see how epoch is relevant.

The actions that are prevented by atomic_load_ptr() are basically arbitrary reloads of si_drv1 at places where the tp value is needed. Epoch, being fenced by compiler membar, already disables that.

EPOCH_ENTER_PREEMPT() should be at least as strong as compiler membarrier, and it is indeed due to use of critical enter, so I do not think that si_drv1 can be re-loaded outside the epoch region. It does not hurt of course to use explicit load_ptr().

Still, add the comment please.

Rebase

In D53537#1222227, @imp wrote:

Worth an issue 8 note in the history standards section?

In D53424#1221598, @gallatin wrote:

Is there any concern that this new use will add pressure to the sf_buf system on non-direct map platforms?

Clear TDB_USERWR under proc lock. Do it earlier.

That said, I disagree that this is a kernel bug at all.

Alan. do you plan to comment on this?

I strongly do not like this, esp the proliferation of PMAP_HAS_DMAP into MD code.

Debugged version. Worked for me with the artificial random errors returned from md(4) start_swap() on BIO_READ.