Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
Hi Stefano,
[auto build test WARNING on arm/for-next]
[also build test WARNING on v4.4-rc6 next-20151222]
url:
https://github.com/0day-ci/linux/commits/Stefano-Stabellini/arm-remove-CPU_V6-and-GENERIC_ATOMIC64-build-dependencies-for-XEN/20151222-222129
base: http://repo.or.cz/linux-2.6/linux-2.6-arm.git for-next
config: arm-allmodconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
drivers/gpu/drm/exynos/exynos_drm_ipp.c: In function 'ipp_get_mem_node':
>> drivers/gpu/drm/exynos/exynos_drm_ipp.c:585:4: warning: format '%x' expects
>> argument of type 'unsigned int', but argument 4 has type 'dma_addr_t'
>> [-Wformat=]
DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%lx]\n", i,
^
--
In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/clk.h:16,
from drivers/gpu/drm/sti/sti_hqvdp.c:7:
drivers/gpu/drm/sti/sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
>> drivers/gpu/drm/sti/sti_hqvdp.c:605:3: note: in expansion of macro 'dev_dbg'
dev_dbg(hqvdp->dev, "%s Posted command:0x%x\n",
^
drivers/gpu/drm/sti/sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/gpu/drm/sti/sti_hqvdp.c:931:2: note: in expansion of macro 'dev_dbg'
dev_dbg(hqvdp->dev, "%s Posted command:0x%x\n",
^
--
In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/media/platform/soc_camera/mx3_camera.c:13:
drivers/media/platform/soc_camera/mx3_camera.c: In function
'mx3_cam_dma_done':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
>> drivers/media/platform/soc_camera/mx3_camera.c:149:2: note: in expansion of
>> macro 'dev_dbg'
dev_dbg(chan->device->dev, "callback cookie %d, active DMA 0x%08x\n",
^
drivers/media/platform/soc_camera/mx3_camera.c: In function
'mx3_videobuf_queue':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/media/platform/soc_camera/mx3_camera.c:341:2: note: in expansion of
macro 'dev_dbg'
dev_dbg(icd->parent, "Submitted cookie %d DMA 0x%08x\n",
^
drivers/media/platform/soc_camera/mx3_camera.c: In function
'mx3_videobuf_release':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: n
Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
On Tue, 22 Dec 2015, Russell King - ARM Linux wrote: > On Tue, Dec 22, 2015 at 03:45:19PM +, Stefano Stabellini wrote: > > The code builds, but of course it could not actually run on CPU_V6. But > > the use case for me is building drivers/xen/grant-table.c, which can > > only run on CPU_V7 anyway, so it is not a problem. > > What I'm concerned about in this case is if you try to use instructions > which are not supported by the CPU, even in assembly, the assembler > will barf. > > So, if we're building an ARMv6 + ARMv7 kernel, and you try to use > LDREXB in generic code, even though you may intend it to only be > executed on ARMv7, the assembler will error out. > > We used to be able to work around that by passing -Wa,-march=armv7 > to the compiler for specific files, which would then tell the assembler > to accept ARMv7 instructions, but modern GCC output .arch pseudo-ops > which override the command line. So now the only way to do it is to > override the assemblers selected archtecture using .arch pseudo-ops > in the assembly code. > > So, what I'm saying is that dropping the !ARMv6 dependency is not as > simple as it would seem, and I'm nervous about including any such > patches this close to Christmas and the merge window. Sure, that's understandable. Merge window aside, do you think that for the future it might be better to change approach and write a Xen specific implementation of sync_cmpxchg? Like this older patch tried to do http://marc.info/?l=linux-arm-kernel&m=138436406724990&w=2 ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
On Tue, Dec 22, 2015 at 03:45:19PM +, Stefano Stabellini wrote: > The code builds, but of course it could not actually run on CPU_V6. But > the use case for me is building drivers/xen/grant-table.c, which can > only run on CPU_V7 anyway, so it is not a problem. What I'm concerned about in this case is if you try to use instructions which are not supported by the CPU, even in assembly, the assembler will barf. So, if we're building an ARMv6 + ARMv7 kernel, and you try to use LDREXB in generic code, even though you may intend it to only be executed on ARMv7, the assembler will error out. We used to be able to work around that by passing -Wa,-march=armv7 to the compiler for specific files, which would then tell the assembler to accept ARMv7 instructions, but modern GCC output .arch pseudo-ops which override the command line. So now the only way to do it is to override the assemblers selected archtecture using .arch pseudo-ops in the assembly code. So, what I'm saying is that dropping the !ARMv6 dependency is not as simple as it would seem, and I'm nervous about including any such patches this close to Christmas and the merge window. I've recently been through a run of "apply this patch, no it's wrong, drop it, apply the next version, no it's still wrong, drop it again." So, today is the last day I'm accepting _known_ good patches into my tree for the 4.5 merge window. This is not yet a known good patch because it hasn't been through several iterations of testing - and I don't want to be adding and removing patches from my tree over Christmas. I'd rather leave my tree in a known good state before Christmas so that those who want to fiddle with the kernel over the holiday break can do so without having the hassle of trees containing partially tested patches. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
On Tue, 22 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 02:17:17PM +, Stefano Stabellini wrote:
> > Hello Russell,
> >
> > Would you please consider this patch for the next merge window? It
> > is a very old patch (March 2014) which has been left over.
>
> This patch has some obvious problems...
>
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 34e1569..e09ed94 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1807,8 +1807,7 @@ config XEN_DOM0
> > config XEN
> > bool "Xen guest support on ARM"
> > depends on ARM && AEABI && OF
> > - depends on CPU_V7 && !CPU_V6
> > - depends on !GENERIC_ATOMIC64
> > + depends on CPU_V7
>
> How sure are we that this won't cause regressions? How much testing
> has been done with these changed dependencies?
I did build-test a range of combinations of those options, sorry for not
spotting the error below.
> > diff --git a/arch/arm/include/asm/sync_bitops.h
> > b/arch/arm/include/asm/sync_bitops.h
> > index 9732b8e..4103319 100644
> > --- a/arch/arm/include/asm/sync_bitops.h
> > +++ b/arch/arm/include/asm/sync_bitops.h
> > @@ -20,7 +20,29 @@
> > #define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
> > #define sync_test_and_change_bit(nr, p)_test_and_change_bit(nr, p)
> > #define sync_test_bit(nr, addr)test_bit(nr, addr)
> > -#define sync_cmpxchg cmpxchg
> >
> > +static inline unsigned long sync_cmpxchg(volatile void *ptr,
> > +
> > unsigned long old,
> > +
> > unsigned long new)
> > +{
> > + unsigned long oldval;
> > + int size = sizeof(*(ptr));
>
> This is buggy. You're doing sizeof(void) here, which on GCC will always
> be 1:
>
>A consequence of this is that `sizeof' is also allowed on `void' and
> on function types, and returns 1.
You are right, thank you very much for looking at the patch and finding
this bug. I think the issue can be solved with something like:
+#define sync_cmpxchg(ptr, o, n) ({ \
+ (__typeof(*ptr))__sync_cmpxchg((ptr), \
+ (unsigned long)(o), \
+ (unsigned long)(n), \
+ sizeof(*(ptr)));\
+})
+static inline unsigned long __sync_cmpxchg(volatile void *ptr,
+
unsigned long old,
+
unsigned long new,
+
int size)
+{
> > +
> > + smp_mb();
> > + switch (size) {
> > + case 1:
> > + oldval = __cmpxchg8(ptr, old, new);
> > + break;
> > + case 2:
> > + oldval = __cmpxchg16(ptr, old, new);
> > + break;
>
> The ldrexb/ldrexh instructions are not available on ARMv6 CPUs. __xchg()
> and friends avoided these for ARMv6 CPUs, but this does not.
>
> I'd expect anything that uses sync_cmpxchg() will fail to build when a
> kernel including ARMv6 is attempted.
The code builds, but of course it could not actually run on CPU_V6. But
the use case for me is building drivers/xen/grant-table.c, which can
only run on CPU_V7 anyway, so it is not a problem.
Is that acceptable for you? If not, do you have any other suggestions?
> So... I don't think this patch is ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
On Tue, Dec 22, 2015 at 02:17:17PM +, Stefano Stabellini wrote:
> Hello Russell,
>
> Would you please consider this patch for the next merge window? It
> is a very old patch (March 2014) which has been left over.
This patch has some obvious problems...
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 34e1569..e09ed94 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1807,8 +1807,7 @@ config XEN_DOM0
> config XEN
> bool "Xen guest support on ARM"
> depends on ARM && AEABI && OF
> - depends on CPU_V7 && !CPU_V6
> - depends on !GENERIC_ATOMIC64
> + depends on CPU_V7
How sure are we that this won't cause regressions? How much testing
has been done with these changed dependencies?
> diff --git a/arch/arm/include/asm/sync_bitops.h
> b/arch/arm/include/asm/sync_bitops.h
> index 9732b8e..4103319 100644
> --- a/arch/arm/include/asm/sync_bitops.h
> +++ b/arch/arm/include/asm/sync_bitops.h
> @@ -20,7 +20,29 @@
> #define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
> #define sync_test_and_change_bit(nr, p) _test_and_change_bit(nr, p)
> #define sync_test_bit(nr, addr) test_bit(nr, addr)
> -#define sync_cmpxchg cmpxchg
>
> +static inline unsigned long sync_cmpxchg(volatile void *ptr,
> +
> unsigned long old,
> +
> unsigned long new)
> +{
> + unsigned long oldval;
> + int size = sizeof(*(ptr));
This is buggy. You're doing sizeof(void) here, which on GCC will always
be 1:
A consequence of this is that `sizeof' is also allowed on `void' and
on function types, and returns 1.
> +
> + smp_mb();
> + switch (size) {
> + case 1:
> + oldval = __cmpxchg8(ptr, old, new);
> + break;
> + case 2:
> + oldval = __cmpxchg16(ptr, old, new);
> + break;
The ldrexb/ldrexh instructions are not available on ARMv6 CPUs. __xchg()
and friends avoided these for ARMv6 CPUs, but this does not.
I'd expect anything that uses sync_cmpxchg() will fail to build when a
kernel including ARMv6 is attempted.
So... I don't think this patch is ready.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
Hello Russell,
Would you please consider this patch for the next merge window? It
is a very old patch (March 2014) which has been left over.
See some of the original threads here:
http://marc.info/?l=linux-arm-kernel&m=138920414402610&w=2
http://marc.info/?l=linux-arm-kernel&m=139031200118436&w=2
Many thanks,
Stefano
---
Remove !GENERIC_ATOMIC64 build dependency:
- introduce xen_atomic64_xchg
- use it to implement xchg_xen_ulong
Remove !CPU_V6 build dependency:
- introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef
CONFIG_CPU_V6
- implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16
Signed-off-by: Stefano Stabellini
Reviewed-by: Will Deacon
Acked-by: Ian Campbell
CC: a...@arndb.de
CC: will.dea...@arm.com
CC: catalin.mari...@arm.com
CC: linux-arm-ker...@lists.infradead.org
CC: linux-kernel@vger.kernel.org
CC: xen-de...@lists.xenproject.org
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 34e1569..e09ed94 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1807,8 +1807,7 @@ config XEN_DOM0
config XEN
bool "Xen guest support on ARM"
depends on ARM && AEABI && OF
- depends on CPU_V7 && !CPU_V6
- depends on !GENERIC_ATOMIC64
+ depends on CPU_V7
depends on MMU
select ARCH_DMA_ADDR_T_64BIT
select ARM_PSCI
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index 97882f9..3b342ec 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -152,6 +152,44 @@ extern void __bad_cmpxchg(volatile void *ptr, int size);
* cmpxchg only support 32-bits operands on ARMv6.
*/
+static inline unsigned long __cmpxchg8(volatile void *ptr, unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval, res;
+
+ do {
+ asm volatile("@ __cmpxchg8\n"
+ " ldrexb %1, [%2]\n"
+ " mov %0, #0\n"
+ " teq %1, %3\n"
+ " strexbeq %0, %4, [%2]\n"
+ : "=&r" (res), "=&r" (oldval)
+ : "r" (ptr), "Ir" (old), "r" (new)
+ : "memory", "cc");
+ } while (res);
+
+ return oldval;
+}
+
+static inline unsigned long __cmpxchg16(volatile void *ptr, unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval, res;
+
+ do {
+ asm volatile("@ __cmpxchg16\n"
+ " ldrexh %1, [%2]\n"
+ " mov %0, #0\n"
+ " teq %1, %3\n"
+ " strexheq %0, %4, [%2]\n"
+ : "=&r" (res), "=&r" (oldval)
+ : "r" (ptr), "Ir" (old), "r" (new)
+ : "memory", "cc");
+ } while (res);
+
+ return oldval;
+}
+
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
{
@@ -162,28 +200,10 @@ static inline unsigned long __cmpxchg(volatile void *ptr,
unsigned long old,
switch (size) {
#ifndef CONFIG_CPU_V6 /* min ARCH >= ARMv6K */
case 1:
- do {
- asm volatile("@ __cmpxchg1\n"
- " ldrexb %1, [%2]\n"
- " mov %0, #0\n"
- " teq %1, %3\n"
- " strexbeq %0, %4, [%2]\n"
- : "=&r" (res), "=&r" (oldval)
- : "r" (ptr), "Ir" (old), "r" (new)
- : "memory", "cc");
- } while (res);
+ oldval = __cmpxchg8(ptr, old, new);
break;
case 2:
- do {
- asm volatile("@ __cmpxchg1\n"
- " ldrexh %1, [%2]\n"
- " mov %0, #0\n"
- " teq %1, %3\n"
- " strexheq %0, %4, [%2]\n"
- : "=&r" (res), "=&r" (oldval)
- : "r" (ptr), "Ir" (old), "r" (new)
- : "memory", "cc");
- } while (res);
+ oldval = __cmpxchg16(ptr, old, new);
break;
#endif
case 4:
diff --git a/arch/arm/include/asm/sync_bitops.h
b/arch/arm/include/asm/sync_bitops.h
index 9732b8e..4103319 100644
--- a/arch/arm/include/asm/sync_bitops.h
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -20,7 +20,29 @@
#define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
#define sync_test_and_change_bit(nr, p)_test_and_change_bit(nr, p)
#define sync_test_bit(nr, addr)test_bit(nr, addr)
-#define sync_cmpxchg cmpxchg
+static inline unsigned long sync_cmpxchg(volatile void *ptr,
+
