Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 10, 2007 at 10:34:41PM +0100, Jan Engelhardt wrote:
>> On Mar 10 2007 22:27, Sam Ravnborg wrote:
>> >On Sat, Mar 10, 2007 at 07:23:41PM +0100, Jan Engelhardt wrote:
>> >> Whether the 'working config file path' should change when you do
>> >>
Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
>> Absolutely not. We dont want to slow down kernel 'just in case a fool might
>> want to do crazy things'
>
> Actually, I think it would make the kernel (negligibly) faster to bump
> f_pos before
On Mon, 12 Mar 2007, Michael K. Edwards wrote:
> On 3/12/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> > > Actually, I think it would make the kernel (negligibly) faster to bump
> > > f_pos before the vfs_w
Kumar Gala <[EMAIL PROTECTED]> wrote:
> For source lines I've seen both:
>
> source "arch/powerpc/platforms/52xx/Kconfig"
>
> and
>
> source arch/powerpc/platforms/85xx/Kconfig
>
> Is there a preferred style? Quotes or not?
$ find . -name Kconfig -exec grep ^source '{}' \;|grep \"|wc -l
Rik van Riel <[EMAIL PROTECTED]> wrote:
+++ linux-2.6.20.noarch/mm/swap.c2007-02-20 06:44:17.0 -0500
@@ -420,6 +420,26 @@ void pagevec_strip(struct pagevec *pvec)
> +if (printk_ratelimit())
> +printk("kswapd freed a swap
vjn <[EMAIL PROTECTED]> wrote:
> in my project i want to code the kernel such that when i plugged my usb it
> should ask for password and check it in the kernel space . can anyone help
> me
No, since the kernel has no way to ask for input. Imagine a two-seated
machine with two keyboards, mice
David Hubbard <[EMAIL PROTECTED]> wrote:
> For I/O and memory that ACPI accesses and has not reserved, the AML
> interpreter could allocate at run-time.
>
> I'm not sure how to implement exactly. For example, it would be bad to
> have a /proc/ioports that had a lot of single ports allocated, for
On Tue, 6 Mar 2007, Jean Delvare wrote:
> On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
> > 2) make ACPI take this lock whenever it touches ports not allocated by
> > itself
> >and release it on function return.
>
> This is costly.
TANSTAAFL. Yo
On Wed, 7 Mar 2007, Jean Delvare wrote:
> On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
> > 1) I asume port allocations or ACPI foreign port acces to be rare, so
> >there would be little impact on (un)registering hardware. Off cause
> >there are some
On Sat, 13 Jan 2007, Bill Davidsen wrote:
> Bodo Eggert wrote:
>
> > (*) This would allow fadvise_size(), too, which could reduce fragmentation
> > (and give an early warning on full disks) without forcing e.g. fat to
> > zero all blocks. OTOH, fadvise_size() woul
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> My point is, that there is code to handle sparse data now, without
> O_DIRECT involved, and if O_DIRECT bypasses that, it's not a problem
> with the idea of O_DIRECT, the kernel has a security problem.
The idea of O_DIRECT is to bypass the pagecache,
Helge Hafting <[EMAIL PROTECTED]> wrote:
> Michael Tokarev wrote:
>> But seriously - what about just disallowing non-O_DIRECT opens together
>> with O_DIRECT ones ?
>>
> Please do not create a new local DOS attack.
> I open some important file, say /etc/resolv.conf
> with O_DIRECT and just sit
On Tue, 16 Jan 2007, Arjan van de Ven wrote:
> On Tue, 2007-01-16 at 21:26 +0100, Bodo Eggert wrote:
> > Helge Hafting <[EMAIL PROTECTED]> wrote:
> > > Michael Tokarev wrote:
> > >> But seriously - what about just disallowing non-O_DIRECT open
Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
> On 1/18/07, Russell King <[EMAIL PROTECTED]> wrote:
>> On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
>> > 2. Set command_line as __initdata.
>> You can't.
>>
>> > -static char command_line[COMMAND_LINE_SIZE];
>> > +static char __initdata
Tony Foiani <[EMAIL PROTECTED]> wrote:
>> "David" == David Schwartz <[EMAIL PROTECTED]> writes:
> Just last night I formatted some new "500GB" drives, and they
> eventually came back with 465GB as the displayed capacity. Wouldn't
> it make more sense to display that as "465GiB"?
[...]
>
On Mon, 22 Jan 2007, Tony Foiani wrote:
> > "Jan" == Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
> Jan> For "F"s sake, when you gotta use abbreviations, then just use
> Jan> k=1000 and K=1024 already, b for bits and B for bytes. Problem
> Jan> gone.
>
>The one-letter abbreviations are
Scott Preece <[EMAIL PROTECTED]> wrote:
> My own hot button is making sure that the definition of what
> constitutes user activity is managed in exactly one place, whether in
> the kernel or not. My naive model would be to put the response at user
> level, but to provide a single point of
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-24 at 22:22 +0800, Aubrey Li wrote:
>> On 1/24/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>> > He wants to make a nommu system act like a mmu system; this will just
>> > never ever work.
>>
>> Nope. Actually my nommu system works
v j <[EMAIL PROTECTED]> wrote:
> On 2/14/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>> On Wed, 2007-02-14 at 21:16 -0800, v j wrote:
>> > This is in reference to the following thread:
>> >
>> > http://lkml.org/lkml/2006/12/14/63
>> >
>> > I am not sure if this is ever addressed in LKML, but
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Now if it's better to set up a empty node or use a nearby node
> for a memory less cpu can be further discussed. I still think
> I lean towards the later.
Worst case: Only slot 0 is used. Plug your memoryless CPU card into the last
slot before your plug
Sergei Organov <[EMAIL PROTECTED]> wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>> Exactly because "char" *by*definition* is "indeterminate sign" as far as
>> something like "strlen()" is concerned.
>
> Thanks, I now understand that you either don't see the difference
> between
v j <[EMAIL PROTECTED]> wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."
That's exactly what you tell to the linux community: If they don't contribute
to your project *FOR*NOTHING*IN*RETURN*, you'll punish them by - stamping
your feet, crying out loud and *paying*
On Fri, 16 Feb 2007, Sergei Organov wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > Sergei Organov <[EMAIL PROTECTED]> wrote:
> >> Linus Torvalds <[EMAIL PROTECTED]> writes:
> [...]
> > Using signed chars for strings is wrong in most countries on
On Fri, 16 Feb 2007, Sergei Organov wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > Sergei Organov <[EMAIL PROTECTED]> wrote:
> >> Linus Torvalds <[EMAIL PROTECTED]> writes:
> > If you don't code for a specific compiler with specific setting
Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Feb 2007, David Howells wrote:
>> > This is really the weak point - it offers no advantage over an equivalent
>> > implementation in user space (e.g. in the module tools). So why has to be
>> > done in the kernel?
>>
>> Because the
On Sat, 3 Feb 2007, Alan wrote:
> Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > This patch changes the module license handling code to:
> > - allow modules to have multiple licenses
>
> NAK
I still think it would be a good idea, but if too many people misinterpre
Al Boldi <[EMAIL PROTECTED]> wrote:
> Doing the following results in an incomplete vmlinuz:
> # make bzlilo
>
> objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
> make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
> make[1]: *** [arch/i386/boot/compressed/vmlinux] Error
Ethan Solomita <[EMAIL PROTECTED]> wrote:
> I suggest a variant on what Andrew says: don't change reclaim.
> Instead, when referencing a page, don't mark the page as referenced if
> the current task is not permitted to allocate from the page's node. I'm
> thinking in terms of cpusets, with
Fengguang Wu <[EMAIL PROTECTED]> wrote:
> The new/old ra class were implicitly stored in low bits of
> file_ra_state.flags. Now make the data structure obvious, and remove the
> coding tricks.
> +++ linux-2.6.20-rc4-mm1/include/linux/fs.h
> - unsigned long flags;/* RA_FLAG_xxx |
Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> On Friday 26 January 2007 19:23, Bill Davidsen wrote:
>> Denis Vlasenko wrote:
>> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
>> >> But even single-threaded I/O but in large quantities benefits from
>> >> O_DIRECT significantly, and I
Eriberto <[EMAIL PROTECTED]> wrote:
> I am trying understand the swap. I would like to know which is the
> maximum swap size on i386. Is 64 MB? If yes, how to know the origin of
> this "magic" number? I don't found it (Internet).
Look into the manpage of mkswap. It's 2 G x 32 swap partitions,
Dave Jones <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 12, 2007 at 05:58:41PM -0500, [EMAIL PROTECTED] wrote:
> > jengelh> What: RAW driver (CONFIG_RAW_DRIVER)
> > jengelh> When: December 2005
> > jengelh> Why:declared obsolete since kernel 2.6.3
> > jengelh> O_DIRECT can
Jeff Layton <[EMAIL PROTECTED]> wrote:
> This patch updates pipefs to do defer assigning an i_ino value to its inodes
> until someone actually tries to stat it. This allows us to have unique i_ino
> values for the inodes here, without the performance impact for anyone who
> doesn't actually care
change pipefs to use a unique inode number equal to the memory
address unless it would be truncated.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
---
Tested on i386.
--- 2.6.19/fs/pipe.c.ori2007-01-30 22:02:46.0 +0100
+++ 2.6.19/fs/pipe.c2007-01-30 23:22:27.0
es)
- move the ndiswrapper check into the new license checking routine
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
---
The license handling code was kind of strange:
- The kernel itself would only consider the first license, while modpost
looks at all of them.
- If you offer your mo
On Sat, 3 Feb 2007, Jan Engelhardt wrote:
> On Feb 3 2007 03:08, Bodo Eggert wrote:
> >This patch changes the module license handling code to:
> >- allow modules to have multiple licenses
> >- access GPL symbols if at least one license is GPL-compatible
>
> I strong
Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On some machines, buggy BIOSes don't properly setup WB MTRRs to
> cover all available RAM, meaning the last few megs (or even gigs)
> of memory will be marked uncached. Since Linux tends to allocate
> from high memory addresses first, this causes the
Since your (William) patch will change the kconfig files my proposed patch
would change, could you please add those changes?
I hand-updated the patch below as recommended by the original discussion
on LKML. It won't aply as-is because of that (and because of your changes).
---
Michael Kerrisk <[EMAIL PROTECTED]> wrote:
> ./man2/ioperm.2
> FIXME is the following ("Only the first 0x3ff I/O ports can be
> specified in this manner") still true? Looking at changes in
> include/asm-i386/processor.h between 2.4 and 2.6 suggests
> that the limit is
alan <[EMAIL PROTECTED]> wrote:
> I just wish that people would learn from the mistakes of others. The
> MacOS is a prime example of why you do not want to use a forked
> filesystem, yet some people still seem to think it is a good idea.
> (Forked filesystems tend to be fragile and do not play
Egmont Koblinger <[EMAIL PROTECTED]> wrote:
> 2. My patch introduced "question mark with inverted color attributes" as a
>last resort fallback glyph. Though it perfectly works on VGA console, on
>framebuffer you may end up with question marks that are highlighed but
>shouldn't be, and
On Tue, 19 Jun 2007, Egmont Koblinger wrote:
> On Tue, Jun 19, 2007 at 03:54:52PM +0200, Bodo Eggert wrote:
>
> > Does the FLUSH DTRT by design, or does it just shrink and hide the original
> > race?
> But you may be right: yes, it might be a bug (or misfeature) in the
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 04/19/2007 04:18 PM, Bart Trojanowski wrote:
>> I need to preserve some state from the bios before entering protected
>> mode. For now I want to copy it into some ram accessible by real-mode,
>> say the last megabyte visible in real-mode.
>>
>> What's
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
>> * Juergen Beisert <[EMAIL PROTECTED]> dixit:
>>> So the last free sector count is also stored. When mounting this
>>> filesystem you don't need to walk through the whole FAT to calculate
>>> the available space, you can use this "cached" value
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
> DervishD <[EMAIL PROTECTED]> writes:
>> Probably it's stupid to update the free clusters count at mount time
>> (sorry if so...) but it looks like a good idea to me. And of course, I
>> don't mean to update the value _on disk_, but the kernel's idea
On Sun, 22 Apr 2007, OGAWA Hirofumi wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > Windows _does_ care*, it will pretend the disk to be full.
>
> Did you test on 2000 or XP? (e.g. write 0 to free_clusters, then
> create new file.)
That was back when I still
Tejun Heo <[EMAIL PROTECTED]> wrote:
> This really isn't a regression. It's been always like that with libata.
> libata doesn't make devices go into standby mode and shutdown(8) does
> it for libata. The problem here is that libata does issue
> SYNCHRONIZE_CACHE on shutdown. So, the sequence
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Mon, 04 Jun 2007, Dmitry Torokhov wrote:
>> >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
>> >often. Launch the line above and try to do some typing...
>>
>> This used to work fine on my box last time I tried
Change the description of CONFIG_*HIGHMEM* to reflect "lost" memory due to
PCI space and the existence of the NX flag.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
---
I made this quick patch using the information from LKML as I remembered
it. Please verify.
--- 2.6.21/arch/
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On May 25 2007 14:14, David Miller wrote:
>>"!!" is used in contexts where pointers might be being
>>tested as well as plain integers, the "!!" turns a pointer
>>into the equivalent integer boolean for testing.
>>
>>NULL pointers become 0
>>non-NULL
On Sat, 26 May 2007, Al Viro wrote:
> On Sat, May 26, 2007 at 06:38:07PM +0200, Bodo Eggert wrote:
> > Not exactly, if(foo) is the same as if( (int) foo), which is not
> > guaranteed to result in non-null values for non-null pointers.
>
> RTFStandard.
... and don´t forget
Uncle George <[EMAIL PROTECTED]> wrote:
> i am using the GARMIN_GPS/usb driver to read a gps receiver.
> In testing the ability of my software to recover from various errors, I
> try this: unplug the gps/USB cable from the usb hub.
>
> Interestingly enough the thread spins.
> the SELECT() waits
Tejun Heo <[EMAIL PROTECTED]> wrote:
> David Greaves wrote:
>> I have 2 ide disks. If I enable SMART and hibernate/suspend2disk, SMART is
>> disabled when I resume.
Maybe it's disabled by the BIOS?
> According to the ATA standard, the device (drive) itself is responsible
> for preserving
Albert Cahalan <[EMAIL PROTECTED]> wrote:
> On 5/9/07, Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
>> 3. this still does not answer how can I *create* long name from within Linux.
>
> WTF? These names are too annoying to use, even if there
> weren't this limit. Anything over about 29 characters
Satyam Sharma <[EMAIL PROTECTED]> wrote:
> In fact you can't really say the same for
> volatile. We already assume the compiler _actually_ took some
> pains to stuff meaning into C's (lack of) definition of volatile and
> implement it -- but in what sense, nobody knows (the C standard
Theodore Tso <[EMAIL PROTECTED]> wrote:
> But as has already been discussed on this thread, in situations where
> the fileserver is under high memory pressure, any filesystem (XFS or
> ext4) would still end up allocating blocks out of order, resulting in
> fragmentation. Explicit preallocation,
Robin Getz <[EMAIL PROTECTED]> wrote:
> On Fri 4 May 2007 16:52, Robert Schwebel pondered:
>> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>> > We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
>> > that would be nice to put in the "right" place - I don't think
Jörn Engel <[EMAIL PROTECTED]> wrote:
> On Fri, 4 May 2007 10:46:10 +0100, Christoph Hellwig wrote:
>> Which means the right place to fix this is samba. Samba just need
>> to intersept lseek and pread/pwrite to never allocate sparse files
>> but do the right thing instead. Now what the right
Albert Cahalan <[EMAIL PROTECTED]> wrote:
[...]
> At two bytes per character, you get 127 characters in a filename.
> That's wider than the standard 80-column display, and far wider
> than the 28 or 29 characters that an "ls -l" has room for. In a
> GUI file manager or file dialog box, you'll
Pavel Machek <[EMAIL PROTECTED]> wrote:
>> I also don't like the idea of storing this in the swap partition for a
>> couple of reasons.
>>
>> 1. on many modern linux systems the swap partition is not large enough.
>>
>> for example, on my boxes with 16G or ram I only allocate 2G of swap
>>
Some Kconfig menus are very unsorted, so finding the option you want to
change takes careful reading of the complete menu.
I'm about to change some of the menus to be more user-friendly, starting
with the general setup and working my way through the rest as time permits.
In order to make the
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> vfat does not know about ownership, hence the files are always owned by the
> vfat mounter (or whatever the uid= option specified). Which brings
> a problem to userspace programs trying to utime() but which do not
> run as the same user as the vfat
rongly set keyboard LED.
This patch adds 48 bytes of init-text on x86_32.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
diff -X dontdiff -pruN linux-2.6.22/drivers/char/keyboard.c
linux-2.6.22.changed/drivers/char/keyboard.c
--- linux-2.6.22/drivers/char/keyboard.c2007-07-11 23
If you build using O=builddir ARCH=bar, you'll currently need to supply
ARCH= on builds from the builddir, too. With this patch, the generated
Makefile will do that instead.
make ARCH= will still override the Makefile default, allowing existing
scripts to work correctly.
Signed-Off-By: Bodo
On Wed, 11 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > Instead of the byte at 0x497 as suggested in that thread, I'm using the
> > byte at 0x417, which reflects the intended LED state. In order to change
> > the keyboard LED, DOS programs would change thi
On Wed, 11 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> >> That being said, one could argue that since this is a BIOS interface it
> >> should be queried via INT 16h, AH=02h and stuffed in the zeropage
> >> structure. This would also solve the i
If you build using O=builddir ARCH=bar, you'll currently need to supply
ARCH= on builds from the builddir, too. With this patch, the generated
Makefile will do that instead.
make ARCH= will still override the Makefile default, allowing existing
scripts to work correctly.
Signed-Off-By: Bodo
I toyed with setting up a diskless system in initramfs. In the process, I
came across some things:
1) There is no way to have the kernel not mount a filesystem,
unless you use /init or rdinit=.
1a) In the process of writing these patches, I found prepare_namespace not to
be called if
Disable mounting a root filesystem if root=rootfs is supplied.
If you put a rescue system on an initramfs, you should be able to boot it
without using tricks like an additional /init script.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
diff -X dontdiff -pruN linux-2.6.22/Documentation/
.
This is a rework of Al Boldi's "[PATCH] initramfs: Allow rootfs to use
tmpfs instead of ramfs". All the fame belongs to him, the bugs belong to me.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
diff -Xdontdiff -pruN linux-2.6.22.base/fs/Kconfig
linux-2.6.22.tmpfsroot/fs/Kconfig
This patch adds an option to disables the kernel's capability of mounting a
root device other than the ramfs. If you use initramfs, you don't need to
have this legacy feature anymore.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
diff -X dontdiff -pruN linux-2.6.22.base/init/do_mounts.c
On Fri, 13 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > I toyed with setting up a diskless system in initramfs. In the process, I
> > came across some things:
> >
> > 1) There is no way to have the kernel not mount a filesystem,
> >
On Fri, 13 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > On Fri, 13 Jul 2007, H. Peter Anvin wrote:
> >> Bodo Eggert wrote:
> >>> I toyed with setting up a diskless system in initramfs. In the process, I
> >>> came across some things:
> >
Al Boldi <[EMAIL PROTECTED]> wrote:
> Bodo Eggert wrote:
Please reply-to-all, I'm not subscribed, but reading through a news gateway.
>> This is a rework of Al Boldi's "[PATCH] initramfs: Allow rootfs to use
>> tmpfs instead of ramfs". All the fame belongs t
On Sat, 14 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > Setting the name of the rdinit process to the name of the init process
> > in order to select the root device should not be the right knob.
> >
>
> What's wrong with it?
rdinit is supposed to be th
On Sat, 14 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > On Sat, 14 Jul 2007, H. Peter Anvin wrote:
> >> Bodo Eggert wrote:
> >>> Setting the name of the rdinit process to the name of the init process
> >>> in order to select th
Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 13, 2007 at 03:20:54PM +0200, Rene Herman wrote:
>> As far as I'm aware, the actual reason for 4K stacks is that after the
>> system has been up and running for some time getting "1 physically
>> contiguous pages" becomes significantly easier
Satyam Sharma <[EMAIL PROTECTED]> wrote:
[zillions of ways to do -X dontdiff]
> Or just "cp -al" to create multiple trees at (almost) no disk cost
> that won't interfere with each other in any way, and makes the
> development process / generating patchsets trifle easier as well ...
Beware, some
On Sun, 15 Jul 2007, Rene Herman wrote:
> On 07/15/2007 07:17 PM, Bodo Eggert wrote:
> > Matt Mackall <[EMAIL PROTECTED]> wrote:
> >> On Fri, Jul 13, 2007 at 03:20:54PM +0200, Rene Herman wrote:
> >>> As far as I'm aware, the actual reason for 4K stacks is tha
On Tue, 17 Jul 2007, Jesper Juhl wrote:
> Please note that I was not trying to remove the 8K stack option right
> now - heck, I didn't even add anything to feature-removal-schedule.txt
> - all I wanted to accomplish with the patch that started this threas
> was; a) indicate that the 4K option is
On Tue, 17 Jul 2007, Rene Herman wrote:
> On 07/17/2007 12:37 AM, Ray Lee wrote:
> > On 7/16/07, Rene Herman <[EMAIL PROTECTED]> wrote:
> > If at some point one of the pro-4k stacks crowd can prove that all
> > code paths are safe
>
> I'll do that the minute you prove the current shared 8K
Albert Cahalan <[EMAIL PROTECTED]> wrote:
> On 6/19/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
>>> Right now, Linux isn't all that friendly to JIT emulators.
>>> Here are the problems and suggestions to improve the
Rene Herman <[EMAIL PROTECTED]> wrote:
> The point was that real mode could only access the first 1M, not
> the first 16... :-)
The real mode on i386+ can actually access the whole 4GB address range due to
a former-bug-now-feature in the i386+. This "bug" causes the segment limit
to not be reset
(not CCing security, since it's not a security bug and it's too late to
verify if they should be on cc. Will do later.)
Anand Jahagirdar <[EMAIL PROTECTED]> wrote:
> This patch Warns the administrator about the fork bombing attack
> (whenever any user is crossing its process limit). I have used
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 18:41 +0200, Joerg Schilling wrote:
>> Well, I did report these kind of problems many years ago and as it has not
>> been fixed after some years, I was asuming that it is still the way I see it
>> on Suse 10.0.
>
> I'd suggest
On Tue, 17 Jul 2007, Rene Herman wrote:
> On 07/17/2007 01:45 AM, Bodo Eggert wrote:
> > On Tue, 17 Jul 2007, Rene Herman wrote:
> >> On 07/17/2007 12:37 AM, Ray Lee wrote:
> >>> If at some point one of the pro-4k stacks crowd can prove that all
> >
On Tue, 17 Jul 2007, Rene Herman wrote:
> On 07/17/2007 12:06 PM, Bodo Eggert wrote:
> > On Tue, 17 Jul 2007, Rene Herman wrote:
> >> On 07/17/2007 01:45 AM, Bodo Eggert wrote:
> >>> You claim 4k+4k is safe, therefore 8k must be safe, too.
> >>
> >&
Alan Cox <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jul 2007 03:33:58 +0200
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>> > 8K stacks without IRQ stacks are not "safer" so I don't understand your
>> > comment ?
>>
>> Ouch, see the reports about 4k stack crashes. I agree they're not
>> safe w/o
On Wed, 18 Jul 2007, Rob Landley wrote:
> On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote:
> > I toyed with setting up a diskless system in initramfs. In the process, I
> > came across some things:
> >
> > 1) There is no way to have the kernel not mount a filesys
On Wed, 18 Jul 2007, Rene Herman wrote:
> On 07/18/2007 01:19 AM, Bodo Eggert wrote:
> > Please post a list of things you have designed, so I can avoid them.
>
> - The ability to read
> - The ability to understand
>
> You're doing a hell of a job already.
If you desig
On Tue, 17 Jul 2007, Arjan van de Ven wrote:
> > 1) It all can be reduced to 4K + 4K by asuming all IRQ happen on one CPU.
>
> no it's separate stacks for soft and hard irqs, so it's really 4+4+4
Thanks, I missed that information. Unfortunately this change still does
not help if one of these
On Thu, 19 Jul 2007, Stephen Smalley wrote:
> Not wanting to get into any flamewars here about selinux, but just FYI:
> security_sb_post_mountroot is obsolete and can be removed without harm
> to selinux; it is a leftover of selinux before we moved the initial
> policy load to userspace. These
Daniël Mantione <[EMAIL PROTECTED]> wrote:
> Op Thu, 19 Jul 2007, schreef Dmitry Torokhov:
>> On 7/14/07, Daniel Mantione <[EMAIL PROTECTED]> wrote:
> To make this discussion productive, I want to work towards a solution. I
> don't mind how I can make the keyboard work as it should, I just want
On Thu, 19 Jul 2007, Denis Vlasenko wrote:
> On Tuesday 17 July 2007 00:42, Bodo Eggert wrote:
> > > b) make 4K stacks the default option in vanilla kernel.org kernels as
> > > a gentle nudge towards getting people to start fixing the code paths
> > > that are not
Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote:
>> I'm not trying to document /sys/devices. I'm trying to document hotplug,
>> populating /dev, and things like firmware loading that fall out of that.
>> This requires use of sysfs, and I'm only
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> On 15/08/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
>> I noticed that a bad CD of mine makes DMA disabled:
[...]
>> hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
>> ide: failed opcode was: unknown
>> hda: DMA disabled
>> hda:
Mike Mohr <[EMAIL PROTECTED]> wrote:
(intentionally not snipping much)
> Per the post here:
>
> http://lkml.org/lkml/2007/6/18/228
>
> it appears that the group ownership patch has made it into .23. I am
> using these patches, amongst which the kernel component appears to be
> identical:
>
>
On Sun, 19 Aug 2007, Rene Herman wrote:
> On 08/19/2007 06:05 PM, Bodo Eggert wrote:
>
> > IMHO the check is broken:
> >
> > + if (((tun->owner != -1 &&
> > + current->euid != tun->owner
On Mon, 20 Aug 2007, Rene Herman wrote:
> On 08/19/2007 11:42 PM, Bodo Eggert wrote:
> > The intended [my me] semantics is If the user is not
> > * the allowed user
> > or
> > * member of the allowed group
> > or
> > * cabable of CAP_NE
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On Aug 16 2007 10:21, Andy Whitcroft wrote:
>>> + if ($line =~ /\bif\s*\([^\)]*\)\s*\;/) {
>>
>>Heh, you are the second person to suggest this check today, do I detect
>>some ripped out hair due to one of these!
>>
>>I've taken this idea and
501 - 600 of 739 matches
Mail list logo
