On Tue, Aug 02, 2022 at 01:41:58AM +0200, Jason A. Donenfeld wrote: > Hi Thomas, > > On Mon, Aug 01, 2022 at 10:48:56PM +0200, Thomas Gleixner wrote: > > On Sun, Jul 31 2022 at 03:31, Jason A. Donenfeld wrote: > > You clearly forgot to tell people that they need a special config to > > make this compile. > > As I wrote in my patch body: > > | The actual place that has the most work to do is in all of the other > | files. Most of the vDSO shared page infrastructure is centered around > | gettimeofday, and so the main structs are all in arrays for different > | timestamp types, and attached to time namespaces, and so forth. I've > | done the best I could to add onto this in an unintrusive way, but you'll > | notice almost immediately from glancing at the code that it still needs > | some untangling work. This also only works on x86 at the moment. I could > | certainly use a hand with this part. > > So I'm not surprised other things are screwed up. This works well in my > test harness, indeed, but I imagine there are lots of fiddly bits like > that to work out. I wanted to send an RFC to elicit comments on the idea > and API before moving forward, as I have a strong sense this is one of > those "90% 10%" things, where 10% of the details take 90% of the time. > > Also, I haven't hooked up vdso32 yet. Just to add, your "special config", "defconfig" remarks and such don't strike me as very accurate. I had forgotten until a second ago that I'm actually running this on my laptop's kernel, which is a fairly normal "desktop distro" kernel with modules and lots of bloat turned on. So c'mon now... the thing does work. With that said, I've taken a stab at the various build, symbol, and timens things you pointed out (thanks for that), and that's sitting now in a branch, and will be part of a v3 if I ever post a v3: https://git.zx2c4.com/linux-rng/commit/?h=jd/vdso That pointer arithmetic around the timens stuff might not be super duper appealing; I could add a symbol and have the linker resolve its location and such. But also I wasn't keen on adding a symbol to a piece of data that's not really there. So instead I calculate that offset from the vdso_data and timens_vdso_data symbols. By the way, in writing a test for that, I thought it was interesting that CLONE_NEWTIME requires a new process, rather than just an execve. You don't want to do it immediately, because that'd involve a potentially racy remapping of the vvar pages. But at the very least it could have been done on execve, right? Since all the maps are thrown out then. Jason
