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
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
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
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
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
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'
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
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/
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;
>
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(
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
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
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
On Tue, Apr 10, 2001 at 03:11:05AM -0700, Dawson Engler wrote:
> As a side question: is it still true that verify_area's must be done before
> any use of __put_user/__get_user/__copy_from_user/etc?
I believe so, at least in generic code.
In architecture specific code (non-i386) it is usually suff
On Tue, Apr 24, 2001 at 11:46:20AM -0500, Tom Brusehaver (N-Sysdyne Corporation) wrote:
>
> I have been chasing all around trying to find out why
> shm_open always returns ENOSYS. It is implemented
> in glibc-2.2.2, and seems the 2.4.3 kernel knows about
> shmfs.
>
> It seems the file linux/mm/s
On Tue, Feb 20, 2001 at 02:51:24PM +1300, Chris Wedgwood wrote:
> Why isn't there a sendfile64?
>
> because nobody has implemented on -- arguably it's not needed; the
> different between:
>
> sendfile64(...)
>
> and
>
> while(blah){
> sendfile( ... 1G or so ...)
>
On Mon, Feb 26, 2001 at 05:15:28PM +, Alan Cox wrote:
> > I think I heve found a bug in gcc. I have tried both egcs 1.1.2 (gcc
> > 2.91.66) and gcc 2.95.2 versions.
> >
> > I am attaching you a simplified test program ('bug.c', a really simple
> > program).
>
> Well gcc-bugs would be the bet
On Tue, Jan 16, 2001 at 10:05:06AM -0500, David L. Parsley wrote:
> Felix von Leitner wrote:
> > > close (0);
> > > close (1);
> > > close (2);
> > > open ("/dev/console", O_RDWR);
> > > dup ();
> > > dup ();
> >
> > So it's not actually part of POSIX, it's just to get around fixing
>
On Tue, Nov 14, 2000 at 10:42:41AM +, Malcolm Beattie wrote:
> Keith Owens writes:
> > All these patches against request_module are attacking the problem at
> > the wrong point. The kernel can request any module name it likes,
> > using any string it likes, as long as the kernel generates the
On Sun, Nov 19, 2000 at 07:24:16PM +0900, GOTO Masanori wrote:
> At Mon, 13 Nov 2000 11:13:19 -0500,
> Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > ago were done in the kernel, POSIX message queue passing is not doable in
> > userland without kernel help either (I have a
On Wed, Nov 01, 2000 at 04:54:18PM -0700, Cort Dougan wrote:
> Since you're setting yourself up as a proponent of this can you explain why
> RedHat includes a compiler that doesn't work with the kernel? Don't get
It actually does not compile only 2.2 kernels unless they are patched (the
patches
On Tue, Nov 21, 2000 at 06:02:35AM -0600, Peter Samuelson wrote:
>
> While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
> discovered that gcc 2.95.2 (i386) does not remove dead string
> constants:
>
> void foo (void)
> {
> if (0)
> printk(KERN_INFO "bar");
> }
>
On Fri, Nov 24, 2000 at 06:20:33AM +0100, [EMAIL PROTECTED] wrote:
> >> ... RedHat's GCC snapshot "2.96" handles this case just fine.
>
> > Now, if you can isolate the relevant part of the diff between
> > 2.95.2 and RH 2.96...
>
> Maybe I have to be more precise in the statement "gcc 2.95.2 is
On Mon, Nov 27, 2000 at 09:54:57AM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 07:30:44 -0800,
> "Adam J. Richter" <[EMAIL PROTECTED]> wrote:
> > In reading include/linux/init.h, I was surprised to discover
> >that __init{,data} expands to nothing when compiling a module.
> >I was wonderi
On Mon, Nov 27, 2000 at 05:48:28PM +0100, Jes Sorensen wrote:
> > "Keith" == Keith Owens <[EMAIL PROTECTED]> writes:
>
> Keith> On Sun, 26 Nov 2000 16:36:55 -0700, "Jeff V. Merkey"
> Keith> <[EMAIL PROTECTED]> wrote:
> >> Keith,
> >>
> >> Please consider the attached patch for inclusion in a
On Wed, Sep 06, 2000 at 10:05:46PM +0200, [EMAIL PROTECTED] wrote:
>
> I'm trying to compile 2.2.17 with gcc 2.96, and it shows a lot of
> warnings like this in several files.
First of all, you should not use gcc 2.96 for 2.2.x kernel compiles, only
2.4 should work.
> warning: pasting would not
On Thu, Sep 07, 2000 at 08:53:29AM +1100, Keith Owens wrote:
> On Wed, 6 Sep 2000 21:49:44 +0100 (BST),
> Alan Cox <[EMAIL PROTECTED]> wrote:
> >Use a different gcc. There are reasons people shipping 2.96 for intel x86 also
> >include egcs. The kernel isnt ready for 2.96
>
> Out of curiousity, w
On Tue, Sep 12, 2000 at 03:12:34PM +0100, Alan Cox wrote:
> > I need support for files larger than 2GB. What's the status for that ?
>
> 2.2 + patches or 2.4 test and glibc 2.1.9x
And make sure the utilities you want to work with those 2GB+ files were
compiled with -D_FILE_OFFSET_BITS=64 (che
On Mon, Oct 23, 2000 at 12:06:31PM +, David Wragg wrote:
> Gregory Maxwell <[EMAIL PROTECTED]> writes:
> > If 2.96 is broken, I'd appreciate it if you would describe the breakage.
>
> As in the RedHat 2.96? Try compiling the following on RedHat 7.0 x86
> with "gcc -O2" and take a look at th
On Mon, Oct 30, 2000 at 03:01:16PM +0100, Martin Dalecki wrote:
> Horst von Brand wrote:
> >
> > Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> > both sides).
> >
> > abs() is used at least in:
> >
> > arch/i386/kernel/time.c
> > drivers/md/raid1.c
> > drivers/sound/s
On Mon, Oct 30, 2000 at 05:50:07PM -0300, Horst von Brand wrote:
> Martin Dalecki <[EMAIL PROTECTED]> said:
> > Peter Samuelson wrote:
>
> [...]
>
> > > * Red Hat "2.96" or CVS 2.97 will probably break any known kernel.
>
> > Works fine for me and 2.4.0-test10-pre5... however there are tons of
On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
> Alan,
>
> Perhaps I did not explain myself, or perhaps I misunderstand your
> comments. I was responding to a comment that we could just copy some of
> the optimizations from Pro64 over into gcc.
That's hard to do, because the whole gc
On Mon, Nov 13, 2000 at 11:00:09AM -0500, Jeff Garzik wrote:
> [EMAIL PROTECTED] wrote:
> > Sorry if this is a FAQ, but I've searched the archives for this list
> > (http://www.uwsg.iu.edu/hypermail/linux/kernel/) and only come with references
> > from 1996!
> >
> > What is the state of Posix-com
On Thu, Dec 14, 2000 at 04:42:03AM -0800, Clayton Weaver wrote:
> There has a been a thread on the teTeX mailing list the last few days
> about a (RedHat, but probably more general than just their rpms)
> gcc-2.9.6 w/glibc-2.2.x bug. At -O2, it can miscompile
>
> unsigned varname; /* "unsigned i
On Thu, Dec 14, 2000 at 11:11:28AM -0800, Linus Torvalds wrote:
> user applications and (b) gcc-2.96 is so broken that it requires special
> libraries for C++ vtable chunks handling that is different, so the
> _working_ gcc can only be used with programs that do not need such
> library support.
E
On Fri, Dec 29, 2000 at 10:54:38AM +0100, Ulrich Windl wrote:
> Hello,
>
> I noticed (with some inspiration from Andy Kleen) that some asm()
> instructions for the ia32 use the "g" constraint for "mull", where my
> Intel 386 Assembly Language Manual suggests the "MUL" instruction needs
> an r/
On Tue, Sep 26, 2000 at 08:20:49AM +0200, Michael N. Lipp wrote:
> Hi,
>
> I can't compile the latest linux kernel with the latest gcc due to a
> strange define in checksum.S. The gcc preprocessor complains about
> the usage of elipses in the macros
>
> #define SRC(y...) \
>
On Tue, Sep 26, 2000 at 05:42:59PM +0200, Mads Martin Joergensen wrote:
> * Timur Tabi <[EMAIL PROTECTED]> [Sep 26. 2000 17:36]:
> > > Maybe this can be fixed for 2.96, but it breaks badly elsewhere (doesn't
> > > compile; kernel builds but hangs/crashes at boot; kernel appears to work
> > > fine
On Fri, Sep 29, 2000 at 11:09:33AM +, Stephen Torri wrote:
> I get the following message compiling 2.4.0-test6 or test8 on a RedHat 7
> system. "/usr/src/linux/include/asm/apic.h:13:29: warning: nothing can be
> posted after this token". Is this an issue with apic?
Yes, this one is apic.h bug
On Tue, Oct 03, 2000 at 10:41:57PM -0700, Dr. Kelsey Hudson wrote:
> > Question is, is this still broken on -test9-final or did
> > the fix Linus merged earlier today get rid of your problems?
>
> Let me try this and find out...
...
> making dep...
>
> ::curses his SS20 for being so SLOW!::
> I
On Tue, Oct 03, 2000 at 11:12:24PM -0700, [EMAIL PROTECTED] wrote:
> No, better yet,
> what is a good version to use when porting to a new processor (actually
> an old processor)? I've pulled the source to gcc (2.95.2) and binutils
> (2.10) in prep for a port to a new/old machine. If these versi
On Tue, Oct 10, 2000 at 11:32:43PM -0500, Gnea wrote:
>
> On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth:
>
> >
> > Ted,
> >
> > Please add this to your list. Linux is unusable in these machines.
> > I have cc'ed Martin and Linus because they play in that PCI area.
>
> erm,
On Thu, Oct 12, 2000 at 11:38:11AM -0400, Yong Chi wrote:
> Hopefully this will do for SMP locks. =)
Holding a spinlock for this long (especially when you might sleep there in two
places (interruptible_sleep_on, put_user)) is basically a bad idea.
spinlocks are designed to be holded only for sho
On Fri, Oct 13, 2000 at 02:17:23PM -0700, Richard Henderson wrote:
> On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote:
> > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the
> > ultrsparc/alpha ?
>
> It is not.
It is not even 32bit on sparc32 (24bit only).
On Mon, Apr 02, 2001 at 09:54:25AM -0300, Gustavo Niemeyer wrote:
> Hi Richard! Hi Dennis!
>
> > I tracked this down to a corrupt jumptable somewhere in the pthreads
> > part of the libc (didnt have the source handy at that time, though). So
> > I think this is a libc bug (version does not matter
On Sat, Feb 03, 2001 at 12:40:03AM +0100, J . A . Magallon wrote:
> Please, do not do so. That depends on the PACKAGE name and version, and there
> is no standard way of versioning a patched gcc.
> The -54 is a RH'ism, for example Mandrake Cooker includes patches from
> different sources, and gcc
On Sat, Feb 03, 2001 at 04:25:20AM +, Paul Jakma wrote:
> On Fri, 2 Feb 2001, Jakub Jelinek wrote:
>
> > You can do:
> > if [ "$CC" = gcc ]; then
> > echo 'inline void f(unsigned int n){int
>i,j=-1;for(i=0;i<10&&j<0;i++)if((1UL<
On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote:
> Not supporting #ident for CVS managed code bases would see to
> me, at first glance, to be a show stopper to shipping a release
> of anything, since many folks need CVS support.
Could you please explain what you mean by not suppo
On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
> pure luck. NPTL threading uses it to store a pointer to per thread info
> structure; other threading (linuxthreads) may have stored a pid there to
> identify the internal thread. nptl is 2.6 only so you might have
> switched implem
On Thu, Jul 07, 2005 at 02:13:02PM +0200, Paolo Ornati wrote:
> You need to tell GCC to use "libmqueue"... something like this:
>
> gcc -Wall -O2 -o prog prog.c -lmqueue
If you have glibc 2.3.4 or later, you should use -lrt instead.
Jakub
-
To unsubscribe from this list: send the l
On Fri, Jul 08, 2005 at 06:42:53PM +0100, Alistair John Strachan wrote:
> > btw., which gcc version are you using?
>
> Not the GCC version known to bloat stacks ;-)
>
> 3.4.4, on both my machines. I'm not touching 4.x until 4.0.1 is released with
> the miscompiled-code fixes.
GCC 4.0.x bloats s
On Tue, Aug 23, 2005 at 01:14:38PM +0530, Suparna Bhattacharya wrote:
> 2. No support for propagating IO completion events to user space
> threads using RT signals. User threads need to poll the completion
> queue using io_getevents. POSIX specifies that when an AIO
>
Hi!
ATM pthread_cond_signal is unnecessarily slow, because it wakes one
waiter (which at least on UP usually means an immediate context switch
to one of the waiter threads). This waiter wakes up and after a few
instructions it attempts to acquire the cv internal lock, but that lock
is still held
On Tue, Aug 23, 2005 at 10:36:08AM -0400, Ingo Molnar wrote:
> a detail: many of the futex_atomic_op_inuser() seem to be duplicated
> across architectures. Might be worth putting into asm-generic, to avoid
> the duplication?
Those are stub files waiting for arch maintainers to actually implement
t
On Wed, Aug 31, 2005 at 02:11:44PM +0200, Ingo Molnar wrote:
> > I recompiled and installed the kernel, but there's no change (getconf
> > ARG_MAX still gives 131072.) What am I missing?
>
> MAX_ARG_PAGES should work just fine. I think the 'getconf ARG_MAX'
> output is hardcoded. (because the k
On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
> It isn't the same, but "static inline" is the correct variant.
>
> "extern inline __attribute__((always_inline))" (which is what
> "extern inline" is expanded to) doesn't make sense.
It does make sense and is different from
static inl
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(
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
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.
On Thu, Nov 18, 2004 at 02:47:26PM -0500, Jakub Jelinek wrote:
> The scenario described in futex_wait-fix.patch IMHO can happen even
> if all calls to pthread_cond_signal are done with mutex held around it, i.e.
> A B X Y
> pthread_mute
On Thu, Mar 17, 2005 at 03:20:31PM +, Jamie Lokier wrote:
> If you change futex_wait to be "atomic", and then have userspace locks
> which _depend_ on that atomicity, it becomes impossible to wait on
> multiple of those locks, or make poll-driven state machines which can
> wait on those locks.
On Thu, Mar 17, 2005 at 03:20:31PM +, Jamie Lokier wrote:
> > [numerous instances of...]
> > + preempt_check_resched();
>
> Not required. The spin unlocks will do this.
Here is updated patch with those removed (all of them are preceeded
by spin_unlock) and out_unqueue label and following u
On Tue, Mar 22, 2005 at 12:30:53AM -0500, Lee Revell wrote:
> On Mon, 2005-03-21 at 21:08 -0800, Andrew Morton wrote:
> > Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > >
> > > The most recent messages under "Futex queue_me/get_user ordering",
> >
On Wed, Mar 23, 2005 at 05:12:59AM -0800, [EMAIL PROTECTED] wrote:
> the hang occurs during an attempted thread cancel+join. we know from
> strace that one thread calls tgkill() on the other. the other thread is
> blocked in a poll call on a FIFO. after tgkill, the first thread enters a
> futex wai
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
> Finally, although an NX stack is nice, you should probably take into
> account IBM's stack smash protector, ProPolice. Any attack that can
> evade SSP reliably can evade an NX stack; but ProPolice protects from
> other overflows
On Thu, Feb 24, 2005 at 04:08:47PM +0100, Mikael Pettersson wrote:
> /* gcc4bug.c
> * Written by Mikael Pettersson <[EMAIL PROTECTED]>, 2005-02-24.
...
Reproduced, thanks for the testcase. Looking into it...
Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, Feb 24, 2005 at 04:08:47PM +0100, Mikael Pettersson wrote:
> _However_, the 0k data message is due to a gcc-4.0 bug, and below
> you'll find a test program which illustrates it.
http://gcc.gnu.org/PR20196
Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
Hi!
There is a bug in binfmt_elf.c if the dynamic linker has non-zero base vaddr
(e.g. if it is prelinked). The issue is that in such case ld-linux.so.2 is
loaded at ELF_ET_DYN_BASE + p_vaddr instead of ELF_ET_DYN_BASE, on some
architectures into non-desirable places in virtual memory.
Best expl
Hi!
Apparently all kernel scripts only have .rodata and not also .rodata.* input
sections in it.
This has been no problem so far, but since binutils and gcc support SHF_MERGE
sections (so that string constant (and other constant too) duplicates can be
removed at link time) the compiler creates se
On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
> typedef unsigned int size_t;
>
> static inline void * __memcpy(void * to, const void * from, size_t n)
> {
> int d0, d1, d2;
> __asm__ __volatile__(
> "rep ; movsl\n\t"
> "testb $2,%b4\n\t"
> "je 1f\n\t"
>
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(
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]
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]
>
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]
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 -
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
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
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
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
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
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
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
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
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
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
> >
1 - 100 of 154 matches
Mail list logo
