> On Aug. 9, 2016, 5 a.m., Avinash sridharan wrote: > > src/linux/fs.cpp, line 139 > > <https://reviews.apache.org/r/50763/diff/6/?file=1468596#file1468596line139> > > > > This still seems problematic to me. Calling std::move an object makes > > it "empty", so accessing that objects memory after calling std::move could > > cause problems. Either we should copy out entry.id before calling the > > `std::move` on entry or we should just use copy semantics here.
I admittedly don't know much about the semantics of `std::move()` other than that it is typically used as an optimization to avoid copying. I should probably look into it more before just blindly using it. Intuitively though, I can see how it would be problematic to access a variable that you just "moved" by reading from its previous reference. I've updated the code accordingly. - Kevin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50763/#review145171 ----------------------------------------------------------- On Aug. 9, 2016, 12:54 a.m., Kevin Klues wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/50763/ > ----------------------------------------------------------- > > (Updated Aug. 9, 2016, 12:54 a.m.) > > > Review request for mesos, Benjamin Mahler and Jie Yu. > > > Bugs: MESOS-5969 > https://issues.apache.org/jira/browse/MESOS-5969 > > > Repository: mesos > > > Description > ------- > > Many places in the codebase assume that the mountinfo table is sorted > according to the order: 'parent mount point < child mount point'. > > However, in some cases this may not be true if (for example), a parent > mount point (say '/') is remounted to add some extra flags to it. > When this happens, the remounted file system will appear in the > mountinfo table at the point where it was remounted. > > We actually encountered this problem in the wild for the case of '/' > being remounted after '/run' was mounted -- causing problems in the > 'NvidiaVolume' which assumes the 'parent < child' ordering. > > This commit fixes this problem by building the list of MountInfoTable > entries in sorted order when 'read()' is called. An optional flag can > be used to disable sorting produce the the original ordering. > > > Diffs > ----- > > src/linux/fs.hpp ec3b5b8cd6926b1f69ad499de1c13b989766a84e > src/linux/fs.cpp f57db80ad0d7235d47910e05d663c77e233f8228 > src/tests/containerizer/fs_tests.cpp > 4cfafad28daac6bed849992a254660117d7ff30b > > Diff: https://reviews.apache.org/r/50763/diff/ > > > Testing > ------- > > GTEST_FILTER="" make -j check > src/mesos-tests > sudo src/mesos-tests > > Appeared to have one unrelated flaky test fail: > `ResourceOffersTest.ResourcesGetReofferedAfterTaskInfoError` > Rerunning the tests a second time passed. > > > Thanks, > > Kevin Klues > >
