* [Buildroot] [PATCH 1/4] configs: atmel: at91sam9260eknf: update defconfig
From: Ludovic Desroches @ 2016-11-09 10:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109073638.ozgbr5vy6gglznlx@tarshish>
On Wed, Nov 09, 2016 at 09:36:38AM +0200, Baruch Siach wrote:
> Hi Ludovic,
>
> On Wed, Nov 09, 2016 at 07:59:45AM +0100, Ludovic Desroches wrote:
> > Bump to a recent version of AT91bootstrap and use mainline version of
> > U-Boot and Linux.
> >
> > Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> > ---
> > configs/at91sam9260eknf_defconfig | 22 ++++++++++++----------
> > 1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/configs/at91sam9260eknf_defconfig b/configs/at91sam9260eknf_defconfig
> > index 92bb071..4c17cb6 100644
> > --- a/configs/at91sam9260eknf_defconfig
> > +++ b/configs/at91sam9260eknf_defconfig
> > @@ -2,9 +2,6 @@
> > BR2_arm=y
> > BR2_arm926t=y
> >
> > -# Linux headers same as kernel, a 3.9 series
> > -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_9=y
> > -
> > # Packages
> > BR2_PACKAGE_HOST_SAM_BA=y
> >
> > @@ -13,15 +10,20 @@ BR2_TARGET_ROOTFS_UBIFS=y
> > BR2_TARGET_ROOTFS_UBI=y
> >
> > # Bootloaders
> > -BR2_TARGET_AT91BOOTSTRAP=y
> > -BR2_TARGET_AT91BOOTSTRAP_BOARD="at91sam9260ek"
> > -BR2_TARGET_AT91BOOTSTRAP_NANDFLASH=y
> > +BR2_TARGET_AT91BOOTSTRAP3=y
> > +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_GIT=y
> > +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_REPO_URL="https://github.com/linux4sam/at91bootstrap.git"
> > +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_REPO_VERSION="v3.8.7"
> > +BR2_TARGET_AT91BOOTSTRAP3_DEFCONFIG="at91sam9260eknf_uboot"
> > BR2_TARGET_BAREBOX=y
> > BR2_TARGET_BAREBOX_BOARD_DEFCONFIG="at91sam9260ek"
> > +BR2_TARGET_UBOOT=y
> > +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
> > +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="at91sam9260ek_nandflash"
>
> Why enable both U-Boot and Barebox?
>
I don't know why Barebox was selected but the 'official' bootloader is
U-Boot for all our products that's why I add it. I kept Barebox because
it was already selected and I don't know if someone is still using it or
not.
> > # Kernel
> > BR2_LINUX_KERNEL=y
> > -BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.9.1"
>
> For the sake of reproducibility you should set this to the version you tested,
> say, 4.8.6. The same goes for other patches in this series.
>
As Alexandre said, we don't want to spend time for the maintainance of these
old boards so sticking to the mainline seems to be the way to go. Giving a
version is a kind of commitment but we no longer perform tests on these
boards excepting kernel boot with kernelci.
> > -BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> > -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/atmel/at91sam9260ek/linux-3.9.config"
>
> You can now drop this file.
Ok.
>
> > +BR2_LINUX_KERNEL_DEFCONFIG="at91_dt"
> > +BR2_LINUX_KERNEL_DTS_SUPPORT=y
> > +BR2_LINUX_KERNEL_INTREE_DTS_NAME="at91sam9260ek"
>
> baruch
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* Patch "smc91x: avoid self-comparison warning" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:08 UTC (permalink / raw)
To: arnd, davem, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
smc91x: avoid self-comparison warning
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
smc91x-avoid-self-comparison-warning.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From e3ebd894f084255fde19116955ba7054858ff5d6 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 14 Mar 2016 23:45:12 +0100
Subject: smc91x: avoid self-comparison warning
From: Arnd Bergmann <arnd@arndb.de>
commit e3ebd894f084255fde19116955ba7054858ff5d6 upstream.
The smc91x driver defines a macro that compares its argument to
itself, apparently to get a true result while using its argument
to avoid a warning about unused local variables.
Unfortunately, this triggers a warning with gcc-6, as the comparison
is obviously useless:
drivers/net/ethernet/smsc/smc91x.c: In function 'smc_hardware_send_pkt':
drivers/net/ethernet/smsc/smc91x.c:563:14: error: self-comparison always evaluates to true [-Werror=tautological-compare]
if (!smc_special_trylock(&lp->lock, flags)) {
This replaces the macro with another one that behaves similarly,
with a cast to (void) to ensure the argument is used, and using
a literal 'true' as its value.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/smsc/smc91x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -540,7 +540,7 @@ static inline void smc_rcv(struct net_d
#define smc_special_lock(lock, flags) spin_lock_irqsave(lock, flags)
#define smc_special_unlock(lock, flags) spin_unlock_irqrestore(lock, flags)
#else
-#define smc_special_trylock(lock, flags) (flags == flags)
+#define smc_special_trylock(lock, flags) ((void)flags, true)
#define smc_special_lock(lock, flags) do { flags = 0; } while (0)
#define smc_special_unlock(lock, flags) do { flags = 0; } while (0)
#endif
Patches currently in stable-queue which might be from arnd@arndb.de are
queue-4.4/drm-exynos-fix-error-handling-in-exynos_drm_subdrv_open.patch
queue-4.4/arm-8584-1-floppy-avoid-gcc-6-warning.patch
queue-4.4/powerpc-ptrace-fix-out-of-bounds-array-access-warning.patch
queue-4.4/cgroup-avoid-false-positive-gcc-6-warning.patch
queue-4.4/smc91x-avoid-self-comparison-warning.patch
^ permalink raw reply
* Patch "powerpc/ptrace: Fix out of bounds array access warning" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:08 UTC (permalink / raw)
To: raj.khem, aaro.koskinen, arnd, gregkh, keescook, mpe, olof,
segher
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/ptrace: Fix out of bounds array access warning
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-ptrace-fix-out-of-bounds-array-access-warning.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 1e407ee3b21f981140491d5b8a36422979ca246f Mon Sep 17 00:00:00 2001
From: Khem Raj <raj.khem@gmail.com>
Date: Mon, 25 Apr 2016 09:19:17 -0700
Subject: powerpc/ptrace: Fix out of bounds array access warning
From: Khem Raj <raj.khem@gmail.com>
commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream.
gcc-6 correctly warns about a out of bounds access
arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Warray-bounds]
offsetof(struct thread_fp_state, fpr[32][0]));
^
check the end of array instead of beginning of next element to fix this
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -376,7 +376,7 @@ static int fpr_get(struct task_struct *t
#else
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
- offsetof(struct thread_fp_state, fpr[32][0]));
+ offsetof(struct thread_fp_state, fpr[32]));
return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
&target->thread.fp_state, 0, -1);
@@ -404,7 +404,7 @@ static int fpr_set(struct task_struct *t
return 0;
#else
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
- offsetof(struct thread_fp_state, fpr[32][0]));
+ offsetof(struct thread_fp_state, fpr[32]));
return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
&target->thread.fp_state, 0, -1);
Patches currently in stable-queue which might be from raj.khem@gmail.com are
queue-4.4/powerpc-ptrace-fix-out-of-bounds-array-access-warning.patch
^ permalink raw reply
* [PATCH 2/2] drm/amdgpu: change log level to KERN_INFO in ci_dpm.c
From: Rex Zhu @ 2016-11-09 10:08 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW; +Cc: Rex Zhu
In-Reply-To: <1478686135-21055-1-git-send-email-Rex.Zhu-5C7GfCeVMHo@public.gmane.org>
Change-Id: I2ad8a66d4dfd089b2a64ffaed81daf5b1525810b
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
---
drivers/gpu/drm/amd/amdgpu/ci_dpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
index fe42e2f..1027f92 100644
--- a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
@@ -5991,7 +5991,7 @@ static int ci_dpm_init(struct amdgpu_device *adev)
tmp |= CNB_PWRMGT_CNTL__DPM_ENABLED_MASK;
break;
default:
- DRM_ERROR("Invalid PCC GPIO: %u!\n", gpio.shift);
+ DRM_INFO("Invalid PCC GPIO: %u!\n", gpio.shift);
break;
}
WREG32_SMC(ixCNB_PWRMGT_CNTL, tmp);
--
1.9.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* [PATCH 1/2] drm/amdgpu: always un-gate UVD REGS path.
From: Rex Zhu @ 2016-11-09 10:08 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW; +Cc: Rex Zhu
Change-Id: I910a79b551a9b79b635161bb42ac123a23783225
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
---
drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c b/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c
index d2c96f1..d686946 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c
@@ -596,7 +596,10 @@ static void uvd_v4_2_set_dcm(struct amdgpu_device *adev,
bool sw_mode)
{
u32 tmp, tmp2;
+ u32 data = RREG32(mmUVD_CGC_GATE);
+ data &= ~UVD_CGC_GATE__REGS_MASK;
+ WREG32(mmUVD_CGC_GATE, data);
tmp = RREG32(mmUVD_CGC_CTRL);
tmp &= ~(UVD_CGC_CTRL__CLK_OFF_DELAY_MASK | UVD_CGC_CTRL__CLK_GATE_DLY_TIMER_MASK);
tmp |= UVD_CGC_CTRL__DYN_CLOCK_MODE_MASK |
--
1.9.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Patch "mm/cma: silence warnings due to max() usage" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:08 UTC (permalink / raw)
To: sfr, akpm, gregkh, torvalds; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
mm/cma: silence warnings due to max() usage
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mm-cma-silence-warnings-due-to-max-usage.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From badbda53e505089062e194c614e6f23450bc98b2 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 27 May 2016 14:27:41 -0700
Subject: mm/cma: silence warnings due to max() usage
From: Stephen Rothwell <sfr@canb.auug.org.au>
commit badbda53e505089062e194c614e6f23450bc98b2 upstream.
pageblock_order can be (at least) an unsigned int or an unsigned long
depending on the kernel config and architecture, so use max_t(unsigned
long, ...) when comparing it.
fixes these warnings:
In file included from include/asm-generic/bug.h:13:0,
from arch/powerpc/include/asm/bug.h:127,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/mm.h:8,
from include/linux/memblock.h:18,
from mm/cma.c:28:
mm/cma.c: In function 'cma_init_reserved_mem':
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_max1 == &_max2); ^
mm/cma.c:186:27: note: in expansion of macro 'max'
alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
^
mm/cma.c: In function 'cma_declare_contiguous':
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_max1 == &_max2); ^
include/linux/kernel.h:747:9: note: in definition of macro 'max'
typeof(y) _max2 = (y); ^
mm/cma.c:270:29: note: in expansion of macro 'max'
(phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
^
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_max1 == &_max2); ^
include/linux/kernel.h:747:21: note: in definition of macro 'max'
typeof(y) _max2 = (y); ^
mm/cma.c:270:29: note: in expansion of macro 'max'
(phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
^
[akpm@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20160526150748.5be38a4f@canb.auug.org.au
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/cma.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -183,7 +183,8 @@ int __init cma_init_reserved_mem(phys_ad
return -EINVAL;
/* ensure minimal alignment required by mm core */
- alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
+ alignment = PAGE_SIZE <<
+ max_t(unsigned long, MAX_ORDER - 1, pageblock_order);
/* alignment should be aligned with order_per_bit */
if (!IS_ALIGNED(alignment >> PAGE_SHIFT, 1 << order_per_bit))
@@ -266,8 +267,8 @@ int __init cma_declare_contiguous(phys_a
* migratetype page by page allocator's buddy algorithm. In the case,
* you couldn't get a contiguous memory, which is not what we want.
*/
- alignment = max(alignment,
- (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
+ alignment = max(alignment, (phys_addr_t)PAGE_SIZE <<
+ max_t(unsigned long, MAX_ORDER - 1, pageblock_order));
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit &= ~(alignment - 1);
Patches currently in stable-queue which might be from sfr@canb.auug.org.au are
queue-4.4/mm-cma-silence-warnings-due-to-max-usage.patch
^ permalink raw reply
* Patch "drm/exynos: fix error handling in exynos_drm_subdrv_open" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:08 UTC (permalink / raw)
To: arnd, gregkh, inki.dae; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/exynos: fix error handling in exynos_drm_subdrv_open
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-exynos-fix-error-handling-in-exynos_drm_subdrv_open.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 55c4b906aa2aec3fa66310ec03c6842e34a04b2a Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 14 Mar 2016 15:22:25 +0100
Subject: drm/exynos: fix error handling in exynos_drm_subdrv_open
From: Arnd Bergmann <arnd@arndb.de>
commit 55c4b906aa2aec3fa66310ec03c6842e34a04b2a upstream.
gcc-6 warns about a pointless loop in exynos_drm_subdrv_open:
drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open':
drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always evaluates to false [-Werror=tautological-compare]
list_for_each_entry_reverse(subdrv, &subdrv->list, list) {
Here, the list_for_each_entry_reverse immediately terminates because
the subdrv pointer is compared to itself as the loop end condition.
If we were to take the current subdrv pointer as the start of the
list (as we would do if list_for_each_entry_reverse() was not a macro),
we would iterate backwards over the &exynos_drm_subdrv_list anchor,
which would be even worse.
Instead, we need to use list_for_each_entry_continue_reverse()
to go back over each subdrv that was successfully opened until
the first entry.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -101,7 +101,7 @@ int exynos_drm_subdrv_open(struct drm_de
return 0;
err:
- list_for_each_entry_reverse(subdrv, &subdrv->list, list) {
+ list_for_each_entry_continue_reverse(subdrv, &exynos_drm_subdrv_list, list) {
if (subdrv->close)
subdrv->close(dev, subdrv->dev, file);
}
Patches currently in stable-queue which might be from arnd@arndb.de are
queue-4.4/drm-exynos-fix-error-handling-in-exynos_drm_subdrv_open.patch
queue-4.4/arm-8584-1-floppy-avoid-gcc-6-warning.patch
queue-4.4/powerpc-ptrace-fix-out-of-bounds-array-access-warning.patch
queue-4.4/cgroup-avoid-false-positive-gcc-6-warning.patch
queue-4.4/smc91x-avoid-self-comparison-warning.patch
^ permalink raw reply
* Patch "Disable "frame-address" warning" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:08 UTC (permalink / raw)
To: torvalds, gregkh, rostedt; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
Disable "frame-address" warning
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
disable-frame-address-warning.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 124a3d88fa20e1869fc229d7d8c740cc81944264 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 27 Jul 2016 19:03:04 -0700
Subject: Disable "frame-address" warning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Linus Torvalds <torvalds@linux-foundation.org>
commit 124a3d88fa20e1869fc229d7d8c740cc81944264 upstream.
Newer versions of gcc warn about the use of __builtin_return_address()
with a non-zero argument when "-Wall" is specified:
kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’:
kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address]
stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
[ .. repeats a few times for other similar cases .. ]
It is true that a non-zero argument is somewhat dangerous, and we do not
actually have very many uses of that in the kernel - but the ftrace code
does use it, and as Stephen Rostedt says:
"We are well aware of the danger of using __builtin_return_address() of
> 0. In fact that's part of the reason for having the "thunk" code in
x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames
when tracking irqs off sections, to prevent __builtin_return_address()
from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to
trace irqs off. (otherwise CALLER_ADDR1 might crash)'."
For now, __builtin_return_address() with a non-zero argument is the best
we can do, and the warning is not helpful and can end up making people
miss other warnings for real problems.
So disable the frame-address warning on compilers that need it.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/Makefile
+++ b/Makefile
@@ -617,6 +617,7 @@ include arch/$(SRCARCH)/Makefile
KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
+KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os
Patches currently in stable-queue which might be from torvalds@linux-foundation.org are
queue-4.4/mm-list_lru.c-avoid-error-path-null-pointer-deref.patch
queue-4.4/mm-memcontrol-do-not-recurse-in-direct-reclaim.patch
queue-4.4/disable-frame-address-warning.patch
queue-4.4/x86-xen-fix-upper-bound-of-pmd-loop-in-xen_cleanhighmap.patch
queue-4.4/mm-cma-silence-warnings-due-to-max-usage.patch
queue-4.4/h8300-fix-syscall-restarting.patch
queue-4.4/fix-potential-infoleak-in-older-kernels.patch
^ permalink raw reply
* Patch "cgroup: avoid false positive gcc-6 warning" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:08 UTC (permalink / raw)
To: arnd, gregkh, tj; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
cgroup: avoid false positive gcc-6 warning
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
cgroup-avoid-false-positive-gcc-6-warning.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From cfe02a8a973e7e5f66926b8ae38dfce404b19e29 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 15 Mar 2016 00:21:06 +0100
Subject: cgroup: avoid false positive gcc-6 warning
From: Arnd Bergmann <arnd@arndb.de>
commit cfe02a8a973e7e5f66926b8ae38dfce404b19e29 upstream.
When all subsystems are disabled, gcc notices that cgroup_subsys_enabled_key
is a zero-length array and that any access to it must be out of bounds:
In file included from ../include/linux/cgroup.h:19:0,
from ../kernel/cgroup.c:31:
../kernel/cgroup.c: In function 'cgroup_add_cftypes':
../kernel/cgroup.c:261:53: error: array subscript is above array bounds [-Werror=array-bounds]
return static_key_enabled(cgroup_subsys_enabled_key[ssid]);
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
../include/linux/jump_label.h:271:40: note: in definition of macro 'static_key_enabled'
static_key_count((struct static_key *)x) > 0; \
^
We should never call the function in this particular case, so this is
not a bug. In order to silence the warning, this adds an explicit check
for the CGROUP_SUBSYS_COUNT==0 case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup.c | 3 +++
1 file changed, 3 insertions(+)
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -236,6 +236,9 @@ static int cgroup_addrm_files(struct cgr
*/
static bool cgroup_ssid_enabled(int ssid)
{
+ if (CGROUP_SUBSYS_COUNT == 0)
+ return false;
+
return static_key_enabled(cgroup_subsys_enabled_key[ssid]);
}
Patches currently in stable-queue which might be from arnd@arndb.de are
queue-4.4/drm-exynos-fix-error-handling-in-exynos_drm_subdrv_open.patch
queue-4.4/arm-8584-1-floppy-avoid-gcc-6-warning.patch
queue-4.4/powerpc-ptrace-fix-out-of-bounds-array-access-warning.patch
queue-4.4/cgroup-avoid-false-positive-gcc-6-warning.patch
queue-4.4/smc91x-avoid-self-comparison-warning.patch
^ permalink raw reply
* Patch "ARM: 8584/1: floppy: avoid gcc-6 warning" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:08 UTC (permalink / raw)
To: arnd, gregkh, rmk+kernel; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: 8584/1: floppy: avoid gcc-6 warning
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-8584-1-floppy-avoid-gcc-6-warning.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From dd665be0e243873343a28e18f9f345927b658daf Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 1 Jul 2016 18:02:22 +0100
Subject: ARM: 8584/1: floppy: avoid gcc-6 warning
From: Arnd Bergmann <arnd@arndb.de>
commit dd665be0e243873343a28e18f9f345927b658daf upstream.
gcc-6.0 warns about comparisons between two identical expressions,
which is what we get in the floppy driver when writing to the FD_DOR
register:
drivers/block/floppy.c: In function 'set_dor':
drivers/block/floppy.c:810:44: error: self-comparison always evaluates to true [-Werror=tautological-compare]
fd_outb(newdor, FD_DOR);
It would be nice to use a static inline function instead of the
macro, to avoid the warning, but we cannot do that because the
FD_DOR definition is incomplete at this point.
Adding a cast to (u32) is a harmless way to shut up the warning,
just not very nice.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/asm/floppy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/include/asm/floppy.h
+++ b/arch/arm/include/asm/floppy.h
@@ -17,7 +17,7 @@
#define fd_outb(val,port) \
do { \
- if ((port) == FD_DOR) \
+ if ((port) == (u32)FD_DOR) \
fd_setdor((val)); \
else \
outb((val),(port)); \
Patches currently in stable-queue which might be from arnd@arndb.de are
queue-4.4/drm-exynos-fix-error-handling-in-exynos_drm_subdrv_open.patch
queue-4.4/arm-8584-1-floppy-avoid-gcc-6-warning.patch
queue-4.4/powerpc-ptrace-fix-out-of-bounds-array-access-warning.patch
queue-4.4/cgroup-avoid-false-positive-gcc-6-warning.patch
queue-4.4/smc91x-avoid-self-comparison-warning.patch
^ permalink raw reply
* Re: Patch "scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices" has been added to the 4.8-stable tree
From: Greg KH @ 2016-11-09 10:08 UTC (permalink / raw)
To: Kashyap Desai
Cc: Sumit Saxena, emilne, hare, martin.petersen, thenzl, stable,
stable-commits
In-Reply-To: <fe425e4e97d881ac19f44f90cb3cd3d5@mail.gmail.com>
On Wed, Nov 09, 2016 at 02:45:30PM +0530, Kashyap Desai wrote:
> > >> please let
> > > >> ><stable@vger.kernel.org> know about it.
> > > >>
> > > >> There will be follow up patch which I will be sending in sometime
> > > >> so follow patch needs to be applied along with this patch.
> > > >
> > > >Does that mean that this patch on its own is broken?
> > > >
> > > >confused,
> > > Yes this patch is broken and follow up patch will fix that. I am doing
> > > some testing with fix and will send it in sometime.
> >
> > So should I drop this one from the stable trees until that one is
> merged?
>
> Greg - We are sending another patch which is small fix on top of this one.
> It is critical regression.
> Not sure which will be a good .. To reject or hold current patch. Current
> patch is definitely a not good to keep without upcoming fix.
>
> To avoid confusion, let's reject this patch and apply once full fix is
> available (by EOD).
Ok, I've dropped this from the stable queue, please let me know when the
"fix" is in Linus's tree, so I can re-add this patch, and the fix patch
(please let me know what the git ids are for both.)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Björn Töpel @ 2016-11-09 10:05 UTC (permalink / raw)
To: Ananyev, Konstantin, dev@dpdk.org, helin.zhang
Cc: Xu, Qian Q, Yao, Lei A, Wu, Jingjing, thomas.monjalon@6wind.com
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0D2F6C@irsmsx105.ger.corp.intel.com>
Adding Helin to the conversation.
> That's a common problem across Intel VF devices. Bothe igb and ixgbe
> overcomes that problem just by forcing ' rxmode.hw_strip_crc = 1;' at
> PMD itself:
[...]
> Wonder, can't i40e VF do the same?
Right, however, and this (silent failure) approach was rejected by the
maintainers. Please, refer to this thread:
http://dpdk.org/ml/archives/dev/2016-April/037523.html
> BTW, all other examples would experience same problem too, right?
Correct, so the broader question would be "what is the correct behavior
for an example application, when a port configuration isn't supported by
the hardware?".
My stand, FWIW, is that igb and ixgbe should have the same semantics as
i40e currently has, i.e. return an error to the user if the port is
mis-configured, NOT changing the setting behind the users back.
Björn
^ permalink raw reply
* Re: [PATCH] kernel.bbclass: Allow ${S} to be overridden
From: Burton, Ross @ 2016-11-09 10:04 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: OpenEmbedded Core
In-Reply-To: <CADkTA4OaRgUJwFwT=S_h41EW4OO_Koa+QQr=t3t+X+6pszrzBQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
On 9 November 2016 at 02:23, Bruce Ashfield <bruce.ashfield@gmail.com>
wrote:
> I can ack this patch, since no defaults change .. there's no risk to
> existing users.
>
Saying that of course doomed the patch:
ERROR: hello-mod-0.1-r0 do_make_scripts: Function failed: do_make_scripts
(log file is located at
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work/qemux86_64-poky-linux/hello-mod/0.1-r0/temp/log.do_make_scripts.14071)
ERROR: Logfile of failure stored in:
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work/qemux86_64-poky-linux/hello-mod/0.1-r0/temp/log.do_make_scripts.14071
Log data follows:
| DEBUG: Executing shell function do_make_scripts
| make: Entering directory
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work-shared/qemux86-64/kernel-source'
| make: *** No rule to make target 'scripts'. Stop.
| make: Leaving directory
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work-shared/qemux86-64/kernel-source'
| WARNING:
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work/qemux86_64-poky-linux/hello-mod/0.1-r0/temp/run.do_make_scripts.14071:1
exit 2 from 'make CC="x86_64-poky-linux-gcc -fuse-ld=bfd"
LD="x86_64-poky-linux-ld.bfd " AR="x86_64-poky-linux-ar " -C
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work-shared/qemux86-64/kernel-source
O=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work-shared/qemux86-64/kernel-build-artifacts
scripts'
| ERROR: Function failed: do_make_scripts (log file is located at
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work/qemux86_64-poky-linux/hello-mod/0.1-r0/temp/log.do_make_scripts.14071)
NOTE: recipe hello-mod-0.1-r0: task do_make_scripts: Failed
The autobuilder builds hello-mod from meta-skeleton, which inherits module
and sets S=${WORKDIR}.
Ross
[-- Attachment #2: Type: text/html, Size: 2543 bytes --]
^ permalink raw reply
* [Buildroot] [Question] Downgrade package application.
From: Yu-Ting Kao @ 2016-11-09 10:04 UTC (permalink / raw)
To: buildroot
Hi,
I have a patch for new feature on a package, but it works on lower
version. How can I build lower version in buildroot ? Are there any
menuconfig I can choose ?
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
From: Cornelia Huck @ 2016-11-09 10:04 UTC (permalink / raw)
To: Samuel Thibault
Cc: Peter Maydell, Michal Suchanek, QEMU Developers, Sergey Smolov
In-Reply-To: <20161109095238.GE2870@var.eduroam.u-bordeaux.fr>
On Wed, 9 Nov 2016 10:52:38 +0100
Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Hello,
>
> Cornelia Huck, on Wed 09 Nov 2016 10:40:28 +0100, wrote:
> > Still curses=no... log attached.
>
> Oops, sorry, I misplaced my code, and it somehow worked in my case.
> Could you give a try at the attached patch instead?
Works for me on SLES, Fedora, Ubuntu.
Tested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Sergey, could you test whether the patch works for you as well?
(Inserted for convenience.)
commit cc8965eb848f53599895a650a6e062319189be1f
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Tue Nov 8 20:57:27 2016 +0100
Fix cursesw detection
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
- curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+ curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw 2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
IFS=:
for curses_inc in $curses_inc_list; do
+ IFS=:
for curses_lib in $curses_lib_list; do
unset IFS
if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
break
fi
done
+ if test "$curses_found" = yes ; then
+ break
+ fi
done
unset IFS
if test "$curses_found" = "yes" ; then
^ permalink raw reply related
* Re: [PATCH 8/9] xfs: fuzz every field of every structure
From: Eryu Guan @ 2016-11-09 10:04 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: david, linux-xfs, fstests
In-Reply-To: <20161109092523.GF20710@birch.djwong.org>
On Wed, Nov 09, 2016 at 01:25:23AM -0800, Darrick J. Wong wrote:
> On Wed, Nov 09, 2016 at 05:13:44PM +0800, Eryu Guan wrote:
> > On Wed, Nov 09, 2016 at 12:52:36AM -0800, Darrick J. Wong wrote:
> > > On Wed, Nov 09, 2016 at 04:09:24PM +0800, Eryu Guan wrote:
> > > > On Fri, Nov 04, 2016 at 05:18:00PM -0700, Darrick J. Wong wrote:
> > > > > Previously, our XFS fuzzing efforts were limited to using the xfs_db
> > > > > blocktrash command to scribble garbage all over a block. This is
> > > > > pretty easy to discover; it would be far more interesting if we could
> > > > > fuzz individual fields looking for unhandled corner cases. Since we
> > > > > now have an online scrub tool, use it to check for our targeted
> > > > > corruptions prior to the usual steps of writing to the FS, taking it
> > > > > offline, repairing, and re-checking.
> > > > >
> > > > > These tests use the new xfs_db 'fuzz' command to test corner case
> > > > > handling of every field. The 'print' command tells us which fields
> > > > > are available, and the fuzz command can write zeroes or ones to the
> > > > > field; set the high, middle, or low bit; add or subtract numbers; or
> > > > > randomize the field. We loop through all fields and all fuzz verbs to
> > > > > see if we can trip up the kernel.
> > > > >
> > > > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > > >
> > > > The first test gave me a kernel crash :) xfs/1300 crashed your kernel
> > > > djwong-devel branch. I appended the console log at the end of this mail
> > > > if you have interest to see it.
> > > >
> > > > And another xfs/1300 run gave me this failure message:
> > > >
> > > > +/mnt/testarea/scratch: Kernel lacks GETFSMAP; scrub will be less efficient. (xfs.c line 661)
> > > > +/mnt/testarea/scratch: Kernel cannot help scrub metadata; scrub will be incomplete. (xfs.c line 661)
> > > > +/mnt/testarea/scratch: Kernel cannot help scrub inodes; scrub will be incomplete. (xfs.c line 661)
> > > > +/mnt/testarea/scratch: Kernel cannot help scrub extent map; scrub will be less efficient. (xfs.c line 661)
> > > >
> > > > Is this known issue or something should be filtered out in the test?
> > >
> > > That's strange, the djwong-devel branch should have getfsmap & scrub in it...
> > >
> > > ...are you running the djwong-devel kernel and xfsprogs code? The scrub
> > > ioctl structure has shifted some over the past few months, though GETFSMAP
> > > hasn't changed in ages.
> > >
> > > Wait, "another xfs/1300 run" ... so after the first crash, did you go
> > > back to a vanilla kernel without all my crazypatches? :)
> >
> > Ahh, you're right! It booted into 4.9-rc4 vanilla kernel, sorry about
> > that.. But xfs/1300 crashed djwong-devel for the second time in my
> > second try, seems the crash is reliable reproduced, with reflink
> > enabled.
>
> I think if you change the XFS_SCRUB_OP_ERROR_GOTO at line 2237 of
> xfs_scrub_get_inode() to "if (error) goto out_err;" that ought to clear it up.
>
> > > > And ext4/1300 generated large .out.bad file (51M), containing something
> > > > like:
> > > >
> > > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101381632/2469888/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> > > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> > > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> > > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> > > > +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> > > >
> > > > Seems like scrub found something wrong (real problems) and became very
> > > > noisy?
> > >
> > > Hmm that's even stranger. I'll try to reproduce tomorrow.
> >
> > So this ext4 noise came from the vanilla kernel too, retested with
> > djwong-devel kernel & userspace ext4/1300 passed without problems. Sorry
> > for my noise..
>
> But that's even more weird; there haven't been any changes to ext4 that
> would explain why this breaks on a vanilla 4.9-rc4 kernel...
Puzzle resolved, I somehow switched back to mainline xfsprogs or some
other wrong xfsprogs version after booted into 4.9-rc4 vanilla kernel.
After updating xfsprogs to djwong-devel, ext4/1300 showed no problem on
4.9-rc4 kernel too.
Sorry again for the mess!
Eryu
^ permalink raw reply
* [Buildroot] [PATCH] qemu: allow to build statically
From: Jérôme Pouiller @ 2016-11-09 10:03 UTC (permalink / raw)
To: buildroot
Compiling Qemu statically allows to use it to chroot into target/. It is a
nice feature, so add an option for it.
Signed-off-by: J?r?me Pouiller <jezz@sysmic.org>
---
package/qemu/Config.in.host | 26 ++++++++++++++++++++++++++
package/qemu/qemu.mk | 4 ++++
2 files changed, 30 insertions(+)
diff --git a/package/qemu/Config.in.host b/package/qemu/Config.in.host
index b3eb590..c61b787 100644
--- a/package/qemu/Config.in.host
+++ b/package/qemu/Config.in.host
@@ -17,6 +17,32 @@ config BR2_PACKAGE_HOST_QEMU
if BR2_PACKAGE_HOST_QEMU
+config BR2_PACKAGE_HOST_QEMU_STATIC
+ bool "Build statically"
+ help
+ Build static qemu executable(s). Use this option if you want to
+ 'chroot' in your target directory. An example to do this for an ARM
+ target:
+
+ 1. copy qemu binary on your target directory:
+
+ cp host/usr/bin/qemu-arm target/usr/bin
+
+ 2. Make sure binfmt_misc is mounted on /proc/sys/fs/binfmt_misc:
+
+ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
+
+ 3. Register /usr/bin/qemu-arm is interpreter for arm binaries. See
+ linux/Documentation/binfmt_misc.txt for more information:
+
+ MAGIC='\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00'
+ MASK='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
+ echo ":qemu-arm:M:0:$MAGIC:$MASK:/usr/bin/qemu-arm:OC" > /proc/sys/fs/binfmt_misc/register
+
+ 4. Chroot to your target:
+
+ chroot target /bin/sh
+
comment "Emulators selection"
config BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE
diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
index cf23f16..d33106c 100644
--- a/package/qemu/qemu.mk
+++ b/package/qemu/qemu.mk
@@ -110,6 +110,10 @@ HOST_QEMU_OPTS += --enable-vde
HOST_QEMU_DEPENDENCIES += host-vde2
endif
+ifeq ($(BR2_PACKAGE_HOST_QEMU_STATIC),y)
+HOST_QEMU_OPTS += --static
+endif
+
# Override CPP, as it expects to be able to call it like it'd
# call the compiler.
define HOST_QEMU_CONFIGURE_CMDS
--
2.9.3
^ permalink raw reply related
* Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)
From: Greg KH @ 2016-11-09 10:02 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, Kernel Build Reports Mailman List,
Olof's autobuilder, stable, Eric W. Biederman
In-Reply-To: <20161109094447.GB9540@kroah.com>
On Wed, Nov 09, 2016 at 10:44:47AM +0100, Greg KH wrote:
> On Tue, Nov 08, 2016 at 02:17:41PM -0800, Olof Johansson wrote:
> > On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> > >> Here are the build results from automated periodic testing.
> > >>
> > >> The tree being built was stable-rc, found at:
> > >>
> > >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
> > >>
> > >> Topmost commit:
> > >>
> > >> f821e08 Linux 4.4.31-rc1
> > >>
> > >> Build logs (stderr only) can be found at the following link (experimental):
> > >>
> > >> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
> > >
> > > These seem to be largely caused by building with gcc-6. It's probably
> > > a good idea to keep supporting that configuration though and
> > > backport the fixes. Here are the upstream commit IDs I've found.
> >
> > That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.
> >
> > It's not entirely reasonable to expect older releases to build with
> > new toolchains without warnings, and I'm not sure if it makes sense to
> > bring back those fixes to -stable (unless they fix real bugs, of
> > course).
>
> My test-builder system is using gcc-6, and I do keep track of warnings
> as it is a good indication that an applied patch is wrong (found a bug
> in an i2c patch just yesterday because of it.)
>
> I'm currently seeing only 3 warnings on x86 for 4.4-stable and gcc-6,
> and just found the fix for one of them, so I'll gladly take warning
> fixes that resolve issues to make it easier for the real problems to
> jump out at us.
And now I'm down to 0 warnings thanks to Arnd's hints in this thread and
some more digging. If there's anything else I should add to 4.4 to make
it "quieter", please let me know.
thanks,
greg k-h
^ permalink raw reply
* [Buildroot] [PATCH 1/4] configs: atmel: at91sam9260eknf: update defconfig
From: Baruch Siach @ 2016-11-09 10:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109095249.bgurrb6bhujkgnac@piout.net>
Hi Alexandre,
On Wed, Nov 09, 2016 at 10:52:49AM +0100, Alexandre Belloni wrote:
> On 09/11/2016 at 09:36:38 +0200, Baruch Siach wrote :
> > On Wed, Nov 09, 2016 at 07:59:45AM +0100, Ludovic Desroches wrote:
> > > # Kernel
> > > BR2_LINUX_KERNEL=y
> > > -BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > > -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.9.1"
> >
> > For the sake of reproducibility you should set this to the version you tested,
> > say, 4.8.6. The same goes for other patches in this series.
>
> I'm not sure this is actually useful because the amount of testing is
> minimal and it just increases the maintenance burden.
I don't understand. How would locking a specific kernel version in the
defconfig increase maintenance burden? Any tested kernel version would do. We
just want to ensure consistent user experience. Otherwise the built kernel
will change with the default value of BR2_LINUX_KERNEL_VERSION.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)
From: Martin Steigerwald @ 2016-11-09 9:59 UTC (permalink / raw)
To: Jani Nikula
Cc: intel-gfx, Intel Gfx Mailing List, Linus Torvalds,
Linux Kernel Mailing List
In-Reply-To: <87d1i5gfar.fsf@intel.com>
Am Mittwoch, 9. November 2016, 11:42:36 CET schrieb Jani Nikula:
> > *However*, I got a soft freeze and a hard freeze (well after about a
> > minute I gave up and rebooted by pressing power button long enough to
> > forcefully switch off the laptop) when playing PlaneShift using
> > drm-intel-fixes branch.
> >
> > Unfortunately I have no further time to debug any of this week, but it
> > seems not all fixes are there are ready for next stable kernel.
>
> Current drm-intel-fixes is just six commits on top of -rc4, and it's
> very hard for me to believe any of those would cause the symptoms you
> see. I presume the problem, whatever it is, is already in -rc4.
>
> That, of course, is not a happy thing per se, but please don't block the
> current batch of fixes by making unsubstantiated claims. Please do file
> a bug about that issue over at [1] so we don't hijack this thread.
You are right. I have no comparison with 4.9-rc4 due to the graphics glitches
I had in it.
--
Martin
^ permalink raw reply
* Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)
From: Martin Steigerwald @ 2016-11-09 9:59 UTC (permalink / raw)
To: Jani Nikula
Cc: Intel Gfx Mailing List, intel-gfx, Linus Torvalds,
Linux Kernel Mailing List
In-Reply-To: <87d1i5gfar.fsf@intel.com>
Am Mittwoch, 9. November 2016, 11:42:36 CET schrieb Jani Nikula:
> > *However*, I got a soft freeze and a hard freeze (well after about a
> > minute I gave up and rebooted by pressing power button long enough to
> > forcefully switch off the laptop) when playing PlaneShift using
> > drm-intel-fixes branch.
> >
> > Unfortunately I have no further time to debug any of this week, but it
> > seems not all fixes are there are ready for next stable kernel.
>
> Current drm-intel-fixes is just six commits on top of -rc4, and it's
> very hard for me to believe any of those would cause the symptoms you
> see. I presume the problem, whatever it is, is already in -rc4.
>
> That, of course, is not a happy thing per se, but please don't block the
> current batch of fixes by making unsubstantiated claims. Please do file
> a bug about that issue over at [1] so we don't hijack this thread.
You are right. I have no comparison with 4.9-rc4 due to the graphics glitches
I had in it.
--
Martin
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] timers: Fix timer inaccuracy
From: Thomas Gleixner @ 2016-11-09 9:56 UTC (permalink / raw)
To: Joonwoo Park
Cc: John Stultz, Eric Dumazet, Frederic Weisbecker, Linus Torvalds,
Paul E. McKenney, Peter Zijlstra, linux-kernel
In-Reply-To: <1478684203-11966-1-git-send-email-joonwoop@codeaurora.org>
On Wed, 9 Nov 2016, Joonwoo Park wrote:
> When a new timer list enqueued into the time wheel, array index
> for the given expiry time is:
>
> expires = (expires + LVL_GRAN(lvl)) >> LVL_SHIFT(lvl);
> idx = LVL_OFFS(lvl) + (expires & LVL_MASK);
>
> The granularity of the expiry time level is being added to the index
> in order to fire the timer after its expiry time for the case when
> the timer cannot fire at the exact time because of each level's
> granularity. However current index calculation also increases index
> of timer list even if the timer can fire at exact time. Consequently
> timers which can fire at exact time including all in the first level
> of bucket fire with one jiffy delay at present.
>
> Fix such inaccuracy by adding granularity of expiry time level only
> when a given timer cannot fire at exact time.
That's simply wrong. We guarantee that the timer sleeps for at least a
jiffy. So in case of the first wheel we _must_ increment by one simply
because the next jiffie might be immanent and not doing so would expire the
timer early.
The wheel is not meant to be accurate at all and I really don't want an
extra conditional in that path just to make it accurate for some expiry
values. That's a completely pointless exercise.
Thanks,
tglx
^ permalink raw reply
* Re: ILP32 for ARM64: testing with glibc testsuite
From: Yury Norov @ 2016-11-09 9:56 UTC (permalink / raw)
To: arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc,
linux-arch, GNU C Library
Cc: schwidefsky, heiko.carstens, pinskia, broonie, joseph,
christoph.muellner, bamvor.zhangjian, szabolcs.nagy, klimov.linux,
Nathan_Lynch, agraf, Prasun.Kapoor, kilobyte, geert,
philipp.tomsich, manuel.montezelo, linyongting, maxim.kuvyrkov,
davem, zhouchengming1, cmetcalf, Adhemerval Zanella, Steve Ellcey
In-Reply-To: <20161107082359.GA19666@yury-N73SV>
On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote:
> Hi all,
>
> [add libc-alpha mail list]
>
> For libc-alpha: this is the part of LKML submission with latest
> patches for aarch64/ilp32.
> https://www.spinics.net/lists/arm-kernel/msg537846.html
>
> Glibc that I use has also included consolidation patches from Adhemerval
> Zanella and me that are still not in the glibc master. The full series is:
> https://github.com/norov/glibc/tree/ilp32-2.24-dev2
>
> Below is the results of glibc testsuite run for aarch64/lp64
> in different configurations. Column names meaning:
> kvgv: kernel is vanilla, glibc is vanilla;
> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config;
> glibc is vanilla;
> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla;
> kege: kernel patches are applied and enabled, glibc patches are applied.
>
> Only different lines are shown. Full results are in attached archive.
The same, plus ILP32 regressions:
Test kvgv kdgv kegv kege ilp32
conform/ISO/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/ISO11/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/ISO99/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/POSIX/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/POSIX/sys/stat.h/linknamespace PASS PASS PASS FAIL FAIL
conform/UNIX98/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/XOPEN2K/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/XPG3/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/XPG4/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
csu/tst-atomic PASS PASS PASS FAIL PASS
elf/check-localplt PASS PASS PASS FAIL FAIL
iconvdata/mtrace-tst-loading PASS FAIL PASS PASS FAIL
iconvdata/tst-loading PASS FAIL PASS PASS PASS
io/check-installed-headers-c PASS PASS PASS FAIL FAIL
io/check-installed-headers-cxx PASS PASS PASS FAIL FAIL
malloc/tst-malloc-backtrace FAIL PASS PASS PASS PASS
malloc/tst-malloc-thread-exit FAIL PASS PASS PASS PASS
malloc/tst-malloc-usable FAIL PASS PASS PASS PASS
malloc/tst-mallocfork FAIL PASS PASS PASS PASS
malloc/tst-mallocstate FAIL PASS PASS PASS PASS
malloc/tst-mallopt FAIL PASS PASS PASS PASS
malloc/tst-mcheck FAIL PASS PASS PASS PASS
malloc/tst-memalign FAIL PASS PASS PASS PASS
malloc/tst-obstack FAIL PASS PASS PASS PASS
malloc/tst-posix_memalign FAIL PASS PASS PASS PASS
malloc/tst-pvalloc FAIL PASS PASS PASS PASS
malloc/tst-realloc FAIL PASS PASS PASS PASS
malloc/tst-scratch_buffer FAIL PASS PASS PASS PASS
malloc/tst-trim1 FAIL PASS PASS PASS PASS
nptl/tst-eintr4 PASS PASS PASS NA NA
posix/tst-regex2 PASS FAIL FAIL FAIL FAIL
posix/tst-getaddrinfo4 PASS PASS FAIL FAIL PASS
posix/tst-getaddrinfo5 PASS PASS FAIL FAIL PASS
sysvipc/test-sysvmsg NA NA NA FAIL PASS
sysvipc/test-sysvsem NA NA NA FAIL PASS
sysvipc/test-sysvshm NA NA NA FAIL PASS
c++-types-check PASS PASS PASS PASS FAIL
debug/tst-backtrace4 PASS PASS PASS PASS FAIL
elf/check-abi-libc PASS PASS PASS PASS FAIL
elf/tst-tls1 PASS PASS PASS PASS FAIL
elf/tst-tls1-static PASS PASS PASS PASS FAIL
elf/tst-tls2 PASS PASS PASS PASS FAIL
elf/tst-tls2-static PASS PASS PASS PASS FAIL
elf/tst-tls3 PASS PASS PASS PASS FAIL
math/check-abi-libm PASS PASS PASS PASS FAIL
misc/tst-writev PASS PASS PASS PASS NA
nptl/tst-cancel-self-canceltype PASS PASS PASS PASS FAIL
nptl/tst-cancel1 PASS PASS PASS PASS FAIL
nptl/tst-cancel10 PASS PASS PASS PASS FAIL
nptl/tst-cancel11 PASS PASS PASS PASS FAIL
nptl/tst-cancel13 PASS PASS PASS PASS FAIL
nptl/tst-cancel15 PASS PASS PASS PASS FAIL
nptl/tst-cancel16 PASS PASS PASS PASS FAIL
nptl/tst-cancel17 PASS PASS PASS PASS FAIL
nptl/tst-cancel18 PASS PASS PASS PASS FAIL
nptl/tst-cancel2 PASS PASS PASS PASS FAIL
nptl/tst-cancel20 PASS PASS PASS PASS FAIL
nptl/tst-cancel21 PASS PASS PASS PASS FAIL
nptl/tst-cancel24 PASS PASS PASS PASS FAIL
nptl/tst-cancel25 PASS PASS PASS PASS FAIL
nptl/tst-cancel26 PASS PASS PASS PASS FAIL
nptl/tst-cancel27 PASS PASS PASS PASS FAIL
nptl/tst-cancel3 PASS PASS PASS PASS FAIL
nptl/tst-cancel4 PASS PASS PASS PASS FAIL
nptl/tst-cancel5 PASS PASS PASS PASS FAIL
nptl/tst-cancel6 PASS PASS PASS PASS FAIL
nptl/tst-cancel7 PASS PASS PASS PASS FAIL
nptl/tst-cancelx10 PASS PASS PASS PASS FAIL
nptl/tst-cancelx11 PASS PASS PASS PASS FAIL
nptl/tst-cancelx13 PASS PASS PASS PASS FAIL
nptl/tst-cancelx15 PASS PASS PASS PASS FAIL
nptl/tst-cancelx16 PASS PASS PASS PASS FAIL
nptl/tst-cancelx17 PASS PASS PASS PASS FAIL
nptl/tst-cancelx18 PASS PASS PASS PASS FAIL
nptl/tst-cancelx2 PASS PASS PASS PASS FAIL
nptl/tst-cancelx20 PASS PASS PASS PASS FAIL
nptl/tst-cancelx21 PASS PASS PASS PASS FAIL
nptl/tst-cancelx3 PASS PASS PASS PASS FAIL
nptl/tst-cancelx4 PASS PASS PASS PASS FAIL
nptl/tst-cancelx5 PASS PASS PASS PASS FAIL
nptl/tst-cancelx6 PASS PASS PASS PASS FAIL
nptl/tst-cancelx7 PASS PASS PASS PASS FAIL
nptl/tst-cleanup4 PASS PASS PASS PASS FAIL
nptl/tst-cleanupx4 PASS PASS PASS PASS FAIL
nptl/tst-cond-except PASS PASS PASS PASS FAIL
nptl/tst-cond7 PASS PASS PASS PASS FAIL
nptl/tst-cond8 PASS PASS PASS PASS FAIL
nptl/tst-fini1 PASS PASS PASS PASS FAIL
nptl/tst-initializers1 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-c11 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-c89 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-c99 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-gnu11 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-gnu89 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-gnu99 PASS PASS PASS PASS FAIL
nptl/tst-join5 PASS PASS PASS PASS FAIL
nptl/tst-key3 PASS PASS PASS PASS FAIL
nptl/tst-mutex8 PASS PASS PASS PASS FAIL
nptl/tst-mutexpi8 PASS PASS PASS PASS FAIL
nptl/tst-once3 PASS PASS PASS PASS FAIL
nptl/tst-once4 PASS PASS PASS PASS FAIL
nptl/tst-oncex3 PASS PASS PASS PASS FAIL
nptl/tst-oncex4 PASS PASS PASS PASS FAIL
nptl/tst-rwlock15 PASS PASS PASS PASS FAIL
nptl/tst-rwlock8 PASS PASS PASS PASS FAIL
nptl/tst-rwlock9 PASS PASS PASS PASS FAIL
nptl/tst-sem11 PASS PASS PASS PASS FAIL
nptl/tst-sem12 PASS PASS PASS PASS FAIL
posix/bug-regex24 PASS PASS PASS PASS FAIL
rt/tst-mqueue1 PASS PASS PASS PASS FAIL
rt/tst-mqueue2 PASS PASS PASS PASS FAIL
rt/tst-mqueue4 PASS PASS PASS PASS FAIL
rt/tst-mqueue7 PASS PASS PASS PASS FAIL
rt/tst-mqueue8 PASS PASS PASS PASS FAIL
rt/tst-mqueue8x PASS PASS PASS PASS FAIL
stdlib/tst-makecontext3 PASS PASS PASS PASS FAIL
^ permalink raw reply
* Re: [Qemu-devel] [Qemu-block] [PATCH] Added iopmem device emulation
From: Stefan Hajnoczi @ 2016-11-09 9:58 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Kevin Wolf, Max Reitz, Michael S. Tsirkin, Marcel Apfelbaum,
qemu-devel, qemu-block, Stephen Bates
In-Reply-To: <b15f8110-78e8-ef79-3ed5-449cf3dd7602@deltatee.com>
[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]
On Tue, Nov 08, 2016 at 09:46:47AM -0700, Logan Gunthorpe wrote:
> On 08/11/16 08:58 AM, Stefan Hajnoczi wrote:
> > My concern with the current implementation is that a PCI MMIO access
> > invokes a synchronous blk_*() call. That can pause vcpu execution while
> > I/O is happening and therefore leads to unresponsive guests. QEMU's
> > monitor interface is also blocked during blk_*() making it impossible to
> > troubleshoot QEMU if it gets stuck due to a slow/hung I/O operation.
> >
> > Device models need to use blk_aio_*() so that control is returned while
> > I/O is running. There are a few legacy devices left that use
> > synchronous I/O but new devices should not use this approach.
>
> That's fair. I wasn't aware of this and I must have copied a legacy
> device. We can certainly make the change in our patch.
>
> > Regarding the hardware design, I think the PCI BAR approach to nvdimm is
> > inefficient for virtualization because each memory load/store requires a
> > guest<->host transition (vmexit + vmenter). A DMA approach (i.e.
> > message passing or descriptor rings) is more efficient because it
> > requires fewer vmexits.
> >
> > On real hardware the performance characteristics are different so it
> > depends what your target market is.
>
> The performance of the virtual device is completely unimportant. This
> isn't something I'd expect anyone to use except to test drivers. On real
> hardware, with real applications, DMA would almost certainly be used --
> but it would be the DMA engine in another device. eg. an IB NIC would
> DMA from the PCI BAR of the iopmem device. This completely bypasses the
> CPU so there would be no load/stores to be concerned about.
Okay, sounds good.
Is there a reason to use the block layer in QEMU? Perhaps it's better
to do the same as the nvdimm device in QEMU and use a memory backend
instead. The memory backend can be MAP_PRIVATE or MAP_SHARED. It can
be anonymous memory or it can be backed by a real file. This gives you
options can avoids using the QEMU block layer in a way it wasn't
designed.
Doing this would forgo QEMU block layer features like image file formats
(qcow2), block jobs (storage migration), etc. But those probably aren't
necessary for this device.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCHv2 32/36] pathspec: allow querying for attributes
From: Duy Nguyen @ 2016-11-09 9:57 UTC (permalink / raw)
To: Stefan Beller; +Cc: Junio C Hamano, Brandon Williams, Git Mailing List
In-Reply-To: <20161028185502.8789-33-sbeller@google.com>
On Sat, Oct 29, 2016 at 1:54 AM, Stefan Beller <sbeller@google.com> wrote:
> The pathspec mechanism is extended via the new
> ":(attr:eol=input)pattern/to/match" syntax to filter paths so that it
> requires paths to not just match the given pattern but also have the
> specified attrs attached for them to be chosen.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/glossary-content.txt | 20 +++++
> dir.c | 35 ++++++++
Pathspec can be processed in a couple more places. The big two are
match_pathspec and tree_entry_interesting, the former traverses a list
while the latter does a tree. You don't have to implement attr
matching in tree_entry_interesting right now because nobody needs it,
probably. But you need to make sure if somebody accidentally calls
tree_entry_interesting with an attr pathspec, then it should
die("BUG"), not silently ignore attr.
The way to do that is GUARD_PATHSPEC macro which makes sure if only
recognized magic is allowed through. This macro guards all pathspec
processing functions. So you can add a new PATHSPEC_ATTR macro (or
some other name) to the "Pathspec magic" group near the beginning of
pathspec.h, set it whenever attr magic is present when you
parse_pathspec(), then lift the GUARD_PATHSPEC restriction in
match_pathspec() only because this function can handle it. Whenever
attr magic is used by any other functions, it will die() the way we
want.
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.