<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 25, 2022 at 2:00 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/25/22 14:58, enh wrote:<br>
> On Tue, Jul 19, 2022 at 6:34 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
>     >     Good suggestion, but I'm never sure what actually _is_ easy. I shelved<br>
>     this<br>
>     >     after doing about half of mp3 identification, which turns out to be a<br>
>     >     surprisingly large rathole due to funky container formats. (And I<br>
>     don't trust<br>
>     >     anything microsoft's ever touched not to be turing-complete to solve...)<br>
>     ><br>
>     > heh, i know exactly what you mean because (a) i have this problem all the time<br>
>     > at work, where people don't finish their "starter project" for years and (b)<br>
>     > your specific jpeg size example was one _i_ punted when i originally submitted<br>
>     > jpeg support because it turned out to be non-obvious.<br>
> <br>
>     The problem with "leaving easy stuff for other people to do" is they don't do<br>
>     it. I submitted a series of updated patches to make the kernel's<br>
>     CONFIG_DEVTMPFS_MOUNT work for initramfs and not just the fallback root= mount,<br>
>     and nobody else ever picked that up and put it in.<br>
> <br>
>     <a href="https://lkml.org/lkml/2017/9/13/651" rel="noreferrer" target="_blank">https://lkml.org/lkml/2017/9/13/651</a> <<a href="https://lkml.org/lkml/2017/9/13/651" rel="noreferrer" target="_blank">https://lkml.org/lkml/2017/9/13/651</a>><br>
> <br>
>     That seems quite easy, no? Here it is again 3 years later...<br>
> <br>
>     <a href="https://lkml.iu.edu/hypermail/linux/kernel/2005.1/09399.html" rel="noreferrer" target="_blank">https://lkml.iu.edu/hypermail/linux/kernel/2005.1/09399.html</a><br>
> <br>
>     There's a type of salesmanship in getting Huck Finn's friends to paint his fence<br>
>     which is a completely different skillset from doing the work yourself. It's a<br>
>     quite useful skill I do not have.<br>
> <br>
> yeah, but at the same time we do get people asking "is there something i can do<br>
> to help?", and having a pile of fences to paint eases that.<br>
<br>
I am terrible at maintaining such piles. :)<br>
<br>
(If it looks simple and I haven't already done it, generally there's some subtle<br>
sharp edge. Doesn't mean it was a SIGNIFICANT problem, just what made me put it<br>
down where a drift of papers blew over it...)<br>
<br>
>     > i still think this is the "least worst" option though, and that's actually one<br>
>     > reason why i suggested a separate bug for each: it lets people thrash about a<br>
>     > bit until they find one that _is_ easy (for them).<br>
> <br>
>     People have been trying to get me to do more with bug trackers for a larger<br>
>     number of years than I like to think about.<br>
> <br>
>     There's a whole lot of years of unmedicated ADHD tangled up in there. I use them<br>
>     when somebody ELSE manages them and regularly reviews what's been sitting there<br>
>     composting. <br>
> <br>
> yeah, sorry for not having stayed on top of that after the last time you<br>
> mentioned it was an issue. i've been through just now and closed out the stuff<br>
> where we think it's fixed (but haven't heard back) or you've said you're not<br>
> going to do the thing (such as move README to markdown).<br>
<br>
Thanks. I reopened two of them. :)<br>
<br>
>     My objection to ASAN is I'm not yet convinced it ISN'T a false positive<br>
>     generator, although I should give it a closer look. (My first encounter with it<br>
>     being commit 472599b99bec is a contributing factor here.)<br>
> <br>
>     > with one of your diff.c changes. i've sent a patch (and a separate patch<br>
>     to add<br>
>     > that -Werror= to the default toybox configure, since that's one we always have<br>
>     > to fix in the end anyway; may as well catch them fresh?).<br>
> <br>
>     I agree I should hit the false positives before you hit the false positives.<br>
> <br>
>     I need something like a ./testy.sh script that builds with the NDK (ASAN<br>
>     enabled) and runs the test suite... which involves getting the test suite to<br>
>     pass when built with the NDK. Working on it, I'll try to go faster and see if I<br>
>     can reshuffle the priorities a bit. I have been accused of trying to boil the<br>
>     ocean on more than one occasion...<br>
> <br>
> yeah, though i think asan by default is a great idea, i think the NDK only adds<br>
> to your problems with no real benefit.<br>
<br>
I added ASAN=1 to the llwrap script I did building with NDK, but as I mentioned<br>
in the github comment I need to fix passwd.c now the compile time probe isn't<br>
skipping it. (There's no reason to use the "shadow" functions if I've got direct<br>
/etc/passwd reading logic in lib anyway, I just hadn't finished converting stuff<br>
over. I've got a large patch in a tree here for that, and promoting a half dozen<br>
toys/pending/useradd.c variants as part of it, but that's DEFINITELY something<br>
to test under mkroot and it's queued up behind getting mkroot to run the test<br>
suite...)<br>
<br>
> my point with asan is that any C<br>
> programmer should probably just run with that on all the time.<br>
<br>
This promise was made by like 15 different address sanitizer packages over the<br>
years, from "electric fence" through the bounds checker built into tinycc, and I<br>
broke every one I tried. But if this one's different...<br></blockquote><div><br></div><div>it catches a lot more than those tools (because it instruments reads and writes; it's closer to valgrind than to them), and it's fast enough that we *do* run with it on all the time. we run all the Android tests (CTS and ad hoc like the toybox tests) under asan (x86-64) and hwasan (arm64, but hopefully "coming soon" for x86-64 with intel's Linear Address Masking and whatever amd's equivalent is called).</div><div><br></div><div>so even if you do manage to break it ... we'll need to work around that at some point before we can sync AOSP anyway. (and i know the folks who invented and maintain asan, so i'm not worried even if you do find anything.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(I still have "set up valgrind" on my todo list, </blockquote><div><br></div><div>valgrind never really worked on Android, and upstream were terrible about taking patches so i just gave up.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and need a memory leak detector<br>
for toysh when that's ready to promote. </blockquote><div><br></div><div>asan's that too (unless you tell it not to be). like i said: no C/C++ programmer should be without it :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That's a long running thing where I need<br>
to see if I've missed any allocation lifetimes after running real world scripts<br>
through it. I can police filehandles via /proc/self/fds but not heap objects...)<br></blockquote><div><br></div><div>(fwiw, bionic has an fdsan/fdtrack system for this kind of thing, but it's not on for "random executables" by default. well, fd*san* is, but that's correctness not leaks. fdtrack is only enabled in system_server, aka "the giant monolith" which suffers most from a tragedy of the commons as far as leaks are concerned.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> it's great at<br>
> catching memory errors early and it's pretty damn cheap on x86-64 --- unless i'm<br>
> benchmarking i run most stuff under asan most of the time. (and toybox doesn't<br>
> have a lot of Android-only code, so it's unlikely that we'd get significantly<br>
> better coverage from building with the NDK, and the *platform* is always ahead<br>
> of the NDK anyway, so "builds with the NDK" isn't as strong a guarantee as you<br>
> might think, even ignoring the fact that if you _do_ build with the NDK, we<br>
> don't actually build the Android-specific stuff in exactly the same way.)<br>
<br>
Oh sure. I've just never managed to build with the AOSP toolchain outside of<br>
AOSP, so the NDK is the closest thing I've got. (The only musl+llvm toolchain I<br>
have is that hexagon cross compiler...)<br></blockquote><div><br></div><div>again, don't worry about it --- if you want to do something, build with gcc and clang. it's not common that we have "our clang is so new that..." issues, and it's likely we can test and send you patches in less time than you'd have wasted doing "mostly fine" NDK builds.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Alas, AOSP hasn't got an obvious mkroot equivalent where I can get JUST build a<br>
quick boot to shell prompt test. It's "set that thing running and go to lunch"<br>
territory, and not something you can usefully do on battery either...<br></blockquote><div><br></div><div>yeah, _that's_ a bit more of a loss. but tbh you can probably fake most of our differences by just being in a chroot with /bin/sh pointing to mksh :-)</div><div><br></div><div>if that was where you were going with your question about "what filesystems are allowed?", i can try harder to get a canonical answer (or at least just tell you what we're currently using on Pixel and/or cuttlefish!).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>