I left this nullfd test here for you to see, but as my comment above suggests, I'm inclined to remove it. It is not a reliable test. I would need some some sort of /dev/foo for which non-root mmap works.

I suppose I could add a test that used /dev/mem and was skipped if the open failed due to not being root? This would at least test when run as root. Not sure if the automated tests under jenkins run as root or a mere mortal though.

I used this test to verify that my recent fix for /dev/zero preserved existing behavior for the MAP_SHARED case. This failed in a pre-fo_mmap kernel and now still fails after the recent change.

FWIW, MAP_SHARED mappings of a read/write /dev/zero fd have the same behavior. Not sure if that is a feature we should test for or just due to the implementation being simple.

Somewhat complicated suggestion is to check whether you really get a private mapping, i.e. zero pages even if other mapping wrote something.

Oh, I found the test below.

Might be, consider /dev/devstat ? I did not checked it actually.

I see. This is the feature, and since you test for the behaviour of the private mapping, the shared mapping could be easily handled.

FWIW, MAP_SHARED mappings of a read/write /dev/zero fd have the same behavior.

I'm confused by this statement. It's the same behavior as what?

Does the mapping of /dev/zero ever behave differently from MAP_ANON?

Well, the behaviour is weird for something with mmap(fd) where fd != -1. Every new mapping gets zero content, and flags only define future sharing mode. This is in contrast of other anonymous memory, like posix shm fd.

Yes, mmap("/dev/zero") is defned to behave as mmap(MAP_ANON), but sometimes caller of mmap cannot tell since it is defined by fd.