Re: [stable] [PATCH] ipx: header length validation needed
On Mon, Aug 07, 2006 at 04:36:02PM -0700, Stephen Hemminger wrote: > This patch will linearize and check there is enough data. > It handles the pprop case as well as avoiding a whole audit of > the routing code. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> queued to -stable, thanks. greg k-h - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take6 1/3] kevent: Core files.
On Wed, Aug 09, 2006 at 11:42:35PM -0700, David Miller ([EMAIL PROTECTED]) wrote: > > > > + k->kevent_entry.next = LIST_POISON1; > > > > + k->storage_entry.prev = LIST_POISON2; > > > > + k->ready_entry.next = LIST_POISON1; > > > > > > Nope ;) > > > > I use pointer checks to determine if entry is in the list or not, why it > > is frowned upon here? > > As Andrew mentioned in another posting, these poison macros > are likely to simply go away some day, so you should not use > them. They exist for ages and sudently can go away?.. > If you want pointer encoded tags you use internally, define your own. I think if I will add code like this list_del(&k->entry); k->entry.prev = KEVENT_POISON1; k->entry.next = KEVENT_POISON2; I will be suggested to make myself a lobotomy. I have enough space in flags in each kevent, so I will use some bits there. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take6 1/3] kevent: Core files.
From: Evgeniy Polyakov <[EMAIL PROTECTED]> Date: Thu, 10 Aug 2006 10:14:33 +0400 > On Wed, Aug 09, 2006 at 03:21:27PM -0700, Andrew Morton ([EMAIL PROTECTED]) > wrote: > > On big-endian machines, this pointer will appear to be word-swapped as far > > as a 64-bit kernel is concerned. Or something. > > > > IOW: What's going on here?? > > It is user data - I put there a union just to simplify userspace, so it > sould not require some typecasting. And this is consistent with similar mechianism we use for netlink socket dumping, so that we don't have compat layer crap just because we provide a place for the user to store his pointer or whatever there. > > > + k->kevent_entry.next = LIST_POISON1; > > > + k->storage_entry.prev = LIST_POISON2; > > > + k->ready_entry.next = LIST_POISON1; > > > > Nope ;) > > I use pointer checks to determine if entry is in the list or not, why it > is frowned upon here? As Andrew mentioned in another posting, these poison macros are likely to simply go away some day, so you should not use them. If you want pointer encoded tags you use internally, define your own. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
On Wed, 2006-08-09 at 16:58 -0700, David Miller wrote: > From: Peter Zijlstra <[EMAIL PROTECTED]> > Date: Wed, 09 Aug 2006 16:07:20 +0200 > > > Hmm, what does sk_buff::input_dev do? That seems to store the initial > > device? > > You can run grep on the tree just as easily as I can which is what I > did to answer this question. It only takes a few seconds of your > time to grep the source tree for things like "skb->input_dev", so > would you please do that before asking more questions like this? That is exactly what I did, but I wanted a bit of confirmation. Sorry if it offends you, but I'm a bit new to this network thing. > It does store the initial device, but as Thomas tried so hard to > explain to you guys these device pointers in the skb are transient and > you cannot refer to them outside of packet receive processing. Yes, I understood that after Thomas' last mail. > The reason is that there is no refcounting performed on these devices > when they are attached to the skb, for performance reasons, and thus > the device can be downed, the module for it removed, etc. long before > the skb is freed up. I understood that, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ehea: header files
Hi Jan-Bernd,
I haven't read all of this, but a few things caught my eye ...
cheers
On Wed, 2006-08-09 at 10:39 +0200, Jan-Bernd Themann wrote:
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
>
>
> drivers/net/ehea/ehea.h| 452
> +
> drivers/net/ehea/ehea_hw.h | 319 +++
> 2 files changed, 771 insertions(+)
>
>
>
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
> 16:00:00.0 -0800
> +++ kernel/drivers/net/ehea/ehea.h2006-08-08 23:59:39.927452928 -0700
> @@ -0,0 +1,452 @@
> +/*
> + * linux/drivers/net/ehea/ehea.h
> + *
> + * eHEA ethernet device driver for IBM eServer System p
> + *
> + * (C) Copyright IBM Corp. 2006
> + *
> + * Authors:
> + * Christoph Raisch <[EMAIL PROTECTED]>
> + * Jan-Bernd Themann <[EMAIL PROTECTED]>
> + * Heiko-Joerg Schick <[EMAIL PROTECTED]>
> + * Thomas Klein <[EMAIL PROTECTED]>
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2, or (at your option)
> + * any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#ifndef __EHEA_H__
> +#define __EHEA_H__
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define EHEA_DRIVER_NAME "IBM eHEA"
> +#define EHEA_DRIVER_VERSION "EHEA_0015"
> +
> +#define NET_IP_ALIGN 0
> +#define EHEA_NUM_TX_QP 1
> +#ifdef EHEA_SMALL_QUEUES
> +#define EHEA_MAX_CQE_COUNT 1020
> +#define EHEA_MAX_ENTRIES_SQ1020
> +#define EHEA_MAX_ENTRIES_RQ1 4080
> +#define EHEA_MAX_ENTRIES_RQ2 1020
> +#define EHEA_MAX_ENTRIES_RQ3 1020
> +#define EHEA_SWQE_REFILL_TH 100
> +#else
> +#define EHEA_MAX_CQE_COUNT32000
> +#define EHEA_MAX_ENTRIES_SQ 16000
> +#define EHEA_MAX_ENTRIES_RQ1 32080
> +#define EHEA_MAX_ENTRIES_RQ2 4020
> +#define EHEA_MAX_ENTRIES_RQ3 4020
> +#define EHEA_SWQE_REFILL_TH1000
> +#endif
> +
> +#define EHEA_MAX_ENTRIES_EQ 20
> +
> +#define EHEA_SG_SQ 2
> +#define EHEA_SG_RQ1 1
> +#define EHEA_SG_RQ2 0
> +#define EHEA_SG_RQ3 0
> +
> +#define EHEA_MAX_PACKET_SIZE9022 /* for jumbo frame */
> +#define EHEA_RQ2_PKT_SIZE 1522
> +#define EHEA_LL_PKT_SIZE 256
> +
> +/* Send completion signaling */
> +#define EHEA_SIG_IV 1000
> +#define EHEA_SIG_IV_LONG 4
> +
> +/* Protection Domain Identifier */
> +#define EHEA_PD_ID0xaabcdeff
> +
> +#define EHEA_RQ2_THRESHOLD 1
> +/* use RQ3 threshold of 1522 bytes */
> +#define EHEA_RQ3_THRESHOLD 9
> +
> +#define EHEA_SPEED_10G 1
> +#define EHEA_SPEED_1G 1000
> +#define EHEA_SPEED_100M 100
> +#define EHEA_SPEED_10M10
> +
> +/* Broadcast/Multicast registration types */
> +#define EHEA_BCMC_SCOPE_ALL 0x08
> +#define EHEA_BCMC_SCOPE_SINGLE 0x00
> +#define EHEA_BCMC_MULTICAST 0x04
> +#define EHEA_BCMC_BROADCAST 0x00
> +#define EHEA_BCMC_UNTAGGED 0x02
> +#define EHEA_BCMC_TAGGED 0x00
> +#define EHEA_BCMC_VLANID_ALL 0x01
> +#define EHEA_BCMC_VLANID_SINGLE 0x00
> +
> +/* Use this define to kmallocate PHYP control blocks */
> +#define H_CB_ALIGNMENT 4096
> +
> +#define EHEA_PAGESHIFT 12
> +#define EHEA_PAGESIZE 4096UL
> +#define EHEA_CACHE_LINE 128
This looks like a very bad idea, what happens if you're running on a
machine with 64K pages?
> +
> +#define EHEA_ENABLE 1
> +#define EHEA_DISABLE 0
Do you really need hash defines for 0 and 1 ? They're fairly well
understood in C as meaning true and false.
> +
> +/* Memory Regions */
> +#define EHEA_MR_MAX_TX_PAGES 20
> +#define EHEA_MR_TX_DATA_PN 3
> +#define EHEA_MR_ACC_CTRL 0x0080
> +#define EHEA_RWQES_PER_MR_RQ2 10
> +#define EHEA_RWQES_PER_MR_RQ3 10
> +
> +
> +void ehea_set_ethtool_ops(struct net_device *netdev);
> +
> +#ifndef KEEP_EDEBS_BELOW
> +#define KEEP_EDEBS_BELOW 8
> +#endif
> +
> +extern int ehea_trace_level;
> +
> +#ifdef EHEA_NO_EDEB
> +#define EDEB_P_GENERIC(level, idstring, format, args...) \
> + while (0 == 1) { \
> + if(unlikely (level <= ehea_trace_level)) { \
> + printk("%s " idstring " "format "\n", \
> + __func__, ##args); \
> + } \
> + } \
> +
Re: [take6 1/3] kevent: Core files.
On Wed, Aug 09, 2006 at 03:21:27PM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> On Wed, 9 Aug 2006 12:02:40 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> >
> > Core files.
> >
> > This patch includes core kevent files:
> > - userspace controlling
> > - kernelspace interfaces
> > - initialization
> > - notification state machines
> >
> > It might also inlclude parts from other subsystem (like network related
> > syscalls, so it is possible that it will not compile without other
> > patches applied).
>
> Summary:
>
> - has serious bugs which indicate that much better testing is needed.
>
> - All -EFOO return values need to be reviewed for appropriateness
>
> - needs much better commenting before I can do more than a local-level review.
>
>
> > --- /dev/null
> > +++ b/include/linux/kevent.h
> > ...
> >
> > +/*
> > + * Poll events.
> > + */
> > +#defineKEVENT_POLL_POLLIN 0x0001
> > +#defineKEVENT_POLL_POLLPRI 0x0002
> > +#defineKEVENT_POLL_POLLOUT 0x0004
> > +#defineKEVENT_POLL_POLLERR 0x0008
> > +#defineKEVENT_POLL_POLLHUP 0x0010
> > +#defineKEVENT_POLL_POLLNVAL0x0020
> > +
> > +#defineKEVENT_POLL_POLLRDNORM 0x0040
> > +#defineKEVENT_POLL_POLLRDBAND 0x0080
> > +#defineKEVENT_POLL_POLLWRNORM 0x0100
> > +#defineKEVENT_POLL_POLLWRBAND 0x0200
> > +#defineKEVENT_POLL_POLLMSG 0x0400
> > +#defineKEVENT_POLL_POLLREMOVE 0x1000
>
> 0x0800 got lost.
I will use usual poll definitions.
> > +struct ukevent
> > +{
> > + struct kevent_idid; /* Id of this request,
> > e.g. socket number, file descriptor and so on... */
> > + __u32 type; /* Event type, e.g.
> > KEVENT_SOCK, KEVENT_INODE, KEVENT_TIMER and so on... */
> > + __u32 event; /* Event itself, e.g.
> > SOCK_ACCEPT, INODE_CREATED, TIMER_FIRED... */
> > + __u32 req_flags; /* Per-event request
> > flags */
> > + __u32 ret_flags; /* Per-event return
> > flags */
> > + __u32 ret_data[2];/* Event return data.
> > Event originator fills it with anything it likes. */
> > + union {
> > + __u32 user[2];/* User's data. It is
> > not used, just copied to/from user. */
> > + void*ptr;
> > + };
> > +};
>
> What is this union for?
>
> `ptr' needs a __user tag, does it not?
Not, it is never touched by kernel.
> `ptr' will be 64-bit in-kernel and 64-bit for 64-bit userspace, but 32-bit
> for 32-bit userspace. I guess that's why user[] is there.
Exactly.
> On big-endian machines, this pointer will appear to be word-swapped as far
> as a 64-bit kernel is concerned. Or something.
>
> IOW: What's going on here??
It is user data - I put there a union just to simplify userspace, so it
sould not require some typecasting.
> > +#ifdef CONFIG_KEVENT_INODE
> > +void kevent_inode_notify(struct inode *inode, u32 event);
> > +void kevent_inode_notify_parent(struct dentry *dentry, u32 event);
> > +void kevent_inode_remove(struct inode *inode);
> > +#else
> > +static inline void kevent_inode_notify(struct inode *inode, u32 event)
> > +{
> > +}
> > +static inline void kevent_inode_notify_parent(struct dentry *dentry, u32
> > event)
> > +{
> > +}
> > +static inline void kevent_inode_remove(struct inode *inode)
> > +{
> > +}
> > +#endif /* CONFIG_KEVENT_INODE */
> > +#ifdef CONFIG_KEVENT_SOCKET
> > +#ifdef CONFIG_LOCKDEP
> > +void kevent_socket_reinit(struct socket *sock);
> > +void kevent_sk_reinit(struct sock *sk);
> > +#else
> > +static inline void kevent_socket_reinit(struct socket *sock)
> > +{
> > +}
> > +static inline void kevent_sk_reinit(struct sock *sk)
> > +{
> > +}
> > +#endif
> > +void kevent_socket_notify(struct sock *sock, u32 event);
> > +int kevent_socket_dequeue(struct kevent *k);
> > +int kevent_socket_enqueue(struct kevent *k);
> > +#define sock_async(__sk) sock_flag(__sk, SOCK_ASYNC)
>
> Is this header the correct place to be implementing sock_async()?
I decided to have kevent as much separate as possible, so I put a lot
there. When people decide that it is ok, than it can be moved into
appropriate network header file - here it is much easier to review.
> > --- /dev/null
> > +++ b/kernel/kevent/Kconfig
> > @@ -0,0 +1,50 @@
> > +config KEVENT
> > + bool "Kernel event notification mechanism"
> > + help
> > + This option enables event queue mechanism.
> > + It can be used as replacement for poll()/select(), AIO callback
> > invocations,
> > + advanced timer notifications and other kernel object status changes.
>
> Please squeeze all the help text into 80-columns. Or at least check that
> it looks OK in menuconfig in an 80-col xterm,
Ok.
> > --- /dev/null
> > +++ b/kernel/kevent/kevent.c
> > @@ -0,0 +1,238 @@
> > +/*
> > + * kevent.c
> > + *
> > + * 2006 Copyright
Re: [PATCH 1/6] ehea: interface to network stack
Hi Jan-Bernd,
Comments below the code they refer to.
On Wed, 2006-08-09 at 10:38 +0200, Jan-Bernd Themann wrote:
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
> drivers/net/ehea/ehea_main.c | 2738
> +++
> 1 file changed, 2738 insertions(+)
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_main.c1969-12-31
> 16:00:00.0 -0800
> +++ kernel/drivers/net/ehea/ehea_main.c 2006-08-08 23:59:39.683357016
> -0700
> @@ -0,0 +1,2738 @@
> +/*
> + * linux/drivers/net/ehea/ehea_main.c
Putting the file name in the file is fairly redundant IMHO.
> + * eHEA ethernet device driver for IBM eServer System p
What's the actual hardware that this is for? System p covers a whole
range of machines, do they really all support this driver?
> + * (C) Copyright IBM Corp. 2006
> + *
> + * Authors:
> + * Christoph Raisch <[EMAIL PROTECTED]>
> + * Jan-Bernd Themann <[EMAIL PROTECTED]>
> + * Heiko-Joerg Schick <[EMAIL PROTECTED]>
> + * Thomas Klein <[EMAIL PROTECTED]>
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2, or (at your option)
> + * any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#define DEB_PREFIX "main"
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ehea.h"
> +#include "ehea_qmr.h"
> +#include "ehea_phyp.h"
> +
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Christoph Raisch <[EMAIL PROTECTED]>");
> +MODULE_DESCRIPTION("IBM eServer HEA Driver");
> +MODULE_VERSION(EHEA_DRIVER_VERSION);
> +
> +static int __devinit ehea_probe(struct ibmebus_dev *dev,
> + const struct of_device_id *id);
> +static int __devexit ehea_remove(struct ibmebus_dev *dev);
> +static int ehea_sense_port_attr(struct ehea_adapter *adapter, int portnum);
I haven't looked closely, but can you rearrange the functions so you
don't need these forward declarations?
> +int ehea_trace_level = 5;
> +
> +static struct net_device_stats *ehea_get_stats(struct net_device *dev)
> +{
> + int i;
> + u64 hret = H_HARDWARE;
You unconditionally assign to hret below.
> + u64 rx_packets = 0;
Why not just update stats->rx_packets directly?
> + struct ehea_port *port = (struct ehea_port*)dev->priv;
> + struct ehea_adapter *adapter = port->adapter;
I don't think you need adapter, you only use it in one place, just
access it through port->adapter->handle (below).
> + struct hcp_query_ehea_port_cb_2 *cb2 = NULL;
> + struct net_device_stats *stats = &port->stats;
> +
> + EDEB_EN(7, "net_device=%p", dev);
> +
> + cb2 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
> + if (!cb2) {
> + EDEB_ERR(4, "No memory for cb2");
> + goto get_stat_exit;
You leak cb2 here.
> + }
> +
> + hret = ehea_h_query_ehea_port(adapter->handle,
> + port->logical_port_id,
> + H_PORT_CB2,
> + H_PORT_CB2_ALL,
> + cb2);
> +
> + if (hret != H_SUCCESS) {
> + EDEB_ERR(4, "query_ehea_port failed for cb2");
> + goto get_stat_exit;
> + }
> +
> + EDEB_DMP(7, (u8*)cb2,
> + sizeof(struct hcp_query_ehea_port_cb_2), "After HCALL");
> +
> + for (i = 0; i < port->num_def_qps; i++) {
> + rx_packets += port->port_res[i].rx_packets;
> + }
> +
> + stats->tx_packets = cb2->txucp + cb2->txmcp + cb2->txbcp;
> + stats->multicast = cb2->rxmcp;
> + stats->rx_errors = cb2->rxuerr;
> + stats->rx_bytes = cb2->rxo;
> + stats->tx_bytes = cb2->txo;
> + stats->rx_packets = rx_packets;
> +
> +get_stat_exit:
> + EDEB_EX(7, "");
> + return stats;
> +}
> +
> +static inline u32 ehea_get_send_lkey(struct ehea_port_res *pr)
> +{
> + return pr->send_mr.lkey;
> +}
Get rid of this, it's only used once.
> +static inline u32 ehea_get_recv_lkey(struct ehea_port_res *pr)
> +{
> + return pr->recv_mr.lkey;
> +}
And this one only twice? Is it really useful?
> +
> +#define EHEA_OD_ADDR(address, segment) (((address) & (PAGE_SIZE - 1)) \
> + | ((segment) << 12));
> +
> +static inline u64 get_swqe_addr(u64 tmp_addr, int addr_seg)
> +{
> + u64 addr;
> + addr = tmp_addr;
> + return addr;
Re: d80211 merge plans
Mohamed Abbas wrote: David Miller wrote: I think this is a non-started until the SMP problems are worked out. Is it still SMP challenged? I been using d80211 stack for about a month I have not encounter any SMP issues. We are currently involving validation engineers to do more stress tests and will see if any SMP issues come up. Well, tests are interesting, but I would rather see a real _analysis_ of the locking. Locking is provable, you know... Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
On Wed, 2006-08-09 at 16:54 -0700, David Miller wrote: > From: Peter Zijlstra <[EMAIL PROTECTED]> > Date: Wed, 09 Aug 2006 15:32:33 +0200 > > > The idea is to drop all !NFS packets (or even more specific only > > keep those NFS packets that belong to the critical mount), and > > everybody doing critical IO over layered networks like IPSec or > > other tunnel constructs asks for trouble - Just DON'T do that. > > People are doing I/O over IP exactly for it's ubiquity and > flexibility. It seems a major limitation of the design if you cancel > out major components of this flexibility. We're not, that was a bit of my own frustration leaking out; I think this whole push to IP based storage is a bit silly. I'm just not going to help the admin who's server just hangs because his VPN key expired. Running critical resources remotely like this is tricky, and every hop/layer you put in between increases the risk of something going bad. The only setup I think even remotely sane is a dedicated network in the very same room - not unlike FC but cheaper (which I think is the whole push behind this, eth is cheap) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
d80211: minor review item: generic_lock
generic_lock does not appear to be used at all. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] net socket family patches
On Wed, 9 Aug 2006, David Miller wrote: From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 11:31:38 -0700 These patches cleanup the net socket family interface and convert it to RCU. This is new stuff that should go into 2.6.19 (if it is ready). Andrew could you put it in -mm as well? Andrew pulls net-2.6.19 so there is no need to ask him to put networking patches explicitly into -mm I've been wondering - are the relationships of which of the various kernel trees pull patches from which other ones documented anywhere? If so, I'd love to read about it. Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
David Miller wrote: From: Peter Zijlstra <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 16:07:20 +0200 Hmm, what does sk_buff::input_dev do? That seems to store the initial device? You can run grep on the tree just as easily as I can which is what I did to answer this question. It only takes a few seconds of your time to grep the source tree for things like "skb->input_dev", so would you please do that before asking more questions like this? C'mon cscope is your friend for this. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET]: Clean up netlink NLM_F_ECHO and rtnl event notifications
From: Thomas Graf <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 22:48:21 +0200 > Aims at cleaning up rtnetlink event notifications and implements > real NLM_F_ECHO support. > > Please disregard my last IPv4 routing related patchset, I'll > resubmit it based on this patchset. All applied, nice work Thomas. Especially nice to see the RTNL semaphore export go away :-) Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Excess use of packed attribute
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Wed, 09 Aug 2006 11:37:31 -0700
> Agreed (although not really RISC -- sparc64 and ia64 have this
> problem, while ppc is fine with unaligned access). However
> __attribute__((packed,aligned)) has just been brought to my attention.
> For example, on sparc64,
>
> struct foo { char x; int a; } __attribute__((packed,aligned));
> struct bar { char x; int b; } __attribute__((packed));
>
> int c(struct foo *x) { return x->a; }
> int d(struct bar *x) { return x->b; }
>
> compiles to:
...
> which suggests that adding "aligned" is a good idea for many of the
> uses of "packed". However I don't know how all gcc version do with
> this. Anyone have any comments on "__attribute__((packed,aligned))"?
Good find.
It might usable in some of the questionable cases, however it changes
the size of the struct which eliminates most of the gains.
For example:
[EMAIL PROTECTED]:~/src/GIT/net-2.6$ cat foo.c
#include
struct foo_packed {
char x; int a;
} __attribute__((packed));
struct foo_packed_aligned {
char x; int a;
} __attribute__((packed,aligned));
int main(void)
{
printf("foo_packed: sizeof(%Zd)\n",
sizeof(struct foo_packed));
printf("foo_packed_aligned: sizeof(%Zd)\n",
sizeof(struct foo_packed_aligned));
return 0;
}
[EMAIL PROTECTED]:~/src/GIT/net-2.6$ gcc -O -o foo foo.c
[EMAIL PROTECTED]:~/src/GIT/net-2.6$ ./foo
foo_packed: sizeof(5)
foo_packed_aligned: sizeof(8)
[EMAIL PROTECTED]:~/src/GIT/net-2.6$
This doesn't work for things like packet headers, for example.
Oh well.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: remove unnecessary config.h includes from net/
From: Dave Jones <[EMAIL PROTECTED]> Date: Wed, 9 Aug 2006 22:21:16 -0400 > config.h is automatically included by kbuild these days. > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> Applied to net-2.6.19, thanks Dave. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] sock_register interface changes
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 11:31:43 -0700 > The sock_register() doesn't change the family, so the protocols can > define it read-only. No caller ever checks return value from > sock_unregister() Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] net: socket family using RCU
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 11:31:42 -0700 > Replace the gross custom locking done in socket code for net_family[] > with simple RCU usage. Some reordering necessary to avoid sleep > issues with sock_alloc. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied, but I had to do this by hand since it's not cleanly against net-2.6.19: > *res = sock; > security_socket_post_create(sock, family, type, protocol, kern); security_socket_post_create() returns an error code in the current tree, and does a goto out_release; on error. So I defer the *res = sock; until we know that this security hook ran error-less. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] net: drop unused elements from net_proto_family
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 11:31:41 -0700 > Three values in net_proto_family are defined but never used. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] socket: code style cleanup
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 11:31:40 -0700 > Make socket.c conform to current style: > * run through Lindent > * get rid of unneeded casts > * split assignment and comparsion where possible > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] sock_create bad error return
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 11:31:39 -0700 > If socket create call races with module unload, it correctly > fails the socket call but doesn't return an error. This race > is theoritical because the sock->ops are always the same and > non-modular. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> I think the intention of the code is to return -EAFNOSUPPORT which is set explicitly some lines above, and this makes sense because if we can't grab onto the module reference count it means the module is in the process of being unloaded. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, We had some patch need to submit for sundance.c
Dear All: We had some patch need to submit. Would you tell me where to get current sundance.c for myself to generate those patch files. Sorry, I only got this link: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=f13b2a195c708fe32d8c53d05988875a51bd52e1;hb=1668b19f75cb949f930814a23b74201ad6f76a53;f=drivers/net/sundance.c Thanks for everybody. Best Regards, Jesse Huang - Original Message - From: "Francois Romieu" <[EMAIL PROTECTED]> To: "Jesse Huang" <[EMAIL PROTECTED]> Cc: ; ; "Andrew Morton" <[EMAIL PROTECTED]>; "Jeff Garzik" <[EMAIL PROTECTED]> Sent: Friday, July 28, 2006 3:07 AM Subject: Re: Hello, We have IP100A Linux driver need to submit to 2.6.x kernel Jesse Huang <[EMAIL PROTECTED]> : [...] > I am IC Plus software engineer. We have IP100A 10/100 fast network adapter > driver need to submit to Linux 2.6.x kernel. Please tell me who should I > submit to. > > IP100A's device ID is 0x13f0 0200. You do not need to do anything: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1668b19f75cb949f930814a23b74201ad6f76a53 As far as I have checked before forwarding Pedro Alejandro's patch, the out-of-tree IP100 driver exhibited no significant difference with the sundance driver. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
remove unnecessary config.h includes from net/
config.h is automatically included by kbuild these days. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> --- linux-2.6/net/ipv4/netfilter/ip_conntrack_sip.c~2006-08-09 22:18:48.0 -0400 +++ linux-2.6/net/ipv4/netfilter/ip_conntrack_sip.c 2006-08-09 22:18:53.0 -0400 @@ -8,7 +8,6 @@ * published by the Free Software Foundation. */ -#include #include #include #include --- linux-2.6/net/ipv4/af_inet.c~ 2006-08-09 22:18:58.0 -0400 +++ linux-2.6/net/ipv4/af_inet.c2006-08-09 22:19:03.0 -0400 @@ -67,7 +67,6 @@ * 2 of the License, or (at your option) any later version. */ -#include #include #include #include --- linux-2.6/net/ipv4/ipconfig.c~ 2006-08-09 22:19:07.0 -0400 +++ linux-2.6/net/ipv4/ipconfig.c 2006-08-09 22:19:10.0 -0400 @@ -31,7 +31,6 @@ * -- Josef Siemes <[EMAIL PROTECTED]>, Aug 2002 */ -#include #include #include #include --- linux-2.6/net/ipv4/raw.c~ 2006-08-09 22:19:14.0 -0400 +++ linux-2.6/net/ipv4/raw.c2006-08-09 22:19:18.0 -0400 @@ -38,8 +38,7 @@ * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. */ - -#include + #include #include #include --- linux-2.6/net/ipv4/tcp_veno.c~ 2006-08-09 22:19:23.0 -0400 +++ linux-2.6/net/ipv4/tcp_veno.c 2006-08-09 22:19:26.0 -0400 @@ -9,7 +9,6 @@ * See http://www.ntu.edu.sg/home5/ZHOU0022/papers/CPFu03a.pdf */ -#include #include #include #include --- linux-2.6/net/ipv4/tcp_lp.c~2006-08-09 22:19:31.0 -0400 +++ linux-2.6/net/ipv4/tcp_lp.c 2006-08-09 22:19:34.0 -0400 @@ -31,7 +31,6 @@ * Version: $Id: tcp_lp.c,v 1.22 2006-05-02 18:18:19 hswong3i Exp $ */ -#include #include #include --- linux-2.6/net/atm/atm_sysfs.c~ 2006-08-09 22:19:38.0 -0400 +++ linux-2.6/net/atm/atm_sysfs.c 2006-08-09 22:19:40.0 -0400 @@ -1,6 +1,5 @@ /* ATM driver model support. */ -#include #include #include #include --- linux-2.6/net/core/wireless.c~ 2006-08-09 22:19:44.0 -0400 +++ linux-2.6/net/core/wireless.c 2006-08-09 22:19:47.0 -0400 @@ -72,7 +72,6 @@ /* INCLUDES */ -#include /* Not needed ??? */ #include #include/* off_t */ #include/* struct ifreq, dev_get_by_name() */ --- linux-2.6/net/core/dev_mcast.c~ 2006-08-09 22:19:52.0 -0400 +++ linux-2.6/net/core/dev_mcast.c 2006-08-09 22:19:59.0 -0400 @@ -21,8 +21,7 @@ * 2 of the License, or (at your option) any later version. */ -#include -#include +#include #include #include #include -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
On Wed, August 9, 2006 21:45, Peter Zijlstra said: > On Wed, 2006-08-09 at 20:34 +0200, Indan Zupancic wrote: >> Why is it needed for the protocol specific code to call dev_unreserve_skb? > > It uses this to get an indication of memory pressure; if we have > memalloc'ed skbs memory pressure must be high, hence we must drop all > non critical packets. But you are right in that this is a problematic > area; the mapping from skb to device is non trivial. > > Your suggestion of testing skb->memalloc might work just as good; indeed > if we have regressed into the fallback allocator we know we have > pressure. You seem to have explained dev_reserve_used usage, not the dev_unreserve_skb calls. But I've just found -v2 and see that they're gone now, great. -v2 looks much better. >> Only problem is if the device can change. rx_reserve_used should probably >> be updated when that happens, as a skb can't use reserved memory on a device >> it was moved away from. (right?) > > Well yes, this is a problem, only today have I understood how volatile > the mapping actually is. I think you are right in that transferring the > accounting from the old to the new device is correct solution. > > However this brings us the problem of limiting the fallback allocator; > currently this is done in __netdev_alloc_skb where rx_reserve_used it > compared against rx_reserve. If we transfer accounting away this will > not work anymore. I'll have to think about this case, perhaps we already > have a problem here. The point of the reservations is to avoid deadlocks, and they're always big enough to hold all in-flight skbs, right? So what about solving the whole device problem by using a global counter and limit instead of per device? The question is whether traffic on one device can starve traffic on other devices or not, and how big a problem that is. It probably can, tricky stuff. Though getting rid of the per device stuff would simplify a lot... >> > Also, I've been thinking (more pain), should I not up the reserve for >> > each SOCK_MEMALLOC socket. >> >> Up rx_reserve_used or the total ammount of reserved memory? Probably 'no' for >> both though, as it's either device specific or skb dependent. > > I came up with yes, if for each socket you gain a request queue, the > number of in-flight pages is proportional to the number of sockets. Yes, seems so. Good night, Indan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPX changes introduce warning.
From: Dave Jones <[EMAIL PROTECTED]> Date: Wed, 9 Aug 2006 19:44:17 -0400 > We've just added an implicit declaration in the latest tree.. > > net/ipx/af_ipx.c: In function 'ipx_rcv': > net/ipx/af_ipx.c:1648: error: implicit declaration of function 'ipxhdr' > > (Yes, my builds fail on -Werror-implicit, so that things like this get caught > early) > > Probably something simple like a missing #include, but I'm heading out > the door right now :) I'll poke at it later if no-one has beaten me to it. I could have sworn this compiled in my tree, sorry. Fix below. Greg, I'll queue this up to you in a GIT tree along with another fix later tonight. Thanks Dave. commit fff642570dc47ab76491fe81ee6599269c4eb13e Author: David S. Miller <[EMAIL PROTECTED]> Date: Wed Aug 9 17:36:15 2006 -0700 [IPX]: Fix typo, ipxhdr() --> ipx_hdr() Noticed by Dave Jones. Signed-off-by: David S. Miller <[EMAIL PROTECTED]> diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c index 4019642..bef3f61 100644 --- a/net/ipx/af_ipx.c +++ b/net/ipx/af_ipx.c @@ -1645,7 +1645,7 @@ static int ipx_rcv(struct sk_buff *skb, if (!pskb_may_pull(skb, sizeof(struct ipxhdr))) goto drop; - ipx_pktsize = ntohs(ipxhdr(skb)->ipx_pktsize); + ipx_pktsize = ntohs(ipx_hdr(skb)->ipx_pktsize); /* Too small or invalid header? */ if (ipx_pktsize < sizeof(struct ipxhdr) || - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] net socket family patches
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 11:31:38 -0700 > These patches cleanup the net socket family interface and > convert it to RCU. This is new stuff that should go into 2.6.19 > (if it is ready). Andrew could you put it in -mm as well? Andrew pulls net-2.6.19 so there is no need to ask him to put networking patches explicitly into -mm - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [GIT PATCH] IPv6 Routing / Ndisc Fixes
From: Ville Nuorvala <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 21:19:56 +0300 > sorry if you get this email twice, but we have been having some problems > with our mailer today... FWIW I personally got the first copy. I'll look at it later. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take6 1/3] kevent: Core files.
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 10:47:38 -0700
> static wrapper_functions_with_execessive_long_names(struct i_really_hate
> *this)
> {
> suck();
> }
Yes, typing 50 characters just to bump a counter, it's beyond
rediculious.
Go hack on the X server if you like long-winded function names
that do trivial operations :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] limit rt cache size
From: Andi Kleen <[EMAIL PROTECTED]> Date: Wed, 9 Aug 2006 18:32:26 +0200 > One issue I forgot earlier and Kirill pointed out is that the > reallocation would require vmalloc because memory will be too fragmented > to get a big piece of physical memory. So it would add TLB pressure. > > Can't think of a good way around that. > > You might have been right with being sceptical. For NUMA this already happens, is it a problem in practice? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 2/2] update sunrpc to use in-kernel sockets API
From: Sridhar Samudrala <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 10:34:38 -0700 > [SUNRPC]: Remove the unnecessary check for highmem in xs_sendpages() > and call kernel_sendpage() directly. > > Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]> Applied to net-2.6.19, thanks a lot Sridhar. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
From: Peter Zijlstra <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 18:19:54 +0200 > disregards this part from -v2 then :-( And please don't do arbitrary cleanups in your patches like how you reformatted all of the NETIF_F_* macro values. Do things like that as a seperate change in your set of patches so it's easier for people to review your work. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
From: Peter Zijlstra <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 16:07:20 +0200 > Hmm, what does sk_buff::input_dev do? That seems to store the initial > device? You can run grep on the tree just as easily as I can which is what I did to answer this question. It only takes a few seconds of your time to grep the source tree for things like "skb->input_dev", so would you please do that before asking more questions like this? It does store the initial device, but as Thomas tried so hard to explain to you guys these device pointers in the skb are transient and you cannot refer to them outside of packet receive processing. The reason is that there is no refcounting performed on these devices when they are attached to the skb, for performance reasons, and thus the device can be downed, the module for it removed, etc. long before the skb is freed up. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
From: Peter Zijlstra <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 15:32:33 +0200 > The idea is to drop all !NFS packets (or even more specific only > keep those NFS packets that belong to the critical mount), and > everybody doing critical IO over layered networks like IPSec or > other tunnel constructs asks for trouble - Just DON'T do that. People are doing I/O over IP exactly for it's ubiquity and flexibility. It seems a major limitation of the design if you cancel out major components of this flexibility. I really can't take this work seriously when I see things like this being said. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: another networking lockdep trace.
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 21:52:23 +1000 > Nice. This is a bug introduced less than 2 weeks ago. We're finally > getting some dividends from the lock validator :) Thanks guys! Horray! :-) > [IPV6]: The ifa lock is a BH lock > > The ifa lock is expected to be taken in BH context (by addrconf timers) > so we must disable BH when accessing it from user context. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Applied, thanks Herbert. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
IPX changes introduce warning.
We've just added an implicit declaration in the latest tree.. net/ipx/af_ipx.c: In function 'ipx_rcv': net/ipx/af_ipx.c:1648: error: implicit declaration of function 'ipxhdr' (Yes, my builds fail on -Werror-implicit, so that things like this get caught early) Probably something simple like a missing #include, but I'm heading out the door right now :) I'll poke at it later if no-one has beaten me to it. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2]: [IPV4] route: Locking infrastructure for dynamic routing cache sizing.
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 09 Aug 2006 21:31:45 +1000 > If we hit a writer just as they begin resizing, we could be here for > quite a while. Yes, we discussed this a bit on IRC. > In fact because we expect each writer to stick around for a > relatively long time, we could use a new seqlock primitive that just > spun until the LSB becomes zero again. Indeed, and put a cpu_relax() in there. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DECnet] Convert rwlock to spinlock
From: Steven Whitehouse <[EMAIL PROTECTED]> Date: Wed, 9 Aug 2006 11:06:33 +0100 > As per Stephen Hemminger's recent patch to ipv4/fib_semantics.c this > is the same change but for DECnet. > > Signed-off-by: Steven Whitehouse <[EMAIL PROTECTED]> Also applied, thanks Steven. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rules and groups
From: Steven Whitehouse <[EMAIL PROTECTED]> Date: Wed, 9 Aug 2006 11:03:26 +0100 > [DECnet] Covert rules to use generic code > > This patch converts the DECnet rules code to use the generic > rules system created by Thomas Graf <[EMAIL PROTECTED]>. > > Signed-off-by: Steven Whitehouse <[EMAIL PROTECTED]> Patch applied, thanks Steven. I know it may seem like a minor detail, but can you format your top comment line like this: [DECNET]: Covert rules to use generic code I've been making this transformation by hand. The important parts for me are: [X]: blah Where X is the main subsystem name in all capital letters, and there is a colon after the closing right bracket. If there is a specific sub-area being effected, the following is a nice way to show that: [X] subarea: blah This makes all of the networking changesets look consistent and it's easier for human eyes to scan the changeset lines if we make an effort to do it this way. Thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/2] [IPV4]: Use network-order dport for all visible inet_lookup_*
From: Herbert Xu <[EMAIL PROTECTED]> Date: Tue, 8 Aug 2006 21:11:40 +1000 > Good point. This patch eliminates the double swap for __inet_lookup. > > [IPV4]: Use network-order dport for all visible inet_lookup_* Applied, thanks Herbert. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
On Wednesday 09 August 2006 12:22, Dan Williams wrote: > The atmel driver is somewhat of a hybrid. I dunno - the last time I checked atmel, it seemed to have quite a bit of softmac code. If atmel isn't actually a softmac card, um.. I dunno. What parts of it is fullmac? -Michael Wu pgpF2OVtp7q03.pgp Description: PGP signature
Re: [take6 1/3] kevent: Core files.
On Wed, 9 Aug 2006 12:02:40 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> Core files.
>
> This patch includes core kevent files:
> - userspace controlling
> - kernelspace interfaces
> - initialization
> - notification state machines
>
> It might also inlclude parts from other subsystem (like network related
> syscalls, so it is possible that it will not compile without other
> patches applied).
Summary:
- has serious bugs which indicate that much better testing is needed.
- All -EFOO return values need to be reviewed for appropriateness
- needs much better commenting before I can do more than a local-level review.
> --- /dev/null
> +++ b/include/linux/kevent.h
> ...
>
> +/*
> + * Poll events.
> + */
> +#define KEVENT_POLL_POLLIN 0x0001
> +#define KEVENT_POLL_POLLPRI 0x0002
> +#define KEVENT_POLL_POLLOUT 0x0004
> +#define KEVENT_POLL_POLLERR 0x0008
> +#define KEVENT_POLL_POLLHUP 0x0010
> +#define KEVENT_POLL_POLLNVAL0x0020
> +
> +#define KEVENT_POLL_POLLRDNORM 0x0040
> +#define KEVENT_POLL_POLLRDBAND 0x0080
> +#define KEVENT_POLL_POLLWRNORM 0x0100
> +#define KEVENT_POLL_POLLWRBAND 0x0200
> +#define KEVENT_POLL_POLLMSG 0x0400
> +#define KEVENT_POLL_POLLREMOVE 0x1000
0x0800 got lost.
> +struct ukevent
> +{
> + struct kevent_idid; /* Id of this request,
> e.g. socket number, file descriptor and so on... */
> + __u32 type; /* Event type, e.g.
> KEVENT_SOCK, KEVENT_INODE, KEVENT_TIMER and so on... */
> + __u32 event; /* Event itself, e.g.
> SOCK_ACCEPT, INODE_CREATED, TIMER_FIRED... */
> + __u32 req_flags; /* Per-event request
> flags */
> + __u32 ret_flags; /* Per-event return
> flags */
> + __u32 ret_data[2];/* Event return data.
> Event originator fills it with anything it likes. */
> + union {
> + __u32 user[2];/* User's data. It is
> not used, just copied to/from user. */
> + void*ptr;
> + };
> +};
What is this union for?
`ptr' needs a __user tag, does it not?
`ptr' will be 64-bit in-kernel and 64-bit for 64-bit userspace, but 32-bit
for 32-bit userspace. I guess that's why user[] is there.
On big-endian machines, this pointer will appear to be word-swapped as far
as a 64-bit kernel is concerned. Or something.
IOW: What's going on here??
> +#ifdef CONFIG_KEVENT_INODE
> +void kevent_inode_notify(struct inode *inode, u32 event);
> +void kevent_inode_notify_parent(struct dentry *dentry, u32 event);
> +void kevent_inode_remove(struct inode *inode);
> +#else
> +static inline void kevent_inode_notify(struct inode *inode, u32 event)
> +{
> +}
> +static inline void kevent_inode_notify_parent(struct dentry *dentry, u32
> event)
> +{
> +}
> +static inline void kevent_inode_remove(struct inode *inode)
> +{
> +}
> +#endif /* CONFIG_KEVENT_INODE */
> +#ifdef CONFIG_KEVENT_SOCKET
> +#ifdef CONFIG_LOCKDEP
> +void kevent_socket_reinit(struct socket *sock);
> +void kevent_sk_reinit(struct sock *sk);
> +#else
> +static inline void kevent_socket_reinit(struct socket *sock)
> +{
> +}
> +static inline void kevent_sk_reinit(struct sock *sk)
> +{
> +}
> +#endif
> +void kevent_socket_notify(struct sock *sock, u32 event);
> +int kevent_socket_dequeue(struct kevent *k);
> +int kevent_socket_enqueue(struct kevent *k);
> +#define sock_async(__sk) sock_flag(__sk, SOCK_ASYNC)
Is this header the correct place to be implementing sock_async()?
> --- /dev/null
> +++ b/kernel/kevent/Kconfig
> @@ -0,0 +1,50 @@
> +config KEVENT
> + bool "Kernel event notification mechanism"
> + help
> + This option enables event queue mechanism.
> + It can be used as replacement for poll()/select(), AIO callback
> invocations,
> + advanced timer notifications and other kernel object status changes.
Please squeeze all the help text into 80-columns. Or at least check that
it looks OK in menuconfig in an 80-col xterm,
> --- /dev/null
> +++ b/kernel/kevent/kevent.c
> @@ -0,0 +1,238 @@
> +/*
> + * kevent.c
> + *
> + * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with th
RE: 3945 driver using d80211
One thing driving many silicon vendors away from putting the MLME in the card - is that in order to support the advanced wireless features of MS Vista you have to leave the MLME to the host! (this is to enable Vista's advanced wireless features - like simultaneous client/ad-hoc mode). This is forcing more and more vendors to do things the right way. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Barber Sent: Wednesday, August 09, 2006 2:33 PM To: Dan Williams; Michael Wu Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org Subject: RE: 3945 driver using d80211 There are many different functions in a complete 802.11 implementation - and different implementations put these functions in different places. In general, I would consider the primary difference between a "full-mac" card and others to be the location of the MLME function. All full-mac cards perform the MLME in the card. They typically also do the conversion of data frames between 802.3 and 802.11 format in the card as well, and the inter-BSS transitions are handled in the card too. This key difference make it very unlikely that full-mac cards will implement various advanced 802.11 features - such as WDS, virtual APs, multiple clients, simultaneous client/AP modes etc etc. (Of course, by adding a large number of APIs all this can theoretically be achieved - it's just a lot more work this way). Because the full-mac cards have functions in the card that other cards do not the API for these cards will necessarily be quite different from the API for non-full-mac cards. Typically the full mac cards will only ever expose a single 802.3 interface - and hence they may not need to have an 802.11 master interface at all. They will require a user space API that includes control of MLME functions - because the MLME is in the card. A non full-mac card does not require this user space API - with the MLME built in to hostapd since year dot, and in new versions of wpa_supplicant there is little need for the kernel to have a MLME API from user space - unless you are using a full-mac card. This is a great thing - goodbye to much of the awkward parts of the legacy kernel wireless APIs. In short - full-mac and non full-mac cards have very different kernel and API requirements. I'd be very careful in looking at how much their kernel support should be fully merged. It would be very interesting to do a taxonomy of the different cards, and look at where different functions are performed. One question for intel - will intel ever release a firmware for the 2100/2200 that makes the card into a non-full-mac card? (This would make unified support so much easier, as well as giving the cards much more capability and flexability.) Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Williams Sent: Wednesday, August 09, 2006 12:23 PM To: Michael Wu Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org Subject: Re: 3945 driver using d80211 On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote: > On Wednesday 09 August 2006 00:57, Johannes Berg wrote: > > Please not, for now. We need someone pushing for fullmac features in > > d80211, we need those anyway for embedded systems that can't afford > > running all of it on the main CPU. While obviously Intel would > > benefit from doing this since a lot more d80211 features would come > > available, the greater good would be having a main-stream card that > > someone cares about and helps making d80211 full-mac capable. > > > It's not that hard to generate probe, authentication, and association > frames, and it isn't done frequently enough to stress any embedded > system that can run linux. Doing this would let 3945 take advantage of > all the d80211 features, so why not? > > What level of fullmac support are we talking about? True fullmac cards > (as I define them) do not need to use d80211. WE19 is all they need, > to add > WPA/WPA2 support. The IPW cards have a particularly unique split > between firmware and host 802.11 duties which I haven't seen in any > other cards. They aren't quite fullmac enough to interface with WE > directly, yet they only need probe response handling to complete the > picture. What other half-fullmac, half-softmac card besides the other > IPW cards splits card/host 802.11 duties along those lines? What other > splits between card and host are out there? I would be very reluctant > to make changes to the 802.11 stack to support "fullmac" without evidence that other drivers need the change. The atmel driver is somewhat of a hybrid. For fullmac cards like airo, you just set the connection info up, let the card go, and you get back a link event. But the atmel driver controls authentication and association stuff; that's not done in firmware. Look at: send_authentication_request() send_association_request() atmel_transmit_management_frame() atmel_management_frame() authentic
Re: [RFC] [GIT PATCH] IPv6 Routing / Ndisc Fixes
Hi,
I still seem to have serious problems with my mailer. Despite numerous
resends, I still haven't seen my reply on netdev. Hopefully it finally
gets through, sorry for any possible duplicates.
Ville Nuorvala wrote:
> YOSHIFUJI Hideaki wrote:
>> Hello.
>
> Hello Yoshifuji-san!
>
>> Here's a set of changesets (on top of net-2.6.19 tree) to fix routing /
>> ndisc.
>> Changesets are available at:
>>
>> git://git.skbuff.net/gitroot/yoshfuji/net-2.6.19-20060809-polroute-fixes/
>
> I'd like to comment some of the NDISC patches a bit (comments inline),
> but all other changes looked good.
>
>> CHANGESETS
>> --
>>
>> commit 4f2956c43d77e1efbf044db305455493276fc6f2
>> Author: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
>> Date: Wed Aug 9 16:53:52 2006 +0900
>>
>> [IPV6] NDISC: Take source address into account for redirects.
>>
>> Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
>
> Signed-off-by: Ville Nuorvala <[EMAIL PROTECTED]>
>
>
>> ---
>> commit 40ff54178bd3c5dbd80f9422e88f7539727cc4e7
>> Author: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
>> Date: Wed Aug 9 16:53:53 2006 +0900
>>
>> [IPV6] NDISC: Search over all possible rules on receipt of redirect.
>>
>> Split up function for finding routes for redirects.
>>
>> Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
>>
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index 91c9461..4650787 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -1282,19 +1282,18 @@ static int ip6_route_del(struct in6_rtms
>> /*
>> * Handle redirects
>> */
>> -void rt6_redirect(struct in6_addr *dest, struct in6_addr *src,
>> - struct in6_addr *saddr,
>> - struct neighbour *neigh, u8 *lladdr, int on_link)
>> +struct ip6rd_flowi {
>> +struct flowi fl;
>> +struct in6_addr gateway;
>> +};
>> +
>> +static struct rt6_info *__ip6_route_redirect(struct fib6_table *table,
>> + struct flowi *fl,
>> + int flags)
>> {
>> -struct rt6_info *rt, *nrt = NULL;
>> +struct ip6rd_flowi *rdfl = (struct ip6rd_flowi *)fl;
>> +struct rt6_info *rt;
>> struct fib6_node *fn;
>> -struct fib6_table *table;
>> -struct netevent_redirect netevent;
>> -
>> -/* TODO: Very lazy, might need to check all tables */
>> -table = fib6_get_table(RT6_TABLE_MAIN);
>> -if (table == NULL)
>> -return;
>>
>> /*
>> * Get the "current" route for this destination and
>> @@ -1308,7 +1307,7 @@ void rt6_redirect(struct in6_addr *dest,
>> */
>>
>> read_lock_bh(&table->tb6_lock);
>> -fn = fib6_lookup(&table->tb6_root, dest, src);
>> +fn = fib6_lookup(&table->tb6_root, &fl->fl6_dst, &fl->fl6_src);
>> restart:
>> for (rt = fn->leaf; rt; rt = rt->u.next) {
>> /*
>> @@ -1323,29 +1322,67 @@ restart:
>> continue;
>> if (!(rt->rt6i_flags & RTF_GATEWAY))
>> continue;
>> -if (neigh->dev != rt->rt6i_dev)
>> +if (fl->oif != rt->rt6i_dev->ifindex)
>> continue;
>> -if (!ipv6_addr_equal(saddr, &rt->rt6i_gateway))
>> +if (!ipv6_addr_equal(&rdfl->gateway, &rt->rt6i_gateway))
>> continue;
>> break;
>> }
>> -if (rt)
>> -dst_hold(&rt->u.dst);
>> -else if (rt6_need_strict(dest)) {
>> -while ((fn = fn->parent) != NULL) {
>> -if (fn->fn_flags & RTN_ROOT)
>> -break;
>> -if (fn->fn_flags & RTN_RTINFO)
>> -goto restart;
>> +
>> +if (!rt) {
>> +if (rt6_need_strict(&fl->fl6_dst)) {
>> +while ((fn = fn->parent) != NULL) {
>> +if (fn->fn_flags & RTN_ROOT)
>> +break;
>> +if (fn->fn_flags & RTN_RTINFO)
>> +goto restart;
>> +}
>> }
>> +rt = &ip6_null_en
RE: 3945 driver using d80211
There are many different functions in a complete 802.11 implementation - and different implementations put these functions in different places. In general, I would consider the primary difference between a "full-mac" card and others to be the location of the MLME function. All full-mac cards perform the MLME in the card. They typically also do the conversion of data frames between 802.3 and 802.11 format in the card as well, and the inter-BSS transitions are handled in the card too. This key difference make it very unlikely that full-mac cards will implement various advanced 802.11 features - such as WDS, virtual APs, multiple clients, simultaneous client/AP modes etc etc. (Of course, by adding a large number of APIs all this can theoretically be achieved - it's just a lot more work this way). Because the full-mac cards have functions in the card that other cards do not the API for these cards will necessarily be quite different from the API for non-full-mac cards. Typically the full mac cards will only ever expose a single 802.3 interface - and hence they may not need to have an 802.11 master interface at all. They will require a user space API that includes control of MLME functions - because the MLME is in the card. A non full-mac card does not require this user space API - with the MLME built in to hostapd since year dot, and in new versions of wpa_supplicant there is little need for the kernel to have a MLME API from user space - unless you are using a full-mac card. This is a great thing - goodbye to much of the awkward parts of the legacy kernel wireless APIs. In short - full-mac and non full-mac cards have very different kernel and API requirements. I'd be very careful in looking at how much their kernel support should be fully merged. It would be very interesting to do a taxonomy of the different cards, and look at where different functions are performed. One question for intel - will intel ever release a firmware for the 2100/2200 that makes the card into a non-full-mac card? (This would make unified support so much easier, as well as giving the cards much more capability and flexability.) Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Williams Sent: Wednesday, August 09, 2006 12:23 PM To: Michael Wu Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org Subject: Re: 3945 driver using d80211 On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote: > On Wednesday 09 August 2006 00:57, Johannes Berg wrote: > > Please not, for now. We need someone pushing for fullmac features in > > d80211, we need those anyway for embedded systems that can't afford > > running all of it on the main CPU. While obviously Intel would > > benefit from doing this since a lot more d80211 features would come > > available, the greater good would be having a main-stream card that > > someone cares about and helps making d80211 full-mac capable. > > > It's not that hard to generate probe, authentication, and association > frames, and it isn't done frequently enough to stress any embedded > system that can run linux. Doing this would let 3945 take advantage of > all the d80211 features, so why not? > > What level of fullmac support are we talking about? True fullmac cards > (as I define them) do not need to use d80211. WE19 is all they need, > to add > WPA/WPA2 support. The IPW cards have a particularly unique split > between firmware and host 802.11 duties which I haven't seen in any > other cards. They aren't quite fullmac enough to interface with WE > directly, yet they only need probe response handling to complete the > picture. What other half-fullmac, half-softmac card besides the other > IPW cards splits card/host 802.11 duties along those lines? What other > splits between card and host are out there? I would be very reluctant > to make changes to the 802.11 stack to support "fullmac" without evidence that other drivers need the change. The atmel driver is somewhat of a hybrid. For fullmac cards like airo, you just set the connection info up, let the card go, and you get back a link event. But the atmel driver controls authentication and association stuff; that's not done in firmware. Look at: send_authentication_request() send_association_request() atmel_transmit_management_frame() atmel_management_frame() authenticate() associate() The driver has an auth/assoc state machine, receives management frames, and sends out the next appropriate management frame based on the current state. I think this is the reverse of ipw2100, where the firmware handles assoc/auth but not much else, but it's still less fullmac than airo, and more fullmac than softmac. Dan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PR
[PATCH] sky2: phy power problems on 88e805X chips
On the 88E805X chipsets (used in laptops), the PHY was not getting powered
out of shutdown properly. The variable reg1 was getting reused incorrectly.
This is probably the cause of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=6471
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- netdev-2.6.orig/drivers/net/sky2.c 2006-08-09 14:13:36.0 -0700
+++ netdev-2.6/drivers/net/sky2.c 2006-08-09 14:14:07.0 -0700
@@ -233,6 +233,8 @@
if (hw->ports > 1)
reg1 |= PCI_Y2_PHY2_COMA;
}
+ sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
+ udelay(100);
if (hw->chip_id == CHIP_ID_YUKON_EC_U) {
sky2_pci_write32(hw, PCI_DEV_REG3, 0);
@@ -242,9 +244,6 @@
sky2_pci_write32(hw, PCI_DEV_REG5, 0);
}
- sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
- udelay(100);
-
break;
case PCI_D3hot:
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove ugly TODO output from log files in bcm43xx-softmac
This patch removes the ugly TODO output from the logs for bcm43xx-softmac. The
patch is for the latest version of Linville's wireless-2.6 tree.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
index b095f3c..d32a9d0 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1124,9 +1124,9 @@ static void keymac_write(struct bcm43xx_
cpu_to_be16(*((u16 *)(addr + 1;
} else {
if (index < 8) {
- TODO(); /* Put them in the macaddress filter */
+ /*TODO();*/ /* Put them in the macaddress filter */
} else {
- TODO();
+ /*TODO();*/
/* Put them BCM43xx_SHM_SHARED, stating index 0x0120.
Keep in mind to update the count of keymacs in
0x003E as well! */
}
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index b095f3c..d32a9d0 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1124,9 +1124,9 @@ static void keymac_write(struct bcm43xx_
cpu_to_be16(*((u16 *)(addr + 1;
} else {
if (index < 8) {
- TODO(); /* Put them in the macaddress filter */
+ /*TODO();*/ /* Put them in the macaddress filter */
} else {
- TODO();
+ /*TODO();*/
/* Put them BCM43xx_SHM_SHARED, stating index 0x0120.
Keep in mind to update the count of keymacs in
0x003E as well! */
}
Re: 3945 driver using d80211
For 3945 a lot of functionalities were moved to the driver level, what kept in the firmware is basically some timely related functions like beacon in IBSS mode but the beacon frame is provided by the driver and the firmware is responsible to send it according to the timing constrains. Also scanning was left in the firmware. We don’t do and authentication or association frame in the firmware and we use d80211 to do this. We just needed to know once we associated to inform the firmware we are associated now. I just want to say d80211 was very flexible and easy to work with, the porting process was smooth and we only faces these problems with a working workaround and I thought we can even make d80211 more flexible to cater more varieties of cards. For ipw2[2/1]00 we did a gap analysis and we found it is hard to port it to use d80211 because of what mentioned below. I hope to post 3945 with d80211 code sometime next week so we can have the code available for our discussion. Thanks Mohamed Dan Williams wrote: On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote: On Wednesday 09 August 2006 00:57, Johannes Berg wrote: Please not, for now. We need someone pushing for fullmac features in d80211, we need those anyway for embedded systems that can't afford running all of it on the main CPU. While obviously Intel would benefit from doing this since a lot more d80211 features would come available, the greater good would be having a main-stream card that someone cares about and helps making d80211 full-mac capable. It's not that hard to generate probe, authentication, and association frames, and it isn't done frequently enough to stress any embedded system that can run linux. Doing this would let 3945 take advantage of all the d80211 features, so why not? What level of fullmac support are we talking about? True fullmac cards (as I define them) do not need to use d80211. WE19 is all they need, to add WPA/WPA2 support. The IPW cards have a particularly unique split between firmware and host 802.11 duties which I haven't seen in any other cards. They aren't quite fullmac enough to interface with WE directly, yet they only need probe response handling to complete the picture. What other half-fullmac, half-softmac card besides the other IPW cards splits card/host 802.11 duties along those lines? What other splits between card and host are out there? I would be very reluctant to make changes to the 802.11 stack to support "fullmac" without evidence that other drivers need the change. The atmel driver is somewhat of a hybrid. For fullmac cards like airo, you just set the connection info up, let the card go, and you get back a link event. But the atmel driver controls authentication and association stuff; that's not done in firmware. Look at: send_authentication_request() send_association_request() atmel_transmit_management_frame() atmel_management_frame() authenticate() associate() The driver has an auth/assoc state machine, receives management frames, and sends out the next appropriate management frame based on the current state. I think this is the reverse of ipw2100, where the firmware handles assoc/auth but not much else, but it's still less fullmac than airo, and more fullmac than softmac. Dan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND 2/4] [RTNETLINK]: Use rtnl_multicast()/rtnl_unicast()
... forgot to export the new symbols.
Introduces rtnl_multicast() to broadcast events and rtnl_unicast()
to send unicast messages via the rtnl socket.
This obsoletes rtnetlink_send() which wrongly provided the netlink
pid of the requesting applications to netlink_broadcast() which
lead to events not being sent to that application even though it
was subscribed.
This patch ensures consistency in all rtnetlink event notification
mechansims, i.e. the pid of the requesting application is kept
in nlmsg_pid to help applications such as quagga to identify whether
the event was caused by themselves and properly feeds all calls
to netlink_broadcast() with a pid of 0 to not exclude any sockets.
Removes the obsoleted NLM_F_ECHO code.
Some notifications are done in atomic contex, therefore
nlmsg_multicast() had to be extended to take allocation flags.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19.git/include/linux/rtnetlink.h
===
--- net-2.6.19.git.orig/include/linux/rtnetlink.h
+++ net-2.6.19.git/include/linux/rtnetlink.h
@@ -583,7 +583,8 @@ struct rtnetlink_link
};
extern struct rtnetlink_link * rtnetlink_links[NPROTO];
-extern int rtnetlink_send(struct sk_buff *skb, u32 pid, u32 group, int echo);
+extern int rtnl_multicast(struct sk_buff *skb, unsigned int group, gfp_t
flags);
+extern int rtnl_unicast(struct sk_buff *skb, u32 pid);
extern int rtnetlink_put_metrics(struct sk_buff *skb, u32 *metrics);
extern void __rta_fill(struct sk_buff *skb, int attrtype, int attrlen, const
void *data);
Index: net-2.6.19.git/net/core/rtnetlink.c
===
--- net-2.6.19.git.orig/net/core/rtnetlink.c
+++ net-2.6.19.git/net/core/rtnetlink.c
@@ -153,17 +153,14 @@ size_t rtattr_strlcpy(char *dest, const
return ret;
}
-int rtnetlink_send(struct sk_buff *skb, u32 pid, unsigned group, int echo)
+int rtnl_multicast(struct sk_buff *skb, unsigned int group, gfp_t flags)
{
- int err = 0;
+ return nlmsg_multicast(rtnl, skb, 0, group, flags);
+}
- NETLINK_CB(skb).dst_group = group;
- if (echo)
- atomic_inc(&skb->users);
- netlink_broadcast(rtnl, skb, pid, group, GFP_KERNEL);
- if (echo)
- err = netlink_unicast(rtnl, skb, pid, MSG_DONTWAIT);
- return err;
+int rtnl_unicast(struct sk_buff *skb, u32 pid)
+{
+ return nlmsg_unicast(rtnl, skb, pid);
}
int rtnetlink_put_metrics(struct sk_buff *skb, u32 *metrics)
@@ -560,9 +557,7 @@ static int rtnl_getlink(struct sk_buff *
goto errout;
}
- err = netlink_unicast(rtnl, skb, NETLINK_CB(skb).pid, MSG_DONTWAIT);
- if (err > 0)
- err = 0;
+ err = rtnl_unicast(skb, NETLINK_CB(skb).pid);
errout:
kfree(iw_buf);
dev_put(dev);
@@ -609,8 +604,8 @@ void rtmsg_ifinfo(int type, struct net_d
kfree_skb(skb);
return;
}
- NETLINK_CB(skb).dst_group = RTNLGRP_LINK;
- netlink_broadcast(rtnl, skb, 0, RTNLGRP_LINK, GFP_KERNEL);
+
+ rtnl_multicast(skb, RTNLGRP_LINK, GFP_KERNEL);
}
/* Protected by RTNL sempahore. */
@@ -811,3 +806,5 @@ EXPORT_SYMBOL(rtnl);
EXPORT_SYMBOL(rtnl_lock);
EXPORT_SYMBOL(rtnl_trylock);
EXPORT_SYMBOL(rtnl_unlock);
+EXPORT_SYMBOL(rtnl_multicast);
+EXPORT_SYMBOL(rtnl_unicast);
Index: net-2.6.19.git/net/decnet/dn_table.c
===
--- net-2.6.19.git.orig/net/decnet/dn_table.c
+++ net-2.6.19.git/net/decnet/dn_table.c
@@ -343,12 +343,8 @@ static void dn_rtmsg_fib(int event, stru
kfree_skb(skb);
return;
}
-NETLINK_CB(skb).dst_group = RTNLGRP_DECnet_ROUTE;
-if (nlh->nlmsg_flags & NLM_F_ECHO)
-atomic_inc(&skb->users);
-netlink_broadcast(rtnl, skb, pid, RTNLGRP_DECnet_ROUTE, GFP_KERNEL);
-if (nlh->nlmsg_flags & NLM_F_ECHO)
-netlink_unicast(rtnl, skb, pid, MSG_DONTWAIT);
+
+ rtnl_multicast(skb, RTNLGRP_DECnet_ROUTE, GFP_KERNEL);
}
static __inline__ int dn_hash_dump_bucket(struct sk_buff *skb,
Index: net-2.6.19.git/net/ipv4/fib_semantics.c
===
--- net-2.6.19.git.orig/net/ipv4/fib_semantics.c
+++ net-2.6.19.git/net/ipv4/fib_semantics.c
@@ -291,12 +291,8 @@ void rtmsg_fib(int event, u32 key, struc
kfree_skb(skb);
return;
}
- NETLINK_CB(skb).dst_group = RTNLGRP_IPV4_ROUTE;
- if (n->nlmsg_flags&NLM_F_ECHO)
- atomic_inc(&skb->users);
- netlink_broadcast(rtnl, skb, pid, RTNLGRP_IPV4_ROUTE, GFP_KERNEL);
- if (n->nlmsg_flags&NLM_F_ECHO)
- netlink_unicast(rtnl, skb, pid, MSG_DONTWAIT);
+
+ rtnl_multicast(skb, RTNLGRP_IPV4_ROUTE, GFP_KERNEL);
}
/* Return the first fib alias matching TOS with
Index: net
[PATCH 4/4] [RTNETLINK]: Unexport global rtnl sock
All references to the rtnl sock are now done via wrapper
functions, unexport it.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19.git/include/linux/rtnetlink.h
===
--- net-2.6.19.git.orig/include/linux/rtnetlink.h
+++ net-2.6.19.git/include/linux/rtnetlink.h
@@ -574,8 +574,6 @@ extern int rtattr_parse(struct rtattr *t
#define rtattr_parse_nested(tb, max, rta) \
rtattr_parse((tb), (max), RTA_DATA((rta)), RTA_PAYLOAD((rta)))
-extern struct sock *rtnl;
-
struct rtnetlink_link
{
int (*doit)(struct sk_buff *, struct nlmsghdr*, void *attr);
Index: net-2.6.19.git/net/core/rtnetlink.c
===
--- net-2.6.19.git.orig/net/core/rtnetlink.c
+++ net-2.6.19.git/net/core/rtnetlink.c
@@ -58,6 +58,7 @@
#endif /* CONFIG_NET_WIRELESS_RTNETLINK */
static DEFINE_MUTEX(rtnl_mutex);
+static struct sock *rtnl;
void rtnl_lock(void)
{
@@ -95,8 +96,6 @@ int rtattr_parse(struct rtattr *tb[], in
return 0;
}
-struct sock *rtnl;
-
struct rtnetlink_link * rtnetlink_links[NPROTO];
static const int rtm_min[RTM_NR_FAMILIES] =
@@ -802,7 +801,6 @@ EXPORT_SYMBOL(rtattr_strlcpy);
EXPORT_SYMBOL(rtattr_parse);
EXPORT_SYMBOL(rtnetlink_links);
EXPORT_SYMBOL(rtnetlink_put_metrics);
-EXPORT_SYMBOL(rtnl);
EXPORT_SYMBOL(rtnl_lock);
EXPORT_SYMBOL(rtnl_trylock);
EXPORT_SYMBOL(rtnl_unlock);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] [NETLINK]: Dont set socket error for failed event notifications
Setting a socket error on all sockets subscribed to a group
if an event notificiation of said group fails due to memory
pressure only confuses applications and is of no use.
This patch removes it all together.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19.git/net/bridge/br_netlink.c
===
--- net-2.6.19.git.orig/net/bridge/br_netlink.c
+++ net-2.6.19.git/net/bridge/br_netlink.c
@@ -76,25 +76,17 @@ rtattr_failure:
void br_ifinfo_notify(int event, struct net_bridge_port *port)
{
struct sk_buff *skb;
- int err = -ENOMEM;
pr_debug("bridge notify event=%d\n", event);
skb = alloc_skb(NLMSG_SPACE(sizeof(struct ifinfomsg) + 128),
GFP_ATOMIC);
if (!skb)
- goto err_out;
+ return;
- err = br_fill_ifinfo(skb, port, current->pid, 0, event, 0);
- if (err)
- goto err_kfree;
-
- rtnl_multicast(skb, RTNLGRP_LINK, GFP_ATOMIC);
- return;
-
-err_kfree:
- kfree_skb(skb);
-err_out:
- netlink_set_err(rtnl, 0, RTNLGRP_LINK, err);
+ if (br_fill_ifinfo(skb, port, current->pid, 0, event, 0) <= 0)
+ kfree_skb(skb);
+ else
+ rtnl_multicast(skb, RTNLGRP_LINK, GFP_ATOMIC);
}
/*
Index: net-2.6.19.git/net/core/fib_rules.c
===
--- net-2.6.19.git.orig/net/core/fib_rules.c
+++ net-2.6.19.git/net/core/fib_rules.c
@@ -349,11 +349,11 @@ static void notify_rule_change(int event
struct sk_buff *skb = alloc_skb(size, GFP_KERNEL);
if (skb == NULL)
- netlink_set_err(rtnl, 0, ops->nlgroup, ENOBUFS);
- else if (fib_nl_fill_rule(skb, rule, 0, 0, event, 0, ops) < 0) {
+ return;
+
+ if (fib_nl_fill_rule(skb, rule, 0, 0, event, 0, ops) <= 0)
kfree_skb(skb);
- netlink_set_err(rtnl, 0, ops->nlgroup, EINVAL);
- } else
+ else
rtnl_multicast(skb, ops->nlgroup, GFP_KERNEL);
}
Index: net-2.6.19.git/net/decnet/dn_dev.c
===
--- net-2.6.19.git.orig/net/decnet/dn_dev.c
+++ net-2.6.19.git/net/decnet/dn_dev.c
@@ -748,17 +748,13 @@ static void rtmsg_ifa(int event, struct
int size = NLMSG_SPACE(sizeof(struct ifaddrmsg)+128);
skb = alloc_skb(size, GFP_KERNEL);
- if (!skb) {
- netlink_set_err(rtnl, 0, RTNLGRP_DECnet_IFADDR, ENOBUFS);
- return;
- }
- if (dn_dev_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) {
- kfree_skb(skb);
- netlink_set_err(rtnl, 0, RTNLGRP_DECnet_IFADDR, EINVAL);
+ if (skb == NULL)
return;
- }
- rtnl_multicast(skb, RTNLGRP_DECnet_IFADDR, GFP_KERNEL);
+ if (dn_dev_fill_ifaddr(skb, ifa, 0, 0, event, 0) <= 0)
+ kfree_skb(skb);
+ else
+ rtnl_multicast(skb, RTNLGRP_DECnet_IFADDR, GFP_KERNEL);
}
static int dn_dev_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
Index: net-2.6.19.git/net/ipv4/devinet.c
===
--- net-2.6.19.git.orig/net/ipv4/devinet.c
+++ net-2.6.19.git/net/ipv4/devinet.c
@@ -1195,11 +1195,11 @@ static void rtmsg_ifa(int event, struct
skb = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
if (skb == NULL)
- netlink_set_err(rtnl, 0, RTNLGRP_IPV4_IFADDR, ENOBUFS);
- else if (inet_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) {
+ return;
+
+ if (inet_fill_ifaddr(skb, ifa, 0, 0, event, 0) <= 0)
kfree_skb(skb);
- netlink_set_err(rtnl, 0, RTNLGRP_IPV4_IFADDR, EINVAL);
- } else
+ else
rtnl_multicast(skb, RTNLGRP_IPV4_IFADDR, GFP_KERNEL);
}
Index: net-2.6.19.git/net/ipv6/addrconf.c
===
--- net-2.6.19.git.orig/net/ipv6/addrconf.c
+++ net-2.6.19.git/net/ipv6/addrconf.c
@@ -3283,17 +3283,13 @@ static void inet6_ifa_notify(int event,
int size = NLMSG_SPACE(sizeof(struct ifaddrmsg) +
INET6_IFADDR_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
- if (!skb) {
- netlink_set_err(rtnl, 0, RTNLGRP_IPV6_IFADDR, ENOBUFS);
+ if (skb == NULL)
return;
- }
- if (inet6_fill_ifaddr(skb, ifa, current->pid, 0, event, 0) < 0) {
- kfree_skb(skb);
- netlink_set_err(rtnl, 0, RTNLGRP_IPV6_IFADDR, EINVAL);
- return;
- }
- rtnl_multicast(skb, RTNLGRP_IPV6_IFADDR, GFP_ATOMIC);
+ if (inet6_fill_ifaddr(skb, ifa, current->pid, 0, event, 0) <= 0)
+ kfree_skb(skb);
+ else
+ rtnl_multicast(skb, RTNLGRP_IPV6_IFADDR, GFP_ATOMIC);
}
static void inline ipv6_store_devconf(struct ipv6_devconf *cnf,
@@
[PATCH 1/4] [NETLINK]: Handle NLM_F_ECHO in netlink_rcv_skb()
The current behaviour around NLM_F_ECHO is inconsistent
and spread all around in various subsystems and doesn't
represent what it was meant for.
This patch handles NLM_F_ECHO in netlink_rcv_skb() to
handle it in a central point. Most subsystems currently
interpret NLM_F_ECHO as to just unicast events to the
originator of the change while the real meaning of the
flag is to echo the request.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19.git/net/netlink/af_netlink.c
===
--- net-2.6.19.git.orig/net/netlink/af_netlink.c
+++ net-2.6.19.git/net/netlink/af_netlink.c
@@ -1430,6 +1430,28 @@ int netlink_dump_start(struct sock *ssk,
return 0;
}
+static void netlink_echo(struct sk_buff *in_skb, struct nlmsghdr *orig)
+{
+ struct sk_buff *skb;
+ struct nlmsghdr *nlh;
+ int payload = nlmsg_len(orig);
+
+ skb = nlmsg_new(nlmsg_total_size(payload), GFP_KERNEL);
+ if (skb == NULL)
+ return;
+
+ /*
+* Return original header with pid set to 0 (from kernel) and
+* NLM_F_REQUEST flag removed to indicate this is not a request
+* for an echo but the reply.
+*/
+ nlh = __nlmsg_put(skb, 0, orig->nlmsg_seq, orig->nlmsg_type,
+ payload, orig->nlmsg_flags & ~NLM_F_REQUEST);
+ memcpy(nlmsg_data(nlh), nlmsg_data(orig), payload);
+
+ nlmsg_unicast(in_skb->sk, skb, NETLINK_CB(in_skb).pid);
+}
+
void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err)
{
struct sk_buff *skb;
@@ -1476,6 +1498,9 @@ static int netlink_rcv_skb(struct sk_buf
if (nlh->nlmsg_len < NLMSG_HDRLEN || skb->len < nlh->nlmsg_len)
return 0;
+ if (nlh->nlmsg_flags & NLM_F_ECHO)
+ netlink_echo(skb, nlh);
+
if (cb(skb, nlh, &err) < 0) {
/* Not an error, but we have to interrupt processing
* here. Note: that in this case we do not pull
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] [RTNETLINK]: Use rtnl_multicast()/rtnl_unicast()
Introduces rtnl_multicast() to broadcast events and rtnl_unicast()
to send unicast messages via the rtnl socket.
This obsoletes rtnetlink_send() which wrongly provided the netlink
pid of the requesting applications to netlink_broadcast() which
lead to events not being sent to that application even though it
was subscribed.
This patch ensures consistency in all rtnetlink event notification
mechansims, i.e. the pid of the requesting application is kept
in nlmsg_pid to help applications such as quagga to identify whether
the event was caused by themselves and properly feeds all calls
to netlink_broadcast() with a pid of 0 to not exclude any sockets.
Removes the obsoleted NLM_F_ECHO code.
Some notifications are done in atomic contex, therefore
nlmsg_multicast() had to be extended to take allocation flags.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19.git/include/linux/rtnetlink.h
===
--- net-2.6.19.git.orig/include/linux/rtnetlink.h
+++ net-2.6.19.git/include/linux/rtnetlink.h
@@ -583,7 +583,8 @@ struct rtnetlink_link
};
extern struct rtnetlink_link * rtnetlink_links[NPROTO];
-extern int rtnetlink_send(struct sk_buff *skb, u32 pid, u32 group, int echo);
+extern int rtnl_multicast(struct sk_buff *skb, unsigned int group, gfp_t
flags);
+extern int rtnl_unicast(struct sk_buff *skb, u32 pid);
extern int rtnetlink_put_metrics(struct sk_buff *skb, u32 *metrics);
extern void __rta_fill(struct sk_buff *skb, int attrtype, int attrlen, const
void *data);
Index: net-2.6.19.git/net/core/rtnetlink.c
===
--- net-2.6.19.git.orig/net/core/rtnetlink.c
+++ net-2.6.19.git/net/core/rtnetlink.c
@@ -153,17 +153,14 @@ size_t rtattr_strlcpy(char *dest, const
return ret;
}
-int rtnetlink_send(struct sk_buff *skb, u32 pid, unsigned group, int echo)
+int rtnl_multicast(struct sk_buff *skb, unsigned int group, gfp_t flags)
{
- int err = 0;
+ return nlmsg_multicast(rtnl, skb, 0, group, flags);
+}
- NETLINK_CB(skb).dst_group = group;
- if (echo)
- atomic_inc(&skb->users);
- netlink_broadcast(rtnl, skb, pid, group, GFP_KERNEL);
- if (echo)
- err = netlink_unicast(rtnl, skb, pid, MSG_DONTWAIT);
- return err;
+int rtnl_unicast(struct sk_buff *skb, u32 pid)
+{
+ return nlmsg_unicast(rtnl, skb, pid);
}
int rtnetlink_put_metrics(struct sk_buff *skb, u32 *metrics)
@@ -560,9 +557,7 @@ static int rtnl_getlink(struct sk_buff *
goto errout;
}
- err = netlink_unicast(rtnl, skb, NETLINK_CB(skb).pid, MSG_DONTWAIT);
- if (err > 0)
- err = 0;
+ err = rtnl_unicast(skb, NETLINK_CB(skb).pid);
errout:
kfree(iw_buf);
dev_put(dev);
@@ -609,8 +604,8 @@ void rtmsg_ifinfo(int type, struct net_d
kfree_skb(skb);
return;
}
- NETLINK_CB(skb).dst_group = RTNLGRP_LINK;
- netlink_broadcast(rtnl, skb, 0, RTNLGRP_LINK, GFP_KERNEL);
+
+ rtnl_multicast(skb, RTNLGRP_LINK, GFP_KERNEL);
}
/* Protected by RTNL sempahore. */
Index: net-2.6.19.git/net/decnet/dn_table.c
===
--- net-2.6.19.git.orig/net/decnet/dn_table.c
+++ net-2.6.19.git/net/decnet/dn_table.c
@@ -343,12 +343,8 @@ static void dn_rtmsg_fib(int event, stru
kfree_skb(skb);
return;
}
-NETLINK_CB(skb).dst_group = RTNLGRP_DECnet_ROUTE;
-if (nlh->nlmsg_flags & NLM_F_ECHO)
-atomic_inc(&skb->users);
-netlink_broadcast(rtnl, skb, pid, RTNLGRP_DECnet_ROUTE, GFP_KERNEL);
-if (nlh->nlmsg_flags & NLM_F_ECHO)
-netlink_unicast(rtnl, skb, pid, MSG_DONTWAIT);
+
+ rtnl_multicast(skb, RTNLGRP_DECnet_ROUTE, GFP_KERNEL);
}
static __inline__ int dn_hash_dump_bucket(struct sk_buff *skb,
Index: net-2.6.19.git/net/ipv4/fib_semantics.c
===
--- net-2.6.19.git.orig/net/ipv4/fib_semantics.c
+++ net-2.6.19.git/net/ipv4/fib_semantics.c
@@ -291,12 +291,8 @@ void rtmsg_fib(int event, u32 key, struc
kfree_skb(skb);
return;
}
- NETLINK_CB(skb).dst_group = RTNLGRP_IPV4_ROUTE;
- if (n->nlmsg_flags&NLM_F_ECHO)
- atomic_inc(&skb->users);
- netlink_broadcast(rtnl, skb, pid, RTNLGRP_IPV4_ROUTE, GFP_KERNEL);
- if (n->nlmsg_flags&NLM_F_ECHO)
- netlink_unicast(rtnl, skb, pid, MSG_DONTWAIT);
+
+ rtnl_multicast(skb, RTNLGRP_IPV4_ROUTE, GFP_KERNEL);
}
/* Return the first fib alias matching TOS with
Index: net-2.6.19.git/net/sched/act_api.c
===
--- net-2.6.19.git.orig/net/sched/act_api.c
+++ net-2.6.19.git/net/sched/act_api.c
@@ -459,7 +459,6 @@ static int
act_get_notify
[PATCHSET]: Clean up netlink NLM_F_ECHO and rtnl event notifications
Aims at cleaning up rtnetlink event notifications and implements real NLM_F_ECHO support. Please disregard my last IPv4 routing related patchset, I'll resubmit it based on this patchset. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211 merge plans
On Wed, Aug 09, 2006 at 01:40:27AM -0400, Jeff Garzik wrote: > Michael Buesch wrote: > >To heavily reduce maintainance burden I would like to see d80211 > >going mainline as soon as possible > Does it have active maintainers? > > The DeviceScape people seem to have disappeared for months, except for a > rare appearance recently by Jouni. Unfortunately, I have been tied up in another project that required way too much of my time last couple of months. Getting this code into suitable state for merging it into mainline and then making sure it remains in working condition is my highest priority and we have freed up more of my time for this. We are planning on using this tree in our future products and want to be able to remain as close to the version that is in the mainline tree as possible, so it is indeed in our interest to make sure that this gets maintained. We have a group of people working on this and merging rest of our AP product to be based on this version. I'll try to be more actively involved in getting the changes submitted to wireless-dev (and hopefully, into mainline once the code gets there). -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] d80211/bcm43xx: Modify struct ieee80211_rx_status for wireless statistics.
On Wed, Aug 09, 2006 at 10:21:16AM -0500, Larry Finger wrote: > Dan Williams wrote: > >> int ssi; > >>+ int maxssi; > >Spacing? Looks like you're using real tabs here, but the current code > >uses 8 spaces instead. Not sure if that's a problem. > > I am using tabs, which I think is the preferred way. I also remember that > the rule is not to change the white space on things you are not touching. > Is that correct? That's at least the way I would prefer to do this. Unrelated whitespace changes as part of a patch are almost always bad and large patch of modifying just the whitespaces around the tree is likely to add large number of conflicts for pending work that goes on at the moment. Unfortunately, I forgot to replace this part when making the initial release of the Devicescape stack. I've always used tabs myself, but some of the areas of the code that I did not write was done using spaces. Anyway, this should move to using tabs over time whenever source code is being modified. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
On Wed, 2006-08-09 at 21:45 +0200, Peter Zijlstra wrote: > On Wed, 2006-08-09 at 20:34 +0200, Indan Zupancic wrote: > > Why is it needed for the protocol specific code to call dev_unreserve_skb? > > It uses this to get an indication of memory pressure; if we have > memalloc'ed skbs memory pressure must be high, hence we must drop all > non critical packets. But you are right in that this is a problematic > area; the mapping from skb to device is non trivial. > > Your suggestion of testing skb->memalloc might work just as good; indeed > if we have regressed into the fallback allocator we know we have > pressure. > > > Only problem is if the device can change. rx_reserve_used should probably > > be updated when that happens, as a skb can't use reserved memory on a device > > it was moved away from. (right?) > > Well yes, this is a problem, only today have I understood how volatile > the mapping actually is. I think you are right in that transferring the > accounting from the old to the new device is correct solution. > > However this brings us the problem of limiting the fallback allocator; > currently this is done in __netdev_alloc_skb where rx_reserve_used it > compared against rx_reserve. If we transfer accounting away this will > not work anymore. I'll have to think about this case, perhaps we already > have a problem here. Humm, if we do not use dev_reserve_used in the protocols anymore, the only place that still uses it is the fallback limit. If we could solve that in another way we might be able to get rid of it all together. That would save the pain of managing the accounting transferal on skb::dev assignments too. Daniel, any ideas? I'm fighting to stay awake... ;-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211 merge plans
David Miller wrote: From: Michael Buesch <[EMAIL PROTECTED]> Date: Wed, 9 Aug 2006 07:03:41 +0200 I am wondering about d80211 mainline merge plans. I think this is a non-started until the SMP problems are worked out. Is it still SMP challenged? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html I been using d80211 stack for about a month I have not encounter any SMP issues. We are currently involving validation engineers to do more stress tests and will see if any SMP issues come up. Mohamed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
On Wed, 2006-08-09 at 20:34 +0200, Indan Zupancic wrote: > On Wed, August 9, 2006 16:00, Peter Zijlstra said: > > On Wed, 2006-08-09 at 15:48 +0200, Indan Zupancic wrote: > >> On Wed, August 9, 2006 14:54, Peter Zijlstra said: > >> > On Wed, 2006-08-09 at 14:02 +0200, Indan Zupancic wrote: > >> >> That avoids lots of checks and should guarantee that the > >> >> accounting is correct, except in the case when the IFF_MEMALLOC flag is > >> >> cleared and the counter is set to zero manually. Can't that be avoided > >> >> and > >> >> just let it decrease to zero naturally? > >> > > >> > That would put the atomic op on the free path unconditionally, I think > >> > davem gets nightmares from that. > >> > >> I confused SOCK_MEMALLOC with sk_buff::memalloc, sorry. What I meant was > >> to unconditionally decrement the reserved usage only when memalloc is true > >> on the free path. That way all skbs that increased the reserve also > >> decrease > >> it, and the counter should never go below zero. > > > > OK, so far so good, except we loose the notion of getting memory back > > from regular skbs. > > I don't understand this, regular skbs don't have anything to do with > rx_reserve_used as far as I can see. I'm only talking about keeping > that field up to date and correct. rx_reserve_used is only increased > by a skb when memalloc is set to true on that skb, so only if that field > is set rx_reserve_used needs to be reduced when the skb is freed. I know what you ment, and if you've looked at -v2 you'll see that I've done this, basically because its easier. However the thought behind the other semantics is, any skb freed will reduce memory pressure. > Why is it needed for the protocol specific code to call dev_unreserve_skb? It uses this to get an indication of memory pressure; if we have memalloc'ed skbs memory pressure must be high, hence we must drop all non critical packets. But you are right in that this is a problematic area; the mapping from skb to device is non trivial. Your suggestion of testing skb->memalloc might work just as good; indeed if we have regressed into the fallback allocator we know we have pressure. > Only problem is if the device can change. rx_reserve_used should probably > be updated when that happens, as a skb can't use reserved memory on a device > it was moved away from. (right?) Well yes, this is a problem, only today have I understood how volatile the mapping actually is. I think you are right in that transferring the accounting from the old to the new device is correct solution. However this brings us the problem of limiting the fallback allocator; currently this is done in __netdev_alloc_skb where rx_reserve_used it compared against rx_reserve. If we transfer accounting away this will not work anymore. I'll have to think about this case, perhaps we already have a problem here. > >> Also as far as I can see it should be possible to replace all atomic > >> "if (unlikely(dev_reserve_used(skb->dev)))" checks witha check if > >> memalloc is set. That should make davem happy, as there aren't any > >> atomic instructions left in hot paths. > > > > dev_reserve_used() uses atomic_read() which isn't actually a LOCK'ed > > instruction, so that should not matter. > > Perhaps, but the main reason to check memalloc instead of using > dev_reserve_used is because the latter doesn't tell which skb did the > reservation. Very good point indeed. > >> If IFF_MEMALLOC is set new skbs set memalloc and increase the reserve. > > > > Not quite, if IFF_MEMALLOC is set new skbs _could_ get memalloc set. We > > only fall back to alloc_pages() if the regular path fails to alloc. If the > > skb is backed by a page (as opposed to kmem_cache fluff) sk_buff::memalloc > > is set. > > Yes, true. But doesn't matter for the rx_reserve_used accounting, as long as > memalloc set means that it did increase rx_reserve_used. > > > Also, I've been thinking (more pain), should I not up the reserve for > > each SOCK_MEMALLOC socket. > > Up rx_reserve_used or the total ammount of reserved memory? Probably 'no' for > both though, as it's either device specific or skb dependent. I came up with yes, if for each socket you gain a request queue, the number of in-flight pages is proportional to the number of sockets. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
On Wed, Aug 09, 2006 at 03:32:33PM +0200, Peter Zijlstra ([EMAIL PROTECTED]) wrote: > > > > >http://lwn.net/Articles/144273/ > > > > >"Kernel Summit 2005: Convergence of network and storage paths" > > > > > > > > > > We believe that an approach very much like today's patch set is > > > > > necessary for NBD, iSCSI, AoE or the like ever to work reliably. > > > > > We further believe that a properly working version of at least one of > > > > > these subsystems is critical to the viability of Linux as a modern > > > > > storage platform. > > > > > > > > There is another approach for that - do not use slab allocator for > > > > network dataflow at all. It automatically has all you pros amd if > > > > implemented correctly can have a lot of additional usefull and > > > > high-performance features like full zero-copy and total fragmentation > > > > avoidance. > > > > > > On your site where you explain the Network Tree Allocator: > > > > > > http://tservice.net.ru/~s0mbre/blog/devel/networking/nta/index.html > > > > > > You only test the fragmentation scenario with the full scale of sizes. > > > Fragmentation will look different if you use a limited number of sizes > > > that share no factors (other than the block size); try 19, 37 and 79 > > > blocks with 1:1:1 ratio. > ^^ > > > 19, 37 and 79 will be rounded by SLAB to 32, 64 and 128 bytes, with NTA it > > will be 32, 64 and 96 bytes. NTA wins in each allocation which is not > > power-of-two (I use 32 bytes alignemnt, as the smallest one which SLAB > > uses). And as you saw in the blog, network tree allocator is faster > > than SLAB one, although it can have different side effects which are not > > yet 100% discovered. > > So that would end up being 19*32 = 608 bytes, etc.. > As for speed, sure. NTA aligns data to 32bytes, SLAB to power of two, so overhead becomes extremely large for unaligned access for almost every sizes. > > > Also, I have yet to see how you will do full zero-copy receives; full > > > zero-copy would mean getting the data from driver DMA to user-space > > > without > > > a single copy. The to user-space part almost requires that each packet > > > live > > > on its own page. > > > > Each page can easily have several packets inside. > > For sure, the problem is: do you know for which user-space process a > packet > is going to be before you receive it? That is not a problem for sniffer, if some process wants that data it can be copied, it can be checked if neighbour packet is for the same socket and do not copy in that case - there are a lot of things which can be done, when data _is_ in place. NTA allows zero-copy access to the whole network traffic, how system is going to work with it is another task. > > > As for the VM deadlock avoidance; I see no zero overhead allocation path > > > - you do not want to deadlock your allocator. I see no critical resource > > > isolation (our SOCK_MEMALLOC). Without these things your allocator might > > > improve the status quo but it will not aid in avoiding the deadlock we > > > try to tackle here. > > > > Because such reservation is not needed at all. > > SLAB OOM can be handled by reserving pool using SOCK_MEMALLOC and > > similar hacks, and different allocator, which obviously work with own > > pool of pages, can not suffer from SLAB problems. > > > > You say "critical resource isolation", but it is not the case - consider > > NFS over UDP - remote side will not stop sending just because receiving > > socket code drops data due to OOM, or IPsec or compression, which can > > requires reallocation. There is no "critical resource isolation", since > > reserved pool _must_ be used by everyone in the kernel network stack. > > The idea is to drop all !NFS packets (or even more specific only keep > those > NFS packets that belong to the critical mount), and everybody doing > critical > IO over layered networks like IPSec or other tunnel constructs asks for > trouble - Just DON'T do that. Well, such approach does not scale well - either it must be generic enough to fully solve the problem, or solve it at least at the most casees, but when you turn anything off - that is not what is expected I suppose. > Dropping these non-essential packets makes sure the reserve memory > doesn't > get stuck in some random blocked user-space process, hence you can make > progress. It still requires to receive and analyze the packet before deciding to drop it. Different allocator is just next step in idea of reserved pool. > > And as you saw fragmentation issues are handled very good in NTA, just > > consider usual packet with data with 1500 MTU - 500 bytes are wasted. > > If you use jumbo frames... it is posible to end up with 32k allocation > > for 9k jumbo frame with some hardware. > > Sure, SLAB does suck at some things, and I don't argue that NTA will > not > improve. Its just that 'total fragmentation avoidance' it too strong > and > this deadlock avoidance needs more. Wel
Re: 3945 driver using d80211
On Wed, 2006-08-09 at 09:47 -0700, Michael Wu wrote: > On Wednesday 09 August 2006 00:57, Johannes Berg wrote: > > Please not, for now. We need someone pushing for fullmac features in > > d80211, we need those anyway for embedded systems that can't afford > > running all of it on the main CPU. While obviously Intel would benefit > > from doing this since a lot more d80211 features would come available, > > the greater good would be having a main-stream card that someone cares > > about and helps making d80211 full-mac capable. > > > It's not that hard to generate probe, authentication, and association frames, > and it isn't done frequently enough to stress any embedded system that can > run linux. Doing this would let 3945 take advantage of all the d80211 > features, so why not? > > What level of fullmac support are we talking about? True fullmac cards (as I > define them) do not need to use d80211. WE19 is all they need, to add > WPA/WPA2 support. The IPW cards have a particularly unique split between > firmware and host 802.11 duties which I haven't seen in any other cards. They > aren't quite fullmac enough to interface with WE directly, yet they only need > probe response handling to complete the picture. What other half-fullmac, > half-softmac card besides the other IPW cards splits card/host 802.11 duties > along those lines? What other splits between card and host are out there? I > would be very reluctant to make changes to the 802.11 stack to support > "fullmac" without evidence that other drivers need the change. The atmel driver is somewhat of a hybrid. For fullmac cards like airo, you just set the connection info up, let the card go, and you get back a link event. But the atmel driver controls authentication and association stuff; that's not done in firmware. Look at: send_authentication_request() send_association_request() atmel_transmit_management_frame() atmel_management_frame() authenticate() associate() The driver has an auth/assoc state machine, receives management frames, and sends out the next appropriate management frame based on the current state. I think this is the reverse of ipw2100, where the firmware handles assoc/auth but not much else, but it's still less fullmac than airo, and more fullmac than softmac. Dan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Excess use of packed attribute
David Miller wrote: > From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Mon, 7 Aug 2006 13:34:23 -0700 > >> Silly offenders: include/net/ipx.h >> include/net/ieee80211.h >> include/net/ip6_tunnel.h >> include/net/ndisc.h >> include/linux/if_ether.h >> include/linux/if_fddi.h >> >> include/linux/sctp.h -- really bad > > The ndisc.h one, for example, is needed for cases like ARM. > > The if_ether.h one is also needed, or else for: > > struct ethhdr *eth; > > "eth + 1" would do the wrong thing as the compiler would > align the structure to the native pointer size or similar. > This is an issue because ethhdr is 14 bytes in size. Similarly the ipv6_tlv_tnl_enc_lim in ip6_tunnel.h is a 3-octet IPv6 destination sub-option. The sub-option can be located anywhere inside the destination option header and can only be found by parsing the whole header. Regards, Ville - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take6 1/3] kevent: Core files.
On Wed, Aug 09, 2006 at 10:47:38AM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> > +static inline void kevent_user_stat_increase_total(struct kevent_user *u)
> > +{
> > + u->total++;
> > +}
> >
>
> static wrapper_functions_with_execessive_long_names(struct i_really_hate
> *this)
> {
> suck();
> }
Understood...
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
On Wed, Aug 09, 2006 at 02:25:39AM -0400, Jeff Garzik wrote: > > Please pull from 'upstream-greg' branch of > master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git > upstream-greg > > to receive the following updates: > > drivers/net/myri10ge/myri10ge.c |2 +- > net/core/wireless.c | 24 +++- > 2 files changed, 24 insertions(+), 2 deletions(-) Applied, thanks. greg k-h - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] sock_register interface changes
The sock_register() doesn't change the family, so the protocols can
define it read-only. No caller ever checks return value from sock_unregister()
---
include/linux/net.h |4 ++--
net/socket.c| 10 --
2 files changed, 6 insertions(+), 8 deletions(-)
--- net-2.6.orig/include/linux/net.h2006-08-09 11:19:19.0 -0700
+++ net-2.6/include/linux/net.h 2006-08-09 11:19:24.0 -0700
@@ -176,8 +176,8 @@
struct kvec;
extern int sock_wake_async(struct socket *sk, int how, int band);
-extern int sock_register(struct net_proto_family *fam);
-extern int sock_unregister(int family);
+extern int sock_register(const struct net_proto_family *fam);
+extern void sock_unregister(int family);
extern int sock_create(int family, int type, int proto,
struct socket **res);
extern int sock_create_kern(int family, int type, int proto,
--- net-2.6.orig/net/socket.c 2006-08-09 11:19:22.0 -0700
+++ net-2.6/net/socket.c2006-08-09 11:19:24.0 -0700
@@ -147,7 +147,7 @@
*/
static DEFINE_SPINLOCK(net_family_lock);
-static const struct net_proto_family *net_families[NPROTO];
+static const struct net_proto_family *net_families[NPROTO] __read_mostly;
/*
* Statistics counters of the socket lists
@@ -2070,7 +2070,7 @@
* socket interface. The value ops->family coresponds to the
* socket system call protocol family.
*/
-int sock_register(struct net_proto_family *ops)
+int sock_register(const struct net_proto_family *ops)
{
int err;
@@ -2106,10 +2106,9 @@
* a module then it needs to provide its own protection in
* the ops->create routine.
*/
-int sock_unregister(int family)
+void sock_unregister(int family)
{
- if (family < 0 || family >= NPROTO)
- return -EINVAL;
+ BUG_ON(family < 0 || family >= NPROTO);
spin_lock(&net_family_lock);
net_families[family] = NULL;
@@ -2118,7 +2117,6 @@
synchronize_rcu();
printk(KERN_INFO "NET: Unregistered protocol family %d\n", family);
- return 0;
}
static int __init sock_init(void)
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] socket: code style cleanup
Make socket.c conform to current style:
* run through Lindent
* get rid of unneeded casts
* split assignment and comparsion where possible
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- net-2.6.orig/net/socket.c 2006-08-09 10:08:13.0 -0700
+++ net-2.6/net/socket.c2006-08-09 11:19:08.0 -0700
@@ -42,7 +42,7 @@
* Andi Kleen : Some small cleanups, optimizations,
* and fixed a copy_from_user() bug.
* Tigran Aivazian : sys_send(args) calls sys_sendto(args,
NULL, 0)
- * Tigran Aivazian : Made listen(2) backlog sanity checks
+ * Tigran Aivazian : Made listen(2) backlog sanity checks
* protocol-independent
*
*
@@ -53,7 +53,7 @@
*
*
* This module is effectively the top level interface to the BSD socket
- * paradigm.
+ * paradigm.
*
* Based upon Swansea University Computer Society NET3.039
*/
@@ -95,28 +95,27 @@
#include
static int sock_no_open(struct inode *irrelevant, struct file *dontcare);
-static ssize_t sock_aio_read(struct kiocb *iocb, char __user *buf,
-size_t size, loff_t pos);
-static ssize_t sock_aio_write(struct kiocb *iocb, const char __user *buf,
- size_t size, loff_t pos);
-static int sock_mmap(struct file *file, struct vm_area_struct * vma);
+static ssize_t sock_aio_read(struct kiocb *iocb, char __user * buf,
+size_t size, loff_t pos);
+static ssize_t sock_aio_write(struct kiocb *iocb, const char __user * buf,
+ size_t size, loff_t pos);
+static int sock_mmap(struct file *file, struct vm_area_struct *vma);
static int sock_close(struct inode *inode, struct file *file);
static unsigned int sock_poll(struct file *file,
struct poll_table_struct *wait);
-static long sock_ioctl(struct file *file,
- unsigned int cmd, unsigned long arg);
+static long sock_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
#ifdef CONFIG_COMPAT
static long compat_sock_ioctl(struct file *file,
- unsigned int cmd, unsigned long arg);
+ unsigned int cmd, unsigned long arg);
#endif
static int sock_fasync(int fd, struct file *filp, int on);
static ssize_t sock_readv(struct file *file, const struct iovec *vector,
- unsigned long count, loff_t *ppos);
+ unsigned long count, loff_t * ppos);
static ssize_t sock_writev(struct file *file, const struct iovec *vector,
- unsigned long count, loff_t *ppos);
+ unsigned long count, loff_t * ppos);
static ssize_t sock_sendpage(struct file *file, struct page *page,
-int offset, size_t size, loff_t *ppos, int more);
+int offset, size_t size, loff_t * ppos, int more);
/*
* Socket files have a set of 'special' operations as well as the generic
file ones. These don't appear
@@ -193,7 +192,6 @@
#define net_family_read_unlock() do { } while(0)
#endif
-
/*
* Statistics counters of the socket lists
*/
@@ -201,19 +199,20 @@
static DEFINE_PER_CPU(int, sockets_in_use) = 0;
/*
- * Support routines. Move socket addresses back and forth across the
kernel/user
- * divide and look after the messy bits.
+ * Support routines.
+ * Move socket addresses back and forth across the kernel/user
+ * divide and look after the messy bits.
*/
-#define MAX_SOCK_ADDR 128 /* 108 for Unix domain -
+#define MAX_SOCK_ADDR 128 /* 108 for Unix domain -
16 for IP, 16 for IPX,
24 for IPv6,
- about 80 for AX.25
+ about 80 for AX.25
must be at least one bigger than
the AF_UNIX size (see
net/unix/af_unix.c
- :unix_mkname()).
+ :unix_mkname()).
*/
-
+
/**
* move_addr_to_kernel - copy a socket address into kernel space
* @uaddr: Address in user space
@@ -225,13 +224,13 @@
* invalid addresses -EFAULT is returned. On a success 0 is returned.
*/
-int move_addr_to_kernel(void __user *uaddr, int ulen, void *kaddr)
+int move_addr_to_kernel(void __user * uaddr, int ulen, void *kaddr)
{
- if(ulen<0||ulen>MAX_SOCK_ADDR)
+ if (ulen < 0 || ulen > MAX_SOCK_ADDR)
return -EINVAL;
- if(ulen==0)
+ if (ulen == 0)
return 0;
- if(copy_from_user(kaddr,uaddr,ule
[PATCH 4/5] net: socket family using RCU
Replace the gross custom locking done in socket code for net_family[]
with simple RCU usage. Some reordering necessary to avoid sleep
issues with sock_alloc.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/socket.c | 171 +--
1 file changed, 74 insertions(+), 97 deletions(-)
--- net-2.6.orig/net/socket.c 2006-08-09 11:19:08.0 -0700
+++ net-2.6/net/socket.c2006-08-09 11:19:22.0 -0700
@@ -59,11 +59,11 @@
*/
#include
-#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -146,51 +146,8 @@
* The protocol list. Each protocol is registered in here.
*/
-static struct net_proto_family *net_families[NPROTO];
-
-#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
-static atomic_t net_family_lockct = ATOMIC_INIT(0);
static DEFINE_SPINLOCK(net_family_lock);
-
-/* The strategy is: modifications net_family vector are short, do not
- sleep and veeery rare, but read access should be free of any exclusive
- locks.
- */
-
-static void net_family_write_lock(void)
-{
- spin_lock(&net_family_lock);
- while (atomic_read(&net_family_lockct) != 0) {
- spin_unlock(&net_family_lock);
-
- yield();
-
- spin_lock(&net_family_lock);
- }
-}
-
-static __inline__ void net_family_write_unlock(void)
-{
- spin_unlock(&net_family_lock);
-}
-
-static __inline__ void net_family_read_lock(void)
-{
- atomic_inc(&net_family_lockct);
- spin_unlock_wait(&net_family_lock);
-}
-
-static __inline__ void net_family_read_unlock(void)
-{
- atomic_dec(&net_family_lockct);
-}
-
-#else
-#define net_family_write_lock() do { } while(0)
-#define net_family_write_unlock() do { } while(0)
-#define net_family_read_lock() do { } while(0)
-#define net_family_read_unlock() do { } while(0)
-#endif
+static const struct net_proto_family *net_families[NPROTO];
/*
* Statistics counters of the socket lists
@@ -1131,6 +1088,7 @@
{
int err;
struct socket *sock;
+ const struct net_proto_family *pf;
/*
* Check protocol is in range
@@ -1159,6 +1117,20 @@
if (err)
return err;
+ /*
+* Allocate the socket and allow the family to set things up. if
+* the protocol is 0, the family is instructed to select an
appropriate
+* default.
+*/
+ sock = sock_alloc();
+ if (!sock) {
+ printk(KERN_WARNING "socket: no more sockets\n");
+ return -ENFILE; /* Not exactly a match, but its the
+ closest posix thing */
+ }
+
+ sock->type = type;
+
#if defined(CONFIG_KMOD)
/* Attempt to load a protocol module if the find failed.
*
@@ -1166,70 +1138,59 @@
* requested real, full-featured networking support upon configuration.
* Otherwise module support will break!
*/
- if (net_families[family] == NULL) {
+ if (net_families[family] == NULL)
request_module("net-pf-%d", family);
- }
#endif
- net_family_read_lock();
- if (net_families[family] == NULL) {
- err = -EAFNOSUPPORT;
- goto out;
- }
-
-/*
- * Allocate the socket and allow the family to set things up. if
- * the protocol is 0, the family is instructed to select an appropriate
- * default.
- */
-
- if (!(sock = sock_alloc())) {
- printk(KERN_WARNING "socket: no more sockets\n");
- err = -ENFILE; /* Not exactly a match, but its the
- closest posix thing */
- goto out;
- }
-
- sock->type = type;
+ rcu_read_lock();
+ pf = rcu_dereference(net_families[family]);
+ err = -EAFNOSUPPORT;
+ if (!pf)
+ goto out_release;
/*
* We will call the ->create function, that possibly is in a loadable
* module, so we have to bump that loadable module refcnt first.
*/
- err = -EAFNOSUPPORT;
- if (!try_module_get(net_families[family]->owner))
+ if (!try_module_get(pf->owner))
goto out_release;
- if ((err = net_families[family]->create(sock, protocol)) < 0) {
- sock->ops = NULL;
+ /* Now protected by module ref count */
+ rcu_read_unlock();
+
+ err = pf->create(sock, protocol);
+ if (err < 0)
goto out_module_put;
- }
/*
* Now to bump the refcnt of the [loadable] module that owns this
* socket at sock_release time we decrement its refcnt.
*/
- if (!try_module_get(sock->ops->owner)) {
- err = -EAGAIN;
- sock->ops = NULL;
- goto out_module_put;
- }
+ if (!try_module_get(sock->ops->owner))
+ goto out_mod
[PATCH 1/5] sock_create bad error return
If socket create call races with module unload, it correctly
fails the socket call but doesn't return an error. This race
is theoritical because the sock->ops are always the same and
non-modular.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- tcp-2.6.orig/net/socket.c
+++ tcp-2.6/net/socket.c
@@ -1204,6 +1204,7 @@ static int __sock_create(int family, int
* socket at sock_release time we decrement its refcnt.
*/
if (!try_module_get(sock->ops->owner)) {
+ err = -EAGAIN;
sock->ops = NULL;
goto out_module_put;
}
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] net socket family patches
These patches cleanup the net socket family interface and convert it to RCU. This is new stuff that should go into 2.6.19 (if it is ready). Andrew could you put it in -mm as well? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] net: drop unused elements from net_proto_family
Three values in net_proto_family are defined but never used.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- net-2.6.orig/include/linux/net.h2006-08-09 11:14:51.0 -0700
+++ net-2.6/include/linux/net.h 2006-08-09 11:19:19.0 -0700
@@ -169,11 +169,6 @@
struct net_proto_family {
int family;
int (*create)(struct socket *sock, int protocol);
- /* These are counters for the number of different methods of
- each we support */
- short authentication;
- short encryption;
- short encrypt_net;
struct module *owner;
};
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Excess use of packed attribute
David> For the cases where it is no actually necessary, the code
David> generation cost on RISC cpus is very high. Byte loads and
David> stores will be used to access _every_ member of such
David> structures on RISC machines because the compiler cannot
David> guarentee the alignment of any data object when packed is
David> specified.
Agreed (although not really RISC -- sparc64 and ia64 have this
problem, while ppc is fine with unaligned access). However
__attribute__((packed,aligned)) has just been brought to my attention.
For example, on sparc64,
struct foo { char x; int a; } __attribute__((packed,aligned));
struct bar { char x; int b; } __attribute__((packed));
int c(struct foo *x) { return x->a; }
int d(struct bar *x) { return x->b; }
compiles to:
:
0: d0 5a 00 00 ldx [ %o0 ], %o0
4: 91 2a 30 08 sllx %o0, 8, %o0
8: 81 c3 e0 08 retl
c: 91 3a 30 20 srax %o0, 0x20, %o0
10: 30 68 00 04 b,a %xcc, 20
14: 01 00 00 00 nop
18: 01 00 00 00 nop
1c: 01 00 00 00 nop
0020 :
20: c6 0a 20 01 ldub [ %o0 + 1 ], %g3
24: c2 0a 20 02 ldub [ %o0 + 2 ], %g1
28: c4 0a 20 03 ldub [ %o0 + 3 ], %g2
2c: 87 28 f0 18 sllx %g3, 0x18, %g3
30: d0 0a 20 04 ldub [ %o0 + 4 ], %o0
34: 83 28 70 10 sllx %g1, 0x10, %g1
38: 82 10 40 03 or %g1, %g3, %g1
3c: 85 28 b0 08 sllx %g2, 8, %g2
40: 84 10 80 01 or %g2, %g1, %g2
44: 90 12 00 02 or %o0, %g2, %o0
48: 81 c3 e0 08 retl
4c: 91 3a 20 00 sra %o0, 0, %o0
50: 30 68 00 04 b,a %xcc, 60
54: 01 00 00 00 nop
58: 01 00 00 00 nop
5c: 01 00 00 00 nop
which suggests that adding "aligned" is a good idea for many of the
uses of "packed". However I don't know how all gcc version do with
this. Anyone have any comments on "__attribute__((packed,aligned))"?
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
On Wed, August 9, 2006 16:00, Peter Zijlstra said: > On Wed, 2006-08-09 at 15:48 +0200, Indan Zupancic wrote: >> On Wed, August 9, 2006 14:54, Peter Zijlstra said: >> > On Wed, 2006-08-09 at 14:02 +0200, Indan Zupancic wrote: >> >> That avoids lots of checks and should guarantee that the >> >> accounting is correct, except in the case when the IFF_MEMALLOC flag is >> >> cleared and the counter is set to zero manually. Can't that be avoided and >> >> just let it decrease to zero naturally? >> > >> > That would put the atomic op on the free path unconditionally, I think >> > davem gets nightmares from that. >> >> I confused SOCK_MEMALLOC with sk_buff::memalloc, sorry. What I meant was >> to unconditionally decrement the reserved usage only when memalloc is true >> on the free path. That way all skbs that increased the reserve also decrease >> it, and the counter should never go below zero. > > OK, so far so good, except we loose the notion of getting memory back > from regular skbs. I don't understand this, regular skbs don't have anything to do with rx_reserve_used as far as I can see. I'm only talking about keeping that field up to date and correct. rx_reserve_used is only increased by a skb when memalloc is set to true on that skb, so only if that field is set rx_reserve_used needs to be reduced when the skb is freed. Why is it needed for the protocol specific code to call dev_unreserve_skb? Only problem is if the device can change. rx_reserve_used should probably be updated when that happens, as a skb can't use reserved memory on a device it was moved away from. (right?) >> Also as far as I can see it should be possible to replace all atomic >> "if (unlikely(dev_reserve_used(skb->dev)))" checks witha check if >> memalloc is set. That should make davem happy, as there aren't any >> atomic instructions left in hot paths. > > dev_reserve_used() uses atomic_read() which isn't actually a LOCK'ed > instruction, so that should not matter. Perhaps, but the main reason to check memalloc instead of using dev_reserve_used is because the latter doesn't tell which skb did the reservation. >> If IFF_MEMALLOC is set new skbs set memalloc and increase the reserve. > > Not quite, if IFF_MEMALLOC is set new skbs _could_ get memalloc set. We > only fall back to alloc_pages() if the regular path fails to alloc. If the > skb is backed by a page (as opposed to kmem_cache fluff) sk_buff::memalloc > is set. Yes, true. But doesn't matter for the rx_reserve_used accounting, as long as memalloc set means that it did increase rx_reserve_used. > Also, I've been thinking (more pain), should I not up the reserve for > each SOCK_MEMALLOC socket. Up rx_reserve_used or the total ammount of reserved memory? Probably 'no' for both though, as it's either device specific or skb dependent. I'm slowly getting a clearer image of the big picture, I'll take another look when you post the updated code. Greetings, Indan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take6 1/3] kevent: Core files.
On Wed, 9 Aug 2006 12:02:40 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> Core files.
>
> This patch includes core kevent files:
> - userspace controlling
> - kernelspace interfaces
> - initialization
> - notification state machines
>
> It might also inlclude parts from other subsystem (like network related
> syscalls, so it is possible that it will not compile without other
> patches applied).
>
> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
>
>
> +#ifdef CONFIG_KEVENT_USER_STAT
> +static inline void kevent_user_stat_init(struct kevent_user *u)
> +{
> + u->wait_num = u->im_num = u->total = 0;
> +}
> +static inline void kevent_user_stat_print(struct kevent_user *u)
> +{
> + pr_debug("%s: u=%p, wait=%lu, immediately=%lu, total=%lu.\n",
> + __func__, u, u->wait_num, u->im_num, u->total);
> +}
> +static inline void kevent_user_stat_increase_im(struct kevent_user *u)
> +{
> + u->im_num++;
> +}
> +static inline void kevent_user_stat_increase_wait(struct kevent_user *u)
> +{
> + u->wait_num++;
> +}
> +static inline void kevent_user_stat_increase_total(struct kevent_user *u)
> +{
> + u->total++;
> +}
>
static wrapper_functions_with_execessive_long_names(struct i_really_hate *this)
{
suck();
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 2/2] update sunrpc to use in-kernel sockets API
On Tue, 2006-08-08 at 23:16 -0400, Trond Myklebust wrote:
> On Tue, 2006-08-08 at 17:09 -0700, David Miller wrote:
>
> > Trond, I think the highmem check in xs_sendpages() is completely
> > bogus, do you mind if we remove it? :-)
> >
> > The socket layer will properly check the device to make sure it
> > can handle highmem pages, and if not it will copy the data into
> > a low-mem page as-needed.
>
> If the special case is no longer useful, then I for one am quite happy
> to get rid of it.
OK. Here is a patch that does it.
[SUNRPC]: Remove the unnecessary check for highmem in xs_sendpages()
and call kernel_sendpage() directly.
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -174,7 +174,6 @@ static inline int xs_sendpages(struct so
struct page **ppage = xdr->pages;
unsigned int len, pglen = xdr->page_len;
int err, ret = 0;
- ssize_t (*sendpage)(struct socket *, struct page *, int, size_t, int);
if (unlikely(!sock))
return -ENOTCONN;
@@ -207,7 +206,6 @@ static inline int xs_sendpages(struct so
base &= ~PAGE_CACHE_MASK;
}
- sendpage = kernel_sendpage;
do {
int flags = XS_SENDMSG_FLAGS;
@@ -220,10 +218,7 @@ static inline int xs_sendpages(struct so
if (pglen != len || xdr->tail[0].iov_len != 0)
flags |= MSG_MORE;
- /* Hmm... We might be dealing with highmem pages */
- if (PageHighMem(*ppage))
- sendpage = sock_no_sendpage;
- err = sendpage(sock, *ppage, base, len, flags);
+ err = kernel_sendpage(sock, *ppage, base, len, flags);
if (ret == 0)
ret = err;
else if (err > 0)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rules and groups
Steven Whitehouse wrote: Hi, On Wed, Aug 09, 2006 at 01:01:25AM -0700, David Miller wrote: From: Steven Whitehouse <[EMAIL PROTECTED]> Date: Wed, 9 Aug 2006 09:01:39 +0100 Is there anything to stop me using RTNLGRP_NOP3 for that? (suitable renamed of course!) So far as I can see its never been assigned to anything else... I have no objection to you using it. Excellent. Please find attached my attempt at doing the conversion to the generic rules code. It appears to work ok for me. You can also pull this patch from the decnet git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/steve/decnet-2.6.19.git which was cloned from net-2.6.19.git quite recently. In addition the git tree has another patch which is in a following email. Patrick: does this patch get your blessing? Yes, that works fine for me. -- patrick - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report for MV643XX driver
Time is not an issue, I'm filing this after some drawn out testing. It won't be right away that I get it built under 3.3 either. Thanks again, -Stuart On Aug 9, 2006, at 1:18 PM, Dale Farnsworth wrote: On Wed, Aug 09, 2006 at 12:53:27PM -0400, Stuart Peloquin wrote: Hi Dale, Thank you for responding quickly. This is with gcc 4.1.1 and the config file has been added to the web directory at http://web.mit.edu/peloquin/marvell/ Please let me know if I can provide anything else. Can you test with an earlier version of the toolchain? Maybe gcc-3.3? Just this week I rebuilt a kernel for one of my Debian x86 server boxes with gcc-4.1, and the tulip driver died early on. When I rebuilt with gcc-3.3, all was well. I haven't had time to look for the details yet. I'm not saying that gcc-4.1 is buggy, but this will help us narrow it down. BTW, I'm up against a deadline on another project, so I won't be able to devote a lot of time to this today. Thanks, -Dale - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report for MV643XX driver
Sorry, the revised URL is http://web.mit.edu/peloquin/www/marvell/ On Wednesday 09 August 2006 10:47, Stuart Peloquin wrote: > Kernel oops during heavy load downloads with the MV643XX driver on a PegII. > I've replicated the problem on 2.6.17_gentoo-4, vanilla 2.6.17.1, vanilla > 2.6.18_rc3. When downloading a large file from any fast mirror (I tested > getting around 2.0MB/s) the system crashes after a random amount of time. > Usually after 30seconds to a couple of minutes. > > I took pictures of the call trace, I'm sorry about the quality, they were > taken with a phone camera. They can be viewed at > http://web.mit.edu/peloquin/marvell > > Thanks, > -Stuart - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
On Wed, Aug 09, 2006 at 09:47:15AM -0700, Michael Wu wrote: > probe response handling to complete the picture. What other half-fullmac, > half-softmac card besides the other IPW cards splits card/host 802.11 duties > along those lines? What other splits between card and host are out there? I > would be very reluctant to make changes to the 802.11 stack to support > "fullmac" without evidence that other drivers need the change. You need to support ipw2[12]00 anyway. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report for MV643XX driver
On Wed, Aug 09, 2006 at 12:53:27PM -0400, Stuart Peloquin wrote: > Hi Dale, > > Thank you for responding quickly. > > This is with gcc 4.1.1 and the config file has been added to the web > directory at http://web.mit.edu/peloquin/marvell/ > > Please let me know if I can provide anything else. Can you test with an earlier version of the toolchain? Maybe gcc-3.3? Just this week I rebuilt a kernel for one of my Debian x86 server boxes with gcc-4.1, and the tulip driver died early on. When I rebuilt with gcc-3.3, all was well. I haven't had time to look for the details yet. I'm not saying that gcc-4.1 is buggy, but this will help us narrow it down. BTW, I'm up against a deadline on another project, so I won't be able to devote a lot of time to this today. Thanks, -Dale - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report for MV643XX driver
Hi Dale, Thank you for responding quickly. This is with gcc 4.1.1 and the config file has been added to the web directory at http://web.mit.edu/peloquin/marvell/ Please let me know if I can provide anything else. Thanks, -Stuart On Aug 9, 2006, at 12:24 PM, Dale Farnsworth wrote: On Wed, Aug 09, 2006 at 10:47:28AM -0400, Stuart Peloquin wrote: Kernel oops during heavy load downloads with the MV643XX driver on a PegII. I've replicated the problem on 2.6.17_gentoo-4, vanilla 2.6.17.1, vanilla 2.6.18_rc3. When downloading a large file from any fast mirror (I tested getting around 2.0MB/s) the system crashes after a random amount of time. Usually after 30seconds to a couple of minutes. I took pictures of the call trace, I'm sorry about the quality, they were taken with a phone camera. They can be viewed at http://web.mit.edu/peloquin/marvell Thanks for the report Stuart. I'm investigating this now. Would you mind sending me the config file used to build the kernel? Also, which version of gcc are you using? Thanks, -Dale - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
On Wednesday 09 August 2006 00:57, Johannes Berg wrote: > Please not, for now. We need someone pushing for fullmac features in > d80211, we need those anyway for embedded systems that can't afford > running all of it on the main CPU. While obviously Intel would benefit > from doing this since a lot more d80211 features would come available, > the greater good would be having a main-stream card that someone cares > about and helps making d80211 full-mac capable. > It's not that hard to generate probe, authentication, and association frames, and it isn't done frequently enough to stress any embedded system that can run linux. Doing this would let 3945 take advantage of all the d80211 features, so why not? What level of fullmac support are we talking about? True fullmac cards (as I define them) do not need to use d80211. WE19 is all they need, to add WPA/WPA2 support. The IPW cards have a particularly unique split between firmware and host 802.11 duties which I haven't seen in any other cards. They aren't quite fullmac enough to interface with WE directly, yet they only need probe response handling to complete the picture. What other half-fullmac, half-softmac card besides the other IPW cards splits card/host 802.11 duties along those lines? What other splits between card and host are out there? I would be very reluctant to make changes to the 802.11 stack to support "fullmac" without evidence that other drivers need the change. -Michael Wu pgpMi8P3W8Lb5.pgp Description: PGP signature
Re: [PATCH] limit rt cache size
> > There will be some hickup, but as long as the downtime > > is limited it shouldn't be too bad. > > > > Benchmarks are in order One issue I forgot earlier and Kirill pointed out is that the reallocation would require vmalloc because memory will be too fragmented to get a big piece of physical memory. So it would add TLB pressure. Can't think of a good way around that. You might have been right with being sceptical. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] ehea: Kernel build (Kconfig / Makefile)
On Wed, Aug 09, 2006 at 10:40:50AM +0200, Jan-Bernd Themann wrote: > Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]> > > > drivers/net/Kconfig |6 ++ > drivers/net/Makefile |1 + > 2 files changed, 7 insertions(+) > > > > diff -Nurp -X dontdiff linux-2.6.18-rc4/drivers/net/Kconfig > patched_kernel/drivers/net/Kconfig > --- linux-2.6.18-rc4/drivers/net/Kconfig 2006-08-06 11:20:11.0 > -0700 > +++ patched_kernel/drivers/net/Kconfig2006-08-08 03:00:49.526421944 > -0700 > @@ -2277,6 +2277,12 @@ config CHELSIO_T1 > To compile this driver as a module, choose M here: the module > will be called cxgb. > > +config EHEA > +tristate "eHEA Ethernet support" > +depends on IBMEBUS > +---help--- > + This driver supports the IBM pSeries ethernet adapter Does this adapter really not have a better name for the option description? That's a very vague description given that IBM pSeries machines have had all sorts of ethernet adapters through the years. -Olof - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] limit rt cache size
On Wed, 9 Aug 2006, Andi Kleen wrote: But there's alot of state to update (more or less atomically, too) Why does it need to be atomic? It might be enough to just check a flag and poll for it in the readers and then redo the lookup. (I qualified "atomic" with "more or less" :-) Sure, something like that could work. There will be some hickup, but as long as the downtime is limited it shouldn't be too bad. Benchmarks are in order -- Arthur - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report for MV643XX driver
On Wed, Aug 09, 2006 at 10:47:28AM -0400, Stuart Peloquin wrote: > Kernel oops during heavy load downloads with the MV643XX driver on a PegII. > I've replicated the problem on 2.6.17_gentoo-4, vanilla 2.6.17.1, vanilla > 2.6.18_rc3. When downloading a large file from any fast mirror (I tested > getting around 2.0MB/s) the system crashes after a random amount of time. > Usually after 30seconds to a couple of minutes. > > I took pictures of the call trace, I'm sorry about the quality, they were > taken with a phone camera. They can be viewed at > http://web.mit.edu/peloquin/marvell Thanks for the report Stuart. I'm investigating this now. Would you mind sending me the config file used to build the kernel? Also, which version of gcc are you using? Thanks, -Dale - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
On Wed, 2006-08-09 at 18:18 +0200, Thomas Graf wrote: > * Peter Zijlstra <[EMAIL PROTECTED]> 2006-08-09 16:07 > > I think Daniel was thinking of adding struct net_device * > > sk_buff::alloc_dev, > > I know I was after reading the first few mails. However if adding a > > field > > there is strict no-no > > > > /me takes a look at struct sk_buff > > > > Hmm, what does sk_buff::input_dev do? That seems to store the initial > > device? > > No, skb->input_dev is used when redirecting packets around in the > stack and may change. Even if it would keep its value the reference > to the netdevice is not valid anymore when you free the skb as the > skb was queued and the refcnt acquired in __netifx_rx_schedule() > has been released again thus making it possible for the netdevice > to disappear. Bah, tricky stuff that. disregards this part from -v2 then :-( - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/9] deadlock prevention core
* Peter Zijlstra <[EMAIL PROTECTED]> 2006-08-09 16:07 > I think Daniel was thinking of adding struct net_device * > sk_buff::alloc_dev, > I know I was after reading the first few mails. However if adding a > field > there is strict no-no > > /me takes a look at struct sk_buff > > Hmm, what does sk_buff::input_dev do? That seems to store the initial > device? No, skb->input_dev is used when redirecting packets around in the stack and may change. Even if it would keep its value the reference to the netdevice is not valid anymore when you free the skb as the skb was queued and the refcnt acquired in __netifx_rx_schedule() has been released again thus making it possible for the netdevice to disappear. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pcnet32: break in 2.6.18-rc1 identified (corrected)
Don Fry wrote: When I have some positive results, I will add the signed-off-by line and resubmit the patch or ask for the old patch to be removed. When does the patch need to be submitted in order to be included in 2.6.18? A couple weeks, Linus posted that he won't be back until towards the end of August. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
-v2 [RFC][PATCH 2/9] deadlock prevention core
The core of the VM deadlock avoidance framework.
>From the 'user' side of things it provides a function to mark a 'struct sock'
as SOCK_MEMALLOC, meaning this socket may dip into the memalloc reserves on
the receive side.
>From the net_device side of things, the extra 'struct net_device *' argument
to {,__}netdev_alloc_skb() is used to attribute/account the memalloc usage.
When netdev_alloc_skb() finds it cannot allocate a struct sk_buff the regular
way it will grab some memory from the memalloc reserve.
Drivers that have been converted to the netdev_alloc_skb() family will
automatically receive this feature.
Network paths will drop !SOCK_MEMALLOC packets ASAP when reserve is being used.
Memalloc sk_buff allocations are not done from the SLAB but are done using
alloc_pages(). sk_buff::memalloc records this exception so that kfree_skbmem()
can do the right thing. NOTE this does not play very nice with skb_clone()
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Daniel Phillips <[EMAIL PROTECTED]>
---
include/linux/gfp.h |3 -
include/linux/mmzone.h|1
include/linux/netdevice.h | 41 +++-
include/linux/skbuff.h|3 -
include/net/sock.h|8 +++
mm/page_alloc.c | 38 ++-
net/core/dev.c| 40
net/core/skbuff.c | 112 +++---
net/core/sock.c | 18 +++
net/ethernet/eth.c|1
net/ipv4/af_inet.c|4 +
net/ipv4/icmp.c |3 +
net/ipv4/tcp_ipv4.c |3 +
net/ipv4/udp.c|8 ++-
14 files changed, 258 insertions(+), 25 deletions(-)
Index: linux-2.6/include/linux/gfp.h
===
--- linux-2.6.orig/include/linux/gfp.h
+++ linux-2.6/include/linux/gfp.h
@@ -46,6 +46,7 @@ struct vm_area_struct;
#define __GFP_ZERO ((__force gfp_t)0x8000u)/* Return zeroed page on
success */
#define __GFP_NOMEMALLOC ((__force gfp_t)0x1u) /* Don't use emergency
reserves */
#define __GFP_HARDWALL ((__force gfp_t)0x2u) /* Enforce hardwall cpuset
memory allocs */
+#define __GFP_MEMALLOC ((__force gfp_t)0x4u) /* Use emergency reserves */
#define __GFP_BITS_SHIFT 20/* Room for 20 __GFP_FOO bits */
#define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))
@@ -54,7 +55,7 @@ struct vm_area_struct;
#define GFP_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS| \
__GFP_COLD|__GFP_NOWARN|__GFP_REPEAT| \
__GFP_NOFAIL|__GFP_NORETRY|__GFP_NO_GROW|__GFP_COMP| \
- __GFP_NOMEMALLOC|__GFP_HARDWALL)
+ __GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_MEMALLOC)
/* This equals 0, but use constants in case they ever change */
#define GFP_NOWAIT (GFP_ATOMIC & ~__GFP_HIGH)
Index: linux-2.6/include/linux/mmzone.h
===
--- linux-2.6.orig/include/linux/mmzone.h
+++ linux-2.6/include/linux/mmzone.h
@@ -420,6 +420,7 @@ int percpu_pagelist_fraction_sysctl_hand
void __user *, size_t *, loff_t *);
int sysctl_min_unmapped_ratio_sysctl_handler(struct ctl_table *, int,
struct file *, void __user *, size_t *, loff_t *);
+int adjust_memalloc_reserve(int bytes);
#include
/* Returns the number of the current Node. */
Index: linux-2.6/include/linux/netdevice.h
===
--- linux-2.6.orig/include/linux/netdevice.h
+++ linux-2.6/include/linux/netdevice.h
@@ -298,18 +298,20 @@ struct net_device
/* Net device features */
unsigned long features;
-#define NETIF_F_SG 1 /* Scatter/gather IO. */
-#define NETIF_F_IP_CSUM2 /* Can checksum only TCP/UDP
over IPv4. */
-#define NETIF_F_NO_CSUM4 /* Does not require checksum.
F.e. loopack. */
-#define NETIF_F_HW_CSUM8 /* Can checksum all the
packets. */
-#define NETIF_F_HIGHDMA32 /* Can DMA to high memory. */
-#define NETIF_F_FRAGLIST 64 /* Scatter/gather IO. */
-#define NETIF_F_HW_VLAN_TX 128 /* Transmit VLAN hw acceleration */
-#define NETIF_F_HW_VLAN_RX 256 /* Receive VLAN hw acceleration */
-#define NETIF_F_HW_VLAN_FILTER 512 /* Receive filtering on VLAN */
-#define NETIF_F_VLAN_CHALLENGED1024/* Device cannot handle VLAN
packets */
-#define NETIF_F_GSO2048/* Enable software GSO. */
-#define NETIF_F_LLTX 4096/* LockLess TX */
+#define NETIF_F_SG 0x0001 /* Scatter/gather IO. */
+#define NETIF_F_IP_CSUM0x0002 /* Can checksum only TCP/UDP
over IPv4. */
+#define NETIF_F_NO_CSUM0x0004 /* Does not require checksum.
F.e. loopack. */
+#define NETIF_F_HW_CSUM
Re: 3945 driver using d80211
On Tue, Aug 08, 2006 at 02:27:37PM -0700, Mohamed Abbas wrote: > 1- I needed to use sta_info_get function to do rate scaling for 3945, > although this function is exported but it was missing from d80211.h, for > work around I had to copy more header files to my driver's directory, It > this plan to add this function to d80211.h ? sta_info_get() (and well, any access to struct sta_info) was not designed to be available for the rate control modules. Could you please provide some more details on what kind of information you would need from there? > 2- Scanning; in 3945 driver, we can not tune to other channels while we > are connected, this will cause a firmware error. The firmware provides a > scanning command we call so the firmware will take care of switching of > the available channels and gather beacons and probe responses. The > current d80211 the stack will call config callback to switch to > different channel and send the probe requests. One of our engineers did > come up with a patch to add one more callback function if provided the > d80211 will call this function to allow the registered driver to perform > the scanning functionalities. For work around I currently check inside > config callback if the scanning flag set I will issues the scan command > then ignore the next config callback. If the hardware/firmware has such limitation, providing an alternative mechanism for this is indeed needed. However, I though 3945 did not have much firmware on it and I was not expecting this kind of requirement from it (though, I have to admit that I'm not at all familiar with the details of its design). Anyway, there are other wireless cards that will need similar mechanism, so this is needed to support more "full mac" type designs. > 3- I can not access beacon's info from current associated AP. > information I need to callback into the firmware like timestamp and aid, > work around I would parse incoming management frame and filter beacon > from associated AP to get this info. This is a duplicate code that > d80211 stack doing, maybe there is away to get these info that I don’t > know of. Also it will be nice to have some callback function on > association, disassociation. What kind of information/events do you need in the low-level hardware driver? It sounds reasonable to add this kind of event callbacks. > 4- I am been using the driver for sometime right now and it seems to be > stable and liable although I am using SMP system. I hearted of some SMP > issues in d80211 and I have the machine and time to help in this. Do you > have any test script the cause this SMP problems? Or steps to reproduce it. I have heard of open claims on there being SMP issues, but I don't think I've ever seen any details on this. I've also added a dual core laptop to my testbed, so it will be interesting to see whether I can trigger any of the issues easily. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
On Tue, Aug 08, 2006 at 05:06:31PM -0700, Jouni Malinen wrote: > On Tue, Aug 08, 2006 at 02:27:37PM -0700, Mohamed Abbas wrote: > > > 1- I needed to use sta_info_get function to do rate scaling for 3945, > > although this function is exported but it was missing from d80211.h, for > > work around I had to copy more header files to my driver's directory, It > > this plan to add this function to d80211.h ? > > sta_info_get() (and well, any access to struct sta_info) was not > designed to be available for the rate control modules. Could you please > provide some more details on what kind of information you would need > from there? Actually, that was not correct.. What I should have said is that sta_info was not supposed to be available for low-level drivers. If the rate control algorithm is tightly coupled with the driver, some cleanup would likely be needed here. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pcnet32: break in 2.6.18-rc1 identified (corrected)
On Wed, Aug 09, 2006 at 12:01:34AM -0400, Jeff Garzik wrote: > Don Fry wrote: > >I noticed this morning that I had the polarity wrong in my patch > >yesterday for older chips in the pcnet32_suspend routine. Here is the > >correct patch to test. > > > >>A change I made for 2.6.17 and another for 2.6.18 do not work on older > >>pcnet32 chips which I do not have access to. Please test this patch if > >>you have access to a 79C970, 79C974, or 79C965 (VLB) version of the > >>pcnet32 and let me know if it solves any problems. I have tested with a > >>79C970A, 79C971, 79C972, 79C973, 79C975, 79C976, and 79C978 and the > >>changes work as expected. > > Did testing succeed? > I have not heard anything about testing results yet. I have tested successfully with the hardware I have, but there are at least three variants of the chip that I have not been able to find. "It should work" are the famous last words of most programmers ;-(. I received an email from Martin on Saturday that he had been traveling and would get back to me. I believe that the patch will resolve the issue with older cards. The patch is no worse than what is in 2.6.18-rc4 today, but removing the offending patch is also an option. The patch also addresses an issue raised by Yuri Strelenko that the changes in 2.6.17 caused his 79C970 to stop working. I have sent him a patch as well, but have heard nothing from him. Those changes I am much more positive about, but I would like confirmation that I have not broken something else. When I have some positive results, I will add the signed-off-by line and resubmit the patch or ask for the old patch to be removed. When does the patch need to be submitted in order to be included in 2.6.18? > signed-off-by? > > Jeff -- Don Fry [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] d80211/bcm43xx: Modify ieee80211_ioctl.c for wireless statistics.
Dan Williams wrote:
On Tue, 2006-08-08 at 19:00 -0500, Larry Finger wrote:
Part 8 of 8 to add wireless statistics to the bcm43xx-d80211 system.
This patch adds the appropriate range parameters and routine
ieee80211_get_wireless_stats to ieee80211_ioctl.c.
The patch is for the August 8 version of Linville's wireless-dev tree.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index dd52555..3a1b97f 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -1525,6 +1525,16 @@ static int ieee80211_ioctl_giwrange(stru
range->min_frag = 256;
range->max_frag = 2346;
+ range->max_qual.qual = 100;
+ range->max_qual.level = 152; /* set floor at -104 dBm (152 - 256) */
+ range->max_qual.noise = 152;
+ range->max_qual.updated = IW_QUAL_ALL_UPDATED;
+
+ range->avg_qual.qual = 50;
+ range->avg_qual.level = 0;
+ range->avg_qual.noise = 0;
+ range->avg_qual.updated = IW_QUAL_ALL_UPDATED;
+
return 0;
}
@@ -2963,6 +2973,39 @@ static int ieee80211_ioctl_giwauth(struc
return ret;
}
+/* Get wireless statistics. Called by /proc/net/wireless and by SIOCGIWSTATS
*/
+static struct iw_statistics *ieee80211_get_wireless_stats(struct net_device
*net_dev)
+{
+ struct ieee80211_local *local = net_dev->ieee80211_ptr;
+ struct iw_statistics * wstats = &local->wstats;
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(net_dev);
+ struct sta_info *sta;
+ static int tmp_level = 0;
+ static int tmp_qual = 0;
+
+ sta = sta_info_get(local, sdata->u.wds.remote_addr);
+ if (!sta) {
+ wstats->discard.fragment = 0;
+ wstats->discard.misc = 0;
+ wstats->qual.qual = 0;
+ wstats->qual.level = 0;
+ wstats->qual.noise = 0;
+ wstats->qual.updated |= IW_QUAL_ALL_UPDATED;
What does the 'if (!sta)' check do? What's the case here? If the card
is not connected an access point or otherwise unconnected to anything
else, you should use IW_QUAL_ALL_INVALID here I think, because signal
quality has no meaning when you're disconnected (except possibly
background noise).
The check is mostly to prevent NULL pointers in the else branch, but your
suggestion of INVALID is good.
+ } else {
+ if (!tmp_level) { /* get initial values */
+ tmp_level = sta->last_signal;
+ tmp_qual = sta->last_rssi;
+ } else {/* smooth results */
+ tmp_level = (15 * tmp_level + sta->last_signal)/16;
+ tmp_qual = (15 * tmp_qual + sta->last_rssi)/16;
+ }
+ wstats->qual.level = tmp_level;
+ wstats->qual.qual = 100*tmp_qual/sta->max_rssi;
+ wstats->qual.noise = sta->last_noise;
+ wstats->qual.updated = IW_QUAL_ALL_UPDATED | IW_QUAL_DBM;
By using IW_QUAL_DBM, you're forcing all cards that use d80211 to report
statistics in dBm. I think that's a _good_ thing personally (it brings
some consistency to the whole wireless quality pit-of-doom), but I want
to make sure this is actually what you want to do here.
From what I learned in our previous discussions, that is exactly what I meant.
Thanks for your comments.
Larry
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] d80211/bcm43xx: Modify struct ieee80211_rx_status for wireless statistics.
Dan Williams wrote:
On Tue, 2006-08-08 at 18:58 -0500, Larry Finger wrote:
diff --git a/include/net/d80211.h b/include/net/d80211.h
index ba5cb4c..8479b58 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -205,6 +205,9 @@ struct ieee80211_rx_status {
int channel;
int phymode;
int ssi;
+ int maxssi;
+ int signal;
+ int noise;
Spacing? Looks like you're using real tabs here, but the current code
uses 8 spaces instead. Not sure if that's a problem.
I am using tabs, which I think is the preferred way. I also remember that the
rule is not to change the white space on things you are not touching. Is that
correct?
Larry
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3: tg3_stop_block timed out
On Tuesday 08 August 2006 01:46, Michael Chan wrote: > On Tue, 2006-08-08 at 01:24 +0200, Bernd Schubert wrote: > > tg3.c:v3.49 (Feb 2, 2006) > > acpi_bus-0201 [01] bus_set_power : Device is not power manageable > > eth1: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) > > 10/100/1000BaseT Ethernet 00:e0:81:2b:aa:28 eth1: RXcsums[1] > > LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] eth1: > > dma_rwctrl[769f4000] dma_mask[64-bit] > > eth2: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) > > 10/100/1000BaseT Ethernet 00:e0:81:2b:aa:29 eth2: RXcsums[1] > > LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] eth2: > > dma_rwctrl[769f4000] dma_mask[64-bit] > > You have ASF enabled on eth1 but not on eth2 so I wonder if ASF is > causing the problem. Can you run the same traffic on eth2 and see if > you get the same timeout problem? Thanks. Currently I have no physical access to the system and eth2 is not connected to our switch. I will connect it and run a test as soon as possible (sometime this week). However, I don't think I can easily reproduce it even with eth1. Its the first time I noticed those error messages in seven months. However, we are experiencing random crashes of the system and maybe thats the cause of it, who knows. The system is running its root file system over nfs, so a network failure will lockup the entire system. Thanks, Bernd - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Change some sysctl variables to __read_mostly
Change net/core, ipv4 and ipv6 sysctl variables to __read_mostly.
Couldn't actually measure any performance increase while testing (.3% I
consider noise), but seems like the right thing to do.
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index d273cad..e3d8d9b 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -2449,7 +2449,7 @@ static struct neigh_sysctl_table {
ctl_table neigh_neigh_dir[2];
ctl_table neigh_proto_dir[2];
ctl_table neigh_root_dir[2];
-} neigh_sysctl_template = {
+} neigh_sysctl_template __read_mostly = {
.neigh_vars = {
{
.ctl_name = NET_NEIGH_MCAST_SOLICIT,
diff --git a/net/core/sock.c b/net/core/sock.c
index b67d868..cfaf090 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -187,13 +187,13 @@ static struct lock_class_key af_callback
#define SK_RMEM_MAX (_SK_MEM_OVERHEAD * _SK_MEM_PACKETS)
/* Run time adjustable parameters. */
-__u32 sysctl_wmem_max = SK_WMEM_MAX;
-__u32 sysctl_rmem_max = SK_RMEM_MAX;
-__u32 sysctl_wmem_default = SK_WMEM_MAX;
-__u32 sysctl_rmem_default = SK_RMEM_MAX;
+__u32 sysctl_wmem_max __read_mostly = SK_WMEM_MAX;
+__u32 sysctl_rmem_max __read_mostly = SK_RMEM_MAX;
+__u32 sysctl_wmem_default __read_mostly = SK_WMEM_MAX;
+__u32 sysctl_rmem_default __read_mostly = SK_RMEM_MAX;
/* Maximal space eaten by iovec or ancilliary data plus some space */
-int sysctl_optmem_max = sizeof(unsigned long)*(2*UIO_MAXIOV + 512);
+int sysctl_optmem_max __read_mostly = sizeof(unsigned long)*(2*UIO_MAXIOV+512);
static int sock_set_timeout(long *timeo_p, char __user *optval, int optlen)
{
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index fc40da3..701960e 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -392,7 +392,7 @@ int inet_release(struct socket *sock)
}
/* It is off by default, see below. */
-int sysctl_ip_nonlocal_bind;
+int sysctl_ip_nonlocal_bind __read_mostly;
int inet_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
@@ -988,7 +988,7 @@ void inet_unregister_protosw(struct inet
* Shall we try to damage output packets if routing dev changes?
*/
-int sysctl_ip_dynaddr;
+int sysctl_ip_dynaddr __read_mostly;
static int inet_sk_reselect_saddr(struct sock *sk)
{
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 6d223e5..c2ad07e 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -187,11 +187,11 @@ struct icmp_err icmp_err_convert[] = {
};
/* Control parameters for ECHO replies. */
-int sysctl_icmp_echo_ignore_all;
-int sysctl_icmp_echo_ignore_broadcasts = 1;
+int sysctl_icmp_echo_ignore_all __read_mostly;
+int sysctl_icmp_echo_ignore_broadcasts __read_mostly = 1;
/* Control parameter - ignore bogus broadcast responses? */
-int sysctl_icmp_ignore_bogus_error_responses = 1;
+int sysctl_icmp_ignore_bogus_error_responses __read_mostly = 1;
/*
* Configurable global rate limit.
@@ -205,9 +205,9 @@ int sysctl_icmp_ignore_bogus_error_respo
* time exceeded (11), parameter problem (12)
*/
-int sysctl_icmp_ratelimit = 1 * HZ;
-int sysctl_icmp_ratemask = 0x1818;
-int sysctl_icmp_errors_use_inbound_ifaddr;
+int sysctl_icmp_ratelimit __read_mostly = 1 * HZ;
+int sysctl_icmp_ratemask __read_mostly = 0x1818;
+int sysctl_icmp_errors_use_inbound_ifaddr __read_mostly;
/*
* ICMP control array. This specifies what to do with each ICMP.
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index f84c4d0..48d705e 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1397,8 +1397,8 @@ static struct in_device * ip_mc_find_dev
/*
* Join a socket to a group
*/
-int sysctl_igmp_max_memberships = IP_MAX_MEMBERSHIPS;
-int sysctl_igmp_max_msf = IP_MAX_MSF;
+int sysctl_igmp_max_memberships __read_mostly = IP_MAX_MEMBERSHIPS;
+int sysctl_igmp_max_msf __read_mostly = IP_MAX_MSF;
static int ip_mc_del1_src(struct ip_mc_list *pmc, int sfmode,
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 8d7f107..165d728 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -54,15 +54,15 @@
* even the most extreme cases without allowing an attacker to measurably
* harm machine performance.
*/
-int sysctl_ipfrag_high_thresh = 256*1024;
-int sysctl_ipfrag_low_thresh = 192*1024;
+int sysctl_ipfrag_high_thresh __read_mostly = 256*1024;
+int sysctl_ipfrag_low_thresh __read_mostly = 192*1024;
-int sysctl_ipfrag_max_dist = 64;
+int sysctl_ipfrag_max_dist __read_mostly = 64;
/* Important NOTE! Fragment queue must be destroyed before MSL expires.
* RFC791 is wrong proposing to prolongate timer each fragment arrival by TTL.
*/
-int sysctl_ipfrag_time = IP_FRAG_TIME;
+int sysctl_ipfrag_time __read_mostly = IP_FRAG_TIME;
struct ipfrag_skb_cb
{
@@ -130,7 +130,7 @@ static unsigned int ipqhashfn(u16 id, u3
}
static struct timer_list ipfrag_secret_timer;
-int sysctl_ipfrag_secret_interval = 10 * 60 * HZ;
+int sysctl_ipfrag_secret_interval __read_mostly = 10 * 60 * HZ;
static void ipfrag_secret_re
Re: [PATCH 4/9] [TULIP] Clean tulip.h so it can be used by winbond-840.c
On Wed, Aug 09, 2006 at 01:33:18AM -0400, Jeff Garzik wrote: > 2) nobody (but parisc folks?) knows what CBMA and CBIO mean. Just use > "MMIO" and "PIO" "CBIO" is what's in the public documentation. I just want to make it easy for anyone who bothers to read the documentation to be sure they are reading about the right register. thanks, grant - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
On Wed, Aug 09, 2006 at 09:57:12AM +0200, Johannes Berg wrote: > Michael Wu wrote: > >I think it would be best if you made the firmware not be aware of a > >connection, and let the d80211 code take care of all the > >scanning/authenticating/associating. Of course, I know nothing about 3945, > >so I don't know if that's possible. > > > Please not, for now. We need someone pushing for fullmac features in > d80211, we need those anyway for embedded systems that can't afford > running all of it on the main CPU. While obviously Intel would benefit > from doing this since a lot more d80211 features would come available, > the greater good would be having a main-stream card that someone cares > about and helps making d80211 full-mac capable. I second this opinion. It would be good to make d80211 more capable of dealing with these cards. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug report for MV643XX driver
Kernel oops during heavy load downloads with the MV643XX driver on a PegII. I've replicated the problem on 2.6.17_gentoo-4, vanilla 2.6.17.1, vanilla 2.6.18_rc3. When downloading a large file from any fast mirror (I tested getting around 2.0MB/s) the system crashes after a random amount of time. Usually after 30seconds to a couple of minutes. I took pictures of the call trace, I'm sorry about the quality, they were taken with a phone camera. They can be viewed at http://web.mit.edu/peloquin/marvell Thanks, -Stuart - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3: tg3_stop_block timed out
Michael Chan wrote: On Tue, 2006-08-08 at 01:24 +0200, Bernd Schubert wrote: tg3.c:v3.49 (Feb 2, 2006) acpi_bus-0201 [01] bus_set_power : Device is not power manageable eth1: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:2b:aa:28 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] eth1: dma_rwctrl[769f4000] dma_mask[64-bit] eth2: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:2b:aa:29 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] eth2: dma_rwctrl[769f4000] dma_mask[64-bit] You have ASF enabled on eth1 but not on eth2 so I wonder if ASF is causing the problem. Can you run the same traffic on eth2 and see if you get the same timeout problem? Thanks. I'm also having this same problem: divert: allocating divert_blk for bond0 tg3.c:v3.14 (November 15, 2004) divert: allocating divert_blk for eth0 eth0: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:2e:82:1a eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] divert: allocating divert_blk for eth1 eth1: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:2e:82:1b eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] divert: freeing divert_blk for bond0 divert: freeing divert_blk for eth0 divert: freeing divert_blk for eth1 02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03) Subsystem: Broadcom Corporation: Unknown device 1644 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 161 Memory at fc8c (64-bit, non-prefetchable) [size=fc8a] Memory at fc8b (64-bit, non-prefetchable) [size=64K] Expansion ROM at 0001 [disabled] Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- 02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03) Subsystem: Broadcom Corporation: Unknown device 1644 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 169 Memory at fc8f (64-bit, non-prefetchable) [size=fc8d] Memory at fc8e (64-bit, non-prefetchable) [size=64K] Expansion ROM at 0001 [disabled] Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- I run these things with jumbo frames and bonding. In the case last night, our machine completely locked up because both interfaces stopped working and the channel bond between them went down. These guys are pushing a little over 1Gb/s total traffic between them (500Mb/s each) and one of them will take in about 300Mb/s. Outgoing packets average 20kpkts/s and incoming packets on the one interface average about 45kpkts/s (most incoming traffic is not jumbo). This was on console: tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 tg3: eth1: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=3400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2 tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 tg3: eth0: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=3400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2 tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 tg3: eth1: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=3400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2 tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 tg3: eth0: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=3400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2 tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2 We tried restarting networking. We tried unloading all network-related modules and reloading them. We eventually had to reboot the box to get networking started again. The kernel is 2.6.10, via FC2 (2.6.10-2.3.legacy). We've also had the problem with the latest FC4 kernel. Any information would be greatly appreciated. Philip - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211 merge plans
On Wed, 2006-08-09 at 01:40 -0400, Jeff Garzik wrote: > Michael Buesch wrote: > > To heavily reduce maintainance burden I would like to see d80211 > > going mainline as soon as possible, so that we can feature-freeze > > the softmac port of bcm43xx and reduce maintainance to next to zero > > there. So if people want freaky features, we simply point them > > to the d80211 port, which would coexist in mainline. > > > > d80211 in mainline would clearly marked as experimental, for sure. > > Notes must be added for possibly breaking usermode interfaces. > > > Does it have active maintainers? > > The DeviceScape people seem to have disappeared for months, except for a > rare appearance recently by Jouni. > > Did anyone ever come up with a list of why d80211 is superior? For one, it's got a _much_ more flexible device model than the current hostap/ipw-based stack, more like the net80211 stack for Atheros/madwifi. I think that's one of the main benefits. i.e., you can have the d80211 cards be any combination of [AP | client | wds? ] at any given time. Think of a repeater node, which is both an AP and client at the same time, all with one card. That's one of the things a lot of people like about net80211. Secondly, DS is also working hard on moving a lot of the higher-level processing to user space. Management frames and other more complex operations will eventually be pushed up to a fused wpa_supplicant +hostapd running in user space, which should (a) reduce the amount of kernel driver code, (b) increase flexibility of configuration, and (c) make any kernel API/ABI/etc much smaller since you don't have to push so much configuration down into the kernel itself. That's a start (please correct me if I'm wrong on any of this). Dan > What are the remaining d80211 issues? > > Jeff > > > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] d80211/bcm43xx: Modify ieee80211_ioctl.c for wireless statistics.
On Tue, 2006-08-08 at 19:00 -0500, Larry Finger wrote:
> Part 8 of 8 to add wireless statistics to the bcm43xx-d80211 system.
> This patch adds the appropriate range parameters and routine
> ieee80211_get_wireless_stats to ieee80211_ioctl.c.
>
> The patch is for the August 8 version of Linville's wireless-dev tree.
>
> Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
>
>
> diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
> index dd52555..3a1b97f 100644
> --- a/net/d80211/ieee80211_ioctl.c
> +++ b/net/d80211/ieee80211_ioctl.c
> @@ -1525,6 +1525,16 @@ static int ieee80211_ioctl_giwrange(stru
> range->min_frag = 256;
> range->max_frag = 2346;
>
> + range->max_qual.qual = 100;
> + range->max_qual.level = 152; /* set floor at -104 dBm (152 - 256) */
> + range->max_qual.noise = 152;
> + range->max_qual.updated = IW_QUAL_ALL_UPDATED;
> +
> + range->avg_qual.qual = 50;
> + range->avg_qual.level = 0;
> + range->avg_qual.noise = 0;
> + range->avg_qual.updated = IW_QUAL_ALL_UPDATED;
> +
> return 0;
> }
>
> @@ -2963,6 +2973,39 @@ static int ieee80211_ioctl_giwauth(struc
> return ret;
> }
>
> +/* Get wireless statistics. Called by /proc/net/wireless and by
> SIOCGIWSTATS */
> +static struct iw_statistics *ieee80211_get_wireless_stats(struct net_device
> *net_dev)
> +{
> + struct ieee80211_local *local = net_dev->ieee80211_ptr;
> + struct iw_statistics * wstats = &local->wstats;
> + struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(net_dev);
> + struct sta_info *sta;
> + static int tmp_level = 0;
> + static int tmp_qual = 0;
> +
> + sta = sta_info_get(local, sdata->u.wds.remote_addr);
> + if (!sta) {
> + wstats->discard.fragment = 0;
> + wstats->discard.misc = 0;
> + wstats->qual.qual = 0;
> + wstats->qual.level = 0;
> + wstats->qual.noise = 0;
> + wstats->qual.updated |= IW_QUAL_ALL_UPDATED;
What does the 'if (!sta)' check do? What's the case here? If the card
is not connected an access point or otherwise unconnected to anything
else, you should use IW_QUAL_ALL_INVALID here I think, because signal
quality has no meaning when you're disconnected (except possibly
background noise).
> + } else {
> + if (!tmp_level) { /* get initial values */
> + tmp_level = sta->last_signal;
> + tmp_qual = sta->last_rssi;
> + } else {/* smooth results */
> + tmp_level = (15 * tmp_level + sta->last_signal)/16;
> + tmp_qual = (15 * tmp_qual + sta->last_rssi)/16;
> + }
> + wstats->qual.level = tmp_level;
> + wstats->qual.qual = 100*tmp_qual/sta->max_rssi;
> + wstats->qual.noise = sta->last_noise;
> + wstats->qual.updated = IW_QUAL_ALL_UPDATED | IW_QUAL_DBM;
By using IW_QUAL_DBM, you're forcing all cards that use d80211 to report
statistics in dBm. I think that's a _good_ thing personally (it brings
some consistency to the whole wireless quality pit-of-doom), but I want
to make sure this is actually what you want to do here.
Dan
> + }
> + return wstats;
> +}
>
> static int ieee80211_ioctl_siwencodeext(struct net_device *dev,
> struct iw_request_info *info,
> @@ -3128,4 +3171,5 @@ const struct iw_handler_def ieee80211_iw
> .standard = (iw_handler *) ieee80211_handler,
> .private= (iw_handler *) ieee80211_private_handler,
> .private_args = (struct iw_priv_args *) ieee80211_ioctl_priv,
> + .get_wireless_stats = ieee80211_get_wireless_stats,
> };
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
