Re: [PATCH 0/2] unify DMA_..BIT_MASK definitions: v1

On Tue, Sep 18, 2007 at 06:29:19AM +0200, Borislav Petkov wrote: > These patches remove redundant DMA_..BIT_MASK definitions across two drivers. > In this version of the patches, the computation of the bitmasks is done by > the compiler. > > Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> >

Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)

(Reposted for completeness. Previously rejected by vger due to accidental send as html mail. CC's except for Mike and vger deleted) On Monday 17 September 2007 20:27, Mike Snitzer wrote: > To give you context for where I'm coming from; I'm looking to get NBD > to survive the mke2fs hell I

Re: CFS patch (v6) -- dynamic RT priorities?

On Mon, Sep 17, 2007 at 02:33:28PM -0600, Chris Rigg wrote: > Hello, > > I have a system with 2.6.20.7 patched with the v6 CFS patch. I am having > issues (I believe) with fairness in regards to my real-time tasks. > First, let me describe my setup: Chris, CFSv6 is *very* old. It was not that

Re: Scheduler benchmarks - a follow-up

On 9/18/07, Willy Tarreau <[EMAIL PROTECTED]> wrote: > Hi Rob, > > On Tue, Sep 18, 2007 at 12:30:05AM -0400, Rob Hussey wrote: > > I should have pointed out before that I don't really have a dual-core > > system, just a P4 with Hyper-Threading (I loosely used core to refer > > to processor). > >

Re: Scheduler benchmarks - a follow-up

Hi Rob, On Tue, Sep 18, 2007 at 12:30:05AM -0400, Rob Hussey wrote: > I should have pointed out before that I don't really have a dual-core > system, just a P4 with Hyper-Threading (I loosely used core to refer > to processor). Just for reference, we call them "siblings", not "cores" on HT. I

Re: [patch 2/7] Use extended crashkernel command line on i386

On Thu, Sep 13, 2007 at 06:14:30PM +0200, Bernhard Walle wrote: > - > void arch_crash_save_vmcoreinfo(void) > { > #ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE > --- a/arch/i386/kernel/setup.c > +++ b/arch/i386/kernel/setup.c > @@ -381,6 +381,33 @@ extern unsigned long __init setup_memory > extern

[PATCH 2/2] unify DMA_..BIT_MASK definitions v1: cleanup drivers/scsi/gdth.c

Move dma bitmask definitions into the dma-mappings header. Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]> -- Index: 23-rc6/drivers/scsi/gdth.c === --- 23-rc6/drivers/scsi/gdth.c.orig

[PATCH 1/2] unify DMA_..BIT_MASK definitions v1: netxen local defs

Move dma bitmask definitions into the dma-mappings header. Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]> -- Index: 23-rc6/drivers/net/netxen/netxen_nic_main.c === ---

Re: Scheduler benchmarks - a follow-up

On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > i've meanwhile tested hackbench 90 and the performance difference > > between -ck and -cfs-devel seems to be mostly down to the more precise > > (but slower) sched_clock() introduced in v2.6.23

[PATCH 0/2] unify DMA_..BIT_MASK definitions: v1

These patches remove redundant DMA_..BIT_MASK definitions across two drivers. In this version of the patches, the computation of the bitmasks is done by the compiler. Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]> -- Index:

Re: My position on general ``RAS'' tool support infrastructure

On Mon, Sep 17, 2007 at 06:38:53PM -0700, Randy Dunlap wrote: > On Thu, 13 Sep 2007 07:21:10 -0600 Eric W. Biederman wrote: > > > Pete/Piet Delaney <[EMAIL PROTECTED]> writes: > > > > > Jason, Eric: > > > > > > Did you read Keith Owens suggestion on RAS tools from: > > > Yes. and I re-read

Re: [PATCH mm] fix swapoff breakage; however...

Hugh Dickins wrote: > On Tue, 18 Sep 2007, Balbir Singh wrote: >> Hugh Dickins wrote: >>> What would make sense is (what I meant when I said swap counted >>> along with RSS) not to count pages out and back in as they are >>> go out to swap and back in, just keep count of instantiated pages >>> >>

Re: PROBLEM: Network sky2 Module

i'm experiencing this problem myself. i have 2 servers, one using X86_64 kernel version 2.6.23-rc5 on a 100Mbit network and one with i386 kernel version 2.6.23-rc6 on a 1Gbit network. They both have this issue with the sky2 network device driver whereby the device would stop working and need

Re: Fwd: Intel DQ35JOE Mainboard 82566DM-2 Gigabit Network

John Duthie wrote: > I'm having a few Problems with a NEW PC > > Spec is: > Intel DQ35JOE Mainboard > > The Integrated NIC is not found by kernel 2.6.23-rc6 or 2.6.22.1 > Am I missing an option in there ?? support for that nic has not yet been released as a -rc or stable kernel release > The

Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)

On 9/17/07, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Friday 07 September 2007 22:12, Mike Snitzer wrote: > > Can you be specific about which changes to existing mainline code > > were needed to make recursive reclaim "work" in your tests (albeit > > less ideally than peterz's patchset in

Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet

Hi, Sorry for my error. The problem is the current icmp_reply and ip_send_reply will send out packets with wrong destination address. Not wrong source address. My point is that we should always use the source address of packets we received as the destination address of our reply packets. On

Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet

On Tue, 18 Sep 2007, YOSHIFUJI Hideaki / [EMAIL PROTECTED](B wrote: In article <[EMAIL PROTECTED]> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: From: lepton <[EMAIL PROTECTED]> Date: Tue, 18 Sep 2007 10:16:17 +0800 Hi, In some situation, icmp_reply

Re: [PATCH] CONFIG_ZONE_MOVABLE [2/2] config zone movable

On Mon, 17 Sep 2007 19:47:48 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Fri, 31 Aug 2007 19:14:15 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> > wrote: > > > Makes ZONE_MOVABLE as configurable > > > > Based on "zone_ifdef_cleanup_by_renumbering.patch" > > > > This patch causes my old

Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet

Hi, sorry for my previous email. What I mean is icmp_reply and ip_send_reply in some situation will send out packets with wrong DESTINATION address. the source address is always correct. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [RFC -mm 2/2] i386/x86_64 boot: document for 32 bit boot protocol

On Mon, 2007-09-17 at 18:48 -0700, H. Peter Anvin wrote: > Huang, Ying wrote: > > > > OK, I will check the actual structure, and change the document > > accordingly. > > > > The best would probably be to fix zero-page.txt (and probably rename it > something saner.) Does the patch appended with

Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet

Hi, sorry for lack of details. let's think about ip_send_reply. it is only called by tcp_v4_send_ack and tcp_v4_reset. I don't know why we need a source address diffrent from ip_hdr(skb)->s_addr icmp_reply is only called by icmp_echo and icmp_timestamp. Is there a situation to need we use a

Re: [PATCH] CONFIG_ZONE_MOVABLE [2/2] config zone movable

On Fri, 31 Aug 2007 19:14:15 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > Makes ZONE_MOVABLE as configurable > > Based on "zone_ifdef_cleanup_by_renumbering.patch" > This patch causes my old dual-pIII machine to instantly reboot: 0.01 seconds uptime.

Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

On Mon, 17 Sep 2007 18:37:49 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote: > > > Untested (not even compile-tested) patch. > > Could someone point me to ppc32/64 cross-compilers for i386? > > OSDL had some, but those are gone now.

Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet

In article <[EMAIL PROTECTED]> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > From: lepton <[EMAIL PROTECTED]> > Date: Tue, 18 Sep 2007 10:16:17 +0800 > > > Hi, > > In some situation, icmp_reply and ip_send_reply will send > > out packet with the wrong

Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet

From: lepton <[EMAIL PROTECTED]> Date: Tue, 18 Sep 2007 10:16:17 +0800 > Hi, > In some situation, icmp_reply and ip_send_reply will send > out packet with the wrong source addr, the following patch > will fix this. > > I don't understand why we must use rt->rt_src in the current >

[PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet

Hi, In some situation, icmp_reply and ip_send_reply will send out packet with the wrong source addr, the following patch will fix this. I don't understand why we must use rt->rt_src in the current code, if this is a wrong fix, please correct me. Signed-off-by: Lepton Wu <[EMAIL

Re: [BUG:] forcedeth: MCP55 not allowing DHCP

Casey Dahlin wrote: I have an Asus Striker Extreme motherboard with two built in MCP55 GigE interfaces. When I build with the original Fedora 7 release kernel ( ftp://ftp.belnet.be/linux/fedora/linux/releases/7/Fedora/i386/os/Fedora/kernel-2.6.21-1.3194.fc7.i686.rpm ) everything works fine.

Re: [RFC -mm 2/2] i386/x86_64 boot: document for 32 bit boot protocol

Huang, Ying wrote: > > OK, I will check the actual structure, and change the document > accordingly. > The best would probably be to fix zero-page.txt (and probably rename it something saner.) -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

Re: 2.6.20 (XFS? related) crash after uptime of > 180 days during apt-get dist-upgrade on Debian Testing

On Mon, Sep 17, 2007 at 01:20:17PM -0400, Justin Piszcz wrote: > Including the XFS mailing list in here too because it may be an XFS bug > looking at the call trace. > > System: Debian Testing > Kernel: 2.6.20 > Config: Attached > > I was running apt-get dist-upgrade as I always do to get the

Re: Scheduler benchmarks - a follow-up

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

Re: My position on general ``RAS'' tool support infrastructure

On Thu, 13 Sep 2007 07:21:10 -0600 Eric W. Biederman wrote: > Pete/Piet Delaney <[EMAIL PROTECTED]> writes: > > > Jason, Eric: > > > > Did you read Keith Owens suggestion on RAS tools from: Yes. and I re-read it. There are several things in Keith's email that make sense: a. all RAS tools

Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote: > Untested (not even compile-tested) patch. > Could someone point me to ppc32/64 cross-compilers for i386? OSDL had some, but those are gone now. I downloaded all of them and still use them, although it would be good to have some more

Fwd: Intel DQ35JOE Mainboard 82566DM-2 Gigabit Network

I'm having a few Problems with a NEW PC Spec is: Intel DQ35JOE Mainboard Intel Q6600 Quad core CPU 4GB ram 3 SATA HDDs 1 SATA DVD-RW The Integrated NIC is not found by kernel 2.6.23-rc6 or 2.6.22.1 Am I missing an option in there ?? The Intel Drivers (e1000-7.6.5) don't compile against

Re: [2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

On Tue, Sep 18, 2007 at 12:54:07AM +0100, Nix wrote: > The code which calls new_do_write() looks like this: > > ,[ libio/fileops.c:_IO_new_file_xsputn() ] > | if (do_write) > |{ > | count = new_do_write (f, s, do_write); > | to_do -= count; > | if (count < do_write) > |

Re: [RFC -mm 2/2] i386/x86_64 boot: document for 32 bit boot protocol

On Mon, 2007-09-17 at 08:29 -0700, H. Peter Anvin wrote: > 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

Re: [RFC -mm 1/2] i386/x86_64 boot: setup data

On Mon, 2007-09-17 at 08:30 -0700, H. Peter Anvin wrote: > 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

Re: Wasting our Freedom

On Mon, Sep 17, 2007 at 05:03:55PM -0700, David Schwartz wrote: > > > "David Schwartz" <[EMAIL PROTECTED]> writes: > > > > My point is that you *cannot* prevent a recipient of a > > > derivative work from > > > receiving any rights under either the GPL or the BSD to any protectable > > >

Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)

On Friday 07 September 2007 22:12, Mike Snitzer wrote: > Can you be specific about which changes to existing mainline code > were needed to make recursive reclaim "work" in your tests (albeit > less ideally than peterz's patchset in your view)? Sorry, I was incommunicado out on the high seas all

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

Charles N Wyble wrote: > > > Zachary Amsden wrote: > > > > Virtualization is completely different, and probably needs separate > > server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in > > it's menu. > > > So what is the differentiation between client and server above? Just >

Re: [PATCH] ext34: ensure do_split leaves enough free space in both blocks

Andreas Dilger: > > So this looks like 2.6.22 and 2.6.23 material, but the timing is getting > > pretty squeezy. Could people please give this change an extra-close > > review, let me know? > > I already discussed it at length with Eric and inspected the patch, so we > could add: >

Re: [PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

On Tue, 18 Sep 2007, Satyam Sharma wrote: > > > [ cut here ] > > Badness at arch/powerpc/kernel/smp.c:202 > > comes when smp_call_function_map() has been called with irqs disabled, > which is illegal. However, there is a special case, the panic() codepath, > when we do

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zachary Amsden wrote: > > Virtualization is completely different, and probably needs separate > server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in > it's menu. So what is the differentiation between client and server above?

RE: Wasting our Freedom

> "David Schwartz" <[EMAIL PROTECTED]> writes: > > My point is that you *cannot* prevent a recipient of a > > derivative work from > > receiving any rights under either the GPL or the BSD to any protectable > > elements in that work. > > Of course you can. No you can't. > What rights do you

Re: Wasting our Freedom

[EMAIL PROTECTED] wrote on Sun, Sep 16, 2007 at 04:40:38PM -0700: > On Sun, 16 Sep 2007, Jacob Meuser wrote: >> so the linux community is morally equivilent to a corporation? >> that's what it sounds like you are all legally satisfied with. > > if it's legal it's legal. it's not a matter of the

Re: [2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

On 17 Sep 2007, J. Bruce Fields stated: > On Mon, Sep 17, 2007 at 11:23:46PM +0100, Nix wrote: >> A while later we start seeing runs of malloc failures, which I think >> correlated with the unexplained pauses in NFS response: > > Actually, they're nothing to do with malloc failures--the message >

Re: 2.6.23-rc4-mm1 OOPS in forcedeth?

On Mon, 17 Sep 2007, Denis V. Lunev wrote: > Dhaval Giani wrote: > > On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote: > >> EIP: [] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec As Vlad Yasevich mentioned, this one is already fixed in 23-rc6. The forcedeth oops is unrelated, but

Re: Wasting our Freedom

On Mon, Sep 17, 2007 at 03:06:37PM -0700, Can E. Acar wrote: > The only remaining issue is whether Nick & Jiri have enough > original contributions to the code to be added to the Copyright. > > I believe this needs to be resolved between Reyk and Nick and Jiri. > > The main reason of Theo's

Re: [ofa-general] [PATCH] [WORKAROUND] CONFIG_PREEMPT_RT and ib_umad_close() issue

Roland Dreier wrote: Thanks for the explanation... > But basically, with CONFIG_PREEMPT_RT enabled, the lock points, such as > aqcuiring a spinlock, potentially become places where the current task > may be context switched out / preempted. > > Therefore, when a call is made to lock a

[PATCH] powerpc: Avoid pointless WARN_ON(irqs_disabled()) from panic codepath

> [ cut here ] > Badness at arch/powerpc/kernel/smp.c:202 comes when smp_call_function_map() has been called with irqs disabled, which is illegal. However, there is a special case, the panic() codepath, when we do not want to warn about this -- warning at that time is

Re: Wasting our Freedom

"David Schwartz" <[EMAIL PROTECTED]> writes: > My point is that you *cannot* prevent a recipient of a derivative work from > receiving any rights under either the GPL or the BSD to any protectable > elements in that work. Of course you can. What rights do you have to BSD-licenced works, made

Re: [PATCH] modpost: detect unterminated device id lists

Hi Andrew, Em Seg, 2007-09-17 às 14:50 -0700, Andrew Morton escreveu: > On Tue, 18 Sep 2007 03:15:14 +0530 (IST) > Satyam Sharma <[EMAIL PROTECTED]> wrote: > > > > > > > On Sun, 16 Sep 2007, Andrew Morton wrote: > > > > > On Mon, 17 Sep 2007 05:54:45 +0530 "Satyam Sharma" <[EMAIL PROTECTED]>

Re: [2.6.23-rc4-mm1][Bug] kernel BUG at include/linux/netdevice.h:339!

From: Andrew Morton <[EMAIL PROTECTED]> Date: Mon, 17 Sep 2007 14:16:22 -0700 > On Mon, 17 Sep 2007 17:46:38 +0530 > Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > > > Kernel Bug is hit with 2.6.23-rc4-mm1 kernel on ppc64 machine. > > > > kernel BUG at include/linux/netdevice.h:339! > > (please

Re: [PATCH 048/104] KVM: Add and use pr_unimpl for standard formatting of unimplemented features

On Mon, 2007-09-17 at 09:16 -0700, Joe Perches wrote: > 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

Re: [00/41] Large Blocksize Support V7 (adds memmap support)

On Sun, 16 Sep 2007, Nick Piggin wrote: > > > So if you argue that vmap is a downside, then please tell me how you > > > consider the -ENOMEM of your approach to be better? > > > > That is again pretty undifferentiated. Are we talking about low page > > In general. There is no -ENOMEM approach.

Re: [PATCH] JBD slab cleanups

On Mon, 2007-09-17 at 15:01 -0700, Badari Pulavarty wrote: > On Mon, 2007-09-17 at 12:29 -0700, Mingming Cao wrote: > > On Fri, 2007-09-14 at 11:53 -0700, Mingming Cao wrote: > > > jbd/jbd2: Replace slab allocations with page cache allocations > > > > > > From: Christoph Lameter <[EMAIL

Re: [patch 1/8] Immediate Values - Global Modules List and Module Mutex

On Fri, 2007-09-14 at 11:32 -0400, Mathieu Desnoyers wrote: > * Rusty Russell ([EMAIL PROTECTED]) wrote: > > Alternatively, if you called it "immediate_init" then the semantics > > change slightly, but are more obvious (ie. only use this when the value > > isn't being accessed yet). But it can't

Re: [2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

On Mon, Sep 17, 2007 at 11:23:46PM +0100, Nix wrote: > Sep 17 22:57:55 loki warning: kernel: nfsd_dispatch: vers 3 proc 4 > Sep 17 22:57:55 loki warning: kernel: nfsd: ACCESS(3) 36: 01070001 000fb001 > d32ff38f 404811a6 a88d96ab 0x1f > Sep 17 22:57:55 loki warning: kernel: nfsd:

Re: [PATCH mm] fix swapoff breakage; however...

On Tue, 18 Sep 2007, Balbir Singh wrote: > Hugh Dickins wrote: > > > > What would make sense is (what I meant when I said swap counted > > along with RSS) not to count pages out and back in as they are > > go out to swap and back in, just keep count of instantiated pages > > > > I am not sure

Re: [PATCH] 2.6.23-rc6: Fix NUMA Memory Policy Reference Counting

> Handling policy ref counts for hugepages is a bit trickier. > huge_zonelist() returns a zone list that might come from a > shared or vma 'BIND policy. In this case, we should hold the > reference until after the huge page allocation in > dequeue_hugepage(). The patch modifies

Re: [PATCH] 2.6.23-rc6: Fix NUMA Memory Policy Reference Counting

> The patch does require concurrent increments and decrements in the main > fault patch. The potential is to create another bouncing cacheline for > concurrent faults. This looks like it would cause a performance issue. While may be true correctness is always more important than performance.

[2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

Back in early 2006 I reported persistent hangs on the NFS server, whereby all of a sudden about ten minutes after boot my primary NFS server would cease responding to NFS requests until it was rebooted. That time, the problem

Add all thread stats for TASKSTATS_CMD_ATTR_TGID (v5)

TASKSTATS_CMD_ATTR_TGID used to return only the delay accounting stats, not the basic and extended accounting. With this patch, TASKSTATS_CMD_ATTR_TGID also aggregates the accounting info for all threads of a thread group. This makes TASKSTATS_CMD_ATTR_TGID usable in a similar fashion to

Re: [PATCH 1/3] IB/ehca: Fix large page HW cap defines

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

Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

> The IGMP enabling patch posted by me on September 2nd isn't on your list > http://lists.openfabrics.org/pipermail/general/2007-September/040250.html > can you add it? Yes, I lost that somehow. I will add it to my list of things to take a look at (no opinion yet). - R. - To unsubscribe

Re: [00/41] Large Blocksize Support V7 (adds memmap support)

On Mon, 17 Sep 2007, Bernd Schmidt wrote: > 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

Re: Wasting our Freedom

Adrian Bunk wrote on Mon, Sep 17, 2007 at 02:57:14PM +0200: > But stating in your licence that noone has to give back but then > complaining to some people on ethical grounds that they should give > back is simply dishonest. > > Is your intention to allow people to include your code into GPL'ed

Re: [00/41] Large Blocksize Support V7 (adds memmap support)

On Sun, 16 Sep 2007, Nick Piggin wrote: > > > fsblock doesn't need any of those hacks, of course. > > > > Nor does mine for the low orders that we are considering. For order > > > MAX_ORDER this is unavoidable since the page allocator cannot manage such > > large pages. It can be used for lower

Re: [00/41] Large Blocksize Support V7 (adds memmap support)

On Sun, 16 Sep 2007, Jörn Engel wrote: > I bet! My (false) assumption was the same as Goswin's. If non-movable > pages are clearly seperated from movable ones and will evict movable > ones before polluting further mixed superpages, Nick's scenario would be > nearly infinitely impossible. > >

Re: Wasting our Freedom

Theodore Tso wrote: > On Mon, Sep 17, 2007 at 09:23:41PM +0200, Claudio Jeker wrote: >> Because they put their copyright plus license on code that they barely >> modified. If they would have added substantial work into the OpenHAL code >> and by doing that creating something new I would not say

Re: [00/41] Large Blocksize Support V7 (adds memmap support)

On Sun, 16 Sep 2007, Nick Piggin wrote: > I don't know how it would prevent fragmentation from building up > anyway. It's commonly the case that potentially unmovable objects > are allowed to fill up all of ram (dentries, inodes, etc). Not in 2.6.23 with ZONE_MOVABLE. Unmovable objects are not

Re: [PATCH] Userspace tuner

Dâniel Fraga wrote: Well, I'd like to see Linus' opinion about this, because while programmers keep discussing this, users are waiting forever... so if Markus has a concrete and better solution, why don't use it? And as far as I know, Markus is the programmer who is most

Re: [PATCH] JBD slab cleanups

On Mon, 2007-09-17 at 12:29 -0700, Mingming Cao wrote: > On Fri, 2007-09-14 at 11:53 -0700, Mingming Cao wrote: > > jbd/jbd2: Replace slab allocations with page cache allocations > > > > From: Christoph Lameter <[EMAIL PROTECTED]> > > > > JBD should not pass slab pages down to the block layer. >

Re: [PATCH] selinux: Improving SELinux read/write performance

On Mon, 17 Sep 2007, Stephen Smalley wrote: > > It reduces the selinux overhead on read/write by only revalidating > > permissions in selinux_file_permission if the task or inode labels have > > changed or the policy has changed since the open-time check. A new LSM > > hook,

RE: [kvm-devel] [PATCH 2/3] Refactor hypercall infrastructure (v3)

Anthony Liguori wrote: > This patch refactors the current hypercall infrastructure to better support > live > migration and SMP. It eliminates the hypercall page by trapping the UD > exception that would occur if you used the wrong hypercall instruction for the > underlying architecture and

[PATCH 11/11] eCryptfs: Replace magic numbers

Replace some magic numbers with sizeof() equivalents. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/ecryptfs/crypto.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c index 3b3cf27..425a144 100644 ---

[PATCH 10/11] eCryptfs: Remove unused functions and kmem_cache

The switch to read_write.c routines and the persistent file make a number of functions unnecessary. This patch removes them. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/ecryptfs/crypto.c | 150 -- fs/ecryptfs/ecryptfs_kernel.h | 21 +---

[PATCH 9/11] eCryptfs: Initialize persistent lower file on inode create

Initialize persistent lower file on inode create. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/ecryptfs/super.c | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/fs/ecryptfs/super.c b/fs/ecryptfs/super.c index b97e210..f8cdab2 100644 ---

[PATCH 8/11] eCryptfs: Convert mmap functions to use persistent file

Convert readpage, prepare_write, and commit_write to use read_write.c routines. Remove sync_page; I cannot think of a good reason for implementing that in eCryptfs. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/ecryptfs/mmap.c | 199

[PATCH 7/11] eCryptfs: Make open, truncate, and setattr use persistent file

Rather than open a new lower file for every eCryptfs file that is opened, truncated, or setattr'd, instead use the existing lower persistent file for the eCryptfs inode. Change truncate to use read_write.c functions. Change ecryptfs_getxattr() to use the common ecryptfs_getxattr_lower() function.

Re: [PATCH] add consts where appropriate in sound/pci/hda/*

On Monday 17 September 2007 11:01, Takashi Iwai wrote: > > There is a lot of data structures in that code, > > and most of them seems to be read-only. > > > > I added const modifiers to most of such places: > > > >textdata bss dec hex filename > > 106315 179564 36

[PATCH 6/11] eCryptfs: Update metadata read/write functions

Update the metadata read/write functions and grow_file() to use the read_write.c routines. Do not open another lower file; use the persistent lower file instead. Provide a separate function for crypto.c::ecryptfs_read_xattr_region() to get to the lower xattr without having to go through the

[PATCH 5/11] eCryptfs: Set up and destroy persistent lower file

This patch sets up and destroys the persistent lower file for each eCryptfs inode. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/ecryptfs/inode.c | 23 +++--- fs/ecryptfs/main.c | 65 +++ fs/ecryptfs/super.c | 22

[PATCH 4/11] eCryptfs: Replace encrypt, decrypt, and inode size write

Replace page encryption and decryption routines and inode size write routine with versions that utilize the read_write.c functions. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/ecryptfs/crypto.c | 427 ++-- fs/ecryptfs/ecryptfs_kernel.h

[PATCH 3/11] eCryptfs: read_write.c routines

Add a set of functions through which all I/O to lower files is consolidated. This patch adds a new inode_info reference to a persistent lower file for each eCryptfs inode; another patch later in this series will set that up. This persistent lower file is what the read_write.c functions use to call

Re: [PATCH] modpost: detect unterminated device id lists

On Tue, 18 Sep 2007 03:15:14 +0530 (IST) Satyam Sharma <[EMAIL PROTECTED]> wrote: > > > On Sun, 16 Sep 2007, Andrew Morton wrote: > > > On Mon, 17 Sep 2007 05:54:45 +0530 "Satyam Sharma" <[EMAIL PROTECTED]> > > wrote: > > > > > On 9/17/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > >

[PATCH 2/11] eCryptfs: Remove assignments in if-statements

Remove assignments in if-statements. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/ecryptfs/crypto.c| 17 -- fs/ecryptfs/file.c |8 -- fs/ecryptfs/inode.c | 35 ++ fs/ecryptfs/keystore.c | 55

[PATCH 1/11] eCryptfs: Remove header_extent_size

There is no point to keeping a separate header_extent_size and an extent_size. The total size of the header can always be represented as some multiple of the regular data extent size. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/ecryptfs/crypto.c | 40

[PATCH 0/11] eCryptfs: Introduce persistent lower files for each eCryptfs inode

Currently, eCryptfs directly accesses the lower inode address space, doing things like grab_cache_page() on lower_inode->i_mapping. It really should not do that. The main point of this patch set is to make all I/O with the lower files go through vfs_read() and vfs_write() instead. In order to

Re: InfiniBand/RDMA merge plans for 2.6.24

> > IPoIB CM handles this properly by gathering together single pages in > > skbs' fragment lists. > Then can we reuse IPoIB CM code here? Yes, if possible, refactoring things so that the rx skb allocation code becomes common between CM and non-CM would definitely make sense. - To unsubscribe

Re: [PATCH] revert ath5k ioread32()/iowrite32() usage - use readl()/writel(), we're MMIO-only

On 09/17/2007 10:59 PM, Jeff Garzik wrote: > Jiri Slaby wrote: >> NACK, this is wrong. iomap returns platform dependant return value, >> which may or > > Incorrect. readl() and writel() work just fine on all existing > platforms where Atheros may be used. Ok, this is what Alan Cox wrote about

Re: 2.6.23 alpha unistd.h changes

On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote: > Hi! Hi Oliver! >... > As these additions are quite new to upstream kernel, but at Alphacore we > have patched it since a while now (I don't know about other Alpha ports; > Debian folks may speak up now!), I would suggest to use the

Re: [PATCH] modpost: detect unterminated device id lists

On Sun, 16 Sep 2007, Andrew Morton wrote: > On Mon, 17 Sep 2007 05:54:45 +0530 "Satyam Sharma" <[EMAIL PROTECTED]> wrote: > > > On 9/17/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > I'm getting this: > > > > > > rusb2/pvrusb2: struct usb_device_id is 20 bytes. The last of 3 is: > >

Re: [ofa-general] [PATCH] [WORKAROUND] CONFIG_PREEMPT_RT and ib_umad_close() issue

Thanks for the explanation... > But basically, with CONFIG_PREEMPT_RT enabled, the lock points, such as > aqcuiring a spinlock, potentially become places where the current task > may be context switched out / preempted. > > Therefore, when a call is made to lock a spinlock for example, the

[PATCH 18/33] containers implement namespace tracking subsystem

From: "Serge E. Hallyn" <[EMAIL PROTECTED]> (container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>) When a task enters a new namespace via a clone() or unshare(), a new cgroup is created and the task moves into it. This version names cgroups which are automatically created using

Re: [PATCH] 2.6.23-rc6: Fix NUMA Memory Policy Reference Counting

On Mon, 17 Sep 2007, Lee Schermerhorn wrote: > Only for vma policy, right? show_numa_maps() isn't a performance path, > and shared policies are already reference counted--just not unref'd! Right. > I do have some ideas for enhancements to memtoy to test vma policies in > a multi-threaded task.

Re: [PATCH] Configurable reclaim batch size

On Tue, 18 Sep 2007, Balbir Singh wrote: > Please do let me know if someone finds a good standard test for it or a > way to stress reclaim. I've heard AIM7 come up often, but never been > able to push it much. I should retry. AIM7 does small computing loads reflecting an earlier time. I wish

[PATCH 00/33] Rename "Task Containers" to "Control Groups"

-- This patchset renames "Task Containers" to "Control Groups", in line with recent discussions. These patches are drop-in replacements for those of the same names in the current -mm tree, as listed at the bottom of this email. I have tried to keep the patch names (based on the description

Re: 2.6.23 alpha unistd.h changes

On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote: > Hi! Hi Oliver! > At Alphacore we used to patch the kernel headers for a while now; We > added syscalls __NR_openat (447) until __NR_tee (466). Why did your numbers differ from the numbers that were used in the upstream kernel? The

Re: [2.6.23-rc4-mm1][Bug] kernel BUG at include/linux/netdevice.h:339!

On Mon, 17 Sep 2007 17:46:38 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > Kernel Bug is hit with 2.6.23-rc4-mm1 kernel on ppc64 machine. > > kernel BUG at include/linux/netdevice.h:339! (please cc [EMAIL PROTECTED] on networking-related matters) You died here: static inline void

[PATCH] mac_hid: fix build error if MAC_EMUMOUSEBTN && !INPUT

Hi, With current git an invalid kernel configuration is selectable which leads to kernel build errors for mac_hid. To prevent this selection I suggest follwoing patch. Regards, Andreas -- Build error if MAC_EMUMOUSEBTN && !INPUT: LD .tmp_vmlinux1 drivers/built-in.o: In function

  1   2   3   4   5   6   7   8   9   10   >