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

[Scott Preece]

On 6/15/07, Tim Post <[EMAIL PROTECTED]> wrote:

On Fri, 2007-06-15 at 19:52 -0500, Scott Preece wrote:

>
> Yes, but in highlighting the possibility of evil intentions you
> distort the fact that usually there are no such evil intentions...
>

I don't think you can use "usually" and "fact" together like that. Why
is it so bad to account for them since they (do) surface and (could)
increase significantly in frequency?

---

I agree that it is possible to have different definitions of "evil"
and "ethical"...

scott
-
To unsubscribe from this list: send the line "unsubscribe 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

[Scott Preece]

On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

On Jun 15, 2007, "Scott Preece" <[EMAIL PROTECTED]> wrote:




> Whether it's a legal requirement or a business decision, the result is
> the same - neither forcing the manufacturer to make the device
> non-updatable nor forcing the manufacturer to use different software
> benefits anyone.

I agree.  But that's an incomplete picture.

It's the other part of the picture, that you left out twice, that is
the case that is good for the users *and* for the community.

---

I don't think I "left it out". The point is that if the manufacturer
is unwilling to give the right to modify, no change in the language is
going to cause the user to have that right.

scott
-
To unsubscribe from this list: send the line "unsubscribe 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 Gerdau]

> On Friday 15 June 2007 18:59:14 Linus Torvalds wrote:
> > So it's true: the GPL just gives you rights, and without it you have no
> > rights (other than fair use ones etc), and blah blah. But the distinction
> > between "license" vs "contract" really isn't a very important one in any
> > case.
> 
> Er, copyright law is federal, contract law is generally state level?  So not 
> only does contract law vary a lot more by jurisdiction, but it's enforced by 
> different courts than suits over copyright?  (You'll notice the GPL doesn't 
> say which state law holds sway.  If it was a contract this would be kind of 
> important.)

That seems to be a special property of the US legal system. At least I'm
not aware of this or a similar distinction in e.g. germany (or most parts
of europe AFAIK).

Best,
Michael
-- 
 Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar
 Sitz Hamburg; HRB 89145 Amtsgericht Hamburg
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau   email: [EMAIL PROTECTED]
 GPG-keys available on request or at public keyserver


signature.asc
Description: This is a digitally signed message part.

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

[Scott Preece]

On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

On Jun 15, 2007, "Scott Preece" <[EMAIL PROTECTED]> wrote:

> On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> > * Daniel Hazelton <[EMAIL PROTECTED]> wrote:
>>
>> That's correct, but with a catch: since the contract or license is
>> chosen by the licensor, in case of ambiguity in the terms, many courts
>> will interpret it in a way that privileges the licensee, regardless of
>> the fact that copyright licenses are to be interpreted restrictively
>> (at least in Brazilian law).  And IANAL ;-)
> ---

> Hmm. In such a suit, however, the user would not be "the licensee" and
> would not be a party to the suit - some author would be the plaintiff
> and would be suing someone for doing something in violation of the
> license that author granted - that is, the *defendant* would be the
> licensee who would get the benefit of the doubt...

Yes.  And so justice is made.  Licensor gets to pick the license,
licensee gets the benefit of the doubt.  What's the 'however' about?
Was this not obvious?

---

Sorry - I thought you were saying ambiguity would be resolved in favor
of the user. If you meant in favor of the licensee (regardless of that
limiting the user's rights), then I agree.

scott
-
To unsubscribe from this list: send the line "unsubscribe 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: Help needed: Partitioned software raid > 2TB

[Alexander E. Patrakov]

Jan Engelhardt wrote:

On Jun 15 2007 16:03, Christian Schmidt wrote:



Thanks for the clarification. I didn't use LVM on the device on purpose,
as root on LVM requires initrd (which I strongly dislike as
yet-another-point-of-failure). As LVM is on the large partition anyway
I'll just add the second partition for now, and change the system setup
with the next drive migration. Maybe linux even supports root-on-lvm
natively until then ;)


Uh, it does. By means of initrd/ramfs image. Blame your distro if it still
can't do root-on-LVM, there is at least one who can.


AFAIK, root-on-LVM on the whole disk (BTW, I use such setup myself) requires 
LILO, doesn't it? Could you please list a few distributions with an easy 
method to install LILO (and, of course, root and /boot on LVM on whole disk) 
from their default installation media? So far, I only know that Debian can 
do it if you run debootstrap by hand, although they say that such setup is a 
bug (http://bugs.debian.org/401393).


--
Alexander E. Patrakov
-
To unsubscribe from this list: send the line "unsubscribe 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

[Rob Landley]

On Friday 15 June 2007 21:29:22 Linus Torvalds wrote:
> On Fri, 15 Jun 2007, Rob Landley wrote:
> > Technically what they're holding back is _trademark_ rights, which are a
> > different area of IP law and not addressed by the GPL.  (I know you know
> > this, but just for the record...)
>
> No, technically Red Hat really *does* have copyrights of their own.

They do have copyrights.  They license them under the GPL, and afterwards they 
still have them.

> Red Hat owns the "compilation copyright" on their distribution. That
> means, for example, that even if they have _only_ open source programs on
> their DVD image, you still are not necessarily able (without their
> permission) to set up a "cheap-cd's" kind of operation, and sell their
> CD-ROM/DVD images for a lower price.

I agree that they have this right, but that wasn't the rationale they gave in 
the cease and desist letters they sent out in 2001.  Those said it was ok to 
redistribute, but you can't use their trademarks to promote it when you did 
so:
http://www.newsforge.com/article.pl?sid=01/12/10/2014239=thread

[Rummages around for their current policy statement...]

The restriction is embodied in their "trademark guidelines and policies":
http://www.redhat.com/about/companyprofile/trademark/

If you open the PDF:
http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf

Page one, the right hand side talks about copyright, second paragraph:

> At the same time, the combined body of work that consitutes Red Hat (R)
> Enterprise Linux (R) is a collective work which has been organized by Red
> hat, and Red hat holds the copyright in that collective work.  Red hat then
> permits others to copy, modify and redistribute the collective work.  To
> grant this permission Red hat usually uses the GNU General Public License
> ("GPL") version 2 and Red Hat's own End User License Agreement.  Although
> software licensed under the GPL is "open source software," Red Hat retains
> ownership of the copyright in its collective work.  If someone violates the
> GPL regarding that collective work, only Red Hat, as the copyright owner and
> licensor of that collective work, has legal authority to enforce the GPL
> against the violator.  Although Red hat "owns" the collective work, in
> licenseing it under the GPL, Red Hat grants broad rights in the collective
> work to others.  Neither the GPL nor Red Hat's End User License Agreement
> grant any right to use Red hat's trademarks in the redistribution of the
> collective work.

That seems to say that their compilation copyright is also licensed under the 
GPL, and what they're not giving permission to use is the trademark.

> So yes, they do own the Red Hat trademark too, but they fundamentally do
> own copyrights over and beyond those of the individual programs they
> distribute!

I agree they claim compilation copyrights.  But they seem to have licensed 
their compilation copyrights under GPLv2.

If they're including GPLed works in the compilation, this may actually be a 
requirement.  (Lawyers would happily fight over this issue for months: 
asserting a copyright over the aggregation takes the "mere" out of it, don't 
you think?  Is a compilation a derived work of the components that were 
compiled, at least for the purposes of GPLv2?  Can it be "mere aggregation" 
if you're enforcing a copyright on that aggregation?  Does it not then become 
a larger work with GPL components?  I dunno.)

You'll notice that back under Bob Young, Red Hat carefully didn't go there, by 
licensing the compilation GPLv2 and segregating incompatibly licensed content 
to a separate CD.  After the IPO, he retired and different management took 
over, and introduced Red Hat Enterprise to eat Sun's market[1], and who knows 
what they're thinking now?  I suspect their lawyers still want the 
GPL-incompatible stuff on a separate CD so they can sleep at night.

(Either that, or they just don't assert a compilation copyright, but why give 
that up if they don't have to?)

> Now, I think it so happens that the RHEL DVD's contains other programs
> than just open source, and that you couldn't legally copy them *anyway*,
> but that's a different issue.

The existence of CentOS seems to argue against this.  They say:

> The vast majority of changes made will be made to comply with the upstream
> vendor's re-distribution policies concerning trademarked names or logos.
> Any other changes made will be spelled out in the Release Notes for the
> individual CentOS product.

I haven't noticed any specific non-GPL packages removed from Centos.  Buried 
down in their FAQ they say they're building the same set of packages as are 
in Red Hat Enterprise AS.

I suspect the reason for a lack of obvious proprietary stuff in the RHEL base 
distro is that Red Hat's lawyers don't want to give up the option to enforce 
the compilation copyright on said base distro, but also don't want to raise 
the spectre of enforcing a copyright on a derived work of GPL code (the 

Re: My kernel hangs again: Help with git please

[Daniel Barkalow]

On Sat, 16 Jun 2007, Carlo Wood wrote:

> I don't understand - any branch that I am on has many tags. I can use
> 'git reset --hard sometag' to change the source tree to that tag (which
> works if I look at the version in the Makefile and pick tags that are
> far apart enough).

That's not actually the right image. There's a graph of commits with a lot 
of splitting and joining lines. Each branch and each tag sits something in 
this web. The difference between branches and tags is that you're expected 
to move branch pointers around, and tags stay mostly in place. There's no 
accounting of commits newer than the current spot in the web for a branch 
belonging to that branch, so if you move a branch back to an older tag (or 
other commit), the spot it's leaving is no longer "on the branch".

So master is a point in the web, and bisect jumps around through the web 
according to some special rules (due to having git-bisect use the good/bad 
marks do determine which commit to try next, and jump there). git-bisect 
doesn't really even care that you started on any single branch. It's just 
operating on the web, and the branch you start on is treated as an 
arbitrary commit that has the problem.

You may find "gitk --all" informative.

> Anyway, I tried this:
> 
> $ git checkout master
> $ git branch
>   bisect
> * master
>   origin
> $ BRANCH=$(git branch | grep "^\*" | sed -e "s/\* //")
> $ echo $BRANCH
> master
> $ git rev-list --max-count=1 $BRANCH
> 5ecd3100e695228ac5e0ce0e325e252c0f11806f
> 
> Is it correct that this last command gives me the 'git id' (if that
> is the correct name for the hash) of the revision that my local
> working copy is at?

Yes.

> Can you tell me what is the latest git id that you see?

I'm seeing de7f928ca460005086a8296be07c217aac4b625d, but I just got the 
latest code, more recently than you probably did.

> Because, if I compile 5ecd3100e695228ac5e0ce0e325e252c0f11806f is
> still hangs at boot :(

It looks like you moved master back to 2.6.22-rc4 (with git reset --hard 
v2.6.22-rc4) at some point.

What you should do now is:

$ git checkout master
$ git merge origin

Which should move master forward through the web to "origin", which is 
(unless you've moved it) what you got from upsteam.

Alternatively:

$ git checkout master
$ git pull

Should fetch the latest stuff and advance master to the fetched version.

-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe 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

[Dmitry Torokhov]

On Friday 15 June 2007 23:51, Alexandre Oliva wrote:
> On Jun 16, 2007, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> 
> > On Friday 15 June 2007 17:08, Alexandre Oliva wrote:
> >> >> If the Program does not specify a version number of this License,
> >> >> you may choose any version ever published by the Free Software
> >> >> Foundation.
> 
> > Distributing a copy of GPL is not a requirement for me as a licensor
> > however I did chose to include a copy of a specific version of a
> > specific license and did not make any other statements that is the
> > license for the work.
>  
> And the copy you chose to include says the above.
> 
> Are you absolutely sure you could terminate the license of a
> distributor that refrains to pass on a patent license it obtained, if
> you included a copy of the GPLv2 without any other indication that
> you're choosing GPLv2 and no other version of the GPL, in spite of the
> above?
> 

You never sure about anything taht involves lawyers ;)

> Would it change anything if you had released the program back when
> GPLv3 wasn't under discussion, and GPLv1 was long forgotten, so most
> people (yourself included) only referred to it as GPL, or GNU GPL?
> 
> >> Then, any redistributor adds a copy of any version of the GPL (because
> >> you didn't specify a version number).  At this point, is the program
> >> licensed by *you* only under this specific license?
> 
> > If they did not make any changes then they have to include the earliest
> > version of GPL that applies.
> 
> Why?  Why does it have to be the earliest?

Earliest is wrong I suppose. What I meant is post permissive. Otherwise it
does not make any sense. And what about if there is a version of GPL that
does not require passing a copy of the license along with the program?

I guess it does not matter because somewhere it would still state
"this program is released under GPL" (as you said there is no version
number) so receient can look up what versions of GPL were ever released.

This is different from attaching a specific license.

> 
> >> even though the license itself 
> >> says otherwise?
> 
> > License does not say otherwise. License says that if there is an
> > _additional_ stipulation my the licensor then some other license
> > (non existing yet license) may be used.
> 
> No, you're referring to the portion you quoted, but I'm referring to
> another portion, that I quoted above.
> 
> > "If the Program specifies a version number of this License which
> > applies to it and "or BSD license", you have the option of following
> > the terms and conditions either of that version or of BSD license"
> 
> > would you still say that BSD is allowed by default by GPL? "GPL v2
> > and later versions" is not different from "GPL v2 or BSD" or
> > "GPLv2 or CDDL".
> 
> Agreed.  But this is not what this is about.  This is about the
> license saying something like:
> 
>   If the program does not specify a license version number, then
>   you're permitted to relicense the program under the BSD license.
> 
> Since the license file itself is not part of the program (if it were,
> a program under the GPL would require the GPL itself to be under the
> GPL, right?), I claim the program does not specify a license version
> number.
> 

Why don't you claim that actually the program is in public domain and
the license file just got there by mistake? Attaching a specific license
(and GPL v2 is a distinctive license, not a bumped up version of other
license) places work under this (and only this) license. In my book
this is different form just saying "the program is under GPL".

I guess we'll have to agree to disagree.

-- 
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: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

[I've added Herbert as former kernel team member in the debian(AFAIK),
 sorry, if i'm wrong and you have no opinion on that, Herbert.]

On Sat, Jun 16, 2007 at 04:55:16AM +0200, Adrian Bunk wrote:
> On Sat, Jun 16, 2007 at 03:32:36AM +0200, Oleg Verych wrote:
> > On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
> > > On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
> > > > 
> > > > 
> > > > On Thu, 14 Jun 2007, Oleg Verych wrote:
> > > > > 
> > > > > I'm seeing this long (198) thread and just have no idea how it has
> > > > > ended (wiki? hand-mailing?).
> > > > 
> > > > I'm hoping it's not "ended".
> > > > 
> > > > IOW, I really don't think we _resolved_ anything, although the work 
> > > > that 
> > > > Adrian started is continuing through the wiki and other people trying 
> > > > to 
> > > > track regressions, and that was obviously something good.
> > > > 
> > > > But I don't think we really know where we want to take this thing in 
> > > > the 
> > > > long run. I think everybody wants a better bug-tracking system, but 
> > > > whether something that makes people satisfied can even be built is 
> > > > open. 
> > > > It sure doesn't seem to exist right now ;)
> > > 
> > > The problem is not the bug tracking system, be it manual tracking in a 
> > > text file or a Wiki or be it in Bugzilla or any other bug tracking 
> > > system.
> > > 
> > > One problem is the lack of experienced developers willing to debug bug 
> > > reports.
> > 
> > *debug*
> > 
> > I hope you saw what subject i've chosen to bring this discussion back.
> > Yes, "tracking", as the first brick for big wall.
> 
> Tracking regressions is not a real problem.
> Especially since it doesn't require much technical knowledge.

I've tried to express different point of view. We have different ones {0}.
Thus, no comments.
 
> > Your arguments about developers and users, you've said already, but i've
> > asked different questions, have i?
> > 
> > Lets look on regular automatic report, like this one:
> > 
> > Message-ID: <[EMAIL PROTECTED]>
> > Xref: news.gmane.org gmane.linux.debian.devel.general:116248
> > Archived-At: 
> >  > 
> > And what we see? Basic packages, like ``dpkg'', ``grub'', ``mc'' are
> > in the list, requesting help. And as you can see for quite some time.
> > And it's *OK*, because distribution is working, development is going on.
> > Sometimes slowly, sometimes with delays.
> 
> I sent weekly regression reports.
> Not automatically generated but manually - but that doesn't matter.
> 
> The problem is that sending reports itself does not fix anything.

...{1}

> > > But what really annoyed me was the missing integration of regression 
> > > tracking into the release process, IOW how _you_ handled the regression 
> > > lists.
> > 
> > So, _tracking_ or _debugging_?
> 
> _debugging_ (can be indirectly by poking other people to do debugging)
> 
> > > If we want to offer something less of a disaster than 2.6.21, and if we 
> > > want to encourage people to start and continue testing -rc kernels, we 
> > > must try to fix as many reported regressions as reasonably possible.
> > 
> > *tracking*
> 
> no, *debugging*
> 
> I tracked regressions for the 2.6.21 disaster, and the not debugged 
> regressions that I had tracked are exactly where we should be better.

...{2}

> >...
> > > This means going through every single point in the regression list 
> > > asking "Have we tried everything possible to solve this regression?". 
> > > There are very mysterious regressions and there are regressions that 
> > > might simply be reported too late. But if at the time of the final 
> > > release 3 week old regressions hadn't been debugged at all there's 
> > > definitely room for improvement. And mere mortals like me reminding 
> > > people is often not enough, sometimes an email by Linus Torvalds himself 
> > > asking a patch author or maintainer to look after a regression might be 
> > > required.
> > 
> > *social* (first approximation)
> 
> Yes.
> 
> > That's a social problem, just like Debian loosing good kernel team members.
> 
> Different social problem.

The term ``like'' here means people are not able/willing to do work, they
might/can do. And cause of it is *social*, not technical. {1},{2} are
results of that problem/behavior. But according to {0}, you think,
differently.

> > For example you feel, that you've wasted time. But after all, if you've
> > came up with some kind of tool, everybody else could take it. No
> > problems, useful ideas must and will evolve. But _ideally_ this must not be
> > from ground zero every time. _Ideally_ from technical, not personal
> > point of view ;).
> 
> As I expected, someone else has picked up regression tracking.
> And other from what you claim, this did not require any kind of tool.

So you expected good, doing bad. ``Bad'' means bringing pointless flame
about what everybody should do, without 

Re: limits on raid

[Dan Merillat]

For raid5 on an array with more than 3 drive, if you attempt to write
a single block, it will:

 - read the current value of the block, and the parity block.
 - "subtract" the old value of the block from the parity, and "add"
   the new value.
 - write out the new data and the new parity.

If the parity was wrong before, it will still be wrong.  If you then
lose a drive, you lose your data.


Wow, that really needs to be put somewhere in 120 point red blinking
text.  A lot of us are used to uninitialized disks calculating the
parity-on-first-write, but if linux MD is forgoeing that
'dangerous-no-resync' sounds really REALLY bad.  How about at least a
'Warning: unlike other systems this WILL cause corruption if you
forego reconstruction' on mkraid?
-
To unsubscribe from this list: send the line "unsubscribe 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

[Tim Post]

On Sat, 2007-06-16 at 00:44 -0300, Alexandre Oliva wrote:
> On Jun 16, 2007, Tim Post <[EMAIL PROTECTED]> wrote:
> 
> > On Fri, 2007-06-15 at 23:29 +0200, Ingo Molnar wrote:
> >> Tivo has two choices: either it gives 
> >> users the content they want to watch, or it goes out of business. Is 
> >> that legitimate enough of a reason to restrict the hardware?
> 
> > Can I submit that they could just rent the use of their machines?
> 
> I don't think this would escape the wording of section 6 in GPLv3dd4:
> 
>   [...] User Product is transferred to the recipient in perpetuity or
>   for a fixed term (regardless of how the transaction is
>   characterized), [...]
> 
> and IMHO that's as it should be to defend the freedoms of the user.
> 

Yes, I think you're right. There may be no good solution for tivo.

I'm not yet ready to give up on middle ground! :) I'll just have to work
harder if I'm to think of it. I refuse to accept a situation where the
only good outcome results in people being hurt, one way or another.

You might see that as futility, it could very well be. But I feel
obligated to keep looking and thinking because I can.

My head hurts.

Best,
--Tim

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

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 09:21:57PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
> 
> > Oh great, then things like source code control systems would have no
> > problems with new files being created under them, or renaming whole
> > trees.
> 
> It depends -- I think we may be talking about different things.
> 
> If you're using inotify to watch for new files and kick something in 
> userspace to relabel them, it could take a while to relabel a lot of 
> files, although there are likely some gains to be had from parallel 
> relabeling which we've not explored.
> 
> What I was saying is that you can use traditional SELinux labeling policy 
> underneath that to ensure that there is always a safe label on each file 
> before it is relabeled from userspace.

Ok, yes, I think we are in violent agreement here :)

> > So, so much for the "it's going to be too slow re-labeling everything"
> > issue, as it's not even required for almost all situations :)
> 
> You could probably get an idea of the cost by running something like:
> 
> $ time find /usr/src/linux | xargs setfattr -n user.foo -v bar
> 
> On my system, it takes about 1.2 seconds to label a fully checked out 
> kernel source tree with ~23,000 files in this manner, on a stock standard 
> ext3 filesystem with a SATA drive.

Yeah, that should be very reasonable.  I'll wait to see Crispin's code
to work off of and see if I can get it to approach that kind of speed.

thanks,

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

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

[Daniel Hazelton]

On Friday 15 June 2007 22:16:30 Bron Gondwana wrote:
> On Fri, Jun 15, 2007 at 04:26:34PM -0300, Alexandre Oliva wrote:
> > On Jun 15, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote:
> > > What happens if you're debugging something you think is a bug in the
> > > Linux kernel and then you run bang into some interactions that make you
> > > think the bug might be in the BIOS instead.
> > >
> > > have denied your freedom to modify and debug the system they sold you
> >
> > If the bug is in the non-GPLed BIOS, not in the GPLed code, too bad.
> > One more reason to dislike non-Free Software.
>
> If the bug is in the non-GPLed binary module, not in the GPLed code, too
> bad.  One more reason to dislike non-Free Software.
>
> It's the same argument from the other direction.  The BIOS is linked
> (inside the machine, sure) to the kernel for all intents and purposes
> through a defined interface.  This doesn't affect the BIOS developers
> who ship me a machine on to which I then install Linux, but it _does_
> affect a hardware vendor who ships me a system with Linux pre-installed,
> because it could easily be argued that they linked the BIOS with the
> Linux kernel and hence produced a combined work (remember, they reserve
> the right to modify the BIOS, but don't give that that right to me) and
> the BIOS should now come under the GPL.

This is the point that was being made, IMHO. But thank you for explaining it 
for the people that either could not understand, or will not willing to 
understand, the original point that was made.

DRH

>
> Talk about your chilling effects.  It's a strong reason for vendors not
> to ship GPL3 or GPL2[your interpretation] code pre-installed while the
> legal boundaries of work combination are in any way grey.
>
> Regards,
>
> Bron.



-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: My kernel hangs again: Help with git please

[Carlo Wood]

On Fri, Jun 15, 2007 at 08:33:38PM -0400, Daniel Barkalow wrote:
> HEAD doesn't mean what you think it means. It's the latest revision on the 
> branch with the *. What you want is:
> 
> $ git checkout master
> 
> This will move the * to "master", which shouldn't have been affected by 
> any of this, and move your working directory to this point as well. At 
> that point, you should be able to build a working kernel.
> 
> What "git reset --hard HEAD" does is discard any differences to tracked 
> files between your working directory and the revision you're on. It's 
> relevant if you want to discard local changes, not otherwise.

I don't understand - any branch that I am on has many tags. I can use
'git reset --hard sometag' to change the source tree to that tag (which
works if I look at the version in the Makefile and pick tags that are
far apart enough). Then, shouldn't 'HEAD' have the meaning: the newest
tag on the branch? I was on the 'bisect' branch - but that is a copy
of the master, no? At least, that was what I started on when I started
the bisect.

Anyway, I tried this:

$ git checkout master
$ git branch
  bisect
* master
  origin
$ BRANCH=$(git branch | grep "^\*" | sed -e "s/\* //")
$ echo $BRANCH
master
$ git rev-list --max-count=1 $BRANCH
5ecd3100e695228ac5e0ce0e325e252c0f11806f

Is it correct that this last command gives me the 'git id' (if that
is the correct name for the hash) of the revision that my local
working copy is at?

Can you tell me what is the latest git id that you see?

Because, if I compile 5ecd3100e695228ac5e0ce0e325e252c0f11806f is
still hangs at boot :(

I really don't know how I got a working kernel before :/

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

[Daniel Hazelton]

On Friday 15 June 2007 23:44:00 Alexandre Oliva wrote:
> On Jun 16, 2007, Tim Post <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-06-15 at 23:29 +0200, Ingo Molnar wrote:
> >> Tivo has two choices: either it gives
> >> users the content they want to watch, or it goes out of business. Is
> >> that legitimate enough of a reason to restrict the hardware?
> >
> > Can I submit that they could just rent the use of their machines?
>
> I don't think this would escape the wording of section 6 in GPLv3dd4:
>
>   [...] User Product is transferred to the recipient in perpetuity or
>   for a fixed term (regardless of how the transaction is
>   characterized), [...]
>
> and IMHO that's as it should be to defend the freedoms of the user.

In the case of renting a machine you can try to legislate new laws all you 
want. It doesn't make a difference. There are certain rights you don't get 
when renting something that you do when you own it.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alexandre Oliva]

On Jun 16, 2007, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:

> On Friday 15 June 2007 17:08, Alexandre Oliva wrote:
>> >> If the Program does not specify a version number of this License,
>> >> you may choose any version ever published by the Free Software
>> >> Foundation.

> Distributing a copy of GPL is not a requirement for me as a licensor
> however I did chose to include a copy of a specific version of a
> specific license and did not make any other statements that is the
> license for the work.
 
And the copy you chose to include says the above.

Are you absolutely sure you could terminate the license of a
distributor that refrains to pass on a patent license it obtained, if
you included a copy of the GPLv2 without any other indication that
you're choosing GPLv2 and no other version of the GPL, in spite of the
above?

Would it change anything if you had released the program back when
GPLv3 wasn't under discussion, and GPLv1 was long forgotten, so most
people (yourself included) only referred to it as GPL, or GNU GPL?

>> Then, any redistributor adds a copy of any version of the GPL (because
>> you didn't specify a version number).  At this point, is the program
>> licensed by *you* only under this specific license?

> If they did not make any changes then they have to include the earliest
> version of GPL that applies.

Why?  Why does it have to be the earliest?

>> even though the license itself 
>> says otherwise?

> License does not say otherwise. License says that if there is an
> _additional_ stipulation my the licensor then some other license
> (non existing yet license) may be used.

No, you're referring to the portion you quoted, but I'm referring to
another portion, that I quoted above.

> "If the Program specifies a version number of this License which
> applies to it and "or BSD license", you have the option of following
> the terms and conditions either of that version or of BSD license"

> would you still say that BSD is allowed by default by GPL? "GPL v2
> and later versions" is not different from "GPL v2 or BSD" or
> "GPLv2 or CDDL".

Agreed.  But this is not what this is about.  This is about the
license saying something like:

  If the program does not specify a license version number, then
  you're permitted to relicense the program under the BSD license.

Since the license file itself is not part of the program (if it were,
a program under the GPL would require the GPL itself to be under the
GPL, right?), I claim the program does not specify a license version
number.

Now what?

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

[Neil Brown]

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.
For raid5 on an array with more than 3 drive, if you attempt to write
a single block, it will:

 - read the current value of the block, and the parity block.
 - "subtract" the old value of the block from the parity, and "add"
   the new value.
 - write out the new data and the new parity.

If the parity was wrong before, it will still be wrong.  If you then
lose a drive, you lose your data.

With the current implementation in md, this only affect RAID5.  RAID6
will always behave as you describe.  But I don't promise that won't
change with time.

It would be possible to have a 'this is not initialised' flag on the
array, and if that is not set, always do a reconstruct-write rather
than a read-modify-write.  But the first time you have an unclean
shutdown you are going to resync all the parity anyway (unless you
have a bitmap) so you may as well resync at the start.

And why is it such a big deal anyway?  The initial resync doesn't stop
you from using the array.  I guess if you wanted to put an array into
production instantly and couldn't afford any slowdown due to resync,
then you might want to skip the initial resync but is that really
likely?

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

[Alexandre Oliva]

On Jun 16, 2007, Tim Post <[EMAIL PROTECTED]> wrote:

> On Fri, 2007-06-15 at 23:29 +0200, Ingo Molnar wrote:
>> Tivo has two choices: either it gives 
>> users the content they want to watch, or it goes out of business. Is 
>> that legitimate enough of a reason to restrict the hardware?

> Can I submit that they could just rent the use of their machines?

I don't think this would escape the wording of section 6 in GPLv3dd4:

  [...] User Product is transferred to the recipient in perpetuity or
  for a fixed term (regardless of how the transaction is
  characterized), [...]

and IMHO that's as it should be to defend the freedoms of the user.

-- 
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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, Casey Schaufler wrote:

> 
> --- James Morris <[EMAIL PROTECTED]> wrote:
> 
> > On my system, it takes about 1.2 seconds to label a fully checked out 
> > kernel source tree with ~23,000 files in this manner
> 
> That's an eternity for that many files to be improperly labeled.
> If, and the "if" didn't originate with me, your policy is
> demonstrably correct (how do you do that?) for all domains
> you could claim that the action is safe, if not ideal. 
> I can't say if an evaluation team would buy the "safe"
> argument. They've been known to balk before.

To clarify:

We are discussing a scheme where the underlying SELinux labeling policy 
always ensures a safe label on a file, and then relabeling newly created 
files according to their pathnames.

There is no expectation that this scheme would be submitted for 
certification.  Its purpose is to merely to provide pathname-based 
labeling outside of the kernel.



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

[Sanjoy Mahajan]

>> "version 2 or higher"

> That phrase exists outside the license

That's true.  But sec. 9 of the GPLv2 says:

  If the Program does not specify a version number of this License, you
  may choose any version ever published by the Free Software Foundation.

So, by making the COPYING contain the v2 text, is the author
specifying a particular version?  If yes, then the sec. 9 provision
would be meaningless, since there would be no way to not specify a
version number.  

My understanding is that courts would presume that a license term has
a meaning, if it has a plausible reading.  And there such a reading:
that to specify a version, there needs to be (e.g. in the source
files) a statement like, "This file [or work] is licensed under the
GNU GPLv2."

Corrections, flames, etc. are welcome.

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

Re: 2.6.22-rc[23]: blinking capslock led, stuck keys?

[Dmitry Torokhov]

On Friday 15 June 2007 22:04, Indan Zupancic wrote:
> On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
> >  /*
> > + * Schedule switch for execution. We need to throttle requests,
> > + * otherwise keyboard may become unresponsive.
> > + */
> > +static void atkbd_schedule_event_work(struct atkbd *atkbd, int event_bit)
> > +{
> > +   unsigned long delay = msecs_to_jiffies(50);
> > +
> > +   if (time_after(jiffies, atkbd->event_jiffies + delay))
> > +   delay = 0;
> > +
> > +   atkbd->event_jiffies = jiffies;
> > +   set_bit(event_bit, >event_mask);
> > +   wmb();
> > +   schedule_delayed_work(>event_work, delay);
> > +}
> 
> I don't know whether schedule_delayed_work() requeues event_work, or if
> it adds more work, but both seem to give wrong behaviour:

Well, my advise would be to research the matter before saying that
it will not work.

> In the first case 
> event_work can be postponed forever if atkbd_schedule_event_work() is
> called repeatedly each time within 50 ms, and for the second case there's a
> delay added, but the number of times the LED is switched stays the same,
> so it's not being throttled.
> 

No, once work is queued for execution subsequent attempts to queue the
same work will be ignored (until work starts executing). Therefore first
time work will be scheduled for execution immediately and then execution
be spaced by ~50 ms.

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

[Dmitry Torokhov]

On Friday 15 June 2007 17:08, Alexandre Oliva wrote:
> On Jun 15, 2007, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> 
> > On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> >> On Jun 15, 2007, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> >> 
> >> > On 6/15/07, Bernd Paysan <[EMAIL PROTECTED]> wrote:
> >> >> On Friday 15 June 2007 13:49, Paulo Marques wrote:
> >> >>
> >> >> > No, it is not "any version". It is the license specified in COPYING 
> >> >> > and
> >> >> > nothing else.
> >> >>
> >> >> COPYING says in section 9 that there may be other versions, and if you 
> >> >> as
> >> >> author don't specify the version, it's "any version".
> >> 
> >> > Please read this sentence over and over until it sinks:
> >> 
> >> I believe he was talking about the sentence just after the one you
> >> quoted:
> >> 
> >> If the Program does not specify a version number of this License,
> >> you may choose any version ever published by the Free Software
> >> Foundation.
> 
> > My response to this is that by including an entire copy of specific
> > version of GPL in the release the version number was specified.
> 
> It's not that simple.  Including a copy of the license is a license
> requirement for any redistributor, yes.
> 
> But if you, a sole copyright holder, were to distribute your program,
> without any copy of the GPL, claiming "it's under the GPL", you're not
> a violator.
>

Distributing a copy of GPL is not a requirement for me as a licensor
however I did chose to include a copy of a specific version of a
specific license and did not make any other statements that is the
license for the work.
 
> Then, any redistributor adds a copy of any version of the GPL (because
> you didn't specify a version number).  At this point, is the program
> licensed by *you* only under this specific license?
>

If they did not make any changes then they have to include the earliest
version of GPL that applies. If they did modifications and chose GPLv4
they will have to include GPL v4 (if such requirement is in GPLv4) because
what good any other license will do me?
 
> Now, if you picked one of the various versions of the license, to make
> things easier for redistributors, does it mean you're choosing that
> particular version of the license,

Yes, this is my opinion.

> even though the license itself 
> says otherwise?
>

License does not say otherwise. License says that if there is an
_additional_ stipulation my the licensor then some other license
(non existing yet license) may be used. They had to use this wording
because these licensed do not exist yet. If GPL would say:

"If the Program specifies a version number of this License which
applies to it and "or BSD license", you have the option of following
the terms and conditions either of that version or of BSD license"

would you still say that BSD is allowed by default by GPL? "GPL v2
and later versions" is not different from "GPL v2 or BSD" or
"GPLv2 or CDDL".  

> > You can't say that inclusion of copy of GPL is enough to specify
> > class of licenses (all GPL) but not specific version.
> 
> I can't say either of these, indeed.  Or rather, I can, but I wouldn't
> know whether I was right ;-)
> 

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

[Rob Landley]

On Friday 15 June 2007 14:15:58 Linus Torvalds wrote:
> On Fri, 15 Jun 2007, Carlo Wood wrote:
> > The point is: can you, or can't you (legally) relicense the whole kernel
> > tree under the GPLv3 (or GPLv2+GPLv3)?
>
> No. My special rights do not actually give me those kinds of powers,
> exactly because I'm bound by my _other_ agreement (namely the GPLv2) to
> follow the license of the code that other people have sent me.
>
> > At first I thought that you cannot, because too many (significant)
> > contributors have been involved (and you will never get signatures from
> > them all). Then someone surprised me by claiming that the original author
> > had copyright for everything - even files added by others.
>
> Both are true facts, but the "copyright for everything" is a *separate*
> kind of copyright, which does not include the right to relicense. It's
> literally the "copyright in the collective".
>
> For examples of the US rules, see USC 17.2.201(c) ("Ownership of
> copyright" and " Contributions to Collective Works"), which spells out
> some limited special rights that I have (namely the right to reproduce and
> distribute).

http://www.copyright.gov/title17/92chap2.html#201

There are some really interesting bits in Chapter 1 too...

http://www.copyright.gov/title17

> entirely sure about certain special cases. In particular, if somebody
> tried to _revoke_ the rights to their code under the GPLv2,

There's no revocation clause in the license.  They can't.  (SCO would have 
tried to revoke Caldera's license to its contributions it if it were at all 
possible.)

> I suspect that 
> my rights in the collective would protect me from that and allow me to
> still distribute the code in question, since _those_ rights cannot be
> revoked, and they are _mine_).

Title 17 chapter 1 section 103(a) seems to lean against this.  I think it says 
that having rights to the collective is conditional on having had the rights 
to the components of that collective.

> So only in the case of some really obscure and unclear situations, I _may_
> have more rights than some other people, but trust me, but that is damn
> murky, and you'd better have a good lawyer state it, not just a programmer
> who has talked to too many lawyers..

Entirely agreed. :)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe 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: PC speaker

[Kyle Moffett]

On Jun 15, 2007, at 15:34:52, Jan Engelhardt wrote:
Perhaps live cd? In which case, the OP should, as recommended in  
this thread already, deactivate choosing boot devices, if that's  
possible.


(Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or  
so, but I have not seen a way to deactivate _that_ menu.)


Heh, with virtually every PC BIOS I've seen, the procedure is  
something like this:


1)  Reboot into BIOS
2)  Set a BIOS "Supervisor Password" (as opposed to "User" or "Boot"  
password)
3)  Go to the "Boot Devices" list and uncheck everything except "Hard  
Disk"

4)  Go to the "USB Stick Hard Disk Emulation" feature and turn that off
5)  Save settings to BIOS and reboot (Usually "F10" or "ESC-Y" )

The "Integrated BootMenu (F8)" stuff only lists boot devices that are  
enabled in the BIOS.  If everything but the hard disk is disabled  
then pressing (F8) is _really_useful_ :-)

  1) Boot from Hard Disk
  2) Enter BIOS Setup

Of course, choosing option 2 is also quite an entertaining thing for  
the student:

,--.
| Enter Password:  |
`--'

And since they don't actually know the password, it's followed by the  
inevitable:

,--.
| Invalid Password |
`--'

Admittedly there are more things to turn off than with older BIOSen,  
but there are also more features too.  Of course, with OpenFirmware- 
based systems (like the PowerPC macs) it's scriptable and doesn't  
require rebooting.

  1)  Install the "nvsetenv" utility via your distro

  2)  Encode your password by xoring each character's ascii value  
with 0xAA and printing the result in hex.  This perl oneliner will do  
it easily (Change 'my-password' to your plain-text password).
perl -ne 'map { printf "%%%02x", 0xaa ^ ord($_) } split //, $1;  
print "\n"' my-password


  For example, the password "linux" is encoded as "%c6%c3%c4%df%d2"

  3)  Run "nvsetenv security-password %c6%c3%c4%df%d2", where the  
hex stuff is your encoded password


  4)  Run "nvsetenv security-mode command"

Then it auto-locks all possible ways of modifying the open-firmware  
boot device or specifying alternative boot options.  The only way to  
get around it on most systems is with the firmware-reset button on  
the inside of the case or moving RAM around and rebooting with some  
magic key combo held down (Cmd-Opt-P-R on mac systems).  Typically if  
your students can do that there's exactly nothing you can do to  
prevent them from doing whatever they want.  They could always just  
stick in a different hard-drive, after all.


Cheers,
Kyle Moffett

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

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

[Tim Post]

On Fri, 2007-06-15 at 23:29 +0200, Ingo Molnar wrote:

> Tivo has two choices: either it gives 
> users the content they want to watch, or it goes out of business. Is 
> that legitimate enough of a reason to restrict the hardware?

Can I submit that they could just rent the use of their machines? It
seems to me like that would work. People can copy the copy of Linux to
their hearts content, but do not own the machines. Its then up to people
if they feel comfortable with that.

If nothing else, a little label that says "This appliance contains free
software which you can copy, but not modify in place". In other words,
you can't treat our gizmos like you would a computer. Therefore we rent
them. Its up to you if you get one after knowing that.

> If you want to make a difference you shouldnt attempt to screw with 
> Tivo, they are clearly the _victims_ of the content industry.

They are now more than ever a house hold word in every country. They
have the public at large championing them. I'd say they were a huge
success.

The situation you describe is very real however, I don't mean to negate
it. They did face undue hardship due to the stupid and unpredictable
industries that they built their business around.

But, they elected to do it. They deserve some sympathy and some kudos
for breaking ground, but I just can't quite see them as a total victim
in all of this. A victim never asked for it in the first place.

Best,
--Tim

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

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Casey Schaufler]

--- James Morris <[EMAIL PROTECTED]> wrote:

> On my system, it takes about 1.2 seconds to label a fully checked out 
> kernel source tree with ~23,000 files in this manner

That's an eternity for that many files to be improperly labeled.
If, and the "if" didn't originate with me, your policy is
demonstrably correct (how do you do that?) for all domains
you could claim that the action is safe, if not ideal. 
I can't say if an evaluation team would buy the "safe"
argument. They've been known to balk before.


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

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Sat, Jun 16, 2007 at 03:32:36AM +0200, Oleg Verych wrote:
> On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
> > On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
> > > 
> > > 
> > > On Thu, 14 Jun 2007, Oleg Verych wrote:
> > > > 
> > > > I'm seeing this long (198) thread and just have no idea how it has
> > > > ended (wiki? hand-mailing?).
> > > 
> > > I'm hoping it's not "ended".
> > > 
> > > IOW, I really don't think we _resolved_ anything, although the work that 
> > > Adrian started is continuing through the wiki and other people trying to 
> > > track regressions, and that was obviously something good.
> > > 
> > > But I don't think we really know where we want to take this thing in the 
> > > long run. I think everybody wants a better bug-tracking system, but 
> > > whether something that makes people satisfied can even be built is open. 
> > > It sure doesn't seem to exist right now ;)
> > 
> > The problem is not the bug tracking system, be it manual tracking in a 
> > text file or a Wiki or be it in Bugzilla or any other bug tracking 
> > system.
> > 
> > One problem is the lack of experienced developers willing to debug bug 
> > reports.
> 
> *debug*
> 
> I hope you saw what subject i've chosen to bring this discussion back.
> Yes, "tracking", as the first brick for big wall.

Tracking regressions is not a real problem.
Especially since it doesn't require much technical knowledge.

> Your arguments about developers and users, you've said already, but i've
> asked different questions, have i?
> 
> Lets look on regular automatic report, like this one:
> 
> Message-ID: <[EMAIL PROTECTED]>
> Xref: news.gmane.org gmane.linux.debian.devel.general:116248
> Archived-At: 
>  
> And what we see? Basic packages, like ``dpkg'', ``grub'', ``mc'' are
> in the list, requesting help. And as you can see for quite some time.
> And it's *OK*, because distribution is working, development is going on.
> Sometimes slowly, sometimes with delays.

I sent weekly regression reports.
Not automatically generated but manually - but that doesn't matter.

The problem is that sending reports itself does not fix anything.

> > But what really annoyed me was the missing integration of regression 
> > tracking into the release process, IOW how _you_ handled the regression 
> > lists.
> 
> So, _tracking_ or _debugging_?

_debugging_ (can be indirectly by poking other people to do debugging)

> > If we want to offer something less of a disaster than 2.6.21, and if we 
> > want to encourage people to start and continue testing -rc kernels, we 
> > must try to fix as many reported regressions as reasonably possible.
> 
> *tracking*

no, *debugging*

I tracked regressions for the 2.6.21 disaster, and the not debugged 
regressions that I had tracked are exactly where we should be better.

>...
> > This means going through every single point in the regression list 
> > asking "Have we tried everything possible to solve this regression?". 
> > There are very mysterious regressions and there are regressions that 
> > might simply be reported too late. But if at the time of the final 
> > release 3 week old regressions hadn't been debugged at all there's 
> > definitely room for improvement. And mere mortals like me reminding 
> > people is often not enough, sometimes an email by Linus Torvalds himself 
> > asking a patch author or maintainer to look after a regression might be 
> > required.
> 
> *social* (first approximation)

Yes.

> That's a social problem, just like Debian loosing good kernel team members.

Different social problem.

> For example you feel, that you've wasted time. But after all, if you've
> came up with some kind of tool, everybody else could take it. No
> problems, useful ideas must and will evolve. But _ideally_ this must not be
> from ground zero every time. _Ideally_ from technical, not personal
> point of view ;).

As I expected, someone else has picked up regression tracking.
And other from what you claim, this did not require any kind of tool.

> That's why people in Debian have started *team* maintenance with alioth. 

The problem for the Linux kernel is that for a better bug handling you'd 
need people willing to learn other people's code and to do the hard work 
of debugging bug reports. E.g. writing a new filesystem is simply much 
more fun than learning and debugging other people's code in some old 
filesystem.

Talking about "team maintenance" sounds nice, but the problem in the 
kernel starts with code that has zero maintainers. And if there's 
already a maintainer, it's unlikely that he'll not accept patches from 
some new person debugging bug reports. But how to find people who will 
become good maintainers?

> Unfortunately problems with individuals in big machine with bad people,
> got randomly elected, can't be solved (IMHO). Even LKML's rule "patches
> are welcome", that is very technical, thus good, 

Re: [PATCH] natsemi irq flags

[Alexey Dobriyan]

On Fri, Jun 15, 2007 at 06:06:58PM -0400, Chuck Ebbert wrote:
> On 06/15/2007 05:17 PM, Gregory Haskins wrote:
> > The spinlock irq flags should be a unsigned long to properly support 64 bit
> 
> Ouch. Can't we automate checking for that?

Hopefully I'll do it before next -rc1.

--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -191,6 +191,7 @@ typedef __u32 __bitwise __wsum;
 
 #ifdef __KERNEL__
 typedef unsigned __bitwise__ gfp_t;
+typedef unsigned long __bitwise__ irq_flags_t;
 
 #ifdef CONFIG_RESOURCES_64BIT
 typedef u64 resource_size_t;


803 files changed, 2651 insertions(+), 2617 deletions(-)
and counting

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

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, Seth Arnold wrote:

> The time for restorecon is probably best imagined as a kind of 'du' that
> also updates extended attributes as it does its work. It'd be very
> difficult to improve on this.

restorecon can most definitely be improved. 


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

[Bron Gondwana]

On Fri, Jun 15, 2007 at 04:26:34PM -0300, Alexandre Oliva wrote:
> On Jun 15, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote:
> 
> > What happens if you're debugging something you think is a bug in the
> > Linux kernel and then you run bang into some interactions that make you
> > think the bug might be in the BIOS instead.
> 
> > have denied your freedom to modify and debug the system they sold you
> 
> If the bug is in the non-GPLed BIOS, not in the GPLed code, too bad.
> One more reason to dislike non-Free Software.

If the bug is in the non-GPLed binary module, not in the GPLed code, too
bad.  One more reason to dislike non-Free Software.

It's the same argument from the other direction.  The BIOS is linked
(inside the machine, sure) to the kernel for all intents and purposes
through a defined interface.  This doesn't affect the BIOS developers
who ship me a machine on to which I then install Linux, but it _does_
affect a hardware vendor who ships me a system with Linux pre-installed,
because it could easily be argued that they linked the BIOS with the
Linux kernel and hence produced a combined work (remember, they reserve
the right to modify the BIOS, but don't give that that right to me) and
the BIOS should now come under the GPL.

Talk about your chilling effects.  It's a strong reason for vendors not
to ship GPL3 or GPL2[your interpretation] code pre-installed while the
legal boundaries of work combination are in any way grey.

Regards,

Bron.
-
To unsubscribe from this list: send the line "unsubscribe 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

[Tim Post]

On Fri, 2007-06-15 at 19:52 -0500, Scott Preece wrote:

> 
> Yes, but in highlighting the possibility of evil intentions you
> distort the fact that usually there are no such evil intentions...
> 

I don't think you can use "usually" and "fact" together like that. Why
is it so bad to account for them since they (do) surface and (could)
increase significantly in frequency? 

For me, the (could) is enough to act upon, regardless of the current
likely hood of it happening. Things change frequently. 

This, unfortunately comes pre-distorted depending on what you believe.
All of us are right but we still don't agree. Quite a fluke. 

That's the problem.

Best,
--Tim



-
To unsubscribe from this list: send the line "unsubscribe 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]

By the way, the unfortunate answer to the question of what the default
position is when contributions to a collective work are received without
explicit license, at least in the United States, is:

"In the absence of an express transfer of the copyright or of any rights
under it, the owner of copyright in the collective work is presumed to have
acquired only the privilege of reproducing and distributing the contribution
as part of that particular collective work, any revision of that collective
work, and any later collective work in the same series." -- USC 201(c)

That is, as I understand the law, if you receive a contribution to a project
without any specific license in that contribution, it works like this:

1) You automatically receive a license to use that piece as part of that
project by virtue of the fact that it was contributed by the author to that
project. (Because 210(c) says so.)

2) If the contribution is itself a derivative work of a GPL'd work, then you
receive a GPL license. (Because the GPL says so).

So it would be very unwise to add a contribution that wasn't itself a
derivative work without clear indication from the author that the
contribution is offered under the license you need. I had assumed no law set
a default, and therefore the default would be the project's license. THIS IS
INCORRECT. 201(c) sets the default, and it's the wrong one.

This means that contributions of non-derivative works to GPL projects should
not be added to the project unless the author specifically licenses that
piece under the GPL. I would not consider it safe to assume that the fact
that the author knowingly contributed the work to a GPL'd project is
sufficient to change the 201(c) default.

What's worse, section 203 appears to grant the author various ways, by law,
to *terminate* a license grant. This termination removes the ability to
create subsequent derivative works. Ouch.

http://www.copyright.gov/title17/92chap2.html

I sure hope I'm misunderstanding something.

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

[Wakko Warner]

Neil Brown wrote:
> On Thursday June 14, [EMAIL PROTECTED] wrote:
> > why does it need to do a rebuild when makeing a new array? couldn't it 
> > just zero all the drives instead? (or better still just record most of the 
> > space as 'unused' and initialize it as it starts useing it?)
> 
> Yes, it could zero all the drives first.  But that would take the same
> length of time (unless p/q generation was very very slow), and you
> wouldn't be able to start writing data until it had finished.
> You can "dd" /dev/zero onto all drives and then create the array with
> --assume-clean if you want to.  You could even write a shell script to
> do it for you.

I still fail to see the reason to actually "resync" the drives.  I've dealt
with some hardware raid devices and they do not force a resync but they do
recommend it.

If there was no resync (I have not found a way to force the kernel not to do
this), the parity will not be correct.  Well in this case, that's fine, the
data is pretty much useless anyway.  (I'm assuming newly created arrays,
not attempting to recreate an array that had some failures)

Noone zeros out a new hard drive because of what might be on it.  You just
fdisk (or lvm or whatever), mkfs and use it.  Assume this is performed on an
array that has not been resync'd (or initialized as some hardware raids call
it).  You fdisk it, mkfs it, and start using it.  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.
(I also assume that if you write lots of data at a time, there may not be a
read since those sectors will be over written anyway).

Ok, so we have a device with some parity information "correct" due to writes
of some of the sectors but not all of them since there was no resync.  What
happens if a drive fails and you replace it?  Ok, now we have to resync. 
The strips that were never written to may now have random data.  Well, does
that *really* matter?  After all, it was never written to.

In the past, I have used arrays that were not initialized (hardware raids)
and had to rebuild the array due to a disk failure.  There was no problems
with the data that was already allocated on the array.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22-rc[23]: blinking capslock led, stuck keys?

[Indan Zupancic]

On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
> Does the patch below help?

Didn't try it yet, but will tomorrow.


> Input: atkbd - throttle LED switching
>
> On some boxes keyboard controllers are too slow to withstand
> continuous flow of requests to turn keyboard LEDs on and off
> and start losing some keypresses or even all of them.
>
> Delay executing of LED switching request if we had another one
> withing 50 ms thus easing load on the controller.
>
> Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
> ---
>
>  drivers/input/keyboard/atkbd.c |   40 
> ++--
>  1 files changed, 26 insertions(+), 14 deletions(-)
>
> Index: work/drivers/input/keyboard/atkbd.c
> ===
> --- work.orig/drivers/input/keyboard/atkbd.c
> +++ work/drivers/input/keyboard/atkbd.c
> @@ -219,7 +219,8 @@ struct atkbd {
>   unsigned long time;
>   unsigned long err_count;
>
> - struct work_struct event_work;
> + struct delayed_work event_work;
> + unsigned long event_jiffies;
>   struct mutex event_mutex;
>   unsigned long event_mask;
>  };
> @@ -565,7 +566,7 @@ static int atkbd_set_leds(struct atkbd *
>
>  static void atkbd_event_work(struct work_struct *work)
>  {
> - struct atkbd *atkbd = container_of(work, struct atkbd, event_work);
> + struct atkbd *atkbd = container_of(work, struct atkbd, event_work.work);
>
>   mutex_lock(>event_mutex);
>
> @@ -579,12 +580,30 @@ static void atkbd_event_work(struct work
>  }
>
>  /*
> + * Schedule switch for execution. We need to throttle requests,
> + * otherwise keyboard may become unresponsive.
> + */
> +static void atkbd_schedule_event_work(struct atkbd *atkbd, int event_bit)
> +{
> + unsigned long delay = msecs_to_jiffies(50);
> +
> + if (time_after(jiffies, atkbd->event_jiffies + delay))
> + delay = 0;
> +
> + atkbd->event_jiffies = jiffies;
> + set_bit(event_bit, >event_mask);
> + wmb();
> + schedule_delayed_work(>event_work, delay);
> +}

I don't know whether schedule_delayed_work() requeues event_work, or if
it adds more work, but both seem to give wrong behaviour: In the first case
event_work can be postponed forever if atkbd_schedule_event_work() is
called repeatedly each time within 50 ms, and for the second case there's a
delay added, but the number of times the LED is switched stays the same,
so it's not being throttled.

Greetings,

Indan


-
To unsubscribe from this list: send the line "unsubscribe 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

[Rob Landley]

On Friday 15 June 2007 18:59:14 Linus Torvalds wrote:
> So it's true: the GPL just gives you rights, and without it you have no
> rights (other than fair use ones etc), and blah blah. But the distinction
> between "license" vs "contract" really isn't a very important one in any
> case.

Er, copyright law is federal, contract law is generally state level?  So not 
only does contract law vary a lot more by jurisdiction, but it's enforced by 
different courts than suits over copyright?  (You'll notice the GPL doesn't 
say which state law holds sway.  If it was a contract this would be kind of 
important.)

Also, in addition to the "exchange of value" bit there's "privity of contract" 
and "informed consent" when dealing with contract, which are cans of worms 
which can be avoided by Not Going There (tm)...

(These were largeish issues in the SCO vs Novell case, involving lots of 
motions in Utah detailed blow-by-blow on Groklaw...)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, Seth Arnold wrote:

> > How does inotify not work here?  You are notified that the tree is
> > moved, your daemon goes through and relabels things as needed.  In the
> > meantime, before the re-label happens, you might have the wrong label on
> > things, but "somehow" SELinux already handles this, so I think you
> > should be fine.
> 
> SELinux does not relabel files when containing directories move, so it
> is not a problem they've chosen to face.

It's a deliberate design choice, and follows traditional Unix security 
logic.  DAC permissions don't change on every file in the subtree when you 
mv directories, either.




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

[Alexandre Oliva]

On Jun 15, 2007, Rob Landley <[EMAIL PROTECTED]> wrote:

> On Friday 15 June 2007 15:28:29 Alexandre Oliva wrote:
>> On Jun 15, 2007, Rob Landley <[EMAIL PROTECTED]> wrote:
>> > On Thursday 14 June 2007 22:25:57 Alexandre Oliva wrote:
>> >> Is the signature not derived from the bits in the GPLed component, as
>> >> much as it is derived from the key?

>> > Actually, you can't copyright, trademark, or patent a number.

>> Agreed.  And this counter-argument of yours is a distraction.

>> I was careful to not talk about "derived work". 

> "Is the signature not derived from X as much as it is derived from Y."

> "I was careful to not talk about "derived work"."

> Which personality of yours am I currently addressing?

The one that speaks English, not Legalese.  IANAL.

Last I looked it up, "derived" was a plain-English word.

-- 
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 15, 2007, "Scott Preece" <[EMAIL PROTECTED]> wrote:

> On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> > * Daniel Hazelton <[EMAIL PROTECTED]> wrote:
>> 
>> That's correct, but with a catch: since the contract or license is
>> chosen by the licensor, in case of ambiguity in the terms, many courts
>> will interpret it in a way that privileges the licensee, regardless of
>> the fact that copyright licenses are to be interpreted restrictively
>> (at least in Brazilian law).  And IANAL ;-)
> ---

> Hmm. In such a suit, however, the user would not be "the licensee" and
> would not be a party to the suit - some author would be the plaintiff
> and would be suing someone for doing something in violation of the
> license that author granted - that is, the *defendant* would be the
> licensee who would get the benefit of the doubt...

Yes.  And so justice is made.  Licensor gets to pick the license,
licensee gets the benefit of the doubt.  What's the 'however' about?
Was this not obvious?

-- 
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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote:

> on the contrary, useing 'mv' is by far the cleanest way to do this.
> 
> mv htdocs htdocs.old;mv htdocs.new htdocs
> 
> this makes two atomic changes to the filesystem, but can generate thousands to
> millions of permission changes as a result.

OTOH, you've performed your labeling up front, and don't have to 
effectively relabel each file each time on each access, which is what 
you're really doing with pathname labeling.



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

[Alexandre Oliva]

On Jun 15, 2007, "Scott Preece" <[EMAIL PROTECTED]> wrote:

> On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> > The FSF's approval of this distinction (ROM versus replaceable) places
>> > the FSF's particular principles over users interests, for no
>> > particular reason

>> Over *users* interest?  How so?

> Users benefit from the ability to get software updates, from the
> manufacturer, to resolve problems, fix security vulnerabilities, and
> provide updated functionality.

Which they could have the option to do themselves if the manufacturer
didn't prohibit them from doing so.

>> > if the manufacturer believes that it cannot legally allow software
>> > modification, all the restriction does is force them either to make
>> > the software unmodifiable (which advances freedom not at all) or to
>> > use software under a different license (which advances freedom not
>> > at all).

>> Right.

>> But if the manufacturer believes that it can legally allow it, and
>> wants to be able to install, software modifications, then it must
>> decide between giving that up and letting the user do it as well.  And
>> this is where the users interests may prevail.

> Whether it's a legal requirement or a business decision, the result is
> the same - neither forcing the manufacturer to make the device
> non-updatable nor forcing the manufacturer to use different software
> benefits anyone.

I agree.  But that's an incomplete picture.

It's the other part of the picture, that you left out twice, that is
the case that is good for the users *and* for the community.

> I don't believe that the existence of this clause will lead to more
> manufacturers making their devices modifiable - there are too many
> other options if they think that non-modifiability is important to
> them.

> [Note that I *do* think it's perfectly appropriate that authors who
> feel that they don't want their work used in such devices should be
> able to license them in line with that belief. I just don't think it
> has any practical value aside from making them feel better.]

They can do that with GPLv3.  And those who don't want to stop this
can then add a special permission.  And then everybody wins.

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

[Linus Torvalds]

On Fri, 15 Jun 2007, Rob Landley wrote:
> 
> Technically what they're holding back is _trademark_ rights, which are a 
> different area of IP law and not addressed by the GPL.  (I know you know 
> this, but just for the record...)

No, technically Red Hat really *does* have copyrights of their own.

Red Hat owns the "compilation copyright" on their distribution. That 
means, for example, that even if they have _only_ open source programs on 
their DVD image, you still are not necessarily able (without their 
permission) to set up a "cheap-cd's" kind of operation, and sell their 
CD-ROM/DVD images for a lower price.

So yes, they do own the Red Hat trademark too, but they fundamentally do 
own copyrights over and beyond those of the individual programs they 
distribute!

Now, I think it so happens that the RHEL DVD's contains other programs 
than just open source, and that you couldn't legally copy them *anyway*, 
but that's a different issue.

Also, happily, a lot of vendors do not *want* to exercise their 
copyright in the compilation, so you can go to cheapbytes.com, and you'll 
find Fedora CD's, OpenSuSE CD's, Ubuntu CD's, etc, and as far as I know, 
they're all perfectly legal. Exactly because open-source vendors usually 
don't want to look nasty by limiting the compilation, when they can't 
really limit the individual parts anyway.

> The five main areas of IP law as I understand them are copyright, patent, 
> trademark, contract, and trade secret.

I'd not put contract there, but fair enough. But what I was really trying 
to point out is that there are many different "levels" of copyright.

So you can own a "copyright in the compilation" - which just means that 
you own the details of how you set it all together - _without_ actually 
necessarily owning the copyrights in any of the individual packages 
(although you obviously have to have a license to _make_ a compilation of 
them - but the GPLv2 is one such license).

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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, Greg KH wrote:

> Oh great, then things like source code control systems would have no
> problems with new files being created under them, or renaming whole
> trees.

It depends -- I think we may be talking about different things.

If you're using inotify to watch for new files and kick something in 
userspace to relabel them, it could take a while to relabel a lot of 
files, although there are likely some gains to be had from parallel 
relabeling which we've not explored.

What I was saying is that you can use traditional SELinux labeling policy 
underneath that to ensure that there is always a safe label on each file 
before it is relabeled from userspace.

> So, so much for the "it's going to be too slow re-labeling everything"
> issue, as it's not even required for almost all situations :)

You could probably get an idea of the cost by running something like:

$ time find /usr/src/linux | xargs setfattr -n user.foo -v bar

On my system, it takes about 1.2 seconds to label a fully checked out 
kernel source tree with ~23,000 files in this manner, on a stock standard 
ext3 filesystem with a SATA drive.



- James
-- 
James Morris
<[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: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
> On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Thu, 14 Jun 2007, Oleg Verych wrote:
> > > 
> > > I'm seeing this long (198) thread and just have no idea how it has
> > > ended (wiki? hand-mailing?).
> > 
> > I'm hoping it's not "ended".
> > 
> > IOW, I really don't think we _resolved_ anything, although the work that 
> > Adrian started is continuing through the wiki and other people trying to 
> > track regressions, and that was obviously something good.
> > 
> > But I don't think we really know where we want to take this thing in the 
> > long run. I think everybody wants a better bug-tracking system, but 
> > whether something that makes people satisfied can even be built is open. 
> > It sure doesn't seem to exist right now ;)
> 
> The problem is not the bug tracking system, be it manual tracking in a 
> text file or a Wiki or be it in Bugzilla or any other bug tracking 
> system.
> 
> One problem is the lack of experienced developers willing to debug bug 
> reports.

*debug*

I hope you saw what subject i've chosen to bring this discussion back.
Yes, "tracking", as the first brick for big wall.

Your arguments about developers and users, you've said already, but i've
asked different questions, have i?

Lets look on regular automatic report, like this one:

Message-ID: <[EMAIL PROTECTED]>
Xref: news.gmane.org gmane.linux.debian.devel.general:116248
Archived-At:  But what really annoyed me was the missing integration of regression 
> tracking into the release process, IOW how _you_ handled the regression 
> lists.

So, _tracking_ or _debugging_?

> If we want to offer something less of a disaster than 2.6.21, and if we 
> want to encourage people to start and continue testing -rc kernels, we 
> must try to fix as many reported regressions as reasonably possible.

*tracking*

Despite of tools, Debian have such thing as long release cycles, so
called ``Debian sickness''. And reason, i see, is what you've just
pointed out: less disaster, zer0 RC bugs. Plus everybody is volunteer,
big chunk of bureaucracy-based decisions. And all this for about
15000 packages.

* + reporting*

One side Linux is facing is hardware, and that kind of thing is very-very
diverse. LKML traffic is huge, yet there's no suitable tracking and
reporting *tool*.

> This means going through every single point in the regression list 
> asking "Have we tried everything possible to solve this regression?". 
> There are very mysterious regressions and there are regressions that 
> might simply be reported too late. But if at the time of the final 
> release 3 week old regressions hadn't been debugged at all there's 
> definitely room for improvement. And mere mortals like me reminding 
> people is often not enough, sometimes an email by Linus Torvalds himself 
> asking a patch author or maintainer to look after a regression might be 
> required.

*social* (first approximation)

That's a social problem, just like Debian loosing good kernel team members.

For example you feel, that you've wasted time. But after all, if you've
came up with some kind of tool, everybody else could take it. No
problems, useful ideas must and will evolve. But _ideally_ this must not be
from ground zero every time. _Ideally_ from technical, not personal
point of view ;).

That's why people in Debian have started *team* maintenance with alioth. 

Unfortunately problems with individuals in big machine with bad people,
got randomly elected, can't be solved (IMHO). Even LKML's rule "patches
are welcome", that is very technical, thus good, doesn't work there.

Finally, read the end of 2.6.21 release message ;)

> And a low hanging fruit to improve the release would be if you could 
> release one last -rc, wait for 48 hours, and then release either this 
> -rc unchanged as -final or another -rc (and wait another 48 hours).
> There were at least two different regressions people ran into in 2.6.21 
> who successfully tested -rc7.

What about Linus' tree is a development tree, Andrew's one is a "crazy
development one" (quoting Linus)?

What about open (web page still exists) position on bug manager in
Google?

What about *volunteers* working from both developer's and user's
sides? What about "release is a reward" for everybody?

Balanced eco-system will oscillate. Be it .19(---++), .20(-),
.21(+) *relese*. That's natural, unless pushed to extremes.

I think, i can trust Linus in it, and you are welcome too.

*tools*

That's why i'm talking about tools, and started to discuss them.

My last try: reportbug (there's "-ng" one also), Debian BTS.

Adrian, 

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

[Rob Landley]

On Friday 15 June 2007 15:28:29 Alexandre Oliva wrote:
> On Jun 15, 2007, Rob Landley <[EMAIL PROTECTED]> wrote:
> > On Thursday 14 June 2007 22:25:57 Alexandre Oliva wrote:
> >> Is the signature not derived from the bits in the GPLed component, as
> >> much as it is derived from the key?
> >
> > Actually, you can't copyright, trademark, or patent a number.
>
> Agreed.  And this counter-argument of yours is a distraction.
>
> I was careful to not talk about "derived work". 

"Is the signature not derived from X as much as it is derived from Y."

"I was careful to not talk about "derived work"."

Which personality of yours am I currently addressing?

> Please read it again 
> under this clarification (that I'm pretty sure I'd already made
> before, but it's getting hard to keep track of everything in this
> thread ;-)

I'm going to stop feeding the troll now...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe 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

[Daniel Hazelton]

On Friday 15 June 2007 20:22:50 Alexandre Oliva wrote:
> On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > * Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> >> On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >> > it irreversibly cuts off certain people from being to distribute
> >> > GPLv3-ed software alongside with certain types of hardware that the
> >> > FSF's president does not like.
> >>
> >> That's not true.  They can just as well throw the key away and refrain
> >> from modifying the installed software behind the users' back.
> >
> > uhm, so you claim that my argument is false, and your proof for that is
> > a "non-upgradeable Tivo"??  That is a _great_ idea. Not being
> > able to patch security holes. Not being able to fix bugs. Not being able
> > to add new features. Makes complete sense.
>
> Oh, so you think patching security holes, fixing bugs and adding new
> features are good ideas?  What if you can't do it in your TiVo?
>
> >> > guess why this section has been completely removed from the GPLv3,
> >> > without a replacement?
> >>
> >> My guess:
> >>
> >> First, because it was redundant, given that the license didn't quite
> >> discuss other activities.  Unless you count say "imposing restrictions
> >> on the exercise of others' freedoms" as other activities, even though
> >> these are associated with modification and distribution.
> >
> > here you prove that you cannot even read what i wrote. I wrote that this
> > section has been removed from the GPLv3. What relevance does it have
> > that in your opinion this section was redundant in the GPLv2??
>
> If you didn't mean "removed from the GPLv3 as compared with v2", I
> misunderstood what you wrote.
>
> The fact that it's redundant is v2 means it is reasonable to take it
> out.  That's the relevance.

It isn't redundant at all. I specifies the definitions of several terms used 
in the GPLv2 and also defines the exact scope of the license. If you feel 
that the definition of the terms and the limitation of scope were redundant 
then you are sadly mistaken.

> > It would clearly not be redundant in the GPLv3: it would contradict
> > and _completely neutralize_ most of the crap from the GPLv3 that we
> > are talking about here ...
>
> And, per the same reasoning, some of the v2 provisions as well.

For a license to be legally enforceable it must be internally consistent. 
Without that internal consistency it becomes very easy to circumvent it. The 
GPLv2's definitions and defined scope - as per section 0 - define the limits 
of the license and are entirely consistent with the rest of it. What it 
*isn't* consistent with is the FSF's other "propaganda" and the wants of the 
FSF to make certain activities verboten in GPLv3.

> > dont you realize that declaring certain types of activities by hardware
> > makers as being "against freedom" is _exactly_ such an activity that the
> > GPLv2 did not attempt to control?
>
> No.  And some Linux hackers disagree with your assessment too.

And that is their right. However, it appears to a nearly unanimous consensus 
that it is the truth. It may not be liked by some people, but likes and 
dislikes don't matter.

> > censure, opression of free speech, out of control climate,
> > dictatorship, campaign financing laws, the WIN32 API and human
> > stupidity. By your argument we'd have to add prohibition against
> > those restrictions of freedom to the license too, right?
>
> -ENONSEQUITUR
>
> How do these stop a user's exercise of the four freedoms of a piece of
> software licensed under the GPL?
>
> > Your argument still leads to absurd results, even now that you've
> > modified it a few times already ...
>
> I hope you're not saying that my listening to you, recognizing
> mistakes in my arguments and fixing them up is a bad thing.
>
> But hey, at least I'm not modifying my arguments as much as you are!
> ;-)
>
> It's pretty easy to shoot a straw man and claim the original argument
> was broken.

Yep. I've done it to you on more than one occasion, Alexandre. The part that 
makes me laugh is that you still haven't realized it.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Rob Landley]

On Friday 15 June 2007 13:03:53 Linus Torvalds wrote:

> But does Red Hat actually give you *all* the rights they
> hold on the DVD? No, they definitely do not. They hold a
> compilation copyright on RHEL, and they very  much do *not*
> give you the right to copy the whole distribution and sell
> it as RHEL. You only get the rights to the individual
> pieces, not to the whole thing!

Technically what they're holding back is _trademark_ rights, which are a 
different area of IP law and not addressed by the GPL.  (I know you know 
this, but just for the record...)

The five main areas of IP law as I understand them are copyright, patent, 
trademark, contract, and trade secret.  Each of which is a different animal 
with a different legal foundation and different enabling legislation.  The 
GPL is a copyright license with some language about patents.  It is not based 
on contract law (although that's a common misperception that Lawrence Lessig 
and Eben Moglen have spent some effort debunking), and doesn't even mention 
trademarks.

So Red Hat isn't saying "you can use some of our copyrights but not others", 
last I heard all of their copyrights are licensed GPLv2 as a matter of 
corporate policy.  What you can't use is their trademarked name or logo, 
because they are explicitly refusing to license the trademarks to third 
parties.

And under GPLv2, this is allowed.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe 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

[Scott Preece]

On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:




How do these stop a user's exercise of the four freedoms of a piece of
software licensed under the GPL?

---

I know you don't see it that way, but I still find it bizarre that
"the right to modify the software" should be construed as "implies the
right to modify the device that the software was shipped in".

I do agree that it's not a change in "spirit" - I'm sure the GPL
authors would have disliked TiVoization 15 years ago as much as they
do today, if they had thought about it (regardless of the Stallman
interview where he said he didn't care very much about devices).

However, whether it is a change "in spirit" or not, it clearly is a
qualitative change that substantially changes the rights granted under
the license and it's perfectly reasonable for some authors who liked
the GPLv2 to dislike and reject GPLv3.

scott
-
To unsubscribe from this list: send the line "unsubscribe 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

[Daniel Hazelton]

On Friday 15 June 2007 19:39:57 Michael Gerdau wrote:
> > > > What matters is *my* intent in *choosing* the GPLv2, not *his*
> > > > intent in writing it.
> > >
> > > I beg to differ. By adopting _his_ license you adopted his view. [...]
> >
> > ianal, but fortunately that's not what the law is. The license says what
> > it says, and that is what controls. The intent of the author (of Linus
> > and other copyright holders) is a secondary source of information /if
> > and only if/ any ambiguity of meaning arises (as determined by a judge,
> > not by you or me). But the opinion and intent of RMS (unless adopted by
> > Linus) is quite immaterial.
>
> I agree with the "/if and only if/ any ambiguity of meaning arises" part.
> I'm sorry I didn't make that clear before.
>
> However if that situation arises (i.e. the judge decides there is an
> ambiguity) then as far as my experience tells me it is the intention of
> the author (RMS et al in this case) that counts. But I erred before...

I doubt this. In a situation like that the intent of the licensor is what 
matter, not the intent of the original author of the license.

DRH

> Best wishes,
> Michael



-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Scott Preece]

On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> * Daniel Hazelton <[EMAIL PROTECTED]> wrote:

That's correct, but with a catch: since the contract or license is
chosen by the licensor, in case of ambiguity in the terms, many courts
will interpret it in a way that privileges the licensee, regardless of
the fact that copyright licenses are to be interpreted restrictively
(at least in Brazilian law).  And IANAL ;-)

---

Hmm. In such a suit, however, the user would not be "the licensee" and
would not be a party to the suit - some author would be the plaintiff
and would be suing someone for doing something in violation of the
license that author granted - that is, the *defendant* would be the
licensee who would get the benefit of the doubt...

scott
-
To unsubscribe from this list: send the line "unsubscribe 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] Interesting race between cpufreq_ondemand and snd_atiixp

[Dave Jones]

On Sat, Jun 16, 2007 at 02:33:41AM +0300, S.Çağlar Onur wrote:

 > One of our colleagues found following problem with his old laptop while 
 > testing Linus's latest git with external alsa-driver (v1.0.14). And we can 
 > also reproduce same problem with 2.6.18.8 so it seems not a new regression 
 > (if it is a regression).
 > 
 > As a summary "sound stops to work if cpufreq_ondemand governor is used" on 
 > that laptop. Problem occurs only if cpufreq_* modules are loaded and %100 
 > reproducable if system configured for ondemand governor. 

I'm puzzled.  The cpuinfo shows that this cpu doesn't have speedstep, so
why acpi-cpufreq successfully loads is a mystery.

What's in/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies  ?

Maybe the acpi implementation is faking multiple speeds using throttling
a la p4-clockmod, which would be a bit loopy, but possible I guess.

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

[Scott Preece]

On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

On Jun 15, 2007, "Scott Preece" <[EMAIL PROTECTED]> wrote:

>> That's not true.  They can just as well throw the key away and refrain
>> from modifying the installed software behind the users' back.

> This characterization misses something important.  For many product
> devices, like cell phones, the modification is never "behind the
> user's back"

Okay, take out the "behind the users' back", it makes no difference.
That was just to highlight the frequent evil intentions behind keeping
the keys.

---

Yes, but in highlighting the possibility of evil intentions you
distort the fact that usually there are no such evil intentions...

---


I wonder if giving half the key to the user and keeping the other half
would be enough to satisfy the GPLv3 language while still enabling the
vendor and user to update the software together.

---

I think that's a possibility. I don't see how it's functionally
different from the usual case where the manufacturer can't modify the
device without the user's consent simply because the user has physical
access to the device and the manufacturer doesn't.

---


> The FSF's approval of this distinction (ROM versus replaceable) places
> the FSF's particular principles over users interests, for no
> particular reason

Over *users* interest?  How so?

---

Users benefit from the ability to get software updates, from the
manufacturer, to resolve problems, fix security vulnerabilities, and
provide updated functionality.

---


> if the manufacturer believes that it cannot legally allow software
> modification, all the restriction does is force them either to make
> the software unmodifiable (which advances freedom not at all) or to
> use software under a different license (which advances freedom not
> at all).

Right.


But if the manufacturer believes that it can legally allow it, and
wants to be able to install, software modifications, then it must
decide between giving that up and letting the user do it as well.  And
this is where the users interests may prevail.

---

You're harping on the "cannot legally", which is fine but irrelevant.
Whether it's a legal requirement or a business decision, the result is
the same - neither forcing the manufacturer to make the device
non-updatable nor forcing the manufacturer to use different software
benefits anyone. I don't know of interesting cases where the
manufacturer makes the device non-modifiable out of sheer
bloody-mindedness.

I don't believe that the existence of this clause will lead to more
manufacturers making their devices modifiable - there are too many
other options if they think that non-modifiability is important to
them.

[Note that I *do* think it's perfectly appropriate that authors who
feel that they don't want their work used in such devices should be
able to license them in line with that belief. I just don't think it
has any practical value aside from making them feel better.]

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

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching

[Tetsuo Handa]

Crispin Cowan wrote:
> In a smaller scale example, I want to share some files with a friend. I
> can't be bothered to set up a proper access control system, so I just mv
> the files to ~crispin/public_html/lookitme and in IRC say "get it now,
> going away in 10 minutes" and then move it out again. Yes, you can
> manually address this by running "restorecon ~crispin/public_html". But
> AA does this automatically without having to run any commands.
If you share ~crispin/public_html/lookitme by making a hard link,
does relabeling approach work?
I thought SELinux allows only one label for one file.
If AA (on the top of SELinux) tries to allow different permissions to
~crispin/public_html/lookitme and its original location,
either one of two pathnames won't be accessible as intended, will it?
-
To unsubscribe from this list: send the line "unsubscribe 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: My kernel hangs again: Help with git please

[Daniel Barkalow]

On Sat, 16 Jun 2007, Carlo Wood wrote:

> Therefore I have the following questions:
> 
> 1) What git command will ASSURE that I get the LATEST
>kernel tree checked out?
>
> I tried this:
> 
> hikaru:/usr/src/kernel/git/linux-2.6>git branch -l
> * bisect
>   master
>   origin
> hikaru:/usr/src/kernel/git/linux-2.6>git reset --hard HEAD

HEAD doesn't mean what you think it means. It's the latest revision on the 
branch with the *. What you want is:

$ git checkout master

This will move the * to "master", which shouldn't have been affected by 
any of this, and move your working directory to this point as well. At 
that point, you should be able to build a working kernel.

What "git reset --hard HEAD" does is discard any differences to tracked 
files between your working directory and the revision you're on. It's 
relevant if you want to discard local changes, not otherwise.

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

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 05:01:25PM -0700, [EMAIL PROTECTED] wrote:
>  On Fri, 15 Jun 2007, Greg KH wrote:
> 
> > On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> >> Greg KH wrote:
> >>> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
>  Only case where attacker _can't_ be keeping file descriptors is newly
>  created files in recently moved tree. But as you already create files
>  with restrictive permissions, that's okay.
> 
>  Yes, you may get some -EPERM during the tree move, but AA has that
>  problem already, see that "when madly moving trees we sometimes
>  construct path file never ever had".
> 
> >>> Exactly.
> >>>
> >> You are remembering old behavior. The current AppArmor generates only
> >> correct and consistent paths. If a process has an open file descriptor
> >> to such a file, they will retain access to it, as we described here:
> >> http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
> >>
> >> Under the restorecon-alike proposal, you have a HUGE open race. This
> >> post http://bugs.centos.org/view.php?id=1981 describes restorecon
> >> running for 30 minutes relabeling a file system. That is so far from
> >> acceptable that it is silly.
> >
> > Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
> > only problem we have here, it isn't an issue.
> 
>  how do you 'fix' the laws of physics?
> 
>  the problem is that with a directory that contains lots of files below it 
>  you have to access all the files metadata to change the labels on it. it can 
>  take significant amounts of time to walk the entire three and change every 
>  file.

Agreed, but you can do this in ways that are faster than others :)

> >>> I can't think of a "real world" use of moving directory trees around
> >>> that this would come up in as a problem.
> >> Consider this case: We've been developing a new web site for a month,
> >> and testing it on the server by putting it in a different virtual
> >> domain. We want to go live at some particular instant by doing an mv of
> >> the content into our public HTML directory. We simultaneously want to
> >> take the old web site down and archive it by moving it somewhere else.
> >>
> >> Under the restorecon proposal, the web site would be horribly broken
> >> until restorecon finishes, as various random pages are or are not
> >> accessible to Apache.
> >
> > Usually you don't do that by doing a 'mv' otherwise you are almost
> > guaranteed stale and mixed up content for some period of time, not to
> > mention the issues surrounding paths that might be messed up.
> 
>  on the contrary, useing 'mv' is by far the cleanest way to do this.
> 
>  mv htdocs htdocs.old;mv htdocs.new htdocs
> 
>  this makes two atomic changes to the filesystem, but can generate thousands 
>  to millions of permission changes as a result.

I agree, and yet, somehow, SELinux today handles this just fine, right?
:)

Let's worry about speed issues later on when a working implementation is
produced, I'm still looking for the logical reason a system like this
can not work properly based on the expected AA interface to users.

thanks,

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

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 05:18:10PM -0700, Seth Arnold wrote:
> On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > > We have built a label-based AA prototype. It fails because there is no
> > > reasonable way to address the tree renaming problem.
> > 
> > How does inotify not work here?  You are notified that the tree is
> > moved, your daemon goes through and relabels things as needed.  In the
> > meantime, before the re-label happens, you might have the wrong label on
> > things, but "somehow" SELinux already handles this, so I think you
> > should be fine.
> 
> SELinux does not relabel files when containing directories move, so it
> is not a problem they've chosen to face.
> 
> How well does inotify handle running attached to every directory on a
> typical Linux system?

Look at SLED and Beagle (taking the indexing logic out of the equation.)
It runs good enough that a major Linux vendor is willing to stake its
reputation on it :)

> > > Under the restorecon-alike proposal, you have a HUGE open race. This
> > > post http://bugs.centos.org/view.php?id=1981 describes restorecon
> > > running for 30 minutes relabeling a file system. That is so far from
> > > acceptable that it is silly.
> > 
> > Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
> > only problem we have here, it isn't an issue.
> 
> Restorecon traverses the filesystem from a specific down. In order to
> apply to an entire system (as would be necessary to try to emulate
> AppArmor's model using SELinux), restorecon would need to run on vast
> portions of the filesystem often. (mv ~/public_html ~/archived; or tar
> zxvf linux-*.tar.gz, etc.)
> 
> I'm not sure we need to run restorecon every time rename(2) is called.

Ok, so we optimize it.  Putting speed issues aside right now as a "mere"
implementation details, I'm looking for logical reasons the AA model
will not work in this type of system.

> > > Of course, this depends on the system in question, but restorecon will
> > > necessarily need to traverse whatever portions of the filesystem that
> > > have changed, which can be quite a long time indeed. Any race condition
> > > measured in minutes is a very serious issue.
> > 
> > Agreed, so we fix that.  There are ways to speed those kinds of things
> > up quite a bit, and I imagine since the default SELinux behavior doesn't
> > use restorecon in this kind of use-case, no one has spent the time to do
> > the work.
> 
> The time for restorecon is probably best imagined as a kind of 'du' that
> also updates extended attributes as it does its work. It'd be very
> difficult to improve on this.

Is that a bet?  :)

> > What "kernel memory and performance" issues are there?  Your SLED
> > machine already has inotify running on every directory in the system
> > today, and you don't seem to have noticed that :)
> 
> I beg to differ. :)

The Beagle index backend is known to slow things down at times, yes, but
is that the fault of the inotify watches, or the use of mono and a
big-ass database on the system at the same time?

In the original inotify development, the issue was not inotify at all,
unless you have some newer numbers in this regard?

And Crispin mentioned that you all already implemented this.  Do you
have the code around so that we can take a look at it?

thanks,

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

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

[Alexandre Oliva]

On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:

> * Alexandre Oliva <[EMAIL PROTECTED]> wrote:

>> On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> 
>> > it irreversibly cuts off certain people from being to distribute
>> > GPLv3-ed software alongside with certain types of hardware that the
>> > FSF's president does not like.

>> That's not true.  They can just as well throw the key away and refrain 
>> from modifying the installed software behind the users' back.

> uhm, so you claim that my argument is false, and your proof for that is 
> a "non-upgradeable Tivo"??  That is a _great_ idea. Not being 
> able to patch security holes. Not being able to fix bugs. Not being able 
> to add new features. Makes complete sense.

Oh, so you think patching security holes, fixing bugs and adding new
features are good ideas?  What if you can't do it in your TiVo?

>> > guess why this section has been completely removed from the GPLv3, 
>> > without a replacement?

>> My guess:

>> First, because it was redundant, given that the license didn't quite 
>> discuss other activities.  Unless you count say "imposing restrictions 
>> on the exercise of others' freedoms" as other activities, even though 
>> these are associated with modification and distribution.

> here you prove that you cannot even read what i wrote. I wrote that this 
> section has been removed from the GPLv3. What relevance does it have 
> that in your opinion this section was redundant in the GPLv2??

If you didn't mean "removed from the GPLv3 as compared with v2", I
misunderstood what you wrote.

The fact that it's redundant is v2 means it is reasonable to take it
out.  That's the relevance.

> It would clearly not be redundant in the GPLv3: it would contradict
> and _completely neutralize_ most of the crap from the GPLv3 that we
> are talking about here ...
 
And, per the same reasoning, some of the v2 provisions as well.

> dont you realize that declaring certain types of activities by hardware 
> makers as being "against freedom" is _exactly_ such an activity that the 
> GPLv2 did not attempt to control?

No.  And some Linux hackers disagree with your assessment too.

> censure, opression of free speech, out of control climate,
> dictatorship, campaign financing laws, the WIN32 API and human
> stupidity. By your argument we'd have to add prohibition against
> those restrictions of freedom to the license too, right?

-ENONSEQUITUR

How do these stop a user's exercise of the four freedoms of a piece of
software licensed under the GPL?

> Your argument still leads to absurd results, even now that you've
> modified it a few times already ...

I hope you're not saying that my listening to you, recognizing
mistakes in my arguments and fixing them up is a bad thing.

But hey, at least I'm not modifying my arguments as much as you are!
;-)

It's pretty easy to shoot a straw man and claim the original argument
was broken.

-- 
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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> >>Under the restorecon proposal, the web site would be horribly broken
> >>until restorecon finishes, as various random pages are or are not
> >>accessible to Apache.
> >
> >Usually you don't do that by doing a 'mv' otherwise you are almost
> >guaranteed stale and mixed up content for some period of time, not to
> >mention the issues surrounding paths that might be messed up.
> 
> on the contrary, useing 'mv' is by far the cleanest way to do this.
> 
> mv htdocs htdocs.old;mv htdocs.new htdocs
> 
> this makes two atomic changes to the filesystem, but can generate 
> thousands to millions of permission changes as a result.

Ok, so mv gets slower for big trees... and open() gets faster for deep
trees. Previously, open in current directory was one atomic read of
directory entry, now it has to read directory, and its parent, and its
parent parent, and its...

(Or am I wrong and getting full path does not need to bring anything
in, not even in cache-cold case?)

So, proposed solution has different performance tradeoffs, but should
still be a win -- opens are more common than moves.
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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Seth Arnold]

On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > We have built a label-based AA prototype. It fails because there is no
> > reasonable way to address the tree renaming problem.
> 
> How does inotify not work here?  You are notified that the tree is
> moved, your daemon goes through and relabels things as needed.  In the
> meantime, before the re-label happens, you might have the wrong label on
> things, but "somehow" SELinux already handles this, so I think you
> should be fine.

SELinux does not relabel files when containing directories move, so it
is not a problem they've chosen to face.

How well does inotify handle running attached to every directory on a
typical Linux system?

> > Under the restorecon-alike proposal, you have a HUGE open race. This
> > post http://bugs.centos.org/view.php?id=1981 describes restorecon
> > running for 30 minutes relabeling a file system. That is so far from
> > acceptable that it is silly.
> 
> Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
> only problem we have here, it isn't an issue.

Restorecon traverses the filesystem from a specific down. In order to
apply to an entire system (as would be necessary to try to emulate
AppArmor's model using SELinux), restorecon would need to run on vast
portions of the filesystem often. (mv ~/public_html ~/archived; or tar
zxvf linux-*.tar.gz, etc.)

I'm not sure we need to run restorecon every time rename(2) is called.

> > Of course, this depends on the system in question, but restorecon will
> > necessarily need to traverse whatever portions of the filesystem that
> > have changed, which can be quite a long time indeed. Any race condition
> > measured in minutes is a very serious issue.
> 
> Agreed, so we fix that.  There are ways to speed those kinds of things
> up quite a bit, and I imagine since the default SELinux behavior doesn't
> use restorecon in this kind of use-case, no one has spent the time to do
> the work.

The time for restorecon is probably best imagined as a kind of 'du' that
also updates extended attributes as it does its work. It'd be very
difficult to improve on this.

> What "kernel memory and performance" issues are there?  Your SLED
> machine already has inotify running on every directory in the system
> today, and you don't seem to have noticed that :)

I beg to differ. :)


pgpGrsoKQyWAQ.pgp
Description: PGP signature

[git patches] IDE fixes

[Bartlomiej Zolnierkiewicz]

Please pull from:

master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/

to receive the following updates:

 drivers/ide/ide.c   |9 ++---
 drivers/scsi/ide-scsi.c |2 +-
 2 files changed, 7 insertions(+), 4 deletions(-)


Bartlomiej Zolnierkiewicz (1):
  ide-scsi: fix OOPS in idescsi_expiry()

Rafael J. Wysocki (1):
  Resume from RAM on HPC nx6325 broken


diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
index 0af0d16..0cd76bf 100644
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -1010,7 +1010,6 @@ static int generic_ide_resume(struct device *dev)
 {
ide_drive_t *drive = dev->driver_data;
ide_hwif_t *hwif = HWIF(drive);
-   ide_driver_t *drv = to_ide_driver(dev->driver);
struct request rq;
struct request_pm_state rqpm;
ide_task_t args;
@@ -1033,8 +1032,12 @@ static int generic_ide_resume(struct device *dev)
 
err = ide_do_drive_cmd(drive, , ide_head_wait);
 
-   if (err == 0 && drv && drv->resume)
-   drv->resume(drive);
+   if (err == 0 && dev->driver) {
+   ide_driver_t *drv = to_ide_driver(dev->driver);
+
+   if (drv->resume)
+   drv->resume(drive);
+   }
 
return err;
 }
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index 8263f75..bb90df8 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -463,7 +463,7 @@ static inline unsigned long get_timeout(idescsi_pc_t *pc)
 
 static int idescsi_expiry(ide_drive_t *drive)
 {
-   idescsi_scsi_t *scsi = drive->driver_data;
+   idescsi_scsi_t *scsi = drive_to_idescsi(drive);
idescsi_pc_t   *pc   = scsi->pc;
 
 #if IDESCSI_DEBUG_LOG
-
To unsubscribe from this list: send the line "unsubscribe 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 patch] drivers/ide/ide-dma.c: unexport ide_set_dma

[Bartlomiej Zolnierkiewicz]

On Friday 15 June 2007, Adrian Bunk wrote:
> ide_set_dma no longer has any modular user.
> 
> Signed-off-by: Adrian Bunk <[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/

My kernel hangs again: Help with git please

[Carlo Wood]

Somewhere between 2.6.18 and 2.6.19, a patch was added to the
kernel that makes it hang on my machine after the message:

apgart: Detected an Intel 965G Chipset.

When I upgraded to 2.6.22-rc4 (from debian trunk), I still ran
into this same bug.

After installing git for the first time, I made my first
little steps with git - but it didn't get any further then
an attempt to mount my root because I had done my configuration
wrong (due the fact that libata seems to have moved).

Later, I managed to get the configuration right, compiled
HEAD (I think) and got a working 2.6.22-rc4 (+ patches).
I was very happy, and assumed that by coincidence the very
bug that was introduced shortly after 2.6.18 that made my
machine hang during boot, was fixed only two or so days
after I joined linux-kernel and installed git, somewhere
after 2.6.22-rc4 ... What a coincidence right?

Indeed, I thought it was a bit TOO much of a coincidence.
So I just HAD to see that patch that fixed the problem,
and I tried to used git bisect to find the patch that changes
the behaviour from a hang to a working kernel (that I am
now using to write this very mail).

Surprise: Nothing I try produces a working kernel anymore?!

Therefore I have the following questions:

1) What git command will ASSURE that I get the LATEST
   kernel tree checked out?
 
I tried this:

hikaru:/usr/src/kernel/git/linux-2.6>git branch -l
* bisect
  master
  origin
hikaru:/usr/src/kernel/git/linux-2.6>git reset --hard HEAD
hikaru:/usr/src/kernel/git/linux-2.6>git rev-list --max-count=1 bisect
c420bc9f09a0926b708c3edb27eacba434a4f4ba

And, assuming I have c420bc9f09a0926b708c3edb27eacba434a4f4ba at that
moment, then git reset --hard HEAD didn't do what I wanted: that is
namely -rc3 even! I can see THAT in the Makefile -- but whenever I
see -rc4 in the Makefile, that doesn't garantee in any way (apparently)
that I have the latest of the latest.

2) Is there some way to find back the exact version (git id)
from the .config, System.map and vmlinuz image (or /proc, since I can
boot it)? Because that is all I have left from the time that I managed
to create a working kernel :(

-- 
Carlo Wood <[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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Seth Arnold]

On Sat, Jun 16, 2007 at 01:39:14AM +0200, Pavel Machek wrote:
> > Pavel, please focus on the current AppArmor implementation. You're
> > remembering a flaw with a previous version of AppArmor. The pathnames
> > constructed with the current version of AppArmor are consistent and
> > correct.
> 
> Ok, I did not know that this got fixed.
> 
> How do you do that? Hold a lock preventing renames for a whole time
> you walk from file to the root of filesystem?

We've improved d_path() to remove many of its previous shortcomings:

eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1


pgp0HfqUd4Wd9.pgp
Description: PGP signature

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> >> Only case where attacker _can't_ be keeping file descriptors is newly
> >> created files in recently moved tree. But as you already create files
> >> with restrictive permissions, that's okay.
> >>
> >> Yes, you may get some -EPERM during the tree move, but AA has that
> >> problem already, see that "when madly moving trees we sometimes
> >> construct path file never ever had".
> >> 
> > Exactly.
> >   
> You are remembering old behavior. The current AppArmor generates only
> correct and consistent paths. If a process has an open file descriptor
> to such a file, they will retain access to it, as we described here:

Ok, so what I described was actually secure. Good.

> Under the restorecon-alike proposal, you have a HUGE open race. This
> post http://bugs.centos.org/view.php?id=1981 describes restorecon
> running for 30 minutes relabeling a file system. That is so far from
> acceptable that it is silly.

30 minutes during installation does not seem "silly" to me.

And that race does not make it insecure, because of the open file
descriptors. Good.

> Of course, this depends on the system in question, but restorecon will
> necessarily need to traverse whatever portions of the filesystem that
> have changed, which can be quite a long time indeed. Any race condition
> measured in minutes is a very serious issue.

You seem to imply it is security related, it is not. I can have open
files for hours or days.

> > I can't think of a "real world" use of moving directory trees around
> > that this would come up in as a problem.
> Consider this case: We've been developing a new web site for a month,
> and testing it on the server by putting it in a different virtual
> domain. We want to go live at some particular instant by doing an mv of
> the content into our public HTML directory. We simultaneously want to
> take the old web site down and archive it by moving it somewhere
> else.

And you do that exactly how, without the race? I do not think ve have
three_way_rename(name1, name2, name3) system call.

Notice that

1) mv can take minutes already if you move cross filesystem.

2) this is easily avoided by mv-ing somewhere with "same" permissons,
then doing quick moves when daemon is done.

> You could get restorecon to do this automatically by using inotify. But
> to make it as general and transparent as AA is now, you would have to
> run inotify on every directory in the system, with consequences for
> kernel memory and performance.

So you run inotify everywhere. IIRC beagle does it already.

> > Can anyone else see a problem with this that I'm just being foolish and
> > missing?
> >   
> It is not foolish. The label idea is so attractive that last September
> from discussions with Arjan we actually thought it was the preferred
> implementation. However, what we've been saying over and over again is
> that we *tried* this, and it *doesn't* work at the implementation level.
> There is no good answer, restorecon is an ugly kludge, and so this
> seductive approach turns out to be a dead end.

Talking about dead ends... "just put path-based security module into
kernel" recently got pretty strong "NACK" from Christoph Hellwig (see
TOMOYO Linux thread), and I believe there was similar comment from Al
Viro in past. That seems to me as dead-endy as it gets. "mv takes 30
minutes" is road slightly covered with bushes... compared to that.

So we can either forget about AA completely, or take a way Christoph
did not "NACK". restorecond is such a way, and with inotify it should
be acceptable. find does _not_ take that long, not even for git trees.

[EMAIL PROTECTED]:/data/l/linux$ time find . > /dev/null
0.04user 0.37system 11.50 (0m11.504s) elapsed 3.56%CPU

(If you wanted to be super-nice, you could introduce rename() helper
into glibc, that would do re-labeling synchronously, and only return
when it is done. All the nice applications call glibc anyway, and all
the exploits can't take advantage of it, because it is secure
already.).

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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Fri, 15 Jun 2007, Greg KH wrote:


On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:

Greg KH wrote:

On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:

Only case where attacker _can't_ be keeping file descriptors is newly
created files in recently moved tree. But as you already create files
with restrictive permissions, that's okay.

Yes, you may get some -EPERM during the tree move, but AA has that
problem already, see that "when madly moving trees we sometimes
construct path file never ever had".


Exactly.


You are remembering old behavior. The current AppArmor generates only
correct and consistent paths. If a process has an open file descriptor
to such a file, they will retain access to it, as we described here:
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf

Under the restorecon-alike proposal, you have a HUGE open race. This
post http://bugs.centos.org/view.php?id=1981 describes restorecon
running for 30 minutes relabeling a file system. That is so far from
acceptable that it is silly.


Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
only problem we have here, it isn't an issue.


how do you 'fix' the laws of physics?

the problem is that with a directory that contains lots of files below it 
you have to access all the files metadata to change the labels on it. it 
can take significant amounts of time to walk the entire three and change 
every file.



I can't think of a "real world" use of moving directory trees around
that this would come up in as a problem.

Consider this case: We've been developing a new web site for a month,
and testing it on the server by putting it in a different virtual
domain. We want to go live at some particular instant by doing an mv of
the content into our public HTML directory. We simultaneously want to
take the old web site down and archive it by moving it somewhere else.

Under the restorecon proposal, the web site would be horribly broken
until restorecon finishes, as various random pages are or are not
accessible to Apache.


Usually you don't do that by doing a 'mv' otherwise you are almost
guaranteed stale and mixed up content for some period of time, not to
mention the issues surrounding paths that might be messed up.


on the contrary, useing 'mv' is by far the cleanest way to do this.

mv htdocs htdocs.old;mv htdocs.new htdocs

this makes two atomic changes to the filesystem, but can generate 
thousands to millions of permission changes as a result.


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

[alan]

On Sat, 16 Jun 2007, Al Viro wrote:


On Fri, Jun 15, 2007 at 08:13:54PM -0300, Alexandre Oliva wrote:

On Jun 15, 2007, Chris Adams <[EMAIL PROTECTED]> wrote:


Obviously Linus feels that the spirit of the GPLv2 is exactly what
he wanted


spirit != letter.  He liked the letter.  He couldn't even tell spirit
from letter 2 or 3 days ago.

The spirit is the motivations behind the author of the license.
Anyone who thinks the motivations of RMS and the FSF are not defending
users' freedoms, as defined in the Free Software Definition, hasn't
been around for very long.


Aha.  I.e. "similar in spirit" means simply "written according to
motivations of RMS and FSF".  Which means, of course, that RMS and
FSF are the sole judges in that area.  There is just one problem:
it's not vague enough to be stated openly in the license.  Can't
scare the suckers away - that would reduce the user freedoms, right?


I always thought that the "Spirit of the GPL" runs around 180 proof and 
involves Laudanum.


--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
  - Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe 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 -rt] Fix TASKLET_STATE_SCHED WARN_ON()

[Oleg Nesterov]

On 06/15, john stultz wrote:
>
> On Fri, 2007-06-15 at 19:52 +0400, Oleg Nesterov wrote:
> > 
> > Could you please look at the message below? I sent it privately near a month
> > ago, but I think these problems are not fixed yet.
> 
> Hmm. Maybe you sent it to others on the cc list, as I can't find it in
> my box. But apologies anyway.

checking my mbox... Oops, you are right, sorry!

> > > + if (unlikely(atomic_read(>count))) {
> > > +out_disabled:
> > > + /* implicit unlock: */
> > > + wmb();
> > > + t->state = TASKLET_STATEF_PENDING;
> > 
> > What if tasklet_enable() happens just before this line ?
> > 
> > After the next schedule_tasklet() we have all bits set: SCHED, RUN, PENDING.
> > The next invocation of __tasklet_action() clears SCHED, but 
> > tasklet_tryunlock()
> > below can never succeed because of PENDING.
> 
> Yep. I've only been focusing on races in schedule/action, as I've been
> hunting issues w/ rcu. But I'll agree that the other state changes look
> problematic. I know Paul McKenney was looking at some of the other state
> changes and was seeing some potential problems as well.

OK, thanks. But doesn't this mean your 2-nd patch is questionable?

> +   } else {
> +   /* This is subtle. If we hit the corner case above
> +* It is possible that we get preempted right here,
> +* and another task has successfully called
> +* tasklet_schedule(), then this function, and
> +* failed on the trylock. Thus we must be sure
> +* before releasing the tasklet lock, that the
> +* SCHED_BIT is clear. Otherwise the tasklet
> +* may get its SCHED_BIT set, but not added to the
> +* list
> +*/
> +   if (!tasklet_tryunlock(t))
> +   goto again;

Again, tasklet_tryunlock() can fail because _PENDING was set by 
__tasklet_action().
In that case __tasklet_common_schedule() goes to the endless loop, no?

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe 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: [v4l-dvb-maintainer] drivers/media/dvb/dvb-core/dvb_net.c: check-after-use

[Trent Piepho]

On Fri, 15 Jun 2007, Adrian Bunk wrote:
> The Coverity checker spotted the following obvious check-after-use in
> drivers/media/dvb/dvb-core/dvb_net.c:

I spotted it before the patch was even applied:
http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2007-April/003917.html
If only coverity would get people to fix their bugs too.

I'm almost certain the check for !dvbdev ( = file->private_data) is not
necessary.

If you trace it, starting from the beginning:

dvb device is created:
dvbdev.c:425  cdev_init(_device_cdev, _device_fops);

dvb_device_fops defined:
dvbdev.c:117 static struct file_operations dvb_device_fops =
dvbdev.c:118 {
dvbdev.c:119 .owner =THIS_MODULE,
dvbdev.c:120 .open = dvb_device_open,
dvbdev.c:121 };

BTW, this struct should be const, no?  In fact, why not make it a static
local to "__init init_dvbdev()", the only place it's used?  That way it
will go into the init.data section, right?

Anyway, the relevant code for dvb_device_open:

dvbdev.c:87  static int dvb_device_open(struct inode *inode, struct file *file)
dvbdev.c:91  dvbdev = dvbdev_find_device (iminor(inode));
dvbdev.c:93  if (dvbdev && dvbdev->fops) {
dvbdev.c:101 file->private_data = dvbdev;
dvbdev.c:111 return err;
dvbdev.c:112 }
dvbdev.c:113 return -ENODEV;

So file->private_data must be non-NULL when the file is opened, or the open
function for the dvb device will return ENODEV.

The only code code in the dvb tree that assigns to private_data that I
could find is in the open function for dmx devices, and it doesn't apply to
dvb net devices and can't set private_data to NULL anyway.

So, if there file->private_data starts as non-NULL, and there is no code
that changes it, it can't ever be non-NULL, right?

BTW, I hate checks for a pointer being NULL if it's not actually part of
the design that the pointer can be NULL.  It just clutters the code, as
other programmers see the check and they need to handle the pointer being
NULL too.  And if there is a bug and the pointer is NULL, the check doesn't
fix the bug it just masks it.  The farther it is from a bug's cause to the
point it's detected, the harder it is to fix.

Here is a patch to fix it.  Actually, there is still a check-after-use
after the patch, but is Coverity smart enough to find it?

--
diff -r 2f04637aaea8 linux/drivers/media/dvb/dvb-core/dvb_net.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_net.cFri Jun 08 08:58:41 
2007 -0300
+++ b/linux/drivers/media/dvb/dvb-core/dvb_net.cFri Jun 15 15:34:08 
2007 -0700
@@ -1502,18 +1502,9 @@ static int dvb_net_close(struct inode *i
struct dvb_device *dvbdev = file->private_data;
struct dvb_net *dvbnet = dvbdev->priv;

-   if (!dvbdev)
-   return -ENODEV;
-
-   if ((file->f_flags & O_ACCMODE) == O_RDONLY) {
-   dvbdev->readers++;
-   } else {
-   dvbdev->writers++;
-   }
-
-   dvbdev->users++;
-
-   if(dvbdev->users == 1 && dvbnet->exit==1) {
+   dvb_generic_release(inode, file);
+
+   if(dvbdev->users == 1 && dvbnet->exit == 1) {
fops_put(file->f_op);
file->f_op = NULL;
wake_up(>wait_queue);
-
To unsubscribe from this list: send the line "unsubscribe 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: Fix memory/cpu hotplug section mismatch and oops.

[Linus Torvalds]

On Fri, 15 Jun 2007, Randy Dunlap wrote:

> On Fri, 15 Jun 2007 12:02:41 +0900 Paul Mundt wrote:
> 
> > On Thu, Jun 14, 2007 at 06:32:32PM +0900, Yasunori Goto wrote:
> > > Thanks. I tested compile with cpu/memory hotplug off/on.
> > > It was OK.
> > > 
> > > Acked-by: Yasunori Goto <[EMAIL PROTECTED]>
> > > 
> > It would be nice to have this for 2.6.22..
> 
> Yes, please.

I pushed out my tree that should include this one about ten minutes ago..

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

Re: [PATCH] Introduce compat_u64 and compat_s64 types

[Benjamin Herrenschmidt]

On Fri, 2007-06-15 at 07:45 -0600, Matthew Wilcox wrote:

> 
> $ ./test 
> offset of foo->x is 8
> offset of bar->x is 4

Looks to me like bar (that is compat_s64) is doing the right thing, no ?

Ben.


-
To unsubscribe from this list: send the line "unsubscribe 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

[Al Viro]

On Fri, Jun 15, 2007 at 08:13:54PM -0300, Alexandre Oliva wrote:
> On Jun 15, 2007, Chris Adams <[EMAIL PROTECTED]> wrote:
> 
> > Obviously Linus feels that the spirit of the GPLv2 is exactly what
> > he wanted
> 
> spirit != letter.  He liked the letter.  He couldn't even tell spirit
> from letter 2 or 3 days ago.
> 
> The spirit is the motivations behind the author of the license.
> Anyone who thinks the motivations of RMS and the FSF are not defending
> users' freedoms, as defined in the Free Software Definition, hasn't
> been around for very long.

Aha.  I.e. "similar in spirit" means simply "written according to
motivations of RMS and FSF".  Which means, of course, that RMS and
FSF are the sole judges in that area.  There is just one problem:
it's not vague enough to be stated openly in the license.  Can't
scare the suckers away - that would reduce the user freedoms, right?
-
To unsubscribe from this list: send the line "unsubscribe 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: raid5: coding style cleanup / refactor

[Dan Williams]

On 6/15/07, Neil Brown <[EMAIL PROTECTED]> wrote:

Good idea...  Am I asking too much to have separate things in separate
patches?  It makes review easier.


...yeah I got a little bit carried away after the refactoring.  I will
spin the refactoring out into a separate patch and handle the coding
style violations as you suggested.


NeilBrown


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

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> Greg KH wrote:
> > On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> >   
>  * Renamed Directory trees: The above problem is compounded with
>    directory trees. Changing the name at the top of a large, bushy
>    tree can require instant relabeling of millions of files.
>  
> >>> Same daemon can do this.  And yes, it might take a ammount of time, but
> >>> the times that this happens in "real-life" on a "production" server is
> >>> quite small, if at all.
> >>>   
> >> And now, if you move a tree, there will be old labels for a while. But
> >> this does not matter, because attacker could be keeping file
> >> descriptors.
> >> 
> > Agreed.
> >   
> We have built a label-based AA prototype. It fails because there is no
> reasonable way to address the tree renaming problem.

How does inotify not work here?  You are notified that the tree is
moved, your daemon goes through and relabels things as needed.  In the
meantime, before the re-label happens, you might have the wrong label on
things, but "somehow" SELinux already handles this, so I think you
should be fine.

> >> Only case where attacker _can't_ be keeping file descriptors is newly
> >> created files in recently moved tree. But as you already create files
> >> with restrictive permissions, that's okay.
> >>
> >> Yes, you may get some -EPERM during the tree move, but AA has that
> >> problem already, see that "when madly moving trees we sometimes
> >> construct path file never ever had".
> >> 
> > Exactly.
> >   
> You are remembering old behavior. The current AppArmor generates only
> correct and consistent paths. If a process has an open file descriptor
> to such a file, they will retain access to it, as we described here:
> http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
> 
> Under the restorecon-alike proposal, you have a HUGE open race. This
> post http://bugs.centos.org/view.php?id=1981 describes restorecon
> running for 30 minutes relabeling a file system. That is so far from
> acceptable that it is silly.

Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
only problem we have here, it isn't an issue.

> Of course, this depends on the system in question, but restorecon will
> necessarily need to traverse whatever portions of the filesystem that
> have changed, which can be quite a long time indeed. Any race condition
> measured in minutes is a very serious issue.

Agreed, so we fix that.  There are ways to speed those kinds of things
up quite a bit, and I imagine since the default SELinux behavior doesn't
use restorecon in this kind of use-case, no one has spent the time to do
the work.

> > I can't think of a "real world" use of moving directory trees around
> > that this would come up in as a problem.
> Consider this case: We've been developing a new web site for a month,
> and testing it on the server by putting it in a different virtual
> domain. We want to go live at some particular instant by doing an mv of
> the content into our public HTML directory. We simultaneously want to
> take the old web site down and archive it by moving it somewhere else.
> 
> Under the restorecon proposal, the web site would be horribly broken
> until restorecon finishes, as various random pages are or are not
> accessible to Apache.

Usually you don't do that by doing a 'mv' otherwise you are almost
guaranteed stale and mixed up content for some period of time, not to
mention the issues surrounding paths that might be messed up.

> In a smaller scale example, I want to share some files with a friend. I
> can't be bothered to set up a proper access control system, so I just mv
> the files to ~crispin/public_html/lookitme and in IRC say "get it now,
> going away in 10 minutes" and then move it out again. Yes, you can
> manually address this by running "restorecon ~crispin/public_html". But
> AA does this automatically without having to run any commands.

I'm saying that the daemon will automatically do it for you, you don't
have to do anything on your own.

> You could get restorecon to do this automatically by using inotify.

Yes.

> But to make it as general and transparent as AA is now, you would have
> to run inotify on every directory in the system, with consequences for
> kernel memory and performance.

What "kernel memory and performance" issues are there?  Your SLED
machine already has inotify running on every directory in the system
today, and you don't seem to have noticed that :)

> This problem does not exist for SELinux, because SELinux does not expect
> access to change based on file names.

Agreed.

> This problem does not exist in the proposed AA implementation, because
> the patch makes the access decision based on the current name of the
> file, so it doesn't have a consistency problem between the file and its
> label; there is no label.

No, that's not the issue here.  The 

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 05:42:08PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
> 
> > > Or just create the files with restrictive labels by default. That way
> > > you "fail closed".
> > 
> > From my limited knowledge of SELinux, this is the default today so this
> > would happen by default.  Anyone with more SELinux experience want to
> > verify or fix my understanding of this?
> 
> This is entirely controllable via policy.  That is, you specify that newly 
> create files are labeled to something safe (enforced atomically at the 
> kernel level), and then your userland relabeler would be invoked via 
> inotify to relabel based on your userland pathname specification.
> 
> This labeling policy can be as granular as you wish, from the entire 
> filesystem to a single file.  It can also be applied depending on the 
> process which created the file and the directory its created in, ranging 
> from all processes and all directories, to say, just those running as 
> user_t in directories labeled as public_html_t (or whatever).

Oh great, then things like source code control systems would have no
problems with new files being created under them, or renaming whole
trees.

So, so much for the "it's going to be too slow re-labeling everything"
issue, as it's not even required for almost all situations :)

thanks for letting us know.

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

Re: mm: Fix memory/cpu hotplug section mismatch and oops.

[Randy Dunlap]

On Fri, 15 Jun 2007 12:02:41 +0900 Paul Mundt wrote:

> On Thu, Jun 14, 2007 at 06:32:32PM +0900, Yasunori Goto wrote:
> > Thanks. I tested compile with cpu/memory hotplug off/on.
> > It was OK.
> > 
> > Acked-by: Yasunori Goto <[EMAIL PROTECTED]>
> > 
> It would be nice to have this for 2.6.22..

Yes, please.

---
~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: [PATCH] ext4:fix unexpected error from ext4_reserve_global

[Mingming Cao]

On Thu, 2007-06-14 at 19:29 +0400, Dmitriy Monakhov wrote:
> I just cant belive my eyes then i saw this at the first time...
> simple test: strace dd if=/dev/zero of=/mnt/file
> 
Thanks for reporting it. 

> open("/dev/zero", O_RDONLY) = 0
> close(1)= 0
> open("/mnt/test/file", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 1
> read(0, "\0\0\0\0\0\0\0\0\0"..., 512) = 512
> write(1, "\0\0\0\0\0\0\0\0"..., 512) = 512
> read(0, "\0\0\0\0\0\0\0\0\0"..., 512) = 512
> write(1, "\0\0\0\0\0\0\0\0"..., 512) = -1 ENOENT (No such fil
> e or directory)
> 
> This strange error returned from ext4_reserve_global().
> It's just typo because:
> a) In fact this is 100% ENOSPC situation
> b) simular function ext4_reserve_local() returns -ENOSPC
> 
I agree.

Patch is put in ext4 patch queue. Alex if you can Ack, that would be
great.


Thanks,

Mingming
> Signed-off-by: Dmitriy Monakhov <[EMAIL PROTECTED]>
> ---
>  fs/ext4/balloc.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index 4d7bfd2..43ae8f8 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -1920,7 +1920,7 @@ int ext4_reserve_global(struct super_block *sb, int 
> blocks)
>  {
>   struct ext4_sb_info *sbi = EXT4_SB(sb);
>   struct ext4_reservation_slot *rs;
> - int i, rc = -ENOENT;
> + int i, rc = -ENOSPC;
>   __u64 free = 0;
> 
>   rs = sbi->s_reservation_slots;

-
To unsubscribe from this list: send the line "unsubscribe 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: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 14 Jun 2007, Oleg Verych wrote:
> > 
> > I'm seeing this long (198) thread and just have no idea how it has
> > ended (wiki? hand-mailing?).
> 
> I'm hoping it's not "ended".
> 
> IOW, I really don't think we _resolved_ anything, although the work that 
> Adrian started is continuing through the wiki and other people trying to 
> track regressions, and that was obviously something good.
> 
> But I don't think we really know where we want to take this thing in the 
> long run. I think everybody wants a better bug-tracking system, but 
> whether something that makes people satisfied can even be built is open. 
> It sure doesn't seem to exist right now ;)

The problem is not the bug tracking system, be it manual tracking in a 
text file or a Wiki or be it in Bugzilla or any other bug tracking 
system.

One problem is the lack of experienced developers willing to debug bug 
reports.

But what really annoyed me was the missing integration of regression 
tracking into the release process, IOW how _you_ handled the regression 
lists.

If we want to offer something less of a disaster than 2.6.21, and if we 
want to encourage people to start and continue testing -rc kernels, we 
must try to fix as many reported regressions as reasonably possible.

This means going through every single point in the regression list 
asking "Have we tried everything possible to solve this regression?". 
There are very mysterious regressions and there are regressions that 
might simply be reported too late. But if at the time of the final 
release 3 week old regressions hadn't been debugged at all there's 
definitely room for improvement. And mere mortals like me reminding 
people is often not enough, sometimes an email by Linus Torvalds himself 
asking a patch author or maintainer to look after a regression might be 
required.

And a low hanging fruit to improve the release would be if you could 
release one last -rc, wait for 48 hours, and then release either this 
-rc unchanged as -final or another -rc (and wait another 48 hours).
There were at least two different regressions people ran into in 2.6.21 
who successfully tested -rc7.

>   Linus

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> > Yes, you may get some -EPERM during the tree move, but AA has that
> > problem already, see that "when madly moving trees we sometimes
> > construct path file never ever had".
> 
> Pavel, please focus on the current AppArmor implementation. You're
> remembering a flaw with a previous version of AppArmor. The pathnames
> constructed with the current version of AppArmor are consistent and
> correct.

Ok, I did not know that this got fixed.

How do you do that? Hold a lock preventing renames for a whole time
you walk from file to the root of filesystem?
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 Gerdau]

> > > What matters is *my* intent in *choosing* the GPLv2, not *his* 
> > > intent in writing it.
> > 
> > I beg to differ. By adopting _his_ license you adopted his view. [...]
> 
> ianal, but fortunately that's not what the law is. The license says what 
> it says, and that is what controls. The intent of the author (of Linus 
> and other copyright holders) is a secondary source of information /if 
> and only if/ any ambiguity of meaning arises (as determined by a judge, 
> not by you or me). But the opinion and intent of RMS (unless adopted by 
> Linus) is quite immaterial.

I agree with the "/if and only if/ any ambiguity of meaning arises" part.
I'm sorry I didn't make that clear before.

However if that situation arises (i.e. the judge decides there is an
ambiguity) then as far as my experience tells me it is the intention of
the author (RMS et al in this case) that counts. But I erred before...

Best wishes,
Michael
-- 
 Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar
 Sitz Hamburg; HRB 89145 Amtsgericht Hamburg
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau   email: [EMAIL PROTECTED]
 GPG-keys available on request or at public keyserver


signature.asc
Description: This is a digitally signed message part.

Re: [RFC] [PATCH] selective signal ptracing

[Roland McGrath]

> That might make sense if utrace ever looked like it would solve the
> questions about platforms like ARM

It certainly will.  The only difficult limitations have been in
communication and understanding.  Please don't perpetuate a generic red
herring without adding any content to the subject.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe 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 4/6] ps3: Disk Storage Driver

[David Miller]

From: James Bottomley <[EMAIL PROTECTED]>
Date: Fri, 15 Jun 2007 16:28:03 -0700

> On Fri, 2007-06-15 at 16:08 -0700, David Miller wrote:
> > From: James Bottomley <[EMAIL PROTECTED]>
> > Date: Fri, 15 Jun 2007 15:40:42 -0700
> > 
> > > On Fri, 2007-06-15 at 14:19 -0700, David Miller wrote:
> > > > Another quirk I have to deal with is that under LDOMs you
> > > > can export full disks and also just slices.  So I'll have
> > > > to get down into the partition machinery to support that
> > > > somehow.
> > > 
> > > For this, it sounds like you might find nbd a more enticing
> > > proposition ... it already is partition independent and is basically a
> > > block to net socket exporter.
> > 
> > That's not gonna work, it's a totally different model.
> > 
> > I have a predefined protocol over hypervisor provided "channels" and
> > page flipping also done by the hypervisor for the bulk data transfer.
> > For the client side I cannot change the hypervisor nor the server
> > speaking on the other end.  And when I do write a server I do want
> > it to be able to speak to all of the existing clients.
> > 
> > There's SCSI command pass through as well, as I keep mentioning as
> > it's an important reason I don't want to go with any of the non-SCSI
> > solutions (other than perhaps ATA) being suggested.
> 
> Then sure, use SCSI ... the ibmvscsi client originally talked to some
> type of hypervisor interface too before IBM extracted it and open
> sourced the server.  If actual SCSI commands are going in somewhere ...
> be it a real device, a RAID firmware emulation or a hypervisor input,
> then I'm happy with the driver being in SCSI.

For normal block I/O it's just raw copies over the provided protocol.

But the service exports a service by which raw SCSI commands can be
sent, for things like disk fault probing and stuff like that.  It's
not for block I/O, it's for "all the funny stuff" scsi comands are
used for outside of actual data transfers.
-
To unsubscribe from this list: send the line "unsubscribe 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] Interesting race between cpufreq_ondemand and snd_atiixp

[S.Çağlar Onur]

16 Haz 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı: 
...
> 3. echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
^^^ performance

Sorry for typo!

>strace -o log -f -tttTTT mpg123 some.mp3
>
> works without a problem [full log @ 3]

Cheers
-- 
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


signature.asc
Description: This is a digitally signed message part.

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

[Alexandre Oliva]

> * Daniel Hazelton <[EMAIL PROTECTED]> wrote:

>> > My experience with german courts has shown me that the judges I had 
>> > to deal with always and foremost did apply a reality check and did 
>> > not try to bisect the consequences like an algorithm evaluated by a 
>> > machine, i.e. the tried to decide what is right and wrong and not 
>> > whether the letter of the contract could be twisted this or that 
>> > way.

>> This is the way it should be. However, the letter of the contract, in 
>> this case, is very clear and that hasn't stopped Herr Welte at all.

And this is the beauty of a multi-author project.  Even if some
authors think that the license permits something, if any of them
understands it doesn't, he can try to enforce that WRT his own
contributions.  So those exploiting the gray areas of the license can
still get caught.

On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:

> btw., still ianal, but the GPLv2 is not a "contract" but a "pure 
> copyright license". A contract, almost by definition is a restriction of 
> rights in exchange for consideration - while if you accept the license 
> of a GPLv2-ed work this act only gives rights that you did not have 
> before.

In Brazil, this is kind of contract/license is called a beneficial
contract.

> Furthermore when you get source code of free software then there 
> is no "meeting of minds" needed for you to accept the GPL's conditions, 
> and only the letter of the license (and, in case of any ambiguities, the 
> intent of the author of the code) matters to the interpretation of the 
> license, not the intent of the recipient.

That's correct, but with a catch: since the contract or license is
chosen by the licensor, in case of ambiguity in the terms, many courts
will interpret it in a way that privileges the licensee, regardless of
the fact that copyright licenses are to be interpreted restrictively
(at least in Brazilian law).  And IANAL ;-)

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

[BUG] Interesting race between cpufreq_ondemand and snd_atiixp

[S.Çağlar Onur]

Hi;

One of our colleagues found following problem with his old laptop while 
testing Linus's latest git with external alsa-driver (v1.0.14). And we can 
also reproduce same problem with 2.6.18.8 so it seems not a new regression 
(if it is a regression).

As a summary "sound stops to work if cpufreq_ondemand governor is used" on 
that laptop. Problem occurs only if cpufreq_* modules are loaded and %100 
reproducable if system configured for ondemand governor. 

Here are the steps to reproduce the problem on that laptop;

1. Boot system with cpufreq_* modules blacklisted
   strace -o log -f -tttTTT mpg123 some.mp3

works without a problem [full log @ 1]

2. modprobe cpufreq_ondemand
   echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
   strace -o log -f -tttTTT mpg123 some.mp3

hangs and no sound at all [full log @ 2]

3. echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
   strace -o log -f -tttTTT mpg123 some.mp3

works without a problem [full log @ 3]

And with both 2.6.18.8 and 2.6.22-rc4 KDE (artsd) starts to gave "Operation 
not denied" errors on login, and after that error occured stracing mpg123 
from console gaves following output (the very same check of semctl fails with 
EINTR with second) [full log @ 4];
 
...
4004  1181948891.899907 semget(5678293, 1, IPC_CREAT|0660) = 1081344 
<0.10>
4004  1181948891.899945 semctl(1081344, 0, IPC_64|IPC_STAT, 0xbfd1b498) = 0 
<0.09>
4004  1181948891.899981 semctl(1081344, 0, IPC_64|IPC_SET, 0xbfd1b498) = -1 
EPERM (Operation not permitted) <0.09>
4004  1181948891.900026 semop(1081344, 0xbfd1b6a0, 2) = -1 EINTR (Interrupted 
system call) <15.979441>
4004  1181948907.879574 --- SIGTERM (Terminated) @ 0 (0) ---
4004  1181948907.879782 +++ killed by SIGTERM +++

You can also find dmesg [5], lspci -vv [6], lsmod [7], /proc/cpuinfo 
[8], /proc/interrupts [9] and used .config [10] from there.

I have also a physical access to that laptop so please just ask if you want 
anything else.

[1] http://cekirdek.pardus.org.tr/~caglar/kernel/working
[2] http://cekirdek.pardus.org.tr/~caglar/kernel/notworking
[3] http://cekirdek.pardus.org.tr/~caglar/kernel/againworking
[4] http://cekirdek.pardus.org.tr/~caglar/kernel/perm
[5] http://cekirdek.pardus.org.tr/~caglar/kernel/dmesg_2.6.22
[6] http://cekirdek.pardus.org.tr/~caglar/kernel/lspci
[7] http://cekirdek.pardus.org.tr/~caglar/kernel/lsmod_2.6.22
[8] http://cekirdek.pardus.org.tr/~caglar/kernel/cpuinfo
[9] http://cekirdek.pardus.org.tr/~caglar/kernel/interrupts
[10] http://cekirdek.pardus.org.tr/~caglar/kernel/config

Cheers
-- 
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


signature.asc
Description: This is a digitally signed message part.

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Seth Arnold]

On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Yes, you may get some -EPERM during the tree move, but AA has that
> problem already, see that "when madly moving trees we sometimes
> construct path file never ever had".

Pavel, please focus on the current AppArmor implementation. You're
remembering a flaw with a previous version of AppArmor. The pathnames
constructed with the current version of AppArmor are consistent and
correct.

Thanks.


pgpfRKJ2MwcJ7.pgp
Description: PGP signature

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Crispin Cowan]

Greg KH wrote:
> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
>   
 * Renamed Directory trees: The above problem is compounded with
   directory trees. Changing the name at the top of a large, bushy
   tree can require instant relabeling of millions of files.
 
>>> Same daemon can do this.  And yes, it might take a ammount of time, but
>>> the times that this happens in "real-life" on a "production" server is
>>> quite small, if at all.
>>>   
>> And now, if you move a tree, there will be old labels for a while. But
>> this does not matter, because attacker could be keeping file
>> descriptors.
>> 
> Agreed.
>   
We have built a label-based AA prototype. It fails because there is no
reasonable way to address the tree renaming problem.

>> Only case where attacker _can't_ be keeping file descriptors is newly
>> created files in recently moved tree. But as you already create files
>> with restrictive permissions, that's okay.
>>
>> Yes, you may get some -EPERM during the tree move, but AA has that
>> problem already, see that "when madly moving trees we sometimes
>> construct path file never ever had".
>> 
> Exactly.
>   
You are remembering old behavior. The current AppArmor generates only
correct and consistent paths. If a process has an open file descriptor
to such a file, they will retain access to it, as we described here:
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf

Under the restorecon-alike proposal, you have a HUGE open race. This
post http://bugs.centos.org/view.php?id=1981 describes restorecon
running for 30 minutes relabeling a file system. That is so far from
acceptable that it is silly.

Of course, this depends on the system in question, but restorecon will
necessarily need to traverse whatever portions of the filesystem that
have changed, which can be quite a long time indeed. Any race condition
measured in minutes is a very serious issue.

> I can't think of a "real world" use of moving directory trees around
> that this would come up in as a problem.
Consider this case: We've been developing a new web site for a month,
and testing it on the server by putting it in a different virtual
domain. We want to go live at some particular instant by doing an mv of
the content into our public HTML directory. We simultaneously want to
take the old web site down and archive it by moving it somewhere else.

Under the restorecon proposal, the web site would be horribly broken
until restorecon finishes, as various random pages are or are not
accessible to Apache.

In a smaller scale example, I want to share some files with a friend. I
can't be bothered to set up a proper access control system, so I just mv
the files to ~crispin/public_html/lookitme and in IRC say "get it now,
going away in 10 minutes" and then move it out again. Yes, you can
manually address this by running "restorecon ~crispin/public_html". But
AA does this automatically without having to run any commands.

You could get restorecon to do this automatically by using inotify. But
to make it as general and transparent as AA is now, you would have to
run inotify on every directory in the system, with consequences for
kernel memory and performance.

This problem does not exist for SELinux, because SELinux does not expect
access to change based on file names.

This problem does not exist in the proposed AA implementation, because
the patch makes the access decision based on the current name of the
file, so it doesn't have a consistency problem between the file and its
label; there is no label.

The problem is induced by trying to emulate AA on top of SELinux. They
don't fit well together. AA fits much better with LSM, which is the
reason LSM exists.

>   Maybe a source code control
> system might have this issue for the server, but in a second or two
> everything would be working again as the new files would be relabled
> correctly.
>   
Try an hour or two for a large source code repository. Its linear in the
number of files, and several hundred thousand files would take a while
to relabel. A large GIT tree would be particularly painful because of
the very large number of files.

> Can anyone else see a problem with this that I'm just being foolish and
> missing?
>   
It is not foolish. The label idea is so attractive that last September
from discussions with Arjan we actually thought it was the preferred
implementation. However, what we've been saying over and over again is
that we *tried* this, and it *doesn't* work at the implementation level.
There is no good answer, restorecon is an ugly kludge, and so this
seductive approach turns out to be a dead end.

Caveat: I am *not* saying that labels in general are bad, just that they
are a bad way to emulate the AppArmor model. And yes, I am working on a
model paper that is more abstract than Andreas' paper
,
but that takes time.

Re: PC speaker

[Phillip Susi]

Jan Engelhardt wrote:

On Jun 15 2007 13:07, Phillip Susi wrote:

R.F. Burns wrote:

However, over the past several weeks, the students have found more
creative ways to abuse the PC speaker (outside of the OS.)  The Powers
that Be are asking that the PC speakers be disabled completely.  With
the small number of techs we have, it would be very impractical to go
around to all systems and remove the PC speaker from each and every
computer case.

Now I am curious; how are they getting the pc speaker to make any sound with
the kernel module disabled?


ioperm(), inb(), and outb() from userspace. Needs root, though. Or 
/dev/port, with write. Which comes to the question how they gained root. 
Perhaps live cd? In which case, the OP should, as recommended in this 
thread already, deactivate choosing boot devices, if that's possible.


(Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or so, 
but I have not seen a way to deactivate _that_ menu.)


He already said they don't have root access and that allowed him to stop 
them from accessing the sound card by setting appropriate permissions.


-
To unsubscribe from this list: send the line "unsubscribe 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 4/6] ps3: Disk Storage Driver

[James Bottomley]

On Fri, 2007-06-15 at 16:08 -0700, David Miller wrote:
> From: James Bottomley <[EMAIL PROTECTED]>
> Date: Fri, 15 Jun 2007 15:40:42 -0700
> 
> > On Fri, 2007-06-15 at 14:19 -0700, David Miller wrote:
> > > Another quirk I have to deal with is that under LDOMs you
> > > can export full disks and also just slices.  So I'll have
> > > to get down into the partition machinery to support that
> > > somehow.
> > 
> > For this, it sounds like you might find nbd a more enticing
> > proposition ... it already is partition independent and is basically a
> > block to net socket exporter.
> 
> That's not gonna work, it's a totally different model.
> 
> I have a predefined protocol over hypervisor provided "channels" and
> page flipping also done by the hypervisor for the bulk data transfer.
> For the client side I cannot change the hypervisor nor the server
> speaking on the other end.  And when I do write a server I do want
> it to be able to speak to all of the existing clients.
> 
> There's SCSI command pass through as well, as I keep mentioning as
> it's an important reason I don't want to go with any of the non-SCSI
> solutions (other than perhaps ATA) being suggested.

Then sure, use SCSI ... the ibmvscsi client originally talked to some
type of hypervisor interface too before IBM extracted it and open
sourced the server.  If actual SCSI commands are going in somewhere ...
be it a real device, a RAID firmware emulation or a hypervisor input,
then I'm happy with the driver being in SCSI.

James


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

Re: [2/2] 2.6.22-rc4: known regressions v3

[Linus Torvalds]

On Wed, 13 Jun 2007, Michal Piotrowski wrote:
> 
> Subject: hibernate(?) fails totally - regression
> References : http://lkml.org/lkml/2007/6/1/401
> Submitter  : David Greaves <[EMAIL PROTECTED]>
> Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]>
> Caused-By  : Tejun Heo <[EMAIL PROTECTED]>
> commit 9666f4009c22f6520ac3fb8a19c9e32ab973e828
> Status : problem is being debugged

Ahh. This is fixed (fix by Tejun, confirmed by David), and the fix has 
been merged. It's commit bc90ba093a, in case anybody cares.

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

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Bartlomiej Zolnierkiewicz]

On Tuesday 12 June 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
> >>On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> >>>On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
> 
> It can be changed via /proc/ide/hd?/settings.
> 
> >>>Why do we need to change IDE DMA timeout dynamically?
> 
> >>I've used it to test error recovery (for example).
> 
> > Seems quite useable for developers but I would prefer not to
> > expose it in production kernels for end users.
> 
> It seems that I have counter example of a customer asking if this timeout 
> can be done configurable. :-)

May I ask what was the rationale for this request?

I have no strong feelings about adding this /proc/ide/ setting but I worry
that it could be (mis)used just to (unreliably) work-around problems...

> BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA 
> is 
> not complete or interrupt pending, it may wait 10 more secs...

I really don't remember... :)

Maybe Mark or Alan could help with figuring this out.

Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe 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] ide: add short cables support

[Bartlomiej Zolnierkiewicz]

On Friday 15 June 2007, Sergei Shtylyov wrote:
> Hello.
> 
> Bartlomiej Zolnierkiewicz wrote:
> 
> > This patch allows users to override both host and device side cable 
> > detection
> > with "ideX=ata66" kernel parameter.  Thanks to this it should be now 
> > possible
> > to use UDMA > 2 modes on systems (laptops mainly) which use short 40-pin 
> > cable
> > instead of 80-pin one.
> 
> > Next patches add automatic detection of some systems using short cables.
> 
> > Changes:
> 
> > * Rename hwif->udma_four to hwif->cbl and make it u8.
> 
> Not sure if already short word "cable" was worth further shortening. :-)

The name/usage is the same as in libata.

When we add ->cable_detect method it will make grepping easier. 8)

> > Index: b/drivers/ide/pci/alim15x3.c
> > ===
> > --- a/drivers/ide/pci/alim15x3.c
> > +++ b/drivers/ide/pci/alim15x3.c
> > @@ -594,7 +594,7 @@ out:
> >   * FIXME: frobs bits that are not defined on newer ALi devicea
> >   */
> >  
> > -static unsigned int __devinit ata66_ali15x3 (ide_hwif_t *hwif)
> > +static u8 __devinit ata66_ali15x3(ide_hwif_t *hwif)
> >  {
> > struct pci_dev *dev = hwif->pci_dev;
> > unsigned int ata66  = 0;
> > @@ -657,7 +657,7 @@ static unsigned int __devinit ata66_ali1
> >  
> > local_irq_restore(flags);
> >  
> > -   return(ata66);
> > +   return ata66 ? ATA_CBL_PATA80 : ATA_CBL_PATA40;
> 
> Ahem... I'd think it was about the right time to fix the abomination which
> those ata66 and cable_80_pin[2] are, something like this:
> 
> static unsigned int __devinit ata66_ali15x3 (ide_hwif_t *hwif)
> {
>  struct pci_dev *dev = hwif->pci_dev;
>  unsigned int cbl= ATA_CBL_PATA40;
>  unsigned long flags;
>  u8 tmpbyte, mask = hwif->channel ? 0x02 : 0x01;
> 
>  local_irq_save(flags); /* Not sure if it's necessary... */
> 
>  if (m5229_revision >= 0xC2) {
>  /*
>   * Ultra66 cable detection (from Host View)
>   * m5229, 0x4a, bit0: primary, bit1: secondary
>* 0: 80 pin, 1: 40 pin
>   */
>  pci_read_config_byte(dev, 0x4a, );
>  /*
>   * Allow ata66 if cable of current channel has 80 pins
>   */
>  cbl = (tmpbyte & mask) ? ATA_CBL_PATA40 : ATA_CBL_PATA80;
>  } else {
> 
> [Following code frankly speaking has no business being in this function]

patch #3/5 already takes care of cable_80_pin[2] part,
ata66 part was left as an exercise for the reader ;-)

>  local_irq_restore(flags); /* Not sure if it's necessary... */
> 
>   return cbl;
> >  }
> >  
> >  /**
> > Index: b/drivers/ide/pci/serverworks.c
> > ===
> > --- a/drivers/ide/pci/serverworks.c
> > +++ b/drivers/ide/pci/serverworks.c
> > @@ -329,9 +329,9 @@ static unsigned int __devinit init_chips
> > return dev->irq;
> >  }
> >  
> > -static unsigned int __devinit ata66_svwks_svwks (ide_hwif_t *hwif)
> > +static u8 __devinit ata66_svwks_svwks(ide_hwif_t *hwif)
> >  {
> > -   return 1;
> > +   return ATA_CBL_PATA80;
> >  }
> 
> Hm, worth folding into ata66_svwks()...

Yes and no...

Alan did a very nice rewrite of cable detection code for pata_serverworks.c
driver.  We may be better off just back-porting it (patches are welcomed).

> >  /* On Dell PowerEdge servers with a CSB5/CSB6, the top two bits
> > @@ -341,7 +341,7 @@ static unsigned int __devinit ata66_svwk
> >   * Bit 14 clear = primary IDE channel does not have 80-pin cable.
> >   * Bit 14 set   = primary IDE channel has 80-pin cable.
> >   */
> > -static unsigned int __devinit ata66_svwks_dell (ide_hwif_t *hwif)
> > +static u8 __devinit ata66_svwks_dell(ide_hwif_t *hwif)
> >  {
> > struct pci_dev *dev = hwif->pci_dev;
> > if (dev->subsystem_vendor == PCI_VENDOR_ID_DELL &&
> 
> Isn't this check duplicating the check in ata66_svwks()?

Yep.

> > @@ -359,18 +359,18 @@ static unsigned int __devinit ata66_svwk
> >   *
> >   * WARNING: this only works on Alpine hardware!
> >   */
> > -static unsigned int __devinit ata66_svwks_cobalt (ide_hwif_t *hwif)
> > +static u8 __devinit ata66_svwks_cobalt(ide_hwif_t *hwif)
> >  {
> > struct pci_dev *dev = hwif->pci_dev;
> > if (dev->subsystem_vendor == PCI_VENDOR_ID_SUN &&
> 
> Same question here...

Yep.

> > Index: b/drivers/ide/pci/sis5513.c
> > ===
> > --- a/drivers/ide/pci/sis5513.c
> > +++ b/drivers/ide/pci/sis5513.c
> > @@ -796,7 +796,7 @@ static unsigned int __devinit init_chips
> > return 0;
> >  }
> >  
> > -static unsigned int __devinit ata66_sis5513 (ide_hwif_t *hwif)
> > +static u8 __devinit ata66_sis5513(ide_hwif_t *hwif)
> >  {
> > u8 ata66 = 0;
> >  
> > @@ -811,7 +811,8 @@ static unsigned int __devinit ata66_sis5
> > 

Re: [PATCH] never called printk statement in ide-taskfile.c::wait_drive_not_busy

[Bartlomiej Zolnierkiewicz]

Hi,

On Tuesday 05 June 2007, Masatake YAMATO wrote:
> > On 06/04/2007 10:21 PM, Masatake YAMATO wrote:
> > > diff --git a/drivers/ide/ide-taskfile.c b/drivers/ide/ide-taskfile.c
> > > index 30175c7..5e05311 100644
> > > --- a/drivers/ide/ide-taskfile.c
> > > +++ b/drivers/ide/ide-taskfile.c
> > > @@ -249,7 +249,7 @@ static u8 wait_drive_not_busy(ide_drive_t *drive)
> > >   while (((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) && retries--)
> > >   udelay(10);
> > >  
> > > - if (!retries)
> > > + if (retries < 0)
> > 
> > if (stat & BUSY_STAT)
> > 
> > >   printk(KERN_ERR "%s: drive still BUSY!\n", drive->name);
> > >  
> 
> Oh, yes.
> Giving `retries' both roles: loop counter and condition flag for logging
> may not good.
> 
> 
> for (retries = 0; retries < 100; retries++)
> {
>   if ((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT)
>  break;
> 
>   udelay(10);
> }
> 
> 
> if (stat & BUSY_STAT)
>   printk(KERN_ERR "%s: drive still BUSY!\n", drive->name);

Please re-submit this fix in the form of a patch so I can merge it.

Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe 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: Re: PATCH: udf fs corruption on linux-2.6

[Linus Torvalds]

On Fri, 15 Jun 2007, Jan Kara wrote:
>
>   My fix for this problem is already sitting in Andrew's patch queue
> (http://lkml.org/lkml/2007/6/11/79). Rich's patch still has a problem - you
> cannot call udf_discard_prealloc() from drop_inode() because it is called
> under inode_lock and thus you cannot call e.g. mark_inode_dirty(). I've done
> that mistake too ;). So please don't apply the patch.

Ok, dropped, will depend on Andrew to forward it to me. It may miss the 
(already late) -rc5 I was hoping to release today, but I'll cc Andrew on 
this, and maybe I'll get disorganized and just end up delaying -rc5 even 
more ;)

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: [RFC] [PATCH] selective signal ptracing

[Alan Cox]

On Fri, 15 Jun 2007 12:42:29 -0700 (PDT)
Roland McGrath <[EMAIL PROTECTED]> wrote:

> I am not in favor of any enhancements to the ptrace interface.
> It is a terrible interface and just needs to die.

That might make sense if utrace ever looked like it would solve the
questions about platforms like ARM
-
To unsubscribe from this list: send the line "unsubscribe 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 15, 2007, "Scott Preece" <[EMAIL PROTECTED]> wrote:

> On 6/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> 
>> > it irreversibly cuts off certain people from being to distribute
>> > GPLv3-ed software alongside with certain types of hardware that the
>> > FSF's president does not like.
>> 
>> That's not true.  They can just as well throw the key away and refrain
>> from modifying the installed software behind the users' back.

> This characterization misses something important.  For many product
> devices, like cell phones, the modification is never "behind the
> user's back"

Okay, take out the "behind the users' back", it makes no difference.
That was just to highlight the frequent evil intentions behind keeping
the keys.

I wonder if giving half the key to the user and keeping the other half
would be enough to satisfy the GPLv3 language while still enabling the
vendor and user to update the software together.

> The FSF's approval of this distinction (ROM versus replaceable) places
> the FSF's particular principles over users interests, for no
> particular reason

Over *users* interest?  How so?

> if the manufacturer believes that it cannot legally allow software
> modification, all the restriction does is force them either to make
> the software unmodifiable (which advances freedom not at all) or to
> use software under a different license (which advances freedom not
> at all).

Right.


But if the manufacturer believes that it can legally allow it, and
wants to be able to install, software modifications, then it must
decide between giving that up and letting the user do it as well.  And
this is where the users interests may prevail.

-- 
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: regression tracking (Re: Linux 2.6.21)

[Linus Torvalds]

On Thu, 14 Jun 2007, Oleg Verych wrote:
> 
> I'm seeing this long (198) thread and just have no idea how it has
> ended (wiki? hand-mailing?).

I'm hoping it's not "ended".

IOW, I really don't think we _resolved_ anything, although the work that 
Adrian started is continuing through the wiki and other people trying to 
track regressions, and that was obviously something good.

But I don't think we really know where we want to take this thing in the 
long run. I think everybody wants a better bug-tracking system, but 
whether something that makes people satisfied can even be built is open. 
It sure doesn't seem to exist right now ;)

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

[Alexandre Oliva]

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

> On Friday 15 June 2007 17:24:24 Alexandre Oliva wrote:
>> On Jun 15, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
>> >> PS: Note that Stallmans motivation was *SOURCE* *CODE* *ACCESS* -
>> >> nothing else.

>> Not, it was to be able to modify the behavior of the printer, and he
>> needed the source code in order to do that.  Even for a tivoized
>> printer, this would be enough, understanding that the signature is a
>> functional portion and thus the corresponding sources must be
>> included.

> You totally ignored all the evidence to the contrary, and have made use of 
> clever, circular logic. He needed access to the code to make a modification 
> he'd made for other printers.

As in, he gets the source code, makes the change and, voila, problem
solved, except that the printer still doesn't do what he needs?

And I'm the one ignoring evidence?

-- 
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 15, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> I've looked through the GPLv3 and "tivoization" and DRM are the only things 
> that are functionally different. In reading the GPLv3 *again* today I got the 
> impression that there are more restrictions than grants of rights.

http://fsfla.org/svnwiki/blogs/lxo/draft/gplv3-snowwhite discusses
each one of the significant changes (and some of the insignificant
ones) and shows why each one of them is more "tit-for-tat" than v2.

-- 
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 15, 2007, Chris Adams <[EMAIL PROTECTED]> wrote:

> Obviously Linus feels that the spirit of the GPLv2 is exactly what
> he wanted

spirit != letter.  He liked the letter.  He couldn't even tell spirit
from letter 2 or 3 days ago.

The spirit is the motivations behind the author of the license.
Anyone who thinks the motivations of RMS and the FSF are not defending
users' freedoms, as defined in the Free Software Definition, hasn't
been around for very long.

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

[Alan Cox]

> And the preamble, not being part of the active portion of the license, has 
> absolutely *ZERO* bearing. Just as it is not the *intent* of RMS, the FSF or 

Wrong (again)

The pre-amble is incredibly important as is the intent of the license
creator and even more so of the author.

When trying to solve a dispute the process starts with the legal
equivalent of banging the two parties head together in the hope they see
sense. If that fails then the legal wording is considered in detail.
Where it is ambiguous the surrounding context is considered in order to
understand the probable intent of the case.

Finally the stated intent of the author is considered in defence (The
doctrine of estoppel), and at least in UK law whether their intent was
honest (The doctrine of clean hands)

Legal disputes almost always end up about the things that are not clear
(if they were clear one side would shut up and put up) so the preambles
and statements are terribly important when this occurs, along with the
context and history.

Thus for example the fact Linus has said he believes what Tivo does is ok
means he can no longer sue Tivo for doing it. They are relying on his
promise.

Alan
-
To unsubscribe from this list: send the line "unsubscribe 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 15, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> On Friday 15 June 2007 15:49:00 Alexandre Oliva wrote:
>> On Jun 15, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
>> > On Thursday 14 June 2007 23:19:24 Alexandre Oliva wrote:
>> >> IANAL, but AFAICT it doesn't.  Still, encoded in the spirit (that
>> >> refers to free software, bringing in the free software definition), is
>> >> the notion of protecting users' freedoms, among them the freeom #0, to
>> >> run the software for any purpose.
>> >
>> > And where in GPLv2 is "Freedom #0"?
>> 
>> It may sound like thin evidence for someone arriving from Venus today,
>> but the preamble talks about "free software", some passages clearly
>> imply that software under this license is "free software", the license
>> is published by the Free Software Foundation, and the Free Software
>> Foundation has a published definition of Free Software that
>> establishes the 4 freedoms.

> And that doesn't matter.

Doens't matter for what?

To indicate what the Linux copyright holders meant?  Sure it doesn't.
I never claimed it did.

To indicate what the authors of the GPL meant?  To indicate the spirit
of the license they wrote?  Yes, it matters a lot.

And the latter is what my participation here is all about: to show
that the spirit didn't change at all.

Until you acknowledge and understand this, I should refrain from
answering your other postings.

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