On Mon, Oct 7, 2013 at 2:53 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: > On Mon, Oct 7, 2013 at 2:14 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: >> On Mon, Oct 07, 2013 at 01:34:44PM +0200, Erik Faye-Lund wrote: >>> On Mon, Oct 7, 2013 at 10:34 AM, Thierry Reding >>> <thierry.reding@xxxxxxxxx> wrote: >>> > Rework the address table code for the host1x firewall. The previous >>> > implementation allocated a bitfield but didn't check for a valid pointer >>> > so it could potentially crash. >>> >>> I don't think it could crash. The bitmaps was allocated as a 256-bit >>> field, and the register offset gets AND'ed with 0xFF before being >>> looked up. What am I missing? >> >> The pointer returned from the allocation is never checked, so it could >> theoretically be NULL and be used regardless. >> >> Also I'm not sure that AND'ing with 0xff is the right thing to do here. > > Well, maybe not. I'm not entirely convinced it's *not*, though. > I'm sorry, I intended to fill out a bit more here before I hit send, and totally forgot. Point is, it seems only 0x00..0x4c is used (and then repeated at multiples of 0x4000 for each context, but the offsets don't have enough bits to reach that far), from looking at the TRM. So the question is really how the hardware treats writes to non-existent registers. My guess would be that they are simply not recorded, and if that's the case it doesn't matter what we do. And doing an unconditional AND is faster than doing a bit-test followed by a conditional branch. Of course, if the hardware does *not* ignore writes to non-existent register, then we might be in trouble. But for that, we'd probably want a full map of valid registers, not just saying that they aren't pointers, no? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
