[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKFsvULfrFC_t4CJN5evwu3EnbzbVF1UGs30uHc1Jad-Sd=s9Q@mail.gmail.com>
Date: Thu, 13 Feb 2020 16:54:41 -0800
From: Patricia Alfonso <trishalfonso@...gle.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: Jeff Dike <jdike@...toit.com>, Richard Weinberger <richard@....at>,
anton.ivanov@...bridgegreys.com,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
David Gow <davidgow@...gle.com>,
Brendan Higgins <brendanhiggins@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>, linux-um@...ts.infradead.org
Subject: Re: [RFC PATCH v2] UML: add support for KASAN under x86_64
> Well I had two patches:
> (1) the module constructors one - I guess we need to test it, but you
> can include it here if you like. I'm kinda swamped with other
> things right now, no promises I can actually test it soon, though I
> really do want to because that's the case I need :)
> (2) the [DEMO] patch - you should just take the few lines you need from
> that (in the linker script) and stick it into this patch. Don't
> even credit me for that, I only wrote it as a patch instead of a
> normal text email reply because I couldn't figure out how to word
> things in an understandable way...
>
> Then we end up with 2 patches again, the (1) and your KASAN one. There's
> no point in keeping the [DEMO] separate, and
>
Okay, so I'll rebase onto (1) and just add the lines I need from the
[DEMO]. Are you sure you don't want to be named as a co-developed-by
at least?
>
> > > > + if (mmap(start,
> > > > + len,
> > > > + PROT_READ|PROT_WRITE,
> > > > + MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE|MAP_NORESERVE,
> > > > + -1,
> > > > + 0) == MAP_FAILED)
> > > > + os_info("Couldn't allocate shadow memory %s", strerror(errno));
> > >
> > > If that fails, can we even continue?
> > >
> > Probably not, but with this executing before main(), what is the best
> > way to have an error occur? Or maybe there's a way we can just
> > continue without KASAN enabled and print to the console that KASAN
> > failed to initialize?
>
> You can always "exit(17)" or something.
>
> I'm not sure you can continue without KASAN?
>
> Arguably it's better to fail loudly anyway if something as simple as the
> mmap() here fails - after all, that probably means the KASAN offset in
> Kconfig needs to be adjusted?
>
> johannes
>
Yeah, failing loudly does seem to be the best option here.
--
Patricia Alfonso
Powered by blists - more mailing lists