Skip to content

Fix honoring tmpfs-size for user /dev/shm mount#35316

Merged
vdemeester merged 2 commits into
moby:masterfrom
kolyshkin:facepalm
Nov 14, 2017
Merged

Fix honoring tmpfs-size for user /dev/shm mount#35316
vdemeester merged 2 commits into
moby:masterfrom
kolyshkin:facepalm

Conversation

@kolyshkin
Copy link
Copy Markdown
Contributor

@kolyshkin kolyshkin commented Oct 27, 2017

- What I did
Commit 7120976 ("Implement none, private, and shareable ipc modes") introduces a bug: if a user-specified mount for /dev/shm is provided, its size is overridden by value of ShmSize. This was reported in #35271.

This commit is an attempt to fix this, as well as optimize things a but and make the code easier to read.

- How I did it
Appending the 'size' argument to /dev/shm mount options moved to an earlier place in the function, where we deal with the mounts that came from spec, therefore a user mount is left intact.

- How to verify it

There is a test case included in this PR. In addition, it can easily be checked manually:

 docker run --rm \
	--mount type=tmpfs,dst=/dev/shm,tmpfs-size=100K \
	alpine df /dev/shm

Expected output (i.e. if there is no bug):

Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                      100         0       100   0% /dev/shm

(i.e. 100 should be shown under the "1K-blocks" header)

- Description for the changelog
Fix honoring tmpfs-size for user /dev/shm mount

- A picture of a cute animal (not mandatory but encouraged)
shy-beaver
Shy beaver | Minnesota zoo (source)

@AkihiroSuda
Copy link
Copy Markdown
Member

could you add a test?

@kolyshkin
Copy link
Copy Markdown
Contributor Author

could you add a test?

What stops me is lack of client.ContainerExec functionality in integration/ tests, something similar to cli.DockerCmd("exec", ...) in integration-cli/. Guess I need to write it first.

Copy link
Copy Markdown
Member

@dnephin dnephin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to test this with a unit test instead of an integration that? The fix seems to be in a single function, so having to make multiple API calls seems like it's maybe not the easiest way to reproduce and test the issue.

@kolyshkin
Copy link
Copy Markdown
Contributor Author

@AkihiroSuda @thaJeztah I have added the test case, and made sure it is failing without the fix (and passing with the fix applied).

@kolyshkin
Copy link
Copy Markdown
Contributor Author

Would it be possible to test this with a unit test instead of an integration that?

Problem is, there's a lot of code dealing with mounts, and the setMounts() is not very isolated function. If I am to write a unit test, I have to repeat some of that code in the test case which is prone to error later if this code changes.

Anyway, let me give it a try and see what I end up with.

Commit 7120976 ("Implement none, private, and shareable ipc
modes") introduces a bug: if a user-specified mount for /dev/shm
is provided, its size is overriden by value of ShmSize.

A reproducer is simple:

 docker run --rm
	--mount type=tmpfs,dst=/dev/shm,tmpfs-size=100K \
	alpine df /dev/shm

This commit is an attempt to fix the bug, as well as optimize things
a but and make the code easier to read.

moby#35271

Signed-off-by: Kir Kolyshkin <[email protected]>
@kolyshkin
Copy link
Copy Markdown
Contributor Author

@dnephin OK, I managed to write a unit test. PTAL once time permits.

Comment thread daemon/daemon_linux_test.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is one of the few times when a plain t.Fatal() is actually the best option:

t.Fatal("size option was missing from mount")

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated to use f.Fatal()

Copy link
Copy Markdown
Member

@dnephin dnephin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, test LGTM, just one small nit

Comment thread daemon/daemon_linux_test.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is one of the few times when a plain t.Fatal() is actually the best option:

t.Fatal("size option was missing from mount")

Copy link
Copy Markdown
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🐯

@thaJeztah
Copy link
Copy Markdown
Member

Looks good, but haven't given it a spin yet; let me check if the --tmpfs /dev/shm:rw,nosuid,nodev,size=8 option (more options other than just size) works as expected.

@vieux
Copy link
Copy Markdown
Contributor

vieux commented Nov 13, 2017

@thaJeztah let us know :D

Copy link
Copy Markdown
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doh! I see I mixed up your PR's, had the other PR (#35467) in mind when I commented.

this LGTM, thanks!

@thaJeztah
Copy link
Copy Markdown
Member

Oh, looks like there's one linting failure:

22:04:28 daemon/daemon_linux_test.go:156:5:warning: should omit comparison to bool constant, can be simplified to !found (S1002) (gosimple)
22:04:28 Build step 'Execute shell' marked build as failure

This test case is checking that the built-in default size for /dev/shm
(which is used for `--ipcmode` being `private` or `shareable`)
is not overriding the size of user-defined tmpfs mount for /dev/shm.

In other words, this is a regression test case for issue moby#35271,
moby#35271

Signed-off-by: Kir Kolyshkin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants