* Re: [PATCH 1/2] export cpu_tlbstate to modules
From: H. Peter Anvin @ 2009-08-10 21:56 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, virtualization, kvm, linux-kernel, mingo
In-Reply-To: <20090810185302.GB13924@redhat.com>
On 08/10/2009 11:53 AM, Michael S. Tsirkin wrote:
> vhost net module wants to do copy to/from user from a kernel thread,
> which needs switch_mm (like what fs/aio has).
> export cpu_tlbstate to make this possible
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/x86/mm/tlb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 821e970..e33a5f0 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -13,6 +13,7 @@
>
> DEFINE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate)
> = { &init_mm, 0, };
> +EXPORT_PER_CPU_SYMBOL_GPL(cpu_tlbstate);
>
> /*
> * Smarter SMP flushing macros.
Wouldn't it be a *lot* better to move use_mm() from fs/aio.c into common
code, and export that instead?
-hpa
^ permalink raw reply
* Re: [PATCH 1/2] export cpu_tlbstate to modules
From: Michael S. Tsirkin @ 2009-08-10 22:06 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: netdev, virtualization, kvm, linux-kernel, mingo
In-Reply-To: <4A80979E.3080204@zytor.com>
On Mon, Aug 10, 2009 at 02:56:46PM -0700, H. Peter Anvin wrote:
> On 08/10/2009 11:53 AM, Michael S. Tsirkin wrote:
> > vhost net module wants to do copy to/from user from a kernel thread,
> > which needs switch_mm (like what fs/aio has).
> > export cpu_tlbstate to make this possible
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > arch/x86/mm/tlb.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> > index 821e970..e33a5f0 100644
> > --- a/arch/x86/mm/tlb.c
> > +++ b/arch/x86/mm/tlb.c
> > @@ -13,6 +13,7 @@
> >
> > DEFINE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate)
> > = { &init_mm, 0, };
> > +EXPORT_PER_CPU_SYMBOL_GPL(cpu_tlbstate);
> >
> > /*
> > * Smarter SMP flushing macros.
>
> Wouldn't it be a *lot* better to move use_mm() from fs/aio.c into common
> code, and export that instead?
>
> -hpa
That's easy too. What would a good place for it be?
^ permalink raw reply
* Re: [PATCH 2/2] vhost_net: a kernel-level virtio server
From: Arnd Bergmann @ 2009-08-10 22:16 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtualization, netdev, kvm, linux-kernel
In-Reply-To: <20090810201044.GA16899@redhat.com>
On Monday 10 August 2009 20:10:44 Michael S. Tsirkin wrote:
> On Mon, Aug 10, 2009 at 09:51:18PM +0200, Arnd Bergmann wrote:
> > what is the difference between vhost_net_reset_owner(n)
> > and vhost_net_set_socket(n, -1)?
>
> set socket to -1 will only stop the device.
>
> reset owner will let another process take over the device.
> It also needs to reset all parameters to make it safe for that
> other process, so in particular the device is stopped.
ok
> I tried explaining this in the header vhost.h - does the comment
> there help, or do I need to clarify it?
No, I just didn't get there yet.
> I had the impression that if there's no compat_ioctl,
> unlocked_ioctl will get called automatically. No?
It will issue a kernel warning but not call unlocked_ioctl,
so you need either a compat_ioctl method or list the numbers
in fs/compat_ioctl.c, which I try to avoid.
> > Why do you need a kernel thread here? If the data transfer functions
> > all get called from a guest intercept, shouldn't you already be
> > in the right mm?
>
> several reasons :)
> - I get called under lock, so can't block
> - eventfd can be passed to another process, and I won't be in guest context at all
> - this also gets called outside guest context from socket poll
> - vcpu is blocked while it's doing i/o. it is better to free it up
> as all the packet copying might take a while
Ok.
> > I guess that this is where one could plug into macvlan directly, using
> > sock_alloc_send_skb/memcpy_fromiovec/dev_queue_xmit directly,
> > instead of filling a msghdr for each, if we want to combine this
> > with the work I did on that.
>
> quite possibly. Or one can just bind a raw socket to macvlan :)
Right, that works as well, but may get more complicated once we
try to add zero-copy or other optimizations.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/2] export cpu_tlbstate to modules
From: H. Peter Anvin @ 2009-08-10 22:24 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, virtualization, kvm, linux-kernel, mingo
In-Reply-To: <20090810220613.GA17099@redhat.com>
On 08/10/2009 03:06 PM, Michael S. Tsirkin wrote:
>> Wouldn't it be a *lot* better to move use_mm() from fs/aio.c into common
>> code, and export that instead?
>
> That's easy too. What would a good place for it be?
Somewhere in mm/, presumably. When in doubt, make it a new file...
-hpa
^ permalink raw reply
* Re: module loading permissions and request_module permission inconsistencies
From: Neil Horman @ 2009-08-10 23:25 UTC (permalink / raw)
To: Eric Paris
Cc: linux-kernel, netdev, linux-security-module, sds, davem,
shemminger, kees, morgan, serue, casey, dwlash
In-Reply-To: <1249937339.2501.80.camel@dhcp231-106.rdu.redhat.com>
On Mon, Aug 10, 2009 at 04:48:59PM -0400, Eric Paris wrote:
> On Mon, 2009-08-10 at 16:23 -0400, Neil Horman wrote:
> > On Mon, Aug 10, 2009 at 03:45:13PM -0400, Eric Paris wrote:
>
> > > 1) remove CAP_SYS_MODULE from the networking code and instead check
> > > CAP_NET_ADMIN. Maybe CAP_NET_ADMIN is already being checked and I'll
> > > just remove the capable call altogether but at least I can more
> > > intelligently limit the powers of these processes and they will still be
> > > root limited according to DAC permissions like they are today.
> > >
> > Would this have any adverse effect on how user space sees this working.
> > Intuitively I would think that if you wanted to load a module (directly or
> > indirectly, via an iptables command or whatnot), you would need CAP_SYS_MODULE
> > capabilities on the calling process, not just CAP_NET_ADMIN. I honestly don't
> > know the answer here, I'm just raising the question.
>
> While that might make intuitive sense, it's actually proving to be a bad
> idea to use the same capability for direct and indirect module loading
> (especially considering we have 125 other places in the kernel where you
> can do indirect module loading without any security check) And believe
> me, if someone suggests I move a CAP_SYS_MODULE check down into
> __request_module I'll scream about what a horrible idea that is (and
> then laugh at them behind their back).
>
> While I think there should be some check in __request_module I don't
> think it should be CAP_SYS_MODULE.
>
Forgive my excessive density, but what exactly would be wrong with putting a
CAP_SYS_MODULE check into __request_module? Is there some sort of implicit
behavioral change that will mess with user space in doing so?
> CAP_NET_ADMIN at least limits us to root and in all reality to the same
> situation everyone is in today. I just checked every single selinux
> domain that grants CAP_SYS_MODULE already grants CAP_NET_ADMIN, so we
> can somewhat safely say that nothing (on a fedora system at least) would
> break with this change.
>
Ok, well its definately good that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE
at the moment, but can we guarantee that in the future?
Neil
> -Eric
>
>
^ permalink raw reply
* Re: [PATCH 0/8] sky2: driver update
From: David Miller @ 2009-08-11 0:52 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20090810084822.2df65a12@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 10 Aug 2009 08:48:22 -0700
> On Sun, 09 Aug 2009 21:09:43 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Thu, 06 Aug 2009 09:12:13 -0700
>>
>> > This undoes the prematurely committed sky2 transmit logic changes
>> > and applies Mike's later changes.
>> > Here is a corrected patch stream please apply this to 2.6.31-rc5
>>
>> I have to pass on this set, too many problems:
>>
>> 1) You didn't provide explicit "From: " lines for patches where
>> you were not the author Stephen. I could guess from the
>> Signoff lines but I'd rather not.
>
> What is the mechanics for this, does patchwork accept From:
> lines in message body?
Yes, this is exactly how it works, git format-patch will even
generate these for you :-)
^ permalink raw reply
* Re: [PATCH] AF_PACKET: Fix PACKET_MMAP on 64-bit kernel/32-bit user systems
From: David Miller @ 2009-08-11 1:06 UTC (permalink / raw)
To: cndougla; +Cc: netdev
In-Reply-To: <20090810130359.p2hixk2eoow8kwg8@imap.linux.ibm.com>
You can't make that change without breaking all existing
64-bit binaries running on 64-bit kernels.
Secondarily, we're already fully aware of this problem, that's why
there is a second version of the data structure named tpacket2_hdr
which was created in a way which fixes the problem without breaking
existing setups.
^ permalink raw reply
* Re: module loading permissions and request_module permission inconsistencies
From: Eric Paris @ 2009-08-11 1:29 UTC (permalink / raw)
To: Neil Horman
Cc: linux-kernel, netdev, linux-security-module, sds, davem,
shemminger, kees, morgan, serue, casey
In-Reply-To: <20090810232551.GA20747@hmsreliant.think-freely.org>
On Mon, 2009-08-10 at 19:25 -0400, Neil Horman wrote:
> On Mon, Aug 10, 2009 at 04:48:59PM -0400, Eric Paris wrote:
> > On Mon, 2009-08-10 at 16:23 -0400, Neil Horman wrote:
> > > On Mon, Aug 10, 2009 at 03:45:13PM -0400, Eric Paris wrote:
> >
> > > > 1) remove CAP_SYS_MODULE from the networking code and instead check
> > > > CAP_NET_ADMIN. Maybe CAP_NET_ADMIN is already being checked and I'll
> > > > just remove the capable call altogether but at least I can more
> > > > intelligently limit the powers of these processes and they will still be
> > > > root limited according to DAC permissions like they are today.
> > > >
> > > Would this have any adverse effect on how user space sees this working.
> > > Intuitively I would think that if you wanted to load a module (directly or
> > > indirectly, via an iptables command or whatnot), you would need CAP_SYS_MODULE
> > > capabilities on the calling process, not just CAP_NET_ADMIN. I honestly don't
> > > know the answer here, I'm just raising the question.
> >
> > While that might make intuitive sense, it's actually proving to be a bad
> > idea to use the same capability for direct and indirect module loading
> > (especially considering we have 125 other places in the kernel where you
> > can do indirect module loading without any security check) And believe
> > me, if someone suggests I move a CAP_SYS_MODULE check down into
> > __request_module I'll scream about what a horrible idea that is (and
> > then laugh at them behind their back).
> >
> > While I think there should be some check in __request_module I don't
> > think it should be CAP_SYS_MODULE.
> >
> Forgive my excessive density, but what exactly would be wrong with putting a
> CAP_SYS_MODULE check into __request_module? Is there some sort of implicit
> behavioral change that will mess with user space in doing so?
Yes I believe it would almost certainly break all of the programs
outside of the 3 networking spots which trigger the kernel to try to
load a module. Take a look at everything that call request_module(). I
believe this because currently there are no security checks on those 125
call sites and security policy does not grant CAP_SYS_MODULE to many
domains (for good reason, it's a @#$% dangerous permission to give
things.)
If the kernel does go that route it will force the security policy to be
loosened such that all of those programs will have permission to
directly load arbitrary data they can create. As it stands today,
subverting any of those calling programs 'merely' allows the attacker to
make the kernel load a module using modprobe whose name is sometimes
attacker controlled and sometimes not. I contend that triggering the
kernel to do an upcall is not the same security behavior as loading my
own data directly into the kernel.
That's the whole problem. There are separate security concerns between
triggering the loading of a known module and directly loading arbitrary
data. Pushing a CAP_SYS_MODULE check down into __request_module will
result in a less secure system policy in which the attack space on a
system grows since there would be a significantly increased number of
programs with permission to load data directly into the kernel.
If the community feels that CAP_SYS_MODULE in __request_module is the
right way to go that's fine (but I'm not going to send that patch which
i believe will break systems). I'll just create new security hooks in
init_module, delete_module, and __request_module, which have no DAC
meaning but which LSMs can implement policy with. Given those 2/3 new
hooks an LSMs can freely grant CAP_SYS_MODULE like candy, since in my
opinion, it becomes a lot less meaningful and we can still meet
meaningful security goals.
-Eric
^ permalink raw reply
* Re: [PATCH] fix memory leak in virtio_net
From: Shirley Ma @ 2009-08-11 5:03 UTC (permalink / raw)
To: kvm; +Cc: linux-kernel, netdev
In-Reply-To: <1249934708.7400.10.camel@localhost.localdomain>
This is false report. I checked kfree_skb(), it does free all pages
in the fraglist in skb_release_data() later.
Thanks
Shirley
On Mon, 2009-08-10 at 13:05 -0700, Shirley Ma wrote:
> Whild reading virtio code, I found some memory leak in removing
> virtio_net.
>
> In virtnet_remove, only skb has been freed not the pages in skb
> frags. Here is the patch to fix this, please review it.
>
> Signed-off-by: Shirley Ma <xma@us.ibm.com>
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 2a6e81d..7e629d9 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -978,6 +978,7 @@ static void virtnet_remove(struct virtio_device *vdev)
>
> /* Free our skbs in send and recv queues, if any. */
> while ((skb = __skb_dequeue(&vi->recv)) != NULL) {
> + trim_pages(vi, skb);
> kfree_skb(skb);
> vi->num--;
> }
>
>
>
>
^ permalink raw reply
* Re: 2.6.31-rc5-git2 crash [net/core/flow.c:flow_cache_new_hashrnd]
From: Sachin Sant @ 2009-08-11 5:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, David Miller, linuxppc-dev
In-Reply-To: <1249597385.24311.10.camel@pasglop>
Benjamin Herrenschmidt wrote:
> BTW. Corruption looks like bi_recs... ie, broken yaboot. This was fixed
> recently, yaboot would eventually crap over the kernel for certain sizes
> of the kernel image.
>
> 0x1010 = BI_FIRST
> 0x1013 = BI_BOOTLOADER_ID followed by 0x7961626f6f74 which is
> "yaboot" :-)
> 0x1016 = BI_MACHTYPE
>
Was away from office for few days.
Thanks for the help. The machine under test is running
F11. I will try out the latest yaboot.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [PATCH] Fix Warnings from net/netlink/genetlink.c
From: Johannes Berg @ 2009-08-11 7:36 UTC (permalink / raw)
To: vibi_sreenivasan; +Cc: linux-next, Thomas Graf, netdev
In-Reply-To: <1249975630.2400.7.camel@HunTEr>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
On Tue, 2009-08-11 at 12:57 +0530, vibi sreenivasan wrote:
> Fix following compiler warnings
>
> net/netlink/genetlink.c: In function `genl_register_mc_group':
> net/netlink/genetlink.c:139: warning: 'err' might be used uninitialized in this function
Well, only if there's no netns which can't happen.
However, technical problems prohibit your patch from being applied.
a) you sent it to the wrong list, copying netdev
> Signed-off-by: vibi sreenivasan, CMS COMPUTERS LTD, INDIA <vibi_sreenivasan@cms.com>
b) this isn't correctly formatted, have you actually read
Documentation/SubmittingPatches including the legal text that you're
agreeing to (section 12 of that document)?
johannes
> net/netlink/genetlink.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 575c643..66f6ba0 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -136,7 +136,7 @@ int genl_register_mc_group(struct genl_family *family,
> {
> int id;
> unsigned long *new_groups;
> - int err;
> + int err = 0;
>
> BUG_ON(grp->name[0] == '\0');
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix Warnings from net/netlink/genetlink.c
From: Johannes Berg @ 2009-08-11 9:11 UTC (permalink / raw)
To: vibi_sreenivasan; +Cc: linux-next, Thomas Graf, netdev
In-Reply-To: <1249982110.13065.7.camel@HunTEr>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
Hi,
> > > net/netlink/genetlink.c: In function `genl_register_mc_group':
> > > net/netlink/genetlink.c:139: warning: 'err' might be used uninitialized in this function
> >
> > Well, only if there's no netns which can't happen.
> So how to silence that warning?
Well, I suppose your patch is the best way anyhow, using
uninitialized_var() would seem somewhat dangerous for future
modifications of the function.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix Warnings from net/netlink/genetlink.c
From: vibi sreenivasan @ 2009-08-11 9:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-next, Thomas Graf, netdev
In-Reply-To: <1249976174.5903.16.camel@johannes.local>
Hi Johannes,
On Tue, 2009-08-11 at 09:36 +0200, Johannes Berg wrote:
> On Tue, 2009-08-11 at 12:57 +0530, vibi sreenivasan wrote:
> > Fix following compiler warnings
> >
> > net/netlink/genetlink.c: In function `genl_register_mc_group':
> > net/netlink/genetlink.c:139: warning: 'err' might be used uninitialized in this function
>
> Well, only if there's no netns which can't happen.
So how to silence that warning?
>
> However, technical problems prohibit your patch from being applied.
>
> a) you sent it to the wrong list, copying netdev
>
Sorry i will send it to netdev
> > Signed-off-by: vibi sreenivasan, CMS COMPUTERS LTD, INDIA <vibi_sreenivasan@cms.com>
>
> b) this isn't correctly formatted, have you actually read
> Documentation/SubmittingPatches including the legal text that you're
> agreeing to (section 12 of that document)?
>
Sorry again i will remove the tags at the end & resubmit it again.
Thanks for pointing out the issues.
Thanks & Regards
vibi sreenivasan
> johannes
>
> > net/netlink/genetlink.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> > index 575c643..66f6ba0 100644
> > --- a/net/netlink/genetlink.c
> > +++ b/net/netlink/genetlink.c
> > @@ -136,7 +136,7 @@ int genl_register_mc_group(struct genl_family *family,
> > {
> > int id;
> > unsigned long *new_groups;
> > - int err;
> > + int err = 0;
> >
> > BUG_ON(grp->name[0] == '\0');
> >
>
^ permalink raw reply
* Re: [PATCH 1/2] export cpu_tlbstate to modules
From: Michael S. Tsirkin @ 2009-08-11 11:19 UTC (permalink / raw)
To: H. Peter Anvin
Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm
In-Reply-To: <4A809E32.6060206@zytor.com>
Subject: [PATCH] mm: export use_mm/unuse_mm to modules
vhost net module wants to do copy to/from user from a kernel thread,
which needs use_mm (like what fs/aio has). Move that into mm/ and
export to modules.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
On Mon, Aug 10, 2009 at 03:24:50PM -0700, H. Peter Anvin wrote:
> On 08/10/2009 03:06 PM, Michael S. Tsirkin wrote:
> >> Wouldn't it be a *lot* better to move use_mm() from fs/aio.c into common
> >> code, and export that instead?
> >
> > That's easy too. What would a good place for it be?
>
> Somewhere in mm/, presumably. When in doubt, make it a new file...
>
> -hpa
Like this? Ack?
fs/aio.c | 47 +----------------------------------
include/linux/mmu_context.h | 9 ++++++
mm/Makefile | 2 +-
mm/mmu_context.c | 58 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 69 insertions(+), 47 deletions(-)
create mode 100644 include/linux/mmu_context.h
create mode 100644 mm/mmu_context.c
diff --git a/fs/aio.c b/fs/aio.c
index d065b2c..fc21c23 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -24,6 +24,7 @@
#include <linux/file.h>
#include <linux/mm.h>
#include <linux/mman.h>
+#include <linux/mmu_context.h>
#include <linux/slab.h>
#include <linux/timer.h>
#include <linux/aio.h>
@@ -34,7 +35,6 @@
#include <asm/kmap_types.h>
#include <asm/uaccess.h>
-#include <asm/mmu_context.h>
#if DEBUG > 1
#define dprintk printk
@@ -595,51 +595,6 @@ static struct kioctx *lookup_ioctx(unsigned long ctx_id)
}
/*
- * use_mm
- * Makes the calling kernel thread take on the specified
- * mm context.
- * Called by the retry thread execute retries within the
- * iocb issuer's mm context, so that copy_from/to_user
- * operations work seamlessly for aio.
- * (Note: this routine is intended to be called only
- * from a kernel thread context)
- */
-static void use_mm(struct mm_struct *mm)
-{
- struct mm_struct *active_mm;
- struct task_struct *tsk = current;
-
- task_lock(tsk);
- active_mm = tsk->active_mm;
- atomic_inc(&mm->mm_count);
- tsk->mm = mm;
- tsk->active_mm = mm;
- switch_mm(active_mm, mm, tsk);
- task_unlock(tsk);
-
- mmdrop(active_mm);
-}
-
-/*
- * unuse_mm
- * Reverses the effect of use_mm, i.e. releases the
- * specified mm context which was earlier taken on
- * by the calling kernel thread
- * (Note: this routine is intended to be called only
- * from a kernel thread context)
- */
-static void unuse_mm(struct mm_struct *mm)
-{
- struct task_struct *tsk = current;
-
- task_lock(tsk);
- tsk->mm = NULL;
- /* active_mm is still 'mm' */
- enter_lazy_tlb(mm, tsk);
- task_unlock(tsk);
-}
-
-/*
* Queue up a kiocb to be retried. Assumes that the kiocb
* has already been marked as kicked, and places it on
* the retry run list for the corresponding ioctx, if it
diff --git a/include/linux/mmu_context.h b/include/linux/mmu_context.h
new file mode 100644
index 0000000..70fffeb
--- /dev/null
+++ b/include/linux/mmu_context.h
@@ -0,0 +1,9 @@
+#ifndef _LINUX_MMU_CONTEXT_H
+#define _LINUX_MMU_CONTEXT_H
+
+struct mm_struct;
+
+void use_mm(struct mm_struct *mm);
+void unuse_mm(struct mm_struct *mm);
+
+#endif
diff --git a/mm/Makefile b/mm/Makefile
index 5e0bd64..46c3892 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -11,7 +11,7 @@ obj-y := bootmem.o filemap.o mempool.o oom_kill.o fadvise.o \
maccess.o page_alloc.o page-writeback.o pdflush.o \
readahead.o swap.o truncate.o vmscan.o shmem.o \
prio_tree.o util.o mmzone.o vmstat.o backing-dev.o \
- page_isolation.o mm_init.o $(mmu-y)
+ page_isolation.o mm_init.o mmu_context.o $(mmu-y)
obj-y += init-mm.o
obj-$(CONFIG_PROC_PAGE_MONITOR) += pagewalk.o
diff --git a/mm/mmu_context.c b/mm/mmu_context.c
new file mode 100644
index 0000000..9989c2f
--- /dev/null
+++ b/mm/mmu_context.c
@@ -0,0 +1,58 @@
+/* Copyright (C) 2009 Red Hat, Inc.
+ *
+ * See ../COPYING for licensing terms.
+ */
+
+#include <linux/mm.h>
+#include <linux/mmu_context.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+
+#include <asm/mmu_context.h>
+
+/*
+ * use_mm
+ * Makes the calling kernel thread take on the specified
+ * mm context.
+ * Called by the retry thread execute retries within the
+ * iocb issuer's mm context, so that copy_from/to_user
+ * operations work seamlessly for aio.
+ * (Note: this routine is intended to be called only
+ * from a kernel thread context)
+ */
+void use_mm(struct mm_struct *mm)
+{
+ struct mm_struct *active_mm;
+ struct task_struct *tsk = current;
+
+ task_lock(tsk);
+ active_mm = tsk->active_mm;
+ atomic_inc(&mm->mm_count);
+ tsk->mm = mm;
+ tsk->active_mm = mm;
+ switch_mm(active_mm, mm, tsk);
+ task_unlock(tsk);
+
+ mmdrop(active_mm);
+}
+EXPORT_SYMBOL_GPL(use_mm);
+
+/*
+ * unuse_mm
+ * Reverses the effect of use_mm, i.e. releases the
+ * specified mm context which was earlier taken on
+ * by the calling kernel thread
+ * (Note: this routine is intended to be called only
+ * from a kernel thread context)
+ */
+void unuse_mm(struct mm_struct *mm)
+{
+ struct task_struct *tsk = current;
+
+ task_lock(tsk);
+ tsk->mm = NULL;
+ /* active_mm is still 'mm' */
+ enter_lazy_tlb(mm, tsk);
+ task_unlock(tsk);
+}
+EXPORT_SYMBOL_GPL(unuse_mm);
--
1.6.2.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH net-next 2/6] r8169: differentiate close chipsets in the startup identification message
From: Francois Romieu @ 2009-08-11 5:42 UTC (permalink / raw)
To: David S. Miller; +Cc: edward_hsu, netdev
In-Reply-To: <20090811054039.GA16446@electric-eye.fr.zoreil.com>
The driver displays the same 0x18000000 xid for RTL_GIGA_MAC_VER_06
and RTL_GIGA_MAC_VER_05 whereas the former ought to be identified as
0x98000000.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index eac882b..6c4b879 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2180,7 +2180,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, dev);
if (netif_msg_probe(tp)) {
- u32 xid = RTL_R32(TxConfig) & 0x7cf0f8ff;
+ u32 xid = RTL_R32(TxConfig) & 0x9cf0f8ff;
printk(KERN_INFO "%s: %s at 0x%lx, "
"%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, "
--
1.6.2.5
^ permalink raw reply related
* [PATCH net-next 3/6] r8169: phy init for the 8169sce
From: Francois Romieu @ 2009-08-11 5:43 UTC (permalink / raw)
To: David S. Miller; +Cc: edward_hsu, netdev
In-Reply-To: <20090811054039.GA16446@electric-eye.fr.zoreil.com>
Synced with Realtek's 6.011.00 r8169 driver.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 6c4b879..8672288 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1389,6 +1389,59 @@ static void rtl8169sb_hw_phy_config(void __iomem *ioaddr)
rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
+static void rtl8169sce_hw_phy_config(void __iomem *ioaddr)
+{
+ struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0001 },
+ { 0x04, 0x0000 },
+ { 0x03, 0x00a1 },
+ { 0x02, 0x0008 },
+ { 0x01, 0x0120 },
+ { 0x00, 0x1000 },
+ { 0x04, 0x0800 },
+ { 0x04, 0x9000 },
+ { 0x03, 0x802f },
+ { 0x02, 0x4f02 },
+ { 0x01, 0x0409 },
+ { 0x00, 0xf099 },
+ { 0x04, 0x9800 },
+ { 0x04, 0xa000 },
+ { 0x03, 0xdf01 },
+ { 0x02, 0xdf20 },
+ { 0x01, 0xff95 },
+ { 0x00, 0xba00 },
+ { 0x04, 0xa800 },
+ { 0x04, 0xf000 },
+ { 0x03, 0xdf01 },
+ { 0x02, 0xdf20 },
+ { 0x01, 0x101a },
+ { 0x00, 0xa0ff },
+ { 0x04, 0xf800 },
+ { 0x04, 0x0000 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0001 },
+ { 0x0b, 0x8480 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0001 },
+ { 0x18, 0x67c7 },
+ { 0x04, 0x2000 },
+ { 0x03, 0x002f },
+ { 0x02, 0x4360 },
+ { 0x01, 0x0109 },
+ { 0x00, 0x3022 },
+ { 0x04, 0x2800 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0001 },
+ { 0x17, 0x0cc0 },
+ { 0x1f, 0x0000 }
+ };
+
+ rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
static void rtl8168bb_hw_phy_config(void __iomem *ioaddr)
{
struct phy_reg phy_reg_init[] = {
@@ -1628,6 +1681,9 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_04:
rtl8169sb_hw_phy_config(ioaddr);
break;
+ case RTL_GIGA_MAC_VER_06:
+ rtl8169sce_hw_phy_config(ioaddr);
+ break;
case RTL_GIGA_MAC_VER_07:
case RTL_GIGA_MAC_VER_08:
case RTL_GIGA_MAC_VER_09:
--
1.6.2.5
^ permalink raw reply related
* [PATCH net-next 0/6] r8169 updates
From: Francois Romieu @ 2009-08-11 5:40 UTC (permalink / raw)
To: David S. Miller; +Cc: edward_hsu, netdev
Hi,
this series contains a minor fix (#1), an helper update (#2) as well as
a set of phy related changes taken from Realtek's own driver (#3 .. #6).
--
Ueimor
^ permalink raw reply
* [PATCH net-next 1/6] r8169: fix r8101 quirk dupe
From: Francois Romieu @ 2009-08-11 5:41 UTC (permalink / raw)
To: David S. Miller; +Cc: edward_hsu, netdev, plr.vincent
In-Reply-To: <20090811054039.GA16446@electric-eye.fr.zoreil.com>
Noticed by Vincent Pelletier <plr.vincent@gmail.com>.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b82780d..eac882b 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2757,7 +2757,7 @@ static void rtl_hw_start_8168(struct net_device *dev)
EnableBist | \
Mac_dbgo_oe | \
Force_half_dup | \
- Force_half_dup | \
+ Force_rxflow_en | \
Force_txflow_en | \
Cxpl_dbg_sel | \
ASF | \
--
1.6.2.5
^ permalink raw reply related
* [PATCH net-next 6/6] r8169: phy init for the 8102e
From: Francois Romieu @ 2009-08-11 5:45 UTC (permalink / raw)
To: David S. Miller; +Cc: edward_hsu, netdev
In-Reply-To: <20090811054039.GA16446@electric-eye.fr.zoreil.com>
Synced with Realtek's 1.013.00 r8101 driver.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 93a87aa..8cd8530 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1729,6 +1729,7 @@ static void rtl8102e_hw_phy_config(void __iomem *ioaddr)
mdio_write(ioaddr, 0x1f, 0x0000);
mdio_patch(ioaddr, 0x11, 1 << 12);
mdio_patch(ioaddr, 0x19, 1 << 13);
+ mdio_patch(ioaddr, 0x10, 1 << 15);
rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
--
1.6.2.5
^ permalink raw reply related
* [PATCH net-next 5/6] r8169: phy init for the 8169s
From: Francois Romieu @ 2009-08-11 5:44 UTC (permalink / raw)
To: David S. Miller; +Cc: edward_hsu, netdev
In-Reply-To: <20090811054039.GA16446@electric-eye.fr.zoreil.com>
Synced with Realtek's 6.011.00 r8169 driver.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 116 ++++++++++++++++++++++++++------------------------
1 files changed, 60 insertions(+), 56 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 4470fef..93a87aa 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1222,17 +1222,6 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
.get_ethtool_stats = rtl8169_get_ethtool_stats,
};
-static void rtl8169_write_gmii_reg_bit(void __iomem *ioaddr, int reg,
- int bitnum, int bitval)
-{
- int val;
-
- val = mdio_read(ioaddr, reg);
- val = (bitval == 1) ?
- val | (bitval << bitnum) : val & ~(0x0001 << bitnum);
- mdio_write(ioaddr, reg, val & 0xffff);
-}
-
static void rtl8169_get_mac_version(struct rtl8169_private *tp,
void __iomem *ioaddr)
{
@@ -1328,54 +1317,69 @@ static void rtl_phy_write(void __iomem *ioaddr, struct phy_reg *regs, int len)
static void rtl8169s_hw_phy_config(void __iomem *ioaddr)
{
- struct {
- u16 regs[5]; /* Beware of bit-sign propagation */
- } phy_magic[5] = { {
- { 0x0000, //w 4 15 12 0
- 0x00a1, //w 3 15 0 00a1
- 0x0008, //w 2 15 0 0008
- 0x1020, //w 1 15 0 1020
- 0x1000 } },{ //w 0 15 0 1000
- { 0x7000, //w 4 15 12 7
- 0xff41, //w 3 15 0 ff41
- 0xde60, //w 2 15 0 de60
- 0x0140, //w 1 15 0 0140
- 0x0077 } },{ //w 0 15 0 0077
- { 0xa000, //w 4 15 12 a
- 0xdf01, //w 3 15 0 df01
- 0xdf20, //w 2 15 0 df20
- 0xff95, //w 1 15 0 ff95
- 0xfa00 } },{ //w 0 15 0 fa00
- { 0xb000, //w 4 15 12 b
- 0xff41, //w 3 15 0 ff41
- 0xde20, //w 2 15 0 de20
- 0x0140, //w 1 15 0 0140
- 0x00bb } },{ //w 0 15 0 00bb
- { 0xf000, //w 4 15 12 f
- 0xdf01, //w 3 15 0 df01
- 0xdf20, //w 2 15 0 df20
- 0xff95, //w 1 15 0 ff95
- 0xbf00 } //w 0 15 0 bf00
- }
- }, *p = phy_magic;
- unsigned int i;
+ struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0001 },
+ { 0x06, 0x006e },
+ { 0x08, 0x0708 },
+ { 0x15, 0x4000 },
+ { 0x18, 0x65c7 },
- mdio_write(ioaddr, 0x1f, 0x0001); //w 31 2 0 1
- mdio_write(ioaddr, 0x15, 0x1000); //w 21 15 0 1000
- mdio_write(ioaddr, 0x18, 0x65c7); //w 24 15 0 65c7
- rtl8169_write_gmii_reg_bit(ioaddr, 4, 11, 0); //w 4 11 11 0
+ { 0x1f, 0x0001 },
+ { 0x03, 0x00a1 },
+ { 0x02, 0x0008 },
+ { 0x01, 0x0120 },
+ { 0x00, 0x1000 },
+ { 0x04, 0x0800 },
+ { 0x04, 0x0000 },
- for (i = 0; i < ARRAY_SIZE(phy_magic); i++, p++) {
- int val, pos = 4;
+ { 0x03, 0xff41 },
+ { 0x02, 0xdf60 },
+ { 0x01, 0x0140 },
+ { 0x00, 0x0077 },
+ { 0x04, 0x7800 },
+ { 0x04, 0x7000 },
- val = (mdio_read(ioaddr, pos) & 0x0fff) | (p->regs[0] & 0xffff);
- mdio_write(ioaddr, pos, val);
- while (--pos >= 0)
- mdio_write(ioaddr, pos, p->regs[4 - pos] & 0xffff);
- rtl8169_write_gmii_reg_bit(ioaddr, 4, 11, 1); //w 4 11 11 1
- rtl8169_write_gmii_reg_bit(ioaddr, 4, 11, 0); //w 4 11 11 0
- }
- mdio_write(ioaddr, 0x1f, 0x0000); //w 31 2 0 0
+ { 0x03, 0x802f },
+ { 0x02, 0x4f02 },
+ { 0x01, 0x0409 },
+ { 0x00, 0xf0f9 },
+ { 0x04, 0x9800 },
+ { 0x04, 0x9000 },
+
+ { 0x03, 0xdf01 },
+ { 0x02, 0xdf20 },
+ { 0x01, 0xff95 },
+ { 0x00, 0xba00 },
+ { 0x04, 0xa800 },
+ { 0x04, 0xa000 },
+
+ { 0x03, 0xff41 },
+ { 0x02, 0xdf20 },
+ { 0x01, 0x0140 },
+ { 0x00, 0x00bb },
+ { 0x04, 0xb800 },
+ { 0x04, 0xb000 },
+
+ { 0x03, 0xdf41 },
+ { 0x02, 0xdc60 },
+ { 0x01, 0x6340 },
+ { 0x00, 0x007d },
+ { 0x04, 0xd800 },
+ { 0x04, 0xd000 },
+
+ { 0x03, 0xdf01 },
+ { 0x02, 0xdf20 },
+ { 0x01, 0x100a },
+ { 0x00, 0xa0ff },
+ { 0x04, 0xf800 },
+ { 0x04, 0xf000 },
+
+ { 0x1f, 0x0000 },
+ { 0x0b, 0x0000 },
+ { 0x00, 0x9200 }
+ };
+
+ rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
static void rtl8169sb_hw_phy_config(void __iomem *ioaddr)
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] fix memory leak in virtio_net
From: Avi Kivity @ 2009-08-11 11:52 UTC (permalink / raw)
To: Shirley Ma; +Cc: kvm, linux-kernel, netdev, Rusty Russell
In-Reply-To: <1249934708.7400.10.camel@localhost.localdomain>
(copying Rusty, the virtio maintainer)
On 08/10/2009 11:05 PM, Shirley Ma wrote:
> Whild reading virtio code, I found some memory leak in removing
> virtio_net.
>
> In virtnet_remove, only skb has been freed not the pages in skb
> frags. Here is the patch to fix this, please review it.
>
>
There were indeed reports of virtio ooming; this might be the cause.
> Signed-off-by: Shirley Ma<xma@us.ibm.com>
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 2a6e81d..7e629d9 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -978,6 +978,7 @@ static void virtnet_remove(struct virtio_device *vdev)
>
> /* Free our skbs in send and recv queues, if any. */
> while ((skb = __skb_dequeue(&vi->recv)) != NULL) {
> + trim_pages(vi, skb);
> kfree_skb(skb);
> vi->num--;
> }
>
>
>
>
>
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Neil Horman @ 2009-08-11 11:02 UTC (permalink / raw)
To: Bill Fink
Cc: Andrew Gallatin, Brice Goglin, Linux Network Developers,
Yinghai Lu
In-Reply-To: <20090811033210.6b422ed1.billfink@mindspring.com>
On Tue, Aug 11, 2009 at 03:32:10AM -0400, Bill Fink wrote:
> On Sat, 8 Aug 2009, Neil Horman wrote:
>
> > On Sat, Aug 08, 2009 at 02:21:36PM -0400, Andrew Gallatin wrote:
> > > Neil Horman wrote:
> > >> On Sat, Aug 08, 2009 at 07:08:20AM -0400, Andrew Gallatin wrote:
> > >>> Bill Fink wrote:
> > >>>> On Fri, 07 Aug 2009, Andrew Gallatin wrote:
> > >>>>
> > >>>>> Bill Fink wrote:
> > >>>>>
> > >>>>>> All sysfs local_cpus values are the same (00000000,000000ff),
> > >>>>>> so yes they are also wrong.
> > >>>>> How were you handling IRQ binding? If local_cpus is wrong,
> > >>>>> the irqbalance will not be able to make good decisions about
> > >>>>> where to bind the NICs' IRQs. Did you try manually binding
> > >>>>> each NICs's interrupt to a separate CPU on the correct node?
> > >>>> Yes, all the NIC IRQs were bound to a CPU on the local NUMA node,
> > >>>> and the nuttcp application had its CPU affinity set to the same
> > >>>> CPU with its memory affinity bound to the same local NUMA node.
> > >>>> And the irqbalance daemon wasn't running.
> > >>> I must be misunderstanding something. I had thought that
> > >>> alloc_pages() on NUMA would wind up doing alloc_pages_current(), which
> > >>> would allocate based on default policy which (if not interleaved)
> > >>> should allocate from the current NUMA node. And since restocking the
> > >>> RX ring happens from a the driver's NAPI softirq context, then it
> > >>> should always be restocking on the same node the memory is destined to
> > >>> be consumed on.
> > >>>
> > >>> Do I just not understand how alloc_pages() works on NUMA?
> > >>>
> > >>
> > >> Thats how alloc_works, but most drivers use netdev_alloc_skb to refill their rx
> > >> ring in their napi context. netdev_alloc_skb specifically allocates an skb from
> > >> memory in the node that the actually NIC is local to (rather than the cpu that
> > >> the interrupt is running on). That cuts out cross numa node chatter when the
> > >> device is dma-ing a frame from the hardware to the allocated skb. The offshoot
> > >> of that however (especially in 10G cards with lots of rx queues whos interrupts
> > >> are spread out through the system) is that the irq affinity for a given irq has
> > >> an increased risk of not being on the same node as the skb memory. The ftrace
> > >> module I referenced earlier will help illustrate this, as well as cases where
> > >> its causing applications to run on processors that create lots of cross-node
> > >> chatter.
> > >
> > > One thing worth noting is that myri10ge is rather unusual in that
> > > it fills its RX rings with pages, then attaches them to skbs after
> > > the receive is done. Given how (I think) alloc_page() works, I
> > > don't understand why correct CPU binding does not have the same
> > > benefit as Bill's patch to assign the NUMA node manually.
> > >
> > > I'm certainly willing to change to myri10ge to use alloc_pages_node()
> > > based on NIC locality, if that provides a benefit, but I'd really
> > > like to understand why CPU binding is not helping.
>
> I originally tried to just use alloc_pages_node() instead of alloc_pages(),
> but it didn't help. As mentioned in an earlier e-mail, that seems to
> be because I discovered that doing:
>
> find /sys -name numa_node -exec grep . {} /dev/null \;
>
> revealed that the NUMA node associated with _all_ the PCI devices was
> always 0, when at least some of them should have been associated with
> NUMA node 2, including 6 of the 12 Myricom 10-GigE devices.
>
> I discovered today that the NUMA node cpulist/cpumap is also wrong.
> A cat of /sys/devices/system/node/node0/cpulist returns "0-7" (with a
> cpumask of 00000000,000000ff), while the cpulist for node2 is empty
> (with a cpumask of 00000000,00000000). The distance is correct,
> with "10 20" for node 0 and "20 10" for node2.
>
> Since there seems to be an underlying kernel issue here, what would
> be the proper place to address the apparently incorrect assignment
> of NUMA node information for this system?
>
Well, its possible that there is a kernel bug, but those tables that you're
reading are parsed IIRC directly from the systems SRAT table in acpi space. I'm
not sure of a way to read those directly from user space, but IIRC if you turn
on apic debugging they will get dumped out. It sounds as though perhaps your
SRAT table is incorrectly reporting the location of your devices. You may also
want to look at dumping out your smbios via dmidecode to see where that places
all your 10G nic cards.
Neil
>
^ permalink raw reply
* [PATCH net-next 4/6] r8169: phy init for the 8169scd
From: Francois Romieu @ 2009-08-11 5:44 UTC (permalink / raw)
To: David S. Miller; +Cc: edward_hsu, netdev
In-Reply-To: <20090811054039.GA16446@electric-eye.fr.zoreil.com>
Synced with Realtek's 6.011.00 r8169 driver.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pci_ids.h | 2 +
2 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 8672288..4470fef 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1389,6 +1389,71 @@ static void rtl8169sb_hw_phy_config(void __iomem *ioaddr)
rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
+static void rtl8169scd_hw_phy_config_quirk(struct rtl8169_private *tp,
+ void __iomem *ioaddr)
+{
+ struct pci_dev *pdev = tp->pci_dev;
+ u16 vendor_id, device_id;
+
+ pci_read_config_word(pdev, PCI_SUBSYSTEM_VENDOR_ID, &vendor_id);
+ pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, &device_id);
+
+ if ((vendor_id != PCI_VENDOR_ID_GIGABYTE) || (device_id != 0xe000))
+ return;
+
+ mdio_write(ioaddr, 0x1f, 0x0001);
+ mdio_write(ioaddr, 0x10, 0xf01b);
+ mdio_write(ioaddr, 0x1f, 0x0000);
+}
+
+static void rtl8169scd_hw_phy_config(struct rtl8169_private *tp,
+ void __iomem *ioaddr)
+{
+ struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0001 },
+ { 0x04, 0x0000 },
+ { 0x03, 0x00a1 },
+ { 0x02, 0x0008 },
+ { 0x01, 0x0120 },
+ { 0x00, 0x1000 },
+ { 0x04, 0x0800 },
+ { 0x04, 0x9000 },
+ { 0x03, 0x802f },
+ { 0x02, 0x4f02 },
+ { 0x01, 0x0409 },
+ { 0x00, 0xf099 },
+ { 0x04, 0x9800 },
+ { 0x04, 0xa000 },
+ { 0x03, 0xdf01 },
+ { 0x02, 0xdf20 },
+ { 0x01, 0xff95 },
+ { 0x00, 0xba00 },
+ { 0x04, 0xa800 },
+ { 0x04, 0xf000 },
+ { 0x03, 0xdf01 },
+ { 0x02, 0xdf20 },
+ { 0x01, 0x101a },
+ { 0x00, 0xa0ff },
+ { 0x04, 0xf800 },
+ { 0x04, 0x0000 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0001 },
+ { 0x10, 0xf41b },
+ { 0x14, 0xfb54 },
+ { 0x18, 0xf5c7 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0001 },
+ { 0x17, 0x0cc0 },
+ { 0x1f, 0x0000 }
+ };
+
+ rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+
+ rtl8169scd_hw_phy_config_quirk(tp, ioaddr);
+}
+
static void rtl8169sce_hw_phy_config(void __iomem *ioaddr)
{
struct phy_reg phy_reg_init[] = {
@@ -1681,6 +1746,9 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_04:
rtl8169sb_hw_phy_config(ioaddr);
break;
+ case RTL_GIGA_MAC_VER_05:
+ rtl8169scd_hw_phy_config(tp, ioaddr);
+ break;
case RTL_GIGA_MAC_VER_06:
rtl8169sce_hw_phy_config(ioaddr);
break;
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 73b46b6..fdc3110 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1984,6 +1984,8 @@
#define PCI_VENDOR_ID_SAMSUNG 0x144d
+#define PCI_VENDOR_ID_GIGABYTE 0x1458
+
#define PCI_VENDOR_ID_AMBIT 0x1468
#define PCI_VENDOR_ID_MYRICOM 0x14c1
--
1.6.2.5
^ permalink raw reply related
* Re: [Bugme-new] [Bug 13954] New: Oops in rtnetlink code when creating can device
From: Andrew Morton @ 2009-08-11 4:54 UTC (permalink / raw)
To: dbaryshkov
Cc: bugzilla-daemon, bugme-daemon, Urs Thuermann, Oliver Hartkopp,
Lothar Wassmann, netdev
In-Reply-To: <bug-13954-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 10 Aug 2009 11:34:28 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13954
Thanks.
> Summary: Oops in rtnetlink code when creating can device
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.30-rc5
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: dbaryshkov@gmail.com
> Regression: No
>
>
> I've got a nice oops when looking around new CAN code in kernel.
>
> root@qemux86:~# ip link add type can
> [ 713.113325] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420
> [ 713.114920] *pdpt = 00000000061bd001 *pde = 0000000000000000
> [ 713.115627] Oops: 0000 [#1] SMP
> [ 713.115972] last sysfs file:
> /sys/devices/virtual/backlight/fujitsu-laptop/brightness
> [ 713.116137] Modules linked in:
> [ 713.116137]
> [ 713.116137] Pid: 1803, comm: ip Not tainted (2.6.31-rc5 #68)
> [ 713.116137] EIP: 0060:[<c13eecab>] EFLAGS: 00000246 CPU: 0
> [ 713.116137] EIP is at register_netdevice+0xab/0x420
> [ 713.116137] EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000001
> [ 713.116137] ESI: c72c6000 EDI: 00000000 EBP: c61abb54 ESP: c61abb34
> [ 713.116137] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 713.116137] Process ip (pid: 1803, ti=c61aa000 task=c6f395e0
> task.ti=c61aa000)
> [ 713.116137] Stack:
> [ 713.116137] c61abb54 c13f732f 00000001 c61abbb4 894f908a 00000000 c72c6000
> 00000000
> [ 713.116137] <0> c61abc74 c13f8278 c61abbb4 00000010 c165d494 c1652090
> c61abc18 c6f3d028
> [ 713.116137] <0> 894f908a 894f908a c61abc18 c13f7da0 c61abc74 c13f7f46
> 00000008 c1546f80
> [ 713.116137] Call Trace:
> [ 713.116137] [<c13f732f>] ? rtnl_create_link+0x4f/0x130
> [ 713.116137] [<c13f8278>] ? rtnl_newlink+0x4d8/0x4e0
> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0
> [ 713.116137] [<c13f7f46>] ? rtnl_newlink+0x1a6/0x4e0
> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0
> [ 713.116137] [<c13f7d00>] ? rtnetlink_rcv_msg+0x180/0x220
> [ 713.116137] [<c13f7b80>] ? rtnetlink_rcv_msg+0x0/0x220
> [ 713.116137] [<c1400e56>] ? netlink_rcv_skb+0x86/0xb0
> [ 713.116137] [<c13f7b5a>] ? rtnetlink_rcv+0x2a/0x50
> [ 713.116137] [<c140085b>] ? netlink_unicast+0x29b/0x2b0
> [ 713.116137] [<c1400a5b>] ? netlink_sendmsg+0x1eb/0x2f0
> [ 713.116137] [<c13db72b>] ? sock_sendmsg+0xdb/0x110
> [ 713.116137] [<c10bef17>] ? __d_instantiate+0x57/0xe0
> [ 713.116137] [<c1053cd0>] ? autoremove_wake_function+0x0/0x60
> [ 713.116137] [<c110a75f>] ? ext3_lookup+0xaf/0x130
> [ 713.116137] [<c10bfd24>] ? d_alloc+0x114/0x1a0
> [ 713.116137] [<c10c5a95>] ? mntput_no_expire+0x25/0xe0
> [ 713.116137] [<c11b518e>] ? copy_from_user+0x3e/0x150
> [ 713.116137] [<c11b518e>] ? copy_from_user+0x3e/0x150
> [ 713.116137] [<c13e55cb>] ? verify_iovec+0x3b/0xc0
> [ 713.116137] [<c13db8b8>] ? sys_sendmsg+0x158/0x280
> [ 713.116137] [<c107a22c>] ? unlock_page+0x4c/0x70
> [ 713.116137] [<c108efb8>] ? __do_fault+0x378/0x470
> [ 713.116137] [<c10a81d3>] ? lookup_object+0x33/0x80
> [ 713.116137] [<c107a820>] ? filemap_fault+0x0/0x3c0
> [ 713.116137] [<c1029ba9>] ? kmemcheck_mark_freed+0x19/0x40
> [ 713.116137] [<c11b518e>] ? copy_from_user+0x3e/0x150
> [ 713.116137] [<c13dcd97>] ? sys_socketcall+0xb7/0x290
> [ 713.116137] [<c10230fa>] ? do_page_fault+0x18a/0x2a0
> [ 713.116137] [<c100324f>] ? sysenter_do_call+0x12/0x26
> [ 713.116137] Code: ff ff 3b 96 84 02 00 00 72 d6 8b 86 b4 00 00 00 c7 86 00
> 02 00 00 00 00 00 00 c7 86 04 02 00 00 ff ff ff ff c7 46 4c ff ff ff ff <8b> 10
> 85 d2 74 2f 89 f0 ff d2 83 f8 00 89 c7 74 24 b8 fb ff ff
> [ 713.116137] EIP: [<c13eecab>] register_netdevice+0xab/0x420 SS:ESP
> 0068:c61abb34
> [ 713.116137] CR2: 0000000000000000
> [ 713.142874] ---[ end trace 883d4085b7c1045b ]---
>
Boy, the backtrace is a bit hard to follow. Maybe enabling frame
pointers would clean it up.
^ permalink raw reply
* [PATCH] revert TCP retransmission backoff on ICMP destination unreachable
From: Damian Lukowski @ 2009-08-11 11:27 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
This patch is a proof-of-concept related to the draft "Make TCP more
Robust to Long Connectivity Disruptions"
(http://tools.ietf.org/html/draft-zimmermann-tcp-lcd-01).
Exponential backoff is TCP's standard behaviour during long connectivity
disruptions, which is a countermeasure against network congestion.
If congestion can be excluded as the reason for RTO retransmission loss,
backoff is not desirable, as it yields longer TCP recovery times, when
the communication path is repaired shortly after an unsuccessful
retransmission probe.
Here, an ICMP host/network unreachable message, whose payload fits to
TCPs SND.UNA, is taken as an indication that the RTO retransmission has
not been lost due to congestion, but because of a route failure
somewhere along the path. On receipt of such a message, the timeout is
halved (in order to revert to doubling after the retransmission).
With true congestion, a router won't trigger such a message and the
patched TCP will operate as standard TCP.
Comments are appreciated, especially regarding eventual side effects
with the zero window probing mechanism.
In Linux, the RTO retransmisson mechanism is coupled to the zero window
probing mechanism, but is not intended to be changed. I hope I have not
missed something, here.
---
[-- Attachment #2: TCP_ICMP_2.6.30.4.patch --]
[-- Type: text/plain, Size: 4322 bytes --]
diff -Naur linux-2.6.30.4-vanilla/include/net/tcp.h linux-2.6.30.4-tcp-icmp/include/net/tcp.h
--- linux-2.6.30.4-vanilla/include/net/tcp.h 2009-07-31 00:34:47.000000000 +0200
+++ linux-2.6.30.4-tcp-icmp/include/net/tcp.h 2009-08-11 11:28:23.162009835 +0200
@@ -1220,6 +1220,8 @@
#define tcp_for_write_queue_from_safe(skb, tmp, sk) \
skb_queue_walk_from_safe(&(sk)->sk_write_queue, skb, tmp)
+#define retrans_overstepped(sk, boundary) (inet_csk(sk)->icsk_retransmits && (tcp_time_stamp - tcp_sk(sk)->retrans_stamp) >= TCP_RTO_MIN*(2 << boundary))
+
static inline struct sk_buff *tcp_send_head(struct sock *sk)
{
return sk->sk_send_head;
diff -Naur linux-2.6.30.4-vanilla/net/ipv4/tcp_ipv4.c linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_ipv4.c
--- linux-2.6.30.4-vanilla/net/ipv4/tcp_ipv4.c 2009-07-31 00:34:47.000000000 +0200
+++ linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_ipv4.c 2009-08-11 11:28:33.572009505 +0200
@@ -332,11 +332,14 @@
{
struct iphdr *iph = (struct iphdr *)skb->data;
struct tcphdr *th = (struct tcphdr *)(skb->data + (iph->ihl << 2));
+
+ struct inet_connection_sock *icsk;
struct tcp_sock *tp;
struct inet_sock *inet;
const int type = icmp_hdr(skb)->type;
const int code = icmp_hdr(skb)->code;
struct sock *sk;
+ struct sk_buff *skb_r;
__u32 seq;
int err;
struct net *net = dev_net(skb->dev);
@@ -367,6 +370,7 @@
if (sk->sk_state == TCP_CLOSE)
goto out;
+ icsk = inet_csk(sk);
tp = tcp_sk(sk);
seq = ntohl(th->seq);
if (sk->sk_state != TCP_LISTEN &&
@@ -393,6 +397,34 @@
}
err = icmp_err_convert[code].errno;
+
+ /* check if ICMP unreachable messages allow revert of back-off */
+ if ((code != ICMP_NET_UNREACH && code != ICMP_HOST_UNREACH) || seq != tp->snd_una
+ || !icsk->icsk_retransmits || !icsk->icsk_backoff) break;
+
+ icsk->icsk_backoff--;
+ icsk->icsk_rto >>= 1;
+
+ skb_r = skb_peek(&sk->sk_write_queue);
+ BUG_ON(!skb_r);
+
+ if (sock_owned_by_user(sk)) {
+ // Deferring retransmission clocked by ICMP due to locked socket.
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
+ min(icsk->icsk_rto, TCP_RESOURCE_PROBE_INTERVAL),
+ TCP_RTO_MAX);
+ }
+
+ if (tcp_time_stamp - TCP_SKB_CB(skb_r)->when > inet_csk(sk)->icsk_rto) {
+ // RTO revert clocked out retransmission.
+ tcp_retransmit_skb(sk, skb_r);
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX);
+ } else {
+ //RTO revert shortened timer.
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
+ icsk->icsk_rto - (tcp_time_stamp - TCP_SKB_CB(skb_r)->when), TCP_RTO_MAX);
+ }
+
break;
case ICMP_TIME_EXCEEDED:
err = EHOSTUNREACH;
diff -Naur linux-2.6.30.4-vanilla/net/ipv4/tcp_timer.c linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_timer.c
--- linux-2.6.30.4-vanilla/net/ipv4/tcp_timer.c 2009-07-31 00:34:47.000000000 +0200
+++ linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_timer.c 2009-08-11 11:28:33.557009931 +0200
@@ -143,7 +143,7 @@
dst_negative_advice(&sk->sk_dst_cache);
retry_until = icsk->icsk_syn_retries ? : sysctl_tcp_syn_retries;
} else {
- if (icsk->icsk_retransmits >= sysctl_tcp_retries1) {
+ if (retrans_overstepped(sk, sysctl_tcp_retries1)) {
/* Black hole detection */
tcp_mtu_probing(icsk, sk);
@@ -156,12 +156,12 @@
retry_until = tcp_orphan_retries(sk, alive);
- if (tcp_out_of_resources(sk, alive || icsk->icsk_retransmits < retry_until))
+ if (tcp_out_of_resources(sk, alive || !retrans_overstepped(sk, retry_until)))
return 1;
}
}
- if (icsk->icsk_retransmits >= retry_until) {
+ if (retrans_overstepped(sk, retry_until)) {
/* Has it gone just too far? */
tcp_write_err(sk);
return 1;
@@ -385,7 +385,7 @@
out_reset_timer:
icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX);
- if (icsk->icsk_retransmits > sysctl_tcp_retries1)
+ if (retrans_overstepped(sk, sysctl_tcp_retries1))
__sk_dst_reset(sk);
out:;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox