[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150501091921.GA5029@twins.programming.kicks-ass.net>
Date: Fri, 1 May 2015 11:19:21 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Palmer Dabbelt <palmer@...belt.com>
Cc: mingo@...hat.com, oleg@...hat.com, akpm@...ux-foundation.org,
richard@....at, paulmck@...ux.vnet.ibm.com, bobby.prani@...il.com,
vdavydov@...allels.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Fix a misaligned load inside ptrace_attach()
On Thu, Apr 30, 2015 at 09:19:54PM -0700, Palmer Dabbelt wrote:
> I ran across what I believe is a bug in some asm-generic code while
> working on the RISC-V Linux port. Essentially the problem is that
> wait_on_bit() takes a void *, but then perfroms long-aligned
> operation. As far as I can tell, this bug could manifest on any other
> architecture that doesn't support misaligned operations and uses this
> particular asm-generic implementation.
>
> The patch set is split into three parts:
>
> * #1 fixes the bug by making task_struct.jobctl an unsigned long,
> which ensures wait_on_bit() always ends up with a long-aligned
> argument.
>
> * #2 changes the prototype of wait_on_bit() and friends to take a
> "unsigned long *" instead of a "void *", with the intent of
> ensuring these problems don't happen again.
>
> * #3 is a bit more intrusive: it goes and changes all uses of
> task_struct.jobctl from int to long.
>
> I'm not sure if #3 has gone too far, but I think #1 and #2 are sane.
> The cost is making task_struct larger on machines where
> sizeof(long)>sizeof(int), but since it's so big already this isn't too
> much cost. I thought about making test_bit() perform byte-aligned
> accesses to avoid this cost, but since there are very similar looking
> atomic functions I thought that would be too odd.
Fair enough. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists