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

[Olivier Galibert]

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 sure "KPTI enabled or not",
>>> but I'd also love to have it be something I can easily distribute
>>> without it being handled like a WMD.
>> You mean this:
>>
>> https://git.kernel.org/tip/87590ce6e373d1a5401f6539f0c59ef92dd924a9
>
> I meant that works across all the kpti implementations.  Those with gunk
> in /sys, /proc/cpuinfo, or with nothing at all like the original KAISER
> patches I posted.
>
> And, yes, I want a pony.  I just though someone had such a pony handy
> and it was trivial.

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

[Olivier Galibert]

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 sure "KPTI enabled or not",
>>> but I'd also love to have it be something I can easily distribute
>>> without it being handled like a WMD.
>> You mean this:
>>
>> https://git.kernel.org/tip/87590ce6e373d1a5401f6539f0c59ef92dd924a9
>
> I meant that works across all the kpti implementations.  Those with gunk
> in /sys, /proc/cpuinfo, or with nothing at all like the original KAISER
> patches I posted.
>
> And, yes, I want a pony.  I just though someone had such a pony handy
> and it was trivial.

Re: Linux 4.15-rc7

[Olivier Galibert]

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
>> particular for really being on top of this.  It's been one huge
>> annoyance, and honestly, Thomas really went over and beyond in this
>> whole mess.  A lot of other people have obviously been involved too,
>
> As I understand it: KPTI prevents Meltdown attack on x86-64, but
> Spectre means even x86-64 is not expected to be safe?
>
> Ok, so Meltdown is public... And I still have some nice 32-bit
> machines I'd like to keep working.
>
> Proof of concept is out, https://github.com/IAIK/meltdown/ .
>
> Is anyone working on KPTI for x86-32? SLES11 should still be
> supported, and that should have x86-32 version; any chance SUSE can
> share some patches?
>
> Thanks,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 4.15-rc7

[Olivier Galibert]

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
>> particular for really being on top of this.  It's been one huge
>> annoyance, and honestly, Thomas really went over and beyond in this
>> whole mess.  A lot of other people have obviously been involved too,
>
> As I understand it: KPTI prevents Meltdown attack on x86-64, but
> Spectre means even x86-64 is not expected to be safe?
>
> Ok, so Meltdown is public... And I still have some nice 32-bit
> machines I'd like to keep working.
>
> Proof of concept is out, https://github.com/IAIK/meltdown/ .
>
> Is anyone working on KPTI for x86-32? SLES11 should still be
> supported, and that should have x86-32 version; any chance SUSE can
> share some patches?
>
> Thanks,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Olivier Galibert]

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 vulnerable to spaces.  Go on, try to
disallow spaces in file names, I'll pass the popcorn.

  OG.

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

[Olivier Galibert]

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 vulnerable to spaces.  Go on, try to
disallow spaces in file names, I'll pass the popcorn.

  OG.

Re: [GIT PULL] kdbus for 4.1-rc1

[Olivier Galibert]

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 component.  If that component is not in the kernel, it has
> to be a userspace deamon, which in turn has all of the issues that
> dbus-daemon currently has.

You're not making sense there.  If there is no daemon, then you're
peer-to-peer, because there's no central component.  If you consider
the kernel the central component, then peer-to-peer is almost
impossible by definition.

It seems that almost everybody here thinks that the plumbing (e.g.
transmitting messages in-order with multicasting) should be separated
from the policy (who communicates with who), possibly leveraging the
packet filtering infrastructure to implement the decided policy.  What
it is you reject about that point of view, which seems relatively
normal when you think about building a collection of useful tools?

  OG.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] kdbus for 4.1-rc1

[Olivier Galibert]

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
 to a central component.  If that component is not in the kernel, it has
 to be a userspace deamon, which in turn has all of the issues that
 dbus-daemon currently has.

You're not making sense there.  If there is no daemon, then you're
peer-to-peer, because there's no central component.  If you consider
the kernel the central component, then peer-to-peer is almost
impossible by definition.

It seems that almost everybody here thinks that the plumbing (e.g.
transmitting messages in-order with multicasting) should be separated
from the policy (who communicates with who), possibly leveraging the
packet filtering infrastructure to implement the decided policy.  What
it is you reject about that point of view, which seems relatively
normal when you think about building a collection of useful tools?

  OG.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia32_sysenter_target does not preserve EFLAGS

[Olivier Galibert]

  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 Vlasenko  wrote:
>>>
>>> Apparently, users *don't* depend on arithmetic flags
>>> to survive over syscall. They also okay with DF flag
>>> being cleared.
>>
>> Generally, users probably dont' care about many registers at all being
>> saved, but it's worth noting that the reason system calls save/restore
>> even caller-saved registers is at least partly in order to avoid any
>> kernel information leaks.
>>
>> I don't believe that user mode will ever reasonably care about the
>> arithmetic flags being changed, but at the same time I also don't it
>> is something we should ever consider a "feature" we should try to take
>> advantage of. Generally we should try to not mess with the flag state,
>> and I'd *much* rather make the rule be that all the system call return
>> paths restore flags as much as possible.
>
> "We don't clobber anything" ABI has its appeal.
> OTOH, fulfilling ABI's promises has cost which hast to be paid
> on every syscall, regardless whether userspace needed it or not.
>
> Example. This is the uclibc implementation of write():
>
> 004acfc4 <__libc_write>:
>   4acfc4:   53  push   %rbx
>   4acfc5:   48 63 ffmovslq %edi,%rdi
>   4acfc8:   b8 01 00 00 00  mov$0x1,%eax
>   4acfcd:   0f 05   syscall
>   4acfcf:   48 89 c3mov%rax,%rbx
>   4acfd2:   48 81 fb 00 f0 ff ffcmp$0xf000,%rbx
>   4acfd9:   76 0f   jbe4acfea <__libc_write+0x26>
>   4acfdb:   e8 64 15 00 00  callq  4ae544 <__GI___errno_location>
>   4acfe0:   89 da   mov%ebx,%edx
>   4acfe2:   f7 da   neg%edx
>   4acfe4:   89 10   mov%edx,(%rax)
>   4acfe6:   48 83 c8 ff or $0x,%rax
>   4acfea:   5b  pop%rbx
>   4acfeb:   c3  retq
>
> This is a C function. Therefore any its caller assumes that C-clobbered
> registers can be, indeed, clobbered here, so if that caller uses any
> of them, it saves/restores them.
>
> All efforts by kernel code to save/restore C-clobbered registers,
> eight of them, are in vain. It's just useless work. Userspace
> does not benefit from that effort.
>
> If our syscall ABI would say that those regs are not preserved,
> we could have a bit faster syscalls. Any userspace code which
> really had to have those registers preserved across a particular
> syscall, could push/pop them itself.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia32_sysenter_target does not preserve EFLAGS

[Olivier Galibert]

  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 wrote:
 On Fri, Mar 27, 2015 at 7:25 AM, Denys Vlasenko dvlas...@redhat.com wrote:

 Apparently, users *don't* depend on arithmetic flags
 to survive over syscall. They also okay with DF flag
 being cleared.

 Generally, users probably dont' care about many registers at all being
 saved, but it's worth noting that the reason system calls save/restore
 even caller-saved registers is at least partly in order to avoid any
 kernel information leaks.

 I don't believe that user mode will ever reasonably care about the
 arithmetic flags being changed, but at the same time I also don't it
 is something we should ever consider a feature we should try to take
 advantage of. Generally we should try to not mess with the flag state,
 and I'd *much* rather make the rule be that all the system call return
 paths restore flags as much as possible.

 We don't clobber anything ABI has its appeal.
 OTOH, fulfilling ABI's promises has cost which hast to be paid
 on every syscall, regardless whether userspace needed it or not.

 Example. This is the uclibc implementation of write():

 004acfc4 __libc_write:
   4acfc4:   53  push   %rbx
   4acfc5:   48 63 ffmovslq %edi,%rdi
   4acfc8:   b8 01 00 00 00  mov$0x1,%eax
   4acfcd:   0f 05   syscall
   4acfcf:   48 89 c3mov%rax,%rbx
   4acfd2:   48 81 fb 00 f0 ff ffcmp$0xf000,%rbx
   4acfd9:   76 0f   jbe4acfea __libc_write+0x26
   4acfdb:   e8 64 15 00 00  callq  4ae544 __GI___errno_location
   4acfe0:   89 da   mov%ebx,%edx
   4acfe2:   f7 da   neg%edx
   4acfe4:   89 10   mov%edx,(%rax)
   4acfe6:   48 83 c8 ff or $0x,%rax
   4acfea:   5b  pop%rbx
   4acfeb:   c3  retq

 This is a C function. Therefore any its caller assumes that C-clobbered
 registers can be, indeed, clobbered here, so if that caller uses any
 of them, it saves/restores them.

 All efforts by kernel code to save/restore C-clobbered registers,
 eight of them, are in vain. It's just useless work. Userspace
 does not benefit from that effort.

 If our syscall ABI would say that those regs are not preserved,
 we could have a bit faster syscalls. Any userspace code which
 really had to have those registers preserved across a particular
 syscall, could push/pop them itself.
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 people who
>> want to continue acting "unprofessionally" should document what
>> behaviors set off their cursing streaks, so that others can avoid that
>> behavior.  Somewhere in the middle is the community behavior all
>> developers can thrive in.
>
>
> By defining your viewpoint as being "professional" and the other viewpoint
> as being "unprofessional" you have already started using very loaded terms
> and greatly reduces the probability of actually getting the other group to
> agree and participate.

Especially since you can very easily translate these terms into
"American" and "non-American".

The stereotypical american professionalism attitude is to be polite at
the word choice level the best to hide a profund disrespect under
them.  There's no meaning taken into account, it's just keyword
spotting.  "Your code is crap" is considered unprofessional, while
"Let's leverage my fifth grade nephew's capabilities to assist you in
fixing the code" is perfectly professional, somehow.  That's more
often than not an unacceptable attitude in europe.

  OG.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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.  The people who
 want to continue acting unprofessionally should document what
 behaviors set off their cursing streaks, so that others can avoid that
 behavior.  Somewhere in the middle is the community behavior all
 developers can thrive in.


 By defining your viewpoint as being professional and the other viewpoint
 as being unprofessional you have already started using very loaded terms
 and greatly reduces the probability of actually getting the other group to
 agree and participate.

Especially since you can very easily translate these terms into
American and non-American.

The stereotypical american professionalism attitude is to be polite at
the word choice level the best to hide a profund disrespect under
them.  There's no meaning taken into account, it's just keyword
spotting.  Your code is crap is considered unprofessional, while
Let's leverage my fifth grade nephew's capabilities to assist you in
fixing the code is perfectly professional, somehow.  That's more
often than not an unacceptable attitude in europe.

  OG.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Simplifying kernel configuration for distro issues

[Olivier Galibert]

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 the KConfig options down to 10% of 
> what they are now if we just made a few (hard) choices about some things 
> that would always be there that everyone could count on.  If people want 
> to deviate from the default minimum, sure, let them, but put it under 
> *custom*, *embedded*, *specialized distro*, *you know what you are doing* 
> menu options.

In number of options the "infrastructure" options are at most 20% of
the total.  The other 80% are individual drivers, hardware (like
network cards, serial devices, usb devices, video...) or software
(crypto algorithms, partition formats, codepages, filesystems...).
You're going to have a hard time slashing 90% of that.

  OG.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Simplifying kernel configuration for distro issues

[Olivier Galibert]

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 the KConfig options down to 10% of 
 what they are now if we just made a few (hard) choices about some things 
 that would always be there that everyone could count on.  If people want 
 to deviate from the default minimum, sure, let them, but put it under 
 *custom*, *embedded*, *specialized distro*, *you know what you are doing* 
 menu options.

In number of options the infrastructure options are at most 20% of
the total.  The other 80% are individual drivers, hardware (like
network cards, serial devices, usb devices, video...) or software
(crypto algorithms, partition formats, codepages, filesystems...).
You're going to have a hard time slashing 90% of that.

  OG.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Integration of SCST in the mainstream Linux kernel

[Olivier Galibert]

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.  At that point you might 
> as well run NFS or [gfs|ocfs|flavor-of-the-week], and ditch your 
> networked block device (and associated complexity).

Call me a sysadmin, but I find easier to plug in and keep in place an
ethernet cable than these parallel scsi cables from hell.  Every
server has at least two ethernet ports by default, with rarely any
surprises at the kernel level.  Adding ethernet cards is inexpensive,
and you pretty much never hear of compatibility problems between
cards.

So ethernet as a connection medium is really nice compared to scsi.
Too bad iscsi is demented and ATAoE/NBD inexistant.  Maybe external
SAS will be nice, but I don't see it getting to the level of
universality of ethernet any time soon.  And it won't get the same
amount of user-level compatibility testing in any case.

  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 FAQ at  http://www.tux.org/lkml/

Re: Integration of SCST in the mainstream Linux kernel

[Olivier Galibert]

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.  At that point you might 
 as well run NFS or [gfs|ocfs|flavor-of-the-week], and ditch your 
 networked block device (and associated complexity).

Call me a sysadmin, but I find easier to plug in and keep in place an
ethernet cable than these parallel scsi cables from hell.  Every
server has at least two ethernet ports by default, with rarely any
surprises at the kernel level.  Adding ethernet cards is inexpensive,
and you pretty much never hear of compatibility problems between
cards.

So ethernet as a connection medium is really nice compared to scsi.
Too bad iscsi is demented and ATAoE/NBD inexistant.  Maybe external
SAS will be nice, but I don't see it getting to the level of
universality of ethernet any time soon.  And it won't get the same
amount of user-level compatibility testing in any case.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 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/

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

[Olivier Galibert]

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 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/

Re: Why is the kfree() argument const?

[Olivier Galibert]

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
on the deallocator, you can get bugs indeed.  GIGO.


> Yes. Bad things start to happen when users add wrong indications to
> the compiler. By adding the "const" indication to kfree(), the programmer
> wrongly tells that it can optimize reading the values pointed to before or
> after calling the function (if it is also sure that they cannot be
> read/written otherwise). Current gcc implementations seem quite
> conservative in this regard, and don't optimize that much, but what about
> the future?

The future should be quite nice because:

- the compiler can not know that kmalloc does not have an alias to
  the pointer tucked somewhere accessible by other non-inline functions
  (as kfree is), especially since it does have aliases in practice, so
  it cannot prove to "not read/written otherwise" part without the
  malloc attribute

- if you add the (non-standard C) malloc attribute to kmalloc, then
  you also add the free attribute to kfree which tells the compiler
  that the pointer is invalid after the call, which ensures no
  accesses will be moved after it

  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 FAQ at  http://www.tux.org/lkml/

Re: Why is the kfree() argument const?

[Olivier Galibert]

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 pointer to not to modify the object. Since this is an unusual
> operation that could be an error, it is logical to force the person doing it
> to clearly indicate that he knows the pointer is const and that he knows it
> is right anyway.

Freeing a const pointer is not and has never been unusual.  It happens
all the time for objects whose lifecycle is "initialise at the start,
readonly afterwards", of which names, in particular in the form of
strings, are a large subset.  It also happens in cases of late
deletion on refcounted objects, when the main owner (the one who is
allowed to change the object and has the non-const pointer) has
dropped its reference, but some object needs a readonly instance a
little longer.  Think virtual files in proc, sysfs or friends kept
open after the underlying information source, often a device, is gone.

  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 FAQ at  http://www.tux.org/lkml/

Re: Why is the kfree() argument const?

[Olivier Galibert]

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 function has side effects noticeable by the
other.  Invalidating the pointer in (k)free is rather noticeable.


> (Note that this isn't just a problem for optimizers -- a programmer 
> might expect that passing a pointer to a function that takes a const 
> pointer argument does not, in and of itself, change the pointed-to 
> value.  Given that const certainly does not mean that no one else 
> changes the object, I'm not sure what else it could mean.

Most of the time, const pointer arguments means "I won't change the
contents of the object so that you'll notice by reading it in a normal
way afterwards".  That's pretty much what mutable in a variety of
languages (including C++) is about, saying "this field is internal
management stuff not visible from the external interface, so I need to
be able to change it even through const pointers I got as parameters".
Reference counters for copy-on-write setups is the usual example of
use.

In the case of deallocation functions you are not allowed to do
anything through the pointer or its aliases after the function
returns.  So we're outside of the "most of the time" case, since
you're not allowed to try to notice any change.  Pragmatism takes
over, you want the type that catches as many possible types as
possible while staying reasonable (volatile is never reasonable), and
that's const void *.  As simple as that.

As for releasing resources through const pointers, that happens all
the time as soon as your const use is tight, and if you think forcing
the systematic addition of a (void *) cast is going to make your code
more readable, well, you need more experience in maintaining other
people's applications.


> kfree does not have either property, so I'm don't think it makes
> sense for it to take a const argument.

delete in C++ allows const pointers. Think about it.

  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 FAQ at  http://www.tux.org/lkml/

Re: Why is the kfree() argument const?

[Olivier Galibert]

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
on the deallocator, you can get bugs indeed.  GIGO.


 Yes. Bad things start to happen when users add wrong indications to
 the compiler. By adding the const indication to kfree(), the programmer
 wrongly tells that it can optimize reading the values pointed to before or
 after calling the function (if it is also sure that they cannot be
 read/written otherwise). Current gcc implementations seem quite
 conservative in this regard, and don't optimize that much, but what about
 the future?

The future should be quite nice because:

- the compiler can not know that kmalloc does not have an alias to
  the pointer tucked somewhere accessible by other non-inline functions
  (as kfree is), especially since it does have aliases in practice, so
  it cannot prove to not read/written otherwise part without the
  malloc attribute

- if you add the (non-standard C) malloc attribute to kmalloc, then
  you also add the free attribute to kfree which tells the compiler
  that the pointer is invalid after the call, which ensures no
  accesses will be moved after it

  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 FAQ at  http://www.tux.org/lkml/

Re: Why is the kfree() argument const?

[Olivier Galibert]

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 function has side effects noticeable by the
other.  Invalidating the pointer in (k)free is rather noticeable.


 (Note that this isn't just a problem for optimizers -- a programmer 
 might expect that passing a pointer to a function that takes a const 
 pointer argument does not, in and of itself, change the pointed-to 
 value.  Given that const certainly does not mean that no one else 
 changes the object, I'm not sure what else it could mean.

Most of the time, const pointer arguments means I won't change the
contents of the object so that you'll notice by reading it in a normal
way afterwards.  That's pretty much what mutable in a variety of
languages (including C++) is about, saying this field is internal
management stuff not visible from the external interface, so I need to
be able to change it even through const pointers I got as parameters.
Reference counters for copy-on-write setups is the usual example of
use.

In the case of deallocation functions you are not allowed to do
anything through the pointer or its aliases after the function
returns.  So we're outside of the most of the time case, since
you're not allowed to try to notice any change.  Pragmatism takes
over, you want the type that catches as many possible types as
possible while staying reasonable (volatile is never reasonable), and
that's const void *.  As simple as that.

As for releasing resources through const pointers, that happens all
the time as soon as your const use is tight, and if you think forcing
the systematic addition of a (void *) cast is going to make your code
more readable, well, you need more experience in maintaining other
people's applications.


 kfree does not have either property, so I'm don't think it makes
 sense for it to take a const argument.

delete in C++ allows const pointers. Think about it.

  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 FAQ at  http://www.tux.org/lkml/

Re: Why is the kfree() argument const?

[Olivier Galibert]

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 pointer to not to modify the object. Since this is an unusual
 operation that could be an error, it is logical to force the person doing it
 to clearly indicate that he knows the pointer is const and that he knows it
 is right anyway.

Freeing a const pointer is not and has never been unusual.  It happens
all the time for objects whose lifecycle is initialise at the start,
readonly afterwards, of which names, in particular in the form of
strings, are a large subset.  It also happens in cases of late
deletion on refcounted objects, when the main owner (the one who is
allowed to change the object and has the non-const pointer) has
dropped its reference, but some object needs a readonly instance a
little longer.  Think virtual files in proc, sysfs or friends kept
open after the underlying information source, often a device, is gone.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 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/

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

[Olivier Galibert]

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 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/

Re: INITIO scsi driver fails to work properly

[Olivier Galibert]

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 = cpu_to_le32((u32)sg_dma_address(sglist));
>   total_len += sg->len = 
> cpu_to_le32((u32)sg_dma_len(sglist));
> + ++sg;
>   }

  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 FAQ at  http://www.tux.org/lkml/

Re: INITIO scsi driver fails to work properly

[Olivier Galibert]

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 = cpu_to_le32((u32)sg_dma_address(sglist));
   total_len += sg-len = 
 cpu_to_le32((u32)sg_dma_len(sglist));
 + ++sg;
   }

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 rpmbuild is not
install and rpm is not building-capable not to fall back to rpm and
instead yell loudly that rpmbuild is missing.

To which some said that right now "do not fall back, ever, just
require rpmbuild" may just be the best.

I have no opinion though.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 rpmbuild is not
install and rpm is not building-capable not to fall back to rpm and
instead yell loudly that rpmbuild is missing.

To which some said that right now do not fall back, ever, just
require rpmbuild may just be the best.

I have no opinion though.

  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 FAQ at  http://www.tux.org/lkml/

Re: Why is FIBMAP ioctl root only?

[Olivier Galibert]

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 FAQ at  http://www.tux.org/lkml/

Re: Why is FIBMAP ioctl root only?

[Olivier Galibert]

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 check is removed?

Once upon a time some filesystems fucked up when incorrect values
(negative offsets in particular).  So the easy way out was taken and
FIBMAP was restricted, to the eternal annoyance of DVD players which
needed the sector number for CSS reasons.  Since then dvd players have
included an udf parser and life went on.

Well, psx movie players needed it too, but bah.

Essentially if you remove the restriction you have to audit all
filesystems to be sure that they're not going to be problematic.

  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 FAQ at  http://www.tux.org/lkml/

Re: Why is FIBMAP ioctl root only?

[Olivier Galibert]

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 FAQ at  http://www.tux.org/lkml/

Re: Why is FIBMAP ioctl root only?

[Olivier Galibert]

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 check is removed?

Once upon a time some filesystems fucked up when incorrect values
(negative offsets in particular).  So the easy way out was taken and
FIBMAP was restricted, to the eternal annoyance of DVD players which
needed the sector number for CSS reasons.  Since then dvd players have
included an udf parser and life went on.

Well, psx movie players needed it too, but bah.

Essentially if you remove the restriction you have to audit all
filesystems to be sure that they're not going to be problematic.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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.

Closing the lid also raises a "video bus notify".

How can I go about debugging that?

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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.

Closing the lid also raises a video bus notify.

How can I go about debugging that?

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 case now though, since my
experience of the subject was years ago.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 case now though, since my
experience of the subject was years ago.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 setting the physical value, for instance.

Ok.  I misunderstood the sg_virt/sg_phys difference I guess.  No
problem.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 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/

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

[Olivier Galibert]

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 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/

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

[Olivier Galibert]

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 setting the physical value, for instance.

Ok.  I misunderstood the sg_virt/sg_phys difference I guess.  No
problem.

  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 FAQ at  http://www.tux.org/lkml/

Re: Point of gpl-only modules (flame)

[Olivier Galibert]

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 wrong legally.

  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 FAQ at  http://www.tux.org/lkml/

Re: Point of gpl-only modules (flame)

[Olivier Galibert]

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 wrong legally.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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_ pathnames" is so 
> full of shit that it's not even funny. And a person who says that it has 
> to be one or the other is incompetent.

Not so much incompetent as religious fundamentalist.  Which is worse.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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_ pathnames is so 
 full of shit that it's not even funny. And a person who says that it has 
 to be one or the other is incompetent.

Not so much incompetent as religious fundamentalist.  Which is worse.

  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 FAQ at  http://www.tux.org/lkml/

Re: Chroot bug

[Olivier Galibert]

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("subtree");   // enter chroot
>chdir("/");// now at subtree
>chroot("/tmp");   // now outside of chroot

Of course.  chroots are not a stack, they're just a point in the
namespace.  You change it, the conditions apply to the new one.


> BSD redefined chroot so that the working directory is set to the new 
> root on subsequent uses of chroot; that's how they solved the bug.

They didn't solve a thing.  fchdir baby.  Unless you want to remove
fchdir.  And mknod.  And mount.  And so many other different syscalls
that I don't even know the list.

  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 FAQ at  http://www.tux.org/lkml/

Re: Chroot bug

[Olivier Galibert]

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 outside if you're *already* out.  That's the way it is
defined.  Those who want some kind of chroot for security reasons
should look at (BSD's ?) jail, and/or hypervisors.

  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 FAQ at  http://www.tux.org/lkml/

Re: Chroot bug

[Olivier Galibert]

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 outside if you're *already* out.  That's the way it is
defined.  Those who want some kind of chroot for security reasons
should look at (BSD's ?) jail, and/or hypervisors.

  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 FAQ at  http://www.tux.org/lkml/

Re: Chroot bug

[Olivier Galibert]

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(subtree);   // enter chroot
chdir(/);// now at subtree
chroot(/tmp);   // now outside of chroot

Of course.  chroots are not a stack, they're just a point in the
namespace.  You change it, the conditions apply to the new one.


 BSD redefined chroot so that the working directory is set to the new 
 root on subsequent uses of chroot; that's how they solved the bug.

They didn't solve a thing.  fchdir baby.  Unless you want to remove
fchdir.  And mknod.  And mount.  And so many other different syscalls
that I don't even know the list.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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
#  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
  { { 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, 0, { 0 } } }
#  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
  { { 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, 0, { 0 } } }
#  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
  { { 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, 0, { 0 } } }
# endif

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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
#  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
  { { 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, 0, { 0 } } }
#  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
  { { 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, 0, { 0 } } }
#  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
  { { 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, 0, { 0 } } }
# endif

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 worse.


> Yes, the library solution has merits and demerits.  The library should
> have been differently designed.  But, I don't think the virtual relay
> is the best solution just because you can use a bare kernel
> interface...

Whatever you do in the library won't solve the problem of properly
supporting the OSS interface.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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.
> >
> >Huh?  I have no problems with soft mixing...
> 
> Diverging from the discussion, how is soft mixing actually done? If it was 
> done
> in userspace, it would need shared memory, or a back relay from kernelspace to
> userspace (and back again for the final output), otherwise I could not imagine
> how all alsa streams came together at one point.

SysV shared memory and semaphores, done in the alsa lib.

Yes, your kernel sound access library does shared mem, semaphores,
fork+exec and friends.

Back relay and virtual devices is the way it should have been done.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 "remove ALSA".

Soft mixing is actually the biggest issue because if you had
generalized soft-mixing in the kernel-visible audio ports[1] you would
win two things:

- programs could use the OSS API without interfering with the ALSA one
  or which each other

- programs coult use the ALSA kernel API directly without interfering
  either, which would allow alternative libalsa implementations for
  those who hate the current one

Frankly, mandatory libraries are extremely annoying, and mandatory
extremely complex overdesigned libraries are simply unbearable.

  OG.

[1] Which does *not* mean doing the mixing in the kernel.
-
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/

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

[Olivier Galibert]

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.
 
 Huh?  I have no problems with soft mixing...
 
 Diverging from the discussion, how is soft mixing actually done? If it was 
 done
 in userspace, it would need shared memory, or a back relay from kernelspace to
 userspace (and back again for the final output), otherwise I could not imagine
 how all alsa streams came together at one point.

SysV shared memory and semaphores, done in the alsa lib.

Yes, your kernel sound access library does shared mem, semaphores,
fork+exec and friends.

Back relay and virtual devices is the way it should have been done.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 remove ALSA.

Soft mixing is actually the biggest issue because if you had
generalized soft-mixing in the kernel-visible audio ports[1] you would
win two things:

- programs could use the OSS API without interfering with the ALSA one
  or which each other

- programs coult use the ALSA kernel API directly without interfering
  either, which would allow alternative libalsa implementations for
  those who hate the current one

Frankly, mandatory libraries are extremely annoying, and mandatory
extremely complex overdesigned libraries are simply unbearable.

  OG.

[1] Which does *not* mean doing the mixing in the kernel.
-
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/

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

[Olivier Galibert]

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 worse.


 Yes, the library solution has merits and demerits.  The library should
 have been differently designed.  But, I don't think the virtual relay
 is the best solution just because you can use a bare kernel
 interface...

Whatever you do in the library won't solve the problem of properly
supporting the OSS interface.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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

You mean the undocumented, 100% ioctl one?  With one ioctl to write
interleaved sound, one for non-interleaved sound, in addition to
setting interleaved or not in the configuration?  I should check one
day which one wins.

Or the "library"?  Don't get me started on this one.


I take your word about the fact that the kernel side is better.  The
userland side, not so much.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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

You mean the undocumented, 100% ioctl one?  With one ioctl to write
interleaved sound, one for non-interleaved sound, in addition to
setting interleaved or not in the configuration?  I should check one
day which one wins.

Or the library?  Don't get me started on this one.


I take your word about the fact that the kernel side is better.  The
userland side, not so much.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 
> numerous special cases?

Ahhh, but so much more entreprisy.  I never had realized before that
the DailyWTF applied to licenses too.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 
 numerous special cases?

Ahhh, but so much more entreprisy.  I never had realized before that
the DailyWTF applied to licenses too.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 it shouldn't have.

Just for the record, I still fundamentally disagree with that part.
You're not catching what you think you're catching, since the chipset
tells you what it is going to decode as mmconfig, no matter what is
connected to it.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 it shouldn't have.

Just for the record, I still fundamentally disagree with that part.
You're not catching what you think you're catching, since the chipset
tells you what it is going to decode as mmconfig, no matter what is
connected to it.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 and extended config space, but we can continue to use type 1 
> accesses for legacy PCI config space cycles to avoid decode trouble 
> with mmconfig based BAR sizing.

Isn't that a mac-intel instant killer?  AFAIK they don't have type1,
period.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 and extended config space, but we can continue to use type 1 
 accesses for legacy PCI config space cycles to avoid decode trouble 
 with mmconfig based BAR sizing.

Isn't that a mac-intel instant killer?  AFAIK they don't have type1,
period.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 for the window register are defined
> > invalid in the documentation.
> 
> Added thanks

Oh, feel free to add the:
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>

I forgot in the original mail.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 for the window register are defined
  invalid in the documentation.
 
 Added thanks

Oh, feel free to add the:
Signed-off-by: Olivier Galibert [EMAIL PROTECTED]

I forgot in the original mail.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 these
days?


 arch/i386/pci/mmconfig-shared.c |   25 +
 1 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c
index 747d8c6..c7cabee 100644
--- a/arch/i386/pci/mmconfig-shared.c
+++ b/arch/i386/pci/mmconfig-shared.c
@@ -60,14 +60,19 @@ static const char __init *pci_mmcfg_e7520(void)
u32 win;
pci_conf1_read(0, 0, PCI_DEVFN(0,0), 0xce, 2, );
 
-   pci_mmcfg_config_num = 1;
-   pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), GFP_KERNEL);
-   if (!pci_mmcfg_config)
-   return NULL;
-   pci_mmcfg_config[0].address = (win & 0xf000) << 16;
-   pci_mmcfg_config[0].pci_segment = 0;
-   pci_mmcfg_config[0].start_bus_number = 0;
-   pci_mmcfg_config[0].end_bus_number = 255;
+   win = win & 0xf000;
+   if(win == 0x || win == 0xf000)
+   pci_mmcfg_config_num = 0;
+   else {
+   pci_mmcfg_config_num = 1;
+   pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), 
GFP_KERNEL);
+   if (!pci_mmcfg_config)
+   return NULL;
+   pci_mmcfg_config[0].address = win << 16;
+   pci_mmcfg_config[0].pci_segment = 0;
+   pci_mmcfg_config[0].start_bus_number = 0;
+   pci_mmcfg_config[0].end_bus_number = 255;
+   }
 
return "Intel Corporation E7520 Memory Controller Hub";
 }
@@ -108,6 +113,10 @@ static const char __init *pci_mmcfg_intel_945(void)
if ((pciexbar & mask) & 0x0fffU)
pci_mmcfg_config_num = 0;
 
+   /* Don't hit the APIC registers and their friends */
+   if ((pciexbar & mask) >= 0xf000U)
+   pci_mmcfg_config_num = 0;
+
if (pci_mmcfg_config_num) {
pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), 
GFP_KERNEL);
if (!pci_mmcfg_config)
-- 
1.5.1.81.gee969

-
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/

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

[Olivier Galibert]

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 these
days?


 arch/i386/pci/mmconfig-shared.c |   25 +
 1 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c
index 747d8c6..c7cabee 100644
--- a/arch/i386/pci/mmconfig-shared.c
+++ b/arch/i386/pci/mmconfig-shared.c
@@ -60,14 +60,19 @@ static const char __init *pci_mmcfg_e7520(void)
u32 win;
pci_conf1_read(0, 0, PCI_DEVFN(0,0), 0xce, 2, win);
 
-   pci_mmcfg_config_num = 1;
-   pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), GFP_KERNEL);
-   if (!pci_mmcfg_config)
-   return NULL;
-   pci_mmcfg_config[0].address = (win  0xf000)  16;
-   pci_mmcfg_config[0].pci_segment = 0;
-   pci_mmcfg_config[0].start_bus_number = 0;
-   pci_mmcfg_config[0].end_bus_number = 255;
+   win = win  0xf000;
+   if(win == 0x || win == 0xf000)
+   pci_mmcfg_config_num = 0;
+   else {
+   pci_mmcfg_config_num = 1;
+   pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), 
GFP_KERNEL);
+   if (!pci_mmcfg_config)
+   return NULL;
+   pci_mmcfg_config[0].address = win  16;
+   pci_mmcfg_config[0].pci_segment = 0;
+   pci_mmcfg_config[0].start_bus_number = 0;
+   pci_mmcfg_config[0].end_bus_number = 255;
+   }
 
return Intel Corporation E7520 Memory Controller Hub;
 }
@@ -108,6 +113,10 @@ static const char __init *pci_mmcfg_intel_945(void)
if ((pciexbar  mask)  0x0fffU)
pci_mmcfg_config_num = 0;
 
+   /* Don't hit the APIC registers and their friends */
+   if ((pciexbar  mask) = 0xf000U)
+   pci_mmcfg_config_num = 0;
+
if (pci_mmcfg_config_num) {
pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), 
GFP_KERNEL);
if (!pci_mmcfg_config)
-- 
1.5.1.81.gee969

-
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/

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

[Olivier Galibert]

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 it shouldn't have.  This might be
> overly pessimistic - we might be able to instead verify that no
> other reserved resources (like chipset registers) are inside this
> memory range.

I have a fundamental problem with that: you don't validate a higher
reliability information against a lower one.  The chipset registers
are high reliability.  Modulo unknown hardware erratas and bugs in the
code (and accepting f000 is in practice a bug in the code, the
docs are starting to catch up with it too), the chipset *will* decode
mmconfig at the looked up address no matter what.  On the other side,
the ACPI data is bios generated, and that is well known to be horribly
unreliable.  Hell, if it was reliable we could just use the MFCG ACPI
table without questions.

So you can check the ACPI stuff for coherency (MFCG vs. the rest), you
can validate the ACPI stuff against the results of the lookup if you
want, but validating the lookup against ACPI is nonsensical.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 it shouldn't have.  This might be
 overly pessimistic - we might be able to instead verify that no
 other reserved resources (like chipset registers) are inside this
 memory range.

I have a fundamental problem with that: you don't validate a higher
reliability information against a lower one.  The chipset registers
are high reliability.  Modulo unknown hardware erratas and bugs in the
code (and accepting f000 is in practice a bug in the code, the
docs are starting to catch up with it too), the chipset *will* decode
mmconfig at the looked up address no matter what.  On the other side,
the ACPI data is bios generated, and that is well known to be horribly
unreliable.  Hell, if it was reliable we could just use the MFCG ACPI
table without questions.

So you can check the ACPI stuff for coherency (MFCG vs. the rest), you
can validate the ACPI stuff against the results of the lookup if you
want, but validating the lookup against ACPI is nonsensical.

  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 FAQ at  http://www.tux.org/lkml/

Re: Back to the future.

[Olivier Galibert]

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 aren't limited anymore, I have a number of machines with 20G swap
for experiments.

  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 FAQ at  http://www.tux.org/lkml/

Re: Back to the future.

[Olivier Galibert]

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 approach I've been mulling about for a while:

Suspend-to-disk is pretty much an exercise in state saving.  There are
multiple ways to do state saving, but they tend to end up in two
categories: implicit and explicit.

In implicit state saving, you try to save the state of the
system/application/whatever "under its feet", more or less, and then
fixup what is no saved/saveable correctly.  A well-known example is
the undumping process Emacs goes (went?) where it tries to dump the
state of the memory as a new executable, with a lot of pleasure with
various executable formats and subtleties due to side effects in libc
code you don't control.

In explicit state saving each object saves what is needed from its
state to an independently defined format (instead of "whatever the
memory organization happens to be at that point").  When reloading the
state you have to parse it, and it usually requires
rebuilding/relocating all references/pointers/etc.  XEmacs currently
has a "portable dumper" that pretty much does just that.  We don't
have any redumping problems anymore, they're over.

Which one is the best depends heavily on the application.  The amount
of code in the implicit case depends on the amount of fixups to do.
In the kernel case it happens to be a lot, pretty much everything that
touches hardware has to save to memory the device state and reload it
on resume.  And bugs on hardware handling can be quite annoying to
debug.  And if some driver does not to saving/resume correctly, you
have no way outside of playing with modules to ensure the safety of
the suspend cycle.

The amount of code in the explicit case is an interesting variable in
the case of the kernel.  You have to save what is needed, but how do
you define what is needed?  It is, pretty much, what running processes
can observe from userspace.  Now, what can a process observe:
- its application text and anonymous memory pages
- its file handles
- its mapped files
- its mapped whatever else
- its sys5 IPC stuff
- futex stuff and friends, namespaces, etc
- its intrinsic characteristics it can reach through syscalls
  (i.e. the user-visible parts of current, like pid, uid...)
- its currently running system call, if any

So that's what we'd have to explicitely save.  Anonymous memory, sys5
IPC, futex and current structures, that's easy stuff in practice.  The
fun part are pretty much:
- references to files
- references to active networking links
- references to devices and associated visible state
- currently running system call, aka the kernel stack for the process

The last one is the one I'm the most afraid of.  I hope that the
signal stuff and/or the asynchronous syscall stuff that was discussed
recently would allow to "unwind" blocking system calls back to the
syscall level and then store the parameters for resume-time restart.
The non-blocking calls you can just let finish.

The first one is really interesting.  If you value your filesystems,
you'd rather have them clean after the suspend.  And also you pretty
much know that filesystems can move around when you're not looking, be
it USB hotplug stuff (discovery order is random-ish isn't it?), module
loading order issues or multithreaded device discovery.  So you're way
more happy *not* caching anything from the filesystem you can avoid.

But what is a file reference, really?  With the dcache handy, it's
pretty much a path, since inodes don't always exist reliably.  And if
you have the lists of paths used by the processes on a particular
filesystem, you can easily get an idea of where, if anywhere, the
filesystem is even if you don't have reliable serials.  More
interestingly, you cannot, in any case, instantly corrupt your
filesystem by having a mismatch between the in-memory cache and the
reality.

The processes which referenced files you can't find anywhere will
end-up with EBADF or segfault depending on whether it was fd or mmap,
ala revoke().  They'll probably die horribly.  I'd rather have
processes die than filesystems die, since in any case if the file
isn't here anymore in practice the process could only destroy things.

An interesting things there, nothing in that touches either the
filesystem or the block devices.  Everything is done at the VFS level.
The devices don't need to care.  And the "this filesystem goes there"
can be done in userspace in an initramfs if people want to experiment
with kinky strategies.  After all, why not allow a sysadmin to regroup
two filesystems into one though a suspend, the processes mostly don't
need to care (well, tar may, but heh).  Deleted files would have to be
sillyrenamed or something.  Implementation details ;-)

Active networking links, you can 

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

[Olivier Galibert]

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 "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/

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

[Olivier Galibert]

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 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/

Re: Back to the future.

[Olivier Galibert]

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 approach I've been mulling about for a while:

Suspend-to-disk is pretty much an exercise in state saving.  There are
multiple ways to do state saving, but they tend to end up in two
categories: implicit and explicit.

In implicit state saving, you try to save the state of the
system/application/whatever under its feet, more or less, and then
fixup what is no saved/saveable correctly.  A well-known example is
the undumping process Emacs goes (went?) where it tries to dump the
state of the memory as a new executable, with a lot of pleasure with
various executable formats and subtleties due to side effects in libc
code you don't control.

In explicit state saving each object saves what is needed from its
state to an independently defined format (instead of whatever the
memory organization happens to be at that point).  When reloading the
state you have to parse it, and it usually requires
rebuilding/relocating all references/pointers/etc.  XEmacs currently
has a portable dumper that pretty much does just that.  We don't
have any redumping problems anymore, they're over.

Which one is the best depends heavily on the application.  The amount
of code in the implicit case depends on the amount of fixups to do.
In the kernel case it happens to be a lot, pretty much everything that
touches hardware has to save to memory the device state and reload it
on resume.  And bugs on hardware handling can be quite annoying to
debug.  And if some driver does not to saving/resume correctly, you
have no way outside of playing with modules to ensure the safety of
the suspend cycle.

The amount of code in the explicit case is an interesting variable in
the case of the kernel.  You have to save what is needed, but how do
you define what is needed?  It is, pretty much, what running processes
can observe from userspace.  Now, what can a process observe:
- its application text and anonymous memory pages
- its file handles
- its mapped files
- its mapped whatever else
- its sys5 IPC stuff
- futex stuff and friends, namespaces, etc
- its intrinsic characteristics it can reach through syscalls
  (i.e. the user-visible parts of current, like pid, uid...)
- its currently running system call, if any

So that's what we'd have to explicitely save.  Anonymous memory, sys5
IPC, futex and current structures, that's easy stuff in practice.  The
fun part are pretty much:
- references to files
- references to active networking links
- references to devices and associated visible state
- currently running system call, aka the kernel stack for the process

The last one is the one I'm the most afraid of.  I hope that the
signal stuff and/or the asynchronous syscall stuff that was discussed
recently would allow to unwind blocking system calls back to the
syscall level and then store the parameters for resume-time restart.
The non-blocking calls you can just let finish.

The first one is really interesting.  If you value your filesystems,
you'd rather have them clean after the suspend.  And also you pretty
much know that filesystems can move around when you're not looking, be
it USB hotplug stuff (discovery order is random-ish isn't it?), module
loading order issues or multithreaded device discovery.  So you're way
more happy *not* caching anything from the filesystem you can avoid.

But what is a file reference, really?  With the dcache handy, it's
pretty much a path, since inodes don't always exist reliably.  And if
you have the lists of paths used by the processes on a particular
filesystem, you can easily get an idea of where, if anywhere, the
filesystem is even if you don't have reliable serials.  More
interestingly, you cannot, in any case, instantly corrupt your
filesystem by having a mismatch between the in-memory cache and the
reality.

The processes which referenced files you can't find anywhere will
end-up with EBADF or segfault depending on whether it was fd or mmap,
ala revoke().  They'll probably die horribly.  I'd rather have
processes die than filesystems die, since in any case if the file
isn't here anymore in practice the process could only destroy things.

An interesting things there, nothing in that touches either the
filesystem or the block devices.  Everything is done at the VFS level.
The devices don't need to care.  And the this filesystem goes there
can be done in userspace in an initramfs if people want to experiment
with kinky strategies.  After all, why not allow a sysadmin to regroup
two filesystems into one though a suspend, the processes mostly don't
need to care (well, tar may, but heh).  Deleted files would have to be
sillyrenamed or something.  Implementation details ;-)

Active networking links, you can consider them dead 

Re: Back to the future.

[Olivier Galibert]

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 aren't limited anymore, I have a number of machines with 20G swap
for experiments.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 type "STD" and press "I'm feeling lucky". Google is God).

If it was correctly designed, it would be possible to change the
hardware or even the kernel through a STD cycle.  And that would be
damn interesting on servers.

In any case, if I could trust it, I'd use it when I need to move
servers around and I don't want to lose what is running.  Riding power
cuts that way would be nice.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 {
> > ATA_DFLAG_CDB_INTR  = (1 << 2), /* device asserts INTRQ when ready 
> > for CDB */
> > ATA_DFLAG_NCQ   = (1 << 3), /* device supports NCQ */
> > ATA_DFLAG_FLUSH_EXT = (1 << 4), /* do FLUSH_EXT instead of FLUSH */
> > +   ATA_DFLAG_AN= (1 << 5), /* device supports Async 
> > notification */
> > ATA_DFLAG_CFG_MASK  = (1 << 8) - 1,
> 
> Why don't the macros use the enums? It makes the code hard to read without
> painful cross-reference doesn't it? Surely (id)[76] & (ATA_DFLAG_AN) is a
> lot more readable than 1 << 5 - even if the flag is obviously that, a lot
> of values and registers can have 1 << 5 as a flag and mean a lot of different
> things.

The two being 32 is just a coincidence.  One is a hardware register
bit, the other the signification of the bits of ata_device->flags.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 {
  ATA_DFLAG_CDB_INTR  = (1  2), /* device asserts INTRQ when ready 
  for CDB */
  ATA_DFLAG_NCQ   = (1  3), /* device supports NCQ */
  ATA_DFLAG_FLUSH_EXT = (1  4), /* do FLUSH_EXT instead of FLUSH */
  +   ATA_DFLAG_AN= (1  5), /* device supports Async 
  notification */
  ATA_DFLAG_CFG_MASK  = (1  8) - 1,
 
 Why don't the macros use the enums? It makes the code hard to read without
 painful cross-reference doesn't it? Surely (id)[76]  (ATA_DFLAG_AN) is a
 lot more readable than 1  5 - even if the flag is obviously that, a lot
 of values and registers can have 1  5 as a flag and mean a lot of different
 things.

The two being 32 is just a coincidence.  One is a hardware register
bit, the other the signification of the bits of ata_device-flags.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 type STD and press I'm feeling lucky. Google is God).

If it was correctly designed, it would be possible to change the
hardware or even the kernel through a STD cycle.  And that would be
damn interesting on servers.

In any case, if I could trust it, I'd use it when I need to move
servers around and I don't want to lose what is running.  Riding power
cuts that way would be nice.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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
the one that currently is in the kernel, after all the people who said
"doing it in userland is not necessarily a good idea" got happily
ignored.  Suspend2 which is the continuity of the fully-in-kernel one
is the one that has been constantly rejected by Pavel, lately by
saying "it should be done in userspace", and hence never merged.

Incidentally, it's 13 ioctls, and it's documented in
Documentation/power/userland-swsusp.txt in a hard drive near you.  I
especially like the "get the available swap space in bytes" one that
can only handle 32 bits.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 print a warning and continue
>  
> Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
> 
> @@ -299,6 +305,8 @@ struct ata_taskfile {
>  #define ata_id_queue_depth(id)   (((id)[75] & 0x1f) + 1)
>  #define ata_id_removeable(id)((id)[0] & (1 << 7))
>  #define ata_id_has_dword_io(id)  ((id)[50] & (1 << 0))
> +#define ata_id_has_AN(id)\
> + (((id[76] != 0x) && (id[76] != 0x)) && ((id)[78] & (1 << 5)))

(id)[76] I guess ?  Sorry for being a pain :/

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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])) & ((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)).
> > 
> > I'm not even sure what it is you want.  If for the first part you
> > wanted (id[76] != 0x00 && id[76] != 0xff), please write just that,
> > thanks :-)
> > 
> >   OG.
> > 
> 
> >From the serial ata spec, we have:
> 
> 13.2.1.18Word 78: Serial ATA features supported
> If Word 76 is not h or h, Word 78 reports the optional features 
> supported by the device.  Support for this word is optional and if not 
> supported the word shall be zero indicating the device has no support for new 
> Serial ATA capabilities.
> 
> so, basically yes, I'm really testing to make sure that word 76 isn't 0 or all
> one then using that value & with value of bit in work 78 to determine AN
> support - if you think this is really obfuscated, I've got no problem 
> changing 
> it - there's obviously many ways to mess around with bits.

& is not &&, so right now it's really incorrect.  1 & 32 is 0.

((id)[76] != 0x && (id)[76] != 0x && ((id)[78] & (1 << 5)))

The implicit typing of id looks dangerous to me, but you're not the
one who has started it.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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)).

I'm not even sure what it is you want.  If for the first part you
wanted (id[76] != 0x00 && id[76] != 0xff), please write just that,
thanks :-)

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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)).

I'm not even sure what it is you want.  If for the first part you
wanted (id[76] != 0x00  id[76] != 0xff), please write just that,
thanks :-)

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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]))  ((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)).
  
  I'm not even sure what it is you want.  If for the first part you
  wanted (id[76] != 0x00  id[76] != 0xff), please write just that,
  thanks :-)
  
OG.
  
 
 From the serial ata spec, we have:
 
 13.2.1.18Word 78: Serial ATA features supported
 If Word 76 is not h or h, Word 78 reports the optional features 
 supported by the device.  Support for this word is optional and if not 
 supported the word shall be zero indicating the device has no support for new 
 Serial ATA capabilities.
 
 so, basically yes, I'm really testing to make sure that word 76 isn't 0 or all
 one then using that value  with value of bit in work 78 to determine AN
 support - if you think this is really obfuscated, I've got no problem 
 changing 
 it - there's obviously many ways to mess around with bits.

 is not , so right now it's really incorrect.  1  32 is 0.

((id)[76] != 0x  (id)[76] != 0x  ((id)[78]  (1  5)))

The implicit typing of id looks dangerous to me, but you're not the
one who has started it.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 print a warning and continue
  
 Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
 
 @@ -299,6 +305,8 @@ struct ata_taskfile {
  #define ata_id_queue_depth(id)   (((id)[75]  0x1f) + 1)
  #define ata_id_removeable(id)((id)[0]  (1  7))
  #define ata_id_has_dword_io(id)  ((id)[50]  (1  0))
 +#define ata_id_has_AN(id)\
 + (((id[76] != 0x)  (id[76] != 0x))  ((id)[78]  (1  5)))

(id)[76] I guess ?  Sorry for being a pain :/

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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
the one that currently is in the kernel, after all the people who said
doing it in userland is not necessarily a good idea got happily
ignored.  Suspend2 which is the continuity of the fully-in-kernel one
is the one that has been constantly rejected by Pavel, lately by
saying it should be done in userspace, and hence never merged.

Incidentally, it's 13 ioctls, and it's documented in
Documentation/power/userland-swsusp.txt in a hard drive near you.  I
especially like the get the available swap space in bytes one that
can only handle 32 bits.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 ports and 8250 ports suddenly becomes realistic.

Ok, so that I understand correctly, your problem is with the
tty_register_driver interface as used in
serial_core:uart_register_driver, correct?

Looking at the function, I understand why.
{alloc,register}_chrdev_region is very, very not designed to be
fully dynamic it seems.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 ports and 8250 ports suddenly becomes realistic.

Ok, so that I understand correctly, your problem is with the
tty_register_driver interface as used in
serial_core:uart_register_driver, correct?

Looking at the function, I understand why.
{alloc,register}_chrdev_region is very, very not designed to be
fully dynamic it seems.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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
> compatibility.

libata's hd->s* does that too, with probably a much larger impact.
Could udev be useful for once and make back compatibility symlinks?
Unifying serial the same way disks, cdroms, network, etc got unified
has some charm.

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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
 compatibility.

libata's hd-s* does that too, with probably a much larger impact.
Could udev be useful for once and make back compatibility symlinks?
Unifying serial the same way disks, cdroms, network, etc got unified
has some charm.

  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 FAQ at  http://www.tux.org/lkml/

Re: max_loop limit

[Olivier Galibert]

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 else?

  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 FAQ at  http://www.tux.org/lkml/

Re: max_loop limit

[Olivier Galibert]

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 else?

  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 FAQ at  http://www.tux.org/lkml/

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

[Olivier Galibert]

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 didnt actually attempt to cancel that IO? [but unfortunately 
> failed at doing so, because the platters were being written already.]
> 
> really, what's the point behind aio_cancel()?

Lemme give you a real-world scenario: Question Answering in a Dialog
System.  Your locked-in-memory index ranks documents in a several
million files corpus depending of the chances they have to have what
you're looking for.  You have a tenth of a second to read as many of
them as you can, and each seek is 5ms.  So you aio-read them,
requesting them in order of ranking up to 200 or so, and see what you
have at the 0.1s deadline.  If you're lucky, a combination of cache
(especially if you stat() the whole dir tree on a regular basis to
keep the metadata fresh in cache) and of good io reorganisation by the
scheduler will allow you to get a good number of them and do the
information extraction, scoring and clustering of answers, which is
pure CPU at that point.  You *have* to cancel the remaining i/o
because you do not want the disk saturated when the next request
comes, especially if it's 10ms later because the dialog manager found
out it needed a complementary request.

Incidentally, that's something I'm currently implementing for work,
making these aio discussions more interesting that usual :-)

  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 FAQ at  http://www.tux.org/lkml/

Re: somebody dropped a (warning) bomb

[Olivier Galibert]

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 another -Wxxx option to GCC to silence this particular
> case?

Silence would be good.  "char *" has a special status in C, it can be:
- pointer to a char/to an array of chars (standard interpretation)
- pointer to a string
- generic pointer to memory you can read(/write)

Check the aliasing rules if you don't believe be on the third one.
And it's *way* more often cases 2 and 3 than 1 for the simple reason
that the signedness of char is unpredictable.  As a result, a
signedness warning between char * and (un)signed char * is 99.99% of
the time stupid.


> May I suggest another definition for a warning being entirely sucks?
> "The warning is entirely sucks if and only if it never has true
> positives." In all other cases it's only more or less sucks, IMHO.

That means a warning that triggers on every line saying "there may be
a bug there" does not entirely suck?


> I'm afraid I don't follow. Do we have a way to say "I want an int of
> indeterminate sign" in C?

Almost completely.  The rules on aliasing say you can convert pointer
between signed and unsigned variants and the accesses will be
unsurprising.  The only problem is that the implicit conversion of
incompatible pointer parameters to a function looks impossible in the
draft I have.  Probably has been corrected in the final version.

In any case, having for instance unsigned int * in a prototype really
means in the language "I want a pointer to integers, and I'm probably
going to use it them as unsigned, so beware".  For the special case of
char, since the beware version would require a signed or unsigned tag,
it really means indeterminate.

C is sometimes called a high-level assembler for a reason :-)


> The same way there doesn't seem to be a way
> to say "I want a char of indeterminate sign". :( So no, strlen() doesn't
> actually say that, no matter if we like it or not. It actually says "I
> want a char with implementation-defined sign".

In this day and age it means "I want a 0-terminated string".
Everything else is explicitely signed char * or unsigned char *, often
through typedefs in the signed case.


> In fact it's implementation-defined, and this may make a difference
> here. strlen(), being part of C library, could be specifically
> implemented for given architecture, and as architecture is free to
> define the sign of "char", strlen() could in theory rely on particular
> sign of "char" as defined for given architecture. [Not that I think that
> any strlen() implementation actually depends on sign.]

That would require pointers tagged in a way or another, you can't
distinguish between pointers to differently-signed versions of the
same integer type otherwise (they're required to have same size and
alignment).  You don't have that on modern architectures.


> Can we assure that no function taking 'char*' ever cares about the sign?
> I'm not sure, and I'm not a language lawyer, but if it's indeed the
> case, I'd probably agree that it might be a good idea for GCC to extend
> the C language so that function argument declared "char*" means either
> of "char*", "signed char*", or "unsigned char*" even though there is no
> precedent in the language.

It's a warning you're talking about.  That means it is _legal_ in the
language (even if maybe implementation defined, but legal still).
Otherwise it would be an error.


> BTW, the next logical step would be for "int*" argument to stop meaning
> "signed int*" and become any of "int*", "signed int*" or "unsigned
> int*". Isn't it cool to be able to declare a function that won't produce
> warning no matter what int is passed to it? ;)

No, it wouldn't be logical, because char is *special*.


> Yes, indeed. So the real problem of the C language is inconsistency
> between strxxx() and isxxx() families of functions? If so, what is 
> wrong with actually fixing the problem, say, by using wrappers over
> isxxx()? Checking... The kernel already uses isxxx() that are macros
> that do conversion to "unsigned char" themselves, and a few invocations
> of isspace() I've checked pass "char" as argument. So that's not a real
> problem for the kernel, right?

Because a cast to silence a warning silences every possible warning
even if the then-pointer turns for instance into an integer through an
unrelated change.  Think for instance about an error_t going from
const char * (error string) to int (error code) through a patch, which
happened to be passed to an utf8_to_whatever conversion function that
takes an const unsigned char * as a parameter.  Casting would hide the
impact of changing the type.


> As the isxxx() family does not seem to be a real problem, at least in
> the context of the kernel source base, I'd like to