Re: [PATCH v7 2/2] Kbuild: implement support for DWARF v5

2021-02-03 Thread Jakub Jelinek
On Thu, Feb 04, 2021 at 08:06:12AM +0900, Masahiro Yamada wrote: > GCC never outputs '.file 0', which is why > this test is only needed for Clang, correct? No, GCC outputs .file 0 if it during configure time detected assembler that supports it and doesn't have any of the known bugs related to it.

Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5

2021-01-29 Thread Jakub Jelinek
On Fri, Jan 29, 2021 at 02:05:59PM -0800, Nick Desaulniers wrote: > Ah, I see. Then I should update the script I add > (scripts/test_dwarf5_support.sh) to feature detect that bug, since > it's the latest of the bunch. Also, should update my comment to note > that this requires binutils greater th

Re: [PATCH v6 1/2] Kbuild: make DWARF version a choice

2021-01-29 Thread Jakub Jelinek
On Fri, Jan 29, 2021 at 04:32:32PM -0500, Arvind Sankar wrote: > Given what Jakub is saying, i.e. it was previously impossible to get > dwarf2 with gcc, and you get dwarf4 whether or not DEBUG_INFO_DWARF4 was It isn't impossible to get it, -gdwarf-2 works, it is just not a very good choice (at lea

Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5

2021-01-29 Thread Jakub Jelinek
On Fri, Jan 29, 2021 at 01:05:56PM -0800, Nick Desaulniers wrote: > > Wasn't that fixed in GAS? > > https://sourceware.org/bugzilla/show_bug.cgi?id=27195 > > $ make LLVM=1 -j72 defconfig > $ ./scripts/config -e DEBUG_INFO -e DEBUG_INFO_DWARF5 > $ make LLVM=1 -j72 > ... > /tmp/init-d50d89.s: Assemb

Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5

2021-01-29 Thread Jakub Jelinek
On Fri, Jan 29, 2021 at 12:48:11PM -0800, Nick Desaulniers wrote: > > Should this be...? > > > > KBUILD_AFLAGS += -Wa,-gdwarf-5 > > No; under the set of conditions Clang is compiling .c to .S with DWARF > v5 assembler directives. GAS will choke unless told -gdwarf-5 via > -Wa,-gdwarf-5 for .c sour

Re: [PATCH v6 1/2] Kbuild: make DWARF version a choice

2021-01-29 Thread Jakub Jelinek
On Fri, Jan 29, 2021 at 11:43:17AM -0800, Nick Desaulniers wrote: > Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an > explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a > way that's forward compatible with existing configs, and makes adding > future versions

Re: [PATCH] ilog2: Improve ilog2 for constant arguments

2020-11-21 Thread Jakub Jelinek
On Sat, Nov 21, 2020 at 09:23:10PM +0100, Luc Van Oostenryck wrote: > On Fri, Nov 20, 2020 at 01:51:54PM +0100, Peter Zijlstra wrote: > > > > Other option would be to change the const_ilog2 macro, though as the > > description says it is meant to be used also in C constant expressions, > > and whi

[tip: core/core] ilog2 vs. GCC inlining heuristics

2020-11-20 Thread tip-bot2 for Jakub Jelinek
The following commit has been merged into the core/core branch of tip: Commit-ID: ecbd43f6728a5cf79c8b50ed326658e9181531b1 Gitweb: https://git.kernel.org/tip/ecbd43f6728a5cf79c8b50ed326658e9181531b1 Author:Jakub Jelinek AuthorDate:Wed, 21 Oct 2020 15:27:18 +02:00

Re: [PATCH] Kbuild: implement support for DWARF5

2020-11-04 Thread Jakub Jelinek
On Tue, Nov 03, 2020 at 02:21:22PM -0800, Nick Desaulniers wrote: > > > This script fails for GCC 10. > > > > One thing is GCC DWARF-5 support, that is whether the compiler > > will support -gdwarf-5 flag, and that support should be there from > > GCC 7 onwards. > > I should improve my Kconfig che

Re: [PATCH] Kbuild: implement support for DWARF5

2020-11-02 Thread Jakub Jelinek
On Mon, Nov 02, 2020 at 11:20:41AM +0900, Masahiro Yamada wrote: > > --- /dev/null > > +++ b/scripts/test_dwarf5_support.sh > > @@ -0,0 +1,4 @@ > > +#!/bin/sh > > +# SPDX-License-Identifier: GPL-2.0 > > +set -eu > > +echo ".file 0 \"asdf\"" | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null - > > >

Re: GCC section alignment, and GCC-4.9 being a weird one

2020-10-21 Thread Jakub Jelinek
On Wed, Oct 21, 2020 at 10:00:31AM +0200, Peter Zijlstra wrote: > On Tue, Oct 20, 2020 at 04:39:38PM -0700, Florian Fainelli wrote: > > This patch causes all files under kernel/sched/* that include sched.h to > > be rebuilt whenever the value of CONFIG_BLK_DEV_INITRD. There are at > > least two bui

Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

2017-12-20 Thread Jakub Jelinek
On Wed, Dec 20, 2017 at 09:52:05PM +0100, Arnd Bergmann wrote: > diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c > index ca554d57d01e..35f973ba9878 100644 > --- a/crypto/aes_generic.c > +++ b/crypto/aes_generic.c > @@ -1331,6 +1331,20 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key); > f_rl(

Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

2016-08-20 Thread Jakub Jelinek
On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote: > You have to save the stack pointer at the setjmp point too. And there > might be other architecture-specific ABI rules for that. But you're > right, it might be worth it. > > I *would* be a bit worried about code generation issues.

Re: Q: why didn't GCC warn about this uninitialized variable? (was: Re: [PATCH] perf tests: initialize sa.sa_flags)

2016-03-03 Thread Jakub Jelinek
On Thu, Mar 03, 2016 at 02:47:16PM +0100, Ingo Molnar wrote: > I tried to distill a testcase out of it, and the following silly hack seems > to > trigger it: ... This is a known issue, which we don't have a solution for yet. The thing is, GCC has 2 uninitialized warning passes, one is done very

Re: Q: why didn't GCC warn about this uninitialized variable? (was: Re: [PATCH] perf tests: initialize sa.sa_flags)

2016-03-03 Thread Jakub Jelinek
On Thu, Mar 03, 2016 at 02:24:34PM +0100, Ingo Molnar wrote: > 6 hours of PeterZ time translates to quite a bit of code restructuring > overhead to > eliminate false positive warnings... I'll file a bugzilla enhancement request for this (with new attribute), perhaps we could do it in FRE that is

Re: Q: why didn't GCC warn about this uninitialized variable? (was: Re: [PATCH] perf tests: initialize sa.sa_flags)

2016-03-03 Thread Jakub Jelinek
On Thu, Mar 03, 2016 at 01:19:44PM +0100, Ingo Molnar wrote: > struct sigaction sa; > > ... > > sigfillset(&sa.sa_mask); > sa.sa_sigaction = segfault_handler; > sigaction(SIGSEGV, &sa, NULL); > > ... which uninitialized sa.sa_flags field GCC merrily accepted

Re: gcc feature request / RFC: extra clobbered regs

2015-07-01 Thread Jakub Jelinek
On Wed, Jul 01, 2015 at 01:35:16PM -0400, Vladimir Makarov wrote: > Actually it raise a question for me. If we describe that a function > clobbers more than calling convention and then use it as a value (assigning > a variable or passing as an argument) and loosing a track of it and than > call it

Re: gcc feature request / RFC: extra clobbered regs

2015-07-01 Thread Jakub Jelinek
On Wed, Jul 01, 2015 at 11:23:17AM -0400, Vladimir Makarov wrote: > >>(I'm not necessarily suggesting that we do this for the syscall bodies > >>themselves. I want to do it for the entry and exit helpers, so we'd > >>still lose the five cycles in the full fast-path case, but we'd do > >>better in

Re: gcc feature request / RFC: extra clobbered regs

2015-06-30 Thread Jakub Jelinek
On Tue, Jun 30, 2015 at 02:22:33PM -0700, Andy Lutomirski wrote: > I'm working on a massive set of cleanups to Linux's syscall handling. > We currently have a nasty optimization in which we don't save rbx, > rbp, r12, r13, r14, and r15 on x86_64 before calling C functions. > This works, but it make

Re: [PATCH] x86: Optimize variable_test_bit()

2015-05-01 Thread Jakub Jelinek
On Fri, May 01, 2015 at 09:03:32AM -0700, Linus Torvalds wrote: > > PPS. Jakub, I see gcc5.1 still hasn't got output operands for asm goto; > > is this something we can get 'fixed' ? CCing Richard as author of asm goto and Vlad as register allocator maintainer. There are a few enhancement re

Re: bit fields && data tearing

2014-09-04 Thread Jakub Jelinek
On Thu, Sep 04, 2014 at 08:24:12AM -0400, Peter Hurley wrote: > And I just confirmed with the Alpha cross-compiler that the fields are > not 'padded out' if volatile either. They can't be, struct layout is part of the ABI. Guess you can introduce say atomic_bool and similar typedefs which would be

Re: bit fields && data tearing

2014-09-04 Thread Jakub Jelinek
On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote: > Benjamin Herrenschmidt writes: > > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote: > > > > > Apologies for hijacking this thread but I need to extend this discussion > > > somewhat regarding what a compiler might do wi

Re: [PATCH] gcc version 5: add basic definition header for latest gcc version

2014-08-15 Thread Jakub Jelinek
On Fri, Aug 15, 2014 at 03:23:01PM -0400, Paul Gortmaker wrote: > --- /dev/null > +++ b/include/linux/compiler-gcc5.h > @@ -0,0 +1,52 @@ > +#ifndef __LINUX_COMPILER_H > +#error "Please don't include directly, include > instead." > +#endif > + > +#define __used __attribute__

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

2014-08-06 Thread Jakub Jelinek
On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote: > On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler wrote: > > > > Actually, "perf probe" does (via HAVE_DWARF_SUPPORT), to place probes > > and to extract variables at those probes, much as systemtap does. > > Without var-tracking, pr

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

2014-08-05 Thread Jakub Jelinek
On Tue, Aug 05, 2014 at 01:46:49PM +0200, Markus Trippelsdorf wrote: > On 2014.08.05 at 07:31 -0400, Josh Boyer wrote: > > Sorry to bring this back up after the fact, but it's important for a > > number of things in various distros. I don't disagree it should be > > disabled by default, but making

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

2014-07-30 Thread Jakub Jelinek
On Wed, Jul 30, 2014 at 09:13:08AM +0200, Markus Trippelsdorf wrote: > On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote: > > On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote: > > > 3.15-stable review patch. If anyone has any objections, please

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

2014-07-29 Thread Jakub Jelinek
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote: > 3.15-stable review patch. If anyone has any objections, please let me know. IMNSHO this is a too big hammer approach. The bug happened on a single file only (right?), so if anything, IMHO it could be disabled for that single f

Re: Random panic in load_balance() with 3.16-rc

2014-07-29 Thread Jakub Jelinek
On Mon, Jul 28, 2014 at 08:09:02PM +0200, Markus Trippelsdorf wrote: > Here's the testcase: > > int a, b, c; > void fn1 () > { > int d; > if (fn2 () && !0) > { > b = ( >{ >int e; >fn3 (); >switch (0) >default: >a

Re: Random panic in load_balance() with 3.16-rc

2014-07-26 Thread Jakub Jelinek
On Sat, Jul 26, 2014 at 10:20:55PM +0200, Markus Trippelsdorf wrote: > On 2014.07.26 at 15:55 -0400, Theodore Ts'o wrote: > > On Sat, Jul 26, 2014 at 09:35:57PM +0200, Markus Trippelsdorf wrote: > > > > > > But fortunately the workaround for the new inode.c bug is the same as > > > for the origina

Re: Random panic in load_balance() with 3.16-rc

2014-07-25 Thread Jakub Jelinek
On Fri, Jul 25, 2014 at 01:01:11PM -0700, Linus Torvalds wrote: > For example, gcc will not create a small stack frame with "sub > $8,%rsp". No, what gcc does is to use a random "push" instruction. > Fair enough, but that really makes things much harder to see. Here's > an example: That is because

Re: Random panic in load_balance() with 3.16-rc

2014-07-24 Thread Jakub Jelinek
On Thu, Jul 24, 2014 at 11:47:17AM -0700, Linus Torvalds wrote: > Adding Jakub to the cc, because gcc-4.9.0 seems to be terminally broken. ... > Jakub, any ideas? Can I ask anyone involved in this for preprocessed source and all gcc command line options to reproduce it, best in the form of a http:

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Jakub Jelinek
On Tue, Jun 10, 2014 at 05:13:29PM +0200, Peter Zijlstra wrote: > On Tue, Jun 10, 2014 at 05:04:55PM +0200, Marek Polacek wrote: > > On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote: > > > On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote: > > > > +# Tell gcc to never replac

Re: [tip:x86/urgent] compiler/gcc4: Make quirk for asm_volatile_goto( ) unconditional

2014-02-13 Thread Jakub Jelinek
On Thu, Feb 13, 2014 at 03:37:08AM -0800, tip-bot for Steven Noonan wrote: > Commit-ID: a9f180345f5378ac87d80ed0bea55ba421d83859 > Gitweb: http://git.kernel.org/tip/a9f180345f5378ac87d80ed0bea55ba421d83859 > Author: Steven Noonan > AuthorDate: Wed, 12 Feb 2014 23:01:07 -0800 > Committer:

Re: [GIT PULL] compiler/gcc4: Add quirk for 'asm goto' miscompilation bug

2014-02-12 Thread Jakub Jelinek
On Wed, Feb 12, 2014 at 08:11:49PM -0800, Linus Torvalds wrote: > Jakub, any suggestions to how Steven might be able to pinpoint where > the code generation problem lies? For a suspected wrong-code where you have no idea where the problem is from debugging or oops etc., usually the best way is to

Re: current_thread_info() not respecting program order with gcc 4.8.x

2013-11-19 Thread Jakub Jelinek
On Tue, Nov 19, 2013 at 04:57:49PM +0100, Peter Zijlstra wrote: > On Tue, Nov 19, 2013 at 03:29:12PM +, Mathieu Desnoyers wrote: > > However, looking at ARM arch/arm/include/asm/thread_info.h: > > > > static inline struct thread_info *current_thread_info(void) { register > > unsigned long sp a

Re: [PATCH] gcc4: Add 'asm goto' miscompilation quirk

2013-10-10 Thread Jakub Jelinek
On Thu, Oct 10, 2013 at 07:04:18AM -0700, Richard Henderson wrote: > On 10/10/2013 01:31 AM, Jakub Jelinek wrote: > > Also, for the bitops patch, you probably want an asm_volatile_goto variant. > > Why? Asm without output (which asm goto must be) are automatically volatile

Re: [PATCH, -v2] compiler/gcc4: Add quirk for 'asm goto' miscompilation bug

2013-10-10 Thread Jakub Jelinek
70 > > + * > > + * Work it around via quirk suggested by Jakub Jelinek. > > + * Fixed in GCC 4.8.2 and later versions. > > + */ > > +#if GCC_VERSION <= 40801 > > We didn't do version checks for CC_HAVE_ASM_GOTO because of vendor > backports; can't

Re: [PATCH] gcc4: Add 'asm goto' miscompilation quirk

2013-10-10 Thread Jakub Jelinek
nces: > + * > + * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 > + * > + * Work it around via quirk suggested by Jakub Jelinek. > + * Not yet fixed, so use the quirk on all compiler versions: > + */ > +#if GCC_VERSION <= 9 > +# define asm_goto(x...) do { asm goto(

Re: [x86] BUG: unable to handle kernel paging request at 00740060

2013-10-10 Thread Jakub Jelinek
On Thu, Oct 10, 2013 at 08:51:04AM +0200, Jakub Jelinek wrote: > @@ -8,6 +8,7 @@ foo (int a, int b) >asm volatile goto ("bts $1, %0; jc %l[lab]" : : "m" (b) : "memory" : lab); >return 0; > lab: > + asm (""); >return 0; >

Re: [x86] BUG: unable to handle kernel paging request at 00740060

2013-10-09 Thread Jakub Jelinek
On Thu, Oct 10, 2013 at 08:22:38AM +0200, Ingo Molnar wrote: > > On Wed, Oct 09, 2013 at 09:02:31PM +0200, Peter Zijlstra wrote: > > > On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote: > > > > > > > Confirmed as gcc bug, filed http://gcc.gnu.org/

Re: [x86] BUG: unable to handle kernel paging request at 00740060

2013-10-09 Thread Jakub Jelinek
On Wed, Oct 09, 2013 at 09:02:31PM +0200, Peter Zijlstra wrote: > On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote: > > Confirmed as gcc bug, filed http://gcc.gnu.org/PR58670 > > Seems all of 4.[6-9] miscompile it. Will have a look tomorrow > > unless somebody

Re: [x86] BUG: unable to handle kernel paging request at 00740060

2013-10-09 Thread Jakub Jelinek
On Wed, Oct 09, 2013 at 04:46:56PM +0200, Peter Zijlstra wrote: > On Wed, Oct 09, 2013 at 04:33:59PM +0200, Peter Zijlstra wrote: > > On Wed, Oct 09, 2013 at 04:07:34PM +0200, Peter Zijlstra wrote: > > > Once I force a x86_64 build using the 'same' config it goes away and > > > generates 'sensible'

Re: [x86] BUG: unable to handle kernel paging request at 00740060

2013-10-08 Thread Jakub Jelinek
On Tue, Oct 08, 2013 at 08:51:54PM +0200, Oleg Nesterov wrote: > On 10/08, Linus Torvalds wrote: > > > > (not yet merged), see: > > > > > > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=0c44c2d0f459cd7e275242b72f500137c4fa834d > > I do not really understand inline assembl

Re: Friendlier EPERM - Request for input

2013-01-09 Thread Jakub Jelinek
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote: > I'm suggesting that the string returned by get_extended_error_info() > ought to be the audit record the system call would generate, regardless > of whether the audit system would emit it or not. What system call would that info be

Re: [x86.git#mm] stack protector fixes, vmsplice exploit

2008-02-14 Thread Jakub Jelinek
On Thu, Feb 14, 2008 at 09:25:35PM +0100, Ingo Molnar wrote: > The per function call overhead from stackprotector is already pretty > serious IMO, but at least that's something that GCC _could_ be doing > (much) smarter (why doesnt it jne forward out to __check_stk_failure, > instead of generati

Re: asm-x86/sigcontext.h changes break userland

2008-02-13 Thread Jakub Jelinek
On Wed, Feb 13, 2008 at 08:26:50AM +0100, Ingo Molnar wrote: > > * Jakub Jelinek <[EMAIL PROTECTED]> wrote: > > > x86: use generic register names in struct sigcontext > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=742fa54a62be6

asm-x86/sigcontext.h changes break userland

2008-02-12 Thread Jakub Jelinek
Hi! The x86: use generic register names in struct sigcontext http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=742fa54a62be6a263df14a553bf832724471dfbe changeset breaks userland, e.g. it is not possible to compile gcc anymore (both 32-bit and 64-bit libgcc), and I e

Re: [regression] Re: brk randomization breaks columns

2008-02-05 Thread Jakub Jelinek
On Tue, Feb 05, 2008 at 01:54:26PM +0100, Ingo Molnar wrote: > * Jiri Kosina <[EMAIL PROTECTED]> wrote: > > > On Tue, 5 Feb 2008, Pavel Machek wrote: > > > > > > Actually, this clearly shows that either prehistoric libc.so.5 or the > > > > program itself are broken. > > > I believe it shows clea

Re: Possible 2.6.24-rc7 issue w/respect to pthreads

2008-01-09 Thread Jakub Jelinek
On Wed, Jan 09, 2008 at 02:35:32AM -0800, [EMAIL PROTECTED] wrote: > After I patched my 2.6.23 kernel to 2.6.24-rc7 this morning, I noticed > some odd behavior with respect to POSIX threads in a test program I had > written (originally to test epoll.) > > The behavior is as follows: > > 1. main(

Re: Fedora's latest gcc produces unbootable kernels

2007-12-03 Thread Jakub Jelinek
On Mon, Dec 03, 2007 at 12:34:17PM +0100, Thomas Gleixner wrote: > Of course just to annoy you :) It doesn't matter whether I'm annoyed about this or not, but whether gcc is able to generate decent code with it or not. And especially with union it is not, at least through all the tree ssa passes.

Re: Fedora's latest gcc produces unbootable kernels

2007-12-03 Thread Jakub Jelinek
On Mon, Dec 03, 2007 at 09:17:22AM +0100, Thomas Gleixner wrote: > I looked at the disassembly but I can not spot the problem. > > I think the real problem is somewhere else. Likely candidates are > hrtimer_forward() or hrtimer_start() - in that order. Should be hopefully fixed in latest Fedora g

Re: [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS

2007-11-12 Thread Jakub Jelinek
On Sun, Nov 11, 2007 at 07:48:29AM +0100, Adrian Bunk wrote: > The gcc from svn that will become gcc 4.3 generates libgcc calls in > cases like the following (on 32bit architectures): > > <-- snip --> > > static inline void timespec_add_ns(struct timespec *a, u64 ns) > { > ... > while(

Re: [PATCH] [20/45] x86_64: Use 8 byte stack alignment when possible

2007-09-21 Thread Jakub Jelinek
On Fri, Sep 21, 2007 at 10:45:02PM +0200, Andi Kleen wrote: > > Kernel doesn't use SSE2, so it doesn't need 16 byte alignment. Also > the stack can be already unaligned so letting the compiler align > is useless. This may make some stack frames smaller. Shouldn't sources that are compiled into th

Re: increase AT_VECTOR_SIZE to terminate saved_auxv properly

2007-09-15 Thread Jakub Jelinek
On Fri, Sep 14, 2007 at 01:00:57PM +0200, Olaf Hering wrote: > include/asm-powerpc/elf.h has 6 entries in ARCH_DLINFO. > fs/binfmt_elf.c has 14 unconditional NEW_AUX_ENT entries and 2 > conditional NEW_AUX_ENT entries. > So in the worst case, saved_auxv does not get an AT_NULL entry at the > end. >

Re: [PATCH] [RESEND] PIE executable randomization

2007-08-14 Thread Jakub Jelinek
On Wed, Aug 08, 2007 at 04:03:07PM +0200, Jiri Kosina wrote: > @@ -870,11 +917,15 @@ static int load_elf_binary(struct linux_binprm *bprm, > struct pt_regs *regs) >* default mmap base, as well as whatever program they >* might try to exec. This is b

Re: Implementation of POSIX mqueues in Linux 2.6

2007-08-03 Thread Jakub Jelinek
On Fri, Aug 03, 2007 at 09:59:32AM +, gregfe wrote: > I find little documentation on the actual implementation of POSIX message > queues in Linux, and need some advise. In particular, I am wondering > whether it supports inter-process *and* inter-thread communication, and if Not sure what exac

Re: gcc fixed size char array initialization bug - known?

2007-08-02 Thread Jakub Jelinek
On Thu, Aug 02, 2007 at 09:55:51PM +0200, Guennadi Liakhovetski wrote: > I've run across the following gcc "feature": > > char c[4] = "01234"; > > gcc emits a nice warning > > warning: initializer-string for array of chars is too long > > But do a > > char c[4] = "0123"; > > and -

Re: smaller kernel with no real time futexes

2007-08-01 Thread Jakub Jelinek
On Wed, Aug 01, 2007 at 09:24:34PM +0200, Andi Kleen wrote: > Adrian, > > You said earlier you're looking at smaller allnoconfig kernels. > One thing I noticed recently that realtime pi futexes are always > enabled and that pulls in a lot of other code (like the plists) > > Userland needs to han

Re: vdso.so mislinked by buggy linker was Re: Linus 2.6.23-rc1

2007-07-23 Thread Jakub Jelinek
On Mon, Jul 23, 2007 at 01:56:20AM +0200, Andi Kleen wrote: > On Monday 23 July 2007 01:38:40 Andre Noll wrote: > [readded linux-kernel, Linus] > > > [Nr] Name Type Address Offset > >Size EntSize Flags Link Info Align > > [ 0]

Re: Linus 2.6.23-rc1

2007-07-22 Thread Jakub Jelinek
On Mon, Jul 23, 2007 at 01:31:00AM +0200, Andi Kleen wrote: > On Monday 23 July 2007 01:23:38 Andre Noll wrote: > > On 00:22, Andi Kleen wrote: > > > > /usr/bin/ld: section .text [ff700500 -> ff7007e3] > > > > overlaps section .gnu.version_d [ff7004d8 -> ff70050f] >

Re: vdso.so mislinked by buggy linker was Re: Linus 2.6.23-rc1

2007-07-22 Thread Jakub Jelinek
On Mon, Jul 23, 2007 at 01:56:20AM +0200, Andi Kleen wrote: > On Monday 23 July 2007 01:38:40 Andre Noll wrote: > [readded linux-kernel, Linus] > > > [Nr] Name Type Address Offset > >Size EntSize Flags Link Info Align > > [ 0]

Re: [PATCH][RESEND] PIE randomization

2007-07-10 Thread Jakub Jelinek
hink you could rebase this change against the current state of -mm > and resend it? Thanks, Here it is: Restore BAD_ADDR check strictness, use IS_ERR in the only place where the stricter BAD_ADDR can't work, as the value is a load bias rather than userland address. Signed-off-by: Jakub J

Re: [PATCH][RESEND] PIE randomization

2007-07-07 Thread Jakub Jelinek
p, do_brk etc. return; where TASK_SIZE or more is certainly wrong) or in one case still on unbiased ELF p_vaddr: if (BAD_ADDR(k) || elf_ppnt->p_filesz > elf_ppnt->p_memsz || in load_elf_binary (where >= TASK_SIZE check is ok too). So perhaps doing this instead of changing BAD_ADDR to IS_ERR

Re: [PATCH][RESEND] PIE randomization

2007-07-04 Thread Jakub Jelinek
Kosina <[EMAIL PROTECTED]> > Cc: Ingo Molnar <[EMAIL PROTECTED]> > Cc: Roland McGrath <[EMAIL PROTECTED]> > Cc: Jakub Jelinek <[EMAIL PROTECTED]> > -#define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE) > +#define BAD_ADDR(x) ((unsigned long)(x) >= PAGE_MAS

Re: Userspace compiler support of "long long"

2007-06-28 Thread Jakub Jelinek
On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote: > On Jun 27, 2007, at 23:57:54, Matthew Wilcox wrote: > >On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote: > >>Then all 64-bit archs have: > >>typedef signed long __s64; > >>typedef unsigned long __u64; > >> > >>W

Re: [PATCH] get_random_long() and AT_ENTROPY for auxv, kernel 2.6.21.5

2007-06-25 Thread Jakub Jelinek
On Sun, Jun 24, 2007 at 09:43:03PM -0700, Arjan van de Ven wrote: > > - something to do with aux vector headers > > the primary goal is to pass a random value to userspace at process > start; this to save glibc from having to open /dev/urandom on ever > program start (which it does now for all app

Re: O_CLOEXEC: An alternate proposal

2007-06-08 Thread Jakub Jelinek
On Fri, Jun 08, 2007 at 03:47:12AM -0400, Daniel Colascione wrote: > Hey, this is my first post to linux-kernel, so please be kind. :-) > > Linus Torvalds wrote on May 31: > > I'm with Uli on this one. "Stateful" stuff is bad. It's essentially > > impossible to handle with libraries - either the l

Re: [PATCH] Introduce O_CLOEXEC (take >2)

2007-05-31 Thread Jakub Jelinek
On Thu, May 31, 2007 at 11:46:31AM -0700, Davide Libenzi wrote: > On Thu, 31 May 2007, Ulrich Drepper wrote: > > Davide Libenzi wrote: > > > Isn't this better be a global process flag? Default should be, for legacy > > > reasons, > > > > No. Policies are always wrong since it means code that cann

Re: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory

2007-05-08 Thread Jakub Jelinek
On Tue, May 08, 2007 at 04:12:00PM +1000, Nick Piggin wrote: > I didn't actually check system and user times for the mysql > benchmark, but that's exactly what I had in mind when I > mentioned the poor cache behaviour this patch could cause. I > definitely did see user times go up in benchmarks whe

Re: [PATCH 1/5] fallocate() implementation in i86, x86_64 and powerpc

2007-05-03 Thread Jakub Jelinek
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote: > > > The posix spec implies that negative `len' is permitted - presumably > > > "allocate > > > ahead of `offset'". How peculiar. > > > > I just checked the man page for posix_fallocate() and it says: > > > > EINVAL offset o

Re: MADV_FREE functionality

2007-05-01 Thread Jakub Jelinek
On Mon, Apr 30, 2007 at 06:18:39PM -0700, Andrew Morton wrote: > > In short: > > - both MADV_FREE and MADV_DONTNEED only unmap file pages > > - after MADV_DONTNEED the application will always get back > >fresh zero filled anonymous pages when accessing the > >memory > > - after MADV_FREE th

Re: Big reserved mappings on x86_64

2007-04-25 Thread Jakub Jelinek
On Wed, Apr 25, 2007 at 10:42:20AM +0200, Jan Engelhardt wrote: > I actually took a look at `pmap $$`, which reveals that a lot of shared > libraries map 2044K or 2048K unreadable-unwritable-private > mappings...for _what_ purpose? > > 10:37 opteron:~ > pmap $$ > 4403: bash > START SIZE

Re: [PATCH] lazy freeing of memory through MADV_FREE

2007-04-23 Thread Jakub Jelinek
On Mon, Apr 23, 2007 at 08:21:37PM +1000, Nick Piggin wrote: > I guess it is a good idea to batch these things. But can you > do that on all architectures? What happens if your tlb flush > happens after another thread already accesses it again, or > after it subsequently gets removed from the addre

Re: [PATCH] lazy freeing of memory through MADV_FREE

2007-04-21 Thread Jakub Jelinek
MADV_FREE is not available, to http://people.redhat.com/jakub/glibc/2.5.90-21.1/ and I'm also attaching the glibc patch for those who want to build it themselves: 2007-04-19 Ulrich Drepper <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> * mall

Re: Interface for the new fallocate() system call

2007-04-20 Thread Jakub Jelinek
On Fri, Apr 20, 2007 at 07:21:46PM +0530, Amit K. Arora wrote: > Ok. > In this case we may have to consider following things: > > 1) Obviously, for this glibc will have to call fallocate() syscall with > different arguments on s390, than other archs. I think this should be > doable and should not

Re: [PATCH] make MADV_FREE lazily free memory

2007-04-16 Thread Jakub Jelinek
On Mon, Apr 16, 2007 at 11:10:39AM -0500, Anton Blanchard wrote: > > Making the pte clean also needs to clear the hardware writable > > bit on architectures where we do pte dirtying in software. > > > > If we don't, we would have corruption problems all over the VM, > > for example in the code aro

Re: [PATCH, take4] FUTEX : new PRIVATE futexes

2007-04-07 Thread Jakub Jelinek
On Sat, Apr 07, 2007 at 10:43:39AM +0200, Eric Dumazet wrote: > get_futex_key() does a check against sizeof(u32) regardless of futex being > 64bits or not. > So it is possible a 64bit futex spans two pages of memory... That would be a user bug. 32-bit futexes have to be 32-bit aligned, 64-bit fu

Re: missing madvise functionality

2007-04-05 Thread Jakub Jelinek
On Thu, Apr 05, 2007 at 03:31:24AM -0400, Rik van Riel wrote: > >My guess is that all the page zeroing is pretty expensive as well and > >takes significant time, but I haven't profiled it. > > With the attached patch (Andrew, I'll change the details around > if you want - I just wanted something t

Re: missing madvise functionality

2007-04-04 Thread Jakub Jelinek
On Wed, Apr 04, 2007 at 05:46:12PM +1000, Nick Piggin wrote: > Does mmap(PROT_NONE) actually free the memory? Yes. /* Clear old maps */ error = -ENOMEM; munmap_back: vma = find_vma_prepare(mm, addr, &prev, &rb_link, &rb_parent); if (vma && vma->vm_start < addr + len

Re: getting processor numbers

2007-04-03 Thread Jakub Jelinek
On Tue, Apr 03, 2007 at 07:04:58PM -0700, Paul Jackson wrote: > Andrew wrote: > > I'd have thought that in general an application should be querying its > > present affinity mask - something like sched_getaffinity()? That fixes the > > CPU hotplug issues too, of course. > > The sched_getaffinity

Re: missing madvise functionality

2007-04-03 Thread Jakub Jelinek
On Tue, Apr 03, 2007 at 01:17:09PM -0700, Ulrich Drepper wrote: > Andrew Morton wrote: > > Ulrich, could you suggest a little test app which would demonstrate this > > behaviour? > > It's not really reliably possible to demonstrate this with a small > program using malloc. You'd need something li

Re: getting processor numbers

2007-04-03 Thread Jakub Jelinek
On Tue, Apr 03, 2007 at 10:59:53AM -0700, Ulrich Drepper wrote: > Siddha, Suresh B wrote: > > Not all of the cpu* directories in /sys/devices/system/cpu may be > > online. > > Brilliant. You people really know how to create user interfaces. So > now in any case per CPU another stat/access syscal

Re: Interface for the new fallocate() system call

2007-03-29 Thread Jakub Jelinek
On Thu, Mar 29, 2007 at 10:10:10AM -0700, Andrew Morton wrote: > > Platform: s390 > > -- > > s390 prefers following layout: > > > >int fallocate(int fd, loff_t offset, loff_t len, int mode) > > > > For details on why and how "int, int, loff_t, loff_t" is a problem on > > s390, ple

Re: [PATCH 2.6.21-rc4-mm1 4/4] sys_futex64 : allows 64bit futexes

2007-03-27 Thread Jakub Jelinek
On Wed, Mar 21, 2007 at 10:54:36AM +0100, [EMAIL PROTECTED] wrote: > This last patch is an adaptation of the sys_futex64 syscall provided in -rt > patch (originally written by Ingo Molnar). It allows the use of 64-bit futex. > > I have re-worked most of the code to avoid the duplication of the cod

Re: thread stacks and strict vm overcommit accounting

2007-03-16 Thread Jakub Jelinek
On Thu, Mar 15, 2007 at 11:08:40PM +, Hugh Dickins wrote: > > appears to increase Committed_AS by around 200kb. But we've committed to > > providing it with 8MB for stack. > > > > How come this is correct? > > We've no more committed to providing each instance with 8MB of stack, > than we've

Re: SMP performance degradation with sysbench

2007-03-13 Thread Jakub Jelinek
On Tue, Mar 13, 2007 at 01:02:44PM +0100, Eric Dumazet wrote: > On Tuesday 13 March 2007 12:42, Andrea Arcangeli wrote: > > > My wild guess is that they're allocating memory after taking > > futexes. If they do, something like this will happen: > > > > taskA taskB taskC > >

Re: -freg-struct-return?

2007-02-22 Thread Jakub Jelinek
On Thu, Feb 22, 2007 at 12:09:04AM -0800, Jeremy Fitzhardinge wrote: > Arjan van de Ven wrote: > > Do we know how many gcc bugs this has? (regparm used to have many) > > other than that.. sounds like a win... > > > > The documentation suggests that its the preferred mode of operation, and > tha

Re: dvb shared datastructure bug?

2007-02-13 Thread Jakub Jelinek
On Tue, Feb 13, 2007 at 03:14:23PM +0400, Manu Abraham wrote: > >thanks for pointing out this issue. > > > >attached find a patch that fixes the problem. > > > >@mauro - please pull changeset a7ac92d208fe > > dvbdev: fix illegal re-usage of fileoperations struct > > > >from http://www.linuxtv.or

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

2007-02-04 Thread Jakub Jelinek
On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote: > Arjan van de Ven wrote: > >>Because user threading can avoid context switches, there will always be > >>cases where it will outperform o/s threads for hardware reasons. > > > >actually.. switching from one "real" thread to another in

Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit

2007-01-23 Thread Jakub Jelinek
On Wed, Jan 24, 2007 at 12:06:45AM +0300, Samium Gromoff wrote: > Should we introduce per-arch asm/elf.h files to hold the relevant flag > definitions then? On some architectures there are no bits left. On others you'd need to go through whomever maintains the relevant psABI to get a bit officia

Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit

2007-01-23 Thread Jakub Jelinek
On Tue, Jan 23, 2007 at 11:28:13PM +0300, Samium Gromoff wrote: > Author: Samium Gromoff <[EMAIL PROTECTED]> > Date: Tue Jan 23 22:31:13 2007 +0300 > > Define the ELF binary header flag EF_AS_NO_RANDOM > > EF_AS_NO_RANDOM should mean that the binary requests to not apply > rando

Re: [PATCH 2.6.20-rc4 4/4][RFC] sys_futex64 : allows 64bit futexes

2007-01-11 Thread Jakub Jelinek
On Tue, Jan 09, 2007 at 05:25:26PM +0100, Pierre Peiffer wrote: > This latest patch is an adaptation of the sys_futex64 syscall provided in > -rt > patch (originally written by Ingo). It allows the use of 64bit futex. > > I have re-worked most of the code to avoid the duplication of the code. >

Re: [PATCH 2.6.20-rc4 1/4] futex priority based wakeup

2007-01-10 Thread Jakub Jelinek
On Wed, Jan 10, 2007 at 12:47:21PM +0100, Pierre Peiffer wrote: > So, yes it (logically) has a cost, depending of the number of different > priorities used, so it's specially measurable with real-time threads. > With SCHED_OTHER, I suppose that the priorities are not be very distributed. > > May

Re: Intel Core Duo/Duo2 T2300/E6400 - Hyper-Threading (the absence of)

2007-01-08 Thread Jakub Jelinek
On Mon, Jan 08, 2007 at 01:44:32AM -0800, Robin H. Johnson wrote: > (Please CC me, I am not subscribed to LKML [I have set the > Mail-Followup-To header accordingly]). > > On two of my new machines, with Intel Core Duo T2300 and Core2 Duo E6400 > chips respectively, I noticed some weirdness in how

Re: kernel + gcc 4.1 = several problems

2007-01-03 Thread Jakub Jelinek
On Wed, Jan 03, 2007 at 05:32:16AM -0800, Arjan van de Ven wrote: > On Wed, 2007-01-03 at 12:44 +, Alan wrote: > > > > fixed. At that point an i686 kernel would contain i686 instructions and > > > > actually run on all i686 processors ending all the i586 pain for most > > > > users and distribu

Re: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away

2006-11-30 Thread Jakub Jelinek
On Fri, Dec 01, 2006 at 08:28:16AM +0100, Willy Tarreau wrote: > Oh, I'm perfectly aware of this. That's in part why I started the hotfix > branch in the past :-) But sometimes, fixes consist in merging all the > patches from the maintenance branch (eg: from 4.1.0 to 4.1.1), and if > this is the ca

Re: [PATCH -mm 4/5][AIO] - AIO completion signal notification

2006-11-29 Thread Jakub Jelinek
On Wed, Nov 29, 2006 at 11:33:01AM +0100, S?bastien Dugu? wrote: > AIO completion signal notification > > The current 2.6 kernel does not support notification of user space via > an RT signal upon an asynchronous IO completion. The POSIX specification > states that when an

Re: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away

2006-11-29 Thread Jakub Jelinek
On Wed, Nov 29, 2006 at 02:56:20PM +1100, Keith Owens wrote: > Nicholas Miell (on Tue, 28 Nov 2006 19:08:25 -0800) wrote: > >On Wed, 2006-11-29 at 13:22 +1100, Keith Owens wrote: > >> Compiling 2.6.19-rc6 with gcc version 4.1.0 (SUSE Linux), > >> wait_hpet_tick is optimized away to a never ending l

Re: [PATCH] work around gcc4 issue with -Os in Dwarf2 stack unwind code

2006-11-28 Thread Jakub Jelinek
On Tue, Nov 28, 2006 at 02:48:15PM +, Jan Beulich wrote: > I disagree - the standard says there's a sequence point at a function > call after evaluating all function arguments. To me this means that any That's true, that sequence point makes sure e.g. all side effects such as pre-{dec,inc}reme

Re: [PATCH] work around gcc4 issue with -Os in Dwarf2 stack unwind code

2006-11-28 Thread Jakub Jelinek
On Tue, Nov 28, 2006 at 02:12:24PM +, Jan Beulich wrote: > This fixes a problem with gcc4 mis-compiling the stack unwind code under > -Os, which resulted in 'stuck' messages whenever an assembly routine was > encountered. "mis-compiling" and "work around" are wrong words, the code had undefine

  1   2   >