2019-04-14 21:33:56 |
Christian Brauner |
bug |
|
|
added bug |
2019-04-14 21:34:21 |
Christian Brauner |
linux (Ubuntu): assignee |
|
Christian Brauner (cbrauner) |
|
2019-04-14 21:34:32 |
Christian Brauner |
linux (Ubuntu): status |
New |
In Progress |
|
2019-04-14 21:36:43 |
Christian Brauner |
description |
We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory. |
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory.
Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay.
One solution would be to start reference counting which is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called. |
|
2019-04-14 21:37:25 |
Christian Brauner |
bug |
|
|
added subscriber Seth Forshee |
2019-04-14 21:37:32 |
Christian Brauner |
bug |
|
|
added subscriber Ubuntu Containers Team |
2019-04-15 11:53:40 |
Christian Brauner |
description |
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory.
Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay.
One solution would be to start reference counting which is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called. |
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory.
Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay.
An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called.
Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below).
Test Case: Tested in the lxd CI environment where the bug was originally discovered. No regressions were seen, and the BUG statement was not hit. |
|
2019-04-15 12:21:20 |
Christian Brauner |
description |
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory.
Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay.
An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called.
Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below).
Test Case: Tested in the lxd CI environment where the bug was originally discovered. No regressions were seen, and the BUG statement was not hit. |
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory.
Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay.
An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called.
Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below). |
|
2019-04-15 13:16:13 |
Christian Brauner |
description |
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory.
Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay.
An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called.
Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below). |
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory.
Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay.
An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called.
Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below).
Test Case: Built Ubuntu Disco Kernel with patch applied from source,
installed it, ran LXD and verified that passthrough mount option now
works correctly. |
|
2019-04-15 15:44:57 |
Christian Brauner |
linux (Ubuntu): status |
In Progress |
Fix Committed |
|
2019-04-16 08:11:45 |
Launchpad Janitor |
linux (Ubuntu): status |
Fix Committed |
Fix Released |
|