Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

Wouldn't the time taken by an easy syscall like getuid be a clear indicator? OG. On Thu, Jan 11, 2018 at 8:17 PM, Dave Hansen wrote: > On 01/11/2018 11:07 AM, Borislav Petkov wrote: >> On Thu, Jan 11, 2018 at 10:57:51AM -0800, Dave Hansen wrote: >>> I'd love to

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

Wouldn't the time taken by an easy syscall like getuid be a clear indicator? OG. On Thu, Jan 11, 2018 at 8:17 PM, Dave Hansen wrote: > On 01/11/2018 11:07 AM, Borislav Petkov wrote: >> On Thu, Jan 11, 2018 at 10:57:51AM -0800, Dave Hansen wrote: >>> I'd love to have a tool that tells you for

Re: Linux 4.15-rc7

Wasn't/Isn't the 4G/4G memory layout for 32 bits essentially KPTI? OG. On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek wrote: > Hi! > >> The one thing I want to do now that Meltdown and Spectre are public, >> is to give a *big* shout-out to the x86 people, and Thomas Gleixner

Re: Linux 4.15-rc7

Wasn't/Isn't the 4G/4G memory layout for 32 bits essentially KPTI? OG. On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek wrote: > Hi! > >> The one thing I want to do now that Meltdown and Spectre are public, >> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in >>

Re: [PATCH] vfs: hard-ban creating files with control characters in the name

On Tue, Oct 3, 2017 at 5:22 AM, Adam Borowski wrote: > Well, what about just \n then? Unlike all the others which are relatively > straightforward, \n requires -print0 which not all programs implement, and > way too many people consider too burdensome to use. If you don't

Re: [PATCH] vfs: hard-ban creating files with control characters in the name

On Tue, Oct 3, 2017 at 5:22 AM, Adam Borowski wrote: > Well, what about just \n then? Unlike all the others which are relatively > straightforward, \n requires -print0 which not all programs implement, and > way too many people consider too burdensome to use. If you don't use -print0, you're

Re: [GIT PULL] kdbus for 4.1-rc1

On Tue, Apr 21, 2015 at 12:31 PM, Greg Kroah-Hartman wrote: > Bringing up SCM_RIGHTS means that this is not going to be a bus system > at all. One principal design goal is to _not_ have peer-to-peer > connections between all communicating parties, but rather one connection > to a central

Re: [GIT PULL] kdbus for 4.1-rc1

On Tue, Apr 21, 2015 at 12:31 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: Bringing up SCM_RIGHTS means that this is not going to be a bus system at all. One principal design goal is to _not_ have peer-to-peer connections between all communicating parties, but rather one connection

Re: ia32_sysenter_target does not preserve EFLAGS

Hi, Beware that could be opening the door to information leaks for a very small gain (most syscalls are not getuid). Best, OG. On Sat, Mar 28, 2015 at 1:34 AM, Denys Vlasenko wrote: > On Fri, Mar 27, 2015 at 9:00 PM, Linus Torvalds > wrote: >> On Fri, Mar 27, 2015 at 7:25 AM, Denys

Re: ia32_sysenter_target does not preserve EFLAGS

Hi, Beware that could be opening the door to information leaks for a very small gain (most syscalls are not getuid). Best, OG. On Sat, Mar 28, 2015 at 1:34 AM, Denys Vlasenko vda.li...@googlemail.com wrote: On Fri, Mar 27, 2015 at 9:00 PM, Linus Torvalds torva...@linux-foundation.org

Re: [PATCH 1/6] tty: serial: 8250 core: provide a function to export uart_8250_port

On Wed, Jul 9, 2014 at 7:49 PM, Sebastian Andrzej Siewior wrote: > + * The lock assumption made here is none because runtime-pm suspend/resume > + * callbacks should not be invoked there is any operation performed on the > port. I think there's a missing "if"? Best, OG. -- To unsubscribe

Re: [PATCH 1/6] tty: serial: 8250 core: provide a function to export uart_8250_port

On Wed, Jul 9, 2014 at 7:49 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: + * The lock assumption made here is none because runtime-pm suspend/resume + * callbacks should not be invoked there is any operation performed on the port. I think there's a missing if? Best, OG. --

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

On Tue, Jul 16, 2013 at 9:32 AM, David Lang wrote: > On Mon, 15 Jul 2013, Sarah Sharp wrote: > >> The people who want to work together in a civil manner should get >> together and create a "Kernel maintainer's code of conduct" that >> outlines what they expect from fellow kernel developers. The

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

On Tue, Jul 16, 2013 at 9:32 AM, David Lang da...@lang.hm wrote: On Mon, 15 Jul 2013, Sarah Sharp wrote: The people who want to work together in a civil manner should get together and create a Kernel maintainer's code of conduct that outlines what they expect from fellow kernel developers.

Re: [RFC] Simplifying kernel configuration for distro issues

On Sat, Jul 14, 2012 at 12:33:51AM +0200, Jesper Juhl wrote: > How about we start cutting down on the options and start saying "a Linux > system will provide feature x and y - always ...". > Stuff like (and I'm just pulling random stuff out here) - ASLR, seccomp, > 250HZ minimum etc etc.. We

Re: [RFC] Simplifying kernel configuration for distro issues

On Sat, Jul 14, 2012 at 12:33:51AM +0200, Jesper Juhl wrote: How about we start cutting down on the options and start saying a Linux system will provide feature x and y - always Stuff like (and I'm just pulling random stuff out here) - ASLR, seccomp, 250HZ minimum etc etc.. We could cut

Re: Integration of SCST in the mainstream Linux kernel

On Mon, Feb 04, 2008 at 05:57:47PM -0500, Jeff Garzik wrote: > iSCSI and NBD were passe ideas at birth. :) > > Networked block devices are attractive because the concepts and > implementation are more simple than networked filesystems... but usually > you want to run some sort of filesystem on

Re: Integration of SCST in the mainstream Linux kernel

On Mon, Feb 04, 2008 at 05:57:47PM -0500, Jeff Garzik wrote: iSCSI and NBD were passe ideas at birth. :) Networked block devices are attractive because the concepts and implementation are more simple than networked filesystems... but usually you want to run some sort of filesystem on top.

Re: section breakage on ppc64 (aka __devinitconst is broken by design)

On Sun, Feb 03, 2008 at 09:02:08PM +, Al Viro wrote: > On ppc64 relocs => r/w, AFAICS. On other targets we might have any number > of other rules. And -fpic/PIC => (relocs => r/w) because of the DT_TEXTREL crap. Not of immediate interest to the kernel though. OG. -- To unsubscribe from

Re: section breakage on ppc64 (aka __devinitconst is broken by design)

On Sun, Feb 03, 2008 at 09:02:08PM +, Al Viro wrote: On ppc64 relocs = r/w, AFAICS. On other targets we might have any number of other rules. And -fpic/PIC = (relocs = r/w) because of the DT_TEXTREL crap. Not of immediate interest to the kernel though. OG. -- To unsubscribe from this

Re: Why is the kfree() argument const?

On Fri, Jan 18, 2008 at 05:45:49PM +0100, [EMAIL PROTECTED] wrote: > The malloc attribute is exactly about this : giving the compiler the > indication that no other pointer aliases this object, allowing for > better optimizations. If you put a malloc attribute on the allocator and no free

Re: Why is the kfree() argument const?

On Thu, Jan 17, 2008 at 09:02:44PM -0800, David Schwartz wrote: > 3) It is most useful for 'kfree' to be non-const because destroying an > object through a const pointer can easily be done in error. One of the > reasons you provide a const pointer is because you need the function you > pass the

Re: Why is the kfree() argument const?

On Fri, Jan 18, 2008 at 08:53:44AM -0500, Andy Lutomirski wrote: > I'd say this implies the exact opposite. It almost sounds like the > compiler is free to change: > > void foo(const int *x); > foo(x); > printf("%d", x); > > to: > > void foo(const int *x); > printf("%d", x); > foo(x); That's

Re: Why is the kfree() argument const?

On Fri, Jan 18, 2008 at 05:45:49PM +0100, [EMAIL PROTECTED] wrote: The malloc attribute is exactly about this : giving the compiler the indication that no other pointer aliases this object, allowing for better optimizations. If you put a malloc attribute on the allocator and no free attribute

Re: Why is the kfree() argument const?

On Fri, Jan 18, 2008 at 08:53:44AM -0500, Andy Lutomirski wrote: I'd say this implies the exact opposite. It almost sounds like the compiler is free to change: void foo(const int *x); foo(x); printf(%d, x); to: void foo(const int *x); printf(%d, x); foo(x); That's only if neither

Re: Why is the kfree() argument const?

On Thu, Jan 17, 2008 at 09:02:44PM -0800, David Schwartz wrote: 3) It is most useful for 'kfree' to be non-const because destroying an object through a const pointer can easily be done in error. One of the reasons you provide a const pointer is because you need the function you pass the

Re: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

On Fri, Jan 04, 2008 at 11:38:29AM -0500, Alan Stern wrote: > How about changing it to say "unavailable"? That doesn't imply > permanence. How about not changing a userland-visible interface gratuitously? OG. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the

Re: [linux-pm][PATCH] base: Change power/wakeup output from to unsupported if wakeup feature isn't supported by a device

On Fri, Jan 04, 2008 at 11:38:29AM -0500, Alan Stern wrote: How about changing it to say unavailable? That doesn't imply permanence. How about not changing a userland-visible interface gratuitously? OG. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: INITIO scsi driver fails to work properly

On Mon, Dec 17, 2007 at 06:08:59PM +0200, Boaz Harrosh wrote: > Below fixes a deadly typo. Might as well be included in 2.6.24 You're sure ? scsi_for_each_sg includes a (sg)++ already... > scsi_for_each_sg(cmnd, sglist, cblk->sglen, i) { > sg->data =

Re: INITIO scsi driver fails to work properly

On Mon, Dec 17, 2007 at 06:08:59PM +0200, Boaz Harrosh wrote: Below fixes a deadly typo. Might as well be included in 2.6.24 You're sure ? scsi_for_each_sg includes a (sg)++ already... scsi_for_each_sg(cmnd, sglist, cblk-sglen, i) { sg-data =

Re: can support for "rpm"-based package building just be dropped?

On Mon, Nov 26, 2007 at 05:17:18PM +0100, Jan Engelhardt wrote: > rpm -b does not work in opensuse anymore (redirects you to use rpmbuild), and > I > bet fedora will do the same, so if you don't have rpm-build, tough luck for > make rpm. The point, if I understand it correctly, was that when

Re: can support for rpm-based package building just be dropped?

On Mon, Nov 26, 2007 at 05:17:18PM +0100, Jan Engelhardt wrote: rpm -b does not work in opensuse anymore (redirects you to use rpmbuild), and I bet fedora will do the same, so if you don't have rpm-build, tough luck for make rpm. The point, if I understand it correctly, was that when

Re: Why is FIBMAP ioctl root only?

Original thread btw: http://www.ussg.indiana.edu/hypermail/linux/kernel/9907.0/0132.html OG. - 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

Re: Why is FIBMAP ioctl root only?

On Thu, Nov 22, 2007 at 07:17:14PM +0100, Jan Kara wrote: > Hi, > > I guess subject says it all - why is FIBMAP ioctl restricted only to > root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without any > special capabilities so we are inconsistent here too... > Would anyone mind

Re: Why is FIBMAP ioctl root only?

Original thread btw: http://www.ussg.indiana.edu/hypermail/linux/kernel/9907.0/0132.html OG. - 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

Re: Why is FIBMAP ioctl root only?

On Thu, Nov 22, 2007 at 07:17:14PM +0100, Jan Kara wrote: Hi, I guess subject says it all - why is FIBMAP ioctl restricted only to root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without any special capabilities so we are inconsistent here too... Would anyone mind if the

The /proc/acpi/video/*/DOS default change broke my system

T'was done as a21101c46ca5b4320e31408853cdcbf7cb1ce4ed. The system is a latitude x300 (i855GM). With '1', the old default, I can close and re-open the lid and have nothing happening. With '0' the screen turns black with the mouse cursor left frozen on top of it and the computer crashed.

The /proc/acpi/video/*/DOS default change broke my system

T'was done as a21101c46ca5b4320e31408853cdcbf7cb1ce4ed. The system is a latitude x300 (i855GM). With '1', the old default, I can close and re-open the lid and have nothing happening. With '0' the screen turns black with the mouse cursor left frozen on top of it and the computer crashed.

Re: [alsa-devel] [BUG] New Kernel Bugs

On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > Totally unrelated indeed so why are spouting crap? If the kohab list has a > problem take it up with them but keep ALSA out of it. alsa-devel has only > ever moderated out spam -- nothing else. That is incorrect. Hopefully it is

Re: [alsa-devel] [BUG] New Kernel Bugs

On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: Totally unrelated indeed so why are spouting crap? If the kohab list has a problem take it up with them but keep ALSA out of it. alsa-devel has only ever moderated out spam -- nothing else. That is incorrect. Hopefully it is the

Re: [PATCH 09/10] Change table chaining layout

On Wed, Oct 24, 2007 at 03:38:04PM +0200, Jens Axboe wrote: > (please don't drop cc lists) Sorry. Reactions of people to Cc vary... > That doesn't make any sense. Both sg_set_buf() and sg_set_page() set the > same thing in the sg entry, the input is just different. It has nothing > to do with

Re: [PATCH 09/10] Change table chaining layout

On Wed, Oct 24, 2007 at 11:12:42AM +0200, Jens Axboe wrote: > sg_set_buf() also sets length and offset, sg_set_page() is just a mirror > of that. So I'd prefer to keep the naming. Hmmm, sg_set_phys/sg_set_virt to be more symmetrical to sg_phys/sg_virt? OG. - To unsubscribe from this list: send

Re: [PATCH 09/10] Change table chaining layout

On Wed, Oct 24, 2007 at 11:12:42AM +0200, Jens Axboe wrote: sg_set_buf() also sets length and offset, sg_set_page() is just a mirror of that. So I'd prefer to keep the naming. Hmmm, sg_set_phys/sg_set_virt to be more symmetrical to sg_phys/sg_virt? OG. - To unsubscribe from this list: send

Re: [PATCH 09/10] Change table chaining layout

On Wed, Oct 24, 2007 at 03:38:04PM +0200, Jens Axboe wrote: (please don't drop cc lists) Sorry. Reactions of people to Cc vary... That doesn't make any sense. Both sg_set_buf() and sg_set_page() set the same thing in the sg entry, the input is just different. It has nothing to do with

Re: Point of gpl-only modules (flame)

On Tue, Oct 02, 2007 at 11:49:04PM +0200, Jimmy wrote: > Also, how about a list of PROS, explain to me whats so cool about it? People who do binary-only drivers have a much better chance of not doing a derivative work when they only use non-EXPORT_GPL exports, and as a result not being in the

Re: Point of gpl-only modules (flame)

On Tue, Oct 02, 2007 at 11:49:04PM +0200, Jimmy wrote: Also, how about a list of PROS, explain to me whats so cool about it? People who do binary-only drivers have a much better chance of not doing a derivative work when they only use non-EXPORT_GPL exports, and as a result not being in the

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

On Mon, Oct 01, 2007 at 09:04:44AM -0700, Linus Torvalds wrote: > For example, you security guys still debate "inodes" vs "pathnames", as if > that was an either-or issue. > > Quite frankly, I'm not a security person, but I can tell a bad argument > from a good one. And an argument that says

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

On Mon, Oct 01, 2007 at 09:04:44AM -0700, Linus Torvalds wrote: For example, you security guys still debate inodes vs pathnames, as if that was an either-or issue. Quite frankly, I'm not a security person, but I can tell a bad argument from a good one. And an argument that says inodes _or_

Re: Chroot bug

On Wed, Sep 26, 2007 at 08:43:44PM +0930, David Newall wrote: > Olivier Galibert wrote: > >chroot does not allow you to walk out if you're in. > > You're mistaken. Or more properly, further use of chroot lets you walk > out. This really has been said before, and

Re: Chroot bug

On Wed, Sep 26, 2007 at 07:57:38PM +0930, David Newall wrote: > As has been said, there are thousands of ways to break out of a chroot. > It's just that one of them should not be that chroot lets you walk out. chroot does not allow you to walk out if you're in. It only allows you to walk

Re: Chroot bug

On Wed, Sep 26, 2007 at 07:57:38PM +0930, David Newall wrote: As has been said, there are thousands of ways to break out of a chroot. It's just that one of them should not be that chroot lets you walk out. chroot does not allow you to walk out if you're in. It only allows you to walk

Re: Chroot bug

On Wed, Sep 26, 2007 at 08:43:44PM +0930, David Newall wrote: Olivier Galibert wrote: chroot does not allow you to walk out if you're in. You're mistaken. Or more properly, further use of chroot lets you walk out. This really has been said before, and before, and before. chroot

Re: false positive in checkpatch.pl (complex macro values)

On Fri, Aug 24, 2007 at 05:43:47AM -0700, SL Baur wrote: > Who uses code like this, by the way? People who think Posix is an example to follow maybe? Not sure if it would go past the maintainers though :-) # define PTHREAD_MUTEX_INITIALIZER \ { { 0, 0, 0, 0, 0, { 0 } } } # ifdef __USE_GNU #

Re: false positive in checkpatch.pl (complex macro values)

On Fri, Aug 24, 2007 at 05:43:47AM -0700, SL Baur wrote: Who uses code like this, by the way? People who think Posix is an example to follow maybe? Not sure if it would go past the maintainers though :-) # define PTHREAD_MUTEX_INITIALIZER \ { { 0, 0, 0, 0, 0, { 0 } } } # ifdef __USE_GNU #

Re: Is it time for remove (crap) ALSA from kernel tree ?

On Mon, Jun 25, 2007 at 02:58:02PM +0200, Takashi Iwai wrote: > Hm... I don't agree much with the virtual relay device solution. > I once experimentally implemented an ALSA-OSS virtual kernel driver. > But, it just gives more complexity. So instead you move the complexity in the library where it

Re: Is it time for remove (crap) ALSA from kernel tree ?

On Mon, Jun 25, 2007 at 02:40:23PM +0200, Jan Engelhardt wrote: > > On Jun 25 2007 14:31, Takashi Iwai wrote: > >> It was started in time when most cheap sound cards was without hw mixer. > >> And .. when today you use ALSA on sound card without hw mixer still all > >> this (past ?) problems are

Re: Is it time for remove (crap) ALSA from kernel tree ?

On Mon, Jun 25, 2007 at 02:31:08PM +0200, Takashi Iwai wrote: > So, do you mean the soft-mixing is the biggest issue? That's just a > part of a design issue, and if we want to go to that way, the > impelemtation would be trivial, regardless on ALSA or not. Totally > irrelevant argument

Re: Is it time for remove (crap) ALSA from kernel tree ?

On Mon, Jun 25, 2007 at 02:40:23PM +0200, Jan Engelhardt wrote: On Jun 25 2007 14:31, Takashi Iwai wrote: It was started in time when most cheap sound cards was without hw mixer. And .. when today you use ALSA on sound card without hw mixer still all this (past ?) problems are actual.

Re: Is it time for remove (crap) ALSA from kernel tree ?

On Mon, Jun 25, 2007 at 02:31:08PM +0200, Takashi Iwai wrote: So, do you mean the soft-mixing is the biggest issue? That's just a part of a design issue, and if we want to go to that way, the impelemtation would be trivial, regardless on ALSA or not. Totally irrelevant argument regarding

Re: Is it time for remove (crap) ALSA from kernel tree ?

On Mon, Jun 25, 2007 at 02:58:02PM +0200, Takashi Iwai wrote: Hm... I don't agree much with the virtual relay device solution. I once experimentally implemented an ALSA-OSS virtual kernel driver. But, it just gives more complexity. So instead you move the complexity in the library where it is

Re: Is it time for remove (crap) ALSA from kernel tree ?

On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote: > > Sory Alan but I don't want philosophical/historical discuss. > > Try to answer on question "ALSA or OSS ?" using *only* technical arguments. > > We dropped OSS for ALSA for technical reasons. Those being that ALSA > - has a better

Re: Is it time for remove (crap) ALSA from kernel tree ?

On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote: Sory Alan but I don't want philosophical/historical discuss. Try to answer on question ALSA or OSS ? using *only* technical arguments. We dropped OSS for ALSA for technical reasons. Those being that ALSA - has a better audio API

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

On Thu, Jun 14, 2007 at 09:20:35PM -0400, Rob Landley wrote: > Why do you keep saying "upgraded" to GPLv3? How is it an improvement to move > from a small, simple, elegant, and tested implementation to something that's > more complicated, less elegant, less coherent, totally untested, and full

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

On Thu, Jun 14, 2007 at 09:20:35PM -0400, Rob Landley wrote: Why do you keep saying upgraded to GPLv3? How is it an improvement to move from a small, simple, elegant, and tested implementation to something that's more complicated, less elegant, less coherent, totally untested, and full of

Re: [PATCH -mm] 1/2: MMCONFIG: validate against ACPI motherboard resources

On Tue, May 29, 2007 at 10:03:32PM -0600, Robert Hancock wrote: > -Validate that the area is reserved even if we read it from the > chipset directly and not from the MCFG table. This catches the case > where the BIOS didn't set the location properly in the chipset and > has mapped it over other

Re: [PATCH -mm] 1/2: MMCONFIG: validate against ACPI motherboard resources

On Tue, May 29, 2007 at 10:03:32PM -0600, Robert Hancock wrote: -Validate that the area is reserved even if we read it from the chipset directly and not from the MCFG table. This catches the case where the BIOS didn't set the location properly in the chipset and has mapped it over other things

Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources

On Wed, May 23, 2007 at 02:20:23PM -0700, Jesse Barnes wrote: > On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote: > > Ehh. Even for PCIe, why not use the normal accesses for the first 256 > > bytes? Problem solved. > > Ok, this patch also works. We still need to enable mmconfig space for

Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources

On Wed, May 23, 2007 at 02:20:23PM -0700, Jesse Barnes wrote: On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote: Ehh. Even for PCIe, why not use the normal accesses for the first 256 bytes? Problem solved. Ok, this patch also works. We still need to enable mmconfig space for PCIe

Re: [PATCH] mmconfig: Some additional chipset register values validation.

On Wed, May 02, 2007 at 11:52:36AM +0200, Andi Kleen wrote: > On Wednesday 02 May 2007 02:50:11 Olivier Galibert wrote: > > On i945, a mmconfig range hitting the f000- zone conflicts > > with the APIC registers and others. Consider it invalid. > > > > On

Re: [PATCH] mmconfig: Some additional chipset register values validation.

On Wed, May 02, 2007 at 11:52:36AM +0200, Andi Kleen wrote: On Wednesday 02 May 2007 02:50:11 Olivier Galibert wrote: On i945, a mmconfig range hitting the f000- zone conflicts with the APIC registers and others. Consider it invalid. On E7520, values and f000

[PATCH] mmconfig: Some additional chipset register values validation.

On i945, a mmconfig range hitting the f000- zone conflicts with the APIC registers and others. Consider it invalid. On E7520, values and f000 for the window register are defined invalid in the documentation. --- I haven't seen a bios use these values, but who trusts biosen

[PATCH] mmconfig: Some additional chipset register values validation.

On i945, a mmconfig range hitting the f000- zone conflicts with the APIC registers and others. Consider it invalid. On E7520, values and f000 for the window register are defined invalid in the documentation. --- I haven't seen a bios use these values, but who trusts biosen

Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources

On Sun, Apr 29, 2007 at 08:14:37PM -0600, Robert Hancock wrote: > -Validate that the area is reserved even if we read it from the > chipset directly and not from the MCFG table. This catches the case > where the BIOS didn't set the location properly in the chipset and > has mapped it over other

Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources

On Sun, Apr 29, 2007 at 08:14:37PM -0600, Robert Hancock wrote: -Validate that the area is reserved even if we read it from the chipset directly and not from the MCFG table. This catches the case where the BIOS didn't set the location properly in the chipset and has mapped it over other things

Re: Back to the future.

On Thu, Apr 26, 2007 at 03:49:51PM -0700, David Lang wrote: > swap partitions are limited to 2G (or at least they were a couple of months > ago when I last checked). I also don't want to run the risk of having a box > try to _use_ 16G worth of swap. I'd rather have the box hit OOM first. They

Re: Back to the future.

On Fri, Apr 27, 2007 at 06:50:56AM +1000, Nigel Cunningham wrote: > I'm perfectly willing to think through some alternate approach if you > suggest something or prod my thinking in a new direction, but I'm afraid > I just can't see right now how we can achieve what you're after. Ok, what about

Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

On Thu, Apr 26, 2007 at 01:09:53PM +0200, Pavel Machek wrote: > #define SNAPSHOT_SET_IMAGE_SIZE _IOW(SNAPSHOT_IOC_MAGIC, 6, > unsigned long) So I'm not supposed to be able to suspend the 16Gb-ram, 32bits servers I have here? OG. - To unsubscribe from this list: send the line

Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

On Thu, Apr 26, 2007 at 01:09:53PM +0200, Pavel Machek wrote: #define SNAPSHOT_SET_IMAGE_SIZE _IOW(SNAPSHOT_IOC_MAGIC, 6, unsigned long) So I'm not supposed to be able to suspend the 16Gb-ram, 32bits servers I have here? OG. - To unsubscribe from this list: send the line

Re: Back to the future.

On Fri, Apr 27, 2007 at 06:50:56AM +1000, Nigel Cunningham wrote: I'm perfectly willing to think through some alternate approach if you suggest something or prod my thinking in a new direction, but I'm afraid I just can't see right now how we can achieve what you're after. Ok, what about this

Re: Back to the future.

On Thu, Apr 26, 2007 at 03:49:51PM -0700, David Lang wrote: swap partitions are limited to 2G (or at least they were a couple of months ago when I last checked). I also don't want to run the risk of having a box try to _use_ 16G worth of swap. I'd rather have the box hit OOM first. They

Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

On Wed, Apr 25, 2007 at 11:50:45AM -0700, Linus Torvalds wrote: > .. but if the alternative is a feature that just isn't worth it, and > likely to not only have its own bugs, but cause bugs elsewhere? (And yes, > I believe STD is both of those. There's a reason it's called "STD". Go > to google

Re: [patch 1/7] libata: check for AN support

On Wed, Apr 25, 2007 at 08:16:51PM +0100, Matt Sealey wrote: > > +#define ata_id_has_AN(id) \ > > + ( (((id)[76] != 0x) && ((id)[76] != 0x)) && \ > > + ((id)[78] & (1 << 5)) ) > > ?? > > > --- 2.6-git.orig/include/linux/libata.h > > +++ 2.6-git/include/linux/libata.h > > @@ -136,6

Re: [patch 1/7] libata: check for AN support

On Wed, Apr 25, 2007 at 08:16:51PM +0100, Matt Sealey wrote: +#define ata_id_has_AN(id) \ + ( (((id)[76] != 0x) ((id)[76] != 0x)) \ + ((id)[78] (1 5)) ) ?? --- 2.6-git.orig/include/linux/libata.h +++ 2.6-git/include/linux/libata.h @@ -136,6 +136,7 @@ enum {

Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

On Wed, Apr 25, 2007 at 11:50:45AM -0700, Linus Torvalds wrote: .. but if the alternative is a feature that just isn't worth it, and likely to not only have its own bugs, but cause bugs elsewhere? (And yes, I believe STD is both of those. There's a reason it's called STD. Go to google and

Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

On Tue, Apr 24, 2007 at 04:41:58PM -0700, Linus Torvalds wrote: > How many different magic ioctl's does the thing introduce? Is it really > just *two* entry-points (and how simple are they, interface-wise), and > nothing else? Aren't you a little late to the party here? The userland version is

Re: [patch 1/7] libata: check for AN support

On Tue, Apr 24, 2007 at 01:53:27PM -0700, Kristen Carlson Accardi wrote: > Check to see if an ATAPI device supports Asynchronous Notification. > If so, enable it. > > changes from last version: > * fix typo in ata_id_has_AN and make word 76 test more clear > * If we fail to set the AN feature,

Re: [patch 1/7] libata: check for AN support

On Tue, Apr 24, 2007 at 08:49:04AM -0700, Kristen Carlson Accardi wrote: > On Tue, 24 Apr 2007 12:23:04 +0200 > Olivier Galibert <[EMAIL PROTECTED]> wrote: > > > Sorry for replying to Alan's reply, I missed the original mail. > > > > > > +#define ata_id_ha

Re: [patch 1/7] libata: check for AN support

Sorry for replying to Alan's reply, I missed the original mail. > > +#define ata_id_has_AN(id) \ > > + ((id[76] && (~id[76])) & ((id)[78] & (1 << 5))) (a && ~a) & (b & 32) I don't think that does what you think it does, because at that point it's a funny way to write 0 ((0 or 1) binary-and

Re: [patch 1/7] libata: check for AN support

Sorry for replying to Alan's reply, I missed the original mail. +#define ata_id_has_AN(id) \ + ((id[76] (~id[76])) ((id)[78] (1 5))) (a ~a) (b 32) I don't think that does what you think it does, because at that point it's a funny way to write 0 ((0 or 1) binary-and (0 or 32)).

Re: [patch 1/7] libata: check for AN support

On Tue, Apr 24, 2007 at 08:49:04AM -0700, Kristen Carlson Accardi wrote: On Tue, 24 Apr 2007 12:23:04 +0200 Olivier Galibert [EMAIL PROTECTED] wrote: Sorry for replying to Alan's reply, I missed the original mail. +#define ata_id_has_AN(id) \ + ((id[76] (~id[76

Re: [patch 1/7] libata: check for AN support

On Tue, Apr 24, 2007 at 01:53:27PM -0700, Kristen Carlson Accardi wrote: Check to see if an ATAPI device supports Asynchronous Notification. If so, enable it. changes from last version: * fix typo in ata_id_has_AN and make word 76 test more clear * If we fail to set the AN feature, just

Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

On Tue, Apr 24, 2007 at 04:41:58PM -0700, Linus Torvalds wrote: How many different magic ioctl's does the thing introduce? Is it really just *two* entry-points (and how simple are they, interface-wise), and nothing else? Aren't you a little late to the party here? The userland version is

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

On Wed, Apr 04, 2007 at 07:15:32PM +0100, Russell King wrote: > *However* you still run into the issue that you do not know how many > serial ports you will need to register a tty driver with the tty layer. > Solve that technical problem and the idea of having a single namespace > for chosen

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

On Wed, Apr 04, 2007 at 07:15:32PM +0100, Russell King wrote: *However* you still run into the issue that you do not know how many serial ports you will need to register a tty driver with the tty layer. Solve that technical problem and the idea of having a single namespace for chosen serial

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

On Wed, Apr 04, 2007 at 12:14:34PM +0100, Alan Cox wrote: > > If you want hierarchy, create it: > > > > /sys/blah/serial/controllerX/portY > > > > and keeping them all under the ttyS? major keeps the simple > > cases working sanely too. > > Currently yes you could do that, but that would break

Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

On Wed, Apr 04, 2007 at 12:14:34PM +0100, Alan Cox wrote: If you want hierarchy, create it: /sys/blah/serial/controllerX/portY and keeping them all under the ttyS? major keeps the simple cases working sanely too. Currently yes you could do that, but that would break all the back

Re: max_loop limit

On Thu, Mar 22, 2007 at 02:33:14PM +, Al Viro wrote: > Correction: current ABI is crap. To set the thing up you need to open > it and issue an ioctl. Which is a bloody bad idea, for obvious reasons... Agreed. What would be a right way? Global device ala ptmx/tun/tap? New syscall?

Re: max_loop limit

On Thu, Mar 22, 2007 at 02:33:14PM +, Al Viro wrote: Correction: current ABI is crap. To set the thing up you need to open it and issue an ioctl. Which is a bloody bad idea, for obvious reasons... Agreed. What would be a right way? Global device ala ptmx/tun/tap? New syscall? Something

Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

On Tue, Feb 13, 2007 at 10:57:24PM +0100, Ingo Molnar wrote: > > * Davide Libenzi wrote: > > > > Open issues: > > > If this is going to be a generic AIO subsystem: > > > > - Cancellation of pending request > > How about implementing aio_cancel() as a NOP. Can anyone prove that the > kernel

Re: somebody dropped a (warning) bomb

On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote: > I agree that making strxxx() family special is not a good idea. So what > do we do for a random foo(char*) called with an 'unsigned char*' > argument? Silence? Hmmm... It's not immediately obvious that it's indeed > harmless. Yet

  1   2   3   >