Re: [PATCH RFC] Fix "/usr/bin/xargs: rm: Argument list too long" during make distclean
On 8/13/2012 5:01 PM, H. Peter Anvin wrote: > On 08/13/2012 01:56 PM, David Cullen wrote: >>> >>> That sounds like a bug in xargs... >>> >> >> In my specific case, qemu-arm-static calls xargs (In fact, in my >> cross chroot, qemu-arm-static is used to run every user mode process). >> >> Do you mean that qemu-arm-static is exposing a latent defect in xargs? >> >> Does qemu-arm-static steal some of the command line space that would >> normally be available for xargs? If so, how would xargs figure out >> this was happening and handle the problem? >> > > I have no idea. Perhaps strace can help you see what is happening, I > don't know. More likely it is qemu-arm-static that is broken and it is > trying to enforce the old 128K limit that we used to have before 2.6.23. > This could cause a mismatch between what sysconf(_SC_ARG_MAX) returns > and what the actual limit is. > > Anyway, even more so the reason to reject this patch. I submitted a bug report on xargs: http://savannah.gnu.org/bugs/index.php?37093 I also submitted a bug report on QEMU: https://bugs.launchpad.net/qemu/+bug/1036645
Re: [PATCH RFC] Fix /usr/bin/xargs: rm: Argument list too long during make distclean
On 8/13/2012 5:01 PM, H. Peter Anvin wrote: On 08/13/2012 01:56 PM, David Cullen wrote: That sounds like a bug in xargs... In my specific case, qemu-arm-static calls xargs (In fact, in my cross chroot, qemu-arm-static is used to run every user mode process). Do you mean that qemu-arm-static is exposing a latent defect in xargs? Does qemu-arm-static steal some of the command line space that would normally be available for xargs? If so, how would xargs figure out this was happening and handle the problem? I have no idea. Perhaps strace can help you see what is happening, I don't know. More likely it is qemu-arm-static that is broken and it is trying to enforce the old 128K limit that we used to have before 2.6.23. This could cause a mismatch between what sysconf(_SC_ARG_MAX) returns and what the actual limit is. Anyway, even more so the reason to reject this patch. I submitted a bug report on xargs: http://savannah.gnu.org/bugs/index.php?37093 I also submitted a bug report on QEMU: https://bugs.launchpad.net/qemu/+bug/1036645
Re: [PATCH RFC] Fix "/usr/bin/xargs: rm: Argument list too long" during make distclean
On 8/13/2012 4:38 PM, H. Peter Anvin wrote: > On 08/13/2012 12:39 PM, David Cullen wrote: >> When running "make distclean" in a cross chroot environment, the >> following messages are emitted: >> >> [user@host:/home/work/linux]: make distclean >> /usr/bin/xargs: rm: Argument list too long >> make: *** [clean] Error 126 >> > > That sounds like a bug in xargs... > > -hpa > In my specific case, qemu-arm-static calls xargs (In fact, in my cross chroot, qemu-arm-static is used to run every user mode process). Do you mean that qemu-arm-static is exposing a latent defect in xargs? Does qemu-arm-static steal some of the command line space that would normally be available for xargs? If so, how would xargs figure out this was happening and handle the problem? -- Thank you, David Cullen
[PATCH RFC] Fix "/usr/bin/xargs: rm: Argument list too long" during make distclean
When running "make distclean" in a cross chroot environment, the following messages are emitted: [user@host:/home/work/linux]: make distclean /usr/bin/xargs: rm: Argument list too long make: *** [clean] Error 126 I use the following patch to get around the problem: diff --git a/Makefile b/Makefile index b771af5..e2bca8e 100644 --- a/Makefile +++ b/Makefile @@ -1033,7 +1033,7 @@ distclean: mrproper -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \ -o -name '.*.rej' \ -o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \ - -type f -print | xargs rm -f + -type f -print | xargs -s 122880 rm -f # Packaging of the kernel to various formats @@ -1242,7 +1242,7 @@ clean: $(clean-dirs) -o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \ -o -name '*.symtypes' -o -name 'modules.order' \ -o -name modules.builtin -o -name '.tmp_*.o.*' \ - -o -name '*.gcno' \) -type f -print | xargs rm -f + -o -name '*.gcno' \) -type f -print | xargs -s 122880 rm -f # Generate tags for editors # --- Is there another way to solve this problem that does not require a patch to the Makefile? -- 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 RFC] Fix /usr/bin/xargs: rm: Argument list too long during make distclean
When running make distclean in a cross chroot environment, the following messages are emitted: [user@host:/home/work/linux]: make distclean /usr/bin/xargs: rm: Argument list too long make: *** [clean] Error 126 I use the following patch to get around the problem: diff --git a/Makefile b/Makefile index b771af5..e2bca8e 100644 --- a/Makefile +++ b/Makefile @@ -1033,7 +1033,7 @@ distclean: mrproper -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \ -o -name '.*.rej' \ -o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \ - -type f -print | xargs rm -f + -type f -print | xargs -s 122880 rm -f # Packaging of the kernel to various formats @@ -1242,7 +1242,7 @@ clean: $(clean-dirs) -o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \ -o -name '*.symtypes' -o -name 'modules.order' \ -o -name modules.builtin -o -name '.tmp_*.o.*' \ - -o -name '*.gcno' \) -type f -print | xargs rm -f + -o -name '*.gcno' \) -type f -print | xargs -s 122880 rm -f # Generate tags for editors # --- Is there another way to solve this problem that does not require a patch to the Makefile? -- 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 RFC] Fix /usr/bin/xargs: rm: Argument list too long during make distclean
On 8/13/2012 4:38 PM, H. Peter Anvin wrote: On 08/13/2012 12:39 PM, David Cullen wrote: When running make distclean in a cross chroot environment, the following messages are emitted: [user@host:/home/work/linux]: make distclean /usr/bin/xargs: rm: Argument list too long make: *** [clean] Error 126 That sounds like a bug in xargs... -hpa In my specific case, qemu-arm-static calls xargs (In fact, in my cross chroot, qemu-arm-static is used to run every user mode process). Do you mean that qemu-arm-static is exposing a latent defect in xargs? Does qemu-arm-static steal some of the command line space that would normally be available for xargs? If so, how would xargs figure out this was happening and handle the problem? -- Thank you, David Cullen
[PATCH] Fix error: unknown field reclaim_buffers specified in initializer
The reclaim_buffers field has been removed from struct drm_driver.
Signed-off-by: David Cullen
---
drivers/staging/omapdrm/omap_drv.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 4beab94..44149ee 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -761,7 +761,6 @@ static struct drm_driver omap_drm_driver = {
.irq_postinstall = dev_irq_postinstall,
.irq_uninstall = dev_irq_uninstall,
.irq_handler = dev_irq_handler,
- .reclaim_buffers = drm_core_reclaim_buffers,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = omap_debugfs_init,
.debugfs_cleanup = omap_debugfs_cleanup,
--
1.7.9.5--
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/
[RFC PATCHv2] QEMU Fix /usr/bin/xargs: etags: Argument list too long
Patch applies to
commit 42a579a0f960081cd16fc945036e4780c3ad3202
When running "make ARCH=arm TAGS" in a cross chroot using
qemu-arm-static, the following message is emitted:
[user@host:/home/work/linux]: make ARCH=arm TAGS
GEN TAGS
/usr/bin/xargs: etags: Argument list too long
This can be fixed by by passing "-s $((120 * 1024))" to xargs in
scripts/tags.sh when QEMU matches .*qemu-.*-static$.
This limits the xargs command line to 120KiB characters to provide
headroom for people running inside a cross chroot using
qemu-.*-static.
Signed-off-by: David Cullen
---
scripts/tags.sh | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index cff8faa..02947c5 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -5,12 +5,19 @@
# mode may be any of: tags, TAGS, cscope
#
# Uses the following environment variables:
-# ARCH, SUBARCH, SRCARCH, srctree, src, obj
+# ARCH, SUBARCH, SRCARCH, srctree, src, obj, QEMU
if [ "$KBUILD_VERBOSE" = "1" ]; then
set -x
fi
+# If the user is running in a cross chroot using qemu-.*-static,
+# limit xargs to 120KiB of characters per command line.
+XARGS_MAX_CHARS=
+if [ -n "$QEMU" ] && [[ "$QEMU" =~ .*qemu-.*-static$ ]] ; then
+ XARGS_MAX_CHARS="-s $(( 120 * 1024 ))"
+fi
+
# This is a duplicate of RCS_FIND_IGNORE without escaped '()'
ignore="( -name SCCS -o -name BitKeeper -o -name .svn -o \
-name CVS -o -name .pc -o -name .hg -o \
@@ -121,7 +128,7 @@ dogtags()
exuberant()
{
- all_sources | xargs $1 -a \
+ all_sources | xargs $XARGS_MAX_CHARS $1 -a \
-I __initdata,__exitdata,__acquires,__releases \
-I __read_mostly,cacheline_aligned \
-I cacheline_aligned_in_smp \
--
1.7.9.5--
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: [RFC PATCH] ARM Fix /usr/bin/xargs: etags: Argument list too long
On 8/8/2012 10:41 AM, Michal Marek wrote: > Dne 8.8.2012 16:32, David Cullen napsal(a): >> Patch applies to >> >> commit 42a579a0f960081cd16fc945036e4780c3ad3202 >> >> When running "make ARCH=arm TAGS" in a chroot using qemu-arm-static, >> the following message is emitted: >> >> [user@host:/home/work/linux]: make ARCH=arm TAGS >> GEN TAGS >> /usr/bin/xargs: etags: Argument list too long >> >> This can be fixed by by passing "-L 1024" to xargs in scripts/tags.sh. >> >> The "1024" was a guess. A value of "3862" changes the message to >> >> /usr/bin/xargs: argument list too long >> >> Using "2048" also fixes the problem. However, I don't know how much >> headroom that leaves >> >> Does anyone know why the argument lists must be shorter for ARM? All >> of the documentation I have available says that 4096 should be the >> limit. > > This looks like a bug in xargs, it should make sure that the commandline > fits into ARG_MAX. Actually, it appears to be caused by the combination of qemu-arm-static and xargs. When I run "make ARCH=arm TAGS" on an ARM target, I do not see the problem. > BTW, a better workaround would be to use the -s option, which > limits the size of the argument list. That works. I'll submit another RFC patch. -- Thank you, David Cullen-- 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/
[RFC PATCH] ARM Fix /usr/bin/xargs: etags: Argument list too long
Patch applies to
commit 42a579a0f960081cd16fc945036e4780c3ad3202
When running "make ARCH=arm TAGS" in a chroot using qemu-arm-static,
the following message is emitted:
[user@host:/home/work/linux]: make ARCH=arm TAGS
GEN TAGS
/usr/bin/xargs: etags: Argument list too long
This can be fixed by by passing "-L 1024" to xargs in scripts/tags.sh.
The "1024" was a guess. A value of "3862" changes the message to
/usr/bin/xargs: argument list too long
Using "2048" also fixes the problem. However, I don't know how much
headroom that leaves
Does anyone know why the argument lists must be shorter for ARM? All
of the documentation I have available says that 4096 should be the
limit.
Signed-off-by: David Cullen
---
scripts/tags.sh |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index cff8faa..7f4ebb3 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -121,7 +121,7 @@ dogtags()
exuberant()
{
- all_sources | xargs $1 -a \
+ all_sources | xargs -L 1024 $1 -a \
-I __initdata,__exitdata,__acquires,__releases \
-I __read_mostly,cacheline_aligned \
-I cacheline_aligned_in_smp \
--
1.7.9.5--
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/
[RFC PATCH] ARM Fix /usr/bin/xargs: etags: Argument list too long
Patch applies to
commit 42a579a0f960081cd16fc945036e4780c3ad3202
When running make ARCH=arm TAGS in a chroot using qemu-arm-static,
the following message is emitted:
[user@host:/home/work/linux]: make ARCH=arm TAGS
GEN TAGS
/usr/bin/xargs: etags: Argument list too long
This can be fixed by by passing -L 1024 to xargs in scripts/tags.sh.
The 1024 was a guess. A value of 3862 changes the message to
/usr/bin/xargs: argument list too long
Using 2048 also fixes the problem. However, I don't know how much
headroom that leaves
Does anyone know why the argument lists must be shorter for ARM? All
of the documentation I have available says that 4096 should be the
limit.
Signed-off-by: David Cullen david.cul...@koe-americas.com
---
scripts/tags.sh |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index cff8faa..7f4ebb3 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -121,7 +121,7 @@ dogtags()
exuberant()
{
- all_sources | xargs $1 -a \
+ all_sources | xargs -L 1024 $1 -a \
-I __initdata,__exitdata,__acquires,__releases \
-I __read_mostly,cacheline_aligned \
-I cacheline_aligned_in_smp \
--
1.7.9.5--
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: [RFC PATCH] ARM Fix /usr/bin/xargs: etags: Argument list too long
On 8/8/2012 10:41 AM, Michal Marek wrote: Dne 8.8.2012 16:32, David Cullen napsal(a): Patch applies to commit 42a579a0f960081cd16fc945036e4780c3ad3202 When running make ARCH=arm TAGS in a chroot using qemu-arm-static, the following message is emitted: [user@host:/home/work/linux]: make ARCH=arm TAGS GEN TAGS /usr/bin/xargs: etags: Argument list too long This can be fixed by by passing -L 1024 to xargs in scripts/tags.sh. The 1024 was a guess. A value of 3862 changes the message to /usr/bin/xargs: argument list too long Using 2048 also fixes the problem. However, I don't know how much headroom that leaves Does anyone know why the argument lists must be shorter for ARM? All of the documentation I have available says that 4096 should be the limit. This looks like a bug in xargs, it should make sure that the commandline fits into ARG_MAX. Actually, it appears to be caused by the combination of qemu-arm-static and xargs. When I run make ARCH=arm TAGS on an ARM target, I do not see the problem. BTW, a better workaround would be to use the -s option, which limits the size of the argument list. That works. I'll submit another RFC patch. -- Thank you, David Cullen-- 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/
[RFC PATCHv2] QEMU Fix /usr/bin/xargs: etags: Argument list too long
Patch applies to
commit 42a579a0f960081cd16fc945036e4780c3ad3202
When running make ARCH=arm TAGS in a cross chroot using
qemu-arm-static, the following message is emitted:
[user@host:/home/work/linux]: make ARCH=arm TAGS
GEN TAGS
/usr/bin/xargs: etags: Argument list too long
This can be fixed by by passing -s $((120 * 1024)) to xargs in
scripts/tags.sh when QEMU matches .*qemu-.*-static$.
This limits the xargs command line to 120KiB characters to provide
headroom for people running inside a cross chroot using
qemu-.*-static.
Signed-off-by: David Cullen david.cul...@koe-americas.com
---
scripts/tags.sh | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index cff8faa..02947c5 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -5,12 +5,19 @@
# mode may be any of: tags, TAGS, cscope
#
# Uses the following environment variables:
-# ARCH, SUBARCH, SRCARCH, srctree, src, obj
+# ARCH, SUBARCH, SRCARCH, srctree, src, obj, QEMU
if [ $KBUILD_VERBOSE = 1 ]; then
set -x
fi
+# If the user is running in a cross chroot using qemu-.*-static,
+# limit xargs to 120KiB of characters per command line.
+XARGS_MAX_CHARS=
+if [ -n $QEMU ] [[ $QEMU =~ .*qemu-.*-static$ ]] ; then
+ XARGS_MAX_CHARS=-s $(( 120 * 1024 ))
+fi
+
# This is a duplicate of RCS_FIND_IGNORE without escaped '()'
ignore=( -name SCCS -o -name BitKeeper -o -name .svn -o \
-name CVS -o -name .pc -o -name .hg -o \
@@ -121,7 +128,7 @@ dogtags()
exuberant()
{
- all_sources | xargs $1 -a \
+ all_sources | xargs $XARGS_MAX_CHARS $1 -a \
-I __initdata,__exitdata,__acquires,__releases \
-I __read_mostly,cacheline_aligned \
-I cacheline_aligned_in_smp \
--
1.7.9.5--
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] Fix error: unknown field reclaim_buffers specified in initializer
The reclaim_buffers field has been removed from struct drm_driver.
Signed-off-by: David Cullen david.cul...@koe-americas.com
---
drivers/staging/omapdrm/omap_drv.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 4beab94..44149ee 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -761,7 +761,6 @@ static struct drm_driver omap_drm_driver = {
.irq_postinstall = dev_irq_postinstall,
.irq_uninstall = dev_irq_uninstall,
.irq_handler = dev_irq_handler,
- .reclaim_buffers = drm_core_reclaim_buffers,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = omap_debugfs_init,
.debugfs_cleanup = omap_debugfs_cleanup,
--
1.7.9.5--
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: [git pull] x86 arch updates for v2.6.25
Dear Kernel Maintainers, I am with Phil Oester and Andrew Morton when it comes to getting kgdb into the mainline kernel. I _am_ a full time developer, and when I have to work with Linux kernel code, kgdb makes things a lot easier. I work on many different platforms, with many different operating systems, and there just is not enough time in the day to learn every line of every version of the kernel. kgdb allows me to get in, see what I need, and get out. That being said, if kgdb _does_ become mainline, and people are able to get more visibility into how the kernel works in real time, you will probably see more exploits. This may be the secret reason for reluctance by the powers on high. CC me if you want me to see your reply as I am not on the list. -- Thank you, David Cullen [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] x86 arch updates for v2.6.25
Dear Kernel Maintainers, I am with Phil Oester and Andrew Morton when it comes to getting kgdb into the mainline kernel. I _am_ a full time developer, and when I have to work with Linux kernel code, kgdb makes things a lot easier. I work on many different platforms, with many different operating systems, and there just is not enough time in the day to learn every line of every version of the kernel. kgdb allows me to get in, see what I need, and get out. That being said, if kgdb _does_ become mainline, and people are able to get more visibility into how the kernel works in real time, you will probably see more exploits. This may be the secret reason for reluctance by the powers on high. CC me if you want me to see your reply as I am not on the list. -- Thank you, David Cullen [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
