Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

[Jeff Garzik]

Ingo Molnar wrote:
so how about the following, different approach: anyone who has a tasklet 
in any performance-sensitive codepath, please yell now. We'll also do a 
proactive search for such places. We can convert those places to 
softirqs, or move them back into hardirq context. Once this is done - 
and i doubt it will go beyond 1-2 places - we can just mass-convert the 
other 110 places to the lame but compatible solution of doing them in a 
global thread context.



Color me unconvinced.

Tasklets fill a niche not filled by either workqueues (slower, requiring 
context switches, and possibly much latency is all wq's processes are 
active) or softirqs (limited number of them, not flexible at all). 
Sure, tasklets kick over to ksoftirqd, but not immediately, and therein 
lies their value.


And moving code -back- into hardirq is just the wrong thing to do, usually.

This proposal is ENTIRELY derived from "not convenient to my project" 
logic AFAICS, rather than the more sound "not needed in the kernel."


Jeff



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

Re: [AppArmor 00/44] AppArmor security module overview

[Andreas Dilger]

Any chance you can remove linux-fsdevel from the CC list?  I don't think this
has anything to do with filesystems.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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] atkbd: cleanup only once

[Dmitry Torokhov]

On Wednesday 27 June 2007 01:02, dave young wrote:
> 2007/6/27, Dmitry Torokhov <[EMAIL PROTECTED]>:
> > On Wednesday 27 June 2007 00:28, Greg KH wrote:
> > > On Wed, Jun 27, 2007 at 12:34:09AM -0400, Dmitry Torokhov wrote:
> > > > Hi Dave,
> > > >
> > > > On Wednesday 27 June 2007 06:59, Dave Young wrote:
> > > > > Hi,
> > > > >
> > > > > If you press ctrl+alt+del several times as kernel booting (before 
> > > > > user level bootin), the kernel will oops. I found the ps2_command is 
> > > > > called more than once, then the ps2dev->serio maybe NULL pointer.
> > > > >
> > > > > 2.6.22-rc5 and 2.6.22-rc6 have same result.
> > > > >
> > > > > Signed-off-by: Dave Young <[EMAIL PROTECTED]>
> > > > > ---
> > > > > diff -upr linux/drivers/input/keyboard/atkbd.c 
> > > > > linux.new/drivers/input/keyboard/atkbd.c
> > > > > --- linux/drivers/input/keyboard/atkbd.c  2007-06-27 
> > > > > 10:38:37.0 +
> > > > > +++ linux.new/drivers/input/keyboard/atkbd.c  2007-06-27 
> > > > > 10:37:39.0 +
> > > > > @@ -795,6 +795,11 @@ static int atkbd_activate(struct atkbd *
> > > > >
> > > > >  static void atkbd_cleanup(struct serio *serio)
> > > > >  {
> > > > > + static int flag;
> > > > > +
> > > > > + if(flag)
> > > > > + return;
> > > > > + flag = 1;
> > > >
> > > > Unfortunately this will prevent atkbd from resetting keyboard on 2nd
> > > > suspend attempt. It will also not work if you have an active MUX and
> > > > have a couple of keyboards connected.
> > > >
> > > > Greg, now that you removed rwsem from subsystem (and subsystem itself
> > > > for that matter) there is nothing as far as I can see that stops
> > > > several threads from running device_shutdown() simultaneously. I also
> > > > do not see what would isolate device probing and shutting them down
> > > > at the same time. Am I missing something?
> > >
> > > There was never anything stopping that from happening before.  No driver
> > > core code was using that rwsem, so it wasn't protecting anything,
> > > despite people trying to use it as if it was :)
> > >
> >
> > It did protect device_shutdown() from itself, didn't it?
> >
> > --
> > Dmitry
> >
> how about check ps2dev->serio in ps2_command before use it?

I don't think we ever set it to NULL. Does the patch below help any?

-- 
Dmitry


Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---

 drivers/input/serio/serio.c |2 ++
 1 files changed, 2 insertions(+)

Index: work/drivers/input/serio/serio.c
===
--- work.orig/drivers/input/serio/serio.c
+++ work/drivers/input/serio/serio.c
@@ -769,8 +769,10 @@ static int serio_driver_remove(struct de
 
 static void serio_cleanup(struct serio *serio)
 {
+   mutex_lock(>drv_mutex);
if (serio->drv && serio->drv->cleanup)
serio->drv->cleanup(serio);
+   mutex_unlock(>drv_mutex);
 }
 
 static void serio_shutdown(struct device *dev)
-
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 ?

[Arjan van de Ven]

On Wed, 2007-06-27 at 22:04 -0500, Patrick Draper wrote:
> Rene Herman wrote:
> > So -- the fact that mixing actually works for you when using libaoss 
> > means software mixing is working correctly for your ALSA setup. The only 
> > thing you should do is _use_ ALSA (natively) and not its OSS emulation 
> > so you can drop the library preload.
> 
> Cool. How do I go about figuring out what every app uses? For example, 
> you mentioned that the flash 9 plugin, which I also use, is an ALSA 
> aware application. How do you know? I need the check out everything that 
> I use which needs sound (vmware, skype, kmplayer, etc.) I don't have 
> source code for at least two of those.

run ldd on the binary...


-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Jan Harkes]

On Wed, Jun 27, 2007 at 08:08:08PM -0300, Alexandre Oliva wrote:
> On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
> 
> > GPLv2 section 3.
> > The source code for a work means the preferred form of the work for
> > making modifications to it.
> 
> > I believe this states that the source code has to be in the preferred
> > form for making modifications and not some other form that sucks rocks.
> 
> Yes, but in the scenario I proposed, the source code *is* in the
> preferred form for making modifications, it just so happens to be
> behind a barrier you cannot trespass.  This is not different from
> shipping binaries and sources in a CD inside a locked box that you
> can't open.  You've received both, but how is the fact that you can't
> reach the source code (or the binaries) a violation of the GPL in this
> case?

That was explained in next paragraph where I said that preventing access
sure sounds like a restriction on copying and modification, which is
where the GPL violation would be.

> As for making modifications, I'd like to take this opportunity to
> withdraw, for purposes of interpretation, my earlier agreement that
> TiVo permits modification, even though it doesn't permit modification
> in place.  I don't see any distinction in US copyright law between
> modification in place and modification by creating a separate work.

That doesn't really matter because the GPLv2 makes a distinction between
source code and binary object code. For instance in section 1 where it
says that you may copy and distribute the program's source code.

In section 2 where it talks about modifications it at first doesn't seem
to distinguish between source and binary, but it doesn't grant the right
that the resulting modified program will actually work. And yes, you can
still modify the kernel binary on the Tivo harddrive, it just won't boot
with the standard bootloader.

But there is an explicit no warranty clause in the GPLv2. Which I
believe is a good thing. If the license tried to enforce usability, i.e.
"continued functioning of the modified object code is in no case
prevented or interfered with", then any time a new release of the
program causes a regression for some users this would be a license
violation.

> This distinction makes sense for some cases of modification of
> software, but it doesn't make sense for other copyrightable works,
> such as sculptures, paintings, drawings, etc.
> 
> When you modify a sculpture, you're modifying it in place, and this
> requires as much copyright permission as creating a modified copy of
> it.  Both count as modification.

And when you scribble in the margin of a book you are also modifying it,
so what. I don't think you even need copyright permission, although you
will probably get into trouble if the book was borrowed from a library.
I don't see the relevance in the context of this discussion.

>   And if TiVo creates artificial
> obstacles to your modifying the copy of GPLed programs that ships in
> its devices, then I believe it counts as a restriction on
> modification.

You can modify the source, recompile it, even binary patch the kernel on
the Tivo's harddrive. None of that is restricted. What is restricted is
the freedom to run the modified object code on Tivo's hardware. That
right is not granted by the GPLv2, and fitness for any purpose is
explicitly disclaimed in the NO WARRANTY section.

... skipped a whole bunch, you actually repeated yourself a couple of
times but the same answer applied, GPLv2 does not grant the right to be
able to run the (modified) program on their hardware, and none of the
granted rights, to copy, distribute and modify, are restricted ...

> Here are variations of another scenario I proposed back then:
>
> - Tivoizing device ships with tivoized software, regardless of whether
> the corresponding sources are accessible to the end user or hidden
> inside the box, in a fully-encrypted disk that only that machine can
> read.

I'm assuming no written offer for access to the software is included.

Source are inaccessible, restricted the recipients rights to copy,
distribute and modify the source code, GPLv2 violation.

otherwise, source is accessible and recipient can copy, distribute and
modify.

> - Network authenticates the device with help of the built-in crypto
> device, and device requests feature-complete binaries in encrypted
> network sessions.  It's in the fature-complete binaries that the most
> valuable improvements made by the tivoizer are, that they don't want
> to share with anyone else.  Sources *are* available behind the same
> authentication machinery you don't can't get past.  Whether the device
> chooses to download them into the encrypted device you can't get to ,
> to dispose of them right away or even leave them around, or it simply
> refrains from downloading the sources because it doesn't need them,
> the end result is the same: you've received the sources over the
> network, 

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 28, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> Until someplace you can't actually access the software is customarily used
> for software interchange, ...

As in TiVo boxes? :-) :-)

> This is a defect in the GPL. At least as I understood it, the intent
> was to force distributors to remove any code for which there was a
> patent claim that might threaten redistribution. Section 7 fails to
> do that.

It's not intended to do that.  The existence of a patent doesn't
render the Software non-Free.  The patent holder's threats or
willingness to enforce it doesn't render the Software non-Free.  It's
accepting a restrictive license, voluntarily or by means of a court
order, that does.  And the GPL is not about anything but doing as much
as a copyright license can do to make sure the covered Free Software
remains Free for all its users.  So, requesting licensees to not use
their patents to deny other users' freedoms is something a copyright
license can do.  But since it can't affect patent holders that are not
copyright licensees, or any other legal mechanisms that non-licensees
could use to restrict users' freedoms, it remains silent about this,
rather than forcing licensees to comply with laws or avoid risks that
might not even apply to themselves.

> While you are granted rights under copyright, section 7 does not prevent
> people from using other laws (so long as they don't impose the restrictions
> or agree to them) to hamer your right to redistribute (or for those who
> receive a distribution from you to lawfully use the work).

I think that's correct, and IMHO that's how it's intended to be.

> It is quite difficult to actually arrange this. You would need something
> like a third party to indemnify your customers without your having to agree
> to such indemnification.

... and without making you a party in this collusion.  Basically, if
you're involved in the process of denying users' freedoms, the GPL may
have teeth for you.  If you're not, and you're not a licensee of code
present in that software, there's no way the GPL can stop you from
imposing whatever restrictions that law permits you to impose, if you
choose to do so.  But the GPL won't impose restrictions on others just
in case their downstream users might become your next target.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Daniel Hazelton]

On Thursday 28 June 2007 00:45:18 Alexandre Oliva wrote:
> On Jun 27, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > Section 3 doesn't apply to this situation. However, other sections
> > do. They are distributing in line with the distribution requirement,
> > but not the "modification and copying" requirements. These are
> > granted early in the license and covered by the "no further
> > restrictions" clause.
> >
> > You have to be able to copy and modify the source code for it to
> > comply with the GPL.
>
> Let's hope courts see it this way.

I'm sure they will. Section 0 of the GPLv2 states what the license covers. 
Copying & modification are two of those things.

> But then, why is it that I can't use hardware to stop someone from
> copying or modifying the source code, but I can use hardware to stop
> someone from copying or modifying the binary?  Or is that not so?

As has been repeatedly stated, on a TiVO or similar device they can stop you 
from running a user-built binary. They cannot, and do not, stop you from 
accessing the copy on the disc. They don't even prevent modification of it. 
What they do is stop the hardware from running the modified form.

> Remember, section 2 talks about modifying *your* *copies* of the
> Program, without any reference whatsoever as to whether they're in
> source or object form.

I can't argue with this.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 27, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> Section 3 doesn't apply to this situation. However, other sections
> do. They are distributing in line with the distribution requirement,
> but not the "modification and copying" requirements. These are
> granted early in the license and covered by the "no further
> restrictions" clause.

> You have to be able to copy and modify the source code for it to
> comply with the GPL.

Let's hope courts see it this way.

But then, why is it that I can't use hardware to stop someone from
copying or modifying the source code, but I can use hardware to stop
someone from copying or modifying the binary?  Or is that not so?

Remember, section 2 talks about modifying *your* *copies* of the
Program, without any reference whatsoever as to whether they're in
source or object form.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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: Userspace compiler support of "long long"

[H. Peter Anvin]

Kyle Moffett wrote:


The only trick is if you care about building 32-bit compat code using 
64-bit linux kernel headers.  In that case we should probably just make 
all archs use "long long" for their 64-bit integers, unless there's some 
platform I'm not remembering where "long long" is 128-bits or bigger.  
The other benefit is that people could then just use the printf format 
"%llu" for 64-bit integers instead of having to conditionalize it all 
over the place.




No, you really don't want to do that, because then u64 != uint64_t on 
those platforms.


-hpa

-
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 Kernel include files

[H. Peter Anvin]

Kyle Moffett wrote:


Gah, this particular topic and a few other similar header-compatibility 
ones show up once a month on LKML; I should probably just make a patch 
to fix all the types.h files and be done with it.  The proper solution 
is this:


# if __STDC_VERSION__ >= 19901L
typedef   signed long long __s64;
typedef unsigned long long __u64;
# elif defined(__GNUC__)
__extension__ typedef   signed long long __s64;
__extension__ typedef unsigned long long __u64;
# else
#  error "Your compiler doesn't support long long (IOW: It sucks).  
Please get a new one"

# endif

That way if you have any kind of vaguely-long-long-compatible compiler 
then it will work, and otherwise you'll get a nice useful error 
message.  It also makes sure that GCC doesn't spew warnings/errors when 
in c89-pedantic mode.  The "__extension__" keyword is designed for use 
in implementation header files which want to use GCC-isms unconditionally.




__extension__ should be macroized if so.

However, since something that doesn't have "long long" won't be able to 
compile those headers, there is absolutely no reason to not simply use 
it -- you get an error message on that line, which is good enough. 
There is definitely no reason to use a test like the one above, which is 
wrong for several supportable compilers.


-hpa

-
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: Userspace compiler support of "long long"

[Matthew Wilcox]

On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote:
> Then all 64-bit archs have:
> typedef   signed long  __s64;
> typedef unsigned long  __u64;
> 
> While all 32-bit archs have:
> typedef   signed long long __s64;
> typedef unsigned long long __u64;

include/asm-parisc/types.h:typedef unsigned long long __u64;

For both 32 and 64-bit.

include/asm-sh64/types.h:typedef unsigned long long __u64;
include/asm-x86_64/types.h:typedef unsigned long long  __u64;

So that's three architectures that violate your first assertion.
-
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: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip

[Bjorn Helgaas]

Andrey,

Can you try the following patch?  It applies on top of the previous
two patches, and it is enough to make the driver find the device on
my Portege 4000.  Unfortunately, I can't tell whether it really works
because I don't have a clue about how to make two IR devices talk
to each other.

Bjorn

Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.0 -0600
+++ w/drivers/pnp/quirks.c  2007-06-27 20:57:47.0 -0600
@@ -136,11 +136,11 @@
 
 static void quirk_smc_enable(struct pnp_dev *dev)
 {
-   /*
-* If the BIOS left the device disabled, or it is enabled and
-* responding correctly, we're in good shape.
-*/
-   if (!dev->active || quirk_smc_fir_enabled(dev))
+   unsigned int irq;
+   unsigned long flags;
+
+   pnp_activate_dev(dev);
+   if (quirk_smc_fir_enabled(dev))
return;
 
/*
@@ -159,9 +159,34 @@
pnp_init_resource_table(>res);
pnp_auto_config_dev(dev);
pnp_activate_dev(dev);
+   if (quirk_smc_fir_enabled(dev))
+   return;
+
+   /*
+* The Toshiba Portege 4000 reports the IRQ as active high,
+* edge-triggered, but the device only seems to work when we
+* program it as something else.
+*/
+   irq = pnp_irq(dev, 0);
+   flags = pnp_irq_flags(dev, 0);
+   pnp_disable_dev(dev);
+   dev->res.irq_resource[0].start = irq;
+   dev->res.irq_resource[0].end   = irq;
+   flags &= ~IORESOURCE_AUTO;
+   if ((flags & IORESOURCE_BITS) == IORESOURCE_IRQ_HIGHEDGE) {
+   flags &= ~IORESOURCE_BITS;
+   flags |= IORESOURCE_IRQ_LOWEDGE;
+   dev_err(>dev, "still not responding, changing high-edge "
+   "IRQ to low-edge\n");
+   }
+   dev->res.irq_resource[0].flags = flags;
+   pnp_activate_dev(dev);
+
+   if (quirk_smc_fir_enabled(dev))
+   return;
 
-   if (!quirk_smc_fir_enabled(dev))
-   dev_err(>dev, "giving up; try \"smsc-ircc2.nopnp\"\n");
+   dev_err(>dev, "giving up; try \"smsc-ircc2.nopnp\" and "
+   "email [EMAIL PROTECTED]");
 }
 
 
-
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 3/3] Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode

[David Chinner]

On Tue, Jun 19, 2007 at 03:25:52PM +0200, [EMAIL PROTECTED] wrote:
> * 32bit struct xfs_fsop_bulkreq has different size and layout of
>   members, no matter the alignment. Move the code out of the #else
>   branch (why was it there in the first place?). Define _32 variants of
>   the ioctl constants.
> * 32bit struct xfs_bstat is different because of time_t and on
>   i386 becaus of different padding. Create a new formatter
>   xfs_bulkstat_one_compat() that takes care of this. To do this, we need
>   to make xfs_bulkstat_one_iget() and xfs_bulkstat_one_dinode()
>   non-static.
> * i386 struct xfs_inogrp has different padding. Introduce a similar
>   "formatter" mechanism for xfs_inumbers: the native formatter is just a
>   copy_to_user, the compat formatter takes care of the different layout

Oh, wow, that is so much nicer than the first version, Michal. ;)

Still, I think there's possibly one further revision:

> +static int xfs_bulkstat_one_compat(
> + xfs_mount_t *mp,/* mount point for filesystem */
> + xfs_ino_t   ino,/* inode number to get data for */
> + void__user *buffer, /* buffer to place output in */
> + int ubsize, /* size of buffer */
> + void*private_data,  /* my private data */
> + xfs_daddr_t bno,/* starting bno of inode cluster */
> + int *ubused,/* bytes used by me */
> + void*dibuff,/* on-disk inode buffer */
> + int *stat)  /* BULKSTAT_RV_... */

Hmmm - this is almost all duplicated code. It's pretty much what I
described, but maybe not /quite/ what I had in mind here. It's a
*big* improvement on the first version, but it seems now that the
only real difference xfs_bulkstat_one() and
xfs_bulkstat_one_compat() is copy_to_user() vs the discrete put_user
calls.

I think we can remove xfs_bulkstat_one_compat() completely by using
the same method you used with the xfs_inumber_fmt functions. That
would mean the only duplicated code is the initial ioctl handling
(which we can't really avoid). It would also mean that there is no
need to make xfs_bulkstat_one_iget() and xfs_bulkstat_one_dinode()
non-static. Your thoughts?

Other than that possible improvement, this looks really good.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[David Schwartz]

> Alexandre Oliva writes:
>
> >> Yes, but in the scenario I proposed, the source code *is* in the
> >> preferred form for making modifications, it just so happens to be
> >> behind a barrier you cannot trespass.  This is not different from
> >> shipping binaries and sources in a CD inside a locked box that you
> >> can't open.  You've received both, but how is the fact that you can't
> >> reach the source code (or the binaries) a violation of the GPL in this
> >> case?
>
> > Behind a barrier is not the preferred form for modification.
>
> Where does it state that there must not be a barrier?  I see it saying
> the source must accompany the binary, under 3a.
>
> > Encrypted with a key you don't have is not the preferred form for
> > modification.
>
> Indeed, but why does it matter?  In a CD is not the preferred form for
> making modifications either.  In fact, in the CD, you can't modify it
> at all.  What's *behind* encryption is the source code, along with the
> binary it accompanies.
>
> >> And, if it's not a violation, what is it that makes the case of
> >> shipping programs in a locked enclosure different from shipping them
> >> in a locked computing device?
>
> > I honestly don't see what relevance this could possibly
> > have. Getting access to the source is a fundamental GPL right.
>
> That's the spirit.  But where does the *letter* of the GPL state it?

I stand by my claim that any obstacle to obtaining and modifying any copy of
the source code (and thus encumbering your ability to use it at all) would
be a violation of both the letter and the spirit of the GPL. (As expressed
in section 3.)

Until someplace you can't actually access the software is customarily used
for software interchange, ...

But I fear that your interpretation of section 7 is mostly correct. This is
a defect in the GPL. At least as I understood it, the intent was to force
distributors to remove any code for which there was a patent claim that
might threaten redistribution. Section 7 fails to do that.

While you are granted rights under copyright, section 7 does not prevent
people from using other laws (so long as they don't impose the restrictions
or agree to them) to hamer your right to redistribute (or for those who
receive a distribution from you to lawfully use the work).

It is quite difficult to actually arrange this. You would need something
like a third party to indemnify your customers without your having to agree
to such indemnification.

DS


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

[Lee Revell]

On 6/26/07, Andreas Hartmetz <[EMAIL PROTECTED]> wrote:

Why not put the whole sound system in userland? It has been done before. Sound
is just not performance critical at all and it's almost never mission
critical.


There are dozens of companies selling Linux powered professional audio
gear, multiple pro audio centric distros, and hundreds of serious free
software audio apps.  I suspect these developers and their users would
disagree.

I agree with you about userland drivers but at minimum this would
require merging the -rt kernel patches, otherwise the latency/jitter
will be too high to do anything but toy desktop sounds, then you need
a mergeable mechanism for doing DMA and interrupt handling in
userspace.  It has been attempted before but never evolved to the
point where you could drive a complex device like the emu10k1.

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

i386: [PATCH 1/1] remove-pit-latch-buggy

[TAKADA Yoshihito]

In 2.6.18, replace times with clockevents. arch/i386/kernel/timers/ was removed.
`pit_latch_buggy' was referred in timers/timer_tsc.c, and currently removed. 
Therefore nobody refer it. It has no effect already.

Signed-off-by: TAKADA Yoshihito <[EMAIL PROTECTED]>

diff -Narup a/arch/i386/kernel/cpu/cyrix.c b/arch/i386/kernel/cpu/cyrix.c
--- a/arch/i386/kernel/cpu/cyrix.c  2007-04-26 12:08:32.0 +0900
+++ b/arch/i386/kernel/cpu/cyrix.c  2007-06-28 12:13:13.0 +0900
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "cpu.h"
 
@@ -251,8 +250,6 @@ static void __cpuinit init_cyrix(struct 
 
case 4: /* MediaGX/GXm or Geode GXM/GXLV/GX1 */
 #ifdef CONFIG_PCI
-   {
-   u32 vendor, device;
/* It isn't really a PCI quirk directly, but the cure is the
   same. The MediaGX has deep magic SMM stuff that handles the
   SB emulation. It thows away the fifo on disable_dma() which
@@ -267,20 +264,6 @@ static void __cpuinit init_cyrix(struct 
 
printk(KERN_INFO "Working around Cyrix MediaGX virtual DMA 
bugs.\n");
isa_dma_bridge_buggy = 2;
-
-   /* We do this before the PCI layer is running. However we
-  are safe here as we know the bridge must be a Cyrix
-  companion and must be present */
-   vendor = read_pci_config_16(0, 0, 0x12, PCI_VENDOR_ID);
-   device = read_pci_config_16(0, 0, 0x12, PCI_DEVICE_ID);
-
-   /*
-*  The 5510/5520 companion chips have a funky PIT.
-*/  
-   if (vendor == PCI_VENDOR_ID_CYRIX &&
-(device == PCI_DEVICE_ID_CYRIX_5510 || device == 
PCI_DEVICE_ID_CYRIX_5520))
-   pit_latch_buggy = 1;
-   }
 #endif
c->x86_cache_size=16;   /* Yep 16K integrated cache thats it */
 
diff -Narup a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c   2007-04-26 12:08:32.0 +0900
+++ b/arch/i386/kernel/time.c   2007-06-26 10:15:34.0 +0900
@@ -70,8 +70,6 @@
 
 #include 
 
-int pit_latch_buggy;  /* extern */
-
 #include "do_timer.h"
 
 unsigned int cpu_khz;  /* Detected as we calibrate the TSC */
diff -Narup a/include/asm-i386/timer.h b/include/asm-i386/timer.h
--- a/include/asm-i386/timer.h  2007-04-26 12:08:32.0 +0900
+++ b/include/asm-i386/timer.h  2007-06-26 10:17:02.0 +0900
@@ -10,7 +10,6 @@ unsigned long long native_sched_clock(vo
 unsigned long native_calculate_cpu_khz(void);
 
 /* Modifiers for buggy PIT handling */
-extern int pit_latch_buggy;
 extern int timer_ack;
 extern int no_timer_check;
 extern int no_sync_cmos_clock;
-
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 ?

[Lee Revell]

On 6/27/07, Patrick Draper <[EMAIL PROTECTED]> wrote:

Rene Herman wrote:
> So -- the fact that mixing actually works for you when using libaoss
> means software mixing is working correctly for your ALSA setup. The only
> thing you should do is _use_ ALSA (natively) and not its OSS emulation
> so you can drop the library preload.

Cool. How do I go about figuring out what every app uses? For example,
you mentioned that the flash 9 plugin, which I also use, is an ALSA
aware application. How do you know? I need the check out everything that
I use which needs sound (vmware, skype, kmplayer, etc.) I don't have
source code for at least two of those.


Go into the sound preferences menu of the app and check which device
it uses.  If it's something like /dev/dsp or /dev/audio it's using
OSS.  If it looks like "default" or "hw:0" it's ALSA.

If your app does not have any sound preferences menu it's broken and
you should file a bug report.

You can determine whether an app with no configurable sound device is
using ALSA by running "strace broken_app" and grep the output for
"/dev/dsp" or "/dev/audio".

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

2.6.21.5-rt17 on lenovo t61, some BUG's (lukewarm IQ?)

[Fernando Lopez-Lezcano]

Hi Ingo, this is happening in a brand new laptop, a Lenovo t61 with a
7700 processor and the Santa Rosa chipset. 

Lukewarm IQ detected in hotplug locking
BUG: at kernel/cpu.c:44 lock_cpu_hotplug()
 [] dump_trace+0x64/0x105
 [] show_trace_log_lvl+0x18/0x2c
 [] show_trace+0xf/0x11
 [] dump_stack+0x12/0x14
 [] lock_cpu_hotplug+0x51/0x74
 [] sched_setaffinity+0x13/0xe5
 [] __synchronize_sched+0x35/0x5a
 [] arch_reinit_sched_domains+0x13/0x29
 [] sched_power_savings_store+0x3c/0x49
 [] sysdev_class_store+0x1e/0x22
 [] sysfs_write_file+0xa3/0xc6
 [] vfs_write+0xa8/0x154
 [] sys_write+0x41/0x67
 [] syscall_call+0x7/0xb
 [] 0xb7fb3410
 ===
Lukewarm IQ detected in hotplug locking
BUG: at kernel/cpu.c:44 lock_cpu_hotplug()
 [] dump_trace+0x64/0x105
 [] show_trace_log_lvl+0x18/0x2c
 [] show_trace+0xf/0x11
 [] dump_stack+0x12/0x14
 [] lock_cpu_hotplug+0x51/0x74
 [] sched_setaffinity+0x13/0xe5
 [] __synchronize_sched+0x57/0x5a
 [] arch_reinit_sched_domains+0x13/0x29
 [] sched_power_savings_store+0x3c/0x49
 [] sysdev_class_store+0x1e/0x22
 [] sysfs_write_file+0xa3/0xc6
 [] vfs_write+0xa8/0x154
 [] sys_write+0x41/0x67
 [] syscall_call+0x7/0xb
 [] 0xb7fb3410
 ===

I'm attaching the full output of dmesg FYI, let me know if you need
something else to make sense of this. 

[BTW, I tried to unsuccessfully boot rt18 today in one of my CCRMA
machines but the boot hung when trying to start the acpi daemon - this
was on FC6, I'll try to find out more tomorrow. We are seeing some hungs
with rt17 that I have not tried to diagnose yet]

-- Fernando

Linux version 2.6.21-0182.rt17.1.fc7.ccrmart ([EMAIL PROTECTED]) (gcc version 
4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP PREEMPT RT Tue Jun 19 16:21:25 EDT 
2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start:  size: 0009d800 end: 
0009d800 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 0009d800 size: 2800 end: 
000a type: 2
copy_e820_map() start: 000d2000 size: 2000 end: 
000d4000 type: 2
copy_e820_map() start: 000e size: 0002 end: 
0010 type: 2
copy_e820_map() start: 0010 size: 7d5b end: 
7d6b type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 7d6b size: 0001d000 end: 
7d6cd000 type: 3
copy_e820_map() start: 7d6cd000 size: 00033000 end: 
7d70 type: 4
copy_e820_map() start: 7d70 size: 0090 end: 
7e00 type: 2
copy_e820_map() start: f000 size: 0400 end: 
f400 type: 2
copy_e820_map() start: fec0 size: 0001 end: 
fec1 type: 2
copy_e820_map() start: fed0 size: 0400 end: 
fed00400 type: 2
copy_e820_map() start: fed14000 size: 6000 end: 
fed1a000 type: 2
copy_e820_map() start: fed1c000 size: 00074000 end: 
fed9 type: 2
copy_e820_map() start: fee0 size: 1000 end: 
fee01000 type: 2
copy_e820_map() start: ff00 size: 0100 end: 
0001 type: 2
 BIOS-e820:  - 0009d800 (usable)
 BIOS-e820: 0009d800 - 000a (reserved)
 BIOS-e820: 000d2000 - 000d4000 (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 7d6b (usable)
 BIOS-e820: 7d6b - 7d6cd000 (ACPI data)
 BIOS-e820: 7d6cd000 - 7d70 (ACPI NVS)
 BIOS-e820: 7d70 - 7e00 (reserved)
 BIOS-e820: f000 - f400 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fed0 - fed00400 (reserved)
 BIOS-e820: fed14000 - fed1a000 (reserved)
 BIOS-e820: fed1c000 - fed9 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff00 - 0001 (reserved)
1110MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f6900
Entering add_active_range(0, 0, 513712) 0 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  Normal   4096 ->   229376
  HighMem229376 ->   513712
early_node_map[1] active PFN ranges
0:0 ->   513712
On node 0 totalpages: 513712
  DMA zone: 56 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4040 pages, LIFO batch:0
  Normal zone: 3080 pages used for memmap
  Normal zone: 00 pages, LIFO batch:31
  HighMem zone: 3887 pages used for memmap
  HighMem zone: 280449 pages, LIFO batch:31
DMI present.
Using APIC driver default
ACPI: RSDP 000F68D0, 0024 (r2 LENOVO)
ACPI: XSDT 7D6BDFB8, 009C (r1 LENOVO TP-7L1070  LTP0)
ACPI: FACP 7D6BE100, 00F4 (r3 LENOVO TP-7L1070 

Re: Userspace compiler support of "long long"

[Kyle McMartin]

On Wed, Jun 27, 2007 at 04:16:48PM -0700, Randy Dunlap wrote:
> > LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> > Same for "ppc" (don't know which power* arch. they mean by that).
> 
> Hm, I suppose that table only applies to userspace, not kernel...
> 

Doing 64-bit Linux non-LP64 would be an interesting exercise in masochism...
-
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 007 of 8] knfsd: nfsd4: vary maximum delegation limit based on RAM size

[Andrew Morton]

On Wed, 27 Jun 2007 22:57:39 -0400 "J. Bruce Fields" <[EMAIL PROTECTED]> wrote:

> On Wed, Jun 27, 2007 at 07:36:13PM -0700, Andrew Morton wrote:
> > How's this?
> 
> Makes sense to me, thanks.  I guess fs/nsfd/nfssvc:nfsd_create_serv()
> should be similarly modified?  It calculates the size of per-nfsd-thread
> buffers used to hold requests, which will eventually be allocated with
> an alloc_page(GFP_KERNEL), and it bases the calculation on the same
> .totalram field from struct sysinfo.

Yup, it'd be better to use nr_free_buffer_pages() there too.
-
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 2/3] Fix XFS_IOC_*_TO_HANDLE and XFS_IOC_{OPEN,READLINK}_BY_HANDLE in compat mode

[David Chinner]

On Tue, Jun 19, 2007 at 03:25:51PM +0200, [EMAIL PROTECTED] wrote:
> 32bit struct xfs_fsop_handlereq has different size and offsets (due to
> pointers). TODO: case XFS_IOC_{FSSETDM,ATTRLIST,ATTRMULTI}_BY_HANDLE
> still not handled.

Looks good. Added to my qa tree...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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/3] Fix XFS_IOC_FSGEOMETRY_V1 in compat mode

[David Chinner]

On Tue, Jun 19, 2007 at 03:25:50PM +0200, [EMAIL PROTECTED] wrote:
> i386 struct xfs_fsop_geom_v1 has no padding after the last member, so
> the size is different.

Looks good. Added to my qa tree...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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 ?

[Patrick Draper]

Rene Herman wrote:
So -- the fact that mixing actually works for you when using libaoss 
means software mixing is working correctly for your ALSA setup. The only 
thing you should do is _use_ ALSA (natively) and not its OSS emulation 
so you can drop the library preload.


Cool. How do I go about figuring out what every app uses? For example, 
you mentioned that the flash 9 plugin, which I also use, is an ALSA 
aware application. How do you know? I need the check out everything that 
I use which needs sound (vmware, skype, kmplayer, etc.) I don't have 
source code for at least two of those.


Thanks,
Patrick
-
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: [BUG] long freezes on thinkpad t60

[Davide Libenzi]

On Wed, 27 Jun 2007, Linus Torvalds wrote:

> On Wed, 27 Jun 2007, Davide Libenzi wrote:
> 
> > On Wed, 27 Jun 2007, Linus Torvalds wrote:
> > > 
> > > Stores never "leak up". They only ever leak down (ie past subsequent 
> > > loads 
> > > or stores), so you don't need to worry about them. That's actually 
> > > already 
> > > documented (although not in those terms), and if it wasn't true, then we 
> > > couldn't do the spin unlock with just a regular store anyway.
> > 
> > Yes, Intel has never done that. They'll probably never do it since it'll 
> > break a lot of system software (unless they use a new mode-bit that 
> > allows system software to enable lose-ordering). Although I clearly 
> > remember to have read in one of their P4 optimization manuals to not 
> > assume this in the future.
> 
> That optimization manual was confused. 
> 
> The Intel memory ordering documentation *clearly* states that only reads 
> pass writes, not the other way around.

Yes, they were stating that clearly. IIWNOC (If I Were Not On Crack) I 
remember them saying to not assume any ordering besides the data 
dependency and the CPU self-consistency in the future CPUs, and to use 
*fence instructions when certain semantics were required.
But google did not help me in finding that doc, so maybe I were really on 
crack :)



- Davide


-
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] hwbkpt: Hardware breakpoints (was Kwatch)

[Roland McGrath]

I did the first crack at a powerpc port.  I'd appreciate your comments on
this patch.  It should not be incorporated, isn't finished, probably breaks
ptrace, etc.  I'm posting it now just to get any thoughts you have raised
by seeing the second machine share the intended arch-independent code.

I just translated your implementation to powerpc terms without thinking
about it much.  If you see anything that you aren't sure is right, please
tell me and don't presume there is some powerpc-specific reason it's
different.  More likely I just didn't think it through.

In the first battle just to make it compile, the only issue was that you
assume every machine has TIF_DEBUG, which is in fact an implementation
detail chosen lately by i386 and x86_64.  AFAIK the only reason for it
there is just to make a cheap test of multiple bits in the hot path
deciding to call __switch_to_xtra.  Do you rely on it meaning something
more precise than just being a shorthand for hw_breakpoint_info!=NULL?

Incidentally, I think it would be nice if kernel/hw_breakpoint.c itself had
all the #include's for everything it uses directly.  arch hw_breakpoint.c
files probably only need  and one or two others to
define what they need before #include "../../../kernel/hw_breakpoint.c".

The num_installed/num_kbps stuff feels a little hokey when it's really a
flag because the maximum number is one.  It seems like I could make it
tighter with some more finesse in the arch-specific hook options, so that
chbi and thbi each just store dabr, dabr!=0 means "mine gets installed",
and the switch in is just chbi->dabr?:thbi->dabr or something like that.
As we get more machines, more cleanups along these lines will probably make
sense.  (Also, before the next person not me or you tries a port, we could
use for the generic hw_breakpoint.c to get some comments at the top making
explicit what the arch file is expected to define in its types, etc.)

With just the included change to the generic code for the TIF_DEBUG, this
kind of works.  That is, it doesn't break everything else and I can use
bptest, sort of.  I didn't even try ptrace, I probably broke that.

It works enough to make clear the main new wrinkle.  On powerpc, the data
breakpoint exception is a fault before the instruction executes, not a trap
after it.  The load/store will not complete until the breakpoint is cleared.
With this patch, you can use bptest to generate a tight loop of bp0 triggers.

For ptrace compatibility, userland already expects to deal with this.  gdb
has it as per-machine implementation options how ptrace watchpoints behave,
and for powerpc it knows to remove the watchpoint, step, and reinsert it.

One approach for hw_breakpoint is just to expose in asm/hw_breakpoint.h
some standard macros saying how things behave, and caveat emptor.  But I
don't like that much.  I think things will just wind up being confused and
inadvertently unportable if the important semantics vary too much between
machines.  The point of the whole facility is to make watchpoints easy to
use, after all.

Some uses might be happy with trigger-before, but I don't see much benefit.
For writing, the trigger function can look at the memory before it's
changed.  But you could just as well have recorded the old value before
setting the breakpoint, as you have to for trigger-after--and to see both
old and new values you then need to single-step to get the new value, which
trigger-after handles with a single exception.  For reading, the trigger
function can change the memory before it's read.  But likewise, you could
just as well have changed it before setting the breakpoint--you know noone
will have read the new value until your trigger anyway.  (I have never used
a read-triggered breakpoint, so I'm rather vague on those use scenarios.)

The third machine whose manual I have handy is ia64.  It has instruction
and data breakpoints that are both trigger-before.  It has processor flags
similar to x86's RF for both, to ignore one or both breakpoint flavor for
one instruction.  That makes it cheap to continue past the breakpoint since
you don't have to clear and reset it.  But for getting new values from
data-write breakpoints, it still requires a single-step and second stop,
like powerpc.  (Incidentally ia64 has another interesting feature, which I
think the generic code accomodates nicely as an upward-compatible addition
just by changing the len arg in the register and arch_* calls to unsigned long,
and adding an arch_validate_len that can short-circuit the generic length
and alignment check.)

So, I'd like your thoughts on the whole situation.  The starting point we
can do without anything else is:

int hw_breakpoint_triggers_before(struct hw_breakpoint *);
int hw_breakpoint_can_resume(struct hw_breakpoint *);

or perhaps taking (unsigned int type) instead, in .
i.e. for x86:

#define hw_breakpoint_triggers_before(type) ((type) == HW_BREAKPOINT_EXECUTE)
#define hw_breakpoint_can_resume(type)  

Re: [patch 2/3] MAP_NOZERO - implement sys_brk2()

[Davide Libenzi]

On Wed, 27 Jun 2007, Davide Libenzi wrote:

> On Wed, 27 Jun 2007, Nicholas Miell wrote:
> 
> > 1) euid is not sufficient, you need to store away arbitrary LSM
> > information and call LSM hooks to decide security equivalence. The same
> > applies to VServer or whatever other container system you use.
> 
> The EUID that is used now, can easily be any cookie. It can be an LSM 
> cookie (if LSM is active in the system). We don't do complex checks, like 
> group permission & Co.  We assume that if a UID-cookie had such data 
> available (or it generated it), it can have it back uncleared.

(looking through the LSM/SeLinux jungle)
Also, LSM/SeLinux could disable completely the feature, at request. Just 
assign a known-to-be-invalid UID to mm->owner_uid (passign through 
an(other) hook), and pages will never be recycled.



- Davide


-
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 007 of 8] knfsd: nfsd4: vary maximum delegation limit based on RAM size

[J. Bruce Fields]

On Wed, Jun 27, 2007 at 07:36:13PM -0700, Andrew Morton wrote:
> How's this?

Makes sense to me, thanks.  I guess fs/nsfd/nfssvc:nfsd_create_serv()
should be similarly modified?  It calculates the size of per-nfsd-thread
buffers used to hold requests, which will eventually be allocated with
an alloc_page(GFP_KERNEL), and it bases the calculation on the same
.totalram field from struct sysinfo.

--b.
-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Daniel Hazelton]

On Wednesday 27 June 2007 22:37:42 Alexandre Oliva wrote:
> On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> > Behind a barrier is not on a medium customarily used for software
> > interchange, which 3a requires.
>
> Are you per chance claiming that you've never heard of anyone
> receiving encrypted software in a CD, or pre-installed in a computer?

It isn't common. In fact, I can only think of *ONE* instance of this - that of 
the original Quake 1 "Demo" CD that, when given the proper unlock codes, 
contained the entire game, along with all previous idsoft games.

> >> > I honestly don't see what relevance this could possibly
> >> > have. Getting access to the source is a fundamental GPL right.
> >>
> >> That's the spirit.  But where does the *letter* of the GPL state it?
> >
> > 3a says it.
>
> It says the sources must accompany the binaries (check), must be
> machine-readable (check), and must be on a medium customarily used for
> software interchange (check).
>
> Where does it say you have to be able to access the sources?  Or the
> binary, for that matter?

Section 3 doesn't apply to this situation. However, other sections do. They 
are distributing in line with the distribution requirement, but not 
the "modification and copying" requirements. These are granted early in the 
license and covered by the "no further restrictions" clause.

You have to be able to copy and modify the source code for it to comply with 
the GPL. 

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
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 try #2] security: Convert LSM into a static interface

[Serge E. Hallyn]

Quoting James Morris ([EMAIL PROTECTED]):
> On Wed, 27 Jun 2007, Serge E. Hallyn wrote:
> 
> > Patch tests fine for me for expected capability behavior with lsm=n,
> > lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y.
> > 
> > So while I'm opposed to the patch, it appears to be safe.
> 
> I've also tested a bunch of scenarios: allmodconfig, lsm=y,cap=n, 
> selinux=y,cap=n  etc.

I was wondering about the uninlining of all those functions, so did a
set of performance runs.  Found no statistically relevant change in
dbench, tbench, or reaim.  (tried to run kernbench too but the benchmark
failed somewhere and i didn't care enough to look into it)

-serge
-
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] fsblock

[Nick Piggin]

On Thu, Jun 28, 2007 at 08:35:48AM +1000, David Chinner wrote:
> On Wed, Jun 27, 2007 at 07:50:56AM -0400, Chris Mason wrote:
> > Lets look at a typical example of how IO actually gets done today,
> > starting with sys_write():
> > 
> > sys_write(file, buffer, 1MB)
> > for each page:
> > prepare_write()
> > allocate contiguous chunks of disk
> > attach buffers
> > copy_from_user()
> > commit_write()
> > dirty buffers
> > 
> > pdflush:
> > writepages()
> > find pages with contiguous chunks of disk
> > build and submit large bios
> > 
> > So, we replace prepare_write and commit_write with an extent based api,
> > but we keep the dirty each buffer part.  writepages has to turn that
> > back into extents (bio sized), and the result is completely full of dark
> > dark corner cases.

That's true but I don't think an extent data structure means we can
become too far divorced from the pagecache or the native block size
-- what will end up happening is that often we'll need "stuff" to map
between all those as well, even if it is only at IO-time.

But the point is taken, and I do believe that at least for APIs, extent
based seems like the best way to go. And that should allow fsblock to
be replaced or augmented in future without _too_ much pain.

 
> Yup - I've been on the painful end of those dark corner cases several
> times in the last few months.
> 
> It's also worth pointing out that mpage_readpages() already works on
> an extent basis - it overloads bufferheads to provide a "map_bh" that
> can point to a range of blocks in the same state. The code then iterates
> the map_bh range a page at a time building bios (i.e. not even using
> buffer heads) from that map..

One issue I have with the current nobh and mpage stuff is that it
requires multiple calls into get_block (first to prepare write, then
to writepage), it doesn't allow filesystems to attach resources
required for writeout at prepare_write time, and it doesn't play nicely
with buffers in general. (not to mention that nobh error handling is
buggy).

I haven't done any mpage-like code for fsblocks yet, but I think they
wouldn't be too much trouble, and wouldn't have any of the above
problems...
-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> Behind a barrier is not on a medium customarily used for software
> interchange, which 3a requires.

Are you per chance claiming that you've never heard of anyone
receiving encrypted software in a CD, or pre-installed in a computer?

>> > I honestly don't see what relevance this could possibly
>> > have. Getting access to the source is a fundamental GPL right.
>> 
>> That's the spirit.  But where does the *letter* of the GPL state it?

> 3a says it.

It says the sources must accompany the binaries (check), must be 
machine-readable (check), and must be on a medium customarily used for
software interchange (check).

Where does it say you have to be able to access the sources?  Or the
binary, for that matter?

> It makes no difference who imposes the restriction. Read section 7
> carefully. If *anything* imposes restrictions on the recipient's
> exercise of their GPL rights, you can't distribute.

This is actually not what section 7 says.  If it were so, the GPL
would forbid you from distributing any software whatsoever, because it
might reach someone in the US who would then be forbidden by law from
distributing it to someone in Cuba.  It would forbid you from
distributing cryptography software, or DVD descrambling software,
because the software might reach someone in a country where their
distribution is illegal.  Or it would forbid you from distributing
software that is covered by some patent in some distant country, just
because the software might reach a person there who might then be
stopped by the patent holder from distributing the software.

But the GPL doesn't forbid any such things.

The GPL stops you from distributing the software when you impose the
restriction yourself, or when you are required by a third party to
impose such a restriction.  For example, when you accept a patent
license that states you won't permit downstream users to distribute
the software, then you become a party that impose restrictions.  If
you don't have the source or written offer needed to comply with the
conditions of section 3, then you can't distribute the software.  It's
in this kind of situation that section 7 kicks in.

>> >> I ought to be entitled to modify any bit in the executable and
>> >> expect that to have the same effect as modifying that bit on that
>> >> executable on any other computer.

>> > Nope, sorry. If this were true, you ought to be entitled to
>> > modify a bit in
>> > the Linux kernel and have it have the same effect as modifying
>> > that Linux
>> > kernel on my desktop.

>> If your desktop is sufficiently similar, and the kernel binaries are
>> identical, why should I not expect the same result to arise?

> Because you have no way to get that software to run on my desktop,

Aah, I misunderstood what you wrote.  Yes, as long as you are entitled
to stop me from modifying software on your desktop, then I'm not
entitled to modify it.

However, once I'm entitled to make an identical change to the
identical software running on both your (or my) desktop and another
nearly-identical computer, if they behaved exactly the same before the
modification, I'm reasonably entitled to expect them to do behave
exactly the same after the modification.  If they don't, and I find
out that it's because the party who distributed the software to me
introduced mechanisms to prevent me from modifying the software, how
is that not a "further restriction"?

>> 2. You may modify your copy or copies of the Program or any portion
>> of it  ^^

> This is pretty clear that no copy is special. In any event, this is a grant
> of license, not a guarantee of ability. (Read the context.)

Yes, it's a grant of license.  And then, section 6 tells a licensee
that, when he distributes the software to someone else, she receives a
license to modify that copy of the software, as well as to make
further copies and modify them, and he must not impose any further
restrictions on the exercise of the granted rights.  QED

> Otherwise, you could get around the GPL just by having someone else
> impose restrictions.

Oh, wow, really?  Are you familiar with the Microsoft Novell deal?  Is
this not exactly how they got around the GPL?

The only reason GPLv3 can oppose distribution under these conditions
is precisely the existence of the deal, which turns both Microsoft and
Novell parties of an arrangement to distribute the software in a way
that imposes further restrictions on the recipient's rights granted by
the license.  Unfortunately, I'm told GPLv2 is vulnerable to this
particular deal.

Also remember that it's not enough for Microsoft or anyone else to
have patents that might be used to impose restrictions on others'
exercise of their rights for the GPL to say you can't distribute the
software.  You must (voluntarily or not) accept a restrictive license
before section 7 kicks in and stops you from distributing the software
under the 

Re: [PATCH 007 of 8] knfsd: nfsd4: vary maximum delegation limit based on RAM size

[Andrew Morton]

On Wed, 27 Jun 2007 22:15:52 -0400 "J. Bruce Fields" <[EMAIL PROTECTED]> wrote:

> + /*
> +  * Allow at most 4 delegations per megabyte of RAM.  Quick
> +  * estimates suggest that in the worst case (where every delegation
> +  * is for a different inode), a delegation could take about 1.5K,
> +  * giving a worst case usage of about 6% of memory.
> +  */
>   sys.totalram >>= (18 - PAGE_SHIFT);

6% of 32GB is 2GB is too much for a large highmem machine.  We should base
this on the amount of kernel-addressable memory (aka lowmem).

How's this?

static void
set_max_delegations(void)
{
/*
 * Allow at most 4 delegations per megabyte of RAM.  Quick
 * estimates suggest that in the worst case (where every delegation
 * is for a different inode), a delegation could take about 1.5K,
 * giving a worst case usage of about 6% of memory.
 */
max_delegations = nr_free_buffer_pages() >> (20 - 2 - PAGE_SHIFT);
}


 fs/nfsd/nfs4state.c |7 ++-
 mm/page_alloc.c |1 +

diff -puN 
fs/nfsd/nfs4state.c~knfsd-nfsd4-vary-maximum-delegation-limit-based-on-ram-size-fix-fix-fix-fix
 fs/nfsd/nfs4state.c
--- 
a/fs/nfsd/nfs4state.c~knfsd-nfsd4-vary-maximum-delegation-limit-based-on-ram-size-fix-fix-fix-fix
+++ a/fs/nfsd/nfs4state.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3210,17 +3211,13 @@ get_nfs4_grace_period(void)
 static void
 set_max_delegations(void)
 {
-   struct sysinfo sys;
-
-   si_meminfo();
/*
 * Allow at most 4 delegations per megabyte of RAM.  Quick
 * estimates suggest that in the worst case (where every delegation
 * is for a different inode), a delegation could take about 1.5K,
 * giving a worst case usage of about 6% of memory.
 */
-   sys.totalram >>= (18 - PAGE_SHIFT);
-   max_delegations = (unsigned int) sys.totalram;
+   max_delegations = nr_free_buffer_pages() >> (20 - 2 - PAGE_SHIFT);
 }
 
 /* initialization to perform when the nfsd service is started: */
diff -puN 
mm/page_alloc.c~knfsd-nfsd4-vary-maximum-delegation-limit-based-on-ram-size-fix-fix-fix-fix
 mm/page_alloc.c
--- 
a/mm/page_alloc.c~knfsd-nfsd4-vary-maximum-delegation-limit-based-on-ram-size-fix-fix-fix-fix
+++ a/mm/page_alloc.c
@@ -1729,6 +1729,7 @@ unsigned int nr_free_buffer_pages(void)
 {
return nr_free_zone_pages(gfp_zone(GFP_USER));
 }
+EXPORT_SYMBOL_GPL(nr_free_buffer_pages);
 
 /*
  * Amount of free RAM allocatable within all zones
_

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

[Rene Herman]

On 06/28/2007 03:58 AM, Rene Herman wrote:

to figure it out. If you need to specify an ALSA device somewhere, make 
sure it's not the old "hw:0" but "default" (or "default:0" for the first

card, "default:1" for the second, ...). The "hw:N" devices don't do
mixing.


Slight correction/expansion -- don't do _software_ mixing. Some cards can do 
hardware mixing and in that case, "hw:N" or, specifically "hw:N,0", "hw:N,1" 
and so on devices are available as hardware mixed devices.


Try a cat /proc/asound/card0/pcm0p/info and check the "subdevices_count" for 
the number of hardware mixed playback devices you have available. If it's 1, 
your card should've been configured (by ALSA itself) to use software mixing 
by default and if it's higher than 1, it should not have been and will use 
hardware mixing...


Rene.
-
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 007 of 8] knfsd: nfsd4: vary maximum delegation limit based on RAM size

[J. Bruce Fields]

This code would benefit from a little more explanation.

Also, I screwed up the previous patch and forgot to delete a line, so the
calculation here is off; fix it.

Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
---

 fs/nfsd/nfs4state.c |   16 +++-
 1 files changed, 15 insertions(+), 1 deletions(-)

On Mon, Jun 25, 2007 at 08:52:44PM -0700, Andrew Morton wrote:
>
> Please put yourself in the position of the reader who happens across this
> code and wonders why it is that way.
> 
> They could of course go hunt it out of the git repo but I do think it's
> quite a bit more reader-friendly to explain the thinking in code comments.
>

Yup, sorry about that.  Could you apply this?

--b.

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index fbbbcab..1b2657f 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -3203,13 +3203,27 @@ get_nfs4_grace_period(void)
return max(user_lease_time, lease_time) * HZ;
 }
 
+/*
+ * Since the lifetime of a delegation isn't limited to that of an open, a
+ * client may quite reasonably hang on to a delegation as long as it has
+ * the inode cached.  This becomes an obvious problem the first time a
+ * client's inode cache approaches the size of the server's total memory.
+ *
+ * For now we avoid this problem by imposing a hard limit on the number
+ * of delegations, which varies according to the server's memory size.
+ */
 static void
 set_max_delegations(void)
 {
struct sysinfo sys;
 
si_meminfo();
-   sys.totalram *= sys.mem_unit;
+   /*
+* Allow at most 4 delegations per megabyte of RAM.  Quick
+* estimates suggest that in the worst case (where every delegation
+* is for a different inode), a delegation could take about 1.5K,
+* giving a worst case usage of about 6% of memory.
+*/
sys.totalram >>= (18 - PAGE_SHIFT);
max_delegations = (unsigned int) sys.totalram;
 }
-- 
1.5.2.58.g98ee

-
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: Userspace compiler support of "long long"

[Geert Uytterhoeven]

On Wed, 27 Jun 2007, Randy Dunlap wrote:
> On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
> > LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> > Same for "ppc" (don't know which power* arch. they mean by that).
> 
> Hm, I suppose that table only applies to userspace, not kernel...

32-bit userspace?

On 64-bit, `long' is 64-bit on all platforms supported by Linux.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 ?

[Rene Herman]

On 06/28/2007 02:18 AM, Patrick Draper wrote:

Please always use Reply-to-All on this list -- subscribers here like to also 
get personal copies.



Rene Herman wrote:
KDE has finally dropped aRts from KDE4 and, again, ALSA has been 
mixing by default for some time now so we're talking history anyway. 
You want mixing on your card? You got it.


I've been following this discussion with some interest, to learn more 
about ALSA. I've been creating startup scripts for all of my sound-using 
applications which look like this:


LD_PRELOAD=libaoss.so exec /usr/bin/alsaplayer "$*"

I found that without libaoss.so preloaded, I wasn't getting software 
mixing at all.


This would seem to indicate that your alsaplayer (what's in a name) is setup 
to output to OSS and not to ALSA...


The OSS interface -- consisting of direct access to device nodes such as 
/dev/dsp0, /dev/mixer and /dev/music -- is an older interface for sound on 
Linux. The newer ALSA interface works via a library API and is best used 
natively. For backwards compatibility though, ALSA also provides emulation 
of the older OSS interface.


It does so in two different ways in fact -- the first one is a direct kernel 
space emulation where ALSA interprets accesses to those device nodes it then 
manages much like real OSS would do. This kernel space emulation is made 
available through the "OSS PCM/Mixer/Sequencer API" you see as options in 
the ALSA kernel configuration menu.


The other way is a userspace emulation through the libaoss.so library that 
you are using. That library catches accesses to the OSS device nodes in 
userspace and translates them to ALSA accesses before they even get to the 
kernel.


ALSA does software mixing (the act of mixing two seperate streams together 
to form one) in userspace and as such, the kernelspace OSS emulation does 
not support software mixing, while this userspace emulation does -- if your 
ALSA default device is setup for software mixing (it is by default these 
days) this also works for this libaoss route. If you run a OSS program 
without the library preload it's using the kernel emulation though.


So -- the fact that mixing actually works for you when using libaoss means 
software mixing is working correctly for your ALSA setup. The only thing you 
should do is _use_ ALSA (natively) and not its OSS emulation so you can drop 
the library preload.


I don't have alsaplayer installed (wasn't that thing dead?) so I can't walk 
you through its configuration easily, but I suppose you'll be able to figure 
it out. If you need to specify an ALSA device somewhere, make sure it's not 
the old "hw:0" but "default" (or "default:0" for the first card, "default:1" 
for the second, ...). The "hw:N" devices don't do mixing.



I'm constantly running an MP3 player, and with that library I can get
sound alerts from other apps too.


I myself mostly use the ogg123 and mpg321 command line players, both based 
on libao and thereby only a simple:


$ echo "default_driver=alsa09" >/etc/libao.conf

away from being native ALSA players.

I don't understand exactly what you mean by ALSA mixing by default. I 
have the OSS Mixer API selected during kernel compiles. Is that what you

are referring to?


No. That's part of the kernel space OSS emulation. A "mixer" in that context 
is the part of a soundcard that controls volumes and may mix the output of 
several parts of the card/chip for playback and its inputs for capture. Ie, 
that which is controlled by a mixer application such as the (ncurses) ALSA 
reference mixer "alsamixer" or the mixer your desktop environment provides.


Once you have everything running as a native ALSA application you could 
disable that option. In fact, since you're using the userspace emulation, 
you could already. The new-ish Flash Player 9 (important for youtube these 
days) for Linux is also an ALSA application and since I use it, I myself 
haven't needed OSS emulation for anything anymore.


Rene.

-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[David Schwartz]

> On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
>
> > Alexandre Oliva writes:
>
> >> Yes, but in the scenario I proposed, the source code *is* in the
> >> preferred form for making modifications, it just so happens to be
> >> behind a barrier you cannot trespass.  This is not different from
> >> shipping binaries and sources in a CD inside a locked box that you
> >> can't open.  You've received both, but how is the fact that you can't
> >> reach the source code (or the binaries) a violation of the GPL in this
> >> case?

> > Behind a barrier is not the preferred form for modification.

> Where does it state that there must not be a barrier?  I see it saying
> the source must accompany the binary, under 3a.

Behind a barrier is not on a medium customarily used for software
interchange, which 3a requires.

> > Encrypted with a key you don't have is not the preferred form for
> > modification.

> Indeed, but why does it matter?  In a CD is not the preferred form for
> making modifications either.  In fact, in the CD, you can't modify it
> at all.  What's *behind* encryption is the source code, along with the
> binary it accompanies.

On a CD is a preferred form for making modifications to it. You are assuming
"it" means one particular copy of the source code when in fact "it" means
the source code.

> >> And, if it's not a violation, what is it that makes the case of
> >> shipping programs in a locked enclosure different from shipping them
> >> in a locked computing device?
>
> > I honestly don't see what relevance this could possibly
> > have. Getting access to the source is a fundamental GPL right.
>
> That's the spirit.  But where does the *letter* of the GPL state it?

3a says it.

> > By this argument, shipping a GPL'd work in ROM would violate the GPL
> > because you cannot easily modify that particular copy.

> I've already explained that the inability to modify what's in the CD
> is not a restriction imposed by whoever recorded the bits in there as
> a means to stop you from making modifications.

It makes no difference who imposes the restriction. Read section 7
carefully. If *anything* imposes restrictions on the recipient's exercise of
their GPL rights, you can't distribute.

> >> I ought to be entitled to modify any bit in the executable and
> >> expect that to have the same effect as modifying that bit on that
> >> executable on any other computer.

> > Nope, sorry. If this were true, you ought to be entitled to
> > modify a bit in
> > the Linux kernel and have it have the same effect as modifying
> > that Linux
> > kernel on my desktop.

> If your desktop is sufficiently similar, and the kernel binaries are
> identical, why should I not expect the same result to arise?

Because you have no way to get that software to run on my desktop, just as
you have no way to get that software to run on your Tivo.

> > Again, nonsense view leads to nonsense conclusions.  The fix is to
> > reject the nonsense view. There are no special GPL rights to
> > particular copies of works or particular hardware.

>   2. You may modify your copy or copies of the Program or any portion
>  of it  ^^

This is pretty clear that no copy is special. In any event, this is a grant
of license, not a guarantee of ability. (Read the context.)

> >> The fact that it stops
> >> working as a result of TiVo's design to prohibit modification, rather
> >> than by any other differences in the computer (e.g., the absence of
> >> the signature checks), just goes to show that there is intent to
> >> impose further restrictions on modification of the software.
>
> > Intent is not the issue.
>
> Imposing further restrictions is the issue.

No, read section 7. The GPL does not just prevent you from imposing further
restrictions, it also prohibits you from distrbuting if *anything* imposes
such restrictions. Otherwise, you could get around the GPL just by having
someone else impose restrictions.

> > If the GPL says I can modify my distributed copy, then distributing
> > on CDROM is a GPL violation.

> It doesn't state "you must distribute sources in modifyable media", it
> says "you may modify your copies, and the distributor must not have
> imposed restrictions on your exercise of this right"

> If you can't modify your copies because others get in the way, too
> bad.  If you can't just because the distributor stops you, there's a
> GPL violation.

You are now directly contradicting yourself. We agreed that if anything
prevented your recipients from exercising your GPL rights, that means you
cannot distribute. How you are saying so long as you don't stop them, you
can distribute. In fact, the former view is correct and the latter is wrong,
as GPL section 7 makes clear.

If the right/ability to modify a particular copy is a GPL right, then you
cannot distribute on CDROM.

> > It is mind-bogglingly obvious that any sort of "right to modify one
> > particular copy" is *not* a GPL 

Re: [PATCH 1/1] file capabilities: introduce cap_setfcap

[KaiGai Kohei]

Serge E. Hallyn wrote:

Here's the first patch (of several or many to come) to address some of
Andrew's comments.

Kaigai, IIUC cap_names.h will eventually be automatically updated?  (I
had to manually tweak it for testing as the new kernel sources were not
located on the test system)


The origin of cap_names.h is "/usr/include/linux/capability.h".
Some scripts kicked by Makefile convert it, then cap_names.h will
be generated.

I don't know whether we can expect the kernel headers are always
deployed under "/usr/include/linux", or not.
In Fedora system, the kernel-headers package deploys all headers
there, so cap_names.h will eventually be automatically updated.

Thanks,


thanks,
-serge


From fefcd341e478bd9e490d34abe9efd3c3c4f0b8a0 Mon Sep 17 00:00:00 2001

From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Wed, 27 Jun 2007 13:09:20 -0400
Subject: [PATCH 1/1] file capabilities: introduce cap_setfcap

Setting file capabilities previously required the
cap_sys_admin capability, since they are stored as
extended attributes in the security.* namespace.

Introduce CAP_SETFCAP (to mirror CAP_SETPCAP), and
require it for setting file capabilities instead of
CAP_SYS_ADMIN.

Quoting Andrew Morgan,

"CAP_SYS_ADMIN is way too overloaded and this
functionality is special."

Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
---
 include/linux/capability.h |4 +++-
 security/commoncap.c   |   12 ++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index 89125df..cdfaa10 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -324,7 +324,9 @@ typedef __u32 kernel_cap_t;
 
 #define CAP_AUDIT_CONTROL30
 
-#define CAP_NUMCAPS	 31

+#define CAP_SETFCAP 31
+
+#define CAP_NUMCAPS 32
 
 #ifdef __KERNEL__
 /* 
diff --git a/security/commoncap.c b/security/commoncap.c

index 4e9ff02..24de4fa 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -290,7 +290,11 @@ int cap_bprm_secureexec (struct linux_binprm *bprm)
 int cap_inode_setxattr(struct dentry *dentry, char *name, void *value,
   size_t size, int flags)
 {
-   if (!strncmp(name, XATTR_SECURITY_PREFIX,
+   if (!strcmp(name, XATTR_NAME_CAPS)) {
+   if (!capable(CAP_SETFCAP))
+   return -EPERM;
+   return 0;
+   } else if (!strncmp(name, XATTR_SECURITY_PREFIX,
 sizeof(XATTR_SECURITY_PREFIX) - 1)  &&
!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -299,7 +303,11 @@ int cap_inode_setxattr(struct dentry *dentry, char *name, 
void *value,
 
 int cap_inode_removexattr(struct dentry *dentry, char *name)

 {
-   if (!strncmp(name, XATTR_SECURITY_PREFIX,
+   if (!strcmp(name, XATTR_NAME_CAPS)) {
+   if (!capable(CAP_SETFCAP))
+   return -EPERM;
+   return 0;
+   } else if (!strncmp(name, XATTR_SECURITY_PREFIX,
 sizeof(XATTR_SECURITY_PREFIX) - 1)  &&
!capable(CAP_SYS_ADMIN))
return -EPERM;



--
Open Source Software Promotion Center, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> Alexandre Oliva writes:

>> Yes, but in the scenario I proposed, the source code *is* in the
>> preferred form for making modifications, it just so happens to be
>> behind a barrier you cannot trespass.  This is not different from
>> shipping binaries and sources in a CD inside a locked box that you
>> can't open.  You've received both, but how is the fact that you can't
>> reach the source code (or the binaries) a violation of the GPL in this
>> case?

> Behind a barrier is not the preferred form for modification.

Where does it state that there must not be a barrier?  I see it saying
the source must accompany the binary, under 3a.  

> Encrypted with a key you don't have is not the preferred form for
> modification.

Indeed, but why does it matter?  In a CD is not the preferred form for
making modifications either.  In fact, in the CD, you can't modify it
at all.  What's *behind* encryption is the source code, along with the
binary it accompanies.

>> And, if it's not a violation, what is it that makes the case of
>> shipping programs in a locked enclosure different from shipping them
>> in a locked computing device?

> I honestly don't see what relevance this could possibly
> have. Getting access to the source is a fundamental GPL right.

That's the spirit.  But where does the *letter* of the GPL state it?

> By this argument, shipping a GPL'd work in ROM would violate the GPL
> because you cannot easily modify that particular copy.

I've already explained that the inability to modify what's in the CD
is not a restriction imposed by whoever recorded the bits in there as
a means to stop you from making modifications.

>> I ought to be entitled to modify any bit in the executable and
>> expect that to have the same effect as modifying that bit on that
>> executable on any other computer.

> Nope, sorry. If this were true, you ought to be entitled to modify a bit in
> the Linux kernel and have it have the same effect as modifying that Linux
> kernel on my desktop.

If your desktop is sufficiently similar, and the kernel binaries are
identical, why should I not expect the same result to arise?

> Again, nonsense view leads to nonsense conclusions.  The fix is to
> reject the nonsense view. There are no special GPL rights to
> particular copies of works or particular hardware.

  2. You may modify your copy or copies of the Program or any portion
 of it  ^^

>> The fact that it stops
>> working as a result of TiVo's design to prohibit modification, rather
>> than by any other differences in the computer (e.g., the absence of
>> the signature checks), just goes to show that there is intent to
>> impose further restrictions on modification of the software.

> Intent is not the issue.

Imposing further restrictions is the issue.

> If modifying software in this way is a GPL right, then anything that
> prevents you from modifying software in this way is a GPL violation.

If it is imposed by the licensee, yes, it is indeed.

> If you can't distribute so as to give all GPL rights, you can't
> distribute at all.

Exactly.

> If the GPL says I can modify my distributed copy, then distributing
> on CDROM is a GPL violation.

It doesn't state "you must distribute sources in modifyable media", it
says "you may modify your copies, and the distributor must not have
imposed restrictions on your exercise of this right"

If you can't modify your copies because others get in the way, too
bad.  If you can't just because the distributor stops you, there's a
GPL violation.

> It is mind-bogglingly obvious that any sort of "right to modify one
> particular copy" is *not* a GPL right.

Please read the license instead of assuming you know what it says.
You clearly don't.  See above.

> You are wasting an awful lot of time and effort analyzing things that have
> *NO* GPL consequence at all.

Let's just say I honestly hope you are right and I'm wrong.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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: [BUG] long freezes on thinkpad t60

[Linus Torvalds]

On Wed, 27 Jun 2007, Davide Libenzi wrote:

> On Wed, 27 Jun 2007, Linus Torvalds wrote:
> > 
> > Stores never "leak up". They only ever leak down (ie past subsequent loads 
> > or stores), so you don't need to worry about them. That's actually already 
> > documented (although not in those terms), and if it wasn't true, then we 
> > couldn't do the spin unlock with just a regular store anyway.
> 
> Yes, Intel has never done that. They'll probably never do it since it'll 
> break a lot of system software (unless they use a new mode-bit that 
> allows system software to enable lose-ordering). Although I clearly 
> remember to have read in one of their P4 optimization manuals to not 
> assume this in the future.

That optimization manual was confused. 

The Intel memory ordering documentation *clearly* states that only reads 
pass writes, not the other way around.

Some very confused people have thought that "pass" is a two-way thing. 
It's not. "Passing" in the Intel memory ordering means "go _ahead_ of", 
exactly the same way it means in traffic. You don't "pass" people by 
falling behind them.

It's also obvious from reading the manual, because any other reading would 
be very strange: it says

 1. Reads can be carried out speculatively and in any order

 2. Reads can pass buffered writes, but the processor is self-consistent

 3. Writes to memory are always carried out in program order [.. and then 
lists exceptions that are not interesting - it's clflush and the 
non-temporal stores, not any normal writes ]

 4. Writes can be buffered

 5. Writes are not performed speculatively; they are only performed for 
instructions that have actually been retired.

 6. Data from buffered writes can be forwarded to waiting reads within the 
processor.

 7. Reads or writes cannot pass (be carried out ahead of) I/O 
instructions, locked instructions or serializing instructions.

 8. Reads cannot pass LFENCE and MFENCE instructions.

 9. Writes cannot pass SFENCE or MFENCE instructions.

The thing to note is:

 a) in (1), Intel says that reads can occur in any order, but (2) makes it 
clear that that is only relevant wrt other _reads_

 b) in (2), they say "pass", but then they actually explain that "pass" 
means "be carried out ahead of" in (7). 

HOWEVER, it should be obvious in (2) even _without_ the explicit 
clarification in (7) that "pass" is a one-way thing, because otherwise 
(2) is totally _meaningless_. It would be meaningless for two reasons:

 - (1) already said that reads can be done in any order, so if that 
   was a "any order wrt writes", then (2) would be pointless. So (2) 
   must mean something *else* than "any order", and the only sane 
   reading of it that isn't "any order" is that "pass" is a one-way 
   thing: you pass somebody when you go ahead of them, you do *not* 
   pass somebody when you fall behind them!

 - if (2) really meant that reads and writes can just be re-ordered, 
   then the choice of words makes no sense. It would be much more 
   sensible to say that "reads can be carried out in any order wrt 
   writes", instead of talking explicitly about "passing buffered 
   writes"

Anyway, I'm pretty damn sure my reading is correct. And no, it's not a "it 
happens to work". It's _architecturally_required_ to work, and nobody has 
ever complained about the use of a simple store to unlock a spinlock 
(which would only work if the "reads can pass" only means "*later* reads 
can pass *earlier* writes").

And it turns out that I think #1 is going away. Yes, the uarch will 
internally re-order reads, wrt each other, but if it isn't architecturally 
visible, then from an architectural standpoint #1 simply doesn't happen.

I can't guarantee that will happen, of course, but from talking to both 
AMD and Intel people, I think that they'll just document the stricter 
rules as the de-facto rules.

Linus
-
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] RFC: have tcp_recvmsg() check kthread_should_stop() and treat it as if it were signalled

[Satyam Sharma]

Hi Oleg,

On 6/27/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:

On 06/27, Satyam Sharma wrote:
>
> Thanks for your comments, I'm still not convinced, however.

An perhaps you are right. I don't have a very strong opinion on that.
Still I can't understand why it is better if kthread_stop() sends a
signal as well.
[...]
One can always use force_sig() or allow_signal() + send_sig() when
it is really needed, like cifs does.


The way I look at it, this is about an API being the one with "least surprise".
So when one writes a kthread using its API, one would expect
kthread_stop() to dtrt and just work, which it will not, if the kthread has one
of such functions (which are just like any other, after all). Also, imagine
such a function being added to a kthread that didn't have it previously ...
the solution to which (sending a signal before kthread_stop) is un-intuitive.
Hence, why not make it part of the API itself ... It's not like the signal
would do any harm to other kthreads (that don't use such function) either.


Contrary, I believe we should avoid signals when it
comes to kernel threads.


And I agree, but there's quite a subtle difference between signals being
used like they normally are, and this case here. Fact is, there is simply
no other way to break out of certain functions (if there was, I would've
preferred that myself).

In fact, what I'm proposing is that kthreads should *not* be tinkering
with (flushing, handling, dequeueing, whatever) signals at all, because
like you mentioned, if they do that, it's possible that the TIF_SIGPENDING
could get lost.


> Anyway, I think _all_ usages of kthread_stop() in the kernel *do* want
> the thread to stop *right then*. After all, kthread_stop() doesn't even
> return (gets blocked on wait_for_completion()) till it knows the target
> kthread *has* exited completely.

Yes, kthread_stop(k) means that k should exit eventually, but I don't
think that kthread_stop() should try to force the exit.


Well, it's just an additional notice (apart from setting kthread_stop_info)
sent to the target kthread that its time has come ... I'm not sure how a
kthread would have exit "forced" upon it just by sending it a signal.
Also, note that _not_ using a signal would in fact mean that the kthread
_never_ exits at all (forget asap).


I am talking about the case
when wait_event_interruptible() should not fail (unless something bad
happens) inside the "while (!kthread_should_stop())" loop.
Note also that kthread could use TASK_INTERRUPTIBLE sleep
[...] and because it knows that all signals are ignored.


Ok, I think you're saying that if a kthread used wait_event_interruptible
(and was not expecting signals, because it ignores them), then bad
things (say exit in inconsistent state, etc) will happen if we break that
wait_event_interruptible unexpectedly.

First, such an error ought to be handled gracefully by kthread itself
anyway -- anybody who doesn't check the return of _interruptible()
functions is just asking for trouble.

Second, the kthread must expect that the stop notification _could_
have come during that sleep (in fact all good kthreads I've seen do
always put a kthread_should_stop() after all such blocking functions,
and not only in the while loop's condition) -- but even if it doesn't check
explicitly, what do we lose? If the kthread code _after_ the
wait_event_interruptible is written such that it assumes that the wait
condition has become true (as I mentioned above), then that code is
inherently buggy.

And thirdly, what I'm proposing is putting the check for checking the
SIGKILL in kthread_should_stop itself, in /addition/ to the
kthread_stop_info.k == current check. So the kthread will check
should_stop(), and if true, then exiting cleanly -- this is something that
all existing kthreads would do already (if some kthread out there exits
_uncleanly_ even after seeing seeing kthread_should_stop == true,
then it needs fixing anyway).

Satyam
-
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/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.

[David Gibson]

On Wed, Jun 27, 2007 at 04:35:44PM +0800, Zhang Wei wrote:
> Add the explanation and a sample of RapidIO DTS sector to the document of 
> booting-without-of.txt file.
> 
> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> ---
>  Documentation/powerpc/booting-without-of.txt |   34 
> ++
>  1 files changed, 34 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/powerpc/booting-without-of.txt 
> b/Documentation/powerpc/booting-without-of.txt
> index b49ce16..98692ca 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1727,6 +1727,40 @@ platforms are moved over to use the 
> flattened-device-tree model.
>   partition-names = "fs\0firmware";
>   };
>  
> +   k) RapidIO
> +
> +   Required properties:
> +

Should probably recommend a name for the node here, as well.  "srio" I
guess, from the example below.

> +- compatible : Should be "fsl,rapidio-delta" for Freescale
> +  PowerPC RapidIO controller.
> +- #address-cells : Address representation for "rapidio" devices.
> +  This field represents the number of cells needed to represent
> +  the RapidIO address of the registers.  For supporting more than
> +  32-bits RapidIO address, this field should be <2>.
> +  See 1) above for more details on defining #address-cells.
> +- reg : Offset and length of the register set for the device
> +- ranges : Should be defined as specified in 1) to describe the
> +  translation of addresses for memory mapped RapidIO memory
> +  space.
> +- interrupts : binding interrupts for this device sector,
> +  please follow below orders:
> +   +  msg2_tx_irq msg2_rx_irq ... msgN_tx_irq msgN_rx_irq>.
> +
> +  Example:
> +
> + [EMAIL PROTECTED]
> + compatible = "fsl,rapidio-delta";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = ;
> + ranges = <0 0 c000 2000>;
> + interrupt-parent = <>;
> + /* err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
> +   msg2_tx_irq msg2_rx_irq */
> + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> + };
> +
> More devices will be defined as this spec matures.
>  
>  VII - Specifying interrupt information for devices

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-
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: [AppArmor 00/44] AppArmor security module overview

[David Miller]

From: Casey Schaufler <[EMAIL PROTECTED]>
Date: Wed, 27 Jun 2007 17:27:17 -0700 (PDT)

> --- David Miller <[EMAIL PROTECTED]> wrote:
> 
> > Neither of those are reasons why something should go into the tree.
> 
> They reflect the corporate reality of the open source community.
> If you're going to go down the "open source isn't for money"
> rathole please take it elsewhere. I've heard the arguments so many
> times I can sing them to the tune of "Lady Madonna".

That's a wonderful technical reason for apparmour to go into the tree.
Thanks for sharing and making it even clearer what is really behind
this submission.
-
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: Userspace compiler support of "long long"

[Andi Kleen]

On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote:
> On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> > AFAIR the Intel compiler claims to be gcc.
> >
> > But these are by far not the only C compilers under Linux, and the  
> > more important points are:
> >
> > Is there any userspace Linux compiler that does not support "long  
> > long"?
> 
> Don't know, but I'd guess not.

Tendra C and probably lcc. I would guess tinycc too.

> The only trick is if you care about building 32-bit compat code using  
> 64-bit linux kernel headers.  In that case we should probably just  
> make all archs use "long long" for their 64-bit integers, unless  
> there's some platform I'm not remembering where "long long" is 128- 
> bits or bigger.  The other benefit is that people could then just use  
> the printf format "%llu" for 64-bit integers instead of having to  
> conditionalize it all over the place.
> 
> I'm working on a patch now.

Changing this will give you a zillion warnings for printk formats.

-Andi
 
-
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: [AppArmor 00/44] AppArmor security module overview

[Casey Schaufler]

--- David Miller <[EMAIL PROTECTED]> wrote:

> From: Crispin Cowan <[EMAIL PROTECTED]>
> Date: Wed, 27 Jun 2007 15:46:57 -0700
> 
> > But we do not want to prevent other people from using SELinux if it
> > suits them. Linux is about choice, and that is especially vital in
> > security. As Linus himself observed when LSM was started, there are a
> > lot of security models, they have various strengths and weaknesses, and
> > often are not compatible with each other. That is why it is important
> > that LSM persist, that SELinux not be the only in-tree user of LSM, and
> > why we think AppArmor should be included upstream, so that non-SUSE
> > users can also use AppArmor if it suits them.
> 
> Anyone can apply the apparmour patch to their tree, they get the
> choice that way.  Nobody is currently prevented from using apparmour
> if they want to, any such suggestion is pure rubbish.

The exact same argument was made prior to SELinux going upstream.
Look, if you can't be right, try at least to be original.

> It is even more incredulious to imply that just by having apparmour
> in the upstream kernel all the userland bits will magically appear
> on every user's distribution.

Just like all the SELinux userland magically appeared in everyone's
distribution? Nope, didn't happen.

> Give me a break.

No. You are out of line and spewing ignorance.

> What you get by the code going into the upstream kernel tree is that
> it a) adds some pseudo legitimacy to AppArmour (which I don't
> personally think is warranted) and b) gets the work of keeping
> apparmour working with upstream largely off of your back and in the
> hands of the upstream community.

Duh. Those are pretty much the reasons anyone goes through the
trouble of getting anything upstream.

> Neither of those are reasons why something should go into the tree.

They reflect the corporate reality of the open source community.
If you're going to go down the "open source isn't for money"
rathole please take it elsewhere. I've heard the arguments so many
times I can sing them to the tune of "Lady Madonna".

> Frankly I think AppArmour is a joke,

"SELinux, AppArmor, and Hilary Clinton walk into a bar ..."

> and all of this integration with
> LSM business is just a face saving effort, nothing more.  And saving
> face is not, and has never been, a reason for something to be put into
> the upstream tree.

Believe what you will. Crispin has been working with LSM from the
inception those many years ago. He's been working on getting this
module in for over a year. If you don't like his module go write
your own and put him out of business.


Casey Schaufler
[EMAIL PROTECTED]
-
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 1/1] file capabilities: get_file_caps cleanups

[Serge E. Hallyn]

>From 588755d9498c87c4e963527ba0f49c11107de354 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Wed, 27 Jun 2007 19:55:27 -0400
Subject: [PATCH 1/1] file capabilities: get_file_caps cleanups

Two cleanups relating to set_file caps.

Rename set_file_caps to get_file_caps, since we are getting
the file capabilities, and setting the bprm caps to them.

Move the clearing of bprm caps into get_file_caps, and do it
only when we don't copy them from the capability xattr.

Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
---
 security/commoncap.c |   26 ++
 1 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index 24de4fa..3e3d88c 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -135,21 +135,20 @@ static inline int cap_from_disk(struct vfs_cap_data_disk 
*dcap,
 }
 
 /* Locate any VFS capabilities: */
-static int set_file_caps(struct linux_binprm *bprm)
+static int get_file_caps(struct linux_binprm *bprm)
 {
struct dentry *dentry;
-   int rc;
+   int rc = 0;
struct vfs_cap_data_disk_v1 v1caps;
struct vfs_cap_data_disk *dcaps;
struct inode *inode;
 
dcaps = (struct vfs_cap_data_disk *)
if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID)
-   return 0;
+   goto clear_caps;
 
dentry = dget(bprm->file->f_dentry);
inode = dentry->d_inode;
-   rc = 0;
if (!inode->i_op || !inode->i_op->getxattr)
goto out;
 
@@ -187,12 +186,21 @@ out:
dput(dentry);
if ((void *)dcaps != (void *))
kfree(dcaps);
+clear_caps:
+   if (rc) {
+   cap_clear (bprm->cap_inheritable);
+   cap_clear (bprm->cap_permitted);
+   cap_clear (bprm->cap_effective);
+   }
return rc;
 }
 
 #else
-static inline int set_file_caps(struct linux_binprm *bprm)
+static inline int get_file_caps(struct linux_binprm *bprm)
 {
+   cap_clear (bprm->cap_inheritable);
+   cap_clear (bprm->cap_permitted);
+   cap_clear (bprm->cap_effective);
return 0;
 }
 #endif
@@ -201,13 +209,7 @@ int cap_bprm_set_security (struct linux_binprm *bprm)
 {
int ret;
 
-   /* Copied from fs/exec.c:prepare_binprm. */
-
-   cap_clear (bprm->cap_inheritable);
-   cap_clear (bprm->cap_permitted);
-   cap_clear (bprm->cap_effective);
-
-   ret = set_file_caps(bprm);
+   ret = get_file_caps(bprm);
 
/*  To support inheritance of root-permissions and suid-root
 *  executables under compatibility mode, we raise all three
-- 
1.5.1.1.GIT

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

[Patrick Draper]

Rene Herman wrote:
KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing 
by default for some time now so we're talking history anyway. You want 
mixing on your card? You got it.


I've been following this discussion with some interest, to learn more 
about ALSA. I've been creating startup scripts for all of my sound-using 
applications which look like this:


LD_PRELOAD=libaoss.so exec /usr/bin/alsaplayer "$*"

I found that without libaoss.so preloaded, I wasn't getting software 
mixing at all. I'm constantly running an MP3 player, and with that 
library I can get sound alerts from other apps too.


I don't understand exactly what you mean by ALSA mixing by default. I 
have the OSS Mixer API selected during kernel compiles. Is that what you 
are referring to?


Thanks,

Patrick
-
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 2/3] MAP_NOZERO - implement sys_brk2()

[Davide Libenzi]

On Wed, 27 Jun 2007, Nicholas Miell wrote:

> 1) euid is not sufficient, you need to store away arbitrary LSM
> information and call LSM hooks to decide security equivalence. The same
> applies to VServer or whatever other container system you use.

The EUID that is used now, can easily be any cookie. It can be an LSM 
cookie (if LSM is active in the system). We don't do complex checks, like 
group permission & Co.  We assume that if a UID-cookie had such data 
available (or it generated it), it can have it back uncleared.



> 2) Two processes, A and B, are in separate VFS namespaces but have
> equivalent security identity according to LSM. Process A reads data from
> file F which is not visible in process's B's namespace. You have to
> prevent process B from ever getting a page that once contained data from
> file F.

They have the *same* security identity. It means that at any time such 
security identity can access resources on both VFS (if it is allowed to 
access such resources - according to security rules in place, LSM or not).
Data is either generated by the security identity, or it is faulted in 
(and it means that the security identity had the GO from the security 
provisioning to access such resource).



> 3) mlock() is often used by programs like GPG to prevent decrypted
> secret keys from ever getting swapped out. You need to zero all
> once-mlocked pages before they get reused to prevent that page from
> getting swapped to disk or application bugs from leaking the key.

GPG and other security software do also memclear on top of mlock, to 
prevent such memory staying alive at all. Just for example, you don't want 
in any case that after an munlock you app core and data goes down.



- Davide


-
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] Allow PAGE_OWNER to be set on any architecture

[Andrew Morton]

On Fri, 8 Jun 2007 13:53:49 +0100
[EMAIL PROTECTED] (Mel Gorman) wrote:

> Currently PAGE_OWNER depends on CONFIG_X86. This appears to be due to
> pfn_to_page() being called in an inappropriate for many memory models
> and the presense of memory holes. This patch ensures that pfn_valid()
> and pfn_valid_within() is called at the appropriate places and the offsets
> correctly updated so that PAGE_OWNER is safe on any architecture.
> 
> In situations where CONFIG_HOLES_IN_ZONES is set (IA64 with VIRTUAL_MEM_MAP),
> there may be cases where pages allocated within a MAX_ORDER_NR_PAGES block
> of pages may not be displayed in /proc/page_owner if the hole is at the
> start of the block. Addressing this would be quite complex, perform slowly
> and is of no clear benefit.
> 
> Once PAGE_OWNER is allowed on all architectures, the statistics for grouping
> pages by mobility that declare how many pageblocks contain mixed page types
> becomes optionally available on all arches.
> 
> This patch was tested successfully on x86, x86_64, ppc64 and IA64 machines.

I'm kinda mystified about how you successfully tested this on ppc64 and
ia64.  They don't assemble and execute i386 opcodes?


--- a/mm/page_alloc.c~allow-page_owner-to-be-set-on-any-architecture-fix
+++ a/mm/page_alloc.c
@@ -1498,13 +1498,15 @@ static inline void __stack_trace(struct 
 #endif
 }
 
-static inline void set_page_owner(struct page *page,
-   unsigned int order, unsigned int gfp_mask)
+static void set_page_owner(struct page *page, unsigned int order,
+   unsigned int gfp_mask)
 {
-   unsigned long address, bp;
+   unsigned long address;
+   unsigned long bp = 0;
 #ifdef CONFIG_X86_64
asm ("movq %%rbp, %0" : "=r" (bp) : );
-#else
+#endif
+#ifdef CONFIG_X86_32
asm ("movl %%ebp, %0" : "=r" (bp) : );
 #endif
page->order = (int) order;
_

that'll make it build, but it won't work...
-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[David Schwartz]

Alexandre Oliva writes:

> Yes, but in the scenario I proposed, the source code *is* in the
> preferred form for making modifications, it just so happens to be
> behind a barrier you cannot trespass.  This is not different from
> shipping binaries and sources in a CD inside a locked box that you
> can't open.  You've received both, but how is the fact that you can't
> reach the source code (or the binaries) a violation of the GPL in this
> case?

Behind a barrier is not the preferred form for modification. Encrypted with
a key you don't have is not the preferred form for modification.

> And, if it's not a violation, what is it that makes the case of
> shipping programs in a locked enclosure different from shipping them
> in a locked computing device?

I honestly don't see what relevance this could possibly have. Getting access
to the source is a fundamental GPL right. The GPL is clear that you cannot
burden access to the source.

> When you modify a sculpture, you're modifying it in place, and this
> requires as much copyright permission as creating a modified copy of
> it.  Both count as modification.  And if TiVo creates artificial
> obstacles to your modifying the copy of GPLed programs that ships in
> its devices, then I believe it counts as a restriction on
> modification.

Of course your nonsense view leads to nonsense results. What a surprise. By
this argument, shipping a GPL'd work in ROM would violate the GPL because
you cannot easily modify that particular copy. Burning a GPL'd work to CDROM
would also be a violation. (See below for why your 'artificial' distinction
is wrong.)

> I ought to be entitled to modify any bit in the
> executable and expect that to have the same effect as modifying that
> bit on that executable on any other computer.

Nope, sorry. If this were true, you ought to be entitled to modify a bit in
the Linux kernel and have it have the same effect as modifying that Linux
kernel on my desktop. Again, nonsense view leads to nonsense conclusions.
The fix is to reject the nonsense view. There are no special GPL rights to
particular copies of works or particular hardware.

> The fact that it stops
> working as a result of TiVo's design to prohibit modification, rather
> than by any other differences in the computer (e.g., the absence of
> the signature checks), just goes to show that there is intent to
> impose further restrictions on modification of the software.

Intent is not the issue. The GPL does not care whether you intended to
comply or why you cannot comply, it just cares whether you do or don't
comply. If modifying software in this way is a GPL right, then anything that
prevents you from modifying software in this way is a GPL violation. If you
can't distribute so as to give all GPL rights, you can't distribute at all.

If the GPL says I can modify my distributed copy, then distributing on CDROM
is a GPL violation. It doesn't matter what your intent is. If you can't
distribute so as to honor all GPL rights, you can't distribute.

It is mind-bogglingly obvious that any sort of "right to modify one
particular copy" is *not* a GPL right.

> Saying that I can modify the sources and build another copy of the
> binary and then install that, but then it won't work, but that's fine
> because this is not modifying, while true, does not disqualify the
> claim that TiVo's design imposes artificial restrictions on my
> abilities to modify the copies of the program that I have received.

It doesn't matter. The GPL does not distinguish between artificial
restrictions and other restrictions. It doesn't permit *ANY* further
restrictions on GPL rights. If you can't grant all the rights (whether due
to artificial restrictions or other types of restrictions) you can't
distribute at all.

You are wasting an awful lot of time and effort analyzing things that have
*NO* GPL consequence at all.

DS


-
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: 2.6.22-rcX Transmeta/APM regression

[linux]

> .config and contents of /proc/cpuinfo would be helpful...

Apologies!  I'm still working on the bisection, but...

The following is from 2.6.21-gae1ee11b, which works.

$ cat /tmp/cpuinfo
processor   : 0
vendor_id   : GenuineTMx86
cpu family  : 6
model   : 4
model name  : Transmeta(tm) Crusoe(tm) Processor TM5800
stepping: 3
cpu MHz : 300.000
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr cx8 sep cmov mmx longrun lrti 
constant_tsc
bogomips: 1608.38
clflush size: 32
$ lspci -nn
00:00.0 Host bridge [0600]: Transmeta Corporation LongRun Northbridge 
[1279:0395] (rev 01)
00:00.1 RAM memory [0500]: Transmeta Corporation SDRAM controller [1279:0396]
00:00.2 RAM memory [0500]: Transmeta Corporation BIOS scratchpad [1279:0397]
00:02.0 USB Controller [0c03]: ALi Corporation USB 1.1 Controller [10b9:5237] 
(rev 03)
00:04.0 Multimedia audio controller [0401]: ALi Corporation M5451 PCI AC-Link 
Controller Audio Device [10b9:5451] (rev 01)
00:06.0 Bridge [0680]: ALi Corporation M7101 Power Management Controller [PMU] 
[10b9:7101]
00:07.0 ISA bridge [0601]: ALi Corporation M1533/M1535 PCI to ISA Bridge 
[Aladdin IV/V/V+] [10b9:1533]
00:0c.0 CardBus bridge [0607]: Texas Instruments PCI1410 PC card Cardbus 
Controller [104c:ac50] (rev 01)
00:0f.0 IDE interface [0101]: ALi Corporation M5229 IDE [10b9:5229] (rev c3)
00:12.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)
00:13.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB21 
IEEE-1394a-2000 Controller (PHY/Link) [104c:8026]
00:14.0 VGA compatible controller [0300]: ATI Technologies Inc Rage Mobility 
P/M [1002:4c52] (rev 64)
$ grep ^CONFIG /usr/src/linux/.config
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_IKCONFIG=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_KMOD=y
CONFIG_BLOCK=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_X86_PC=y
CONFIG_MCRUSOE=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_PREEMPT_NONE=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_VM86=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
CONFIG_PAGE_OFFSET=0xC000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ZONE_DMA_FLAG=1
CONFIG_MTRR=y
CONFIG_SECCOMP=y
CONFIG_HZ_100=y
CONFIG_HZ=100
CONFIG_PHYSICAL_START=0x10
CONFIG_PHYSICAL_ALIGN=0x10
CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION="/dev/hda2"
CONFIG_APM=y
CONFIG_APM_CPU_IDLE=y
CONFIG_APM_DISPLAY_BLANK=y
CONFIG_APM_RTC_IS_GMT=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
CONFIG_X86_LONGRUN=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA_DMA_API=y
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_PCCARD_NONSTATIC=y
CONFIG_BINFMT_ELF=y
CONFIG_NET=y

Re: [BUG] long freezes on thinkpad t60

[Davide Libenzi]

On Wed, 27 Jun 2007, Linus Torvalds wrote:

> > IOW shouldn't an mfence always be there? Not only loads could leak up 
> > into the wait phase, but stores too, if they have no dependency with the 
> > "head" and "tail" loads.
> 
> Stores never "leak up". They only ever leak down (ie past subsequent loads 
> or stores), so you don't need to worry about them. That's actually already 
> documented (although not in those terms), and if it wasn't true, then we 
> couldn't do the spin unlock with just a regular store anyway.

Yes, Intel has never done that. They'll probably never do it since it'll 
break a lot of system software (unless they use a new mode-bit that 
allows system software to enable lose-ordering). Although I clearly 
remember to have read in one of their P4 optimization manuals to not 
assume this in the future.



- Davide


-
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] cross-architecture ELF clean up

[Roman Zippel]

Hi,

On Tue, 26 Jun 2007, Jeremy Fitzhardinge wrote:

> > We have the __ASSEMBLY__ define for this, so just for asm code we don't need
> > a separate header.
> >   
> 
> Hm.  The number of __ASSEMBLY__s end up being pretty large, and it just seemed
> cleaner to put them in separate headers.

This could be avoided by reordering things within elf.h, but is it really 
necessary since there is no user of this right now?
Having actual users would help to decide how to deal with this, since e.g. 
if only a few constants were needed this could also be done via 
asm-offsets.h.

> > >   linux/elf-decl.h- ELF type declarations, without definitions
> > >   linux/elf-defn.h- ELF type definitions
> > > 
> > 
> > What's the point in splitting these two?
> >   
> 
> Because there are other headers which just need some type
> forward-declarations, and don't need the whole set of ELF types defined.  In
> particular, linux/module.h - which is included all over the place in the
> kernel - needs a couple of ELF types declared, and including it all over the
> place is just a waste.

module.h does indeed pull in way too much, but instead of hacking headers 
into little pieces, IMO it would be better to solve the real problem.
I played with it a little and the patch below moves a lot stuff out of 
module.h, so this would drastically reduce the header dependencies.
Unless there are major objections, I can test the patch a little more and 
convert the other archs.

bye, Roman

---
 arch/i386/kernel/module.c|   24 +--
 drivers/base/bus.c   |4 
 include/linux/module.h   |  173 ---
 include/linux/moduleloader.h |  212 +-
 include/linux/moduleparam.h  |   22 ---
 include/linux/unwind.h   |4 
 kernel/module.c  |  267 +--
 kernel/params.c  |   13 +-
 scripts/mod/modpost.c|9 -
 9 files changed, 369 insertions(+), 359 deletions(-)

Index: linux-2.6/include/linux/module.h
===
--- linux-2.6.orig/include/linux/module.h
+++ linux-2.6/include/linux/module.h
@@ -44,23 +44,6 @@ struct modversion_info
 
 struct module;
 
-struct module_attribute {
-struct attribute attr;
-ssize_t (*show)(struct module_attribute *, struct module *, char *);
-ssize_t (*store)(struct module_attribute *, struct module *,
-const char *, size_t count);
-   void (*setup)(struct module *, const char *);
-   int (*test)(struct module *);
-   void (*free)(struct module *);
-};
-
-struct module_kobject
-{
-   struct kobject kobj;
-   struct module *mod;
-   struct kobject *drivers_dir;
-};
-
 /* These are either module local, or the kernel's dummy ones. */
 extern int init_module(void);
 extern void cleanup_module(void);
@@ -229,95 +212,13 @@ enum module_state
MODULE_STATE_GOING,
 };
 
-/* Similar stuff for section attributes. */
-struct module_sect_attr
-{
-   struct module_attribute mattr;
-   char *name;
-   unsigned long address;
-};
-
-struct module_sect_attrs
-{
-   struct attribute_group grp;
-   int nsections;
-   struct module_sect_attr attrs[0];
-};
-
-struct module_param_attrs;
-
 struct module
 {
enum module_state state;
 
-   /* Member of list of modules */
-   struct list_head list;
-
/* Unique handle for this module */
char name[MODULE_NAME_LEN];
 
-   /* Sysfs stuff. */
-   struct module_kobject mkobj;
-   struct module_param_attrs *param_attrs;
-   struct module_attribute *modinfo_attrs;
-   const char *version;
-   const char *srcversion;
-   struct kobject *holders_dir;
-
-   /* Exported symbols */
-   const struct kernel_symbol *syms;
-   unsigned int num_syms;
-   const unsigned long *crcs;
-
-   /* GPL-only exported symbols. */
-   const struct kernel_symbol *gpl_syms;
-   unsigned int num_gpl_syms;
-   const unsigned long *gpl_crcs;
-
-   /* unused exported symbols. */
-   const struct kernel_symbol *unused_syms;
-   unsigned int num_unused_syms;
-   const unsigned long *unused_crcs;
-   /* GPL-only, unused exported symbols. */
-   const struct kernel_symbol *unused_gpl_syms;
-   unsigned int num_unused_gpl_syms;
-   const unsigned long *unused_gpl_crcs;
-
-   /* symbols that will be GPL-only in the near future. */
-   const struct kernel_symbol *gpl_future_syms;
-   unsigned int num_gpl_future_syms;
-   const unsigned long *gpl_future_crcs;
-
-   /* Exception table */
-   unsigned int num_exentries;
-   const struct exception_table_entry *extable;
-
-   /* Startup function. */
-   int (*init)(void);
-
-   /* If this is non-NULL, vfree after init() returns */
-   void *module_init;
-
-   /* Here is the actual code + data, vfree'd on unload. 

Re: Userspace compiler support of "long long"

[Randy Dunlap]

On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:

> On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote:
> 
> > On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> > > AFAIR the Intel compiler claims to be gcc.
> > >
> > > But these are by far not the only C compilers under Linux, and the  
> > > more important points are:
> > >
> > > Is there any userspace Linux compiler that does not support "long  
> > > long"?
> > 
> > Don't know, but I'd guess not.
> > 
> > 
> > > If yes, is there any other way to tell that something is a 64bit  
> > > int on 32bit architectures?
> > 
> > Not that I know of.  Probably the straight #else conditional is OK.   
> > We should also merge up the types since *EVERY* linux architecture  
> > has these same types:
> > 
> > typedef   signed char  __s8;
> > typedef unsigned char  __u8;
> > typedef   signed short __s16;
> > typedef unsigned short __u16;
> > typedef   signed int   __s32;
> > typedef unsigned int   __u32;
> > 
> > Then all 64-bit archs have:
> > typedef   signed long  __s64;
> > typedef unsigned long  __u64;
> > 
> > While all 32-bit archs have:
> > typedef   signed long long __s64;
> > typedef unsigned long long __u64;
> > 
> > The only trick is if you care about building 32-bit compat code using  
> > 64-bit linux kernel headers.  In that case we should probably just  
> > make all archs use "long long" for their 64-bit integers, unless  
> > there's some platform I'm not remembering where "long long" is 128- 
> > bits or bigger.  The other benefit is that people could then just use  
> > the printf format "%llu" for 64-bit integers instead of having to  
> > conditionalize it all over the place.
> > 
> > I'm working on a patch now.
> 
> LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> Same for "ppc" (don't know which power* arch. they mean by that).

Hm, I suppose that table only applies to userspace, not kernel...

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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 ?

[Rene Herman]

On 06/27/2007 09:10 PM, Andreas Hartmetz wrote:


I don't like random applications blocking my sound card.


So don't use random applications.


I imitated the style of the mail I replied to. Besides, choosing apps
based on sound system is retarded if you wanted to indicate that this
should be done more often or something.


What I indicated was that if someone wants to use multiple applications that 
work together bringing you The One Integrated Sound Experience it might make 
sense to use applications... that work together. Don't go blame ALSA for 
either the fact that aRTs isn't actually useful nor KDE's decision to stick 
with it for way too long. See -- the problem is again not ALSA (or OSS for 
that matter) but userspace not getting its act together.


KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing by 
default for some time now so we're talking history anyway. You want mixing 
on your card? You got it.


Many don't -- they might not care about desktop sounds period and/or they 
might use a clumsy chip/card for that and use a nice one for music without 
any need for mixing on it (such as I do). Admittedly, mixing Abba's Dancing 
Queen with Slayer's Angel of Death is great fun for quite a while but at 
some point you do actually grow weary of it...



Exactly! And the config file is hostile if you want to change it.


It could be a bit nicer yes. Since software mixing is enabled by default now 
no configuration is generally needed though and it seems not a particularly 
huge priority. Now that it's an advanced feature, maybe the flexibility pays 
off in fact -- not sure, I don't use any configuration myself other than for 
some testing and playing around every once in a while.



KDE 2 *was* released in 2000. Why would you care, I already admitted that
sound daemons were there before ALSA.


Because blaming ALSA for bad decisions made by others seems a little off and 
you did exactly that a few messages back. Not nice!



You give up reporting small hardware problems that bother you because the
application developer documentation for something is not in great shape?


Yep, because I was frustrated with the whole thing. Having huge bad APIs
with no documentation is telling your fellow developers to piss off and
do something else. I did.


You weren't having a developer problem but a user problem. Your problem was 
not with the API documentation but with what would appear to be a simple 
glitch in one particular driver. Mixing that in with a "ALSA sucks because 
its documentation isn't upto par" is a little disingenious.


Sure the (library) documentation blows donkeys. So wat else's is new in the 
land of Linux? I recently did a block-ish driver. Documentation? Whahahaha!


So that leaves that "bad" that you prefixed API with but keep in mind that 
ALSA is designed as an audio system suitable for advanced/professional use 
while also still filling the needs of consumer users and that it does in 
fact do so is obvious from the fact that everyone's using it. A complex API 
is the downside of flexibility. Perhaps it would've been better if alsa-lib 
had also made a very simple API available to non-demanding users from the 
start but other software can do that as well.


For my current purposes libao does, but I hope in the future something like 
Phonon does. The ideal situation is that anyone in userspace is using a 
single API _such_ as Phonon since userspace has to synchronise things itself 
as well -- it might for example want to provide you with the option to 
automatically mute your music when you get an incoming call and this is not 
something which alsa-lib can do by itself.


If it looks like I'm shifting blame -- you bet I am. It's userspace which 
has for years failed to get its multimedia act together, with KDE and GNOME 
going out of their way to pick other infrastructure than the other one. The 
kernel is not a guilty party and improvements should be sought where the 
problems lie.


As said earlier, KDE4 might just be such an improvement. Personally I'm 
hoping I'll even manage to start running it this time because damnit, I miss 
solitaire...



hacking (i.e. more features faster). Latency is an issue? - Well you
can't play sound without userspace creating it so you're not adding any
new problems.


Capture.

If you are not doing DMA from the sound card to kernel memory and then 
directly to disk blocks, you are using user space apps period. So what's 
different with capture?


The latency in this case is defined as the time between data arriving at the 
machine from the outside and it being available for further processing by an 
application. Think looping stuff out again in realtime after doing something 
to it to see why you want it to be low. If you'll grant that all those users 
who were dissatisfied with early 2.6 weren't just blowing smoke, I assume 
you'll grant that latency matters and that putting it all in userspace is 
not an obvious step in minimising 

announcing collectl - a new performance monitoring tool

[Mark Seger]

Just a quick plug for a utility I wrote a number of years ago and have 
recently open sourced.  It's been around as an internal tool for about 4 
years and so has been pretty well shaken out.  There's a pretty good 
description and some example output at 
http://collectl.sourceforge.net/index.html and you can download it at 
http://sourceforge.net/projects/collectl.


What I believe makes this tool different from the already large number 
of 'stat' and other performance monitoring tools is its goal is to be a 
one-stop place for everything and it can collect data on most system 
counters as well as non-standard things such as lustre, infiniband, 
quadrics to name a few.  The data of your choice (the default is cpu, 
disk and network) is displayed horizontally for easy reading, one line 
per sample, which is only limited by how wide you want to make your 
window.  You can display summaries, such as aggregate cpu, disk, 
network, slabs or even lustre traffic OR you can report detail level 
data such as individual NIC traffic, disks, cpus and in the case of 
lustre individual OSTs!  How about only reporting those slabs that 
changed in size between polling intervals?  Or how about seeing nfsstat 
output on a single line!  You can even choose fractional polling 
intervals.  Did you know network stats are only updated once a second?  
Run collectl with a 0.1 second polling interval and see for yourself!


Another biggie is collectl can generate data in 'space separated' format 
so that you can easily plot it using gnuplot, openoffice or if you're of 
that persuasion you can even use excel.


And the best news of all, collectl is very light-weight, using about 
0.03% of the cpu on my amd/xeon boxes.  Naturally your mileage may vary 
depending how many processes or devices may be on your system, but we 
run it continuously on most of our systems and don't even know it's there.


There's far too much to say about it so I won't try.  Install it, read 
the FAQ and check out the 'extended help' and all the man pages - yes, 
there are multiple ones.


Feel free to download it and let me know what you think.  Just be aware 
I'm getting ready to release a new version so if you like what you see 
check back in a day or so and get a newer version.


-mark


-
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: Please release a stable kernel Linux 3.0

[Al Viro]

On Thu, Jun 28, 2007 at 01:32:23AM +0300, Al Boldi wrote:
> > > You are effectively inhibiting the development of an out-of-tree GPL
> > > module pool, by constantly pulling the rug under that community.
> >
> > The same thing happens with any yet-to-be-merged code.
> >
> > > Do you think this is fair?
> >
> > Yes, it is fair.  Decision to maintain your code out of tree indefinitely
> > is your decision.
> 
> It's not my decision, it's the kernel maintainers decision to reject 
> inclusion for one reason or another.  One reason could be a simple "we don't 
> think this is useful".
 
"I maintain a patch to $PROGRAM; maintainers of $PROGRAM don't think it's
useful; they should abstain from making changes that might require rewrite
of that patch".  Would you argue that this is fair?

BTW, "if it's GPLed, it's entitled to any internal function" is a shell game;
it tries to convert GPL-given right to get to those functions into some kind
of promise that those functions won't be changed.

EXPORT_SYMBOL_GPL() should've been EXPORT_SYMBOL_INTERNAL(); like it or not,
in-tree code *is* in different position exactly because it can be modified
by whoever makes a change affecting such code.  For in-tree module one
can expect such modifications to be done; for out-of-tree the same is
obviously not true, but conclusion is not "you can't do changes", it's
"authors of out-of-tree module get to do such modifications themselves".

Sure, there are subsets of exports that have stronger promise of not being
changed often; if a set of functions makes sense as an interface, it's
less likely to change than randomly selected function that just had an
export slapped on it at some point.  The promise is not absolute and it's
not based on some obligations to out-of-tree modules; it's simply a common
sense.

Again, most of the exports had been added with very little justification
at request of out-of-tree module authors.  That pile is many years past
the stage when it could be described as set of sane interfaces and it's
your [collective] fault.  Don't expect sympathy when you find the resulting
devalvation unpleasant to deal with...
-
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: mm snapshot broken-out-2007-06-27-03-28.tar.gz uploaded

[Andrew Morton]

On Thu, 28 Jun 2007 00:57:07 +0200
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:

> Hello,
> 
>   Build problems on iMac G3.
> 
> 1) allnoconfig results in this:
> 
>  CC  arch/powerpc/mm/tlb_32.o
> In file included from include/asm/tlb.h:60,
>  from arch/powerpc/mm/tlb_32.c:30:
> include/asm-generic/tlb.h: In function 'tlb_flush_mmu':
> include/asm-generic/tlb.h:76: error: implicit declaration of function 
> 'release_pages'
> include/asm-generic/tlb.h: In function 'tlb_remove_page':
> include/asm-generic/tlb.h:105: error: implicit declaration of function 
> 'page_cache_release'
> make[1]: *** [arch/powerpc/mm/tlb_32.o] Blad 1
> make: *** [arch/powerpc/mm] Blad 2
> 
> 
> The patch below fixes that for me.
> 
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
> 
>  arch/powerpc/mm/tlb_32.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> --- linux-2.6.22-rc6-bo-a/arch/powerpc/mm/tlb_32.c2007-06-27 
> 23:38:49.0 +0200
> +++ linux-2.6.22-rc6-bo-b/arch/powerpc/mm/tlb_32.c2007-06-27 
> 23:18:05.0 +0200
> @@ -26,6 +26,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
>  #include 
>  #include 

OK.
  
> 
> 
> 2) These are conflicts introduced by 
> kernel-sys_nic-should-include-linux-syscallsh.patch
> 
>   CC  kernel/sys_ni.o
> kernel/sys_ni.c:16: error: conflicting types for 'sys_nfsservctl'
> include/linux/syscalls.h:497: error: previous declaration of 'sys_nfsservctl' 
> was here
> kernel/sys_ni.c:17: error: conflicting types for 'sys_quotactl'

erk, I suspect that's unfixable, or not worth fixing.
-
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/

[RFC] LVM/RAID/FS integration

[Kent Overstreet]

I believe I have the right way of going about it. I agree with the
kernel developers who've stated that ZFS is a layering violation, and
we can do better.

Consider a filesystem on a set of drives; it may want some data to be
in a raid5 and some to be mirrored. The correct interface for the
filesystem is to have two or more opaque volumes, which it may be able
to resize depending on usage.

Basically, the order we want is fs -> raid -> lvm. Given a set of
identical drives, we want LVM to handle them separately and divide
them up into LVs identically; then corresponding LVs are raided
together. We might have a raid5 volume and a raid1 volume, each of
which can be resized independently. The FS then makes use of both of
them, putting metadata and frequently used data on the raid1 and
everything else on the raid5 (btrfs, as I understand it, will be able
to do this sort of thing eventually).

The trouble is it's completely impractical with current tools; we need
tighter integration between md and LVM. Basically, we need a new type
of VG; you'd only be able to make it out of PVs that are the same size
(or close). Then, when you create an LV you decide what kind of
redundancy you want; the LVM internally creates multiple LVs and raids
them together to make the LV the fs sees.

This could, sort of, be done in userspace, but I think it'll work
better if dm and md are better integrated in the kernel. I thought i'd
throw out my ideas before I get too far in. Thoughts?
-
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 Kernel include files

[Arjan van de Ven]

> @Jörg: The responsibility to maintain clean headers shifted only recently,

yes.. from distro to the kernel ;)

in the old case it was always a distro bug...

> and there is possibly still a lot to do. If you can point out errors, they
> can and probably will be fixed. But as you know, having a precise error
> message or description does help.

absolutely. if you find issues with the "real" kernel headers (eg the
make headers_install ones) ... as you have seen there's lots of interest
to make sure they're as useful as reasonably possible


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:

> GPLv2 section 3.
> The source code for a work means the preferred form of the work for
> making modifications to it.

> I believe this states that the source code has to be in the preferred
> form for making modifications and not some other form that sucks rocks.

Yes, but in the scenario I proposed, the source code *is* in the
preferred form for making modifications, it just so happens to be
behind a barrier you cannot trespass.  This is not different from
shipping binaries and sources in a CD inside a locked box that you
can't open.  You've received both, but how is the fact that you can't
reach the source code (or the binaries) a violation of the GPL in this
case?

And, if it's not a violation, what is it that makes the case of
shipping programs in a locked enclosure different from shipping them
in a locked computing device?


As for making modifications, I'd like to take this opportunity to
withdraw, for purposes of interpretation, my earlier agreement that
TiVo permits modification, even though it doesn't permit modification
in place.  I don't see any distinction in US copyright law between
modification in place and modification by creating a separate work.
This distinction makes sense for some cases of modification of
software, but it doesn't make sense for other copyrightable works,
such as sculptures, paintings, drawings, etc.

When you modify a sculpture, you're modifying it in place, and this
requires as much copyright permission as creating a modified copy of
it.  Both count as modification.  And if TiVo creates artificial
obstacles to your modifying the copy of GPLed programs that ships in
its devices, then I believe it counts as a restriction on
modification.  I ought to be entitled to modify any bit in the
executable and expect that to have the same effect as modifying that
bit on that executable on any other computer.  The fact that it stops
working as a result of TiVo's design to prohibit modification, rather
than by any other differences in the computer (e.g., the absence of
the signature checks), just goes to show that there is intent to
impose further restrictions on modification of the software.

Saying that I can modify the sources and build another copy of the
binary and then install that, but then it won't work, but that's fine
because this is not modifying, while true, does not disqualify the
claim that TiVo's design imposes artificial restrictions on my
abilities to modify the copies of the program that I have received.



> And yes, I do realize that you intentionally tried to come up with your
> example to somehow bring tivoization to the source code.

Actually, I first came up with this example long before GPLv3dd3 was
published, and I know there have been changes to the draft in response
to it.

Here are variations of another scenario I proposed back then:

- Tivoizing device ships with tivoized software, regardless of whether
the corresponding sources are accessible to the end user or hidden
inside the box, in a fully-encrypted disk that only that machine can
read.

- The software that ships is feature-limited.  It's just barely enough
to enable the device to connect to the network and download
feature-complete software.

- Network authenticates the device with help of the built-in crypto
device, and device requests feature-complete binaries in encrypted
network sessions.  It's in the fature-complete binaries that the most
valuable improvements made by the tivoizer are, that they don't want
to share with anyone else.  Sources *are* available behind the same
authentication machinery you don't can't get past.  Whether the device
chooses to download them into the encrypted device you can't get to,
to dispose of them right away or even leave them around, or it simply
refrains from downloading the sources because it doesn't need them,
the end result is the same: you've received the sources over the
network, but you can't get to them.

- Updates to the feature-complete software can be delivered over the
same secure channel, and, as a result, derived versions of your
software are distributed to third parties in ways that neither you nor
the recipient can get to the sources.


Here's another variation:

- Vendor distributes device with feature-limited software in the
fully-encrypted disk, with just enough software to download sources
from the network, build the feature-complete software from sources,
and install it.

- Sources are behind network authentication, as above, so although
your device receives them, you can't get to them because they're in
the encrypted disk.


Does it seem to you that GPLv2 blocks any of these means to distribute
your code without granting its users access to the source code?

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL 

Re: [AppArmor 00/44] AppArmor security module overview

[David Miller]

From: Crispin Cowan <[EMAIL PROTECTED]>
Date: Wed, 27 Jun 2007 15:46:57 -0700

> But we do not want to prevent other people from using SELinux if it
> suits them. Linux is about choice, and that is especially vital in
> security. As Linus himself observed when LSM was started, there are a
> lot of security models, they have various strengths and weaknesses, and
> often are not compatible with each other. That is why it is important
> that LSM persist, that SELinux not be the only in-tree user of LSM, and
> why we think AppArmor should be included upstream, so that non-SUSE
> users can also use AppArmor if it suits them.

Anyone can apply the apparmour patch to their tree, they get the
choice that way.  Nobody is currently prevented from using apparmour
if they want to, any such suggestion is pure rubbish.

It is even more incredulious to imply that just by having apparmour
in the upstream kernel all the userland bits will magically appear
on every user's distribution.

Give me a break.

What you get by the code going into the upstream kernel tree is that
it a) adds some pseudo legitimacy to AppArmour (which I don't
personally think is warranted) and b) gets the work of keeping
apparmour working with upstream largely off of your back and in the
hands of the upstream community.

Neither of those are reasons why something should go into the tree.

Frankly I think AppArmour is a joke, and all of this integration with
LSM business is just a face saving effort, nothing more.  And saving
face is not, and has never been, a reason for something to be put into
the upstream tree.

-
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: Userspace compiler support of "long long"

[Randy Dunlap]

On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote:

> On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> > AFAIR the Intel compiler claims to be gcc.
> >
> > But these are by far not the only C compilers under Linux, and the  
> > more important points are:
> >
> > Is there any userspace Linux compiler that does not support "long  
> > long"?
> 
> Don't know, but I'd guess not.
> 
> 
> > If yes, is there any other way to tell that something is a 64bit  
> > int on 32bit architectures?
> 
> Not that I know of.  Probably the straight #else conditional is OK.   
> We should also merge up the types since *EVERY* linux architecture  
> has these same types:
> 
> typedef   signed char  __s8;
> typedef unsigned char  __u8;
> typedef   signed short __s16;
> typedef unsigned short __u16;
> typedef   signed int   __s32;
> typedef unsigned int   __u32;
> 
> Then all 64-bit archs have:
> typedef   signed long  __s64;
> typedef unsigned long  __u64;
> 
> While all 32-bit archs have:
> typedef   signed long long __s64;
> typedef unsigned long long __u64;
> 
> The only trick is if you care about building 32-bit compat code using  
> 64-bit linux kernel headers.  In that case we should probably just  
> make all archs use "long long" for their 64-bit integers, unless  
> there's some platform I'm not remembering where "long long" is 128- 
> bits or bigger.  The other benefit is that people could then just use  
> the printf format "%llu" for 64-bit integers instead of having to  
> conditionalize it all over the place.
> 
> I'm working on a patch now.

LDD3 ch. 11 says that long on Sparc64 is 32 bits.
Same for "ppc" (don't know which power* arch. they mean by that).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: mm snapshot broken-out-2007-06-27-03-28.tar.gz uploaded

[Mariusz Kozlowski]

Hello,

Build problems on iMac G3.

1) allnoconfig results in this:

 CC  arch/powerpc/mm/tlb_32.o
In file included from include/asm/tlb.h:60,
 from arch/powerpc/mm/tlb_32.c:30:
include/asm-generic/tlb.h: In function 'tlb_flush_mmu':
include/asm-generic/tlb.h:76: error: implicit declaration of function 
'release_pages'
include/asm-generic/tlb.h: In function 'tlb_remove_page':
include/asm-generic/tlb.h:105: error: implicit declaration of function 
'page_cache_release'
make[1]: *** [arch/powerpc/mm/tlb_32.o] Blad 1
make: *** [arch/powerpc/mm] Blad 2


The patch below fixes that for me.

Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>

 arch/powerpc/mm/tlb_32.c |2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.22-rc6-bo-a/arch/powerpc/mm/tlb_32.c  2007-06-27 
23:38:49.0 +0200
+++ linux-2.6.22-rc6-bo-b/arch/powerpc/mm/tlb_32.c  2007-06-27 
23:18:05.0 +0200
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 


2) These are conflicts introduced by 
kernel-sys_nic-should-include-linux-syscallsh.patch

  CC  kernel/sys_ni.o
kernel/sys_ni.c:16: error: conflicting types for 'sys_nfsservctl'
include/linux/syscalls.h:497: error: previous declaration of 'sys_nfsservctl' 
was here
kernel/sys_ni.c:17: error: conflicting types for 'sys_quotactl'
include/linux/syscalls.h:396: error: previous declaration of 'sys_quotactl' was 
here
kernel/sys_ni.c:18: error: conflicting types for 'sys_acct'
include/linux/syscalls.h:107: error: previous declaration of 'sys_acct' was here
kernel/sys_ni.c:19: error: conflicting types for 'sys_lookup_dcookie'
include/linux/syscalls.h:394: error: previous declaration of 
'sys_lookup_dcookie' was here
kernel/sys_ni.c:20: error: conflicting types for 'sys_swapon'
include/linux/syscalls.h:489: error: previous declaration of 'sys_swapon' was 
here
kernel/sys_ni.c:21: error: conflicting types for 'sys_swapoff'
include/linux/syscalls.h:490: error: previous declaration of 'sys_swapoff' was 
here
kernel/sys_ni.c:22: error: conflicting types for 'sys_kexec_load'
include/linux/syscalls.h:167: error: previous declaration of 'sys_kexec_load' 
was here
kernel/sys_ni.c:24: error: conflicting types for 'sys_init_module'
include/linux/syscalls.h:183: error: previous declaration of 'sys_init_module' 
was here
kernel/sys_ni.c:25: error: conflicting types for 'sys_delete_module'
include/linux/syscalls.h:185: error: previous declaration of 
'sys_delete_module' was here
kernel/sys_ni.c:26: error: conflicting types for 'sys_socketpair'
include/linux/syscalls.h:422: error: previous declaration of 'sys_socketpair' 
was here
kernel/sys_ni.c:27: error: conflicting types for 'sys_bind'
include/linux/syscalls.h:408: error: previous declaration of 'sys_bind' was here
kernel/sys_ni.c:28: error: conflicting types for 'sys_listen'
include/linux/syscalls.h:424: error: previous declaration of 'sys_listen' was 
here
kernel/sys_ni.c:29: error: conflicting types for 'sys_accept'
include/linux/syscalls.h:410: error: previous declaration of 'sys_accept' was 
here
kernel/sys_ni.c:30: error: conflicting types for 'sys_connect'
include/linux/syscalls.h:409: error: previous declaration of 'sys_connect' was 
here
kernel/sys_ni.c:31: error: conflicting types for 'sys_getsockname'
include/linux/syscalls.h:411: error: previous declaration of 'sys_getsockname' 
was here
kernel/sys_ni.c:32: error: conflicting types for 'sys_getpeername'
include/linux/syscalls.h:412: error: previous declaration of 'sys_getpeername' 
was here
kernel/sys_ni.c:33: error: conflicting types for 'sys_sendto'
include/linux/syscalls.h:415: error: previous declaration of 'sys_sendto' was 
here
kernel/sys_ni.c:34: error: conflicting types for 'sys_send'
include/linux/syscalls.h:413: error: previous declaration of 'sys_send' was here
kernel/sys_ni.c:35: error: conflicting types for 'sys_recvfrom'
include/linux/syscalls.h:419: error: previous declaration of 'sys_recvfrom' was 
here
kernel/sys_ni.c:36: error: conflicting types for 'sys_recv'
include/linux/syscalls.h:417: error: previous declaration of 'sys_recv' was here
kernel/sys_ni.c:37: error: conflicting types for 'sys_socket'
include/linux/syscalls.h:421: error: previous declaration of 'sys_socket' was 
here
kernel/sys_ni.c:38: error: conflicting types for 'sys_setsockopt'
include/linux/syscalls.h:405: error: previous declaration of 'sys_setsockopt' 
was here
kernel/sys_ni.c:39: error: conflicting types for 'sys_getsockopt'
include/linux/syscalls.h:407: error: previous declaration of 'sys_getsockopt' 
was here
kernel/sys_ni.c:40: error: conflicting types for 'sys_shutdown'
include/linux/syscalls.h:161: error: previous declaration of 'sys_shutdown' was 
here
kernel/sys_ni.c:41: error: conflicting types for 'sys_sendmsg'
include/linux/syscalls.h:416: error: previous declaration of 'sys_sendmsg' was 
here
kernel/sys_ni.c:42: error: conflicting types for 'sys_recvmsg'
include/linux/syscalls.h:420: error: previous 

Re: [linux-usb-devel] usb_fill_bulk_urb() broken for USB1.1?

[Keith Chew]

Hi Oliver


You are initialising an interrupt urb with an initializer for
a bulk urb. The behavior is undefined. In older kernels
by random chance a sensible interval was set.

You need to use the correct initializer and the correct interval,
which usually can be read from the device's descriptors.



Thank you very much for all your help. Will correct the code and
report back very soon.

Regards
Keith
-
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: [AppArmor 00/44] AppArmor security module overview

[Crispin Cowan]

Sean wrote:
> On Wed, 27 Jun 2007 14:06:04 -0700
> Crispin Cowan <[EMAIL PROTECTED]> wrote:
>   
>> I am hoping for a reconciliation where the people who don't like
>> AppArmor live with it by not using it. AppArmor is not intended to
>> replace SELinux, it is intended to address a different set of goals.
>> 
> You keep saying that.   But for that to be true you'd have to believe
> _everyone_ using Novell distributions has needs that align exactly
> with AppArmor.  Otherwise, how to explain that you don't offer and
> support both SELinux and AppArmor to your users?
>   
They are meant to co-exist in the Linux kernel source tree.

It is a fact that there exist use cases where AppArmor is incapable of
meeting the need and SELinux is just the right thing. It is Novell's
business judgment that there are not enough of those situations in our
customer base to be worth the additional expense at this time.

But we do not want to prevent other people from using SELinux if it
suits them. Linux is about choice, and that is especially vital in
security. As Linus himself observed when LSM was started, there are a
lot of security models, they have various strengths and weaknesses, and
often are not compatible with each other. That is why it is important
that LSM persist, that SELinux not be the only in-tree user of LSM, and
why we think AppArmor should be included upstream, so that non-SUSE
users can also use AppArmor if it suits them.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor

-
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] LinuxPPS (with new syscalls API)

[Rodolfo Giometti]

On Wed, Jun 27, 2007 at 06:49:48PM +0100, David Woodhouse wrote:
> 
> Looks better. All I can find to complain about is the fact that you
> return whatever copy_from_user() returns. Don't -- that's the number of
> bytes left to copy. It should be if (copy_from_user(..)) return -EFAULT;

Ok, I'll fix it.

Just last question: I still don't well understand where I should
declare the new compat_sys_time_pps_fetch() syscall... it's
automagically defined by the system when CONFIG_COMPAT is enabled? :-o

Thanks for your help,

Rodolfo

-- 

GNU/Linux Solutions  e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
-
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: ZERO_PAGE() vs. loadable modules in Redhat 4.4 i386 kernels ...

[Casey Leedom]

  Nevermind.  I realized I was being an idiot.  Sorry for the wasted bandwidth.

  Basically, if we have a page that get_user_pages() returned to us, the only
way any part of the PGD/PUD/PMD maping hierarchy can be missing is if the page
is the ZERO_PAGE().  Thus I can use this to detect my ZERO_PAGE() failure mode.

  Thanks for your help!

Casey
-
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 Kernel include files

[Bodo Eggert]

Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 18:41 +0200, Joerg Schilling wrote:

>> Well, I did report these kind of problems many years ago and as it has not
>> been fixed after some years, I was asuming that it is still the way I see it
>> on Suse 10.0.
> 
> I'd suggest reporting SuSE bugs to SuSE; that's more effective ;)
> (although I don't know how they will deal with bugreports against older
> versions)
> 
> your bug looks certainly valid.. just you're not using the "proper"
> header set that the kernel developers suggest ;)

Even though you put the smiley there, it does not seem fair to expect people
to know the latest bits of kernel developement and deployment procedures
unless hanging around on lkml is a requirement for linux users. I'm just
browsing that list, filtering and ignoring a lot. If I didn't do that, I
would not even suspect something like make headers_install to exist, nor
would I try to search for it.

@Jörg: The responsibility to maintain clean headers shifted only recently,
and there is possibly still a lot to do. If you can point out errors, they
can and probably will be fixed. But as you know, having a precise error
message or description does help.
-- 
W.I.N.D.O.W.S.:
 Wireless Intelligent Neohuman Designed for Observation and Worldwide Sabotage
-- http://www.brunching.com/toys/toy-cyborger.html (down)
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
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] fsblock

[David Chinner]

On Wed, Jun 27, 2007 at 07:50:56AM -0400, Chris Mason wrote:
> On Wed, Jun 27, 2007 at 07:32:45AM +0200, Nick Piggin wrote:
> > On Tue, Jun 26, 2007 at 08:34:49AM -0400, Chris Mason wrote:
> > > On Tue, Jun 26, 2007 at 07:23:09PM +1000, David Chinner wrote:
> > > > On Tue, Jun 26, 2007 at 01:55:11PM +1000, Nick Piggin wrote:
> > > 
> > > [ ... fsblocks vs extent range mapping ]
> > > 
> > > > iomaps can double as range locks simply because iomaps are
> > > > expressions of ranges within the file.  Seeing as you can only
> > > > access a given range exclusively to modify it, inserting an empty
> > > > mapping into the tree as a range lock gives an effective method of
> > > > allowing safe parallel reads, writes and allocation into the file.
> > > > 
> > > > The fsblocks and the vm page cache interface cannot be used to
> > > > facilitate this because a radix tree is the wrong type of tree to
> > > > store this information in. A sparse, range based tree (e.g. btree)
> > > > is the right way to do this and it matches very well with
> > > > a range based API.
> > > 
> > > I'm really not against the extent based page cache idea, but I kind of
> > > assumed it would be too big a change for this kind of generic setup.  At
> > > any rate, if we'd like to do it, it may be best to ditch the idea of
> > > "attach mapping information to a page", and switch to "lookup mapping
> > > information and range locking for a page".
> > 
> > Well the get_block equivalent API is extent based one now, and I'll
> > look at what is required in making map_fsblock a more generic call
> > that could be used for an extent-based scheme.
> > 
> > An extent based thing IMO really isn't appropriate as the main generic
> > layer here though. If it is really useful and popular, then it could
> > be turned into generic code and sit along side fsblock or underneath
> > fsblock...
> 
> Lets look at a typical example of how IO actually gets done today,
> starting with sys_write():
> 
> sys_write(file, buffer, 1MB)
> for each page:
> prepare_write()
>   allocate contiguous chunks of disk
> attach buffers
> copy_from_user()
> commit_write()
> dirty buffers
> 
> pdflush:
> writepages()
> find pages with contiguous chunks of disk
>   build and submit large bios
> 
> So, we replace prepare_write and commit_write with an extent based api,
> but we keep the dirty each buffer part.  writepages has to turn that
> back into extents (bio sized), and the result is completely full of dark
> dark corner cases.

Yup - I've been on the painful end of those dark corner cases several
times in the last few months.

It's also worth pointing out that mpage_readpages() already works on
an extent basis - it overloads bufferheads to provide a "map_bh" that
can point to a range of blocks in the same state. The code then iterates
the map_bh range a page at a time building bios (i.e. not even using
buffer heads) from that map..

> I do think fsblocks is a nice cleanup on its own, but Dave has a good
> point that it makes sense to look for ways generalize things even more.

*nod*

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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: Please release a stable kernel Linux 3.0

[Al Boldi]

Adrian Bunk wrote:
> On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
> > Al Viro wrote:
> > > On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> > > > And as I understand it, this is (was ?) the whole point of
> > > > stable/development kernels. "We" can trust a newer stable
> > > > kernel to be a drop-in replacement for an older stable
> > > > kernel (from the same series), while development kernels
> > > > need time to stabilise with the new whizz-bang-pfouit stuff
> > > > that you all so nicely add.
> > >
> > > "Drop-in" in which sense?  That out-of-tree modules keep working?
> > > Not really...
> >
> > Al, be reasonable.  There are many out-of-tree GPL modules that won't be
> > accepted into mainline, never mind those that shouldn't be accepted. 
> > But these modules do have a right to not be obsoleted by constant API
> > changes.
>
> "have a right" are strong words.
> Who is granting them this right?

Good-will GPL style.

> > You are effectively inhibiting the development of an out-of-tree GPL
> > module pool, by constantly pulling the rug under that community.
> >
> > Do you think this is fair?
>
> Why are these modules not submitted for inclusion into the kernel?

There are many reasons for this, but basically they are too under-developed 
to be included, and need more time to mature out-of-tree.


Thanks!

--
Al

-
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: Please release a stable kernel Linux 3.0

[Al Boldi]

Al Viro wrote:
> On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
> > Al Viro wrote:
> > > On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> > > > And as I understand it, this is (was ?) the whole point of
> > > > stable/development kernels. "We" can trust a newer stable
> > > > kernel to be a drop-in replacement for an older stable
> > > > kernel (from the same series), while development kernels
> > > > need time to stabilise with the new whizz-bang-pfouit stuff
> > > > that you all so nicely add.
> > >
> > > "Drop-in" in which sense?  That out-of-tree modules keep working?
> > > Not really...
> >
> > Al, be reasonable.  There are many out-of-tree GPL modules that won't be
> > accepted into mainline, never mind those that shouldn't be accepted. 
> > But these modules do have a right to not be obsoleted by constant API
> > changes.
>
> Modules do not have any rights; it's software...

Ok, this should have been read as kernel/module dev/user right to leverage 
each others code under GPL and out of good-will to yield an increased 
harvest.

> > You are effectively inhibiting the development of an out-of-tree GPL
> > module pool, by constantly pulling the rug under that community.
>
> The same thing happens with any yet-to-be-merged code.
>
> > Do you think this is fair?
>
> Yes, it is fair.  Decision to maintain your code out of tree indefinitely
> is your decision.

It's not my decision, it's the kernel maintainers decision to reject 
inclusion for one reason or another.  One reason could be a simple "we don't 
think this is useful".

Also, I think it's unrealistic to expect thousands of little-used modules to 
be included into mainline.

But, should we hinder that community to grow?


Thanks!

--
Al

-
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: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:

AFAIR the Intel compiler claims to be gcc.

But these are by far not the only C compilers under Linux, and the  
more important points are:


Is there any userspace Linux compiler that does not support "long  
long"?


Don't know, but I'd guess not.


If yes, is there any other way to tell that something is a 64bit  
int on 32bit architectures?


Not that I know of.  Probably the straight #else conditional is OK.   
We should also merge up the types since *EVERY* linux architecture  
has these same types:


typedef   signed char  __s8;
typedef unsigned char  __u8;
typedef   signed short __s16;
typedef unsigned short __u16;
typedef   signed int   __s32;
typedef unsigned int   __u32;

Then all 64-bit archs have:
typedef   signed long  __s64;
typedef unsigned long  __u64;

While all 32-bit archs have:
typedef   signed long long __s64;
typedef unsigned long long __u64;

The only trick is if you care about building 32-bit compat code using  
64-bit linux kernel headers.  In that case we should probably just  
make all archs use "long long" for their 64-bit integers, unless  
there's some platform I'm not remembering where "long long" is 128- 
bits or bigger.  The other benefit is that people could then just use  
the printf format "%llu" for 64-bit integers instead of having to  
conditionalize it all over the place.


I'm working on a patch now.

Cheers,
Kyle Moffett

-
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 Kernel include files

[H. Peter Anvin]

Joerg Schilling wrote:


After copying /usr/include/linux/types.h  to
/opt/sunstudio12/prod/include/cc/linux/types.h and removing all 

#if defined(__GNUC__) && !defined(__STRICT_ANSI__) 
...

#endif

stuff, I got cdrtools compiled using "suncc" and I did even get a woring 
cdrecord.




Indeed, this guard is bogus.

-hpa

-
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: 2.6.22-rcX Transmeta/APM regression

[Chuck Ebbert]

On 06/27/2007 11:31 AM, [EMAIL PROTECTED] wrote:
> Hardware: Fujitsu Lifebook P-2040, TM5800 800 MHz processor
> 2.6.21: Closing the lid causes APM suspend.  Opening it resumes just fine.
> 2.6.22-rc5/-rc6: On resume, backlight comes on, but system is otherwise
>   frozen.  Nothing happens until I hold the power button to force
>   a power off.
> 

.config and contents of /proc/cpuinfo would be helpful...
-
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] CodingStyle: Add information about trailing whitespace.

[Jan Engelhardt]

On Jun 27 2007 14:05, Chris Shoemaker wrote:
>
>What I'd really like to see is, _why_ is trailing whitespace
>considered harmful?

Consumes bytes you'll never see :)

>Something about MUAs not preserving it or something?

Well, there is format=flowed. text/plain mails with a trailing blank at the end
of line indicates the paragraph continues -- as a curtesy for mail readers with
non-fixed-font to display the paragraph coherently rather than breaking it at
72/80 columns.


Jan
-- 
-
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] CodingStyle: Add information about trailing whitespace.

[Jan Engelhardt]

On Jun 27 2007 12:31, Andrew Morton wrote:
>
>quilt has ways of detecting and/or correcting newly-added trailing
>whitespace, but I don't know the details.

Upon `quilt ref`, it usually barfs about every line you touched where you
added or kept whitespace at EOL.

>One could share the various scriptlets which detect and fix trailing
>whitespace but I think this issue is getting less and less important
>now, because most maintainers will zap the new whitespace prior to
>merging.
>
>
>But there's less than there used to be.

`| wc -l` it. The patches get larger, the # of patches declines :)


Jan
-- 
-
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: [BUG] long freezes on thinkpad t60

[Linus Torvalds]

On Wed, 27 Jun 2007, Davide Libenzi wrote:
> > 
> > Now, I have good reason to believe that all Intel and AMD CPU's have a 
> > stricter-than-documented memory ordering, and that your spinlock may 
> > actually work perfectly well. But it still worries me. As far as I can 
> > tell, there's a theoretical problem with your spinlock implementation.
> 
> Nice catch ;) But wasn't Intel suggesting in not relying on the old 
> "strict" ordering rules?

Actually, both Intel and AMD engineers have been talking about making the 
documentation _stricter_, rather than looser. They apparently already are 
pretty damn strict, because not being stricter than the docs imply just 
ends up exposing too many potential problems in software that didn't 
really follow the rules.

For example, it's quite possible to do loads out of order, but guarantee 
that the result is 100% equivalent with a totally in-order machine. One 
way you do that is to keep track of the cacheline for any speculative 
loads, and if it gets invalidated before the speculative instruction has 
completed, you just throw the speculation away.

End result: you can do any amount of speculation you damn well please at a 
micro-architectural level, but if the speculation would ever have been 
architecturally _visible_, it never happens!

(Yeah, that is just me in my non-professional capacity of hw engineer 
wanna-be: I'm not saying that that is necessarily what Intel or AMD 
actually ever do, and they may have other approaches entirely).

> IOW shouldn't an mfence always be there? Not only loads could leak up 
> into the wait phase, but stores too, if they have no dependency with the 
> "head" and "tail" loads.

Stores never "leak up". They only ever leak down (ie past subsequent loads 
or stores), so you don't need to worry about them. That's actually already 
documented (although not in those terms), and if it wasn't true, then we 
couldn't do the spin unlock with just a regular store anyway.

(There's basically never any reason to "speculate" stores before other mem 
ops. It's hard, and pointless. Stores you want to just buffer and move as 
_late_ as possible, loads you want to speculate and move as _early_ as 
possible. Anything else doesn't make sense).

So I'm fairly sure that the only thing you really need to worry about in 
this thing is the load-load ordering (the load for the spinlock compare vs 
any loads "inside" the spinlock), and I'm reasonably certain that no 
existing x86 (and likely no future x86) will make load-load reordering 
effects architecturally visible, even if the implementation may do so 
*internally* when it's not possible to see it in the end result.

Linus
-
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 Related With Fork Bombing Attack

[Bodo Eggert]

(not CCing security, since it's not a security bug and it's too late to
 verify if they should be on cc. Will do later.)

Anand Jahagirdar <[EMAIL PROTECTED]> wrote:

> This patch Warns the administrator about the fork bombing attack
> (whenever any user is crossing its process limit). I have used
> printk_ratelimit function in this patch. This function helps to
> prevent flooding of syslog and prints message as per the values set by
> root user in following files:-
> 
> 1) /proc/sys/kernel/printk_ratelimit:- This file contains value for,
> how many times message should be printed in syslog.
[...]

I'm wondering: Can these ratelimits be used to tell real forkbombs from
normal oops-i-hit-the-limits? I imagine if you have your private ratelimit,
that might just do the trick.

Beware: I have no idea on how much such an extra ratelimit would cost, and if
having that ratelimit-based detector would actually be a gain.
-- 
Ever notice how fast Windows runs? Neither did I. 

Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
 [EMAIL PROTECTED] [EMAIL PROTECTED]
-
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 2/3] MAP_NOZERO - implement sys_brk2()

[Nicholas Miell]

On Wed, 2007-06-27 at 11:45 -0700, Davide Libenzi wrote:
> On Wed, 27 Jun 2007, Hugh Dickins wrote:
> 
> > On Wed, 27 Jun 2007, Davide Libenzi wrote:
> > > On Wed, 27 Jun 2007, Hugh Dickins wrote:
> > > 
> > > > In honesty, I should add that I dislike and distrust Davide's
> > > > MAP_NOZERO very much indeed!  Would much rather leave my cpus
> > > > spending a little time in clear_page().  A uid in struct page
> > > > (though I'm sure we could find somewhere to tuck it away) -
> > > > the horror, the horror!  But I've so far failed to find a killer
> > > > argument against it, and am hoping for someone else to do so.
> > > 
> > > Little time? Please, do not trust me. Start oprofile and run a kernel 
> > > build. Look, I'm not even talking about som micro benchmark explicitly 
> > > built to exploit the thing. A kernel build.
> > > You will find clear_page to be the *1st* kernel entry after cc1 and as.
> > > That is bad for two reasons. The time it spends in there, and the cache 
> > > it 
> > > blows.
> > 
> > I don't doubt that it shows real benefits; but dangerously cutting
> > corners usually shows benefits too.  Relying on a uid at this level
> > feels very wrong to me - but as I said, I've not found a killer
> > argument against it.
> 
> The reason why I posted is exactly so other ppl can look at it and find 
> possible flaws in the way pages and retired. If an effective UID was able 
> to see (or it generated) the data on that page, it should be able to get 
> that page back uncleared (when VM_NOZERO is set).
> >From a performance POV, a 2-3% boost on a non-micro-bench test like a 
> kernel build is not exaclty peanuts. And for more heavy malloc/anon-mmap 
> appliations, the boost goes up to 10-15%. That is not exactly what I 
> call "little time" ;)
>
> - Davide
> 

I don't think the security issues with this will ever make it
worthwhile.

Consider:

1) euid is not sufficient, you need to store away arbitrary LSM
information and call LSM hooks to decide security equivalence. The same
applies to VServer or whatever other container system you use.

2) Two processes, A and B, are in separate VFS namespaces but have
equivalent security identity according to LSM. Process A reads data from
file F which is not visible in process's B's namespace. You have to
prevent process B from ever getting a page that once contained data from
file F.

3) mlock() is often used by programs like GPG to prevent decrypted
secret keys from ever getting swapped out. You need to zero all
once-mlocked pages before they get reused to prevent that page from
getting swapped to disk or application bugs from leaking the key.

-- 
Nicholas Miell <[EMAIL PROTECTED]>

-
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] CodingStyle: Add information about trailing whitespace.

[Oleg Verych]

> Newsgroups: gmane.linux.kernel
> Date: Wed, 27 Jun 2007 12:31:22 -0700

>
>
> akpm:/usr/src/25> grep -l "^+.*[]$" patches/git-*.patch
> patches/git-acpi.patch
> patches/git-alsa.patch
> patches/git-battery.patch
> patches/git-cifs.patch
> patches/git-drm.patch
> patches/git-gfs2-nmw.patch
> patches/git-hid.patch
> patches/git-ipwireless_cs.patch
> patches/git-ixgbe.patch
> patches/git-kgdb.patch
> patches/git-leds.patch
> patches/git-libata-all.patch
> patches/git-md-accel.patch
> patches/git-netdev-all.patch
> patches/git-newsetup.patch
> patches/git-nfs.patch
> patches/git-ocfs2.patch
> patches/git-pciseg.patch
> patches/git-qla3xxx.patch
> patches/git-selinux.patch
> patches/git-sym2.patch
> patches/git-unionfs.patch
> patches/git-watchdog.patch
> patches/git-wireless.patch
>
> damn.  Bunch of lamers.

9. The editor is the primary tool for programmers. People who don't
   choose an appropriate primary tool are worthless as professionals.

among others in 

I've shared little sh script too, 4 + 2(optional) sed commands with
comments of what whitespace crap was spotted. Yet nothing happened.
Converse -- questions about why they are useless...

Introduction of editor's labels in C files is the most outrages thing.
Don't editors smart to see filename extensions first? If they don't, fix
editors, not sources!

> But there's less than there used to be.

-
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] balance parenthesis in serial core

[Alan Cox]

On Wed, 27 Jun 2007 22:22:00 +0200
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:

> Hello,
> 
>   This patch balances the parenthesis imbalance in serial core.
> 
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>

Ack although the right thing to do is to remove these checks (and I'm
doing so in my tree). They are a waste of code for a path that basically
never occurs, is never performance critical and is asking for trouble in
future.
-
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] mtd: add module license to mtdbdi

[Mariusz Kozlowski]

Hello,

This seems to be a known issue [1] about Photron PNC-2000 module called
pnc2000. To reproduce this just 'modprobe pnc2000'. The patch attached at least
makes the kernel to be not tainted when mtdbdi gets loaded.

Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>

 drivers/mtd/mtdbdi.c |2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.22-rc6-bo-a/drivers/mtd/mtdbdi.c  2007-06-27 22:05:34.0 
+0200
+++ linux-2.6.22-rc6-bo-b/drivers/mtd/mtdbdi.c  2007-06-27 23:20:57.0 
+0200
@@ -46,3 +46,5 @@ struct backing_dev_info mtd_bdi_rw_mappa
   BDI_CAP_WRITE_MAP),
 };
 EXPORT_SYMBOL_GPL(mtd_bdi_rw_mappable);
+
+MODULE_LICENSE("GPL v2");



Regards,

Mariusz

[1] 
http://groups.google.pl/group/linux.kernel/browse_frm/thread/77d9f9273ab14382

a.txt - unpatched
b.txt - patched

--- a.txt   2007-06-27 23:32:48.0 +0200
+++ b.txt   2007-06-27 23:33:33.0 +0200
@@ -1,4 +1,3 @@
-mtdbdi: module license 'unspecified' taints kernel.
 Photron PNC-2000 flash mapping: 40 at bf00
 BUG: unable to handle kernel paging request at virtual address bf00
  printing eip:
@@ -6,27 +5,29 @@ ded752ff
 *pde = 
 Oops: 0002 [#1]
 PREEMPT
-Modules linked in: cfi_probe gen_probe pnc2000 mtdpart mtdcore mtdbdi(P) 
chipreg eeprom i2c_ali1535 rtc_cmos rtc_core rtc_lib i2c_ali15x3 8139too 
8250_pci 8250 serial_core yenta_socket rsrc_nonstatic
+Modules linked in: cfi_probe gen_probe pnc2000 mtdpart mtdcore mtdbdi chipreg 
eeprom i2c_ali1535 rtc_cmos rtc_core rtc_lib 8139too i2c_ali1
+5x3 yenta_socket rsrc_nonstatic 8250_pci 8250 serial_core
 CPU:0
-EIP:0060:[]Tainted: PVLI
+EIP:0060:[]Not tainted VLI
 EFLAGS: 00010286   (2.6.22-rc6-mm1 #2)
 EIP is at cfi_probe_chip+0xac/0xe61 [cfi_probe]
 eax: bf00   ebx: 0004   ecx: 0010   edx: 00f000f0
-esi: ded564e0   edi: 0002   ebp: c3511e14   esp: c3511db0
+esi: ded574e0   edi: 0002   ebp: c354de14   esp: c354ddb0
 ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
-Process modprobe (pid: 6075, ti=c351 task=c1b70ac0 task.ti=c351)
-Stack:   c3511e2c c0126d84  c3511dd0  
-    0001 dead4ead   c043cc58  0046
-   c3511df0 c3511df0  0001 dead4ead  ded75253 0002
+Process modprobe (pid: 6235, ti=c354c000 task=c263c030 task.ti=c354c000)
+Stack:   c354de2c c0126d84  c354ddd0  
+    0001 dead4ead   c06aee70  c04f3d98
+   c354ddf0 c354ddf0  0001 dead4ead  ded75253 0002
 Call Trace:
- [] mtd_do_chip_probe+0x83/0x32a [gen_probe]
+ [] mtd_do_chip_probe+0x83/0x32a [gen_probe]
  [] cfi_probe+0xd/0xf [cfi_probe]
- [] do_map_probe+0x1c/0x61 [chipreg]
- [] init_pnc2000+0x49/0x76 [pnc2000]
+ [] do_map_probe+0x1c/0x61 [chipreg]
+ [] init_pnc2000+0x49/0x76 [pnc2000]
  [] sys_init_module+0x11b/0x160b
  [] sysenter_past_esp+0x5f/0x85
  [] 0xe410
  ===
 INFO: lockdep is turned off.
-Code: f0 8d 0c fd 00 00 00 00 89 c2 d3 e2 09 c2 83 fb 01 0f 84 af 0d 00 00 83 
fb 02 0f 84 95 0d 00 00 83 fb 04 75 08 8b 45 b8 03 46 0c <89> 10 0f ae f0 89 f6 
8b 5e 14 8b 55 08 8b 4a 08 89 d8 99 f7 f9
-EIP: [] cfi_probe_chip+0xac/0xe61 [cfi_probe] SS:ESP 0068:c3511db0
+Code: f0 8d 0c fd 00 00 00 00 89 c2 d3 e2 09 c2 83 fb 01 0f 84 af 0d 00 00 83 
fb 02 0f 84 95 0d 00 00 83 fb 04 75 08 8b 45 b8 03 46 0c <89>
+ 10 0f ae f0 89 f6 8b 5e 14 8b 55 08 8b 4a 08 89 d8 99 f7 f9
+EIP: [] cfi_probe_chip+0xac/0xe61 [cfi_probe] SS:ESP 0068:c354ddb0


-
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] PM: Introduce set_target method in pm_ops

[Rafael J. Wysocki]

[Please consider as 2.6.22 material.]
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>

Commit 52ade9b3b97fd3bea42842a056fe0786c28d0555 changed the suspend code
ordering to execute pm_ops->prepare() after the device model per-device
.suspend() calls in order to fix some ACPI-related issues.  Unfortunately, it
broke the at91 platform which assumed that pm_ops->prepare() would be called
before suspending devices.

at91 used pm_ops->prepare() to get notified of the target system sleep state, so
that it could use this information while suspending devices.  However, with the
current suspend code ordering pm_ops->prepare() is called too late for this
purpose.  Thus, at91 needs an additional method in 'struct pm_ops' that will
be used for notifying the platform of the target system sleep state.  Moreover,
in the future such a method will also be needed by ACPI.

This patch adds the .set_target() method to 'struct pm_ops' and makes the
suspend code call it, if implemented, before executing the device model
per-device .suspend() calls.  It also modifies the at91 code to implement
pm_ops->set_target() instead of pm_ops->prepare().

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
---
 arch/arm/mach-at91/pm.c |4 +-
 include/linux/pm.h  |   66 +++-
 kernel/power/main.c |6 +++-
 3 files changed, 56 insertions(+), 20 deletions(-)

Index: linux-2.6.22-rc6/include/linux/pm.h
===
--- linux-2.6.22-rc6.orig/include/linux/pm.h2007-06-25 21:09:18.0 
+0200
+++ linux-2.6.22-rc6/include/linux/pm.h 2007-06-25 21:09:30.0 +0200
@@ -110,37 +110,67 @@ typedef int __bitwise suspend_state_t;
 #define PM_SUSPEND_MAX ((__force suspend_state_t) 4)
 
 /**
- * struct pm_ops - Callbacks for managing platform dependent suspend states.
- * @valid: Callback to determine whether the given state can be entered.
- * Valid states are advertised in /sys/power/state but can still
- * be rejected by prepare or enter if the conditions aren't right.
- * There is a %pm_valid_only_mem function available that can be assigned
- * to this if you only implement mem sleep.
+ * struct pm_ops - Callbacks for managing platform dependent system sleep
+ * states.
  *
- * @prepare: Prepare the platform for the given suspend state. Can return a
- * negative error code if necessary.
- *
- * @enter: Enter the given suspend state, must be assigned. Can return a
- * negative error code if necessary.
- *
- * @finish: Called when the system has left the given state and all devices
- * are resumed. The return value is ignored.
+ * @valid: Callback to determine if given system sleep state is supported by
+ * the platform.
+ * Valid (ie. supported) states are advertised in /sys/power/state.  Note
+ * that it still may be impossible to enter given system sleep state if the
+ * conditions aren't right.
+ * There is the %pm_valid_only_mem function available that can be assigned
+ * to this if the platform only supports mem sleep.
+ *
+ * @set_target: Tell the platform which system sleep state is going to be
+ * entered.
+ * @set_target() is executed right prior to suspending devices.  The
+ * information conveyed to the platform code by @set_target() should be
+ * disregarded by the platform as soon as @finish() is executed and if
+ * @prepare() fails.  If @set_target() fails (ie. returns nonzero),
+ * @prepare(), @enter() and @finish() will not be called by the PM core.
+ * This callback is optional.  However, if it is implemented, the argument
+ * passed to @prepare(), @enter() and @finish() is meaningless and should
+ * be ignored.
+ *
+ * @prepare: Prepare the platform for entering the system sleep state indicated
+ * by @set_target() or represented by the argument if @set_target() is not
+ * implemented.
+ * @prepare() is called right after devices have been suspended (ie. the
+ * appropriate .suspend() method has been executed for each device) and
+ * before the nonboot CPUs are disabled (it is executed with IRQs enabled).
+ * This callback is optional.  It returns 0 on success or a negative
+ * error code otherwise, in which case the system cannot enter the desired
+ * sleep state (@enter() and @finish() will not be called in that case).
+ *
+ * @enter: Enter the system sleep state indicated by @set_target() or
+ * represented by the argument if @set_target() is not implemented.
+ * This callback is mandatory.  It returns 0 on success or a negative
+ * error code otherwise, in which case the system cannot enter the desired
+ * sleep state.
+ *
+ * @finish: Called when the system has just left a sleep state, right after
+ * the nonboot CPUs have been enabled and before devices are resumed (it is
+ * executed with IRQs enabled).  If 

Re: ZERO_PAGE() vs. loadable modules in Redhat 4.4 i386 kernels ...

[Casey Leedom]

--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:

> On Wed, 2007-06-27 at 11:53 -0700, Casey Leedom wrote:
> >   Sorry, my bad.  I'm just diving into Linux for the first time and wasn't
> > aware of the protocols.  Here's the code fragment I'm currently using:
> 
> code fragments are only very limited useful because they don't
> compile... use the power of open source and just post your entire source
> code..  (and it's open source, right?)
> 
> you sort of gave too little, we can't see how this is being used for
> example..

  Yes, it's open source -- the company I work for, Chelsio Communications,
makes it money off of the hardware and gives away all of the driver source both
under GPL and BSD licenses.  I just thought that dumping the entire driver
source would bother people.  Basically the problem is that when you call
get_user_pages() and the "write" parameter is 0, get_user_pages() calls
follow_page() with FOLL_ANON in the foll_flags parameter.  This causes
follow_page() to return a reference to empty_zero_page if the page is an
unmodified /dev/zero mapping and any portion of the PGD/PUD/PMD/PTE hierarchy
is missing.  This is all fine, but later on in our driver when we want to
follow down the PGD/PUD/PMD/PTE hierarchy to mark pages COW we fail because of
the missing mappings.

  I've thought of several solutions to this problem:

 1. If the "zero copy" DMA path comes across any /dev/zero mapped page,
fail the zero copy path and fall back to the normal copy path.  This
would be a minor performance loss but even worse, it requires being
able to recognize ZERO_PAGE() which is the problem I'm battling now.

 2. Force get_user_pages() not to pass FOLL_ANON in to follow_page().
The simplest way to do this is to pass in a non-zero "write"
parameter but I'm leary of this because of the potential for
side effects (lots of pages getting marked dirty, etc.)

 3. In the DMA-timeout/COW/return-to-user optimization path, if we run
across ZERO_PAGE() then just skip to the next page since ZERO_PAGE()
doesn't need to be marked COW.  This is our current fix but we've
run across this inability to determine if a page we're looking at is
the ZERO_PAGE() in an i386 32-bit Redhat 4.4 kernel ... (sigh)  This
does work on the x86_64 kernel since empty_zero_page is an
EXPORT_SYMBOL() under that architecture.

 4. Somehow force the PGD/PUD/PMD/PTE hierarchy to instantiate for each
page.  Not sure how to do this ...  (I'm very new to the Linux kernel
and working hard to catch up with everything.)

Sorry for the long drawn out explanation -- most of you probably already know
all about these paths but I just found out most of the above so I figured I
should explain what I _think_ is going on in case I've got some misconceptions.

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

sata_sil, writing bug with multiple cards?

[7091]

Greetings, 

I have been troubleshooting a problem for over a year now, and to make a 
long story short, I think the sata_sil driver has a bug during writing when 
there are multiple cards that are using different models of SiI chips in the 
system. 

I will be watching the list, although cc'ing me over email will be useful 
for speeding up replies. 


Longer version:
I've been having problems with my Linux server corrupting data.  Not just a 
little - it can't copy a 700 meg ISO file and end up with the same checksum 
(and usually corrupts the filesystem in the process). 


Hardware:
Asus A7N8X-Deluxe motherboard.  This has 2 parallel IDE connectors, each 
with a 40 gig IDE HD hanging off it, and 2 SATA connectors (driven by a SiI 
3112 chip) with (right now) 1 300G SATA HD and 1 250G SATA HD.  All of these 
facts are important. 

On my PCI bus, I have a SiI 3114A card with 3 more 300G SATA HDs.  It should 
be noted that only drives on the PCI card have corruption.  Neither the 
parallel IDE HDs, nor the SATA drives on the motherboard experience the 
problem. I have also tried replacing this card, which did not fix the 
problem.  Also, placing the same drive on the add-on card has corruption, 
the same drive, cable, power, etc. on the motherboard works fine. 

I've already swapped motherboards, CPU, and RAM. 

Booting to a Knoppix 5.1 CD shows the same problems. 

Reading is fine (i.e. I can read the same file 50 times and get the same 
md5sum).  Writing causes the corruption. 

The corruption happens no matter what filesystem I try (ext2, ext3, reiser, 
xfs).  (This does mean I've reformatted, etc. several times, so its not a 
metadata problem) 

This happens with at least 3 different drives (the 300 and the 250, 
different manufacturers), with different SATA data cables, power supplies, 
power cables, etc. 

Now, here's the kicker.  Booting to an OpenBSD kernel, and using one of the 
300G drives off the 3114A card (the one that show corruption under Linux) 
works fine. 

This happens with the Knoppix 5.1 kernel (2.6.19), my own compiled 2.6.20.3, 
and Debian kernel 2.6.18-4-k7. 


More spammy data:
# lspci
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) 
(rev a2)

00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev a2)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev a2)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev a2)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev a2)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev a2)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller 
(rev a1)

00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
00:0c.0 PCI bridge: nVidia Corporation nForce2 PCI Bridge (rev a3)
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev a2)
01:06.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W 
[Millennium II]
01:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 
Gigabit Ethernet (rev 10)
01:09.0 Mass storage controller: Silicon Image, Inc. SiI 3114 
[SATALink/SATARaid] Serial ATA Controller (rev 02)
01:0b.0 RAID bus controller: Silicon Image, Inc. SiI 3112 
[SATALink/SATARaid] Serial ATA Controller (rev 01)
02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB Integrated Fast 
Ethernet Controller [Tornado] (rev 40) 


Any assistance, input, etc. appreciated.  Thanks.
-
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] touchscreen support for collie (sharp zaurus sl-5500)

[Pavel Machek]

Hi!

> >+config MCP_COLLIE_TS
> >+   tristate "Touchscreen collie support"
> >+   depends on MCP_UCB1200 && INPUT && !MCP_UCB1200_TS
> >+---help---
> >+ Driver for touchscreen on collie - sharp sl-5500.
> >+
> 
> Can't ucb1x00-ts be modified to properly support collie hardware?
> These drivers look almost like twin brothers.

Well, we don't have non-collie hardware nearby. According to metan,
driver was written by the spec, but we can't test it on non-collie so
we are  probably breaking it. Can someone help with testing?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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 1/7] cpuset write dirty map

[Christoph Lameter]

On Wed, 27 Jun 2007, Ethan Solomita wrote:

>   I looked over it at one point. Most of the code doesn't conflict, but I
> believe that the code path which calculates the dirty limits will need
> some merging. Doable but non-trivial.
>   -- Ethan

I hope you will keep on updating the patchset and posting it against 
current mm?

-
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: [AppArmor 00/44] AppArmor security module overview

[Sean]

On Wed, 27 Jun 2007 14:06:04 -0700
Crispin Cowan <[EMAIL PROTECTED]> wrote:

> I am hoping for a reconciliation where the people who don't like
> AppArmor live with it by not using it. AppArmor is not intended to
> replace SELinux, it is intended to address a different set of goals.

You keep saying that.   But for that to be true you'd have to believe
_everyone_ using Novell distributions has needs that align exactly
with AppArmor.  Otherwise, how to explain that you don't offer and
support both SELinux and AppArmor to your users?

It seems as far as Novell is concerned, AppArmor _is_ meant to replace
SELinux.  Not that there is really anything wrong with that, but it's
a little disingenuous to then argue that they're meant to coexist.

Sean
-
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] rewrite AF_UNIX garbage collector

[Miklos Szeredi]

Please review.

Apologies if the patch itself is not too readable due to lots of code
being replaced, but the end result is quite clear I think.


From: Miklos Szeredi <[EMAIL PROTECTED]>

Throw out the old mark & sweep garbage collector and put in a
refcounting cycle detecting one.

The old one had a race with recvmsg, that resulted in false positives
and hence data loss.  The old algorithm operated on all unix sockets
in the system, so any additional locking would have meant performance
problems for all users of these.

The new algorithm instead only operates on "in flight" sockets, which
are very rare, and the additional locking for these doesn't negatively
impact the vast majority of users.

In fact it's probable, that there weren't *any* heavy senders of
sockets over sockets, otherwise the above race would have been
discovered long ago.

The patch works OK with the app that exposed the race with the old
code.  The garbage collection has also been verified to work in a few
simple cases.

See comments inside patch for the description of the algorithm.

Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
 include/net/af_unix.h |3
 net/unix/af_unix.c|6
 net/unix/garbage.c|  329 --
 3 files changed, 192 insertions(+), 146 deletions(-)

Index: linux-2.6.22-rc6/include/net/af_unix.h
===
--- linux-2.6.22-rc6.orig/include/net/af_unix.h 2007-06-27 22:53:53.0 
+0200
+++ linux-2.6.22-rc6/include/net/af_unix.h  2007-06-27 22:53:55.0 
+0200
@@ -79,9 +79,10 @@ struct unix_sock {
struct mutexreadlock;
 struct sock*peer;
 struct sock*other;
-struct sock*gc_tree;
+   struct list_headlink;
 atomic_tinflight;
 spinlock_t lock;
+   unsigned intgc_candidate : 1;
 wait_queue_head_t   peer_wait;
 };
 #define unix_sk(__sk) ((struct unix_sock *)__sk)
Index: linux-2.6.22-rc6/net/unix/af_unix.c
===
--- linux-2.6.22-rc6.orig/net/unix/af_unix.c2007-06-27 22:53:53.0 
+0200
+++ linux-2.6.22-rc6/net/unix/af_unix.c 2007-06-27 22:53:55.0 +0200
@@ -592,7 +592,8 @@ static struct sock * unix_create1(struct
u->dentry = NULL;
u->mnt= NULL;
spin_lock_init(>lock);
-   atomic_set(>inflight, sock ? 0 : -1);
+   atomic_set(>inflight, 0);
+   INIT_LIST_HEAD(>link);
mutex_init(>readlock); /* single task reading lock */
init_waitqueue_head(>peer_wait);
unix_insert_socket(unix_sockets_unbound, sk);
@@ -1134,9 +1135,6 @@ restart:
/* take ten and and send info to listening sock */
spin_lock(>sk_receive_queue.lock);
__skb_queue_tail(>sk_receive_queue, skb);
-   /* Undo artificially decreased inflight after embrion
-* is installed to listening socket. */
-   atomic_inc(>inflight);
spin_unlock(>sk_receive_queue.lock);
unix_state_unlock(other);
other->sk_data_ready(other, 0);
Index: linux-2.6.22-rc6/net/unix/garbage.c
===
--- linux-2.6.22-rc6.orig/net/unix/garbage.c2007-06-27 22:53:53.0 
+0200
+++ linux-2.6.22-rc6/net/unix/garbage.c 2007-06-27 22:53:55.0 +0200
@@ -62,6 +62,10 @@
  * AV  1 Mar 1999
  * Damn. Added missing check for ->dead in listen queues scanning.
  *
+ * Miklos Szeredi 25 Jun 2007
+ * Reimplement with a cycle collecting algorithm. This should
+ * solve several problems with the previous code, like being racy
+ * wrt receive and holding up unrelated socket operations.
  */
 
 #include 
@@ -84,10 +88,9 @@
 
 /* Internal data structures and random procedures: */
 
-#define GC_HEAD((struct sock *)(-1))
-#define GC_ORPHAN  ((struct sock *)(-3))
-
-static struct sock *gc_current = GC_HEAD; /* stack of objects to mark */
+static LIST_HEAD(gc_inflight_list);
+static LIST_HEAD(gc_candidates);
+static DEFINE_SPINLOCK(unix_gc_lock);
 
 atomic_t unix_tot_inflight = ATOMIC_INIT(0);
 
@@ -122,8 +125,16 @@ void unix_inflight(struct file *fp)
 {
struct sock *s = unix_get_socket(fp);
if(s) {
-   atomic_inc(_sk(s)->inflight);
+   struct unix_sock *u = unix_sk(s);
+   spin_lock(_gc_lock);
+   if (atomic_inc_return(>inflight) == 1) {
+   BUG_ON(!list_empty(>link));
+   list_add_tail(>link, _inflight_list);
+   } else {
+   BUG_ON(list_empty(>link));
+   }
atomic_inc(_tot_inflight);
+   spin_unlock(_gc_lock);
}
 }
 
@@ -131,182 +142,218 @@ void unix_notinflight(struct file *fp)
 {

flexible mmap layout and vdso mapping

[Daniel Forrest]

I am having a problem with memory allocation in a program when run
under Linux 2.6.18.

The program is statically linked and uses its own malloc library based
on brk().  Under previous versions of Linux it was able to allocate up
to ~3GB of memory before failing, now it fails at ~1GB.

The problem is that the vdso is mapped at 0x4000 which limits the
heap to addresses less than 1GB.

I have tracked this down to the point that I see it is dependent on
the function arch_pick_mmap_layout(), in particular:

if (!(2 & exec_shield) && (sysctl_legacy_va_layout ||
(current->personality & ADDR_COMPAT_LAYOUT) ||
current->signal->rlim[RLIMIT_STACK].rlim_cur == 
RLIM_INFINITY)) {
mm->mmap_base = TASK_UNMAPPED_BASE;
mm->get_unmapped_area = arch_get_unmapped_area;
mm->unmap_area = arch_unmap_area;
} else { ...


And the vdso is apparently mapped at "mm->mmap_base".


The program I have is a compiled binary and it is running through a
queueing system so modifying "/proc/sys/kernel/exec-shield" or
changing the stack limit are problematical.

Everything worked fine under Linux 2.6.9, except I notice in this case
that "cat /proc/sys/kernel/vdso" returns 0, whereas under 2.6.18 it
returns 1.


Are there any options on a per-program basis to disable vdso mapping?
Or any per-program options to change the location?  This queueing
system supports checkpointing and process migration, but that requires
that the binary not be changed so recompiling is not desirable.

-- 
Daniel K. Forrest   Laboratory for Molecular and
[EMAIL PROTECTED]   Computational Genomics
(608) 262 - 9479University of Wisconsin, Madison
-
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: NVidia Driver Support - 1680x1050 mode

[Carlo Wood]

Or use the same hardware as me (and debian)-- and read on my home page how
I got things working :p

hikaru:/usr/lib>dpkg -l | grep nvidia
ii  nvidia-glx  
 100.14.11-0  NVIDIA binary Xorg driver
ii  nvidia-glx-dev  
 100.14.11-0  NVIDIA binary Xorg driver development files
ii  nvidia-kernel-2.6-amd64 
 100.14.11+beta   NVIDIA binary kernel module for 2.6 series c
ii  nvidia-kernel-2.6.18-4-amd64
 100.14.11+beta   NVIDIA binary kernel module for Linux 2.6.18
ii  
nvidia-kernel-2.6.22-rc5-agp1-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64 
100.14.11+beta   NVIDIA binary kernel module for Linux 2.6.22

-- 
Carlo Wood <[EMAIL PROTECTED]>

PS I use two of my Samsung SyncMaster 205BW (1650x1050) as dual head
   on an ASUS EN8600 GTS (dual-head). You need nvidia's beta drivers
   (>= 100.14.06) for that to work though.

-
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 1/7] cpuset write dirty map

[Mel Gorman]

On (27/06/07 05:44), Christoph Lameter didst pronounce:
> On Wed, 27 Jun 2007, Andrew Morton wrote:
> 
> > I'm more concerned about all of Mel's code in -mm actually.  I don't recall
> > anyone doing a full review recently and I'm still not sure that this is the
> > overall direction in which we wish to go.  Last time I asked this everyone
> > seemed a bit waffly and non-committal.
> 
> I have looked over this several times lately and it all seems quite okay. 
> Still cannot find a justification for the movable zone (never had to 
> use it in testing) but it seems that it makes memory unplug easier.

As well as helping memory hot-remove, it provides a known lower-limit that
the hugepage pool can be resized to at runtime. Grouping pages by mobility
on its own does not give a known number of pageblocks that could be used
for hugepage allocation. On it's own, it provides a high probability that
the hugepage pool can be grown but how large depends on the workload. With
the zone, an administrator can set aside X amount of memory that can be used
for hugepages if necessary and base pages otherwise.

> The 
> antifrag patchset together with a page migration patch simplifies the 
> unplug patchset significantly.
> 
> I think the antifrag code is a significant step forward and will enable 
> lots of other features (memory unplug, larger page use in SLUB, huge page 
> allocs after boot). It may be useful to put memory compaction and memory 
> unplug in at the same time (I think we can get there even for .23) so that 
> we have a full package.

The memory unplug patches already migrate pages without the help of memory
compaction. Memory compaction needs a bit more work before I try sending
it towards -mm for wider testing. It's important to get right because
with compaction, the migration code is getting a lot more exercise than it
does today. However, memory compaction needing more work should not hold
back memory unplug nor does it impact on the utility of grouping pages
by mobility or the movable zone.

> With compaction we can finally recover from loads 
> that typically cause memory to be split in a lot of disjoint pieces and 
> get to a sitaution were we can dynamically reconfigure the number of huge 
> pages at run time (Our customers currently reboot to do this which is a 
> pain). Compaction increases the chance of I/O controllers being able to 
> merge I/O requests since contiguous pages can be served by the page 
> allocator again. Antifrag almost gets there but I can still construct 
> allocation scenarios that fragment memory significantly.
> 

The number of scenarios that cause fragmentation have dropped over time.
It's something I see as constantly improving over time.

> Also compaction is a requirement if we ever want to support larger 
> blocksizes. That would allow the removal of various layers that are now 
> needed to compensate for not supporting larger pages.
> 
> The whole approach is useful to increase performance. We have seen 
> several percentage points of performance wins with SLUB when allowing 
> larger pages sizes. The use of huge pages is also mainly done for 
> performance reasons. The large blocksize patch has shown a 50% performance 
> increase even in its prototype form where we certainly have not solved 
> server performance issues.
> 
> Even without large blocksize: The ability to restore the capability of the 
> page allocator to serve pages that are in sequence can be used to shorten
> the scatter gather lists in the I/O layer speeding up I/O.
> 
> I think this is an important contribution that will move a lot of other 
> issues forward.
> 

Thanks Christoph for your reviewing of the code, your comments here and the
quite rigorous exercise of the anti-fragmentation code. I too believe
there are performance gains to be had through the use of larger pages
and working on this does not preclude work on improving the use of base
pages.

For larger pages to be used though, external fragmentation has to be
addressed in some fashion and no other viable implementation exists
besides anti-fragmentation right now.

-- 
Mel Gorman
Part-time Phd Student  Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
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: [AppArmor 00/44] AppArmor security module overview

[Crispin Cowan]

Adrian Bunk wrote:
> On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
>   
>> Do you agree with the "irreconcilable" part?  I think I do. 
I am hoping for a reconciliation where the people who don't like
AppArmor live with it by not using it. AppArmor is not intended to
replace SELinux, it is intended to address a different set of goals.

>> I suspect that we're at the stage of having to decide between
>>
>> a) set aside the technical issues and grudgingly merge this stuff as a
>>service to Suse and to their users (both of which entities are very
>>important to us) and leave it all as an object lesson in
>>how-not-to-develop-kernel-features.
>>
>>Minimisation of the impact on the rest of the kernel is of course
>>very important here.
>>
>> versus
>>
>> b) leave it out and require that Suse wear the permanent cost and
>>quality impact of maintaining it out-of-tree.  It will still be an
>>object lesson in how-not-to-develop-kernel-features.
>> ...
> versus
>
> c) if [1] AppArmor is considered to be something that wouldn't 
>be merged if it wasn't already widely deployed by Suse: leave it out, 
>work on an ideal solution [2], and let Suse wear the one-time cost
>of migrating their users to the ideal solution
>   
We argue that the proposed patch is a viable solution for providing
AppArmor functionality. We would be happy for specific suggestions on
how to make it better.

> I'm not claiming to understand the technical details, but from both 
> slightly reading over the previous discussions and the "What are the 
> advantages of AppArmor over SELinux?" section in the AppArmor FAQ [3] my 
> impression is that a main advantage of AppArmor are more user friendly 
> userspace tools. Therefore, if [1] AppArmor is considered technically 
> inferior to SELinux, it might still become more popular than SELinux 
> simply because it's easier to use - and although it's technically 
> inferior.  
AppArmor's advantages come from the model, not the tools. AppArmor is
not inferior to SELinux, it is different than SELinux. Neither can
replace the other without horrid kludges.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor

-
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] hwbkpt: Hardware breakpoints (was Kwatch)

[Roland McGrath]

> So far this work has all been based on the vanilla kernel.  Should I 
> switch over to basing it on -mm?

It doesn't much matter at the moment.  Sticking with vanilla is the easiest
for you and me testing it right now.

> > Calling send_sigtrap twice during the same exception does happen to be
> > harmless, but I don't think it should be presumed to be.  It is just not
> > the right way to go about things that you send a signal twice when there
> > is one signal you want to generate.
> 
> What happens when there are two ptrace exceptions at different points
> during the same system call?  Won't we end up sending the signal twice
> no matter what?

Well then that is two signals for good reason, so that is a different
story.  It winds up indistinguishable from only sending the second, but as
far as the organization of the code and thinking about the semantics, twice
is right in this case and once is right in the simpler case.

> In theory we should get an exception with both DR_STEP and DR_TRAPn 
> set, meaning that neither notifier will return NOTIFY_STOP.  But if the 
> kprobes handler clears DR_STEP in the DR6 image passed to the 
> hw_breakpoint handler, it should work out better.

It's since occurred to me that kprobes can and should do:

args->err &= ~(unsigned long) DR_STEP;
if (args->err == 0)
return NOTIFY_STOP;

This doesn't affect do_debug directly, but it will change the value seen by
the next notifier.  So if hw_breakpoint_handler is responsible for setting
vdr6 based on its args->err value, we should win.

> > vdr6 belongs wholly to hw_breakpoint, no other code refers to it
> > directly.  hw_breakpoint's notifier sets vdr6 with non-DR_TRAPn bits,
> > if it's a user-mode exception.  If it's a ptrace exception it also
> > sets the mapped DR_TRAPn bits.  If it's not a ptrace exception and
> > only DR_TRAPn bits were newly set, then it returns NOTIFY_STOP.  If
> > it's a spurious exception from lazy db7 setting, hw_breakpoint just
> > returns NOTIFY_STOP early.
> 
> That sounds not quite right.  To a user-space debugger, a system call
> should appear as an atomic operation.  If multiple ptrace exceptions
> occur during a system call, all the relevant DR_TRAPn bits should be
> set in vdr6 together and all the other ones reset.  How can we arrange
> that?

That would be nice.  But it's more than the old code did.  I don't feel any
strong need to improve the situation when using ptrace.  The old code
disabled breakpoints after the first hit, so userland would only see the
first DR_TRAPn bit.  (Even if it didn't, with the blind copying of the
hardware %db6 value, we now know it would only see one DR_TRAPn bit still
set after a second exception.)  With my suggestion above, userland would
only see the last DR_TRAPn bit.  So it's not worse.

In the ptrace case, we know it's always going to wind up with a signal
before it finishes and returns to user mode.  So one approach would be in
e.g. do_notify_resume, do:

if (thread_info_flags & _TIF_DEBUG)
current->thread.hw_breakpoint_info->someflag = 0;

Then ptrace_triggered could set someflag, and know from it still being set
on entry that it's a second trigger without getting back to user mode yet
(and so accumulate bits instead reset old ones).

But I just would not bother improving ptrace beyond the status quo for a
corner case noone has cared about in practice so far.  In sensible
mechanisms of the future, nothing will examine db6 values directly.

> There's also the question of whether to send the SIGTRAP.  If
> extraneous bits are set in DR6 (e.g., because the CPU always sets some
> extra bits) then we will never get NOTIFY_STOP.  Nevertheless, the
> signal should not always be sent.

Yeah.  The current Intel manual describes all the unspecified DR6 bits as
explicitly reserved and set to 1 (except 0x1000 reserved and 0).  If new
meanings are assigned in future chips, presumably those will only be
enabled by some new explicit cr/msr setting.  Those might be enabled by
some extra module or something, but there is only so much we can do to
accomodate.  I think the best plan is that notifiers should do:

args->err &= ~bits_i_recognize_as_mine;
if (!(args->err & known_bits))
return NOTIFY_STOP;

known_bits are the ones we use, plus 0x8000 (DR_SWITCH/BS) and 0x2000 (BD).
(Those two should be impossible without some strange new kernel bug.)
Probably should write it as ~DR_STATUS_RESERVED, to parallel existing macros.

Then we only possibly interfere with a newfangled debug exception flavor
that occurs in the same one debug exception for an instruction also
triggering for hw_breakpoint or step.  In the more likely cases of a new
flavor of exception happening by itself, or the aforementioned strange new
kernel bugs, we will get to the bottom of do_debug and do the SIGTRAP.

For this plan, hw_breakpoint_handler also needs not to return NOTIFY_STOP
as a special case for a 

[RFC][PATCH -mm] PM: Do not use saved_state from struct dev_pm_info on ARM (was: Re: patch pm-remove-saved_state-from-struct-dev_pm_info.patch added to gregkh-2.6 tree)

[Rafael J. Wysocki]

On Tuesday, 26 June 2007 23:03, Greg KH wrote:
> On Tue, Jun 26, 2007 at 11:00:06PM +0200, Rafael J. Wysocki wrote:
> > On Friday, 15 June 2007 00:57, [EMAIL PROTECTED] wrote:
> > > 
> > > This is a note to let you know that I've just added the patch titled
> > > 
> > >  Subject: PM: Remove saved_state from struct dev_pm_info
> > > 
> > > to my gregkh-2.6 tree.  Its filename is
> > > 
> > >  pm-remove-saved_state-from-struct-dev_pm_info.patch
> > > 
> > > This tree can be found at 
> > > 
> > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
> > > 
> > > 
> > > From [EMAIL PROTECTED]  Thu Jun 14 15:47:15 2007
> > > From: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> > > To: Andrew Morton <[EMAIL PROTECTED]>
> > > Subject: PM: Remove saved_state from struct dev_pm_info
> > > Date: Wed, 13 Jun 2007 15:55:34 +0200
> > > Cc: Alan Stern <[EMAIL PROTECTED]>, David Brownell <[EMAIL PROTECTED]>, 
> > > Greg KH <[EMAIL PROTECTED]>, Pavel Machek <[EMAIL PROTECTED]>
> > > Content-Disposition: inline
> > > Message-Id: <[EMAIL PROTECTED]>
> > > 
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > 
> > > The saved_state member of struct dev_pm_info, defined in 
> > > include/linux/pm.h, is
> > > not used anywhere, so it can be removed.
> > 
> > Unfortunately this is wrong, as I've just found three drivers in the ARM 
> > tree
> > that use it.  I don't know why I didn't see them when I was creating the 
> > patch,
> > though. :-(
> 
> Why not just fix up the ARM drivers instead?

OK, let's try. :-)

The following patch has only been compilation tested.

---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>

The saved_state member of 'struct dev_pm_info' that's going to be removed is
used in arch/arm/common/locomo.c, arch/arm/common/sa.c and
arch/arm/mach-sa1100/neponset.c.  Change the code in there to use local
variables for saving the state of devices during suspend.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 arch/arm/common/locomo.c|   17 +++--
 arch/arm/common/sa.c|   12 +++-
 arch/arm/mach-sa1100/neponset.c |   15 ---
 3 files changed, 14 insertions(+), 30 deletions(-)

Index: linux-2.6.22-rc6/arch/arm/common/locomo.c
===
--- linux-2.6.22-rc6.orig/arch/arm/common/locomo.c  2007-04-26 
05:08:32.0 +0200
+++ linux-2.6.22-rc6/arch/arm/common/locomo.c   2007-06-27 21:48:15.0 
+0200
@@ -553,20 +553,14 @@ struct locomo_save_data {
u16 LCM_GPE;
u16 LCM_ASD;
u16 LCM_SPIMD;
-};
+} locomo_saved_state;
 
 static int locomo_suspend(struct platform_device *dev, pm_message_t state)
 {
struct locomo *lchip = platform_get_drvdata(dev);
-   struct locomo_save_data *save;
+   struct locomo_save_data *save = _saved_state;
unsigned long flags;
 
-   save = kmalloc(sizeof(struct locomo_save_data), GFP_KERNEL);
-   if (!save)
-   return -ENOMEM;
-
-   dev->dev.power.saved_state = (void *) save;
-
spin_lock_irqsave(>lock, flags);
 
save->LCM_GPO = locomo_readl(lchip->base + LOCOMO_GPO); /* GPIO 
*/
@@ -602,13 +596,9 @@ static int locomo_suspend(struct platfor
 static int locomo_resume(struct platform_device *dev)
 {
struct locomo *lchip = platform_get_drvdata(dev);
-   struct locomo_save_data *save;
+   struct locomo_save_data *save = _saved_state;
unsigned long r;
unsigned long flags;
-   
-   save = (struct locomo_save_data *) dev->dev.power.saved_state;
-   if (!save)
-   return 0;
 
spin_lock_irqsave(>lock, flags);
 
@@ -628,7 +618,6 @@ static int locomo_resume(struct platform
locomo_writel(0x1, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KCMD);
 
spin_unlock_irqrestore(>lock, flags);
-   kfree(save);
 
return 0;
 }
Index: linux-2.6.22-rc6/arch/arm/common/sa.c
===
--- linux-2.6.22-rc6.orig/arch/arm/common/sa.c  2007-06-25 
21:07:24.0 +0200
+++ linux-2.6.22-rc6/arch/arm/common/sa.c   2007-06-27 21:43:50.0 
+0200
@@ -811,6 +811,8 @@ struct sa_save_data {
 
 #ifdef CONFIG_PM
 
+static struct sa_save_data *sa_saved_state;
+
 static int sa_suspend(struct platform_device *dev, pm_message_t state)
 {
struct sa *sachip = platform_get_drvdata(dev);
@@ -822,7 +824,7 @@ static int sa_suspend(struct platfor
save = kmalloc(sizeof(struct sa_save_data), GFP_KERNEL);
if (!save)
return -ENOMEM;
-   dev->dev.power.saved_state = save;
+   sa_saved_state = save;
 
spin_lock_irqsave(>lock, flags);
 
@@ -878,7 +880,7 @@ static int sa_resume(struct platform
unsigned long flags, id;
void __iomem *base;
 
-   save = (struct sa_save_data *)dev->dev.power.saved_state;
+   

Re: [POWERPC] Update defconfigs

[Jan Dittmer]

Linux Kernel Mailing List wrote:
> Gitweb: 
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ca74c013441200b162f6a384b23b833d1865a9e8
> Commit: ca74c013441200b162f6a384b23b833d1865a9e8
> Parent: d30d6badd1769a00bc5a800b8af4e8b3f169c633
> Author: Paul Mackerras <[EMAIL PROTECTED]>
> AuthorDate: Tue Jun 26 14:19:35 2007 +1000
> Committer:  Paul Mackerras <[EMAIL PROTECTED]>
> CommitDate: Tue Jun 26 14:38:47 2007 +1000
> 
> [POWERPC] Update defconfigs
> 
> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
> ---
>  arch/powerpc/configs/cell_defconfig|  243 +++-

Regression from -rc6, cell_defconfig does not build anymore:

  Building modules, stage 2.
  MODPOST 135 modules
ERROR: ".pmi_send_message" [arch/powerpc/platforms/cell/cbe_cpufreq.ko]
undefined!
ERROR: ".pmi_unregister_handler"
[arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined!
ERROR: ".pmi_register_handler"
[arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [_all] Error 2

I've left the relevant diff attached.

Jan

> diff --git a/arch/powerpc/configs/cell_defconfig 
> b/arch/powerpc/configs/cell_defconfig
> index 02c428a..74f83f4 100644
> --- a/arch/powerpc/configs/cell_defconfig
> +++ b/arch/powerpc/configs/cell_defconfig
> @@ -1,7 +1,7 @@
>  #
>  # Automatically generated make config: don't edit
> -# Linux kernel version: 2.6.21-rc6
> -# Mon Apr 23 20:46:48 2007
> +# Linux kernel version: 2.6.22-rc6
> +# Tue Jun 26 12:32:34 2007
>  #
>  CONFIG_PPC64=y
>  CONFIG_64BIT=y
> @@ -41,6 +41,7 @@ CONFIG_PPC_DCR=y
>  CONFIG_PPC_OF_PLATFORM_PCI=y
>  CONFIG_ALTIVEC=y
>  CONFIG_PPC_STD_MMU=y
> +CONFIG_PPC_MM_SLICES=y
>  CONFIG_VIRT_CPU_ACCOUNTING=y
>  CONFIG_SMP=y
>  CONFIG_NR_CPUS=4
> @@ -69,6 +70,7 @@ CONFIG_SYSVIPC_SYSCTL=y
>  # CONFIG_AUDIT is not set
>  CONFIG_IKCONFIG=y
>  CONFIG_IKCONFIG_PROC=y
> +CONFIG_LOG_BUF_SHIFT=15
>  CONFIG_CPUSETS=y
>  CONFIG_SYSFS_DEPRECATED=y
>  # CONFIG_RELAY is not set
> @@ -87,14 +89,19 @@ CONFIG_BUG=y
>  CONFIG_ELF_CORE=y
>  CONFIG_BASE_FULL=y
>  CONFIG_FUTEX=y
> +CONFIG_ANON_INODES=y
>  CONFIG_EPOLL=y
> +CONFIG_SIGNALFD=y
> +CONFIG_TIMERFD=y
> +CONFIG_EVENTFD=y
>  CONFIG_SHMEM=y
> -CONFIG_SLAB=y
>  CONFIG_VM_EVENT_COUNTERS=y
> +CONFIG_SLAB=y
> +# CONFIG_SLUB is not set
> +# CONFIG_SLOB is not set
>  CONFIG_RT_MUTEXES=y
>  # CONFIG_TINY_SHMEM is not set
>  CONFIG_BASE_SMALL=0
> -# CONFIG_SLOB is not set
>  
>  #
>  # Loadable module support
> @@ -163,9 +170,14 @@ CONFIG_SPU_FS=m
>  CONFIG_SPU_BASE=y
>  CONFIG_CBE_RAS=y
>  CONFIG_CBE_THERM=m
> +CONFIG_CBE_CPUFREQ=m
> +# CONFIG_PQ2ADS is not set
>  CONFIG_PPC_NATIVE=y
>  CONFIG_UDBG_RTAS_CONSOLE=y
>  CONFIG_PPC_UDBG_BEAT=y
> +CONFIG_MPIC=y
> +# CONFIG_MPIC_WEIRD is not set
> +# CONFIG_PPC_I8259 is not set
>  # CONFIG_U3_DART is not set
>  CONFIG_PPC_RTAS=y
>  # CONFIG_RTAS_ERROR_LOGGING is not set
> @@ -177,9 +189,23 @@ CONFIG_MMIO_NVRAM=y
>  # CONFIG_PPC_970_NAP is not set
>  CONFIG_PPC_INDIRECT_IO=y
>  CONFIG_GENERIC_IOMAP=y
> -# CONFIG_CPU_FREQ_PMAC64 is not set
> -# CONFIG_WANT_EARLY_SERIAL is not set
> -CONFIG_MPIC=y
> +CONFIG_CPU_FREQ=y
> +CONFIG_CPU_FREQ_TABLE=y
> +# CONFIG_CPU_FREQ_DEBUG is not set
> +CONFIG_CPU_FREQ_STAT=y
> +# CONFIG_CPU_FREQ_STAT_DETAILS is not set
> +CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> +# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
> +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> +
> +#
> +# CPU Frequency drivers
> +#
> +# CONFIG_CPM2 is not set
>  
>  #
>  # Kernel options
> @@ -224,12 +250,14 @@ CONFIG_RESOURCES_64BIT=y
>  CONFIG_ZONE_DMA_FLAG=1
>  CONFIG_ARCH_MEMORY_PROBE=y
>  CONFIG_NODES_SPAN_OTHER_NODES=y
> +CONFIG_PPC_HAS_HASH_64K=y
>  CONFIG_PPC_64K_PAGES=y
>  CONFIG_SCHED_SMT=y
>  CONFIG_PROC_DEVICETREE=y
>  # CONFIG_CMDLINE_BOOL is not set
>  # CONFIG_PM is not set
>  CONFIG_SECCOMP=y
> +# CONFIG_WANT_DEVICE_TREE is not set
>  CONFIG_ISA_DMA_API=y
>  
>  #
> @@ -237,22 +265,18 @@ CONFIG_ISA_DMA_API=y
>  #
>  CONFIG_ZONE_DMA=y
>  CONFIG_GENERIC_ISA_DMA=y
> -# CONFIG_MPIC_WEIRD is not set
> -# CONFIG_PPC_I8259 is not set
>  # CONFIG_PPC_INDIRECT_PCI is not set
>  CONFIG_PCI=y
>  CONFIG_PCI_DOMAINS=y
>  CONFIG_PCIEPORTBUS=y
> +CONFIG_ARCH_SUPPORTS_MSI=y
> +# CONFIG_PCI_MSI is not set
>  # CONFIG_PCI_DEBUG is not set
>  
>  #
>  # PCCARD (PCMCIA/CardBus) support
>  #
>  # CONFIG_PCCARD is not set
> -
> -#
> -# PCI Hotplug Support
> -#
>  # CONFIG_HOTPLUG_PCI is not set
>  CONFIG_KERNEL_START=0xc000
>  
> @@ -264,7 +288,6 @@ CONFIG_NET=y
>  #
>  # Networking options
>  #
> -# CONFIG_NETDEBUG is not set
>  CONFIG_PACKET=y
>  # CONFIG_PACKET_MMAP is not set
>  CONFIG_UNIX=y
> @@ -300,14 +323,11 @@ CONFIG_INET_TCP_DIAG=y
>  CONFIG_TCP_CONG_CUBIC=y
>  CONFIG_DEFAULT_TCP_CONG="cubic"
>  # CONFIG_TCP_MD5SIG is not set
> -
> -#
> 

Re: [PATCH 3/5 v2] Add the platform device support with RapidIO to MPC8641HPCN platform.

[Arnd Bergmann]

On Wednesday 27 June 2007, Zhang Wei wrote:
> +static struct of_device_id mpc86xx_of_ids[] = {
> +   { .type = "soc", },
> +   { .compatible = "fsl,rapidio-delta", },
> +   {},
> +};
> +
> +static __init int mpc86xx_of_device_init(void)
> +{
> +   return of_platform_bus_probe(NULL, mpc86xx_of_ids, NULL);
> +}

This will add any devices below the "fsl,rapidio-delta" device
as an of_device. Is that what you actually want? I would guess that
you want to add the bridge itself, not the devices below it.

Is the rapidio device at the root of the device tree, and if so, why
not under the soc bus?

Arnd <><
-
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] balance parenthesis in serial core

[Andrew Morton]

On Wed, 27 Jun 2007 21:42:38 +0100
David Woodhouse <[EMAIL PROTECTED]> wrote:

> On Wed, 2007-06-27 at 13:37 -0700, Andrew Morton wrote:
> > Thanks.  so...  why shouldn't we just remove the buggy&
> > RELEVANT_CFLAG defines??
> 
> I was just about to suggest that. I originally intended to use them for
> the obvious purpose, but then realised that we can just rely on the
> integers i_speed and o_speed instead.

OK.

> Do you want a replacement/incremental patch?

I'll take care of it, thanks.
-
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: synchronize_qrcu_timeout()

[Rafael J. Wysocki]

On Wednesday, 27 June 2007 13:18, Oleg Nesterov wrote:
> On 06/26, Paul E. McKenney wrote:
> >
> > On Mon, Jun 25, 2007 at 07:49:57PM +0400, Oleg Nesterov wrote:
> > > On 06/25, Oleg Nesterov wrote:
> > > >
> > > > On 06/25, Paul E. McKenney wrote:
> > > > >
> > > > > On Mon, Jun 25, 2007 at 02:43:32PM +0400, Oleg Nesterov wrote:
> > > > > > 
> > > > > > Sadly, you can't use srcu/qrcu because it doesn't handle timeouts.  
> > > > > 
> > > > > Interesting...  So the thought is to have a synchronize_srcu_timeout()
> > > > > or something similar that waited for a grace period to elapse or for
> > > > > a timeout to expire, whichever comes first?  It should not be too hard
> > > > > to arrange something, if needed.
> > > > 
> > > > Yes. As for qrcu (see http://marc.info/?t=11648447651), I think it 
> > > > is easy.
> > > > First, we add "int interrupted" into struct qrcu_struct, then something 
> > > > like this
> > > 
> > > Even simpler, we don't need ->interrupted.
> > 
> > I have to ask...
> > 
> > What sorts of performance characteristics are needed here?  The reason
> > that I ask is because putting a straight synchronize_qrcu() into a
> > workqueue (or something similar) and then using a timer to provide
> > any needed wakeup seems a lot simpler than rearranging the innards of
> > synchronize_qrcu().
> 
> Didn't think about that... But yes, we can implement 
> synchronize_qrcu_timeout()
> on top of synchronize_qrcu() as you suggested. Hovewer, this implementation
> will add more code to .text compared to changing synchronize_qrcu().
> 
> Note also that we can't share the "context" of synchronize_qrcu_timeout() in
> that case. Each caller of synchronize_qrcu_timeout() needs a separate
> wait_queue_head_t + work_struct. This context can't live on stack, because
> it should survive after the timeout.
> 
> 
> If we change synchronize_qrcu() instead, we only add
> 
>   if (unlikely(atomic_read(qp->ctr + prv))) {
>   __wait_event_timeout(qp->wq, !atomic_read(qp->ctr + 
> prv), tout);
>   if (unlikely(!tout))
>   goto out;
>   }
> 
> to the slow path. This has nearly zero perfomance penalty. Yes, we have
> to wait if the previous call was interrupted by timeout. But in that case
> we lost nothing, we spend the same time waiting for qp->mutex when the
> previous call succeeds.
> 
> 
> That said, I am not sure synchronize_Xrcu_timeout() is terribly useful.
> Rafael could use it, but it is not better for this particular case.
> Except the code re-use, which is always good.

Well, if there are more cases in which it's useful, we'll be able to modify
this code to use it too in the future.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
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/