Jens Axboe wrote:
Hi,
A few changes:
- Cleanup up the driver additions even more, blk_complete_barrier_rq()
does all the work now.
- Fixed up the exports
- Comment functions
- Fixed a bug with SCSI and write back caching disabled
- Rename blk_queue_flush() to blk_queue_flushing() to indicate
On Thu, Jan 27, 2005 at 02:29:43PM -0800, Andrew Morton wrote:
> I've already queued a patch for this:
>
> --- 25/mm/oom_kill.c~mm-fix-several-oom-killer-bugs-fix Thu Jan 27
> 13:56:58 2005
> +++ 25-akpm/mm/oom_kill.c Thu Jan 27 13:57:19 2005
> @@ -198,12 +198,7 @@ static void
--- Andreas Gruenbacher <[EMAIL PROTECTED]> escribió:
> Hello,
>
> here is a fix for a NULL pointer access problem with
> NFSv2 that isn't in
> 2.6.11-rc2-mm1, but it can't explain this NULL
> inode->i_op.
>
> -- Andreas.
Hi,
Yes, that patch seems unrelated.
Same Oops with or without it.
Hi.
On Fri, 2005-01-28 at 05:43, Pavel Machek wrote:
> Unfortunately I do not know how to reproduce it. I tried
> parallel-building kernels for few hours and that worked okay. Swsusp
> is not involved (but usb, bluetooth, acpi and sound may be).
I take it you're sure suspending is not involved
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> 3) eepro100
>
> Unmaintained; users should use e100.
>
> When I last mentioned eepro100 was going away, I got a few private
> emails saying complaining about issues not yet taken care of in e100.
> eepro100 will not be removed
On Fri, Jan 28, 2005 at 03:09:40PM +, Hugh Dickins wrote:
> On Thu, 27 Jan 2005, Marcelo Tosatti wrote:
> > On Thu, Jan 27, 2005 at 07:38:49AM +0100, Ake wrote:
> > > On Wed, Jan 26, 2005 at 12:49:04PM -0200, Marcelo Tosatti wrote:
> > > >
> > > > --- a/mm/filemap.c.orig 2004-11-17
Hello,
here is a fix for a NULL pointer access problem with NFSv2 that isn't in
2.6.11-rc2-mm1, but it can't explain this NULL inode->i_op.
-- Andreas.
--- Begin Message ---
Hello,
this patch has an NFSv2 problem that I haven't tripped over until today. The
fix is this:
--- 8< ---
Fix
On Sun, 2005-01-23 at 09:51 -0800, Linus Torvalds wrote:
with this patch the oops is gone(also tested with PREEMPT and no oops)
>
>
> --- 1.32/drivers/char/pty.c 2005-01-10 17:29:36 -08:00
> +++ edited/drivers/char/pty.c 2005-01-23 09:49:16 -08:00
> @@ -149,13 +149,15 @@
> static int
On Thursday 27 January 2005 11:18, Zan Lynx wrote:
> On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
>
> >
> > > > Unfortunately, there will ALWAYS be a path, either direct, or
> > > > indirect between the secure net and the internet.
> > >
> > > Other than letting people use secure
--- Andrew Morton <[EMAIL PROTECTED]> escribió:
> Can you tell us which filesystem is being bad? Add
> this:
>
> if (!inode->i_op)
> printk("%s is naughty\n", inode->i_sb->s_id);
>
> It's probably NFS - there has been some work done in
> there in -mm.
0:a is naughty
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
>Hi,
>
>For the longest time, only the old PATA drivers supported barrier writes
>with journalled file systems. This patch adds support for the same type
>of cache flushing barriers that PATA uses for SCSI, to be utilized with
>libata.
What,
On Fri, 28 Jan 2005, Jaco Kroon wrote:
> >>
> >>ok, how would I try this? Where can I find an example to code it from?
> >> Sorry, I should probably be grepping ...
> > If the udelay() didn't work, then this one isn't worth worryign about
> > either. Back to the drawing board.
> Yea. But
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
>>I feel the need to point something out here.
>>
>>[TEXT][BRK][MMAP---][STACK]
>>
>>Here's a normal layout.
>>
>>[TEXT][BRK][MMAP---][STACK][MMAP--]
>>
>>Is this one any worse?
>
>
> yes.
>
> oracle, db2
On Thu, 27 Jan 2005, John Richard Moser wrote:
> Your patch 5/6 for mmap rand is also small. 1M is trivial, though I'd
> imagine mmap() rand would pose a bit more confusion in some cases at
> least, even for small ranges.
> Still, this is a joke, like OpenBSD's stackgap.
Also, besides security
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> > > Can you replace this:
> > >
> > > if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
> > > force_sig(SIGTERM, p);
> > > } else {
> > > force_sig(SIGKILL, p);
> > > }
> > >
> > >
Albert Herranz <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm getting a kernel Oops while booting 2.6.11-rc2-mm1
> on a diskless (nfsroot based) embedded ppc system.
> Vanilla 2.6.11-rc2 works Ok.
>
> [...]
> VFS: Mounted root (nfs filesystem) readonly.
> Freeing unused kernel memory: 112k init
>
On Thu, Jan 27, 2005 at 02:54:13PM -0400, Mauricio Lin wrote:
> Hi Andrea,
>
> On Wed, 26 Jan 2005 01:49:01 +0100, Andrea Arcangeli <[EMAIL PROTECTED]>
> wrote:
> > On Tue, Jan 25, 2005 at 08:11:19PM -0400, Mauricio Lin wrote:
> > > Sometimes the first application to be killed is XFree. AFAIK
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Hmm, just an idea, shouldn't the i8042_write_command be waiting until
the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the
applied
-
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/
applied to netdev
-
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/
On Thu, 27 Jan 2005, Marcelo Tosatti wrote:
> On Thu, Jan 27, 2005 at 07:38:49AM +0100, Ake wrote:
> > On Wed, Jan 26, 2005 at 12:49:04PM -0200, Marcelo Tosatti wrote:
> > >
> > > --- a/mm/filemap.c.orig 2004-11-17 09:54:22.0 -0200
> > > +++ b/mm/filemap.c2005-01-26
On Thu, Jan 27, 2005, DervishD <[EMAIL PROTECTED]> wrote:
> Didn't knew about that... Thanks a lot for the info!. Is there
> any documentation available for the ioctl USB interface to the
> kernel? Any API guide or something like that?
You can use the kernel sources to see how to use it.
JE
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
(b) sys_mremap() isn't covered.
On Thu, Jan 27, 2005 at 03:58:12PM -0500, Rik van Riel wrote:
AFAICS it is covered.
--- mm1-2.6.11-rc2.orig/mm/mremap.c 2005-01-26 00:26:43.0 -0800
+++
Hi,
I'm getting a kernel Oops while booting 2.6.11-rc2-mm1
on a diskless (nfsroot based) embedded ppc system.
Vanilla 2.6.11-rc2 works Ok.
[...]
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 112k init
INIT: version 2.86 booting
Oops: kernel access of bad area, sig:
> I feel the need to point something out here.
>
> [TEXT][BRK][MMAP---][STACK]
>
> Here's a normal layout.
>
> [TEXT][BRK][MMAP---][STACK][MMAP--]
>
> Is this one any worse?
yes.
oracle, db2 and similar like to mmap 2Gb or more *in one chunk*.
moving the stack in the middle
Jason Gaston wrote:
This patch adds the Intel ICH7R DID's to the ahci.c SATA AHCI driver for ICH7R
SATA support.
If acceptable, please apply.
applied
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* Tony Lindgren <[EMAIL PROTECTED]> [050127 13:34]:
> Hi all,
>
> Thanks for all the comments, here's an updated version of the dynamic
> tick patch.
Oops, I guess I should test before posting :)
Looks like CONFIG_X86_LOCAL_APIC=y is currenly needed on uniprocessor
machines to compile. Also
Viktor Horvath wrote:
Hello everybody,
today I patched myself up from 2.6.7 vanilla to 2.6.10 vanilla, but
after all patches succeeded, "make menuconfig" shows "v2.6.8.1
Configuration". Even worse, a compiled kernel calls in his bootlog
himself "2.6.8.1".
I guess you did somthing like this:
2.6.7
* [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > Whenever I "modprobe parport_pc", I get this message:
> >
> > Jan 27 10:55:47 hummus kernel: pnp: Device 00:0b activated.
> > Jan 27 10:55:47 hummus kernel: parport: PnPBIOS parport detected.
> > Jan 27 10:55:47 hummus kernel: pnp: Device 00:0b
Recently I debugged something that was spinning in the for(;;) in
__getblk_slow(). It turned out it was calling __getblk() with a size
argument that didn't match the bdev's inode's i_blkbits.
grow_buffers() would add a page at the index calculated from the 4k size
argument but when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
[...]
>
> Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
> ACCEPTABLE for a lot of uses. People on 32-bit archtiectures have issues
> with usable virtual memory areas etc.
>
I feel the need to
>
> Here's self-exploiting code to discover its own return address offset
> and exploit itself. It'll lend some insight into how this stuff works.
>
> Just a toy.
>
While I understand the point here, doesn't it become a moot point if:
a) the stack is reinitialized randomly on each execution
and
Hi all,
Thanks for all the comments, here's an updated version of the dynamic
tick patch.
I've fixed couple of things:
- Dyn-tick now supports local APIC timer. This allows longer sleep time
inbetween ticks, over 1000 ticks compared to 54 ticks with PIT timer.
It seems to stop timers on SMP
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
The intention was to disallow vmas starting at 0 categorically. i.e. it
is very intentional to deny the MREMAP_FIXED to 0 case of mremap().
It was also the intention to deny the MAP_FIXED to 0 case of mmap(),
though I didn't actually sweep that
Have you checked that the power connector really provides 5V to the
IDE-CF adapter ? I had the exact same behaviour 5 years ago with a power
wire cut. Signal lines were powerful enough to bring power to the cheap
flash (16 MB), I could even read it, most times. The kernel almost always
booted from
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> (b) sys_mremap() isn't covered.
On Thu, Jan 27, 2005 at 03:58:12PM -0500, Rik van Riel wrote:
> AFAICS it is covered.
> >--- mm1-2.6.11-rc2.orig/mm/mremap.c 2005-01-26 00:26:43.0 -0800
> >+++ mm1-2.6.11-rc2/mm/mremap.c 2005-01-27
On Thu, 27 Jan 2005, Jaco Kroon wrote:
>
> Hmm, just an idea, shouldn't the i8042_write_command be waiting until
> the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the hardware was so
On Thu, 27 Jan 2005, Arjan van de Ven wrote:
>
> and then there are architectures with an upward growing stack
> and maybe the alignment will even vary per cpu type (runtime) for some
> architectures? Maybe arch maintainers can jump in quickly to say if a
> scheme with a per arch shift
I recently tried out adding PNP support to my driver to remove the
hassle of finding the correct parameters for it. This, however, causes
it to show up under the pnp bus, where as it previously was located
under the platform bus.
Is the idea that PNP devices should only reside on the PNP bus
On Thu, Jan 27, 2005 at 08:51:45AM -0800, Chris Wedgwood wrote:
> On Thu, Jan 27, 2005 at 06:24:13PM +, Matthias-Christian Ott wrote:
> > I'll submit it to the mailinglist as a seperate patch, so Linus can
> > apply it to the current Kernel.
Chris' fix for this is in Linus' mail, queued to be
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> 1) iphase (iph5526 a.k.a. drivers/net/fc/*)
>
> Been broken since 2.3 or 2.4. Only janitors have kept it compiling.
No, it doesn't even compile, and didn't so for more than two years.
-
To unsubscribe from this list: send the line
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
(b) sys_mremap() isn't covered.
AFAICS it is covered.
--- mm1-2.6.11-rc2.orig/mm/mremap.c 2005-01-26 00:26:43.0 -0800
+++ mm1-2.6.11-rc2/mm/mremap.c 2005-01-27 12:34:34.0 -0800
@@ -297,6 +297,8 @@
if (flags &
On Wed, Jan 26, 2005 at 03:57:45AM +1100, Anton Blanchard wrote:
> I dont particularly like it, but it would be better for that to be a
> separate cleanup patch. I want to maximise my changes of this going in
> soon :)
What about something like (just for the sake of initial feedback):
On Thu, 2005-01-27 at 20:42 +, Christoph Hellwig wrote:
> On Thu, Jan 27, 2005 at 03:40:48PM -0500, Rik van Riel wrote:
> > On Thu, 27 Jan 2005, Christoph Hellwig wrote:
> >
> > >>+unsigned long arch_align_stack(unsigned long sp)
> > >>+{
> > >>+ if (randomize_va_space)
> > >>+ sp -=
Hello,
running stock 2.6.9 with IDE UDMA(33) disk drive, kernel wrote:
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0xd7 { DriveStatusError BadCRC UncorrectableError
SectorIdNotFound TrackZeroNotFound AddrMarkNotFound }, CHS=1157/0/130,
sector=30901687
George Anzinger wrote:
Ingo Molnar wrote:
* George Anzinger wrote:
What I am suggesting is spliting the mark code so that it would only
grap the offset (current TSC in most systems) during interrupt
processing. Applying this would be done later in the thread. Since
it is not applying the
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected
For the guys on ppc, and other architectures that have all of their
cpu memory behind an iommu. I propose we create a /proc/cpumem
which is the subset of /proc/iomem that deals with RAM. In any event
as something like that is straight forward to implement I will
assume the existence of the
(GregKH cc'd for his deprecated list)
Though this has already been mentioned, I thought I would send out a
reminder. The following net drivers are slated for removal "soon", in
the next kernel version or so:
1) iphase (iph5526 a.k.a. drivers/net/fc/*)
Been broken since 2.3 or 2.4. Only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So 0x02020202 is a no-op?
(somebody finally gets why the randomization range must be > the size of
the stack?)
linux-os wrote:
[...]
>> pointing back into that buffer needs the address of that buffer. That
>> buffer is on the stack, which is now
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> The only claim above is the effect of clobbering virtual page 0 and
>> referring to this phenomenon by the macro. I was rather careful not to
>> claim a specific lower boundary to the address space.
On Thu, Jan 27, 2005 at 02:22:50PM -0500, Rik
On Thu, Jan 27, 2005 at 07:25:04PM +, Russell King wrote:
> Can you provide some details, eg kernel configuration, loaded modules
> and a brief overview of any netfilter modules you may be using.
>
> Maybe we can work out what's common between our setups.
Vanilla 2.6.10, though I've been
On Thu, 27 Jan 2005, Christoph Hellwig wrote:
+unsigned long arch_align_stack(unsigned long sp)
+{
+ if (randomize_va_space)
+ sp -= ((get_random_int() % 4096) << 4);
+ return sp & ~0xf;
+}
this looks like it'd work nicely on all architectures.
I guess it should work for
On Thu, 27 Jan 2005 21:29:47 +0100, Andries Brouwer <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote:
>
> > So what _might_ happen is that we write the command, and then
> > i8042_wait_write() thinks that there is space to write the data
> > immediately,
On Thu, Jan 27, 2005 at 03:40:48PM -0500, Rik van Riel wrote:
> On Thu, 27 Jan 2005, Christoph Hellwig wrote:
>
> >>+unsigned long arch_align_stack(unsigned long sp)
> >>+{
> >>+ if (randomize_va_space)
> >>+ sp -= ((get_random_int() % 4096) << 4);
> >>+ return sp & ~0xf;
> >>+}
> >
On Thu, 27 Jan 2005 16:49:18 +
Russell King <[EMAIL PROTECTED]> wrote:
> notice how /proc/net/stat/rt_cache says there's 1336 entries in the
> route cache. _Where_ are they? They're not there according to
> /proc/net/rt_cache.
When the route cache is flushed, that kills a reference to each
On Thu, 27 Jan 2005, Arjan van de Ven wrote:
On Thu, 2005-01-27 at 14:19 -0500, linux-os wrote:
Gentlemen,
Isn't the return address on the stack an offset in the
code (.text) segment?
How would a random stack-pointer value help? I think you would
need to start a program at a random offset, not the
On Thu, Jan 27, 2005 at 09:19:23PM +0100, Kay Sievers wrote:
> Initialize the allocated bin_attribute structure, otherwise unused fields
> are pointing to random places.
Sorry, wrong place for the inititalization.
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
= drivers/pci/pci-sysfs.c 1.16
On Thu, 2005-01-27 at 20:32 +, Christoph Hellwig wrote:
> > The patch below replaces the existing 8Kb randomisation of the userspace
> > stack pointer (which is currently only done for Hyperthreaded P-IVs) with a
> > more general randomisation over a 64Kb range. 64Kb is not a lot, but it's a
>
> The patch below replaces the existing 8Kb randomisation of the userspace
> stack pointer (which is currently only done for Hyperthreaded P-IVs) with a
> more general randomisation over a 64Kb range. 64Kb is not a lot, but it's a
> start and once the dust settles we can increase this value to a
On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote:
> So what _might_ happen is that we write the command, and then
> i8042_wait_write() thinks that there is space to write the data
> immediately, and writes the data, but now the data got lost because the
> buffer was busy.
Hmm -
On Thu, Jan 27, 2005 at 08:23:35PM +, Christoph Hellwig wrote:
> > + p = arch_align_stack((unsigned long)p);
>
> looking at the code p already is unsigned long, so the cast is not needed.
yeah
how about this one instead ?
The patch below replaces the existing 8Kb randomisation
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
> i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
> i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
The code is
param = 0x5a;
if (i8042_command(, I8042_CMD_AUX_LOOP) || param !=
> + p = arch_align_stack((unsigned long)p);
looking at the code p already is unsigned long, so the cast is not needed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Initialize the allocated bin_attribute structure, otherwise unused fields
are pointing to random places.
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
= drivers/pci/pci-sysfs.c 1.16 vs edited =
--- 1.16/drivers/pci/pci-sysfs.c2005-01-06 21:30:29 +01:00
+++
On Thu, 2005-01-27 at 20:34 +0100, Julien TINNES wrote:
> >
> > Yeah, if it came from PaX the randomization would actually be useful.
> > Sorry, I've just woken up and already explained in another post.
> >
>
> Please, no hard feelings.
>
> Speaking about implementation of the non executable
In other words, no :)
Here's self-exploiting code to discover its own return address offset
and exploit itself. It'll lend some insight into how this stuff works.
Just a toy.
Arjan van de Ven wrote:
> On Thu, 2005-01-27 at 14:19 -0500, linux-os wrote:
>
>>Gentlemen,
>>
>>Isn't the return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
> On Thu, 27 Jan 2005, John Richard Moser wrote:
>
>>>Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
>>>ACCEPTABLE for a lot of uses. People on 32-bit archtiectures have issues
>>>with usable
On Thu, 2005-01-27 at 11:59 -0800, Linus Torvalds wrote:
>
> Btw, since you're clearly at the keyboard now: I do agree with Christoph
> that it would be a lot cleaner to just say that all architectures have to
> have a arch_align_stack() define, instead of having a
> __HAVE_ARCH_ALIGN_STACK
On Thu, 2005-01-27 at 14:19 -0500, linux-os wrote:
> Gentlemen,
>
> Isn't the return address on the stack an offset in the
> code (.text) segment?
>
> How would a random stack-pointer value help? I think you would
> need to start a program at a random offset, not the stack!
> No stack-smasher
On Wed, 2005-01-26 at 23:15 -0600, Jack O'Quin wrote:
> >> > And finally, with rlimit support, is there any reason why lockup
> >> > detection and correction can't go into userspace? Even RT
> >> > throttling could probably be done in a userspace daemon.
> >>
> >> It can. But, doing it in the
On 2005-01-27 at 11:28:48, David Brownell wrote:
> > Indeed, I had to shuffle my machines around a bit to get a proof that
> > something is broken, but now I can confirm the above with a connection
> > to cvs.sourceforge.net:
>
> Thanks for confirming it wasn't just me ... I confess I'm a bit
>
Btw, since you're clearly at the keyboard now: I do agree with Christoph
that it would be a lot cleaner to just say that all architectures have to
have a arch_align_stack() define, instead of having a
__HAVE_ARCH_ALIGN_STACK define.
After all, a trivial implementation would apparently just be
Dave Hansen wrote:
On Thu, 2005-01-27 at 12:52 -0500, Shailabh Nagar wrote:
Version e17 of the Class-based Kernel Resource Management
is now available for download from
http://sourceforge.net/project/showfiles.php?group_id=85838_id=94608
If you want comments on these, please post them inline.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julien TINNES wrote:
>
>>
>> Yeah, if it came from PaX the randomization would actually be useful.
>> Sorry, I've just woken up and already explained in another post.
>>
>
> Please, no hard feelings.
>
> Speaking about implementation of the non
On Thu, 2005-01-27 at 14:46 -0500, Dave Jones wrote:
> On Thu, Jan 27, 2005 at 08:11:20PM +0100, Ingo Molnar wrote:
>
> > so, i'm glad to report, it's a non-issue. Sometimes developers want to
> > disable randomisation during development (quick'n'easy hacks get quicker
> > and easier - e.g. if
* Dave Jones <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 27, 2005 at 08:11:20PM +0100, Ingo Molnar wrote:
>
> > so, i'm glad to report, it's a non-issue. Sometimes developers want to
> > disable randomisation during development (quick'n'easy hacks get quicker
> > and easier - e.g. if you watch
Gentlemen,
Isn't the return address on the stack an offset in the
code (.text) segment?
How would a random stack-pointer value help? I think you would
need to start a program at a random offset, not the stack!
No stack-smasher that worked would care about the value of
the stack-pointer.
While
> The fact is, different people have different needs. YOU only need to care
> about yourself. That's not true for a vendor. A single case that doesn't
> work ends up either (a) being ignored or (b) costing them money. See the
> problem? They can't win. Except by taking small steps, where the
On Thu, Jan 27, 2005 at 08:11:20PM +0100, Ingo Molnar wrote:
> so, i'm glad to report, it's a non-issue. Sometimes developers want to
> disable randomisation during development (quick'n'easy hacks get quicker
> and easier - e.g. if you watch an address within gdb), so having the
> capability
Not very important but ((get_random_int() % 4096) << 4) could be
optimized into get_random_int() & 0xFFF0. Because 4096 is a power of 2
you won't loose any entropy by doing & 0xFFF instead of %4096
Regards,
--
Julien TINNES - & france telecom - R Division/MAPS/NSS
Research Engineer -
Yeah, if it came from PaX the randomization would actually be useful.
Sorry, I've just woken up and already explained in another post.
Please, no hard feelings.
Speaking about implementation of the non executable pages semantics on
IA32, PaX and Exec-Shield are very different (well not that much
Rick Bressler wrote:
ata_piix version 1.03
ata_piix: combined mode detected
Combined mode == DMA impossible.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thursday 27 January 2005 1:02 am, Janos Farkas wrote:
> On 2005-01-25 at 10:54:36, David Brownell wrote:
> > On Tuesday 25 January 2005 10:35 am, David Ford wrote:
> > > PMTU bug -- or better said, bad firewall admin who blocks all ICMP.
> >
> > PMTU bug, sure -- but one that came late in RC2.
On Thu, 27 Jan 2005, John Richard Moser wrote:
>
> > Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
> > ACCEPTABLE for a lot of uses. People on 32-bit archtiectures have issues
> > with usable virtual memory areas etc.
>
> It never bothered me on my Barton core or
On Thu, Jan 27, 2005 at 01:22:28PM -0500, Bill Davidsen wrote:
> > *
> > * This function generates a SHA1 digest for a single. Be warned, it
> ^^
> Is this a term I don't know, "single" as a noun, or should "512 bit
> block" follow, as it
On Thu, Jan 27, 2005 at 10:37:45AM -0800, Phil Oester wrote:
> On Thu, Jan 27, 2005 at 04:49:18PM +, Russell King wrote:
> > so obviously the GC does appear to be working - as can be seen from the
> > number of entries in /proc/net/rt_cache. However, the number of objects
> > in the slab
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
The only claim above is the effect of clobbering virtual page 0 and
referring to this phenomenon by the macro. I was rather careful not to
claim a specific lower boundary to the address space.
OK, here is a patch that does compile against the
Gentlemen,
Isn't the return address on the stack an offset in the
code (.text) segment?
How would a random stack-pointer value help? I think you would
need to start a program at a random offset, not the stack!
No stack-smasher that worked would care about the value of
the stack-pointer.
Cheers,
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > This first patch of the series introduces a sysctl (default off) that
> > enables/disables the randomisation feature globally. Since randomisation may
> > make it harder to debug really tricky situations (reproducability goes
> > down), the
On Thu, 27 Jan 2005, Viktor Horvath wrote:
Hello everybody,
today I patched myself up from 2.6.7 vanilla to 2.6.10 vanilla, but
after all patches succeeded, "make menuconfig" shows "v2.6.8.1
Configuration". Even worse, a compiled kernel calls in his bootlog
himself "2.6.8.1". When installing the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
> On Thu, 27 Jan 2005, Linus Torvalds wrote:
>
>>Real engineering is about doing a good job balancing different issues.
>
>
[...]
> test. Maybe such a vendor understands that you have to ease into things,
> and you
Hi!
> >We do not disable HIGHMEM_64GB for 486, I do not see why we should add
> >extra code to geode...
>
> What about some of the other ones like MTRR and IOAPIC?
> I was kinda passing this along from someone I thought knew
> better than I, but I didn't like it either. It seems just setting
Hi Andrea,
On Wed, 26 Jan 2005 01:49:01 +0100, Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 25, 2005 at 08:11:19PM -0400, Mauricio Lin wrote:
> > Sometimes the first application to be killed is XFree. AFAIK the
>
> This makes more sense now. You need somebody trapping sigterm in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
> On Thu, 27 Jan 2005, John Richard Moser wrote:
>
>>What the hell?
>
>
> John. Stop frothing at the mouth already!
>
I'm coarse, I'm not angry.
> Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
Hi!
It happened for 3rd in a week now...
When problem happens, processes start to segfault, usually right
during startup. Programs that were loaded prior to problem usualy
works, and can be restarted. I also seen sendmail exec failing with
"no such file or directory" when it clearly was there.
Alan Cox wrote:
On Mer, 2005-01-26 at 22:10, Benjamin Herrenschmidt wrote:
On Wed, 2005-01-26 at 10:34 -0600, Brian King wrote:
Well, I honestly think that this is unnecessary burden. I think that
just dropping writes & returning data from the cache on reads is enough,
blocking userspace isn't
On 27 Jan 2005, at 19:04, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What the hell?
So instead of bringing something in that works, you bring something in
that does significantly less, and gives no savings on overhead or patch
complexity why? So you can later come out
Hello everybody,
today I patched myself up from 2.6.7 vanilla to 2.6.10 vanilla, but
after all patches succeeded, "make menuconfig" shows "v2.6.8.1
Configuration". Even worse, a compiled kernel calls in his bootlog
himself "2.6.8.1". When installing the whole kernel package, this
behaviour
On Thu, Jan 27, 2005 at 04:49:18PM +, Russell King wrote:
> so obviously the GC does appear to be working - as can be seen from the
> number of entries in /proc/net/rt_cache. However, the number of objects
> in the slab cache does grow day on day. About 4 days ago, it was only
> about 600
101 - 200 of 729 matches
Mail list logo
