On Sat, 8 Sep 2007 17:36:21 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 8 Sep 2007 13:08:37 -0700 (PDT)
> [EMAIL PROTECTED] wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=8996
> >
> >Summary: atl1 driver cause kernel oops IF ram > 4Gyte
> > and a lot of network
On Sat, 8 Sep 2007 13:08:37 -0700 (PDT) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8996
>
>Summary: atl1 driver cause kernel oops IF ram > 4Gyte and a lot
> of network load
>Product: Networking
>Version: 2.5
>
On Sat, Sep 08, 2007 at 03:15:34PM -0600, Eric W. Biederman wrote:
>
> This is the basic infrastructure needed to support network
> namespaces. This infrastructure is:
> - Registration functions to support initializing per network
> namespace data when a network namespaces is created or destroy
Until we support multiple network namespaces with netfilter only allow
netfilter configuration in the initial network namespace.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
Ooops I overlooked this one on my first path through when gathering up this
patchset.
net/netfilter/nf_socko
The simplest thing to implement is moving network devices between
namespaces. However with the same attribute IFLA_NET_NS_PID we can
easily implement creating devices in the destination network
namespace as well. However that is a little bit trickier so this
patch sticks to what is simple and ea
This patch introduces NETIF_F_NETNS_LOCAL a flag to indicate
a network device is local to a single network namespace and
should never be moved. Useful for pseudo devices that we
need an instance in each network namespace (like the loopback
device) and for any device we find that cannot handle mul
When forcibly changing the network namespace of a device
I need something that can generate a name for the device
in the new namespace without overwriting the old name.
__dev_alloc_name provides me that functionality.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/core/dev.c | 4
Each netlink socket will live in exactly one network namespace,
this includes the controlling kernel sockets.
This patch updates all of the existing netlink protocols
to only support the initial network namespace. Request
by clients in other namespaces will get -ECONREFUSED.
As they would if the
Every user of the network device notifiers is either a protocol
stack or a pseudo device. If a protocol stack that does not have
support for multiple network namespaces receives an event for a
device that is not in the initial network namespace it quite possibly
can get confused and do the wrong
This patch modifies every packet receive function
registered with dev_add_pack() to drop packets if they
are not from the initial network namespace.
This should ensure that the various network stacks do
not receive packets in a anything but the initial network
namespace until the code has been co
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 19:26:21 -0700
> David, I see that you have already done the revert in your 2.6.23 tree.
I intend to revert that and only push the tg3 fix into
2.6.23
Earlier I had the idea to undo the quirk too, but that's
something I decided was
Except for carefully selected pseudo devices all network
interfaces should start out in the initial network namespace.
Ultimately it will be register_netdev that examines what
dev->nd_net is set to and places a device in a network namespace.
This patch modifies alloc_netdev to initialize the netw
This patch passes in the namespace a new socket should be created in
and has the socket code do the appropriate reference counting. By
virtue of this all socket create methods are touched. In addition
the socket create methods are modified so that they will fail if
you attempt to create a socket
Sockets need to get a reference to their network namespace,
or possibly a simple hold if someone registers on the network
namespace notifier and will free the sockets when the namespace
is going to be destroyed.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
include/net/inet_timewait_s
Please note that network devices do not increase the count
count on the network namespace. The are inside the network
namespace and so the network namespace tag is in the nature
of a back pointer and so getting and putting the network namespace
is unnecessary.
Signed-off-by: Eric W. Biederman <[
This is the network namespace from which all which all sockets
and anything else under user control ultimately get their network
namespace parameters.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
include/linux/init_task.h |2 ++
include/linux/nsproxy.h |1 +
2 files changed
This is the basic infrastructure needed to support network
namespaces. This infrastructure is:
- Registration functions to support initializing per network
namespace data when a network namespaces is created or destroyed.
- struct net. The network namespace data structure.
This structure wi
The current implementation of dev_ifname makes maintenance difficult
because updates to the implementation of the ioctl have to made in two
places. So this patch updates dev_ifname32 to do a classic 32/64
structure conversion and call sys_ioctl like the rest of the
compat calls do.
Signed-off-by
This slightly improves code safetly and clarity.
Later network namespace patches touch this code so this is a
preliminary cleanup.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/appletalk/aarp.c |7 ---
net/appletalk/ddp.c |4 +++-
2 files changed, 7 insertions(+), 4
The following patchset was built against the latest net-2.6.24
tree, and should be safe to apply assume not issues are found during
the review. In the interest of keeping the patcheset to a reviewable
size, just the core of the network stack has been covered.
The 10,000 foot overview. We want
remove asm/bitops.h includes
including asm/bitops directly may cause compile errors. don't include it
and include linux/bitops instead. next patch will deny including asm header
directly.
Cc: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 3c05eef3d0a9806
remove setup platform device from jazzsonic, which is done in arch code now
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/jazzsonic.c b/drivers/net/jazzsonic.c
index 75f6f44..435060a 100644
--- a/drivers/net/jazzsonic.c
+++ b/drivers/net/jazzsonic.c
@@ -45,7
On Friday 07 September 2007, J. Bruce Fields wrote:
> On Fri, Sep 07, 2007 at 05:49:55PM +0200, Wolfgang Walter wrote:
> > Hello,
> >
> > 3) For unknown reason these sockets then remain open. In the morning
> > when people start their workstation again we therefor not only get a
> > lot of these
On Sat, 2007-09-08 at 07:49 -0700, Michael Chan wrote:
> Christoph Hellwig wrote:
>
> > Most of it should just go away, and the other bits shouldn't
> > change over
> > the lifetime of the driver except for additions. So there
> > really isn't
> > any point in auto-generating it.
> >
>
> Yes,
The following is the current contents of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
(recently rebased)
The 'upstream' branch is what I will push upstream for 2.6.24, once
the merge window opens. I also have a pile in my inbox I need to go
over, while I was away at confe
James Chapman ([EMAIL PROTECTED]) wrote:
> Hi Mandeep,
>
> Mandeep Singh Baines wrote:
>> Hi James,
>> I like the idea of staying in poll longer.
>> My comments are similar to what Jamal and Stephen have already
>> said.
>> A tunable (via sysfs) would be nice.
>> A timer might be preferred to jiff
James Chapman <[EMAIL PROTECTED]> writes:
>
> Clearly, keeping a device in polled mode for 1-2 jiffies
1-2 jiffies can be a long time on a HZ=100 kernel (20ms). A fast CPU
could do a lot of loops in this time, which would be waste of power
and CPU time.
On some platforms the precise timers (lik
Add a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
Documentation/rfkill.txt | 88 ++
1 files changed, 88 insertions(+
This patch will add support for UWB keys to rfkill,
support for this has been requested by Inaky.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
CC: Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
---
include/linux/input.h |1 +
include/linux/rfkill.h|2 ++
net/rfkill/rfkill-input.c |
As Dmitry pointed out earlier, rfkill-input.c
doesn't support irda because there are no users
and we shouldn't add unrequired KEY_ defines.
However, RFKILL_TYPE_IRDA was defined in the
rfkill.h header file and would confuse people
about whether it is implemented or not.
This patch removes IRDA su
Hi Dmitry,
I have a few rfkill related patches for which I would prefer if you to could
take a look at before I send them for inclusion.
Thanks. :)
Ivo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
Christoph Hellwig wrote:
> Most of it should just go away, and the other bits shouldn't
> change over
> the lifetime of the driver except for additions. So there
> really isn't
> any point in auto-generating it.
>
Yes, I agree with Mike Christie on this. These values in
question are defined
On Sat, Sep 08, 2007 at 07:32:27AM -0400, Jeff Garzik wrote:
> FUJITA Tomonori wrote:
> >Yeah, iommu code ignores the lld limitations (the problem is that the
> >lld limitations are in request_queue and iommu code can't access to
> >request_queue). There is no way to tell iommu code about the lld
>
On Wed, Sep 05, 2007 at 02:27:02PM -0700, Anil Veerabhadrappa wrote:
> This is a very tricky proposal as this header file is automatically
> generated by a well defined process and is shared between various driver
> supporting multiple platform/OS and the firmware. If it is not of a big
> issue I w
FUJITA Tomonori wrote:
Yeah, iommu code ignores the lld limitations (the problem is that the
lld limitations are in request_queue and iommu code can't access to
request_queue). There is no way to tell iommu code about the lld
limitations.
This fact very much wants fixing.
Jeff
-
To
Hi all,
Here is a list of some known regressions in 2.6.23-rc5
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Hi all,
Here is a list of some known regressions in 2.6.23-rc5.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Linus Torvalds
On Fri, 07 Sep 2007 17:36:47 -0500
Mike Christie <[EMAIL PROTECTED]> wrote:
> > +/*
> > + * map SG list
> > + */
> > +static int bnx2i_map_sg(struct bnx2i_hba *hba, struct bnx2i_cmd *cmd)
> > +{
> > + struct scsi_cmnd *sc = cmd->scsi_cmd;
> > + struct iscsi_bd *bd = cmd->bd_tbl->bd_tbl;
> > +
Kok, Auke writes:
> david,
>
> while testing this patch I noticed that the poll routine is now called
> 100% of the time, and since I'm not doing much different than before, I
> suspec that something in the new napi code is staying in polling mode
> forever? Since e1000e is pretty much t
39 matches
Mail list logo
