On Mon, Oct 19, 2020 at 05:16:51AM +0900, Stafford Horne wrote: > commit d877322bc1adcab9850732275670409e8bcca4c4 upstream > > Backport of v5.9 commit d877322bc1ad for v5.8.y and v5.4.y. > > Change in backport: > - The original commit depends on a series of sparse warning fix > patches. This patch elliminates that requirement. > > A build failure was raised by kbuild with the following error. > > drivers/android/binder.c: Assembler messages: > drivers/android/binder.c:3861: Error: unrecognized keyword/register name `l.lwz ?ap,4(r24)' > drivers/android/binder.c:3866: Error: unrecognized keyword/register name `l.addi ?ap,r0,0' > > The issue is with 64-bit get_user() calls on openrisc. I traced this to > a problem where in the internally in the get_user macros there is a cast > to long __gu_val this causes GCC to think the get_user call is 32-bit. > This binder code is really long and GCC allocates register r30, which > triggers the issue. The 64-bit get_user asm tries to get the 64-bit pair > register, which for r30 overflows the general register names and returns > the dummy register ?ap. > > The fix here is to move the temporary variables into the asm macros. We > use a 32-bit __gu_tmp for 32-bit and smaller macro and a 64-bit tmp in > the 64-bit macro. The cast in the 64-bit macro has a trick of casting > through __typeof__((x)-(x)) which avoids the below warning. This was > borrowed from riscv. > > arch/openrisc/include/asm/uaccess.h:240:8: warning: cast to pointer from integer of different size > > I tested this in a small unit test to check reading between 64-bit and > 32-bit pointers to 64-bit and 32-bit values in all combinations. Also I > ran make C=1 to confirm no new sparse warnings came up. It all looks > clean to me. > > Link: https://lore.kernel.org/lkml/202008200453.ohnhqkjQ%25lkp@xxxxxxxxx/ > Signed-off-by: Stafford Horne <shorne@xxxxxxxxx> > Reviewed-by: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> > --- > arch/openrisc/include/asm/uaccess.h | 35 ++++++++++++++++++----------- > 1 file changed, 22 insertions(+), 13 deletions(-) > Now queued up, thanks. greg k-h
