[PATCH][AGPGART] intel_agp: don't load if no IGD and AGP port

[Wang Zhenyu]

Thanks Carlo to report this problem. The following patch should fix
his and potential issue.

[AGPGART] intel_agp: don't load if no IGD detected and no AGP port

After i915 chip, GMCH has no AGP port. Origin bridge driver in device
table will try to access illegal regs like APBASE, APSIZE, etc. This
may cause problem.

So mark them as NULL in the table, we won't load if no IGD got detect
and bridge has no AGP port.

Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]>
---
 drivers/char/agp/intel-agp.c |   35 +++
 1 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 0439ee9..a124060 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -1843,35 +1843,35 @@ static const struct intel_driver_description {
_845_driver, _830_driver },
{ PCI_DEVICE_ID_INTEL_82875_HB, 0, 0, "i875", _845_driver, NULL },
{ PCI_DEVICE_ID_INTEL_82915G_HB, PCI_DEVICE_ID_INTEL_82915G_IG, 0, 
"915G",
-   _845_driver, _915_driver },
+   NULL, _915_driver },
{ PCI_DEVICE_ID_INTEL_82915GM_HB, PCI_DEVICE_ID_INTEL_82915GM_IG, 0, 
"915GM",
-   _845_driver, _915_driver },
+   NULL, _915_driver },
{ PCI_DEVICE_ID_INTEL_82945G_HB, PCI_DEVICE_ID_INTEL_82945G_IG, 0, 
"945G",
-   _845_driver, _915_driver },
+   NULL, _915_driver },
{ PCI_DEVICE_ID_INTEL_82945GM_HB, PCI_DEVICE_ID_INTEL_82945GM_IG, 1, 
"945GM",
-   _845_driver, _915_driver },
+   NULL, _915_driver },
{ PCI_DEVICE_ID_INTEL_82945GM_HB, PCI_DEVICE_ID_INTEL_82945GME_IG, 0, 
"945GME",
-   _845_driver, _915_driver },
+   NULL, _915_driver },
{ PCI_DEVICE_ID_INTEL_82946GZ_HB, PCI_DEVICE_ID_INTEL_82946GZ_IG, 0, 
"946GZ",
-   _845_driver, _i965_driver },
+   NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965G_1_HB, PCI_DEVICE_ID_INTEL_82965G_1_IG, 0, 
"965G",
-   _845_driver, _i965_driver },
+   NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965Q_HB, PCI_DEVICE_ID_INTEL_82965Q_IG, 0, 
"965Q",
-   _845_driver, _i965_driver },
+   NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965G_HB, PCI_DEVICE_ID_INTEL_82965G_IG, 0, 
"965G",
-   _845_driver, _i965_driver },
+   NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965GM_HB, PCI_DEVICE_ID_INTEL_82965GM_IG, 1, 
"965GM",
-   _845_driver, _i965_driver },
+   NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965GM_HB, PCI_DEVICE_ID_INTEL_82965GME_IG, 0, 
"965GME/GLE",
-   _845_driver, _i965_driver },
+   NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_7505_0, 0, 0, "E7505", _7505_driver, NULL },
{ PCI_DEVICE_ID_INTEL_7205_0, 0, 0, "E7205", _7505_driver, NULL },
{ PCI_DEVICE_ID_INTEL_G33_HB, PCI_DEVICE_ID_INTEL_G33_IG, 0, "G33",
-   _845_driver, _g33_driver },
+   NULL, _g33_driver },
{ PCI_DEVICE_ID_INTEL_Q35_HB, PCI_DEVICE_ID_INTEL_Q35_IG, 0, "Q35",
-   _845_driver, _g33_driver },
+   NULL, _g33_driver },
{ PCI_DEVICE_ID_INTEL_Q33_HB, PCI_DEVICE_ID_INTEL_Q33_IG, 0, "Q33",
-   _845_driver, _g33_driver },
+   NULL, _g33_driver },
{ 0, 0, 0, NULL, NULL, NULL }
 };
 
@@ -1917,8 +1917,11 @@ static int __devinit agp_intel_probe(struct pci_dev 
*pdev,
}
 
if (bridge->driver == NULL) {
-   printk(KERN_WARNING PFX "Failed to find bridge device "
-   "(chip_id: %04x)\n", 
intel_agp_chipsets[i].gmch_chip_id);
+   /* bridge has no AGP and no IGD detected */
+   if (cap_ptr)
+   printk(KERN_WARNING PFX "Failed to find bridge device "
+   "(chip_id: %04x)\n",
+   intel_agp_chipsets[i].gmch_chip_id);
agp_put_bridge(bridge);
return -ENODEV;
 }
-- 
1.4.4.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Lennart Sorensen]

On Tue, Jun 19, 2007 at 07:28:22PM +0400, Manu Abraham wrote:
> Well, it is not Tivo alone -- look at http://aminocom.com/ for an
> example. If you want the kernel sources pay USD 50k and we will provide
> the kernel sources, was their attitude.

Hmm, set top boxes are often rented from the cable company rather than
sold.  Stupid grey area for sure.  At least tivo does give you the
sources, without demanding more money.  Rather big difference.

> Well, it is not Tivo alone, a large chunk of the vendors do that. The
> vendors who actually do it the clean way are just few and can be counted
> very easily.

Well at least where I work we don't try to lock down the hardware, we do
contribute our changes and bug fixes to upstream when it makes sense
(and where our changes wouldn't make sense for upstream, they are still
clearly included with the sources we have.)  If a customer wants a copy
of the sources, they will get a nice DVD, although strangely none have
asked for one yet.

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

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

[david]

On Thu, 21 Jun 2007, Alexandre Oliva wrote:


On Jun 20, 2007, [EMAIL PROTECTED] wrote:


On Wed, 20 Jun 2007, Alexandre Oliva wrote:

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

On Jun 20, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote:


However, I don't see how this would ever require a company like Tivo
or Mastercard to have their networks play nice with a unit that has
been modified by the end user, potentially opening up some serious
security holes.


Which is why the GPLv3 doesn't make the requirement that you stated.



so if the BIOS checked the checksum of the boot image and if it found
it wasn't correct would disable the video input hardware but let you
boot the system otherwise it would be acceptable to you and the GPLv3?


I don't think so, but IANAL.  What do you think?  Here's what I
think to be the relevant passages.

 [...] The information must suffice to ensure that the continued
 functioning of the modified object code is in no case prevented or
 interfered with solely because modification has been made.

 [...]

 The requirement to provide Installation Information does not include
 a requirement to continue to provide support service, warranty, or
 updates for a work that has been modified or installed by the
 recipient, or for the User Product in which it has been modified or
 installed.  Network access may be denied when the modification
 itself materially and adversely affects the operation of the network
 or violates the rules and protocols for communication across the
 network.


Ok, so if refusing to run software that's tampered with isn't acceptable, 
and disabling the hardware that would be needed to talk on the network 
isn't acceptable. how exactly can they prevent a system that's been 
tampered with from accessing their network? (something even you say they 
have a right to do)


asking a device that's running software that you haven't verified to give 
you a checksum of itself isn't going to work becouse the software can just 
lie to you.


you claim they have this right, but then claim to prohibit every possible 
method of them excercising that right.


pick one side or the other, you don't get both.

David Lang
-
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: [31/37] Large blocksize support: Core piece

[Christoph Lameter]

On Wed, 20 Jun 2007, Bob Picco wrote:

> > +   if (size > (PAGE_SIZE << MAX_ORDER) || size < 512 ||
> > +   !is_power_of_2(size))
> I think this should be:
>   if (size > (MAX_ORDER_NR_PAGES << PAGE_SHIFT) ... 
>   or
>   if (size > (PAGE_SIZE << (MAX_ORDER - 1)) ...
> bob
> > return -EINVAL;


Right MAX_ORDER is the first illegal order not the last usable.

-
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: [1/2] 2.6.22-rc5: known regressions with patches

[Arjan van de Ven]

On Wed, 2007-06-20 at 16:50 -0700, Linus Torvalds wrote:
> 
> On Wed, 20 Jun 2007, Arjan van de Ven wrote:
> > 
> > the real fix would be something like this instead:
> 
> If people can test this, and confirm it works, please send a patch that 
> not only does this ad undoes the Kconfig language.  It looks like the 
> right thing to do, but I won't touch it without somebody who actually 
> tested these combinarions sending in a patch.

Hi,

I have tested this on x86_64, and without the config language, the
original oopses, while with the patch below it works fine (as expected).
I've not been able to test the i386 one (no 32 bit testboxes since 2
years) but the change is even simpler there, just an ifdef around the
entire kernel text marking.



Do not mark the kernel text read only if KPROBES is in the kernel;
kprobes needs to hot-patch the kernel text to insert it's
instrumentation. In this case, only mark the .rodata segment as read
only.

Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>

--- linux-2.6.22-rc5/arch/i386/Kconfig.debug.org2007-06-20 
22:20:30.0 -0700
+++ linux-2.6.22-rc5/arch/i386/Kconfig.debug2007-06-20 22:20:55.0 
-0700
@@ -49,7 +49,6 @@ config DEBUG_PAGEALLOC
 config DEBUG_RODATA
bool "Write protect kernel read-only data structures"
depends on DEBUG_KERNEL
-   depends on !KPROBES # temporary for 2.6.22
help
  Mark the kernel read-only data as write-protected in the pagetables,
  in order to catch accidental (and incorrect) writes to such const
--- linux-2.6.22-rc5/arch/x86_64/Kconfig.debug.org  2007-06-20 
22:20:28.0 -0700
+++ linux-2.6.22-rc5/arch/x86_64/Kconfig.debug  2007-06-20 22:20:44.0 
-0700
@@ -9,7 +9,6 @@ source "lib/Kconfig.debug"
 config DEBUG_RODATA
bool "Write protect kernel read-only data structures"
depends on DEBUG_KERNEL
-   depends on !KPROBES # temporary for 2.6.22
help
 Mark the kernel read-only data as write-protected in the pagetables,
 in order to catch accidental (and incorrect) writes to such const data.
--- linux-2.6.22-rc5/arch/i386/mm/init.c.org2007-06-20 22:18:40.0 
-0700
+++ linux-2.6.22-rc5/arch/i386/mm/init.c2007-06-20 22:19:45.0 
-0700
@@ -799,6 +799,7 @@ void mark_rodata_ro(void)
unsigned long start = PFN_ALIGN(_text);
unsigned long size = PFN_ALIGN(_etext) - start;
 
+#ifndef CONFIG_KPROBES
 #ifdef CONFIG_HOTPLUG_CPU
/* It must still be possible to apply SMP alternatives. */
if (num_possible_cpus() <= 1)
@@ -808,7 +809,7 @@ void mark_rodata_ro(void)
 size >> PAGE_SHIFT, PAGE_KERNEL_RX);
printk("Write protecting the kernel text: %luk\n", size >> 10);
}
-
+#endif
start += size;
size = (unsigned long)__end_rodata - start;
change_page_attr(virt_to_page(start),
--- linux-2.6.22-rc5/arch/x86_64/mm/init.c.org  2007-06-20 21:44:15.0 
-0700
+++ linux-2.6.22-rc5/arch/x86_64/mm/init.c  2007-06-20 22:17:45.0 
-0700
@@ -605,6 +605,11 @@ void mark_rodata_ro(void)
if (num_possible_cpus() > 1)
start = (unsigned long)_etext;
 #endif
+
+#ifdef CONFIG_KPROBES
+   start = (unsigned long)__start_rodata;
+#endif
+   
end = (unsigned long)__end_rodata;
start = (start + PAGE_SIZE - 1) & PAGE_MASK;
end &= PAGE_MASK;

-- 
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: [RFC PATCH 1/4] Union mount documentation.

[Bharata B Rao]

On 6/20/07, Erez Zadok <[EMAIL PROTECTED]> wrote:

In message <[EMAIL PROTECTED]>, Jan Blunck writes:
> On Tue, 19 Jun 2007 22:59:51 -0700, Arjan van de Ven wrote:
>
> > first of all I'm happy to see that people are still working on unionfs;
> > I'd love to have functionality like this show up in Linux.
>
> This has nothing to do with unionfs. This is about doing a VFS based
> approach to union mounts. Unification is a name-based construct so it
> belongs into VFS and not into a separate file system.

Jan, while I agree with you in principle that unification is a VFS-level
namespace construct, I disagree with you that unioning doesn't belong in a
separate f/s.

As someone whose group developed three generations of the stackable file
system Unionfs (see http://unionfs.filesystems.org/), I can tell you from my
experience and the experience of numerous users, that the devil is the
details -- or the so-called orthogonal issues.  To get a fully working
unioning implementation, one that the many current users of Unionfs could
use, you'll have to deal with many issues and corner cases: cache coherency,
inode persistency (and network f/s exports), copyups, whiteouts and opaque
dirs, how to deal with "odd" file systems which don't support native
whiteouts and such, directory reading (seekdir), and more.  Our third
generation Unionfs, the one with On-Disk Format (ODF), handles all of these.
Rather than reproduce all that discussion here, I'll point people to read
more info here: 


Erez, thanks, will definetely have to look at that to understand how
unionfs is addressing all these corner cases.

Though I don't understand all the issues involved with cache coherency
atm, one of the things you said during unionfs 2.0 release is that it
is now possible to make modifications to the lower layer directly and
they will be visible from the union. Note that since we do unioning at
VFS layer, we don't explicitly address this. Direct
modifications/additions to the lower layer will automatically get
reflected in the union. Anyway before commenting anything more on
this, let me get back and study the coherency issues more closely :)



So, to have a fully usable union mounts implementation, you're going to have
to support a lot of existing features; but if you were to support them all
at the VFS level, you will have bloated the VFS considerably with stuff that
many would argue does not belong in the VFS.


Talking about copyup and whiteout at VFS layer, we have already
demonstrated what complexity it takes to have these within VFS. Please
take a look at the copyup and whiteout patches in our previous
releases at:

http://lkml.org/lkml/2007/4/17/150
http://lkml.org/lkml/2007/5/14/69

Or may be wait till I clean all those up to work with the new union
new stack infrastructure which I have posted here.

Regards,
Bharata.
--
"Men come and go but mountains remain" -- Ruskin Bond.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alexandre Oliva]

On Jun 20, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:

> It allows everybody do make that choice that I consider to be really 
> important: the choice of how something _you_ designed gets used.

> And it does that exactly by *limiting* the license to only that one work. 
> Not trying to extend it past the work.

Actually, the two paragraphs above are contradictory, and the second
is not true in as much as it gives way to the former.

Consider an independent file contributed to Linux.  It is an
independent work.  But the moment it gets combined with Linux, the
only license you can use is GPLv2.

Consider a patch, or any modified version of Linux.  It's another
work.  But the license applies to it as well.

Similarly, the GPL affects patents that somehow cover the work: the
distributor can no longer enforce them against downstream users of the
software.

See?

> The GPLv3 can never do that.

It does it in just the same way that GPLv1 and GPLv2 do: "no further
restrictions".  That it has to make some of them explicit, such that
people understand they apply, or such that this provision can't be
trampled on by other laws that by default trample copyright law, is
just a legal implementation detail.

> It's missing the point that "morals" are about _personal_ choices. You 
> cannot force others to a certain moral standpoint. 

FWIW, I tend to consider morals more of a society issue than an
individual issue.  Morals encode what the society understands to be
the common good, and that's often something evolutionary, even with
biological roots.

Laws (as you say) try to reflect the morals of the society, but since
it's based on morals, it often lags behind.  Which is why some laws
become forgotten and no longer applied, even if still applicable in
theory.  And that's also why (as you alluded to in your message), when
laws actively diverge from morals, you observe a lot of civil
disobedience: think DRM, DMCA, non-benevolent dictatorships and other
abusive regimes.


I must say that it *is* lovely to watch you talk about morals in ways
that I agree so much with, even if I dissent in a some details.  This
has further increased my admiration for you.  Thank you.

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

What's does KPROBE_ENTRY mean?

[jidong xiao]

I searched in linux kernel 2.6.10, didn't find it, then I tried
2.6.20, it is there. But I am not familiar with assembly language, so
can anybody kindly explain it, I don't know the difference between
KPROBE_ENTRY and ENTRY, however, I can find both of these items in
some files, such as arch/x86_64/kernel/entry.S.

Thank you.

Regards
Jason Xiao
-
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/

TUX2 filesystem

[Ph. Marek]

Hello Daniel,
hello everbody else,


in Oct 2000 there's been some discussion "Tux2 - evil patents sighted" 
(http://www.ussg.iu.edu/hypermail/linux/kernel/0010.0/0343.html), and in Aug 
2002 (http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0332.html) Daniel 
wrote
> It's well down my list of priorities because of uncertainties due to
> the U.S. patent system. 
> Does anybody want to know if patent chill exists, and is it hurting
> open source? The answer is yes. 


With the recent Supreme Court decisions 
(http://www.groklaw.net/article.php?story=20070430121005424) and the fact 
that Daniel wrote that he did most of his work in *1989* (which is now 18 
years ago!) is there a chance for newer developments?


It seems to me that this kind of filesystem could solve a few problems that 
are currently attacked:
- Atomic snapshots. Make a new superblock, and mount this copy in another
  directory. As long as it's not overwritten, it stays consistent.
- Speed/Consistency for Flash media. There is a list of superblocks, and when
  the new block has been written the pointer from the old gets set - until the
  first block in the list gets re-written.

There may be some other nice things I didn't think about - but just having 
this filesystem for harddisks might be good, too.


Regards,

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

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

[Alexandre Oliva]

On Jun 20, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote:

> On 18/06/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> Your analysis stopped at the downside of prohibiting tivoization.  You
>> didn't analyze the potential upsides,

> Maybe that's because I don't really see any up sides.

You do:

> a few vendors that currently tivoize hardware may open up their
> hardware but I doubt that will be very many

You just don't think they'd prevail over the downsides.  *This* is an
opinion I can respect, even if it's as much of a guestimate as mine.
I'm sure both are highly influenced by personal opinions, wishful
thinking and fears.  This is all very human.

>> so you may indeed come to different conclusions, and they may very
>> well be wrong.

> Just because I come to a different conclusion than you doesn't
> nessesarily make it wrong.

Agreed.  I didn't say they were.  I said they could be.  Can you prove
they're right?  Do you even have any supporting evidence to back your
guestimates?  Heck, you may even have more than I do.

I openly admit mine is mostly theoretical.  I extrapolate the initial
success of GNU+Linux on the PC environment, due in a large part to the
ability for users to tinker with their computers, and expect it not to
be so significantly different for other kinds of computers.

For sure you'll get a far lower *percentage* of hackers in consumer
devices than on PCs, whose users used to be far more
technically-inclined and thus more propense to become hackers when
GNU+Linux started than these days.

But then I think of all of these computer users who helped make
GNU+Linux what it is today, and other hackers that hadn't discovered
this inclination before because they haven't had access to hackable
computers.  They could be tinkering with their DVRs, cell phones,
wireless routers et al, and bringing the same kind of exciting
community development to these kinds of computers.

I'm saddened that the major Linux developers are willing to trade all
of this (which I openly admit may be just a figment of my imagination,
or just a tip of an iceberg) for some professional contributions
(good) and some additional exposure that won't do justice to their
software (bad), because these users will miss a big part of the
picture by not being able to tinker with the software in the
environment where they use the software.

>> It's very human to look only at the potential downside of an action
>> and conclude it's a bad action.

> And you believe yourself to be immune to that - right?

Last I looked, I was still human.  So no.  I try to use logic to
reason out such behaviors when I realize they might be in action.
But, as the saying goes, logic is a tool we use to justify our
intutions.  Or, logical reasoning is a tool to make the wrong
decisions with a greater amount of confidence ;-)

>> You can create the device using GPLv3 software in it.

> Not as long as I want to prevent the user from tampering with it, no.

mumble ROM mumble

> But do you really expect a vendor to put a device on the market where
> they also lock themselves out of upgrading it and releasing new
> software for it?

Depends on how badly they want to use the GPLed software.

Don't you guys think Linux is so technically superior that some
vendors might prefer to stick with it (should it move to GPLv3, or
tivoization be found to be already forbidden by GPLv2 in a US court or
elsewhere) even if this means going to ROM or respecting users'
freedoms?

Or are Linux advantages so thin and fragile (if they exist at all)
that you're just hoping nobody realizes there are better choices out
there, and you're desperate for vendors not to realize this?

> For a few select individuals that may be true. But for the majority of
> the population it won't mean a thing.

Agreed.  You're thinking of percentages (fewer percent hackers among
consumers of user products than among PC users).  I'm thinking all
hackers in PCs could become hackers of such devices as well, and then
some.

>> This is the upside that you left out from your analysis, and from
>> every other analysis that set out to "prove" that anti-tivoization is
>> bad that I've seen so far.

> I'm sorry, but I don't think it holds water.

Fair enough.

-- 
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: mm snapshot broken-out-2007-06-20-10-12.tar.gz uploaded

[Randy Dunlap]

Bob Picco wrote:

Randy Dunlap wrote: [Wed Jun 20 2007, 09:07:11PM EDT]

On Wed, 20 Jun 2007 20:51:22 -0400 Bob Picco wrote:


[EMAIL PROTECTED] wrote:[Wed Jun 20 2007, 01:14:34PM EDT]
[snip]

Build breakage. pci_mmcfg_late_init is for i386.

then you want CONFIG_X86_32 instead of CONFIG_X86.
CONFIG_X86 is set/true for both X86_32 and X86_64.

Then what I stated within the patch description is incorrect. pci.h which is the
required include for the declaration is conditionally for CONFIG_X86. So it is
both I guess?


Yes.


bob



Signed-off-by: Bob Picco <[EMAIL PROTECTED]>

 drivers/acpi/bus.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6.22-rc5-mm1/drivers/acpi/bus.c
===
--- linux-2.6.22-rc5-mm1.orig/drivers/acpi/bus.c2007-06-20 
14:09:07.0 -0400
+++ linux-2.6.22-rc5-mm1/drivers/acpi/bus.c 2007-06-20 20:32:00.0 
-0400
@@ -757,7 +757,9 @@ static int __init acpi_init(void)
result = acpi_bus_init();
 
 	if (!result) {

+#ifdef CONFIG_X86
pci_mmcfg_late_init();
+#endif
 #ifdef CONFIG_PM_LEGACY
if (!PM_IS_ACTIVE())
pm_active = 1;


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

[PATCH 008 of 8] knfsd: nfsd4: don't delegate files that have had conflicts

[NeilBrown]

From: "J. Bruce Fields" <[EMAIL PROTECTED]>


One more incremental delegation policy improvement: don't give out a
delegation on a file if conflicting access has previously required that
a delegation be revoked on that file.  (In practice we'll forget about
the conflict when the struct nfs4_file is removed on close, so this is
of limited use for now, though it should at least solve a temporary
problem with self-conflicts on write opens from the same client.)

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

### Diffstat output
 ./fs/nfsd/nfs4state.c|4 
 ./include/linux/nfsd/state.h |1 +
 2 files changed, 5 insertions(+)

diff .prev/fs/nfsd/nfs4state.c ./fs/nfsd/nfs4state.c
--- .prev/fs/nfsd/nfs4state.c   2007-06-21 14:14:47.0 +1000
+++ ./fs/nfsd/nfs4state.c   2007-06-21 14:16:21.0 +1000
@@ -194,6 +194,8 @@ alloc_init_deleg(struct nfs4_client *clp
struct nfs4_callback *cb = >st_stateowner->so_client->cl_callback;
 
dprintk("NFSD alloc_init_deleg\n");
+   if (fp->fi_had_conflict)
+   return NULL;
if (num_delegations > max_delegations)
return NULL;
dp = kmem_cache_alloc(deleg_slab, GFP_KERNEL);
@@ -1002,6 +1004,7 @@ alloc_init_file(struct inode *ino)
list_add(>fi_hash, _hashtbl[hashval]);
fp->fi_inode = igrab(ino);
fp->fi_id = current_fileid++;
+   fp->fi_had_conflict = false;
return fp;
}
return NULL;
@@ -1328,6 +1331,7 @@ do_recall(void *__dp)
 {
struct nfs4_delegation *dp = __dp;
 
+   dp->dl_file->fi_had_conflict = true;
nfsd4_cb_recall(dp);
return 0;
 }

diff .prev/include/linux/nfsd/state.h ./include/linux/nfsd/state.h
--- .prev/include/linux/nfsd/state.h2007-06-21 14:09:31.0 +1000
+++ ./include/linux/nfsd/state.h2007-06-21 14:16:21.0 +1000
@@ -224,6 +224,7 @@ struct nfs4_file {
struct inode*fi_inode;
u32 fi_id;  /* used with stateowner->so_id 
 * for stateid_hashtbl hash */
+   boolfi_had_conflict;
 };
 
 /*
-
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 005 of 8] knfsd: nfsd4: fix handling of acl errrors

[NeilBrown]

From: "J. Bruce Fields" <[EMAIL PROTECTED]>


nfs4_acl_nfsv4_to_posix() returns an error and returns any posix acls
calculated in two caller-provided pointers.  It was setting these
pointers to -errno in some error cases, resulting in
nfsd4_set_nfs4_acl() calling posix_acl_release() with a -errno as an
argument.

Fix both the caller and the callee, by modifying nfsd4_set_nfs4_acl() to
stop relying on the passed-in-pointers being left as NULL in the error
case, and by modifying nfs4_acl_nfsv4_to_posix() to stop returning
garbage in those pointers.

Thanks to Alex Soule for reporting the bug.

Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]>
Cc: Alexander Soule <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./fs/nfsd/nfs4acl.c |3 +++
 ./fs/nfsd/vfs.c |   22 +++---
 2 files changed, 10 insertions(+), 15 deletions(-)

diff .prev/fs/nfsd/nfs4acl.c ./fs/nfsd/nfs4acl.c
--- .prev/fs/nfsd/nfs4acl.c 2007-06-21 14:10:06.0 +1000
+++ ./fs/nfsd/nfs4acl.c 2007-06-21 14:11:02.0 +1000
@@ -737,13 +737,16 @@ int nfs4_acl_nfsv4_to_posix(struct nfs4_
*pacl = posix_state_to_acl(_acl_state, flags);
if (IS_ERR(*pacl)) {
ret = PTR_ERR(*pacl);
+   *pacl = NULL;
goto out_dstate;
}
*dpacl = posix_state_to_acl(_acl_state,
flags | NFS4_ACL_TYPE_DEFAULT);
if (IS_ERR(*dpacl)) {
ret = PTR_ERR(*dpacl);
+   *dpacl = NULL;
posix_acl_release(*pacl);
+   *pacl = NULL;
goto out_dstate;
}
sort_pacl(*pacl);

diff .prev/fs/nfsd/vfs.c ./fs/nfsd/vfs.c
--- .prev/fs/nfsd/vfs.c 2007-06-21 13:46:38.0 +1000
+++ ./fs/nfsd/vfs.c 2007-06-21 14:11:02.0 +1000
@@ -435,7 +435,7 @@ nfsd4_set_nfs4_acl(struct svc_rqst *rqst
/* Get inode */
error = fh_verify(rqstp, fhp, 0 /* S_IFREG */, MAY_SATTR);
if (error)
-   goto out;
+   return error;
 
dentry = fhp->fh_dentry;
inode = dentry->d_inode;
@@ -444,33 +444,25 @@ nfsd4_set_nfs4_acl(struct svc_rqst *rqst
 
host_error = nfs4_acl_nfsv4_to_posix(acl, , , flags);
if (host_error == -EINVAL) {
-   error = nfserr_attrnotsupp;
-   goto out;
+   return nfserr_attrnotsupp;
} else if (host_error < 0)
goto out_nfserr;
 
host_error = set_nfsv4_acl_one(dentry, pacl, POSIX_ACL_XATTR_ACCESS);
if (host_error < 0)
-   goto out_nfserr;
+   goto out_release;
 
-   if (S_ISDIR(inode->i_mode)) {
+   if (S_ISDIR(inode->i_mode))
host_error = set_nfsv4_acl_one(dentry, dpacl, 
POSIX_ACL_XATTR_DEFAULT);
-   if (host_error < 0)
-   goto out_nfserr;
-   }
-
-   error = nfs_ok;
 
-out:
+out_release:
posix_acl_release(pacl);
posix_acl_release(dpacl);
-   return (error);
 out_nfserr:
if (host_error == -EOPNOTSUPP)
-   error = nfserr_attrnotsupp;
+   return nfserr_attrnotsupp;
else
-   error = nfserrno(host_error);
-   goto out;
+   return nfserrno(host_error);
 }
 
 static struct posix_acl *
-
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 006 of 8] knfsd: nfsd: remove unused header interface.h

[NeilBrown]

From: "J. Bruce Fields" <[EMAIL PROTECTED]>


It looks like Al Viro gutted this header file five years ago and it
hasn't been touched since.

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

### Diffstat output
 ./fs/nfsd/nfsctl.c   |1 -
 ./include/linux/nfsd/interface.h |   13 -
 ./include/linux/nfsd/nfsd.h  |1 -
 3 files changed, 15 deletions(-)

diff .prev/fs/nfsd/nfsctl.c ./fs/nfsd/nfsctl.c
--- .prev/fs/nfsd/nfsctl.c  2007-06-21 13:46:36.0 +1000
+++ ./fs/nfsd/nfsctl.c  2007-06-21 14:13:57.0 +1000
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 

diff .prev/include/linux/nfsd/interface.h ./include/linux/nfsd/interface.h
--- .prev/include/linux/nfsd/interface.h2007-06-21 13:46:36.0 
+1000
+++ ./include/linux/nfsd/interface.h1970-01-01 10:00:00.0 +1000
@@ -1,13 +0,0 @@
-/*
- * include/linux/nfsd/interface.h
- *
- * defines interface between nfsd and other bits of
- * the kernel.  Particularly filesystems (eventually).
- *
- * Copyright (C) 2000 Neil Brown <[EMAIL PROTECTED]>
- */
-
-#ifndef LINUX_NFSD_INTERFACE_H
-#define LINUX_NFSD_INTERFACE_H
-
-#endif /* LINUX_NFSD_INTERFACE_H */

diff .prev/include/linux/nfsd/nfsd.h ./include/linux/nfsd/nfsd.h
--- .prev/include/linux/nfsd/nfsd.h 2007-06-21 13:46:36.0 +1000
+++ ./include/linux/nfsd/nfsd.h 2007-06-21 14:13:57.0 +1000
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 /*
  * nfsd version
  */
-
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 007 of 8] knfsd: nfsd4: vary maximum delegation limit based on RAM size

[NeilBrown]

From: "J. Bruce Fields" <[EMAIL PROTECTED]>


Our original NFSv4 delegation policy was to give out a read delegation
on any open when it was possible to.

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.

Our first quick solution was to add a hard-coded limit.  This patch
makes a mild incremental improvement by varying that limit according to
the server's total memory size, allowing at most 4 delegations per
megabyte of RAM.

My quick back-of-the-envelope calculation finds that in the worst case
(where every delegation is for a different inode), a delegation could
take about 1.5K, which would make the worst case usage about 6% of
memory.  The new limit works out to be about the same as the old on a
1-gig server.

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

### Diffstat output
 ./fs/nfsd/nfs4state.c   |   15 ++-
 ./include/linux/nfsd/nfsd.h |1 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff .prev/fs/nfsd/nfs4state.c ./fs/nfsd/nfs4state.c
--- .prev/fs/nfsd/nfs4state.c   2007-06-21 14:09:23.0 +1000
+++ ./fs/nfsd/nfs4state.c   2007-06-21 14:14:47.0 +1000
@@ -150,6 +150,7 @@ get_nfs4_file(struct nfs4_file *fi)
 }
 
 static int num_delegations;
+unsigned int max_delegations = 0;
 
 /*
  * Open owner state (share locks)
@@ -193,7 +194,7 @@ alloc_init_deleg(struct nfs4_client *clp
struct nfs4_callback *cb = >st_stateowner->so_client->cl_callback;
 
dprintk("NFSD alloc_init_deleg\n");
-   if (num_delegations > STATEID_HASH_SIZE * 4)
+   if (num_delegations > max_delegations)
return NULL;
dp = kmem_cache_alloc(deleg_slab, GFP_KERNEL);
if (dp == NULL)
@@ -3198,6 +3199,17 @@ get_nfs4_grace_period(void)
return max(user_lease_time, lease_time) * HZ;
 }
 
+static void
+set_max_delegations()
+{
+   struct sysinfo sys;
+
+   si_meminfo();
+   sys.totalram *= sys.mem_unit;
+   sys.totalram >>= (18 - PAGE_SHIFT);
+   max_delegations = (unsigned int) sys.totalram;
+}
+
 /* initialization to perform when the nfsd service is started: */
 
 static void
@@ -3213,6 +3225,7 @@ __nfs4_state_start(void)
   grace_time/HZ);
laundry_wq = create_singlethread_workqueue("nfsd4");
queue_delayed_work(laundry_wq, _work, grace_time);
+   set_max_delegations();
 }
 
 int

diff .prev/include/linux/nfsd/nfsd.h ./include/linux/nfsd/nfsd.h
--- .prev/include/linux/nfsd/nfsd.h 2007-06-21 14:13:57.0 +1000
+++ ./include/linux/nfsd/nfsd.h 2007-06-21 14:14:47.0 +1000
@@ -148,6 +148,7 @@ extern int nfsd_max_blksize;
  * NFSv4 State
  */
 #ifdef CONFIG_NFSD_V4
+extern unsigned int max_delegations;
 void nfs4_state_init(void);
 int nfs4_state_start(void);
 void nfs4_state_shutdown(void);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alexandre Oliva]

On Jun 20, 2007, [EMAIL PROTECTED] wrote:

> On Wed, 20 Jun 2007, Alexandre Oliva wrote:
>> We already know the vendor doesn't care about the user, so why should
>> we take this into account when analyzing the reasoning of the vendor?

> no, we don't know this. you attribute the reason for the lockdown to
> be anti-user. others view it as being pro-user becouse it lets the
> user get functionality that they wouldn't have access to otherwise.

Yeah, yeah, now please put your hands to the back such that I can
place your handcuffs, such that you can't use your hands to kill
someone.  Well, you might still be able to use your hands for this
purpose if you're really clever, or you can kill people by other
means.  But at least I'll be able to claim that I did my part.

:-/

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

[PATCH 004 of 8] knfsd: nfsd4: fix enc_stateid_sz for nfsd callbacks

[NeilBrown]

From: "J. Bruce Fields" <[EMAIL PROTECTED]>


enc_stateid_sz should be given in u32 words units, not bytes, so we were
overestimating the buffer space needed here.

Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./fs/nfsd/nfs4callback.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff .prev/fs/nfsd/nfs4callback.c ./fs/nfsd/nfs4callback.c
--- .prev/fs/nfsd/nfs4callback.c2007-06-21 13:46:38.0 +1000
+++ ./fs/nfsd/nfs4callback.c2007-06-21 14:10:31.0 +1000
@@ -75,7 +75,7 @@ enum nfs_cb_opnum4 {
 #define op_enc_sz  1
 #define op_dec_sz  2
 #define enc_nfs4_fh_sz (1 + (NFS4_FHSIZE >> 2))
-#define enc_stateid_sz 16
+#define enc_stateid_sz (NFS4_STATEID_SIZE >> 2)
 #define NFS4_enc_cb_recall_sz  (cb_compound_enc_hdr_sz +   \
1 + enc_stateid_sz +\
enc_nfs4_fh_sz)
-
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 001 of 8] knfsd: lockd: nfsd4: use same grace period for lockd and nfsd4

[NeilBrown]

From: "J. Bruce Fields" <[EMAIL PROTECTED]>

Both lockd and (in the nfsv4 case) nfsd enforce a "grace period" after
reboot, during which clients may reclaim locks from the previous server
instance, but may not acquire new locks.

Currently the lockd and nfsd enforce grace periods of different lengths.
This may cause problems when we reboot a server with both v2/v3 and v4
clients.  For example, if the lockd grace period is shorter (as is likely
the case), then a v3 client might acquire a new lock that conflicts with a
lock already held (but not yet reclaimed) by a v4 client.

This patch calculates a lease time that lockd and nfsd can both use.

Signed-off-by: Marc Eshel <[EMAIL PROTECTED]>
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./fs/lockd/svc.c |   27 ---
 ./fs/nfsd/lockd.c|1 +
 ./fs/nfsd/nfs4state.c|   16 
 ./include/linux/lockd/bind.h |9 +
 4 files changed, 42 insertions(+), 11 deletions(-)

diff .prev/fs/lockd/svc.c ./fs/lockd/svc.c
--- .prev/fs/lockd/svc.c2007-06-21 14:08:51.0 +1000
+++ ./fs/lockd/svc.c2007-06-21 13:52:05.0 +1000
@@ -76,18 +76,31 @@ static const intnlm_port_min = 0, nlm_
 
 static struct ctl_table_header * nlm_sysctl_table;
 
-static unsigned long set_grace_period(void)
+static unsigned long get_lockd_grace_period(void)
 {
-   unsigned long grace_period;
-
/* Note: nlm_timeout should always be nonzero */
if (nlm_grace_period)
-   grace_period = ((nlm_grace_period + nlm_timeout - 1)
-   / nlm_timeout) * nlm_timeout * HZ;
+   return roundup(nlm_grace_period, nlm_timeout) * HZ;
else
-   grace_period = nlm_timeout * 5 * HZ;
+   return nlm_timeout * 5 * HZ;
+}
+
+unsigned long get_nfs_grace_period(void)
+{
+   unsigned long lockdgrace = get_lockd_grace_period();
+   unsigned long nfsdgrace = 0;
+
+   if (nlmsvc_ops)
+   nfsdgrace = nlmsvc_ops->get_grace_period();
+
+   return max(lockdgrace, nfsdgrace);
+}
+EXPORT_SYMBOL(get_nfs_grace_period);
+
+static unsigned long set_grace_period(void)
+{
nlmsvc_grace_period = 1;
-   return grace_period + jiffies;
+   return get_nfs_grace_period() + jiffies;
 }
 
 static inline void clear_grace_period(void)

diff .prev/fs/nfsd/lockd.c ./fs/nfsd/lockd.c
--- .prev/fs/nfsd/lockd.c   2007-06-21 14:08:51.0 +1000
+++ ./fs/nfsd/lockd.c   2007-06-21 13:46:56.0 +1000
@@ -65,6 +65,7 @@ nlm_fclose(struct file *filp)
 static struct nlmsvc_binding   nfsd_nlm_ops = {
.fopen  = nlm_fopen,/* open file for locking */
.fclose = nlm_fclose,   /* close file */
+   .get_grace_period = get_nfs4_grace_period,
 };
 
 void

diff .prev/fs/nfsd/nfs4state.c ./fs/nfsd/nfs4state.c
--- .prev/fs/nfsd/nfs4state.c   2007-06-21 14:08:51.0 +1000
+++ ./fs/nfsd/nfs4state.c   2007-06-21 14:09:23.0 +1000
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NFSDDBG_FACILITYNFSDDBG_PROC
 
@@ -3191,20 +3192,27 @@ nfsd4_load_reboot_recovery_data(void)
printk("NFSD: Failure reading reboot recovery data\n");
 }
 
+unsigned long
+get_nfs4_grace_period(void)
+{
+   return max(user_lease_time, lease_time) * HZ;
+}
+
 /* initialization to perform when the nfsd service is started: */
 
 static void
 __nfs4_state_start(void)
 {
-   time_t grace_time;
+   unsigned long grace_time;
 
boot_time = get_seconds();
-   grace_time = max(user_lease_time, lease_time);
+   grace_time = get_nfs_grace_period();
lease_time = user_lease_time;
in_grace = 1;
-   printk("NFSD: starting %ld-second grace period\n", grace_time);
+   printk(KERN_INFO "NFSD: starting %ld-second grace period\n",
+  grace_time/HZ);
laundry_wq = create_singlethread_workqueue("nfsd4");
-   queue_delayed_work(laundry_wq, _work, grace_time*HZ);
+   queue_delayed_work(laundry_wq, _work, grace_time);
 }
 
 int

diff .prev/include/linux/lockd/bind.h ./include/linux/lockd/bind.h
--- .prev/include/linux/lockd/bind.h2007-06-21 14:08:51.0 +1000
+++ ./include/linux/lockd/bind.h2007-06-21 13:46:56.0 +1000
@@ -27,6 +27,7 @@ struct nlmsvc_binding {
struct nfs_fh *,
struct file **);
void(*fclose)(struct file *);
+   unsigned long   (*get_grace_period)(void);
 };
 
 extern struct nlmsvc_binding * nlmsvc_ops;
@@ -38,4 +39,12 @@ extern int   nlmclnt_proc(struct inode *, 
 extern int lockd_up(int proto);
 extern voidlockd_down(void);
 
+unsigned long get_nfs_grace_period(void);
+
+#ifdef CONFIG_NFSD_V4
+unsigned long 

[PATCH 002 of 8] knfsd: nfsd4: fix NFSv4 filehandle size units confusion

[NeilBrown]

From: "J. Bruce Fields" <[EMAIL PROTECTED]>


NFS4_FHSIZE is measured in bytes, not 4-byte words, so much more space
than necessary is being allocated for struct nfs4_cb_recall.

I should have wondered why this structure was so much larger than it
needed to be!

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

### Diffstat output
 ./include/linux/nfsd/state.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff .prev/include/linux/nfsd/state.h ./include/linux/nfsd/state.h
--- .prev/include/linux/nfsd/state.h2007-06-21 13:46:39.0 +1000
+++ ./include/linux/nfsd/state.h2007-06-21 14:09:31.0 +1000
@@ -67,7 +67,7 @@ struct nfs4_cb_recall {
int cbr_trunc;
stateid_t   cbr_stateid;
u32 cbr_fhlen;
-   u32 cbr_fhval[NFS4_FHSIZE];
+   charcbr_fhval[NFS4_FHSIZE];
struct nfs4_delegation  *cbr_dp;
 };
 
-
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 003 of 8] knfsd: nfsd4: silence a compiler warning in ACL code

[NeilBrown]

From: "J. Bruce Fields" <[EMAIL PROTECTED]>


Silence a compiler warning in the ACL code, and add a comment making
clear the initialization serves no other purpose.

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

### Diffstat output
 ./fs/nfsd/nfs4acl.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff .prev/fs/nfsd/nfs4acl.c ./fs/nfsd/nfs4acl.c
--- .prev/fs/nfsd/nfs4acl.c 2007-06-21 13:46:39.0 +1000
+++ ./fs/nfsd/nfs4acl.c 2007-06-21 14:10:06.0 +1000
@@ -183,8 +183,13 @@ static void
 summarize_posix_acl(struct posix_acl *acl, struct posix_acl_summary *pas)
 {
struct posix_acl_entry *pa, *pe;
-   pas->users = 0;
-   pas->groups = 0;
+
+   /*
+* Only pas.users and pas.groups need initialization; previous
+* posix_acl_valid() calls ensure that the other fields will be
+* initialized in the following loop.  But, just to placate gcc:
+*/
+   memset(pas, 0, sizeof(*pas));
pas->mask = 07;
 
pe = acl->a_entries + acl->a_count;
-
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 000 of 8] knfsd: Assorted nfsv4 server patches.

[NeilBrown]

Following 8 patches fix minor bug and provide minor enhancements for
nfsv4 service.  They all have "no obvious style problems" and are
"ready for submission".

They are appropriate for inclusion in 2.6.23-rc1.
They are against 2.6.22-rc4-mm2.

Thanks,
NeilBrown


 [PATCH 001 of 8] knfsd: lockd: nfsd4: use same grace period for lockd and nfsd4
 [PATCH 002 of 8] knfsd: nfsd4: fix NFSv4 filehandle size units confusion
 [PATCH 003 of 8] knfsd: nfsd4: silence a compiler warning in ACL code
 [PATCH 004 of 8] knfsd: nfsd4: fix enc_stateid_sz for nfsd callbacks
 [PATCH 005 of 8] knfsd: nfsd4: fix handling of acl errrors
 [PATCH 006 of 8] knfsd: nfsd: remove unused header interface.h
 [PATCH 007 of 8] knfsd: nfsd4: vary maximum delegation limit based on RAM size
 [PATCH 008 of 8] knfsd: nfsd4: don't delegate files that have had conflicts
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alexandre Oliva]

On Jun 20, 2007, [EMAIL PROTECTED] wrote:

> On Wed, 20 Jun 2007, Alexandre Oliva wrote:
>> Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
>> 
>> On Jun 20, 2007, Andrew McKay <[EMAIL PROTECTED]> wrote:
>> 
>>> However, I don't see how this would ever require a company like Tivo
>>> or Mastercard to have their networks play nice with a unit that has
>>> been modified by the end user, potentially opening up some serious
>>> security holes.
>> 
>> Which is why the GPLv3 doesn't make the requirement that you stated.

> so if the BIOS checked the checksum of the boot image and if it found
> it wasn't correct would disable the video input hardware but let you
> boot the system otherwise it would be acceptable to you and the GPLv3?

I don't think so, but IANAL.  What do you think?  Here's what I
think to be the relevant passages.

  [...] The information must suffice to ensure that the continued
  functioning of the modified object code is in no case prevented or
  interfered with solely because modification has been made.

  [...]

  The requirement to provide Installation Information does not include
  a requirement to continue to provide support service, warranty, or
  updates for a work that has been modified or installed by the
  recipient, or for the User Product in which it has been modified or
  installed.  Network access may be denied when the modification
  itself materially and adversely affects the operation of the network
  or violates the rules and protocols for communication across the
  network.

-- 
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 20, 2007, "Tomas Neme" <[EMAIL PROTECTED]> wrote:

>> > However, I don't see how this would ever require a company like Tivo
>> > or Mastercard to have their networks play nice with a unit that has
>> > been modified by the end user, potentially opening up some serious
>> > security holes.
>> 
>> Which is why the GPLv3 doesn't make the requirement that you stated.

> Why, if you let user-compiled kernels to run in a TiVo, it might be
> modified so the TiVo can be used to pirate-copy protected content,

And then the user who uses such features in ways not permitted by the
copyright holders are committing a crime.  They can be prosecuted by
the copyright holders and convicted of the crime.

That TiVo can somehow become liable for this just shows how broken the
legal system in the US is.  It's like making a knife manufacturer
liable for a killing using a knife they made, just because the knife
didn't have technical measures intended to prevent the knife from
being used to kill people.

-- 
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 20, 2007, [EMAIL PROTECTED] wrote:

> On Wed, 20 Jun 2007, Alexandre Oliva wrote:
>> On Jun 20, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote:
 It is the duty of the FSF to defend these freedoms.  It's its public
 mission.  That's a publicly stated goal of the GPL, for anyone who
 cares to understand it, or miss it completely and then complain about
 changes in spirit.
>> 
>>> I wouldn't call it a duty.  It is the chosen mission perhaps, but nobody
>>> is making them do it.
>> 
>> Everyone who donates to it does so understanding what the mission is.
>> Detracting from that mission would be failing the public commitment.

> true, but selecting the GPL as the license for your project is not
> donating to the FSF.

Oh, that's what you meant.  Indeed, absolutely not.

The GPL is "just" a set of permissions you, as an author, grant to
anyone who comes across your program.

Whether you share FSF's goals or not, you can do that.

If you share FSF's goals of not only respecting users' freedoms, but
also defending them as much as deemed legally possible under copyright
law, you can also offer your code under any later version of the GPL,
such that it remains usable by the community who cares about this.

In theory, this shouldn't be a problem for anyone who chose the GPLv2,
since all of the permissions granted by GPLv3 are granted by GPLv2,
and this is how it should be.  The difference is that GPLv3 plugs some
holes that were found in GPLv2, in a similar way that GPLv2 plugged
holes found in GPLv1, and GPL "plugs holes" in LGPL, which "plugs
holes" in other even more permissive licenses.

Each GPL revision is expected to plug holes ("address new problems",
as in the legal terms of GPLv2) that might enable licensees to deny
other licensees the rights you meant to grant them.

This will necessarily make each revision incompatible with the
previous, for being stricter, thus imposing further restrictions, even
if only by removing exploitable ambiguities.  This should have been
clear since GPLv1, anyone who understands the goals of the GPL and
with enough foresight to understand the recommendation of permitting
relicensing under newer versions should be able to see this.

So, since new restrictions are always on licensees' ways to deny other
licensees the enjoyment of the permissions you meant to grant them, if
you mean to permit people to use your work in the ways permitted by
GPLv2, not permitting them to be used in GPLv3 software amounts to
pure selfishness: "if I won't get to use your code, you don't get to
use mine."  Tit-for-tat, for sure, but certainly not in the spirit of
sharing clearly established early in the preamble of every version of
the GPL.

Permitting such relicensing wouldn't deny anyone any freedom, and it
wouldn't create any obligations whatsoever for the licensor.  Whoever
wanted to use the work under the more liberal terms of the earlier
version of the GPL under which the work was licensed still could: this
license can't be unilaterally revoked, not by you, not by anyone else.

-- 
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: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.

[Mattia Dongili]

On Wed, Jun 20, 2007 at 07:47:23PM +0200, Thomas Renninger wrote:
> On Thu, 2007-06-21 at 02:06 +0900, Mattia Dongili wrote:
> > On Sun, Jun 17, 2007 at 10:24:23PM +0200, Thomas Renninger wrote:
...
> > > +static const struct acpi_device_id sony_device_ids[] = {
> > > + {SONY_NC_HID, 0},
> > > + {SONY_PIC_HID, 0},
> > > + {"", 0},
> > > +};
> > > +MODULE_DEVICE_TABLE(acpi, sony_device_ids);
> > > +
> > > +static const struct acpi_device_id sony_nc_device_ids[] = {
> > > + {SONY_NC_HID, 0},
> > > + {"", 0},
> > > +};
> > > +
> > ...
> > > +static const struct acpi_device_id sony_pic_device_ids[] = {
> > > + {SONY_PIC_HID, 0},
> > > + {"", 0},
> > > +};
> > > +
> > 
> > is it really necessary to have those duplicate entries?
> In this case, yes.
> 
> It's because two independent ACPI drivers are set up here.
> If you could put these together, only set up
> acpi_bus_register_driver(..) once in .init and get the pic and nc driver
> handled together it would work.
> 
> I don't know whether this could be done.

probably, I guess the the acpi_device.pnp structs contain enough
informations to detect which one is being handled. I'll get to that
later.

> If not, IMO this driver should get split up in two separate drivers, one
> serving SONY_PIC_HID and one serving SONY_NC_HID.

Oh no, we just merged them :)
Anyway, please feel free to add
Acked-by: Mattia Dongili <[EMAIL PROTECTED]>
to this patch.

> > Also, I guess that when this patch set is applied we also should declare
> > sonypi obsolete as sony-laptop will grab the same device that sonypi
> > wants (the SPIC one). sony-laptop has options to avoid doing that would
> > make things clear to users.
> > I still haven't received reports of mafunctioning vaios using the new
> > sony-laptop instead of sonypi but 2.6.22 isn't final yet.
> 
> Sounds sane.
> Another problem that could come up in future is that new laptops could
> make use of the ACPI video spec (Appendix B) and of these vendor
> specific devices (I already saw this on an ASUS).
> While autoloading should still be ok (both are tried, maybe even both
> are needed), we need to find out which one need to be used in which
> condition.

AFAIK as far as vaios are concerned the spic device (ioport) is mostly
disappearing from newer models and most of the platform specific
operations are gathered through the methods of the acpi only SNC.
I'm also trying to get as many reports as possible[1] from vaio users to
build dmi {black,white}list for functionalities.
So I guess we are going the right direction.

[1]: with the help of TJ who has setup this nice page:
http://tjworld.net/sony-laptop/

Cheers
-- 
mattia
:wq!
-
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/

ELC-Europe 2007 Call for Presentations

[Soon-Son Kwon(Shawn)]

After the successful Embedded Linux Conference in San Jose earlier
this year, it's time for an event targeted at the European embedded
Linux community!

The CE Linux Forum would like to invite you to make a presentation
at our upcoming Embedded Linux Conference - Europe.
The conference will be held November 2 and 3 in Linz, Austria, in
conjunction with the 9th Real Time Linux Workshop.
See http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007
for more information.

= Guidelines =
Presentations should be of a technical nature, covering topics
related to use of Linux in embedded systems.
The CE Linux Forum is focused on the use of Linux in consumer
electronics products, but presentations may cover use of Linux
in other embedded areas, as long as the topic is of general
relevance to most embedded users.
Presentations that are commercial advertisements or sales
pitches are not appropriate for this conference.

Presentations on the following topics are encouraged:

  * Audio, Video, and Graphics systems for embedded products
  * Security
  * System size
  * Bootup time
  * Meeting real-time constraints
  * Power management
  * Streaming media
  * Flash memory devices and filesystems
  * Technologies related to cell phones, digital settop boxes,
handheld devices, or other CE products
  * Development tools for embedded users
  * Use of Linux in actual products, practical experience and
war stories
  * Standards for CE products

A paper submission is NOT required in conjunction with
the presentation. However, if a paper is produced, it is
requested to be published on the Embedded Linux Wiki,
in MediaWiki format. (http://www.elinux.org)

You may also submit a request to present a tutorial.
Tutorials are intended to be longer, interactive learning
sessions. A tutorial may occupy more than one session
slot at the conference.

We prefer presentations that have not been previously
presented. Exceptions will be made for material that is
either of great interest or has been seen previously only
by a limited audience, like e.g. (updated) key presentations
of ELC 2007, San Jose.

For examples of presentations from previous conferences, see:
http://tree.celinuxforum.org/CelfPubWiki/ELC2006Presentations and
http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations

= Deadlines =
Proposals for presentations, demos and Birds-of-a-Feather
sessions must be received by August 11, 2007.
Speakers will be notified by September 15, 2007.

Full details, including the e-mail address to use to submit a proposal, are at:
http://tree.celinuxforum.org/CelfPubWiki/ELCE2007CallForPresentations
--
http://kldp.org/~kss
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[david]

On Thu, 21 Jun 2007, Alexandre Oliva wrote:


On Jun 20, 2007, [EMAIL PROTECTED] wrote:


but the signature isn't part of the kernel, and the code that checks
the signature is completely independant.


Well, then remove or otherwise mangle the signature in the disk of
your TiVo DVR and see at what point the boot-up process halts.


I have actually done exactly that. what happens is that the bootloader 
detects a problem and switches to the other active partition ane reboots. 
ir neither of the boot partitions meet the requirements the cycle will 
continue forever.


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

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

[Alexandre Oliva]

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

> A key is a number. A signature is a number.

And a program is a number.

http://asdf.org/~fatphil/maths/illegal.html

Your point?

-- 
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Michael Poole]

[EMAIL PROTECTED] writes:

> On Wed, 20 Jun 2007, Michael Poole wrote:
>
>> [EMAIL PROTECTED] writes:
>>
>>> if the GPL can excercise control over compilations, then if Oracle
>>> were to ship a Oracle Linux live CD that contained the Oracle Database
>>> in the filesystem image, ready to run. then the GPL would be able to
>>> control the Oracle Database code.
>>
>> By copyright law, it could.  By its language, it does not.
>
> many people (including many lawyers will disagree that it could by
> copyright law

On what grounds would Oracle have a license to ship that part of
Linux?  Unless you are the sole copyright owner, you have no right to
copy a given piece of software _at all_ without a license.  The GPL is
a remarkably giving license in terms of how little it requires.

(This potentially wide scope is one of the major reasons that the GPL
mentions "mere aggregation" and that the Debian Free Software
Guidelines' include guideline #9.)

>>> if the GPL can't do this then it can't control the checksum either.
>>>
>>> again, it's not just the kernel that's part of the checksum on a tivo,
>>> the checksum is over the kernel + initial filesystem, much of which
>>> contains code not covered by the gPL)
>>
>> Again, did you miss where I pointed out that this makes it *worse* for
>> Tivo, because they are tying together -- and making inseparable -- a
>> combination that would otherwise be "mere aggregation"?
>
> and it makes most distro CD's illegal since they contain code under
> different incompatible licenses and they make a checksum across the
> entire CD image.

When distributions generate checksums (as opposed to signatures) over
images, they do provide all of the inputs.  When most distributions
provide signatures, the signatures do not function as statements or
instructions to computers -- they function as statements to users.
Tivo's digital signatures differ in both of these respects.

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

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

[Alexandre Oliva]

On Jun 20, 2007, [EMAIL PROTECTED] wrote:

> but the signature isn't part of the kernel, and the code that checks
> the signature is completely independant.

Well, then remove or otherwise mangle the signature in the disk of
your TiVo DVR and see at what point the boot-up process halts.

-- 
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[david]

On Wed, 20 Jun 2007, Michael Poole wrote:


[EMAIL PROTECTED] writes:


if the GPL can excercise control over compilations, then if Oracle
were to ship a Oracle Linux live CD that contained the Oracle Database
in the filesystem image, ready to run. then the GPL would be able to
control the Oracle Database code.


By copyright law, it could.  By its language, it does not.


many people (including many lawyers will disagree that it could by 
copyright law



if the GPL can't do this then it can't control the checksum either.

again, it's not just the kernel that's part of the checksum on a tivo,
the checksum is over the kernel + initial filesystem, much of which
contains code not covered by the gPL)


Again, did you miss where I pointed out that this makes it *worse* for
Tivo, because they are tying together -- and making inseparable -- a
combination that would otherwise be "mere aggregation"?


and it makes most distro CD's illegal since they contain code under 
different incompatible licenses and they make a checksum across the entire 
CD image.


David Lang
-
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: SATA Harddisk speed drop of 100 MB/s

[Arjan van de Ven]

On Wed, 2007-06-20 at 19:06 -0400, Jeff Garzik wrote:
> Carlo Wood wrote:
> > hdparm -tT gives over 160 MB/s for my tripple 10k rpm Raptor RAID5
> > on 2.6.18, as expected.
> > 
> > In 2.6.22-rc5 this dropped to only 60 MB/s !
> > 
> > Is this a known issue?
> > 
> > I also measured it with bonnie; I get 108 MB/s reading speed on
> > 2.6.18 and only 68 MB/s on 2.6.22-rc5.
> 
> More info needed...  kernel config, before-and-after dmesg output, lspci 
> output.




also do a 

echo 60 > /proc/sys/vm/dirty_ratio

first to see if that helps

-
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-20-10-12.tar.gz uploaded

[Jeremy Fitzhardinge]

[EMAIL PROTECTED] wrote:

git-r8169-fixup.patch
  

This causes a compile failure:

/home/jeremy/hg/xen/paravirt/linux/drivers/net/r8169.c: In function 
'rtl8169_rx_interrupt':
/home/jeremy/hg/xen/paravirt/linux/drivers/net/r8169.c:2569: error: too many 
arguments to function 'rtl8169_try_rx_copy'

with an allyesconfig on x86-64.  Should git-r8169-fixup.patch also be 
changing the callers?


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

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

[Alexandre Oliva]

On Jun 20, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:

> And anybody who thinks others don't have the "right to choice", and then 
> tries to talk about "freedoms" is a damn hypocritical moron.

Yeah, it is indeed possible to twist it such that it sounds bad.

The important point is that one's freedom ends where another's
starts.  Unlimited freedom would be freedom to trample over others'
freedoms too, and that's not right.  That's why freedom of choice has
to be used with care.  Even fundamental human rights sometimes clash
with each other.

We don't fight for the freedoms as goals in themselves.  We fight for
them because we understand they're essential for the common good.

-- 
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: JIT emulator needs

[H. Peter Anvin]

Albert Cahalan wrote:
>>
>> That's fine.  That's a policy decision.  That's what a security policy
>> *is*.  The owner of the system has decided, by security policy, that
>> that is not allowed.  Bypassing that is not acceptable.
> 
> Fixing a bug should be acceptable.
> 

That's not what you're trying to do, though.  You're trying to change
the behaviour underneath the security policy.  If there is a bug, it's
in the security policy and that's where it needs to be changed.

> Look, let's back up a bit here. At a high level, what exactly do
> you imagine that this behavior was intended for? I suggest you
> list some examples of the attacks that are blocked.
> 
> Can you come up with a reasonable argument that the current behavior
> is the least painful restriction required to block those attacks?
> Does the current behavior block any attack that the proposed behavior
> would not? (list the attacks please)

See above.

-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: How to improve the quality of the kernel?

[Al Boldi]

Adrian Bunk wrote:
> On Mon, Jun 18, 2007 at 06:55:47AM +0300, Al Boldi wrote:
> > Michal Piotrowski wrote:
> > > On 18/06/07, Al Boldi <[EMAIL PROTECTED]> wrote:
> > > > Bartlomiej Zolnierkiewicz wrote:
> > > > > On Sunday 17 June 2007, Andrew Morton wrote:
> > > > > > We of course do want to minimise the amount of overhead for each
> > > > > > developer. I'm a strong believer in specialisation: rather than
> > > > > > requiring that *every* developer/maintainer integrate new steps
> > > > > > in their processes it would be better to allow them to proceed
> > > > > > in a close-to-usual fashion and to provide for a specialist
> > > > > > person (or team) to do the sorts of things which you're thinking
> > > > > > about.
> > > > >
> > > > > Makes sense... however we need to educate each and every developer
> > > > > about importance of the code review and proper recognition of
> > > > > reviewers.
> > > >
> > > > That's as easy to manage as is currently done with rc-regressions.
> > >
> > > Are you a volunteer?
> >
> > Probably not, as this task requires a real PRO!
> >...
>
> That's wrong.
>
> We are talking about _tracking_.
>
> I'm not sure whether it makes much sense, and it would cost an enormous
> amount of time, but tracking patches should be possible without any
> knowledge of the kernel.

If that's really true, which I can't imagine, then the proper way forward 
would probably involve a fully automated system.


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: JIT emulator needs

[Albert Cahalan]

On 6/20/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:

Albert Cahalan wrote:
> Putting this into the security policy was an error born of
> lazyness to begin with. Abuse of the security mechanism
> was easier than hacking the toolchain, ELF loader, etc.
>
> Either a binary needs self-modification, or it doesn't. This is
> determined by the author of the code. If you don't trust an
> executable that needs this ability, then you simply can not
> run it in a useful way.

That's fine.  That's a policy decision.  That's what a security policy
*is*.  The owner of the system has decided, by security policy, that
that is not allowed.  Bypassing that is not acceptable.


Fixing a bug should be acceptable.

Look, let's back up a bit here. At a high level, what exactly do
you imagine that this behavior was intended for? I suggest you
list some examples of the attacks that are blocked.

Can you come up with a reasonable argument that the current behavior
is the least painful restriction required to block those attacks?
Does the current behavior block any attack that the proposed behavior
would not? (list the attacks please)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michael Poole]

[EMAIL PROTECTED] writes:

> if the GPL can excercise control over compilations, then if Oracle
> were to ship a Oracle Linux live CD that contained the Oracle Database
> in the filesystem image, ready to run. then the GPL would be able to
> control the Oracle Database code.

By copyright law, it could.  By its language, it does not.

> if the GPL can't do this then it can't control the checksum either.
>
> again, it's not just the kernel that's part of the checksum on a tivo,
> the checksum is over the kernel + initial filesystem, much of which
> contains code not covered by the gPL)

Again, did you miss where I pointed out that this makes it *worse* for
Tivo, because they are tying together -- and making inseparable -- a
combination that would otherwise be "mere aggregation"?

Michael Poole
-
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: Writing a driver for a legacy serial device

[Dmitry Torokhov]

On Wednesday 20 June 2007 04:56, Jean Delvare wrote:
> Hi Dmitry,
> 
> Thanks for your answer, very much appreciated.
> 
> On Tue, 19 Jun 2007 14:59:34 -0400, Dmitry Torokhov wrote:
> > 
> > You need to load serport modue and play with inputattach utility.
> 
> Ah, I see. There's no way to detect what device is connected to the
> serial port, so we need a user-space tool to bind the port to the right
> driver? Makes some sense, even though it's a but strange that I need
> something called inputattach for a device which isn't an input device.

Because serio interface is mostly used with input devices. For all other
devices I think universal answer is "userspace" but with input devices
we want to do processing in kernel so we can route events into console
and other standard interfaces (although one coudl use uinput to achieve
similar result).

> 
> So I've set CONFIG_SERIO_SERPORT=m, compiled and loaded serport. Then I
> added a new protocol number in :
> 
> #define SERIO_TAOSEVM 0x40
> 
> Then I added the following entry to inputattach and recompiled it:
> 
> { "--taos-evm",   "-taos",B1200, CS8, 
> SERIO_TAOSEVM,  0,  0,  0,  NULL },
> 
> Then I changed my driver code to:
> 
> static struct serio_device_id taos_serio_ids[] = {
>   {
>   .type   = SERIO_RS232,
>   .proto  = SERIO_TAOSEVM,
>   .id = SERIO_ANY,
>   .extra  = SERIO_ANY,
>   },
>   { 0 }
> };
> 
> And lastly I ran, as root:
> 
> ./inputattach -taos /dev/ttyS0
> 
> I see the following line in the logs as a result:
> 
> serio: Serial port ttyS0
> 
> But unfortunately, my driver's .connect function is still not called.
> I guess that I missed one step? Any idea what it would be?
> 

Not sure. Could you check /sys/bus/serio/devices/serioX/id/* and verify
that inputattach sets up serio port properly?

-- 
Dmitry
-
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] add printk_ratelimit to atkbd_interrupt

[Dmitry Torokhov]

On Wednesday 20 June 2007 03:34, Qi Yong wrote:
> Dmitry Torokhov wrote:
> > On Tuesday 19 June 2007 21:17, Qi Yong wrote:
> >   
> >> Add printk_ratelimit() to atkbd_interrupt(). I get "Spurious ACK" messages 
> >> flushing on my
> >> screen. This patch helps to read the screen.
> >>
> >> 
> >
> > Will apply, thank you.
> >
> > Do you have any idea why you are getting spurios ACK messages? Do you have
> > an application fiddling with keyboard port or do you have blink driver
> > enabled?
> 
> No idea. It is at boot time.
> Yes, i have CONFIG_BLINK=y.

Disable it.

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

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

[david]

On Wed, 20 Jun 2007, Michael Poole wrote:


David Schwartz writes:


However, compilations (even to the extent they are creative
combinations) are not necessarily derivative works of their elements.
For more details, see
http://www.copyright.gov/circs/circ14.html#compilations


Because compilation copyrights don't really affect the Tivo and GPLv2/GPLv3
issue, I tend to ignore them when discussing that subject. If you think I'm
wrong and there is some relationship between them, please let me know. I
admit I may not have given that possibility enough thought.


I believe compilation copyrights do bear on GPL-licensed software, by
virtue of the GPL's sentence "[...] rather, the intent is to exercise
the right to control the distribution of derivative _or collective_
works based on the Program." (emphasis added).

There is a lot of grey and/or arguable area about what constitutes a
GPL-encumbered collective work versus mere aggregation.  Although I
disagree, I understand and respect that some believe that the kernel
plus a digital signature over it is "mere aggregation".  I would like
to focus the discussion on that question, though, rather than whether
the GPL is worded to control the rights to compilations-in-general
that include GPLed works.


if the GPL can excercise control over compilations, then if Oracle were to 
ship a Oracle Linux live CD that contained the Oracle Database in the 
filesystem image, ready to run. then the GPL would be able to control the 
Oracle Database code.


if the GPL can't do this then it can't control the checksum either.

again, it's not just the kernel that's part of the checksum on a tivo, the 
checksum is over the kernel + initial filesystem, much of which contains 
code not covered by the gPL)


David Lang
-
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: limits on raid

[Neil Brown]

On Saturday June 16, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> > On Friday June 15, [EMAIL PROTECTED] wrote:
> >  
> >>   As I understand the way
> >> raid works, when you write a block to the array, it will have to read all
> >> the other blocks in the stripe and recalculate the parity and write it out.
> > 
> > Your understanding is incomplete.
> 
> Does this help?
> [for future reference so you can paste a url and save the typing for code :) ]
> 
> http://linux-raid.osdl.org/index.php/Initial_Array_Creation
> 
> David
> 
> 
> 
> Initial Creation
> 
> When mdadm asks the kernel to create a raid array the most noticeable 
> activity 
> is what's called the "initial resync".
> 
> The kernel takes one (or two for raid6) disks and marks them as 'spare'; it 
> then 
> creates the array in degraded mode. It then marks spare disks as 'rebuilding' 
> and starts to read from the 'good' disks, calculate the parity and determines 
> what should be on any spare disks and then writes it. Once all this is done 
> the 
> array is clean and all disks are active.

This isn't quite right.
Firstly, it is mdadm which decided to make one drive a 'spare' for
raid5, not the kernel.
Secondly, it only applies to raid5, not raid6 or raid1 or raid10.

For raid6, the initial resync (just like the resync after an unclean
shutdown) reads all the data blocks, and writes all the P and Q
blocks.
raid5 can do that, but it is faster the read all but one disk, and
write to that one disk.

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

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

[Michael Poole]

David Schwartz writes:

>> There is a lot of grey and/or arguable area about what constitutes a
>> GPL-encumbered collective work versus mere aggregation.
>
> I think it's technically/legally clear what the standards are, but certainly
> arguable whether particular works meet that standard. If the choice of works
> to combine is sufficiently creative (above and beyond any choices dictated
> by functional considerations), it's a GPL-encumbered collective work.
>
> I don't think it's arguable that a signature shipped along with a binary is
> a collective work. In any event, if that were true, I think we should be
> able to agree that Linus would be required to release his kernel signing
> keys.

The distinction between GPL-covered works and "mere aggregation" is
not a function only of legal classifications.  If it were, the GPL
would be worded differently than it is -- and have different effects
than most people believe it does.

Michael Poole
-
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-20-10-12.tar.gz uploaded

[Jeremy Fitzhardinge]

[EMAIL PROTECTED] wrote:

i386-minor-nx-handling-adjustment.patch
  


This is needed:

Include asm/pgtable.h to get declaration of __supported_pte_mask

This fixes problem exposed by i386-minor-nx-handling-adjustment.patch

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
include/xen/page.h |1 +
1 file changed, 1 insertion(+)

===
--- a/include/xen/page.h
+++ b/include/xen/page.h
@@ -4,6 +4,7 @@
#include 

#include 
+#include 

#include 



-
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: limits on raid

[Neil Brown]

On Monday June 18, [EMAIL PROTECTED] wrote:
> On Sat, Jun 16, 2007 at 07:59:29AM +1000, Neil Brown wrote:
> > Combining these thoughts, it would make a lot of sense for the
> > filesystem to be able to say to the block device "That blocks looks
> > wrong - can you find me another copy to try?".  That is an example of
> > the sort of closer integration between filesystem and RAID that would
> > make sense.
> 
> I think that this would only be useful on devices that store
> discrete copies of the blocks on different devices i.e. mirrors. If
> it's an XOR based RAID, you don't have another copy you can
> retreive

You could reconstruct the block in question from all the other blocks
(including parity) and see if that differs from the data block read
from disk...  For RAID6, there would be a number of different ways to
calculate alternate blocks.   Not convinced that it is actually
something we want to do, but it is a possibility.

I have that - apparently naive - idea that drives use strong checksum,
and will never return bad data, only good data or an error.  If this
isn't right, then it would really help to understand what the cause of
other failures are before working out how to handle them

NeilBrown
-
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] blink: Only blink when parameter is set

[Dmitry Torokhov]

On Wednesday 20 June 2007 20:24, Jiri Kosina wrote:
> On Thu, 21 Jun 2007, Pavel Machek wrote:
> 
> > > this has probably been already solved by proper throttling - see 
> > > http://lkml.org/lkml/2007/6/15/22
> > No, it was not. I still saw the problems with CONFIG_BLINK on, that is
> > one blink per 5 seconds or something.

Pavel, does my patch fixes keyboard issues for you when blinking via
setleds?

> > We should rename CONFIG_BLINK to
> > CONFIG_BREAK_THINKPAD_KEYBOARD_AND_MORE.

Also CONFIG_KILL_MY_NOHZ_SAVINGS ;)

> 
> In fact it looks quite weird that one blink per 5 seconds can break the 
> keyboard, in fact.

Not wierd at all. The driver uses panic_blink - something that we expect
to work after panic. It rapidly polls KBC status register to detect when
it accepted led command and does it without taking i8042_lock (because
it may have been taken before kernel panicked) so it is quite possible
that that interferes with atkbd operation.

IOW I am not really interested in reports regrading issues with keyboards
and/or mice on boxes with blink driver loaded.

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

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

[David Schwartz]

> I believe compilation copyrights do bear on GPL-licensed software, by
> virtue of the GPL's sentence "[...] rather, the intent is to exercise
> the right to control the distribution of derivative _or collective_
> works based on the Program." (emphasis added).

Ahh, good. So there's no problem with the GPL. I already thought it the most
sensible reading that it included collective works (and it's clear that it
can legally do so), but that makes it clear.

I didn't mean that compilation copyrights have no relevance to GPL issues in
general, just none to the issue of GPLv2 versus GPLv3 and Tivoization. Are
you going to argue that there's a compilation copyright justified by
combining a kernel binary with a signature for that binary? That seems
untenable to me.

> There is a lot of grey and/or arguable area about what constitutes a
> GPL-encumbered collective work versus mere aggregation.

I think it's technically/legally clear what the standards are, but certainly
arguable whether particular works meet that standard. If the choice of works
to combine is sufficiently creative (above and beyond any choices dictated
by functional considerations), it's a GPL-encumbered collective work.

I don't think it's arguable that a signature shipped along with a binary is
a collective work. In any event, if that were true, I think we should be
able to agree that Linus would be required to release his kernel signing
keys.

> Although I
> disagree, I understand and respect that some believe that the kernel
> plus a digital signature over it is "mere aggregation".

It clearly is. What else could it be? The digital signature is a separate
item, a pure number for which there is no copyright interest, that is simply
appended to the kernel. It does not contain significant protected elements
of the kernel. No creative process is used to generate it or attach it. The
decision to append is dictated by purely functional considerations (nobody
creatively picks which signature to bundle with which kernel).

> I would like
> to focus the discussion on that question, though, rather than whether
> the GPL is worded to control the rights to compilations-in-general
> that include GPLed works.

If the kernel plus a digital signature over it is not mere aggregation, then
Linus is violating the GPL by shipping kernel plus digital signatures but
not including the "source code" to produce the signatures. If the
ridiculousness of that is not sufficiently obvious, I'm not sure what else
to say. Where is the outcry that Linus is keeping his signing key secret,
failing to include the source code that he used to build the Linux kernel
distibution?

The past few times this has come up, every possible irrelevent side issue
was raised. For example, that the signature in the case of Linux is not
functional. These considerations do not have anything to do with whether the
combination is mere aggregation or not.

Ironically, this case is even clearer than linking. The two works are quite
literally stapled together. There is no intermingling 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Michael Poole]

David Schwartz writes:

>> However, compilations (even to the extent they are creative
>> combinations) are not necessarily derivative works of their elements.
>> For more details, see
>> http://www.copyright.gov/circs/circ14.html#compilations
>
> Because compilation copyrights don't really affect the Tivo and GPLv2/GPLv3
> issue, I tend to ignore them when discussing that subject. If you think I'm
> wrong and there is some relationship between them, please let me know. I
> admit I may not have given that possibility enough thought.

I believe compilation copyrights do bear on GPL-licensed software, by
virtue of the GPL's sentence "[...] rather, the intent is to exercise
the right to control the distribution of derivative _or collective_
works based on the Program." (emphasis added).

There is a lot of grey and/or arguable area about what constitutes a
GPL-encumbered collective work versus mere aggregation.  Although I
disagree, I understand and respect that some believe that the kernel
plus a digital signature over it is "mere aggregation".  I would like
to focus the discussion on that question, though, rather than whether
the GPL is worded to control the rights to compilations-in-general
that include GPLed works.

Michael Poole
-
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: cpuset attach_task to touch per-cpu kernel threads?

[Paul Jackson]

Srivatsa wrote:
# move all tasks from top cpuset to 'foo' cpuset
sed -nu p < /dev/cpuset/tasks > /dev/cpuset/foo/tasks

Aha - that won't work very well, as you noticed.

In looking through my past email archives, I can see where I have
recommended this trick to move things -into- the top cpuset, but
not to move them -out-of- the top cpuset.  I would not (except by
mistake) recommend using the above trick to move tasks out of the
top cpuset, for the very reason you note.

I do have code to move tasks out of the top cpuset in bulk, but it
is written in C, as part of some SGI proprietary product (though
it relies mostly on some LGPL licensed bitmask and cpuset libraries
that I have written for SGI.)

The basic idea is to avoid moving the threads whose 'Cpus_allowed'
value in their /proc//status file is a strict subset of (less
than, but -not- equal to) the set of online cpus.  The kernel threads
that you don't want to move are those that are pinned to specific
cpus or nodes; they are where they must be for their purposes.
Kernel threads that are not pinned can be moved just as readily
as user threads; they just need to be someplace.

I don't know any easy way to script this.  We just don't have the
tools in shell script to conveniently work with sets or bit masks.
... not yet anyway ... see below.

Checking whether a tasks Cpus_allowed is a strict subset of the
set of online cpus may not always be the check needed, depending
on what one is doing.  But it matched my needs, and from the looks
of what you're doing in that script, making the sys and test cpusets,
it might well match your needs as well, as your needs look rather
similar to what mine were.

> But I am wondering if attach_task() should leave kernel threads alone and
> act only upon user-space threads. Or maybe allow movement if it doesn't
> result in changing kernel-threads's cpu affinity.

I tend to favor minimizing kernel support, where user level support
is sufficient.  This was especially important in the early years of
Linux 2.6 cpuset kernel work, when it was vital for its acceptance to
minimize the kernel footprint of cpusets as much as I was able.

I would tend to favor encouraging further development of the user
level support for such work, over special cases in the kernel calls
just because we had not yet provided the user code to conveniently
make a certain test, but could well enough do so if need be.

Hopefully, in a few months, when I got off this other, non-cpuset
related, task that I'm on, I will get some time to publish the user
level LGPL licensed library code that makes working with bitmasks and
cpusets convenient in user level C code.  The code is in excellent
shape, if I do say so myself.

The next step, which I have fond dreams of getting to, but which is so
low on my managers priority list that there is nearly zero chance of
it happening, would be to provide a scriptable interface to the bitmask
code.  I'd probably do that as a Python module, integrating it with
Python sets.  This would take little more than some routines to import
and export Python sets to the couple of commonly used ascii
representations of bitmasks, which are those formed by the kernels
lib/bitmap.c bitmap_scnprintf() and bitmap_scnlistprintf() routines.
Such work is sufficiently generic that it might even be acceptable as
a patch to the mainline Python release.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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] driver core: multithreaded probing - more parallelism control

[Huang, Ying]

Hi,

This is a new version of multithreaded probing patch, with more
parallelism control added.

There are more control over which devices and drivers will be probed
parallelized or serially. For example, in IEEE1394 subsystem, the
different "units" in one "node" can be probed serially while the
different "nodes" can be probed parallelized.

The number of threads can be controlled through a kernel command line
parameters.

The patch is against 2.6.22-rc5. The "wait_for_probes" function in the
patch comes from the original multithreaded probing patch. If I need do
anything because of it, please let me know.

Any comment is welcome.

Best Regards,
Huang Ying

---

This patch add multithreaded probing with more parallelism control.

The device/driver probing is done on a probing queue, which is a
customized version of work queue, where the thread of probing queue will
come and go on demand. There is a queue No. for each probing queue. The
queue No. ranges from 0 to (unsigned short) ~0U, any queue No. can be
used by probing independent of the underlying thread number.

The device/driver probing is submitted to a probing queue though
"schedule_probe" function with probing queue No, a probing function and
corresponding parameter specified. The probing with same probing queue
No. will be done serially, while the probing with different probing
queue No. may be done parallelized.

"schedule_probe" is a general interface of multithreaded probing. While
convenient interfaces are as follow.

A field named "probe_queue_no" is added to "struct device", which
indicates probing queue No. on which the probing of the device will be
done. The subsystem can control the parallelism through this field. For
example, in IEEE1394 subsystems, the same probe_queue_no can be assigned
for different "units" in same "node" while different probe_queue_no can
be assigned to different "nodes".

Fields named "has_probe_queue" and "probe_queue_no" are added to "struct
device_driver". This let the probing queue can be controlled through
driver side too. If "has_probe_queue" is set, the "probe_queue_no" of
"struct device_driver" is used, otherwise that of "struct device" is
used.

There are other rules to control the parallelism.

1. The child device will not start probing until the probing of its
parent has been done.
2. The different drivers of same device will be probed serially.

If it is intended to separate the probing process of the device/driver
into synchronous part and asynchronous part, the ".probe" of "struct
device_driver" is used as the synchronous interface of device probing,
while the asynchronous part of probing can be submitted through
"schedule_probe" in ".probe" function. All the synchronous part will be
submitted with same probing queue number.

More strict serialization can be gotten through this mechanism if
needed. For example, if two USB driver is inserted into kernel
simultaneously, in original driver probing code, two USB device may be
probed simultaneously, while they will be probed serially if two device
has same probing queue No. in probing queue based probing code.

There is a problem of this multithreaded probing mechanism. There are
some code in kernel doing hardware access but not in the driver ".probe"
function, which may conflict with the multithreaded probiMore strict
serialization can be gotten through this mechanism if
needed. For example, if two USB driver is inserted into kernel
simultaneously, in original driver probing code, two USB device may be
probed simultaneously, while they will be probed serially if two device
has same probing queue No. in probing queue based probing code.

There is a problem of this multithreaded probing mechanism. There are
some code in kernel doing hardware access but not in the driver ".probe"
function, which may conflict with the multithreaded probing driver code.
A possible mechanism is executing those hardware access code in a
probing queue through "schedule_probe".ng driver code. A possible
mechanism is executing those hardware access code in a probing queue
through "schedule_probe".

Signed-off-by: Huang Ying <[EMAIL PROTECTED]>

---

 drivers/base/dd.c  |  182 ++---
 include/linux/device.h |   27 ++-
 2 files changed, 199 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index b0088b0..a5cd629 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -23,6 +23,162 @@
 #include "base.h"
 #include "power/power.h"
 
+struct probe_queue {
+   spinlock_t lock;
+   struct list_head probe_list;
+   unsigned has_thread : 1;
+};
+
+struct simple_probe {
+   struct probe probe;
+   struct device *dev;
+   struct device_driver *drv;
+};
+
+static struct probe_queue *probe_queues;
+static atomic_t probe_count = ATOMIC_INIT(0);
+static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
+
+static int probe_thread_num = 1;
+
+static int __init set_probe_thread_num(char *str)
+{
+  

Re: [PATCH] Chinese translated version of Documentation/stable_api_nonsense.txt

[TripleX]

Thanks for your help :-) I will update the patch soon.

WANG Cong wrote:

On Tue, Jun 19, 2007 at 11:40:44PM +0800, TripleX wrote:
  
This is the Chinese translated version of 
Documentation/stable_api_nonsense.txt


Signed-off-by: Li Yang <[EMAIL PROTECTED]>
Signed-off-by: TripleX Chung <[EMAIL PROTECTED]>




Thanks for your work! It's a good work.

As in the HOWTO translation, I will give my comments on the
following patch. I hope you can consider my comments carefully
and other people who don't understand Chinese won't mind about
my Chinese comments. ;)

  

---
Documentation/zh_CN/stable_api_nonsense.txt | 158 
+++

1 files changed, 158 insertions(+), 0 deletions(-)
create mode 100644 Documentation/zh_CN/stable_api_nonsense.txt

diff --git a/Documentation/zh_CN/stable_api_nonsense.txt 
b/Documentation/zh_CN/stable_api_nonsense.txt

new file mode 100644
index 000..32dca8c
--- /dev/null
+++ b/Documentation/zh_CN/stable_api_nonsense.txt
@@ -0,0 +1,158 @@
+Chinese translated version of Documentation/stable_api_nonsense.txt
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer, if this translation is
+outdated or there is problem with translation.
+
+Maintainer: Greg Kroah-Hartman <[EMAIL PROTECTED]>
+Chinese maintainer: TripleX Chung <[EMAIL PROTECTED]>
+-
+Documentation/stable_api_nonsense.txt 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+
+英文版维护者： Greg Kroah-Hartman <[EMAIL PROTECTED]>
+中文版维护者： 钟宇 TripleX Chung <[EMAIL PROTECTED]>
+中文版翻译者： 钟宇 TripleX Chung <[EMAIL PROTECTED]>
+中文版校译者： 李阳 Li Yang <[EMAIL PROTECTED]>
+以下为正文
+-




首先建议译文中的linux都改为Linux（大写首字母），毕竟原文就是这样的。


  

+
+写作本文档的目的，是为了解释为什么linux既没有一个二进制内核接口，也没有
+一个稳定的内核接口。这里所说的内核接口，是指内核里的接口，而不是内核和




据我了解，这种情况下，“a”是没必要翻译出来的。


  

+用户空间的接口。内核到用户空间的接口，是提供给应用程序使用的系统调用，
+系统调用在历史上几乎没有过变化，将来也不会有变化。我有一些老应用程序是
+在0.9版本或者更早版本的内核上编译的，在使用2.6版本内核的Linux发布上依然
+用得很好。用户和应用程序作者可以将这个接口看成是稳定的。
+
+
+执行纲要
+ 
+
+你也许以为自己想要一个稳定的内核接口，但是你不清楚你要的实际上不是这个
+。你需要的其实是一个稳定的驱动程序，而你只有将驱动程序放到公版内核的源
+代码树里，才有可能达到这个目的。而且这样做还有很多其他好处，正是因为这




s/其他/其它/ ？


  

+些好处使得Linux能成为强壮，稳定，成熟的操作系统，这也是你最开始选择Linux
+的原因。
+
+
+入门
+ -
+
+只有那些写驱动程序的“怪人”才会担心内核接口的改变，对广大用户来说，既
+看不到内核接口，也不需要去关心它。
+
+首先，我不打算讨论关于任何非GPL许可的内核驱动的法律问题，这些非GPL许可
+的驱动程序包括不公开源代码，隐藏源代码，二进制或者是用源代码包装，或者
+是其它任何形式的不能以GPL许可公开源代码的驱动程序。如果有法律问题，请咨
+询律师，我只是一个程序员，所以我只打算探讨技术问题（不是小看法律问题，
+法律问题很实际，并且需要一直关注）。
+
+既然只谈技术问题，我们就有了下面两个主题：二进制内核接口和稳定的内核源
+代码接口。这两个问题是互相关联的，让我们先解决掉二进制接口的问题。
+
+
+二进制内核接口
+ --
+假如我们有一个稳定的内核源代码接口，那么自然的，我们就拥有了稳定的二进




“那么自然而然...”怎样？


  

+制接口，是这样的吗？错。让我们看看关于linux内核的几点事实：
+ - 取决于所用的c编译器的版本，不同的内核数据结构里的结构体的对齐方




s/c/C/


  

+式会有差别，代码中不同函数的表现形式也不一样（函数是不是被inline编译取
+决于编译器行为）。不同的函数的表现形式并不重要，但是数据结构内部的对齐
+方式很关键。
+ - 取决于内核的配置选项，不同的选项会让内核的很多东西发生改变：
+ - 同一个结构体可能包含不同的成员变量
+ - 有的函数可能根本不会被实现（比如编译的时候没有选择 SMP支持
+，一些锁函数就会被定义成空函数）。
+ - 内核使用的内存会以不同的方式对齐，这取决于不同的内核配置选
+项。
+ - linux可以在很多的不同体系结构的处理器上运行。在某个体系结构上编
+译好的二进制驱动程序，不可能在另外一个体系结构上正确的运行。
+
+对于一个特定的内核，满足这些条件并不难，使用同一个c编译器和同样的内核配
+置选项来编译驱动程序模块就可以了。这对于给一个特定linux发布的特定版本提
+供驱动程序，是完全可以满足需求的。但是如果你要给不同的发布不同版本都发
+布一个驱动程序，就需要在每个发布上用不同的内核设置参数都编译一次内核，
+这简直跟噩梦一样。而且还要注意到，每个linux发布还提供不同的Linux内核，
+这些内核都针对不同的硬件类型进行了优化（有很多种不同的处理器，还有不同
+的内核设置选项）。所以每发布一次驱动程序 ，都需要提供很多不同版本的内核
+模块。
+
+相信我，如果你真的要采取这种发布方式，一定会慢慢疯掉，我很久以前就有过
+深刻的教训...
+
+
+稳定的内核源代码接口
+ 
+
+如果有人不将他的内核驱动程序，放入公版内核的源代码树，而又想让驱动程序
+一直保持在最新的内核中可用，那么这个话题将会变得没完没了。
+ 内核开发是持续而且快节奏的，从来都不会慢下来。内核开发人员在当前接口中
+找到bug，或者找到更好的实现方式。一旦发现这些，他们就很快会去修改当前的
+接口。修改接口意味着，函数名可能会改变，结构体可能被扩充或者删减，函数
+的参数也可能发生改变。一旦接口被修改，内核中使用这些接口的地方需要同时
+修正，这样才能保证所有的东西继续工作。
+
+举一个例子，内核的USB驱动程序接口在USB子系统的整个生命周期中，至少经历
+了三次重构。这些重构解决以下问题：




个人认为，rework翻译为“重写”更好一些。


  

+ - 把数据流从同步模式改成非同步模式，这个改动减少了一些驱动程序的
+复杂度，提高了所有USB驱动程序的吞吐率，这样几乎所有的USB设备都能以最大
+速率工作了。
+ - 修改了USB核心代码中为USB驱动分配数据包内存的方式，所有的驱动都
+需要提供更多的参数给USB核心，以修正了很多已经被记录在案的死锁。
+
+这和一些封闭源代码的操作系统形成鲜明的对比，那些在那些操作系统上，不得




“那些在那些操作系统上”读不通，请修改。


  

+不额外的维护旧的USB接口。这导致了一个可能性，新的开发者依然会不小心使用
+旧的接口，以不恰当的方式编写代码，进而影响到操作系统的稳定性。
+ 在上面的例子中，所有的开发者都同意这些重要的改动，在这样的情况下修改代
+价很低。如果Linux保持一个稳定的内核源代码，那么就得创建一个新的接口；旧




原文是“If Linux ... a stable source interface”，而不是“source code”。


  

+的，有问题的接口必须一直维护，给Linux USB开发者带来额外的工作。既然所有
+的Linux USB驱动的作者都是利用自己的时间工作，那么要求他们去做毫无意义的
+免费额外工作，是不可能的。
+ 安全问题对Linux来说十分重要。一个安全问题被发现，就会在短时间内得到修
+正。在很多情况下，这将导致Linux内核中的一些接口被重构，以从根本上避免安
+全问题。一 旦接口被重构，所有使用这些接口的驱动程序，必须同时得到修正，
+以确定安全问题已经得到修复并且不可能在未来还有同样的安全问题。如果内核
+内部接口不允许改变，那么就不可能修复这样的安全问题，也不可能确认这样的
+安全问题以后不会发生。
+开发者一直在清理内核接口。如果一个接口没有人在使用了，它就会被删除。这
+样可以确保内核尽可能的小，而且所有潜在的接口都会得到尽可能完整的测试
+（没有人使用的接口是不可能得到良好的测试的）。
+
+
+要做什么
+ ---
+
+如果你写了一个Linux内核驱动，但是它还不在linux源代码树里，作为一个开发
+者，你应该怎么做？为每个发布的每个版本提供一个二进制驱动，那简直是一个
+噩梦，要跟上 

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

[David Schwartz]

> By "creative combination" do you mean what US copyright law refers to
> as compilations (or their subset collective works)?

Not only. By "creative combination" I mean either a compilation or a
derivative work. I was a bit unclear about that because I wasn't really
addressing compilation rights at the time.

For example, if you adapt a FreeBSD driver to work on Linux, you may be
creatively combining aspects of the driver with code from the kernel. The
result is one that you have copyright interest in because it is a derivative
work but probably not a compilation copyright. The choice of one driver and
one OS, where the goal is to make the driver work on the OS, probably is not
sufficiently creative to justify a compilation copyright. However, this is
clearly not mere aggregation if significant changes are needed to make the
driver work with Linux.

> Compilations can be creative combinations while still being mere
> aggregation under the GPL.  For example, if applications are selected
> to run with a Linux kernel, and they are distributed together, the
> collection is a creative selection -- and this seems to be one of the
> cases evoked by the GPL's reference to "mere aggregation".  See also
> practically every Linux distribution on the planet.

You are quite correct. In this case, the GPL may not require you to license
the compilation copyright. I believe this is so even if all the works are
covered by the GPL. Arguably, that's a defect in the GPL because it means
there might be situations in which you might receive a CD that contains only
GPL'd software and not be able to redistribute it due to a compilation
copyright.

I honestly have no position on whether "mere aggregation" should include
aggregating works where there is sufficient creative input to justify a
compilation copyright on the result. I think either position can be argued.
I think the intent of the GPL was probably that mere aggregation not include
compilation rights because that leads to strange results. I don't know of
any evidence that compilation rights were considered when the GPL was
written. If so, the deliberate lack of mention might weigh in the balance.

> Compilations also can be creative combinations and *more* than mere
> aggregation: for example, Linux with respect to its subsystems, or any
> case where a larger work is derivative of one of its components.

Of course. If I write a Linux kernel module, it might be a derivative work
because it contains significant portions of the Linux kernel source code.
This is true before anyone compiles it or links it.

When I say linking cannot create a derivative work, I mean assuming the work
was not derivative in the first place. I am also further assuming there is
insufficient creativity in the choice of which works to link to justify a
compilation copyright.

> However, compilations (even to the extent they are creative
> combinations) are not necessarily derivative works of their elements.
> For more details, see
> http://www.copyright.gov/circs/circ14.html#compilations

Because compilation copyrights don't really affect the Tivo and GPLv2/GPLv3
issue, I tend to ignore them when discussing that subject. If you think I'm
wrong and there is some relationship between them, please let me know. I
admit I may not have given that possibility enough thought.

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: [BUG?]Set XIP mount option on ext2 bypass check.

[Yan Zheng]

I mount an ext2 fs , then remount it with xip option set.
I get message below when do write operation in the fs.


kernel BUG at fs/ext2/xip.c:21!
invalid opcode:  [#1]
SMP
last sysfs file: /class/net/eth0/carrier
Modules linked in: ext2 autofs4 hidp rfcomm l2cap bluetooth sunrpc ipv6 dm_mirro
r dm_multipath video sbs i2c_ec button dock battery ac lp floppy snd_ens1371 gam
eport snd_rawmidi snd_ac97_codec pcnet32 ac97_bus snd_seq_dummy snd_seq_oss snd_
seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_time
r snd soundcore snd_page_alloc mii serio_raw parport_pc parport pcspkr BusLogic
i2c_piix4 i2c_core sg ext3 jbd mbcache squashfs dm_snapshot dm_mod loop sd_mod e
hci_hcd uhci_hcd ata_piix ata_generic libata sr_mod scsi_mod cdrom
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.21-1.3194.fc7 #1)
EIP is at ext2_clear_xip_target+0x1e/0x47 [ext2]
eax: d887da00   ebx: d310e3c0   ecx: d0648bd4   edx: 1e01
esi: d0648b4c   edi:    ebp: cc863e44   esp: cc863df8
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process dd (pid: 3231, ti=cc863000 task=cd61b710 task.ti=cc863000)
Stack: 00d8 ff10 0200 1e01 d8cb5b5b cc863e44 cc863e8c 0c9f
  cd61b710 0001 d0648bd4  cc863e50 0001 0001 0400
  cc863e74 cc863e50 c043c220 d0648b4c 1e01  0f8c 0e34
Call Trace:
[] ext2_get_block+0x3f4/0x52b [ext2]
[] clockevents_program_event+0xb2/0xb9
[] avc_has_perm+0x4e/0x58
[] ext2_get_xip_page+0x65/0xde [ext2]
[] xip_file_write+0x232/0x38d
[] xip_file_write+0x0/0x38d
[] vfs_write+0xa8/0x154
[] sys_write+0x41/0x67
[] syscall_call+0x7/0xb
===
Code: 89 0c 24 e8 88 cd ff ff 83 c4 0c 5b c3 57 53 83 ec 08 8b 80 9c 00 00 00 8b
98 98 00 00 00 8b 43 5c 8b 40 34 8b 78 14 85 ff 75 04 <0f> 0b eb fe 8d 44 24 04
31 c9 c1 e2 03 89 04 24 89 d8 ff d7 85
EIP: [] ext2_clear_xip_target+0x1e/0x47 [ext2] SS:ESP 0068:cc863df8
-
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/

cpuset attach_task to touch per-cpu kernel threads?

[Srivatsa Vaddagiri]

Paul,
You had once revealed a cute one-line command to move all tasks from 
one cpuset to another [1], which was:

# move all tasks from top cpuset to 'foo' cpuset
sed -nu p < /dev/cpuset/tasks > /dev/cpuset/foo/tasks

I somewhat regret now having fallen for it and using it in my scripts.

To my agony, I found that it moves per-cpu kernel threads too, forcibly
breaking their affinity. In my case, rq->migration thread
(kernel/sched.c) was moved off cpu3 and started running on cpu2, which
caused nasty problems for me. I am sure this can lead to problems for
other per-cpu kernel threads, if their assumption of per-cpu'ness is
broken this way.

One could argue that 'root' user did this and nothing wrong in assuming
he knows what he is doing.

But I am wondering if attach_task() should leave kernel threads alone and
act only upon user-space threads. Or maybe allow movement if it doesn't
result in changing kernel-threads's cpu affinity.

Do you have anything to say regarding this?


Fyi, this was what I was doing (as root):

#!/bin/bash

mount -t container -o cpuset none /dev/cpuset
cd /dev/cpuset
mkdir sys   # create a cpuset to move all tasks into
mkdir test  # test cpuset in which my tests will run

# Assign cpus to both cpusets
cd sys; echo 0-2 > cpus; echo 0 > mems; echo 1 > cpu_exclusive; cd ..
cd test; echo 3 > cpus; echo 0 > mems; echo 1 > cpu_exclusive; cd ..

# Move all tasks to 'sys' cpuset so that cpu3 is dedicated to 
# only my chosen tasks

sed -nu p < /dev/cpuset/tasks > /dev/cpuset/tasks

echo $$ > test/tasks
/path_to/test_prg


References:

1.  http://marc.info/?l=linux-kernel=115627306628524

-- 
Regards,
vatsa
-
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] driver core: multithreaded probing - more parallelism control

[Huang, Ying]

On Wed, 2007-06-20 at 17:09 +0200, Stefan Richter wrote:
> I'd call it probe_queue_number or maybe probe_queue_id.  The term "no"
> is ambiguous.

Yes, I think probe_queue_id is better.

> Is the queue number kernel-global or per subsystem?

The queue number is kernel-global. I think this is easy to be
implemented. And the serialization demand between subsystem can be
satisfied too.

> > + * @probe: probing infromation include probing function and parameter
>   ^^^
> typo: information

Sorry, I will correct it in the next version.

Best Regards,
Huang Ying
-
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-20-10-12.tar.gz uploaded

[Bob Picco]

Randy Dunlap wrote: [Wed Jun 20 2007, 09:07:11PM EDT]
> On Wed, 20 Jun 2007 20:51:22 -0400 Bob Picco wrote:
> 
> > [EMAIL PROTECTED] wrote:[Wed Jun 20 2007, 01:14:34PM EDT]
> > [snip]
> > 
> > Build breakage. pci_mmcfg_late_init is for i386.
> 
> then you want CONFIG_X86_32 instead of CONFIG_X86.
> CONFIG_X86 is set/true for both X86_32 and X86_64.
Then what I stated within the patch description is incorrect. pci.h which is the
required include for the declaration is conditionally for CONFIG_X86. So it is
both I guess?

bob
> 
> 
> > Signed-off-by: Bob Picco <[EMAIL PROTECTED]>
> > 
> >  drivers/acpi/bus.c |2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > Index: linux-2.6.22-rc5-mm1/drivers/acpi/bus.c
> > ===
> > --- linux-2.6.22-rc5-mm1.orig/drivers/acpi/bus.c2007-06-20 
> > 14:09:07.0 -0400
> > +++ linux-2.6.22-rc5-mm1/drivers/acpi/bus.c 2007-06-20 20:32:00.0 
> > -0400
> > @@ -757,7 +757,9 @@ static int __init acpi_init(void)
> > result = acpi_bus_init();
> >  
> > if (!result) {
> > +#ifdef CONFIG_X86
> > pci_mmcfg_late_init();
> > +#endif
> >  #ifdef CONFIG_PM_LEGACY
> > if (!PM_IS_ACTIVE())
> > pm_active = 1;
> 
> 
> ---
> ~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-20-10-12.tar.gz uploaded

[Randy Dunlap]

On Wed, 20 Jun 2007 20:51:22 -0400 Bob Picco wrote:

> [EMAIL PROTECTED] wrote:  [Wed Jun 20 2007, 01:14:34PM EDT]
> [snip]
> 
> Build breakage. pci_mmcfg_late_init is for i386.

then you want CONFIG_X86_32 instead of CONFIG_X86.
CONFIG_X86 is set/true for both X86_32 and X86_64.


> Signed-off-by: Bob Picco <[EMAIL PROTECTED]>
> 
>  drivers/acpi/bus.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: linux-2.6.22-rc5-mm1/drivers/acpi/bus.c
> ===
> --- linux-2.6.22-rc5-mm1.orig/drivers/acpi/bus.c  2007-06-20 
> 14:09:07.0 -0400
> +++ linux-2.6.22-rc5-mm1/drivers/acpi/bus.c   2007-06-20 20:32:00.0 
> -0400
> @@ -757,7 +757,9 @@ static int __init acpi_init(void)
>   result = acpi_bus_init();
>  
>   if (!result) {
> +#ifdef CONFIG_X86
>   pci_mmcfg_late_init();
> +#endif
>  #ifdef CONFIG_PM_LEGACY
>   if (!PM_IS_ACTIVE())
>   pm_active = 1;


---
~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-20-10-12.tar.gz uploaded

[Bob Picco]

[EMAIL PROTECTED] wrote:[Wed Jun 20 2007, 01:14:34PM EDT]
[snip] 

More build breakage. efi_range_is_wc is referenced but not declared.


Signed-off-by: Bob Picco <[EMAIL PROTECTED]>

 include/asm-ia64/fb.h |1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.22-rc5-mm1/include/asm-ia64/fb.h
===
--- linux-2.6.22-rc5-mm1.orig/include/asm-ia64/fb.h 2007-06-20 
14:09:18.0 -0400
+++ linux-2.6.22-rc5-mm1/include/asm-ia64/fb.h  2007-06-20 20:40:48.0 
-0400
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
-
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-20-10-12.tar.gz uploaded

[Bob Picco]

[EMAIL PROTECTED] wrote:[Wed Jun 20 2007, 01:14:34PM EDT]
[snip]

Build breakage. pci_mmcfg_late_init is for i386.

Signed-off-by: Bob Picco <[EMAIL PROTECTED]>

 drivers/acpi/bus.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6.22-rc5-mm1/drivers/acpi/bus.c
===
--- linux-2.6.22-rc5-mm1.orig/drivers/acpi/bus.c2007-06-20 
14:09:07.0 -0400
+++ linux-2.6.22-rc5-mm1/drivers/acpi/bus.c 2007-06-20 20:32:00.0 
-0400
@@ -757,7 +757,9 @@ static int __init acpi_init(void)
result = acpi_bus_init();
 
if (!result) {
+#ifdef CONFIG_X86
pci_mmcfg_late_init();
+#endif
 #ifdef CONFIG_PM_LEGACY
if (!PM_IS_ACTIVE())
pm_active = 1;
-
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 3/9] i386: clean up bzImage generation

[Jeremy Fitzhardinge]

This patch cleans up image generation in several ways:
 - Firstly, it removes tools/build, and uses binutils to do all the
   final construction of the bzImage.  This removes a chunk of code
   and makes the image generation more flexible, since we can compute
   various numbers rather than be forced to use fixed constants.

 - Rename compressed/vmlinux to compressed/blob, to make it a
   bit clearer that it's the compressed kernel image + decompressor
   (now all the files named "vmlinux*" are directly derived from
   the kernel vmlinux).

 - Rather than using objcopy to wrap the compressed kernel into an
   object file, simply use the assembler: payload.S does a .bininc
   of the blob.bin file, which allows us to easily place
   it into a section, and it makes the Makefile dependency a little
   clearer.

 - Similarly, use the same technique to create compressed/piggy.o,
   which cleans things up even more, since the .S file can also
   set the input and output_size symbols without further linker
   script hackery; it also removes a complete linker script.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>

---
 arch/i386/boot/Makefile |   31 +
 arch/i386/boot/compressed/Makefile  |   13 --
 arch/i386/boot/compressed/piggy.S   |   10 +
 arch/i386/boot/compressed/vmlinux.lds   |3 
 arch/i386/boot/compressed/vmlinux.scr   |   10 -
 arch/i386/boot/header.S |7 -
 arch/i386/boot/payload.S|3 
 arch/i386/boot/setup.ld |   37 --
 arch/i386/boot/tools/.gitignore |1 
 arch/i386/boot/tools/build.c|  168 ---
 arch/x86_64/boot/compressed/Makefile|   12 --
 arch/x86_64/boot/compressed/piggy.S |   10 +
 arch/x86_64/boot/compressed/vmlinux.lds |2 
 arch/x86_64/boot/compressed/vmlinux.scr |   10 -
 14 files changed, 73 insertions(+), 244 deletions(-)

===
--- a/arch/i386/boot/Makefile
+++ b/arch/i386/boot/Makefile
@@ -25,12 +25,13 @@ SVGA_MODE := -DSVGA_MODE=NORMAL_VGA
 
 #RAMDISK := -DRAMDISK=512
 
-targets:= vmlinux.bin setup.bin setup.elf zImage bzImage
+targets:= blob.bin setup.elf zImage bzImage
 subdir-:= compressed
 
 setup-y+= a20.o apm.o cmdline.o copy.o cpu.o cpucheck.o edd.o
-setup-y+= header.o main.o mca.o memory.o pm.o pmjump.o
-setup-y+= printf.o string.o tty.o video.o version.o voyager.o
+setup-y+= header.o main.o mca.o memory.o payload.o pm.o
+setup-y+= pmjump.o printf.o string.o tty.o video.o version.o
+setup-y+= voyager.o
 
 # The link order of the video-*.o modules can matter.  In particular,
 # video-vga.o *must* be listed first, followed by video-vesa.o.
@@ -39,10 +40,6 @@ setup-y  += video-vga.o
 setup-y+= video-vga.o
 setup-y+= video-vesa.o
 setup-y+= video-bios.o
-
-hostprogs-y:= tools/build
-
-HOSTCFLAGS_build.o := $(LINUXINCLUDE)
 
 # ---
 
@@ -65,18 +62,12 @@ AFLAGS  := $(CFLAGS) -D__ASSEMBLY__
 $(obj)/bzImage: IMAGE_OFFSET := 0x10
 $(obj)/bzImage: EXTRA_CFLAGS := -D__BIG_KERNEL__
 $(obj)/bzImage: EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__
-$(obj)/bzImage: BUILDFLAGS   := -b
 
-quiet_cmd_image = BUILD   $@
-cmd_image = $(obj)/tools/build $(BUILDFLAGS) $(obj)/setup.bin \
-   $(obj)/vmlinux.bin $(ROOT_DEV) > $@
-
-$(obj)/zImage $(obj)/bzImage: $(obj)/setup.bin \
- $(obj)/vmlinux.bin $(obj)/tools/build FORCE
-   $(call if_changed,image)
+$(obj)/zImage $(obj)/bzImage: $(obj)/setup.elf FORCE
+   $(call if_changed,objcopy)
@echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
 
-$(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
+$(obj)/blob.bin: $(obj)/compressed/blob FORCE
$(call if_changed,objcopy)
 
 SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
@@ -85,12 +76,10 @@ LDFLAGS_setup.elf   := -T
 $(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
$(call if_changed,ld)
 
-OBJCOPYFLAGS_setup.bin := -O binary
+$(obj)/payload.o:  EXTRA_AFLAGS := -Wa,-I$(obj)
+$(obj)/payload.o: $(src)/payload.S $(obj)/blob.bin
 
-$(obj)/setup.bin: $(obj)/setup.elf FORCE
-   $(call if_changed,objcopy)
-
-$(obj)/compressed/vmlinux: FORCE
+$(obj)/compressed/blob: FORCE
$(Q)$(MAKE) $(build)=$(obj)/compressed IMAGE_OFFSET=$(IMAGE_OFFSET) $@
 
 # Set this if you want to pass append arguments to the zdisk/fdimage/isoimage 
kernel
===
--- a/arch/i386/boot/compressed/Makefile
+++ 

[PATCH 0/9] x86 boot protocol updates

[Jeremy Fitzhardinge]

[ This patch depends on the cross-architecture ELF cleanup patch. ]

This series updates the boot protocol to 2.07 and uses it to implement
paravirtual booting.  This allows the bootloader to tell the kernel
what kind of hardware/pseudo-hardware environment it's coming up under,
and the kernel can use the appropriate boot sequence code.

Specifically:

- Update the boot protocol to 2.07, which adds fields to specify the
  hardware subarchitecture and some subarchitecture-specific data.
  It also specifies a flag to tell the boot code to avoid reloading
  segment registers and playing with interrupt state, since it may not
  have a visible gdt and/or may not be running in ring 0.
  (Note: the segment reload and interrupt flags are conflated into one
   flag, but they are not really related.  We could have two flags, but
   the "cli" is probably completely redundant anyway, since the bootloader
   would have to be completely mad to start the kernel with interrupts
   enabled.)

- Change the format of bzImage to contain an ELF file.  The initial part of
  the bzImage is still the boot_params header followed by the 16-bit
  setup code needed for booting from BIOS.  But rather than having
  the self-decompressing kernel follow as a naked blob of code+data,
  its actually wrapped in a page-aligned ELF file.  This allows the
  bootloader to extract it and parse it, and use that to know what
  memory the booting kernel will need initially.  Xen and lguest need
  this because they start the kernel with paging enabled, and so need
  to know what initial mappings to create.

- Modify the kernel boot sequence to:
  1. avoid reloading the segment state (gdt and segment registers) if the
 bootloader asks it to
  2. jump to a subarchitecture-specific entrypoint in kernel/head.S.

- Add Xen-specific starup code, which mainly remaps the kernel from
  its P=V identity mapping to the normal PAGE_OFFSET mapping.

  One open issue is that I haven't made the normal head.S initial
  pagetable construction code generally reusable.  The default
  boot-on-normal x86 hardware still uses it of course, but other
  subarchitectures like Voyager and lguest could probably use it as-is,
  while still needing to do other specialized things.

  The obvious fix is to make it a callable function, but we don't
  generally assume there's a stack available at this early stage.
  It looks like it would be easy to set one up though.

As a pre-requisite for all the above, I've also cleaned up the bzImage
build process process.  I've eliminated the need for the tools/build
program, and instead use the linker to do more heavy lifting.  I've also
removed some somewhat obscure uses of ld and objcopy wrap binary files
in ELF .o wrappers, and replaced with with .S files containing .incbin.

The downside is that its making a bit more complex use of linker scripts,
which always opens scope for finding more binutils bugs.  Only one way
to find out...

Tested to check the generated kernels boot under qemu's internal bootload
and grub, as well as booting under Xen (with an appropriate update to
the Xen domain builder).

TODO:
 - poke Rusty into implementing the lguest bits
 - look at Kbuild use in arch/{i386,x86_64}/boot/

J

-- 

-
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/9] update boot spec to 2.07

[Jeremy Fitzhardinge]

Proposed updates for version 2.07 of the boot protocol.  This includes:

load_flags.KEEP_SEGMENTS- flag to request/inhibit segment reloads
hardware_subarch- what subarchitecture we're booting under
hardware_subarch_data   - per-architecture data

The intention of these changes is to make booting a paravirtualized
kernel work via the normal Linux boot protocol.  The intention is that
the bzImage payload can be a properly formed ELF file, so that the
bootloader can use its ELF notes and Phdrs to get more metadata about
the kernel and its requirements.

The ELF file could be the uncompressed kernel vmlinux itself; it would
only take small buildsystem changes to implement this.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>

---
 Documentation/i386/boot.txt|   34 +-
 arch/i386/kernel/asm-offsets.c |7 +++
 include/asm-i386/bootparam.h   |9 +++--
 3 files changed, 47 insertions(+), 3 deletions(-)

===
--- a/Documentation/i386/boot.txt
+++ b/Documentation/i386/boot.txt
@@ -168,6 +168,8 @@ 0234/1  2.05+   relocatable_kernel Whether 
 0234/1 2.05+   relocatable_kernel Whether kernel is relocatable or not
 0235/3 N/A pad2Unused
 0238/4 2.06+   cmdline_sizeMaximum size of the kernel command line
+023C/4 2.07+   hardware_subarch Hardware subarchitecture
+0240/8 2.07+   hardware_subarch_data Subarchitecture-specific data
 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
 real value is 4.
@@ -204,7 +206,7 @@ boot loaders can ignore those fields.
 
 The byte order of all fields is littleendian (this is x86, after all.)
 
-Field name:setup_secs
+Field name:setup_sects
 Type:  read
 Offset/size:   0x1f1/1
 Protocol:  ALL
@@ -356,6 +358,13 @@ Protocol:  2.00+
- If 0, the protected-mode code is loaded at 0x1.
- If 1, the protected-mode code is loaded at 0x10.
 
+  Bit 6 (write): KEEP_SEGMENTS
+   Protocol: 2.07+
+   - if 0, reload the segment registers in the 32bit entry point.
+   - if 1, do not reload the segment registers in the 32bit entry point.
+   Assume that %cs %ds %ss %es are all set to flat segments with
+   a base of 0 (or the equivalent for their environment).
+
   Bit 7 (write): CAN_USE_HEAP
Set this bit to 1 to indicate that the value entered in the
heap_end_ptr is valid.  If this field is clear, some setup code
@@ -479,6 +488,29 @@ Protocol:  2.06+
   zero. This means that the command line can contain at most
   cmdline_size characters. With protocol version 2.05 and earlier, the
   maximum size was 255.
+
+Field name:hardware_subarch
+Type:  write
+Offset/size:   0x23c/4
+Protocol:  2.07+
+
+  In a paravirtualized environment the hardware low level architectural
+  pieces such as interrupt handling, page table handling, and
+  accessing process control registers needs to be done differently.
+
+  This field allows the bootloader to inform the kernel we are in one
+  one of those environments.
+
+  0x   The default x86/PC environment
+  0x0001   lguest
+  0x0002   Xen
+
+Field name:hardware_subarch_data
+Type:  write
+Offset/size:   0x240/8
+Protocol:  2.07+
+
+  A pointer to data that is specific to hardware subarch
 
 
  THE KERNEL COMMAND LINE
===
--- a/arch/i386/kernel/asm-offsets.c
+++ b/arch/i386/kernel/asm-offsets.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -143,4 +144,10 @@ void foo(void)
OFFSET(LGUEST_PAGES_regs_errcode, lguest_pages, regs.errcode);
OFFSET(LGUEST_PAGES_regs, lguest_pages, regs);
 #endif
+
+   BLANK();
+   OFFSET(BP_scratch, boot_params, scratch);
+   OFFSET(BP_loadflags, boot_params, hdr.loadflags);
+   OFFSET(BP_hardware_subarch, boot_params, hdr.hardware_subarch);
+   OFFSET(BP_version, boot_params, hdr.version);
 }
===
--- a/include/asm-i386/bootparam.h
+++ b/include/asm-i386/bootparam.h
@@ -24,8 +24,9 @@ struct setup_header {
u16 kernel_version;
u8  type_of_loader;
u8  loadflags;
-#define LOADED_HIGH0x01
-#define CAN_USE_HEAP   0x80
+#define LOADED_HIGH(1<<0)
+#define KEEP_SEGMENTS  (1<<6)
+#define CAN_USE_HEAP   (1<<7)
u16 setup_move_size;
u32 code32_start;
u32 ramdisk_image;
@@ -37,6 +38,10 @@ struct setup_header {
u32 initrd_addr_max;
u32 kernel_alignment;
u8  relocatable_kernel;
+   u8  _pad2[3];
+   u32 cmdline_size;
+   u32 hardware_subarch;
+   

[PATCH 7/9] i386: paravirt boot sequence

[Jeremy Fitzhardinge]

This patch uses the updated boot protocol to do paravirtualized boot.
If the boot version is >= 2.07, then it will do two things:

 1. Check the bootparams loadflags to see if we should reload the
segment registers and clear interrupts.  This is appropriate
for normal native boot and some paravirtualized environments, but
inapproprate for others.

 2. Check the hardware architecture, and dispatch to the appropriate
kernel entrypoint.  If the bootloader doesn't set this, then we
simply do the normal boot sequence.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
---
 arch/i386/boot/compressed/head.S |   14 +--
 arch/i386/boot/compressed/misc.c |4 +++
 arch/i386/boot/header.S  |7 -
 arch/i386/kernel/head.S  |   47 ++
 4 files changed, 65 insertions(+), 7 deletions(-)

===
--- a/arch/i386/boot/compressed/head.S
+++ b/arch/i386/boot/compressed/head.S
@@ -33,14 +33,24 @@
.globl blob_startup_32
 
 blob_startup_32:
-   cld
-   cli
+   /* check to see if KEEP_SEGMENTS flag is meaningful */
+   cmpw $0x207, BP_version(%esi)
+   jb 1f
+
+   /* test KEEP_SEGMENTS flag to see if the bootloader is asking
+   us to not reload segments */
+   testb $(1<<6), BP_loadflags(%esi)
+   jnz 2f
+
+1: cli
movl $(__BOOT_DS),%eax
movl %eax,%ds
movl %eax,%es
movl %eax,%fs
movl %eax,%gs
movl %eax,%ss
+
+2: cld
 
 /* Calculate the delta between where we were compiled to run
  * at and where we were actually loaded at.  This can only be done
===
--- a/arch/i386/boot/compressed/misc.c
+++ b/arch/i386/boot/compressed/misc.c
@@ -245,6 +245,10 @@ static void putstr(const char *s)
 {
int x,y,pos;
char c;
+
+   if (RM_SCREEN_INFO.orig_video_mode == 0 &&
+   lines == 0 && cols == 0)
+   return;
 
x = RM_SCREEN_INFO.orig_x;
y = RM_SCREEN_INFO.orig_y;
===
--- a/arch/i386/boot/header.S
+++ b/arch/i386/boot/header.S
@@ -119,7 +119,7 @@ 1:
# Part 2 of the header, from the old setup.S
 
.ascii  "HdrS"  # header signature
-   .word   0x0206  # header version number (>= 0x0105)
+   .word   0x0207  # header version number (>= 0x0105)
# or else old loadlin-1.5 will fail)
.globl realmode_swtch
 realmode_swtch:.word   0, 0# default_switch, SETUPSEG
@@ -209,6 +209,11 @@ cmdline_size:   .long   COMMAND_LINE_SIZ
 #added with boot protocol
 #version 2.06
 
+hardware_subarch:  .long 0 # subarchitecture, added with 
2.07
+   # default to 0 for normal x86 PC
+
+hardware_subarch_data: .quad 0
+
 # End of setup header #
 
.section ".inittext", "ax"
===
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -86,28 +86,37 @@ pg0_init_size = ROUNDUP(INIT_MAP_BEYOND_
  */
 .section .text.head,"ax",@progbits
 ENTRY(startup_32)
+   /* check to see if KEEP_SEGMENTS flag is meaningful */
+   cmpw $0x207, BP_version(%esi)
+   jb 1f
+
+   /* test KEEP_SEGMENTS flag to see if the bootloader is asking
+   us to not reload segments */
+   testb $(1<<6), BP_loadflags(%esi)
+   jnz 2f
 
 /*
  * Set segments to known values.
  */
-   cld
-   lgdt boot_gdt_descr - __PAGE_OFFSET
+1: lgdt boot_gdt_descr - __PAGE_OFFSET
movl $(__BOOT_DS),%eax
movl %eax,%ds
movl %eax,%es
movl %eax,%fs
movl %eax,%gs
+2:
 
 /*
  * Clear BSS first so that there are no surprises...
- * No need to cld as DF is already clear from cld above...
- */
+ */
+   cld
xorl %eax,%eax
movl $__bss_start - __PAGE_OFFSET,%edi
movl $__bss_stop - __PAGE_OFFSET,%ecx
subl %edi,%ecx
shrl $2,%ecx
rep ; stosl
+
 /*
  * Copy bootup parameters out of the way.
  * Note: %esi still has the pointer to the real-mode data.
@@ -135,6 +144,35 @@ 2:
movsl
 1:
 
+#ifdef CONFIG_PARAVIRT
+   cmpw $0x207, (boot_params + BP_version - __PAGE_OFFSET)
+   jb default_entry
+
+   /* Paravirt-compatible boot parameters.  Look to see what architecture
+   we're booting under. */
+   movl (boot_params + 

[PATCH 8/9] ask the hypervisor how much space it needs reserved

[Jeremy Fitzhardinge]

Ask the hypervisor how much space it needs reserved, since 32-on-64
doesn't need any space, and it may change in future.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 arch/i386/xen/enlighten.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

===
--- a/arch/i386/xen/enlighten.c
+++ b/arch/i386/xen/enlighten.c
@@ -1085,6 +1085,17 @@ static const struct machine_ops __initda
 };
 
 
+static void __init xen_reserve_top(void)
+{
+   unsigned long top = HYPERVISOR_VIRT_START;
+   struct xen_platform_parameters pp;
+
+   if (HYPERVISOR_xen_version(XENVER_platform_parameters, ) == 0)
+   top = pp.virt_start;
+
+   reserve_top_address(-top + 2 * PAGE_SIZE);
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1134,7 +1145,7 @@ asmlinkage void __init xen_start_kernel(
paravirt_ops.kernel_rpl = 0;
 
/* set the limit of our address space */
-   reserve_top_address(-HYPERVISOR_VIRT_START + 2 * PAGE_SIZE);
+   xen_reserve_top();
 
/* set up basic CPUID stuff */
cpu_detect(_cpu_data);

-- 

-
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 4/9] i386: make the bzImage payload an ELF file

[Jeremy Fitzhardinge]

This patch makes the payload of the bzImage file an ELF file.  In
other words, the bzImage is structured as follows:
 - boot sector
 - 16bit setup code
 - ELF header
  - decompressor
  - compressed kernel

A bootloader may find the start of the ELF file by looking at the
setup_size entry in the boot params, and using that to find the offset
of the ELF header.  The ELF Phdrs contain all the mapped memory
required to decompress and start booting the kernel.

One slightly complex part of this is that the bzImage boot_params need
to know about the internal structure of the ELF file, at least to the
extent of being able to point the core32_start entry at the ELF file's
entrypoint, so that loaders which use this field will still work.

Similarly, the ELF header needs to know how big the kernel vmlinux's
bss segment is, in order to make sure is is mapped properly.

To handle these two cases, we generate abstracted versions of the
object files which only contain the symbols we care about (generated
with objcopy --strip-all --keep-symbol=X), and then include those
symbol tables with ld -R.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
---
 arch/i386/boot/Makefile |   11 +++--
 arch/i386/boot/compressed/Makefile  |   18 ++--
 arch/i386/boot/compressed/elfhdr.c  |   65 +++
 arch/i386/boot/compressed/head.S|9 ++--
 arch/i386/boot/compressed/notes.c   |7 +++
 arch/i386/boot/compressed/piggy.S   |5 +-
 arch/i386/boot/compressed/vmlinux.lds   |   29 +++--
 arch/i386/boot/header.S |   14 ++
 arch/i386/boot/setup.ld |5 +-
 arch/i386/kernel/asm-offsets.c  |2 
 arch/i386/kernel/head.S |   26 ++--
 arch/i386/kernel/vmlinux.lds.S  |4 +
 arch/x86_64/boot/compressed/Makefile|   22 --
 arch/x86_64/boot/compressed/elfhdr.c|1 
 arch/x86_64/boot/compressed/head.S  |   12 ++---
 arch/x86_64/boot/compressed/vmlinux.lds |   21 +-
 arch/x86_64/kernel/vmlinux.lds.S|3 +
 include/asm-x86_64/elf-defines.h|5 ++
 include/asm-x86_64/elf.h|2 
 scripts/Makefile.lib|   11 +
 20 files changed, 226 insertions(+), 46 deletions(-)

===
--- a/arch/i386/boot/Makefile
+++ b/arch/i386/boot/Makefile
@@ -72,14 +72,19 @@ AFLAGS  := $(CFLAGS) -D__ASSEMBLY__
 
 SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
 
-LDFLAGS_setup.elf  := -T
-$(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
+$(obj)/zImage $(obj)/bzImage:  \
+   LDFLAGS :=  \
+   -R $(obj)/compressed/blob-syms  \
+   --defsym IMAGE_OFFSET=$(IMAGE_OFFSET) -T
+
+$(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS)\
+   $(obj)/compressed/blob-syms FORCE
$(call if_changed,ld)
 
 $(obj)/payload.o:  EXTRA_AFLAGS := -Wa,-I$(obj)
 $(obj)/payload.o: $(src)/payload.S $(obj)/blob.bin
 
-$(obj)/compressed/blob: FORCE
+$(obj)/compressed/blob $(obj)/compressed/blob-syms: FORCE
$(Q)$(MAKE) $(build)=$(obj)/compressed IMAGE_OFFSET=$(IMAGE_OFFSET) $@
 
 # Set this if you want to pass append arguments to the zdisk/fdimage/isoimage 
kernel
===
--- a/arch/i386/boot/compressed/Makefile
+++ b/arch/i386/boot/compressed/Makefile
@@ -4,21 +4,31 @@
 # create a compressed vmlinux image from the original vmlinux
 #
 
-targets:= blob vmlinux.bin vmlinux.bin.gz head.o misc.o 
piggy.o \
+targets:= blob vmlinux.bin vmlinux.bin.gz \
+   elfhdr.o head.o misc.o notes.o piggy.o \
vmlinux.bin.all vmlinux.relocs
 
-LDFLAGS_blob   := -T
 hostprogs-y:= relocs
 
 CFLAGS  := -m32 -D__KERNEL__ $(LINUX_INCLUDE) -O2 \
   -fno-strict-aliasing -fPIC \
   $(call cc-option,-ffreestanding) \
   $(call cc-option,-fno-stack-protector)
-LDFLAGS := -m elf_i386
+LDFLAGS := -R $(obj)/vmlinux-syms --defsym IMAGE_OFFSET=$(IMAGE_OFFSET) -T
 
-$(obj)/blob: $(src)/vmlinux.lds $(obj)/head.o $(obj)/misc.o $(obj)/piggy.o 
FORCE
+OBJS=$(addprefix $(obj)/,elfhdr.o head.o misc.o notes.o piggy.o)
+
+$(obj)/blob: $(src)/vmlinux.lds $(obj)/vmlinux-syms $(OBJS) FORCE
$(call if_changed,ld)
@:
+
+EXTRACTSYMS_blob-syms := blob_entry_32
+$(obj)/blob-syms: $(obj)/blob FORCE
+   $(call if_changed,symextract)
+
+EXTRACTSYMS_vmlinux-syms := __kernel_end __kernel_data_size
+$(obj)/vmlinux-syms: vmlinux FORCE
+   $(call if_changed,symextract)
 
 $(obj)/vmlinux.bin: vmlinux FORCE
$(call 

[PATCH 2/9] define ELF notes for adding to a boot image

[Jeremy Fitzhardinge]

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL PROTECTED]>

---
 include/linux/elf_boot.h |   15 +++
 1 file changed, 15 insertions(+)

===
--- /dev/null
+++ b/include/linux/elf_boot.h
@@ -0,0 +1,15 @@
+#ifndef ELF_BOOT_H
+#define ELF_BOOT_H
+
+/* Elf notes to help bootloaders identify what program they are booting.
+ */
+
+/* Standardized Elf image notes for booting... The name for all of these is 
ELFBoot */
+#define ELF_NOTE_BOOT  "ELFBoot"
+
+#define EIN_PROGRAM_NAME   1 /* The program in this ELF file */
+#define EIN_PROGRAM_VERSION2 /* The version of the program in this ELF 
file */
+#define EIN_PROGRAM_CHECKSUM   3 /* ip style checksum of the memory image. */
+#define EIN_ARGUMENT_STYLE 4 /* String identifying argument passing style 
*/
+
+#endif /* ELF_BOOT_H */

-- 

-
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 9/9] xen: use boot protocol to boot xen kernel

[Jeremy Fitzhardinge]

Boot a Xen kernel using the boot protocol.  There are two parts to this:

1. Add Xen-specific notes to the bzImage's internal ELF file, so that
   the Xen domain builder knows what to do with it.  This is simply a
   matter of adding a new notes-xen.S to the image.  The notes depend
   on the config options, but they contain no addresses, so there's no
   concern about relocation, or references into the kernel image itself.

2. Do the early setup after booting, mainly to remap the kernel to
   the proper virtual address.  The kernel initially comes up with
   a P=V 1:1 mapping.  We need to copy the appropriate internal pagetable
   pointers to get the kernel also mapped at __PAGE_OFFSET.  In order
   to simplify this process, we just keep the same pte pages, and only
   update the pgd/pmd entries (depending on whether its PAE or not, and
   whether the kernel and Xen want to share the same pgd slot).

   A pre-requisite for updating the pagetables is setting up the
   hypercall page in order to do hypercalls.  Rather than using the
   Xen Notes to set this up (which would require a relocatable
   reference from the bzImage notes into the kernel), we use the Xen
   reserved MSR to set the page address.

   Once the kernel has been relocated, we update some of the pointers
   in the start_info to kernel virtual addresses, and then jump to
   xen_start_kernel() to do the rest of the setup before calling
   start_kernel() proper.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 arch/i386/boot/compressed/Makefile|4 
 arch/i386/boot/compressed/notes-xen.c |   17 ++
 arch/i386/kernel/head.S   |2 
 arch/i386/xen/Makefile|2 
 arch/i386/xen/early.c |  216 +
 arch/i386/xen/enlighten.c |   29 +---
 arch/i386/xen/xen-head.S  |   38 -
 arch/i386/xen/xen-ops.h   |1 
 include/asm-i386/xen/hypercall.h  |4 
 9 files changed, 252 insertions(+), 61 deletions(-)

===
--- a/arch/i386/boot/compressed/Makefile
+++ b/arch/i386/boot/compressed/Makefile
@@ -5,7 +5,7 @@
 #
 
 targets:= blob vmlinux.bin vmlinux.bin.gz \
-   elfhdr.o head.o misc.o notes.o piggy.o \
+   elfhdr.o head.o misc.o notes.o notes-xen.o piggy.o \
vmlinux.bin.all vmlinux.relocs
 
 hostprogs-y:= relocs
@@ -16,7 +16,7 @@ CFLAGS  := -m32 -D__KERNEL__ $(LINUX_INC
   $(call cc-option,-fno-stack-protector)
 LDFLAGS := -R $(obj)/vmlinux-syms --defsym IMAGE_OFFSET=$(IMAGE_OFFSET) -T
 
-OBJS=$(addprefix $(obj)/,elfhdr.o head.o misc.o notes.o piggy.o)
+OBJS=$(addprefix $(obj)/,elfhdr.o head.o misc.o notes.o notes-xen.o piggy.o)
 
 $(obj)/blob: $(src)/vmlinux.lds $(obj)/vmlinux-syms $(OBJS) FORCE
$(call if_changed,ld)
===
--- /dev/null
+++ b/arch/i386/boot/compressed/notes-xen.c
@@ -0,0 +1,17 @@
+#ifdef CONFIG_XEN
+#include 
+#include 
+
+ELFNOTE("Xen", XEN_ELFNOTE_GUEST_OS,   "linux");
+ELFNOTE("Xen", XEN_ELFNOTE_GUEST_VERSION,  "2.6");
+ELFNOTE("Xen", XEN_ELFNOTE_XEN_VERSION,"xen-3.0");
+ELFNOTE("Xen", XEN_ELFNOTE_FEATURES,
+   "!writable_page_tables|pae_pgdir_above_4gb");
+ELFNOTE("Xen", XEN_ELFNOTE_LOADER, "generic");
+
+#ifdef CONFIG_X86_PAE
+   ELFNOTE("Xen", XEN_ELFNOTE_PAE_MODE,   "yes");
+#else
+   ELFNOTE("Xen", XEN_ELFNOTE_PAE_MODE,   "no");
+#endif
+#endif
===
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -594,8 +594,6 @@ fault_msg:
.ascii "Int %d: CR2 %p  err %p  EIP %p  CS %p  flags %p\n"
.asciz "Stack: %p %p %p %p %p %p %p %p\n"
 
-#include "../xen/xen-head.S"
-
 /*
  * The IDT and GDT 'descriptors' are a strange 48-bit object
  * only used by the lidt and lgdt instructions. They are not
===
--- a/arch/i386/xen/Makefile
+++ b/arch/i386/xen/Makefile
@@ -1,4 +1,4 @@ obj-y   := enlighten.o setup.o features.o
-obj-y  := enlighten.o setup.o features.o multicalls.o mmu.o \
+obj-y  := early.o enlighten.o setup.o features.o multicalls.o mmu.o \
events.o time.o manage.o xen-asm.o
 
 obj-$(CONFIG_SMP)  += smp.o
===
--- /dev/null
+++ b/arch/i386/xen/early.c
@@ -0,0 +1,216 @@
+/*
+ * Very earliest code, run before we're in the kernel virtual address
+ * space.  As a result, we need to be careful about touching static
+ * symbols or any absolute address.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "xen-ops.h"
+
+#define PA(ptr)((typeof(ptr)) __pa_symbol((ptr)))
+
+extern char 

[PATCH 6/9] always allocate space for notes

[Jeremy Fitzhardinge]

This patch makes .note segments always allocated; that is, they are
loaded as part of the binary and appear in the :data segment.  This is
not always necessary, but certain users - such as vsyscalls and notes
in boot images - require the notes to be allocated.  Rather than
having two ways of creating notes, just have one which suits
everyone.  The only downside is that the notes will actually consume
space at runtime.  This isn't a big deal, since a typical kernel
doesn't have very many, if any.

Also, make the ELFNOTE() macro do the right thing in 32/64 bit
environments.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 arch/i386/kernel/vmlinux.lds.S|9 -
 arch/i386/kernel/vsyscall-note.S  |4 +---
 include/asm-generic/vmlinux.lds.h |7 ++-
 include/linux/elfnote.h   |2 +-
 4 files changed, 12 insertions(+), 10 deletions(-)

===
--- a/arch/i386/kernel/vmlinux.lds.S
+++ b/arch/i386/kernel/vmlinux.lds.S
@@ -28,10 +28,9 @@ jiffies = jiffies_64;
 jiffies = jiffies_64;
 
 PHDRS {
-   text PT_LOAD FLAGS(5);  /* R_E */
-   data PT_LOAD FLAGS(7);  /* RWE */
-   note PT_NOTE FLAGS(0);  /* ___ */
+   STD_PHDRS
 }
+
 SECTIONS
 {
   . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR;
@@ -72,6 +71,8 @@ SECTIONS
   _sdata = .;  /* End of text section */
 
   RODATA
+
+  NOTES
 
   /* writeable */
   . = ALIGN(4096);
@@ -211,6 +212,4 @@ SECTIONS
   STABS_DEBUG
 
   DWARF_DEBUG
-
-  NOTES
 }
===
--- a/arch/i386/kernel/vsyscall-note.S
+++ b/arch/i386/kernel/vsyscall-note.S
@@ -9,9 +9,7 @@
 /* Ideally this would use UTS_NAME, but using a quoted string here
doesn't work. Remember to change this when changing the
kernel's name. */
-ELFNOTE_START(Linux, 0, "a")
-   .long LINUX_VERSION_CODE
-ELFNOTE_END
+ELFNOTE(Linux, 0, .long LINUX_VERSION_CODE)
 
 #ifdef CONFIG_XEN
 
===
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -245,8 +245,13 @@
__stop___bug_table = .; \
}
 
+#define STD_PHDRS  \
+   text PT_LOAD FILEHDR PHDRS FLAGS(5);/* R_E */   \
+   data PT_LOAD FLAGS(7);  /* RWE */   \
+   note PT_NOTE FLAGS(0);  /* ___ */
+
 #define NOTES  \
-   .notes : { *(.note.*) } :note
+   .notes : { *(.note.*) } :data :note
 
 #define INITCALLS  \
*(.initcall0.init)  \
===
--- a/include/linux/elfnote.h
+++ b/include/linux/elfnote.h
@@ -53,7 +53,7 @@ 4484:.balign 4;   \
 .popsection;
 
 #define ELFNOTE(name, type, desc)  \
-   ELFNOTE_START(name, type, "")   \
+   ELFNOTE_START(name, type, "a")  \
desc;   \
ELFNOTE_END
 

-- 

-
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 5/9] add WEAK() for creating weak asm labels

[Jeremy Fitzhardinge]

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

---
 include/linux/linkage.h |6 ++
 1 file changed, 6 insertions(+)

===
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -34,6 +34,12 @@
   name:
 #endif
 
+#ifndef WEAK
+#define WEAK(name)\
+   .weak name;\
+   name:
+#endif
+
 #define KPROBE_ENTRY(name) \
   .pushsection .kprobes.text, "ax"; \
   ENTRY(name)

-- 

-
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] blink: Only blink when parameter is set

[Jiri Kosina]

On Thu, 21 Jun 2007, Pavel Machek wrote:

> > this has probably been already solved by proper throttling - see 
> > http://lkml.org/lkml/2007/6/15/22
> No, it was not. I still saw the problems with CONFIG_BLINK on, that is
> one blink per 5 seconds or something.
> We should rename CONFIG_BLINK to
> CONFIG_BREAK_THINKPAD_KEYBOARD_AND_MORE.

In fact it looks quite weird that one blink per 5 seconds can break the 
keyboard, in fact.

Seems like Dmitry is missing in CC, added.

Thanks,

-- 
Jiri Kosina
-
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] zero_user_page conversion

[Mark Fasheh]

On Wed, Jun 20, 2007 at 05:08:24PM -0500, Eric Sandeen wrote:
> Use zero_user_page() in cifs, ocfs2, ext4, and gfs2 where possible.

Ok, the ocfs2 bits looked fine so I folded that part of the patch into
ocfs2.git, thanks.
--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
[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: [31/37] Large blocksize support: Core piece

[Bob Picco]

Christoph Lameter wrote:[Wed Jun 20 2007, 02:29:38PM EDT]
> Provide an alternate definition for the page_cache_xxx(mapping, ...)
> functions that can determine the current page size from the mapping
> and generate the appropriate shifts, sizes and mask for the page cache
> operations. Change the basic functions that allocate pages for the
> page cache to be able to handle higher order allocations.
> 
> Provide a new function
> 
> mapping_setup(stdruct address_space *, gfp_t mask, int order)
> 
> that allows the setup of a mapping of any compound page order.
> 
> mapping_set_gfp_mask() is still provided but it sets mappings to order 0.
> Calls to mapping_set_gfp_mask() must be converted to mapping_setup() in
> order for the filesystem to be able to use larger pages. For some key block
> devices and filesystems the conversion is done here.
> 
> mapping_setup() for higher order is only allowed if the mapping does not
> use DMA mappings or HIGHMEM since we do not support bouncing at the moment.
> Thus we currently BUG() on DMA mappings and clear the highmem bit of higher
> order mappings.
> 
> Modify the set_blocksize() function so that an arbitrary blocksize can be set.
> Blocksizes up to MAX_ORDER can be set. This is typically 8MB on many
> platforms (order 11). Typically file systems are not only limited by the core
> VM but also by the structure of their internal data structures. The core VM
> limitations fall away with this patch. The functionality provided here
> can do nothing about the internal limitations of filesystems.
> 
> Known internal limitations:
> 
> Ext2  64k
> XFS   64k
> Reiserfs  8k
> Ext3  4k
> Ext4  4k
> 
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> 
> ---
>  block/Kconfig   |   17 ++
>  drivers/block/rd.c  |6 +-
>  fs/block_dev.c  |   29 +++
>  fs/buffer.c |2 
>  fs/inode.c  |7 +-
>  fs/xfs/linux-2.6/xfs_buf.c  |3 -
>  include/linux/buffer_head.h |   12 
>  include/linux/fs.h  |5 +
>  include/linux/pagemap.h |  116 
> +---
>  mm/filemap.c|   17 --
>  10 files changed, 186 insertions(+), 28 deletions(-)
> 
> Index: linux-2.6.22-rc4-mm2/include/linux/pagemap.h
> ===
> --- linux-2.6.22-rc4-mm2.orig/include/linux/pagemap.h 2007-06-19 
> 23:33:44.0 -0700
> +++ linux-2.6.22-rc4-mm2/include/linux/pagemap.h  2007-06-19 
> 23:50:55.0 -0700
> @@ -39,10 +39,30 @@ static inline gfp_t mapping_gfp_mask(str
>   * This is non-atomic.  Only to be used before the mapping is activated.
>   * Probably needs a barrier...
>   */
> -static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask)
> +static inline void mapping_setup(struct address_space *m,
> + gfp_t mask, int order)
>  {
>   m->flags = (m->flags & ~(__force unsigned long)__GFP_BITS_MASK) |
>   (__force unsigned long)mask;
> +
> +#ifdef CONFIG_LARGE_BLOCKSIZE
> + m->order = order;
> + m->shift = order + PAGE_SHIFT;
> + m->offset_mask = (PAGE_SIZE << order) - 1;
> + if (order) {
> + /*
> +  * Bouncing is not supported. Requests for DMA
> +  * memory will not work
> +  */
> + BUG_ON(m->flags & (__GFP_DMA|__GFP_DMA32));
> + /*
> +  * Bouncing not supported. We cannot use HIGHMEM
> +  */
> + m->flags &= ~__GFP_HIGHMEM;
> + m->flags |= __GFP_COMP;
> + raise_kswapd_order(order);
> + }
> +#endif
>  }
>  
>  /*
> @@ -62,6 +82,78 @@ static inline void mapping_set_gfp_mask(
>  #define PAGE_CACHE_ALIGN(addr)   
> (((addr)+PAGE_CACHE_SIZE-1)_CACHE_MASK)
>  
>  /*
> + * The next set of functions allow to write code that is capable of dealing
> + * with multiple page sizes.
> + */
> +#ifdef CONFIG_LARGE_BLOCKSIZE
> +/*
> + * Determine page order from the blkbits in the inode structure
> + */
> +static inline int page_cache_blkbits_to_order(int shift)
> +{
> + BUG_ON(shift < 9);
> +
> + if (shift < PAGE_SHIFT)
> + return 0;
> +
> + return shift - PAGE_SHIFT;
> +}
> +
> +/*
> + * Determine page order from a given blocksize
> + */
> +static inline int page_cache_blocksize_to_order(unsigned long size)
> +{
> + return page_cache_blkbits_to_order(ilog2(size));
> +}
> +
> +static inline int mapping_order(struct address_space *a)
> +{
> + return a->order;
> +}
> +
> +static inline int page_cache_shift(struct address_space *a)
> +{
> + return a->shift;
> +}
> +
> +static inline unsigned int page_cache_size(struct address_space *a)
> +{
> + return a->offset_mask + 1;
> +}
> +
> +static inline loff_t page_cache_mask(struct address_space *a)
> +{
> + return ~a->offset_mask;
> +}
> +
> 

Re: [PATCH] blink: Only blink when parameter is set

[Pavel Machek]

Hi!

> > * It breaks keyboards. Yes, we are talking about maybe-broken i8042s, 
> >   but it still breaks thinkpads at least.
> 
> Hi Pavel,
> 
> this has probably been already solved by proper throttling - see 
> http://lkml.org/lkml/2007/6/15/22

No, it was not. I still saw the problems with CONFIG_BLINK on, that is
one blink per 5 seconds or something.

We should rename CONFIG_BLINK to
CONFIG_BREAK_THINKPAD_KEYBOARD_AND_MORE.

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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Michael Poole]

David Schwartz writes:

>> Most of this list has
>> already dismissed your rather unique -- I would even say frivolous --
>> idea of how far "mere aggregation" goes: I, for one, have better
>> things to do than explain why a C file is not a "mere aggregation" of
>> the functions it contains.)
>>
>> Michael Poole
>
> Of course it's not mere aggregation. The functions in a C file are
> creatively combined. How many times do I have to say that the opposite of
> "mere aggregation" is creative combination?
>
> It is not unique, it is part of the definition of a "derivative work".

By "creative combination" do you mean what US copyright law refers to
as compilations (or their subset collective works)?

Compilations can be creative combinations while still being mere
aggregation under the GPL.  For example, if applications are selected
to run with a Linux kernel, and they are distributed together, the
collection is a creative selection -- and this seems to be one of the
cases evoked by the GPL's reference to "mere aggregation".  See also
practically every Linux distribution on the planet.

Compilations also can be creative combinations and *more* than mere
aggregation: for example, Linux with respect to its subsystems, or any
case where a larger work is derivative of one of its components.

However, compilations (even to the extent they are creative
combinations) are not necessarily derivative works of their elements.
For more details, see
http://www.copyright.gov/circs/circ14.html#compilations

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

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

[Tomas Neme]

On 6/20/07, Dave Neuer <[EMAIL PROTECTED]> wrote:

On 6/20/07, Tomas Neme <[EMAIL PROTECTED]> wrote:
>
> I'm about this far to Linus'izing my wording and calling you stupid,
> hypocrite, or bullshitter

Knock yourself out, it will no doubt lend much moral and logic weight
to your rhetoric.


I might not have the best rhetoric, but I still hold my point about
the credit card. Ask yourself: are you going to complain about Firefox
(GPL'ed) not passing information unencrypted because it stops
potential users (crackers ARE users) from doing what they want to with
it? What's a security issue and what's not is a matter of legality and
it's each part's duty to enforce legality in every way they can (I'm
not saying that I agree, I'm an anarchist, but it's just how it goes).

The content providers do it by not allowing DVRs to work if they're
not secure, and DVRs are secure by doing whatever is legally possible
to avoid crackers from bypassing security measures. On the other hand
is legal for you to bypass those security measures as long as you
don't make illegal use of those bypasses.

The kernel TiVo distributes works on TiVo boxes, The kernel modified
by you, is no longer the kernel TiVo distributes, and therefore the
key that the original kernel had no longer applies to it. Try running
your TiVo kernel on a PC, I think you won't be able to without a lot
of modification.. and then again, once you do the proper modifying,
you will be able to use it on your multimedia computer, and use all of
the wonderful things you DIE to be able to modify the TiVo kernel
for.. If you modify your TiVo kernel and say make it so it doesn't
have an IDE controller module anymore, you won't be able to run it on
your TiVo either.. at least not in any useful way, and would you be
complaining?

And someone said this already, if the signature is created via a known
algorithm, and only the key isn't provided, saying that that's not
GPLv2 compliant is like saying that I can't publish investigation work
that was produced sharing via a secured network unless I also publish
the SSH key I used through investigation, or the original value of the
srand() if the investigation relied on random number generation,
because the exact same results won't be reproducible.

T

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

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

[Dave Neuer]

On 6/20/07, David Schwartz <[EMAIL PROTECTED]> wrote:


> This argument is the obvious nonsense. "Runs on TiVO" is a property of
> the software that TiVO distributes -- such an important property that
> it would be nonsensical for them to distribute it with their hardware.
> But they do distribute it, and only the GPL allows them to.

Why does the importance of the property matter to the validity of the
argument?



From a legal standpoint, perhaps you're right, it doesn't matter what

the function is. From a moral standpoint it should be obvious to you
that "runs on TiVO" is TiVO's sole motivation to distribute the
software at all, it is "the software" and arguing that they have an
equivalent obligation WRT it as to some incidental thing like Linus'
signing key is just preposterous.


> > Tivo's choice is an authorization decision. It is similar to
> > you not having
> > root access to a Linux box. Sorry, you can't run a modified
> > kernel on that
> > machine, but you can still modify the kernel and run it on any hardware
> > where authorization decisions don't stop you from doing so. The GPL was
> > never about such authorization decisions.

> Says judge Schwartz. Oops. That's right, you're not a judge in any
> legal jurisdiction, nor an author of the GPL.

Nice argument. I'm wrong because people can disagree with me.


No, in this case you are wrong because absent authority to decide the
meaning from a dispositive legal standpoint (the law says the license
means this) or knowledge of the intent of the author of the GPL (I the
author intended it to mean this), your statement that the GPL was
"never about" "such decisions" is meaningless, AFAICT.



DS


Dave
-
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] bonding: Fix use after free in unregister path

[Chris Wright]

* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Jay Vosburgh wrote:
> > The following patch (based on a patch from Stephen Hemminger
> ><[EMAIL PROTECTED]>) removes use after free conditions in
> >the unregister path for the bonding master.  Without this patch, an
> >operation of the form "echo -bond0 > /sys/class/net/bonding_masters"
> >would trigger a NULL pointer dereference in sysfs.  I was not able to
> >induce the failure with the non-sysfs code path, but for consistency I
> >updated that code as well.
> >
> > I also did some testing of the bonding /proc file being open
> >while the bond is being deleted, and didn't see any problems there.
> >
> >Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
> 
> applied to #upstream-fixes

This was originally discovered on 2.6.21.5 IIRC, so plan to send this
to -stable as well?

thanks,
-chris
-
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/

[git patches] libata fixes

[Jeff Garzik]

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git 
upstream-linus

to receive the following updates:

 drivers/ata/ahci.c|2 +-
 drivers/ata/libata-core.c |4 +++-
 drivers/ata/pata_amd.c|2 ++
 drivers/ata/pata_it821x.c |   13 -
 4 files changed, 10 insertions(+), 11 deletions(-)

Bartlomiej Zolnierkiewicz (1):
  pata_it821x: (partially) fix DMA in RAID mode

Henrik Kretzschmar (1):
  kerneldoc fix in libata

Peer Chen (1):
  PATA: Add the MCP73/77 support to PATA driver

Stas Sergeev (1):
  fix module_param mistake in it821x

Tejun Heo (2):
  libata: more NONCQ devices
  ahci: fix PORTS_IMPL override

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 545f330..ca5229d 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -527,7 +527,7 @@ static void ahci_save_initial_config(struct pci_dev *pdev,
 
/* fixup zero port_map */
if (!port_map) {
-   port_map = (1 << ahci_nr_ports(hpriv->cap)) - 1;
+   port_map = (1 << ahci_nr_ports(cap)) - 1;
dev_printk(KERN_WARNING, >dev,
   "PORTS_IMPL is zero, forcing 0x%x\n", port_map);
 
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 047eabd..adfae9d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3659,7 +3659,7 @@ static int ata_dev_same_device(struct ata_device *dev, 
unsigned int new_class,
 
 /**
  * ata_dev_reread_id - Re-read IDENTIFY data
- * @adev: target ATA device
+ * @dev: target ATA device
  * @readid_flags: read ID flags
  *
  * Re-read IDENTIFY page and make sure @dev is still attached to
@@ -3802,6 +3802,8 @@ static const struct ata_blacklist_entry 
ata_device_blacklist [] = {
{ "HTS541010G9SA00","MBZOC60D", ATA_HORKAGE_NONCQ, },
/* Drives which do spurious command completion */
{ "HTS541680J9SA00","SB2IC7EP", ATA_HORKAGE_NONCQ, },
+   { "HTS541612J9SA00","SBDIC7JP", ATA_HORKAGE_NONCQ, },
+   { "WDC WD740ADFD-00NLR1", NULL, ATA_HORKAGE_NONCQ, },
 
/* Devices with NCQ limits */
 
diff --git a/drivers/ata/pata_amd.c b/drivers/ata/pata_amd.c
index b439351..a16f629 100644
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -693,6 +693,8 @@ static const struct pci_device_id amd[] = {
{ PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE), 8 },
{ PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_IDE), 8 },
{ PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP67_IDE), 8 },
+   { PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP73_IDE), 8 },
+   { PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP77_IDE), 8 },
{ PCI_VDEVICE(AMD,  PCI_DEVICE_ID_AMD_CS5536_IDE),  9 },
 
{ },
diff --git a/drivers/ata/pata_it821x.c b/drivers/ata/pata_it821x.c
index b3456d7..dab4e7c 100644
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -2,6 +2,7 @@
  * pata_it821x.c   - IT821x PATA for new ATA layer
  *   (C) 2005 Red Hat Inc
  *   Alan Cox <[EMAIL PROTECTED]>
+ *   (C) 2007 Bartlomiej Zolnierkiewicz
  *
  * based upon
  *
@@ -79,7 +80,7 @@
 
 
 #define DRV_NAME "pata_it821x"
-#define DRV_VERSION "0.3.6"
+#define DRV_VERSION "0.3.7"
 
 struct it821x_dev
 {
@@ -460,14 +461,8 @@ static unsigned int it821x_passthru_qc_issue_prot(struct 
ata_queued_cmd *qc)
 
 static int it821x_smart_set_mode(struct ata_port *ap, struct ata_device 
**unused)
 {
-   int dma_enabled = 0;
int i;
 
-   /* Bits 5 and 6 indicate if DMA is active on master/slave */
-   /* It is possible that BMDMA isn't allocated */
-   if (ap->ioaddr.bmdma_addr)
-   dma_enabled = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
-
for (i = 0; i < ATA_MAX_DEVICES; i++) {
struct ata_device *dev = >device[i];
if (ata_dev_enabled(dev)) {
@@ -476,7 +471,7 @@ static int it821x_smart_set_mode(struct ata_port *ap, 
struct ata_device **unused
dev->dma_mode = XFER_MW_DMA_0;
/* We do need the right mode information for DMA or PIO
   and this comes from the current configuration flags 
*/
-   if (dma_enabled & (1 << (5 + i))) {
+   if (ata_id_has_dma(dev->id)) {
ata_dev_printk(dev, KERN_INFO, "configured for 
DMA\n");
dev->xfer_mode = XFER_MW_DMA_0;
dev->xfer_shift = ATA_SHIFT_MWDMA;
@@ -799,7 +794,7 @@ MODULE_VERSION(DRV_VERSION);
 
 
 module_param_named(noraid, it8212_noraid, int, S_IRUGO);
-MODULE_PARM_DESC(it8212_noraid, "Force card into bypass mode");
+MODULE_PARM_DESC(noraid, "Force card into bypass mode");
 
 module_init(it821x_init);
 

Re: [PATCH] kerneldoc fix in libata

[Jeff Garzik]

Henne wrote:

From: Henrik Kretzschmar <[EMAIL PROTECTED]>

Fix parameter name from ata_dev_reread_id() in libata-core.c for kerneldoc.

Signed-off-by: Henrik Kretzschmar <[EMAIL PROTECTED]>

---

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 047eabd..88e2761 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3659,7 +3659,7 @@ static int ata_dev_same_device(struct at
 
 /**

  * ata_dev_reread_id - Re-read IDENTIFY data
- * @adev: target ATA device
+ * @dev: target ATA device
  * @readid_flags: read ID flags


applied


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

Re: [patch] fix module_param mistake in it821x

[Jeff Garzik]

Stas Sergeev wrote:

Hello.

The attached patch fixes a trivial
mistake in a MODULE_PARAM_DESC of pata_it821x
driver. The parameter name in MODULE_PARAM_DESC
should match the one in module_param_named.

Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>




--- a/drivers/ata/pata_it821x.c 2007-04-27 12:46:35.0 +0400
+++ b/drivers/ata/pata_it821x.c 2007-06-20 18:16:20.0 +0400
@@ -828,7 +828,7 @@
 
 
 module_param_named(noraid, it8212_noraid, int, S_IRUGO);

-MODULE_PARM_DESC(it8212_noraid, "Force card into bypass mode");
+MODULE_PARM_DESC(noraid, "Force card into bypass mode");


applied


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

Re: [PATCH] pata_it821x: (partially) fix DMA in RAID mode

[Jeff Garzik]

Bartlomiej Zolnierkiewicz wrote:

Code intended to check DMA status was checking DMA command register.

Moreover firmware seems to "forget" to set DMA capable bit for the
slave device (at least in RAID mode but without ITE RAID volumes) so
check device ID for DMA capable bit when deciding whether to use DMA
and remove DMA status check completely.

Thanks to Pavol Simo for the bugreport and testing the initial fix.

This change unfortunately still doesn't fix DMA in RAID mode (which
works fine with IDE it821x) but Alan is working on the missing pieces
(pata_it821x vs libata EH issues).

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
Cc: Tejun Heo <[EMAIL PROTECTED]>
---
removed non-ASCII char from the patch description + added Alan's ACK

 drivers/ata/pata_it821x.c |   11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)


applied


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

Re: [PATCH 1/3] PATA: Add the MCP73/77 support to PATA driver

[Jeff Garzik]

Peer Chen wrote:

Add the MCP73/MCP77 support to PATA driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>


applied


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

Re: [PATCH] blink: Only blink when parameter is set

[Jiri Kosina]

On Wed, 20 Jun 2007, Pavel Machek wrote:

> * It breaks keyboards. Yes, we are talking about maybe-broken i8042s, 
>   but it still breaks thinkpads at least.

Hi Pavel,

this has probably been already solved by proper throttling - see 
http://lkml.org/lkml/2007/6/15/22

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

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

[Dave Neuer]

On 6/20/07, Tomas Neme <[EMAIL PROTECTED]> wrote:


I'm about this far to Linus'izing my wording and calling you stupid,
hypocrite, or bullshitter


Knock yourself out, it will no doubt lend much moral and logic weight
to your rhetoric.

Dave
-
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: [1/2] 2.6.22-rc5: known regressions with patches

[Linus Torvalds]

On Wed, 20 Jun 2007, Arjan van de Ven wrote:
> 
> the real fix would be something like this instead:

If people can test this, and confirm it works, please send a patch that 
not only does this ad undoes the Kconfig language.  It looks like the 
right thing to do, but I won't touch it without somebody who actually 
tested these combinarions sending in a patch.

Hmm?

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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[David Schwartz]

> Most of this list has
> already dismissed your rather unique -- I would even say frivolous --
> idea of how far "mere aggregation" goes: I, for one, have better
> things to do than explain why a C file is not a "mere aggregation" of
> the functions it contains.)
>
> Michael Poole

Of course it's not mere aggregation. The functions in a C file are
creatively combined. How many times do I have to say that the opposite of
"mere aggregation" is creative combination?

It is not unique, it is part of the definition of a "derivative work".

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: [1/2] 2.6.22-rc5: known regressions with patches

[Linus Torvalds]

On Wed, 20 Jun 2007, Dave Jones wrote:
> 
> Surely the fundamental disagreement is only due to DEBUG_RODATA
> covering write-protection of both .text, and .rodata  ?

I agree that we could well split DEBUG_RODATA into something more 
fine-grained, and for example have it _only_ protect that .rodata thing 
when Kprobes are enabled, and both .text _and_ .rodata when Kprobes are 
not.

That would make lots of sense.

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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[David Schwartz]

> This argument is the obvious nonsense. "Runs on TiVO" is a property of
> the software that TiVO distributes -- such an important property that
> it would be nonsensical for them to distribute it with their hardware.
> But they do distribute it, and only the GPL allows them to.

Why does the importance of the property matter to the validity of the
argument?

> Linus' key is not required to use the software Linus distributes under
> the GPL, by contrast.

Why does whether or not the key is required to use the software matter? It
may be impossible to use a Linux kernel on a particular piece of hardware
without the BIOS, that doesn't mean the BIOS source code is part of the
kernel source code even if the kernel is shipped for that hardware.

> > Tivo's choice is an authorization decision. It is similar to
> > you not having
> > root access to a Linux box. Sorry, you can't run a modified
> > kernel on that
> > machine, but you can still modify the kernel and run it on any hardware
> > where authorization decisions don't stop you from doing so. The GPL was
> > never about such authorization decisions.

> Says judge Schwartz. Oops. That's right, you're not a judge in any
> legal jurisdiction, nor an author of the GPL.

Nice argument. I'm wrong because people can disagree with me.

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/

[git patches] net driver fixes

[Jeff Garzik]

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
upstream-linus

to receive the following updates:

 drivers/net/bonding/bond_3ad.c   |9 +--
 drivers/net/bonding/bond_main.c  |2 +-
 drivers/net/bonding/bond_sysfs.c |2 +-
 drivers/net/bonding/bonding.h|4 +-
 drivers/net/cxgb3/ael1002.c  |   10 +++-
 drivers/net/cxgb3/cxgb3_main.c   |   16 -
 drivers/net/cxgb3/regs.h |6 ++
 drivers/net/cxgb3/sge.c  |3 +-
 drivers/net/cxgb3/xgmac.c|   98 +++
 drivers/net/forcedeth.c  |4 +-
 drivers/net/natsemi.c|2 +-
 drivers/net/spider_net.c |  121 +++---
 drivers/net/spider_net.h |8 ++-
 drivers/net/spider_net_ethtool.c |   21 +--
 drivers/s390/net/claw.c  |   13 +++--
 drivers/s390/net/netiucv.c   |   23 ++-
 drivers/s390/net/qeth_eddp.c |3 +-
 drivers/s390/net/qeth_main.c |   52 -
 18 files changed, 273 insertions(+), 124 deletions(-)

Cornelia Huck (1):
  s390: Use ccw_device_get_id() in qeth/claw drivers

Divy Le Ray (5):
  cxgb3 - fix skb->dev dereference
  cxgb3 - fix netpoll hanlder
  cxgb3 - Fix direct XAUI support
  cxgb3 - Stop mac RX when changing MTU
  cxgb3 - MAC watchdog update

Frank Pavlic (1):
  s390: qeth: wrong packet length in qdio header

Gregory Haskins (1):
  natsemi irq flags

Jay Vosburgh (2):
  bonding: Fix use after free in unregister path
  bonding: Fix 802.3ad no carrier on "no partner found" instance

Linas Vepstas (5):
  spidernet: null out skb pointer after its been used.
  spidernet: Cure RX ram full bug
  spidernet: Don't terminate the RX ring
  spidernet: silence the ramfull messages
  spidernet: turn off descriptor chain end interrupt.

Martin Schwidefsky (1):
  s390: netiucv inlining cleanup

Stephen Hemminger (1):
  spidernet: checksum and ethtool

Thomas Gleixner (1):
  s390: netiucv spinlock initializer cleanup

Tim Mann (1):
  forcedeth: use unicast receive mode for WoL

Ursula Braun (4):
  s390: print correct level for HiperSockets devices
  s390: qeth driver does not recover
  s390: avoid inconsistent lock state in qeth
  s390: don't call iucv_path_connect from tasklet context

diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 7e03f41..f829e4a 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -2303,19 +2303,18 @@ void bond_3ad_handle_link_change(struct slave *slave, 
char link)
 }
 
 /*
- * set link state for bonding master: if we have an active partnered
+ * set link state for bonding master: if we have an active 
  * aggregator, we're up, if not, we're down.  Presumes that we cannot
  * have an active aggregator if there are no slaves with link up.
  *
+ * This behavior complies with IEEE 802.3 section 43.3.9.
+ *
  * Called by bond_set_carrier(). Return zero if carrier state does not
  * change, nonzero if it does.
  */
 int bond_3ad_set_carrier(struct bonding *bond)
 {
-   struct aggregator *agg;
-
-   agg = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
-   if (agg && MAC_ADDRESS_COMPARE(>partner_system, _mac_addr)) {
+   if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
if (!netif_carrier_ok(bond->dev)) {
netif_carrier_on(bond->dev);
return 1;
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 223517d..6287ffb 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4345,8 +4345,8 @@ static void bond_free_all(void)
bond_mc_list_destroy(bond);
/* Release the bonded slaves */
bond_release_all(bond_dev);
-   unregister_netdevice(bond_dev);
bond_deinit(bond_dev);
+   unregister_netdevice(bond_dev);
}
 
 #ifdef CONFIG_PROC_FS
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index a122baa..60cccf2 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -164,9 +164,9 @@ static ssize_t bonding_store_bonds(struct class *cls, const 
char *buffer, size_t
printk(KERN_INFO DRV_NAME
": %s is being deleted...\n",
bond->dev->name);
-   unregister_netdevice(bond->dev);
bond_deinit(bond->dev);
bond_destroy_sysfs_entry(bond);
+   unregister_netdevice(bond->dev);
rtnl_unlock();
goto out;
}
diff --git 

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

[Michael Poole]

David Schwartz writes:

>> I do not say that the BIOS is doing anything (legally) wrong.  The
>> wrong act is distributing the binary kernel image without distributing
>> complete source code for it.
>
> Why are you not complaining that Linus does not distribute the keys he uses
> to sign kernel source distributions? If a digital signature is part of the
> distribution, why is the key used to produce that signature not part of the
> distribution?
>
> If you can cite some legal reason there is a difference, I would be quite
> impressed.
>
> In any event, the argument is obvious nonsense. The signature is merely
> aggregated with the kernel. Cooperation, dependent function, and convergent
> design can't break mere aggregation or you get ridiculous results. (For
> example, a device shipped with the Linux kernel and some applications would
> have to GPL all the applications.)

Do you make it a habit to pose ranty questions to people while neither
attributing their text nor cc'ing them?  Especially when you claim the
person's argument is "obvious nonsense", it seems quite rude.

(Since you have dismissed my argument as nonsense before hearing my
response, I will not bother answering your question.  Since you are
acting like a troll, I will dismiss you as one.  Most of this list has
already dismissed your rather unique -- I would even say frivolous --
idea of how far "mere aggregation" goes: I, for one, have better
things to do than explain why a C file is not a "mere aggregation" of
the functions it contains.)

Michael Poole
-
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: [1/2] 2.6.22-rc5: known regressions with patches

[Dave Jones]

On Wed, Jun 20, 2007 at 04:15:53PM -0700, Arjan van de Ven wrote:
 > On Wed, 2007-06-20 at 19:07 -0400, Dave Jones wrote:
 > > On Wed, Jun 20, 2007 at 03:38:06PM -0700, Linus Torvalds wrote:
 > > 
 > >  > And yes, that patch already got merged. However, the patch to *allow* 
 > >  > Kprobes with DEBUG_RODATA is not, and will not be. It's not a 
 > > regression, 
 > >  > and quite frankly, I don't think I would even want that patch.
 > >  > 
 > >  > Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in 
 > >  > "working around it". Better just admit it.
 > > 
 > > Surely the fundamental disagreement is only due to DEBUG_RODATA
 > > covering write-protection of both .text, and .rodata  ?
 > > I can see value in having a kernel that supports kprobes, whilst
 > > at the same point, raising red flags if something writes into
 > > a const string. With my distro kernel maintainer hat on, I always
 > > hate these 'pick one' decisions, because I always get convincing
 > > arguments from proponents of both sides.
 > > 
 > > Was it always this way?  I thought DEBUG_RODATA initially just
 > > covered, well.. rodata.And kprobes only wants to change .text
 > > doesn't it ?
 > 
 > no this got "fixed" recently. It used to only cover data.
 > Andi merged a patch to make it cover text too.. imo we should reverse
 > that, or make the check better and not have it cover text if kprobes is
 > active. I can do the later if people are ok with that, it's
 > approximately 3 lines of code.

Having the text as a separate option makes sense to me.
(Or at the least we should rename DEBUG_RODATA, as it's now misleading).

Dave

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

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

[Dave Neuer]

On 6/20/07, David Schwartz <[EMAIL PROTECTED]> wrote:


> Tomas Neme writes:

> > I have been following this discussion for the last week or so, and
> > what I haven't been able to figure out is what the hell is the big
> > deal with TiVO doing whatever they want to with their stupid design.
> > They made a design, they build a machine, they sell it as is, and
> > provide source code for GPL'ed software... what's your problem?

> It's simple: they don't provide _complete_ source code.  They keep the
> source code for the part of their Linux kernel images that provides
> the functionality "runs on Tivo DVRs".  The GPL requires that
> distributors of binary versions provide complete source code, not just
> the parts of source code that are convenient.
>
> Michael Poole

That leads to lots of obvious nonsense unless you fix it with all kinds of
made up ad-hoc changes just to get the result you want. Why doesn't Linus
have to release the keys he uses to sign the Linux kernel source
distributions? That provides the functionality "can be proven to be
authorized by Linus". What you call "runs on Tivo DVRs", I call "can be
proven to be authorized by Tivo to run on Tivo DVRs".


This argument is the obvious nonsense. "Runs on TiVO" is a property of
the software that TiVO distributes -- such an important property that
it would be nonsensical for them to distribute it with their hardware.
But they do distribute it, and only the GPL allows them to.

Linus' key is not required to use the software Linus distributes under
the GPL, by contrast.



Tivo's choice is an authorization decision. It is similar to you not having
root access to a Linux box. Sorry, you can't run a modified kernel on that
machine, but you can still modify the kernel and run it on any hardware
where authorization decisions don't stop you from doing so. The GPL was
never about such authorization decisions.


Says judge Schwartz. Oops. That's right, you're not a judge in any
legal jurisdiction, nor an author of the GPL.

Dave
-
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: [1/2] 2.6.22-rc5: known regressions with patches

[Arjan van de Ven]

> Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in 
> "working around it". Better just admit it.

that's wrong. KPROBE fundamentally disagrees with TEXT being read only,
which is a 2.6.22 new "feature".. and a buggy one at that.


the real fix would be something like this instead:

--- linux-2.6.22-rc5/arch/x86_64/mm/init.c.org  2007-06-21 04:20:10.0 
-0700
+++ linux-2.6.22-rc5/arch/x86_64/mm/init.c  2007-06-21 04:21:01.0 
-0700
@@ -605,6 +605,11 @@ void mark_rodata_ro(void)
if (num_possible_cpus() > 1)
start = (unsigned long)_etext;
 #endif
+
+#ifdef CONFIG_KPROBES
+   start = (unsigned long)_etext;
+#endif
+   
end = (unsigned long)__end_rodata;
start = (start + PAGE_SIZE - 1) & PAGE_MASK;
end &= PAGE_MASK;


-
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: SMP read() stopping at memory page boundaries

[Jiri Kosina]

On Wed, 20 Jun 2007, Timo Sirainen wrote:

> > It will occur if you are reading as someone else changes the file size.
> > Use file locking, it exists for a reason ;)
> Annoying extra overhead. Especially with NFS, when nowadays you can't
> even use flock() to create local locks..

It's not only "nowadays", it has been like that for quite a some time.

On the other hand you can use fcntl(F_SETLK) though, which works even 
through NFS (v3).

-- 
Jiri Kosina
-
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: [1/2] 2.6.22-rc5: known regressions with patches

[Arjan van de Ven]

On Wed, 2007-06-20 at 19:07 -0400, Dave Jones wrote:
> On Wed, Jun 20, 2007 at 03:38:06PM -0700, Linus Torvalds wrote:
> 
>  > And yes, that patch already got merged. However, the patch to *allow* 
>  > Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, 
>  > and quite frankly, I don't think I would even want that patch.
>  > 
>  > Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in 
>  > "working around it". Better just admit it.
> 
> Surely the fundamental disagreement is only due to DEBUG_RODATA
> covering write-protection of both .text, and .rodata  ?
> I can see value in having a kernel that supports kprobes, whilst
> at the same point, raising red flags if something writes into
> a const string. With my distro kernel maintainer hat on, I always
> hate these 'pick one' decisions, because I always get convincing
> arguments from proponents of both sides.
> 
> Was it always this way?  I thought DEBUG_RODATA initially just
> covered, well.. rodata.And kprobes only wants to change .text
> doesn't it ?

no this got "fixed" recently. It used to only cover data.
Andi merged a patch to make it cover text too.. imo we should reverse
that, or make the check better and not have it cover text if kprobes is
active. I can do the later if people are ok with that, it's
approximately 3 lines of 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: [PATCH 1/5] cxgb3 - fix skb->dev dereference

[Jeff Garzik]

[EMAIL PROTECTED] wrote:

From: Divy Le Ray <[EMAIL PROTECTED]>

eth_type_trans() now sets skb->dev. 
References to skb->dev should happen after it is called.


Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/sge.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


applied 1-5 to #upstream-fixes (2.6.22)


-
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] natsemi irq flags

[Jeff Garzik]

Gregory Haskins wrote:

The spinlock irq flags should be a unsigned long to properly support 64 bit

Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>

---

 drivers/net/natsemi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


applied to #upstream-fixes


-
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] bonding: Fix use after free in unregister path

[Jeff Garzik]

Jay Vosburgh wrote:

The following patch (based on a patch from Stephen Hemminger
<[EMAIL PROTECTED]>) removes use after free conditions in
the unregister path for the bonding master.  Without this patch, an
operation of the form "echo -bond0 > /sys/class/net/bonding_masters"
would trigger a NULL pointer dereference in sysfs.  I was not able to
induce the failure with the non-sysfs code path, but for consistency I
updated that code as well.

I also did some testing of the bonding /proc file being open
while the bond is being deleted, and didn't see any problems there.

Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>


applied to #upstream-fixes


-
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: oops with USB serial irda adapter

[Alan Cox]

On Wed, 20 Jun 2007 18:16:47 -0400
Chuck Ebbert <[EMAIL PROTECTED]> wrote:

> [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241598]
> 
> Oops happens here in kernel 2.6.20.11:
> drivers/usb/serial/ir-usb.c, line 557:
> 
> /* Notify the tty driver that the termios have changed. */
> port->tty->ldisc.set_termios(port->tty, NULL);
> 
> (ldisc.set_termios is NULL)

Yeah the driver is full of bugs - its also broken for the way its
set_termios tries to play 'guess it the properties have changed' and gets
speed checks wrong, how it snoops the baud bits and some other stuff it
does.

If you make it look like a real serial driver it ought to work fine. If
you've got hardware I can send you test patches ?
-
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: Adding subroot information to /proc/mounts, or obtaining that through other means

[Dr. David Alan Gilbert]

* Karel Zak ([EMAIL PROTECTED]) wrote:
> On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
> > 



> > ... or, alternatively, add a subfield to the first field (which would
> > entail escaping whatever separator we choose):
> > 
> > /dev/md6 /export ext3 rw,data=ordered 0 0
> > /dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0
> > /dev/md6:/users/bar /home/bar ext3 rw,data=ordered 0 0
> 
>  We needn't a new separator (':') there already is one (' ').

What happens with the (sick) case of spaces in directory names?
Also is it really nicely defined that there is no way to put a space
in an option in any of the filesystems?   I suppose someone
particularly sick could have a device node in a directory with a space
in it.  It would be nice if new formats for this are being defined
to make it cover everything.

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.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/