On Mon, Sep 17, 2007 at 09:09:06AM -0700, Sean Hefty ([EMAIL PROTECTED]) wrote:
> >>>+addr = kmalloc(sizeof *addr, GFP_KERNEL);
> >>
> >>As a small nitpick: this wants to be sizeof(struct in_ifaddr)
>
> See chapter 14 of CodingStyle document. kmalloc(sizeof *addr... is correct.
Come on, do
On Mon, Sep 17, 2007 at 08:25:14AM -0700, David Schwartz wrote:
>
> > And if you choose the GPL the code you distribute will be under the GPL
> > *only* forever [1], so what value would be in shipping terms that are
> > void?
>
> Not true. You cannot chose the license that applies to other
On Mon, 2007-09-17 at 10:31 +0200, Avi Kivity wrote:
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index cfda3ab..6d25826 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -474,6 +474,14 @@ struct kvm_arch_ops {
>
> extern struct kvm_arch_ops *kvm_arch_ops;
>
> +/* The
>-Original Message-
>From: Jesper Juhl [mailto:[EMAIL PROTECTED]
>Sent: Sunday, September 16, 2007 2:32 PM
>To: linux-kernel@vger.kernel.org
>Cc: Nelson, Shannon; Leech, Christopher; Jesper Juhl
>Subject: [PATCH] Remove an unused variable from the Intel
>I/OAT DMA engine driver
>
>
+addr = kmalloc(sizeof *addr, GFP_KERNEL);
As a small nitpick: this wants to be sizeof(struct in_ifaddr)
See chapter 14 of CodingStyle document. kmalloc(sizeof *addr... is correct.
- Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
The do_split() function for htree dir blocks is intended to split a
leaf block to make room for a new entry. It sorts the entries in the
original block by hash value, then moves the last half of the entries to
the new block - without accounting for how much space this actually moves.
(IOW, it
On Mon, 2007-09-17 at 18:16 +0400, Pavel Emelyanov wrote:
> Trond Myklebust wrote:
> > On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
> >> When the process is blocked on mandatory lock and someone changes
> >> the inode's permissions, so that the lock is no longer mandatory,
> >>
The following might be a bug in git-send-email (git maintainers Cc'ed
and KVM list removed from Cc):
Patch 54 got the same Message-Id as patch 61 and patch 89 got the same
Message-Id as patch 104.
That's not legal, and users who automatically filter duplicate emails
based on the Message-Id
> When using OFED-1.2.5 based infiniband kernel modules on 2.6.22 based
> kernels with the Ingo Molnar CONFIG_PREEMPT_RT applied, then commands
> such as ibnetdiscvoer, smpquery, sminfo, etc. will hang. The problem
> is with the downgrade_write() rw semaphore usage in the
> ib_umad_close()
Lukas Hejtmanek wrote:
Hello,
is it expected that application sending 8900bytes datagram through 10Gbps NIC
utilizes CPU to 100% and similarly the receiver also utilizes CPU to 100%.
Is it something wrong or this is quite OK?
(The box is dual single core Opteron 2.4GHz with Myricom 10GE NIC.)
On Mon, Sep 17, 2007 at 05:15:05PM +0200, Paul de Weerd wrote:
> On Mon, Sep 17, 2007 at 03:38:45PM +0200, Adrian Bunk wrote:
> | It's not about lazyness of BSD developers, many people who consider the
> | BSD licence more free than the GPL argue that the advantage of the BSD
> | licence is that
Chuck Ebbert wrote:
>
> Still fails. And apparently fails on disk 0, because it hangs right
> after printing a zero:
>
> --- linux-2.6.22.noarch.orig/arch/i386/boot/edd.c
> +++ linux-2.6.22.noarch/arch/i386/boot/edd.c
> @@ -151,6 +151,7 @@ void query_edd(void)
> * Scan the
Stephen Rothwell wrote:
> On Tue, 11 Sep 2007 18:56:53 -0700 [EMAIL PROTECTED] wrote:
>> Convert cpu_sibling_map to a per_cpu cpumask_t array for the ppc64
>> architecture. This fixes build errors in block/blktrace.c and
>> kernel/sched.c when CONFIG_SCHED_SMT is defined.
>>
>> Note: these
Huang, Ying wrote:
> This patch defines a 32-bit boot protocol and adds corresponding
> document.
> +
> +In addition to read/modify/write kernel header of the zero page as
> +that of 16-bit boot protocol, the boot loader should fill the
> +following additional fields of the zero page too.
> +
>
Huang, Ying wrote:
> This patch add a field of 64-bit physical pointer to NULL terminated
> single linked list of struct setup_data to real-mode kernel
> header. This is used to define a more extensible boot parameters
> passing mechanism.
You MUST NOT add a field like this without changing the
David Howells <[EMAIL PROTECTED]> wrote:
> (1) Permit one process to change another process's cred struct. This means
> that a process wishing to read its own creds must use RCU read to do so,
> and a lock must be held when replacing the cred struct.
Having thought about this some
> And if you choose the GPL the code you distribute will be under the GPL
> *only* forever [1], so what value would be in shipping terms that are
> void?
Not true. You cannot chose the license that applies to other people's code. The
code you distribute contains protectable elements from
Evgeniy Polyakov wrote:
Hi Steve.
On Sat, Sep 15, 2007 at 10:56:46AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
The iWARP driver must translate all listens on address 0.0.0.0 to the
set of rdma-only ip addresses for the device in question. This prevents
incoming connect requests to the
On Mon, Sep 17, 2007 at 03:38:45PM +0200, Adrian Bunk wrote:
| It's not about lazyness of BSD developers, many people who consider the
| BSD licence more free than the GPL argue that the advantage of the BSD
| licence is that it does not require you to give back.
|
| Something is wrong if your
When using OFED-1.2.5 based infiniband kernel modules on 2.6.22 based
kernels with the Ingo Molnar CONFIG_PREEMPT_RT applied, then commands
such as ibnetdiscvoer, smpquery, sminfo, etc. will hang. The problem is
with the downgrade_write() rw semaphore usage in the ib_umad_close()
routine.
Theodore Tso writes:
> Now, you don't need a licence from the original author to use
> the derived work. The author of the derived work only needs
> a licence from the original author to create a derived work.
> Do you think Microsoft users have licences from authors of
> the works MS Windows
On 09/14/2007 12:06 PM, H. Peter Anvin wrote:
> Chuck Ebbert wrote:
>> I added debugging code to print a letter for each step in i386 setup,
>> and it gets to 'J', then it hangs:
>>
>> /* Query EDD information */
>> #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
>>
On Mon, Sep 17, 2007 at 10:37:56AM +0400, Pavel Emelyanov wrote:
> J. Bruce Fields wrote:
> > Is there a small chance that a lock may be applied after this check:
> >
> >> + mandatory = (inode->i_flock && MANDATORY_LOCK(inode));
> >> +
> >
> > but early enough that someone can still block on
On Mon, 17 Sep 2007, Randy Dunlap wrote:
>
> OK, I haven't done the microcode update yet. I ran crashme overnight
> with your newer patch and it crashed:
Well, duh.
That's because I forgot to do the "error_code & PF_USER" =>
"user_mode_vm(regs)" thing in the most common case - the
On 9/17/07, Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> The __mandatory_lock(inode) macro makes the same check, but
> makes the code more readable.
>
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> Acked-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
>
> ---
>
> fs/9p/vfs_file.c |2 +-
>
On Tuesday 18 September 2007 00:09, Anton Altaparmakov wrote:
> On 17 Sep 2007, at 15:04, Anton Altaparmakov wrote:
> > On 15 Sep 2007, at 11:52, Andrew Morton wrote:
> >> On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra
> >>
> >> <[EMAIL PROTECTED]> wrote:
> >>> Anyway, looks like all of
Maciej W. Rozycki wrote:
> SCSI is a generic peripheral bus
No, not anymore. http://www.t10.org/scsi-3.htm
> (recall the expansion of the acronym).
The expansion of the acronym doesn't fit anymore to what SCSI is today,
or even to what it became already circa 10 years ago.
> Even though
Adrian Bunk <[EMAIL PROTECTED]> writes:
> Or that
> "OpenBSD != Linux kernel"
>
> was wrong since although they are not equal, they are related since they
> are both open source operating systems.
BTW: never heard someone is using the FreeBSD version of Linux?
I did, not once :-)
--
I have also seen this OOPS on e1000 card. So, looks like driver independent.
By the way, this one has been triggered in a semi-stable way by the
'git-pull'
Regards,
Den
Dhaval Giani wrote:
> On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
>> I have an Oops that may be
On Mon, 17 Sep 2007 15:28:19 +0200
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 15 2007, FUJITA Tomonori wrote:
> > On Fri, 14 Sep 2007 21:16:35 -0700
> > Paul Jackson <[EMAIL PROTECTED]> wrote:
> >
> > > FUJITA Tomonori wrote:
> > > > Can you try this patch (against 2.6.23-rc4-mm1)?
> >
On 9/17/07, Francis Moreau <[EMAIL PROTECTED]> wrote:
> Does that mean we'll need to keep 3 different implementations of gtod
> in the kernel forever ?
That's a question for the kernel maintainers to answer.
> I think signal trampolines will still need them too. So making
> vsyscalls
On Mon, 17 Sep 2007 15:04:05 +0100 Anton Altaparmakov <[EMAIL PROTECTED]>
wrote:
> They files
> are attached this time rather than inlined so people don't complain
> about line wrapping! (No doubt people will not complain about them
> being attached! )-:)
I switched mailer after I learnt
Ivan Kokshaysky wrote:
On Sun, Sep 16, 2007 at 01:52:59PM -0600, Matthew Wilcox wrote:
I don't think it would be that complicated. We could just delay probing
for mmconfig until after the pci bus probes are done. No changes to
other architectures needed.
Indeed. Seems like it's a way to go.
> The real contents of 32-bit boot protocol patch is is in another 2 mails
> with the title:
>
> [RFC -mm 1/2] i386/x86_64 boot: setup data
> [RFC -mm 2/2] i386/x86_64 boot: document for 32 bit boot protocol
>
> The EFI patch in this mail is just an example of 32-bit boot protocol
> usage.
Linus Torvalds wrote:
On Sun, 16 Sep 2007, Randy Dunlap wrote:
I'll test this overnight on 2.6.23-rc6-git2 since that was failing.
I haven't been able to reproduce the fault on 2.6.21 after several
hours of testing.
I'll also test a microcode update to see if it helps.
Before you do the
Trond Myklebust wrote:
> On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
>> When the process is blocked on mandatory lock and someone changes
>> the inode's permissions, so that the lock is no longer mandatory,
>> nobody wakes up the blocked process, but probably should.
>
> Please
On 9/17/07, David Howells <[EMAIL PROTECTED]> wrote:
> A better way would be to compare fsuid/fsgid to uid/gid and to just take an
> extra ref on the incumbent cred object if they're the same, rather than always
> allocating a new one. That, I suspect, would speed up 99.99% of the cases.
Indeed.
On Mon, 2007-09-17 at 19:36 +0530, Ram wrote:
> Hi,
>
>I am trying to write a driver which uses double, float. I am using
> an arm11 with gcc 3.4.4
>
>When i try to compile my modules (with float variables) i get the error
>
>WARNING: "__extendsfdf2" undefined!
>WARNING:
Hi,
On 9/17/07, Ram <[EMAIL PROTECTED]> wrote:
> Hi,
>
>I am trying to write a driver which uses double, float. I am using
> an arm11 with gcc 3.4.4
>
>When i try to compile my modules (with float variables) i get the error
>
>WARNING: "__extendsfdf2" undefined!
>WARNING:
* Jos Poortvliet <[EMAIL PROTECTED]> wrote:
> On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Rob Hussey <[EMAIL PROTECTED]> wrote:
> >
> > > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
> >
> > heh - am i the only one impressed by the consistency of
On Mon, Sep 17, 2007 at 01:22:28AM -0700, J.C. Roberts wrote:
>...
> Saying something like:
> "Linux Kernel != FSF/GNU"
>
> is quite similar to saying:
> "Windows != Microsoft"
>
> In both cases, the pairs of terms may not be "equal" but they are
> certainly related. Also in both
On 17 Sep 2007, at 15:04, Anton Altaparmakov wrote:
On 15 Sep 2007, at 11:52, Andrew Morton wrote:
On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra
<[EMAIL PROTECTED]> wrote:
Anyway, looks like all of zone_normal is pinned in kernel
allocations:
Sep 13 15:31:25 escabot Normal free:3648kB
Hi,
I am trying to write a driver which uses double, float. I am using
an arm11 with gcc 3.4.4
When i try to compile my modules (with float variables) i get the error
WARNING: "__extendsfdf2" undefined!
WARNING: "__mulsf3"undefined!
WARNING: "__fixsfsi"undefined!
WARNING:
On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
> I have an Oops that may be related:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 0025
> printing eip: c037d81b *pde =
> Oops: [#1]
> last sysfs file:
On 15 Sep 2007, at 11:52, Andrew Morton wrote:
On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra
<[EMAIL PROTECTED]> wrote:
Anyway, looks like all of zone_normal is pinned in kernel
allocations:
Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB
high: 5616kB active:0kB
On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rob Hussey <[EMAIL PROTECTED]> wrote:
>
> > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
>
> heh - am i the only one impressed by the consistency of the blue line in
> this graph? :-) [ and the green line
* Beauchemin, Mark <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> Any thoughts on the patch?
looks good to me - but it has a number of style issues, please run it
through scripts/checkpatch.pl to see those.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Sun, 2007-09-16 at 18:15 +1000, Nick Piggin wrote:
> On Saturday 15 September 2007 20:22, Soeren Sonnenburg wrote:
> > On Sat, 2007-09-15 at 09:47 +, Soeren Sonnenburg wrote:
>
> > > Memtest did not find anything after 16 passes so I finally stopped
> it
> > > applied your patch and used
>
On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
> When the process is blocked on mandatory lock and someone changes
> the inode's permissions, so that the lock is no longer mandatory,
> nobody wakes up the blocked process, but probably should.
Please explain in more detail why we need
On Mon, Sep 17, 2007 at 09:33:52AM -0400, Jason Dixon wrote:
> On Sep 17, 2007, at 9:27 AM, Sean <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 17 Sep 2007 09:15:31 -0400
>> Jason Dixon <[EMAIL PROTECTED]> wrote:
>>
>>> Sure it does. My code under BSD license continues to remain free,
>>> regardless of
On Monday 17 September 2007 19:18, Avi Kivity wrote:
> Avi Kivity wrote:
> > Christoph Hellwig wrote:
> >> On Mon, Sep 17, 2007 at 10:30:43AM +0200, Avi Kivity wrote:
> >>> From: Nguyen Anh Quynh <[EMAIL PROTECTED]>
> >>>
> >>> *nopage() in kvm_main.c should only store the type of mmap() fault if
Hannah Schroeter <[EMAIL PROTECTED]> writes:
> Right. You may add nearly any copyright *on your own significant
> additions/changes*.
Such as a patch? Hardly IMHO, a patch is not a work but an output
of an automated tool. The copyright is not about fragments of works.
You may add a copyright
On Mon, Sep 17, 2007 at 11:20:19AM +0200, Hannah Schroeter wrote:
> Hi!
Hi Hannah!
> On Sun, Sep 16, 2007 at 11:13:51PM +0200, Adrian Bunk wrote:
> >On Sun, Sep 16, 2007 at 10:39:26PM +0200, Hannah Schroeter wrote:
> >> On Sun, Sep 16, 2007 at 09:59:09PM +0200, Adrian Bunk wrote:
> >> >On Sun,
On Mon, Sep 17, 2007 at 02:55:54PM +0200, Claudio Jeker wrote:
> Wohoho! Slow here please. NDA have nothing to do with licenses and
> especially with copyright. NetApp even though their stuff is under their
> copyright and license does hopefully not modify the copyrights of imported
> BSD/ISC
On Sep 17, 2007, at 9:27 AM, Sean <[EMAIL PROTECTED]> wrote:
On Mon, 17 Sep 2007 09:15:31 -0400
Jason Dixon <[EMAIL PROTECTED]> wrote:
Sure it does. My code under BSD license continues to remain free,
regardless of what Company X(1) does with their *copy* of my code.
The only restrictions on
Jacob Meuser wrote:
when I see the linux community start to take credit for works they
did not create and I see the linux community respond to warnings
that people in the community are going overboard and jeopardizing
the linux community, which we do all benefit from, with a more or
less
On Sat, Sep 15 2007, FUJITA Tomonori wrote:
> On Fri, 14 Sep 2007 21:16:35 -0700
> Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> > FUJITA Tomonori wrote:
> > > Can you try this patch (against 2.6.23-rc4-mm1)?
> > >
> > > >From 592bd2049cb3e6e1f1dde7cf631879f26ddffeaa Mon Sep 17 00:00:00 2001
> > >
On Mon, 17 Sep 2007 09:15:31 -0400
Jason Dixon <[EMAIL PROTECTED]> wrote:
> Sure it does. My code under BSD license continues to remain free,
> regardless of what Company X(1) does with their *copy* of my code.
> The only restrictions on my code is that copyright and attribution
> must
On Monday 17 September 2007 14:07, David Chinner wrote:
> On Fri, Sep 14, 2007 at 06:48:55AM +1000, Nick Piggin wrote:
> > OK, the vunmap batching code wipes your TLB flushing and IPIs off
> > the table. Diffstat below, but the TLB portions are here (besides that
> > _everything_ is probably
Ingo,
Any thoughts on the patch?
Thanks,
Mark
-Original Message-
From: Beauchemin, Mark
Sent: Tuesday, August 07, 2007 3:42 PM
To: 'Ingo Molnar'
Cc: Thomas Gleixner; linux-kernel@vger.kernel.org; David Miller
Subject: RE: [PATCH -rt] Preemption problem in kernel RT
Am Montag 17 September 2007 15:15 schrieb Jason Dixon:
>
> The GPL places additional restrictions on code. It is therefore less
> free than the BSD.
>
> Free code + restrictions = non-free code.
The legal restriction that people must not enter your house uninvited
by smashing the door adds
Make request_key() and co fundamentally asynchronous to make it easier for NFS
to make use of them. There are now accessor functions that do asynchronous
constructions, a wait function to wait for construction to complete, and a
completion function for the key type to indicate completion of
I agree, this is probably somehow related with SiS chipset - my laptop
has one of these SiS 760 host controllers inside.
I'll probably do some digging to figure out if this is indeed chipset
related. I wonder if this error occurs under Windows (Win does not
report much, yet it's kernel must be
On Sat, 2007-09-15 at 01:43 +1000, Greg Banks wrote:
> On Fri, Sep 14, 2007 at 10:58:38AM -0400, Jeff Layton wrote:
> > If Irix isn't clearing these bits
> > on a write then it might be good to see if they can fix that...
>
> I think first you'd have to mount a serious argument that it's broken,
On Sep 17, 2007, at 8:57 AM, Adrian Bunk wrote:
On Mon, Sep 17, 2007 at 11:30:11AM +0200, Henning Brauer wrote:
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-09-17 02:29]:
you claim that it's unethical for the linux community to use the
code, but
brag about NetApp useing the code. what makes
On Tue, 18 Sep 2007, Konstantin Sharlaimov wrote:
I am experiencing the similar problem on my Acer Aspire 5000 laptop -
once in a while a bunch of "APIC error on CPU0: 40(40)" messages are
showing up in dmesg.
After few experiments and a lot of googling, I identified a cause - it
was my
I am experiencing the similar problem on my Acer Aspire 5000 laptop -
once in a while a bunch of "APIC error on CPU0: 40(40)" messages are
showing up in dmesg.
After few experiments and a lot of googling, I identified a cause - it
was my built-in wireless card! Disabling IO-APIC helped, besides a
On Sat, Sep 15, 2007 at 01:36:19AM -0700, Andrew Morton wrote:
> I just did a successful gcc-4.1.0 alpha allmodconfig build with 2.6.23-rc5
> plus 44 patches which are in or are targetted for 2.6.23:
Yeah, things seem to be in better shape now.
-
To unsubscribe from this list: send the line
* Rob Hussey <[EMAIL PROTECTED]> wrote:
> http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
heh - am i the only one impressed by the consistency of the blue line in
this graph? :-) [ and the green line looks a bit like a .. staircase? ]
i've meanwhile tested
Hi Andrew,
Kernel Bug is hit with 2.6.23-rc4-mm1 kernel on ppc64 machine.
kernel BUG at include/linux/netdevice.h:339!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in: ipv6 binfmt_misc dm_mirror dm_mod sr_mod sg st
NIP: c035e980 LR:
On Sun, Sep 16, 2007 at 05:12:08PM -0400, Theodore Tso wrote:
> On Sun, Sep 16, 2007 at 10:39:26PM +0200, Hannah Schroeter wrote:
> > >The most questionable legal advice in this thread was by Theo de Raadt
> > >who claimed choosing one licence for _dual-licenced_ code was illegal...
> >
> >
On Saturday 15 September 2007 04:08, Christoph Lameter wrote:
> On Fri, 14 Sep 2007, Nick Piggin wrote:
> > However fsblock can do everything that higher order pagecache can
> > do in terms of avoiding vmap and giving contiguous memory to block
> > devices by opportunistically allocating higher
On Monday 17 September 2007 04:13, Mel Gorman wrote:
> On (15/09/07 14:14), Goswin von Brederlow didst pronounce:
> > I keep coming back to the fact that movable objects should be moved
> > out of the way for unmovable ones. Anything else just allows
> > fragmentation to build up.
>
> This is
On Saturday 15 September 2007 20:22, Soeren Sonnenburg wrote:
> On Sat, 2007-09-15 at 09:47 +, Soeren Sonnenburg wrote:
> > Memtest did not find anything after 16 passes so I finally stopped it
> > applied your patch and used
> >
> > CONFIG_DEBUG_SLAB=y
> > CONFIG_DEBUG_SLAB_LEAK=y
> >
> >
On Saturday 15 September 2007 03:52, Christoph Lameter wrote:
> On Fri, 14 Sep 2007, Nick Piggin wrote:
> > > > [*] ok, this isn't quite true because if you can actually put a hard
> > > > limit on unmovable allocations then anti-frag will fundamentally help
> > > > -- get back to me on that when
On Mon, Sep 17, 2007 at 11:30:11AM +0200, Henning Brauer wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-09-17 02:29]:
> > you claim that it's unethical for the linux community to use the code, but
> > brag about NetApp useing the code. what makes NetApp ok and Linux evil?
>
> NetApp
Johannes Berg wrote:
> On Sa, 2007-09-15 at 21:00 +0200, Eric Valette wrote:
>
>
>> I came to this conclusion too. But I would have preferred to have
>> #define subsys_exit(fn) modules_exit(fn)
>>
>> in the case of a module and nop in the non module case...
>>
>
>
> Do *you* read the GPL and tell me where exactly it does *explicitly*
> allow to change license notices at all. Ya know, that right is reserved
> by law and must be *explicitly* granted. So just not explicitly
> forbidding it isn't enough.
You are mistaken about the law and mistaken about the
On Mon, Sep 17, 2007 at 01:18:05PM +0200, Hannah Schroeter wrote:
> >So for code which is single-licensed under a BSD license, someone can
> >create a new derived work, and redistribute it under a more
> >restrictive license --- either one as restrictive as NetApp's (where
> >no one is allowed to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Satyam Sharma wrote:
> I don't have access to any real/meaningful SMP systems, so I wonder
> how much sense it makes in practical terms for me to try and run these
> tests locally on my little boxen ... would be helpful if someone with
> 4/8 CPU
"Can E. Acar" <[EMAIL PROTECTED]> writes:
> Do you believe re-arranging code, renaming functions, splitting code
> to multiple files, adding some adaptation code is original enough
> to be a derivative work and deserve its own copyright?
"Deserve"? The copyright is automatic, the author (of the
Hannah Schroeter wrote:
> The original issue *was* about illegal relicensing (i.e. not just
> choosing which terms to follow, but removing the other terms
> altogether).
You are confusing two completely different issues. One is about removing
license notices, the other is about relicensing. One
Hello!
On Mon, Sep 17, 2007 at 04:57:29AM -0700, David Schwartz wrote:
>> On Sun, Sep 16, 2007 at 03:19:41PM -0700, David Schwartz wrote:
>> >[...]
>> >If you take work that's under a dual-license and remove one
>> >license notice
>> >from it when you create a derivative work, every recipient of
On 9/17/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
[...]
> BTW, this only happens when using libata of course. The
> old CONFIG_IDE stuff works fine every time.
> >>> This maybe one of libata weirdness (I really don't get it why some
> >>> hardware
> >>> works perfectly fine with an old
> On Sun, Sep 16, 2007 at 03:19:41PM -0700, David Schwartz wrote:
> >[...]
>
> >If you take work that's under a dual-license and remove one
> >license notice
> >from it when you create a derivative work, every recipient of that
> >derivative work still receives a dual license from the original
On Mon, Sep 17, 2007 at 09:47:43AM +0200, Helge Hafting wrote:
> Your problem seems to be with the BSD licence,
> and the power to alter that licence lies in the BSD community.
I hope you can understand that this mentality is _exactly_ what has
some in the BSD community so upset.
when I see the
Christoph Lameter wrote:
True. That is why we want to limit the number of unmovable allocations and
that is why ZONE_MOVABLE exists to limit those. However, unmovable
allocations are already rare today. The overwhelming majority of
allocations are movable and reclaimable. You can see that f.e.
Jeff Garzik wrote:
> Tejun Heo wrote:
>> [cc'ing Albert and linux-ide]
>>
>> Alan Cox wrote:
>>> /from the media. */
> +if (qc->nbytes < 2048)
> +return -EOPNOTSUPP;
> +
> /* No ATAPI DMA in smart mode */
> if (itdev->smart)
>
* Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> I gather this was with the complete -ck patchset? It would be
> interesting to see if just SD performed as well. If it does, CFS
> needs more work. if not there are other things in -ck that really do
> improve performance and should be looked
Sergey Dolgov wrote:
> On 9/16/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Michal Piotrowski wrote:
>>> Sergey Dolgov pisze:
On Wed, Sep 12, 2007 at 10:19:03PM +0200, Michal Piotrowski wrote:
> Sergey Dolgov pisze:
>> Hi Michal,
>>
>> On Wed, Sep 12, 2007 at 06:33:20PM +0200,
It's theoretically possible for a single SETATTR call to come in that
sets the mode and the uid/gid. In that case, don't set the ATTR_KILL_S*ID
bits since that would trip the BUG() in notify_change. Just fix up the
mode to have the same effect.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
When an unprivileged process attempts to modify a file that has the
setuid or setgid bits set, the VFS will attempt to clear these bits. The
VFS will set the ATTR_KILL_SUID or ATTR_KILL_SGID bits in the ia_valid
mask, and then call notify_change to clear these bits and set the mode
accordingly.
If the ATTR_KILL_S*ID bits are set then any mode change is only for
clearing the setuid/setgid bits. For CIFS, skip the mode change and
let the server handle it.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
fs/cifs/inode.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
reiserfs_setattr can call notify_change recursively using the same
iattr struct. This could cause it to trip the BUG() in notify_change.
Fix reiserfs to clear those bits near the beginning of the function.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
fs/reiserfs/inode.c |6 +-
1
If the ATTR_KILL_S*ID bits are set then any mode change is only for
clearing the setuid/setgid bits. For NFS, skip the mode change and
let the server handle it.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
fs/nfs/inode.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff
Don't allow either function to trip the BUG() in notify_change. For
unionfs_setattr, clear ATTR_MODE if the either ATTR_KILL_S*ID is set.
This also allows the lower filesystem to interpret these bits in its
own way.
unionfs_create is setting the mode explicitly already, so don't set
On Sat, 15 Sep 2007, Stefan Richter wrote:
> >> +menu "Storage (core and SCSI commands)"
> >>
> >> config SCSI
> >> - tristate "SCSI device support"
> >> + tristate "Storage support (core and SCSI commands)"
> >>depends on BLOCK
> >>select SCSI_DMA if HAS_DMA
> >>---help---
> >>
This patch makes sure ecryptfs doesn't trip the BUG() in notify_change.
It also allows the lower filesystem to interpret ATTR_KILL_S*ID in its
own way.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff
This patchset is the latest one for fixing the clearing of setuid/setgid
bits in networked filesystems. It should apply cleanly to 2.6.23-rc4-mm1.
This is basically the same patchset as take 5. The main differences are
that the patches have been reordered to make the tree cleanly bisectable,
and
* Rob Hussey <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> After posting some benchmarks involving cfs
> (http://lkml.org/lkml/2007/9/13/385), I got some feedback, so I
> decided to do a follow-up that'll hopefully fill in the gaps many
> people wanted to see filled.
thanks for the update!
>
301 - 400 of 1128 matches
Mail list logo
