What is that you had in mind for readstr/readmem? To have it error() if
-EFAULT?
If that's the case, and assuming all the call sites expects for them to
throw, we could add memcpy_{to,from}_user_error(), sibling of the _errno()
ones.
I am not sure all the call sites are safe under throw though.On Thu, Dec 17, 2015 at 3:00 PM, Davide Libenzi <[email protected]> wrote: > OK dropping memstr(), but sigscan() is not it. > As for readstr(), currently is using memove() to write user memory. Given > that we do have now safe copy to/from memory I don't see why that should be > left as is. Especially when it's a 6 lines CL. > About the build info, yes, it is intetionally generate after a clean. > Not sure what to do there, w/out force-triggering a new compile+link every > time. > If that's OK, I can do that (maybe in a future CL). > > > On Thu, Dec 17, 2015 at 2:51 PM, Barret Rhoden <[email protected]> > wrote: > >> Hi - >> >> On 2015-12-14 at 20:28 "'Davide Libenzi' via Akaros" >> <[email protected]> wrote: >> > The new machinery create an info file like: >> > >> > KernelPath: >> > /usr/local/google/home/src/akaros/akaros/obj/kern/akaros-kernel-64b >> > Date: Mon Dec 14 20:21:26 PST 2015 >> > Host: dlibenzi.mtv.corp.google.com >> > CommitID: 769cc0c093f9c9b9f41c6387d0272e317e0e62c3 >> > >> > And stick it into the kernel ELF file. >> > The new device reads the information out into separate files (path, >> > date, host, commit). >> > This branch is based upon the devarch_msr_perf one. >> > >> > >> > >> https://github.com/dlibenzi/akaros/compare/devarch_msr_perf...dlibenzi:build_info >> >> I can take this as is, minus these two commits: >> >> c36986439eb4 ("Added memstr() API to allow to search strings in memory") >> bf1c5c99e797 ("Made readstr and consequently readmem, to use >> copy-to-user API") >> >> The first isn't needed, as discussed in another email. The latter >> isn't either, and I'd like for us to think that through more (and it's >> not a priority). >> >> There is also a minor issue with this. The commitid does not get >> updated unless you do a make clean. >> >> On Akaros: >> / $ cat \#version/commitid >> 345158006a1035496b721fb3946cc3b08839acac >> >> On Linux: >> $ git log -1 >> commit 2823074e41a98f840755bd7f396e9ed44b6df695 >> >> 345158 was an old commit. I made a new commit and ran make. >> >> The fix is probably to have the makefile detect a change in the commit >> (possibly via a hidden file, e.g. obj/kern/.commitid) and remove the >> old buildinfo.c file, triggering a rebuild. >> >> It's not a big deal for now though. If you want to fix that up now, >> let me know. o/w I can just merge what we've got, and we can fix it >> later. >> >> Barret >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Akaros" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
