From mboxrd@z Thu Jan 1 00:00:00 1970 From: victor.kamensky@linaro.org (Victor Kamensky) Date: Sat, 13 Sep 2014 09:55:20 -0700 Subject: [PATCH V3] arm: fix get_user BE behavior for target variable with size of 8 bytes In-Reply-To: <20140913081642.GS12361@n2100.arm.linux.org.uk> References: <1409291466-4064-1-git-send-email-victor.kamensky@linaro.org> <1409291466-4064-2-git-send-email-victor.kamensky@linaro.org> <20140913081642.GS12361@n2100.arm.linux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Russell, I am looking into it. Thanks, Victor On 13 September 2014 01:16, Russell King - ARM Linux wrote: > On Thu, Aug 28, 2014 at 10:51:06PM -0700, Victor Kamensky wrote: >> e38361d 'ARM: 8091/2: add get_user() support for 8 byte types' commit >> broke V7 BE get_user call when target var size is 64 bit, but '*ptr' size >> is 32 bit or smaller. e38361d changed type of __r2 from 'register >> unsigned long' to 'register typeof(x) __r2 asm("r2")' i.e before the change >> even when target variable size was 64 bit, __r2 was still 32 bit. >> But after e38361d commit, for target var of 64 bit size, __r2 became 64 >> bit and now it should occupy 2 registers r2, and r3. The issue in BE case >> that r3 register is least significant word of __r2 and r2 register is most >> significant word of __r2. But __get_user_4 still copies result into r2 (most >> significant word of __r2). Subsequent code copies from __r2 into x, but >> for situation described it will pick up only garbage from r3 register. >> >> Special __get_user_64t_(124) functions are introduced. They are similar to >> corresponding __get_user_(124) function but result stored in r3 register >> (lsw in case of 64 bit __r2 in BE image). Those function are used by >> get_user macro in case of BE and target var size is 64bit. >> >> Also changed __get_user_lo8 name into __get_user_32t_8 to get consistent >> naming accross all cases. >> >> Signed-off-by: Victor Kamensky >> Suggested-by: Daniel Thompson >> Reviewed-by: Daniel Thompson > > This patch isn't quite right, since it causes compile regressions: > > ERROR: "__get_user_64t_4" [fs/ext4/ext4.ko] undefined! > ERROR: "__get_user_64t_4" [fs/cifs/cifs.ko] undefined! > > This was noticed by Olof's builder, with his allmodconfig. I don't > have the configuration to reproduce these failures. > > Could you look into these please? > > -- > FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up > according to speedtest.net.