Re: [take23 0/5] kevent: Generic event handling mechanism.
On Tue, Nov 07, 2006 at 02:17:18PM -0800, Andrew Morton ([EMAIL PROTECTED]) wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > > If kevent_user_wait() gets -EFAULT on the attempt to copy the first event, it > will return 0, which is indistinguishable from "no events pending". > > It can and should return EFAULT in this case. Correct, I missed that. Thanks Andrew, I will put into my tree, -mm seems to have it already. -- 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: [take23 1/5] kevent: Description.
On Tue, Nov 07, 2006 at 02:16:40PM -0800, Andrew Morton ([EMAIL PROTECTED]) wrote: > On Tue, 7 Nov 2006 19:50:48 +0300 > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > Description. > > I converted this into Documentation/kevent.txt. It looks like crap in an > 80-col > xterm btw. Thanks. It was copied as is from documentation page, so it does looks like crap in non-browser window. I'm quite sure there will be some questions about kevent, so I will update that file and fix indent. -- 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: [take23 2/5] kevent: Core files.
On Tue, Nov 07, 2006 at 02:16:57PM -0800, Andrew Morton ([EMAIL PROTECTED]) wrote: > On Tue, 7 Nov 2006 19:50:48 +0300 > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > This patch includes core kevent files: > > * userspace controlling > > * kernelspace interfaces > > * initialization > > * notification state machines > > I fixed up all the rejects, but your syscall numbers changed. Please > always raise patches against the latest kernel. Will do. NUmbers actually are the same, but added new syscall which was against old tree. Thanks Andrew. -- 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
net-2.6.20 is up...
At: kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git I've integrated a series of endianness annotations from Al Viro to start things off. I have some things to review in my queue which I'll work on putting in there including: 1) Stephen Hemminger's netpoll queueing cleanups and fixes 2) The pending IPV6 tunnel work by Ville Nuorvala discussed last week. I have to review that thread carefully as I think there are some semantic issues with those changes which need to be fixed up first. 3) Stephen Hemminger's socket based congestion control selection semantic patches. There are some other small miscellaneous patches in my queue too, like an SCTP warning fix and stuff like that. Feel free to queue 2.6.20 networking stuff to me. 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: net-2.6.20 is up...
In article <[EMAIL PROTECTED]> (at Wed, 08 Nov 2006 00:34:38 -0800 (PST)), David Miller <[EMAIL PROTECTED]> says: > > At: > > kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git I guess you mean net-2.6.20.git; right? --yoshfuji - 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] Add support for configuring the PHY connection interface
Hi Andy,
Andy Fleming wrote:
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
> index b4b5b4a..b053370 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -211,6 +211,36 @@ static int __init gfar_set_flags(struct
> return device_flags;
> }
>
> +/* Return the Linux interface mode type based on the
> + * specification in the device-tree */
> +static int __init gfar_get_interface(struct device_node *np)
> +{
> + const char *istr;
> + int interface = 0;
> +
> + istr = get_property(np, "interface", NULL);
> +
> + if (istr == NULL)
> + istr = "GMII";
> +
> + if (!strcasecmp(istr, "GMII"))
> + interface = PHY_INTERFACE_MODE_GMII;
> + else if (!strcasecmp(istr, "MII"))
> + interface = PHY_INTERFACE_MODE_MII;
> + else if (!strcasecmp(istr, "RGMII"))
> + interface = PHY_INTERFACE_MODE_RGMII;
> + else if (!strcasecmp(istr, "SGMII"))
> + interface = PHY_INTERFACE_MODE_SGMII;
> + else if (!strcasecmp(istr, "TBI"))
> + interface = PHY_INTERFACE_MODE_TBI;
> + else if (!strcasecmp(istr, "RMII"))
> + interface = PHY_INTERFACE_MODE_RMII;
> + else if (!strcasecmp(istr, "RTBI"))
> + interface = PHY_INTERFACE_MODE_RTBI;
> +
> + return interface;
> +}
If you change the modes into an enum (as suggested by Kumar),
you can make a nice static lookup table indexed by mode with a for loop here.
Regards
Ingo Oeser
-
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.6.19-rc1: Volanomark slowdown
Hell]! > > reduced Volanomark benchmark throughput by 10%. The irony of it is that java vm used to be one of victims of over-delayed acks. I will look, there is a little chance that it is possible to detect the situation and to stretch ACKs. There is one little question though. If you see a visible difference in performance, does it mean that you see Volaconomark used to show much better numbers comparing to another OSes? :-) 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: [take23 3/5] kevent: poll/select() notifications.
On Tue, Nov 07, 2006 at 02:53:33PM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
> On Tue, 7 Nov 2006, Evgeniy Polyakov wrote:
>
> > +static int kevent_poll_wait_callback(wait_queue_t *wait,
> > + unsigned mode, int sync, void *key)
> > +{
> > + struct kevent_poll_wait_container *cont =
> > + container_of(wait, struct kevent_poll_wait_container, wait);
> > + struct kevent *k = cont->k;
> > + struct file *file = k->st->origin;
> > + u32 revents;
> > +
> > + revents = file->f_op->poll(file, NULL);
> > +
> > + kevent_storage_ready(k->st, NULL, revents);
> > +
> > + return 0;
> > +}
>
> Are you sure you can safely call file->f_op->poll() from inside a callback
> based wakeup? The low level driver may be calling the wakeup with one of
> its locks held, and during the file->f_op->poll may be trying to acquire
> the same lock. I remember there was a discussion about this, and assuming
> the above not true, made epoll code more complex (and slower, since an
> extra O(R) loop was needed to fetch events).
Indeed, I have not paid too much attention to poll/select notifications in
kevent actually. As far as I recall it should be called on behalf of process
doing kevent_get_event(). I will check and fix if that is not correct.
Thanks Davide.
> - Davide
>
--
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: Intel 82559 NIC corrupted EEPROM
Hello all, [ E-mail address is a bit-bucket. I *do* monitor the mailing lists. ] I will try and summarize the problem as I understand it at this point. I've written two messages so far: http://groups.google.com/group/linux.kernel/msg/3a05d819c66474db http://groups.google.com/group/linux.kernel/msg/391aebbb3dfd6039 And here is a link to the complete thread: http://lkml.org/lkml/fancy/2006/11/3/124 I have a motherboard with three on-board 82559 NICs. o eepro100.ko properly initializes all three NICs o e100.ko fails to initialize one of them NOTE: With kernel 2.6.14, e100.ko fails to initialize the NIC with MAC address 00:30:64:04:E6:E4. With kernel 2.6.18 e100.ko fails to initialize the NIC with MAC address 00:30:64:04:E6:E5. The problem is not an incorrect checksum. (Donald Becker's dump utility reports a correct checksum for all three NICs.) The problem seems to be that e100.ko fails to read the contents of one of the EEPROMs. Auke wrote: How did you do the first `ethtool` eeprom dump? did you have the `e100` module loaded at that time? Did you use the new `override` mechanism graciously donated by David M? These tests were performed on a 2.6.14 kernel. I hacked e100_eeprom_load() to return 0 even when the checksum fails. Thus the driver did not refuse to load, and I was able to use ethtool to dump the contents of the 3 EEPROMs. Here are additional examples running a 2.6.18.1-hrt kernel. 'insmod e100.ko' reports: e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 12 PCI: setting IRQ 12 as level-triggered ACPI: PCI Interrupt :00:08.0[A] -> Link [LNKA] -> GSI 12 (level, low) -> IRQ 12 e100: eth0: e100_probe: addr 0xe530, irq 12, MAC addr 00:30:64:04:E6:E4 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt :00:09.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 e100: :00:09.0: e100_eeprom_load: EEPROM corrupted ACPI: PCI interrupt for device :00:09.0 disabled e100: probe of :00:09.0 failed with error -11 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI Interrupt :00:0a.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 e100: eth1: e100_probe: addr 0xe5301000, irq 11, MAC addr 00:30:64:04:E6:E6 'insmod e100.ko eeprom_bad_csum_allow=1' reports: e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 12 PCI: setting IRQ 12 as level-triggered ACPI: PCI Interrupt :00:08.0[A] -> Link [LNKA] -> GSI 12 (level, low) -> IRQ 12 e100: eth0: e100_probe: addr 0xe530, irq 12, MAC addr 00:30:64:04:E6:E4 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt :00:09.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 e100: :00:09.0: e100_eeprom_load: EEPROM corrupted e100: :00:09.0: e100_probe: Invalid MAC address from EEPROM, aborting. ACPI: PCI interrupt for device :00:09.0 disabled e100: probe of :00:09.0 failed with error -11 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI Interrupt :00:0a.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 e100: eth1: e100_probe: addr 0xe5301000, irq 11, MAC addr 00:30:64:04:E6:E6 'insmod e100.ko debug=16' reports: e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 12 PCI: setting IRQ 12 as level-triggered ACPI: PCI Interrupt :00:08.0[A] -> Link [LNKA] -> GSI 12 (level, low) -> IRQ 12 e100: :00:08.0: mdio_ctrl: READ:addr=1, reg=0, data_in=0x, data_out=0x18203000 e100: :00:08.0: mdio_ctrl: READ:addr=1, reg=1, data_in=0x, data_out=0x18217809 e100: :00:08.0: mdio_ctrl: READ:addr=1, reg=1, data_in=0x, data_out=0x18217809 e100: :00:08.0: e100_phy_init: phy_addr = 1 e100: :00:08.0: mdio_ctrl: WRITE:addr=0, reg=0, data_in=0x0400, data_out=0x14000400 e100: :00:08.0: mdio_ctrl: READ:addr=1, reg=0, data_in=0x, data_out=0x18203000 e100: :00:08.0: mdio_ctrl: WRITE:addr=1, reg=0, data_in=0x3000, data_out=0x14203000 e100: :00:08.0: mdio_ctrl: WRITE:addr=2, reg=0, data_in=0x0400, data_out=0x14400400 e100: :00:08.0: mdio_ctrl: WRITE:addr=3, reg=0, data_in=0x0400, data_out=0x14600400 e100: :00:08.0: mdio_ctrl: WRITE:addr=4, reg=0, data_in=0x0400, data_out=0x14800400 e100: :00:08.0: mdio_ctrl: WRITE:addr=5, reg=0, data_in=0x0400, data_out=0x14A00400 e100: :00:08.0: mdio_ctrl: WRITE:addr=6, reg=0, data_in=0x0400, data_out=0x14C00400 e100: :00:08.0: mdio_ctrl: WRITE:addr=7, reg=0, data_in=0x0400, data_out=0x14E00400 e100: :00:08.0: mdio_ctrl: WRITE:addr=8, reg=0, data_in=0x0400, data_out=0x15000400 e100: :00:08.0: md
Re: [PATCH 0/11] convert d80211 to a proper protocol
On Mon, 06 Nov 2006 22:09:54 +0100, Johannes Berg wrote: > > What did happen with > > d80211: add a function to get the wiphy index > > d80211: add a perm_addr hardware property > > d80211: add a struct device* hardware property > > d80211: add a ethtool_ops hardware property > > patches? > > Well after some chat with a few people I decided that it was stupid and > not very maintainable to copy all the fields in net_device to a new > structure. Ok. Personally, I don't care if we pass net_device or ieee80211_local to drivers. I see pros and cons of both solutions. > Oh come off it! It's really stupid to have to check all the tabs/spaces > all the time. The patch changes 451 lines. And wiggle can handle that > just fine. Besides, if you do > s/^\+ /+\t/ > s/^- /-\t/ > s//\t/ > on your patches, they'll be fine too. I understand that. But the patch isn't small - it's 71 kiB and I'm concerned mainly about David's bitfields conversion patches. So, what about this: let's clean up those spaces (and perhaps do more coding style cleanups?) after David's patches are merged. Is it feasible for you? > Yeah. It's pretty bad actually, but I couldn't really find a good way to > split it into logical chunks. Unfortunately, in the current form it's unreviewable for me, Individual patches may be laid as follows (take it as a guideline only): - introduce IEEE80211_IF_TYPE_MASTER and convert mdev to be of this type - get rid of mdev's sdata (you'll probably find out that you need to preserve it at least in some form but let's see) - do whatever you feel appropriate with driver's private data (I'm not saying I'll be happy with any such solution, though) - do other changes of memory layout - remove ieee80211_dev.c and replace it by cfg80211 index - do some changes to the sysfs layout (again, I'm not promising to be happy with it) - introduce ieee80211_tx.c and ieee80211_rx.c files (I'll probably NAK such patch for the same reasons as the white space cleanup, though) - do .h files cleanup (I'd really like to see this) > I don't think I understand this. I mean, my patch actually gives us > native 802.11 devices by making the drivers register those and then > handling them virtually similar to how 8021q handles ethernet devices. I > honestly thought that this was the plan for said "native 802.11 > devices". What I understand as a "native 802.11 device": 1. it uses native 802.11 protocol, ie. no conversions from/to Ethernet frames 2. better qdiscs support (1) implies some interesting things: a. drivers can call netif_rx directly b. tx/rx path cleanup happens, this will lead to solving of some currently hardly solvable issues c. overall speedup of the frame processing (1) _doesn't_ particularly mean the following things: a. requiring drivers to register net_device by themselves (I'd like to preserve the concept of add_interface/remove_interface callbacks) b. setting hard_start_xmit of mdev by drivers instead of using ieee80211_hw->tx callback (but this isn't disallowed either) c. removing of master net_device (again, this is possible to happen) The main goal for me is to make things as easy as possible for driver developers. Currently, we're going the way of mixed layer/library approach and I really like it. I'm afraid that a pure library way would put unnecessary requirements to drivers. Also, please note that making a patch to use native 802.11 protocol is easy. Actually, I wrote it long time ago (it doesn't apply now and I'd need to rewrite it completly, but anyway). However, it's not possible to apply such patch now - the bridging needs to be solved first. > > > * sysfs layout changed. There is no wiphy or an ieee80211 class any more, > > > the attributes that used to be there are now in the net_device that > > > the driver registered, and our attributes are below the devices we > > > created. > > > > Doesn't belong to this patch. > > Had to be here initially due to the way I did things, but ok, probably > changeable. Sorry, cut&paste error. My comment belonged to: > * memory layout. struct ieee80211_local is allocated by itself now. > > * saner source layout. rx/tx handlers in their own files, one header >for each C file that exports things. But it's valid for the sysfs part as well anyway :-) Thanks, Jiri -- Jiri Benc SUSE Labs - 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/11] convert d80211 to a proper protocol
On Tue, 07 Nov 2006 00:06:34 +0100, Johannes Berg wrote: > Keeping with the protocol theme, we need to rewrite the rx path to do > the following in the order listed: > > 1) if any monitor interfaces are up, copy the skb, add the > prism/radiotap/whatever header and then clone it to all monitor > interfaces (don't actually copy for each as we do now) > 2) if it is a unicast frame, determine which interface the frame should > go to now, it can't be going to more than one afaik > 2) decrypt the frame > 3) defragment the frame > 4) send the frame off to each sub_if that might care about it > 5) do further device specific processing Multicast and broadcast frames complicates this a bit but other than that you're right. See below. > If we're careful, we can probably get away with a lot less copying than > we do now by pushing the copying down into those handlers that really > need different data. Correct. > This would probably only be the crypto handlers, > the others can live with just pskb_copy instead. Unfortunately, in case of broadcast and multicast frames, we probably need to go through decryption handlers for each interface individually. At least I wasn't able to find a solution which allows to perform decryption only once for each frame. But theoretically it should be possible but I'm afraid it would be less effective than the current situation in the end. Unfortunately, when you perform decryption in each interface separately, you are tended to perform defragmentation separately as well. This is something that could be possibly improved. > Then again, we don't > handle non-linear skbs anyway. Actually, we should be calling > skb_linearize at least, no? > > And if the frame is not encrypted at all, then we can even save the > skb_copy for the monitor and just use skb_clone and later pskb_copy... Jiri -- Jiri Benc SUSE Labs - 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/11] convert d80211 to a proper protocol
On Wed, 2006-11-08 at 12:58 +0100, Jiri Benc wrote: > Ok. Personally, I don't care if we pass net_device or ieee80211_local > to drivers. I see pros and cons of both solutions. As I said in the other patchset, I'd prefer to not change the API for these cleanups unless we have to, so dropping this. > I understand that. But the patch isn't small - it's 71 kiB and I'm > concerned mainly about David's bitfields conversion patches. So, what > about this: let's clean up those spaces (and perhaps do more coding > style cleanups?) after David's patches are merged. Is it feasible for > you? Sure. > Unfortunately, in the current form it's unreviewable for me, I know that. Actually, I didn't really expect these to be applied. Just more of a proof-of-concept of how it would look like when converted to a protocol. And you've proven me wrong with the subif issue already :) > Individual patches may be laid as follows (take it as a guideline only): > - introduce IEEE80211_IF_TYPE_MASTER and convert mdev to be of this type > - get rid of mdev's sdata (you'll probably find out that you need to > preserve it at least in some form but let's see) Nah, I don't see a reason why that couldn't be completely in local. In fact, the only things we ought to be using the master device for is sending packets to the driver and attaching the qdisc. Hence, we can completely layer the virtual interfaces atop it instead of making it a peer of them in some ways. I plan to put a magic constant into sub_if_data as the first entry and assign some magic to it for all the non-master interfaces and make the DEV_TO_SUBIF macro BUG_ON() magic != correct. That'll help me get rid of the sdata ;) > - introduce ieee80211_tx.c and ieee80211_rx.c files (I'll probably NAK > such patch for the same reasons as the white space cleanup, though) I think it's a pain to work on the code if we don't do this. > - do .h files cleanup (I'd really like to see this) So far I only did the internal headers... I can redo that patch though. > What I understand as a "native 802.11 device": > 1. it uses native 802.11 protocol, ie. no conversions from/to Ethernet >frames > 2. better qdiscs support Right. That'd be a native 802.11 device. But you haven't specified where you want it, and that's the key issue. For starters, I want it on the master device, sort of like we have now except that it's pretty useless. But you also want the virtual devices to be native 802.11 devices. These two, however, are completely orthogonal! > (1) implies some interesting things: > a. drivers can call netif_rx directly > b. tx/rx path cleanup happens, this will lead to solving of some >currently hardly solvable issues > c. overall speedup of the frame processing Correct, and desperately needed. > (1) _doesn't_ particularly mean the following things: > a. requiring drivers to register net_device by themselves (I'd like to >preserve the concept of add_interface/remove_interface callbacks) Why? > b. setting hard_start_xmit of mdev by drivers instead of using >ieee80211_hw->tx callback (but this isn't disallowed either) Again, you can't at the same time allow removing the mdev and allow drivers to set the hard_start_xmit call :) > c. removing of master net_device (again, this is possible to happen) Yes, but only if you preserve the semantics of having the stack have full control over the hardware. I've come to think that this is wrong. > The main goal for me is to make things as easy as possible for driver > developers. Currently, we're going the way of mixed layer/library > approach and I really like it. I'm afraid that a pure library way would > put unnecessary requirements to drivers. Actually, I was thinking that it would be a lot easier for driver authors if they could just register their net_device along with some 802.11 help functions (ieee80211_hw) and otherwise behave just like a real net_dev. Here's my proposal in text-form instead of code, vaguely listed in order of the work to do: a) we clean up the rx path to get rid of master sub_if, and mostly of the master dev as well. b) instead of having __ieee80211_rx() we register a packet_type for 802.11 frames, and a netdevice notifier to see when new devices show up These are the basic items we have to do. We gain: * drivers must now register a proper net_device with 802.11 arphrd, and when they receive skbs they simply netif_rx them, we get rid of __ieee80211_rx * drivers just assign hard_start_xmit * drivers fully control their net_device so ethtool things make sense again etc. * we don't need the notion of a wiphy since like vlan, the sta/ap/wds/... devices are logically stacked on top of the driver's 802.11 device * we can get rid of virtual monitor interfaces (the driver's 802.11 device gets the frames anyway), we do need a few new config options to configure hard monitor mode for example. * 802.11 finally becomes a proper protocol instead of being a
Re: [PATCH 0/11] convert d80211 to a proper protocol
On Wed, 2006-11-08 at 13:09 +0100, Jiri Benc wrote: > Unfortunately, in case of broadcast and multicast frames, we probably > need to go through decryption handlers for each interface individually. > At least I wasn't able to find a solution which allows to perform > decryption only once for each frame. But theoretically it should be > possible but I'm afraid it would be less effective than the current > situation in the end. Yeah, I can see the point, even though it seems that we can only decrypt a frame with a single key, everything else will be invalid. Maybe we can filter somehow and find which key to use instead of filtering to the interface first... will need to think about it. johannes - 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/11] convert d80211 to a proper protocol
Jiri Benc wrote: On Mon, 06 Nov 2006 22:09:54 +0100, Johannes Berg wrote: What did happen with d80211: add a function to get the wiphy index d80211: add a perm_addr hardware property d80211: add a struct device* hardware property d80211: add a ethtool_ops hardware property patches? Well after some chat with a few people I decided that it was stupid and not very maintainable to copy all the fields in net_device to a new structure. Ok. Personally, I don't care if we pass net_device or ieee80211_local to drivers. I see pros and cons of both solutions. Agreed. Though if using ieee80211_local, please remove the "_local". A better name is needed. 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: [Info]d80211 : Understanding d80211
thanks larry for the initial info.. pls reply.. On 11/4/06, Larry Finger <[EMAIL PROTECTED]> wrote: Udayan Singh wrote: > Hi, > > I wanted to understand the code of d80211 (thanks to James Ketrenos > for the info he provided) and also work in it. > > I found that I can get the latest patches regarding the same from : > > http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/ Wireless-2.6 contains the developmental version of wireless code _NOT_ using d80211. The d80211 development version is at git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git and must be downloaded with git, not ftp or http. ok. > Any docs that I can read through that you would recommend from where I > can start up ? Only the code AFAIK. referring to the standards might be good i.e. 802.11 standards ?? I intend to work in the manner: 1. There are quite many standards that have already been implemented e.g. 802.11a/b/g in the kernel (here wireless-dev). If there is a new standard wrt. 802.11x coming in, then I can work on same. 2. Work on an already implemented standard and try to add a missing feaature into it. Kindly let me know your opinions. tia, Udayan 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] make sch_fifo.o available when CONFIG_NET_SCHED is not set
On Wed, Nov 01, 2006 at 12:24:01AM +0100, Thomas Graf wrote: > I think NET_SCH_FIFO doesn't need a help text, should be invisible > to the user. Just select it from NET_SCHED and d80211. sure, here is a new one: Based on patch by Patrick McHardy. Add a new option, NET_SCH_FIFO, which provides a simple fifo qdisc without requiring CONFIG_NET_SCHED. The d80211 stack needs a generic fifo qdisc for WME. At present it uses net/d80211/fifo_qdisc.c which is functionally equivalent to sch_fifo.c. This patch will allow the d80211 stack to remove net/d80211/fifo_qdisc.c and use sch_fifo.c instead. Signed-off-by: David Kimdon <[EMAIL PROTECTED]> Index: wireless-dev/net/sched/Kconfig === --- wireless-dev.orig/net/sched/Kconfig +++ wireless-dev/net/sched/Kconfig @@ -6,6 +6,7 @@ menu "QoS and/or fair queueing" config NET_SCHED bool "QoS and/or fair queueing" + select NET_SCH_FIFO ---help--- When the kernel has several packets to send out over a network device, it has to decide which ones to send first, which ones to @@ -40,6 +41,9 @@ config NET_SCHED The available schedulers are listed in the following questions; you can say Y to as many as you like. If unsure, say N now. +config NET_SCH_FIFO + bool + if NET_SCHED choice Index: wireless-dev/net/sched/Makefile === --- wireless-dev.orig/net/sched/Makefile +++ wireless-dev/net/sched/Makefile @@ -4,7 +4,7 @@ obj-y := sch_generic.o -obj-$(CONFIG_NET_SCHED)+= sch_api.o sch_fifo.o sch_blackhole.o +obj-$(CONFIG_NET_SCHED)+= sch_api.o sch_blackhole.o obj-$(CONFIG_NET_CLS) += cls_api.o obj-$(CONFIG_NET_CLS_ACT) += act_api.o obj-$(CONFIG_NET_ACT_POLICE) += act_police.o @@ -14,6 +14,7 @@ obj-$(CONFIG_NET_ACT_MIRRED) += act_mirr obj-$(CONFIG_NET_ACT_IPT) += act_ipt.o obj-$(CONFIG_NET_ACT_PEDIT)+= act_pedit.o obj-$(CONFIG_NET_ACT_SIMP) += act_simple.o +obj-$(CONFIG_NET_SCH_FIFO) += sch_fifo.o obj-$(CONFIG_NET_SCH_CBQ) += sch_cbq.o obj-$(CONFIG_NET_SCH_HTB) += sch_htb.o obj-$(CONFIG_NET_SCH_HPFQ) += sch_hpfq.o - 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/3] mlsxfrm: Various fixes
> > Fix SO_PEERSEC for tcp sockets to return the security context of > > the peer (as represented by the SA from the peer) as opposed to the > > SA used by the local/source socket. > > What about the case of a localhost TCP connection not using > xfrm labeling? > > Joe Nall raised this as an important requirement. Yes. We need to come up with some new ideas on this (the failed secid-recon patchset sought to do this using the secmark field on the skb). The scope of this patchset is to strictly fix things related to labeled-xfrm. > > > > (Also, 'mlsxfrm' is MLS-specific). Will switch to "labeled-ipsec". - 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/3] mlsxfrm: Various fixes
> Such duplication can occur among the initial SIDs. For some reason I thought that could happen between an initial SID and a non-initial SID. > Not sure > though when > that would apply here, It could apply to xfrms if they happen to be using the context represented by any of the initial SIDs. > and it would only apply if both SIDs > were initial > SIDs. OK. Will narrow the full context comparison to just this case. - 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: [take3 0/5] d80211: remove bitfields from include/net/d80211.h
On Thu, Nov 02, 2006 at 10:30:56PM -0500, John W. Linville wrote: > David, may I presume there will be a "take4"? yes, refreshing is in progress. - 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
[DECnet] Don't clear memory twice.
When dn_neigh.c was converted from kmalloc to kzalloc in commit 0da974f4f303a6842516b764507e3c0a03f41e5a it was missed that dn_neigh_seq_open was actually clearing the allocation twice was missed. Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> diff --git a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c index ff0ebe9..7322bb3 100644 --- a/net/decnet/dn_neigh.c +++ b/net/decnet/dn_neigh.c @@ -591,7 +591,6 @@ static int dn_neigh_seq_open(struct inod seq = file->private_data; seq->private = s; - memset(s, 0, sizeof(*s)); out: return rc; out_kfree: - 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: [take23 0/5] kevent: Generic event handling mechanism.
On Wednesday 08 November 2006 09:21, Evgeniy Polyakov wrote: > On Tue, Nov 07, 2006 at 02:17:18PM -0800, Andrew Morton ([EMAIL PROTECTED]) wrote: > > From: Andrew Morton <[EMAIL PROTECTED]> > > > > If kevent_user_wait() gets -EFAULT on the attempt to copy the first > > event, it will return 0, which is indistinguishable from "no events > > pending". > > > > It can and should return EFAULT in this case. > > Correct, I missed that. > Thanks Andrew, I will put into my tree, -mm seems to have it already. I believe eventpoll has a similar problem. Not a big problem, but we can be cleaner. Normally, the access_ok() done in sys_epoll_wait() should catch non writeable user area, unless another thread play VM game (the thread in sys_epoll_wait() can sleep) [PATCH] eventpoll : In case a fault occurs during copy_to_user(), we should report the count of events that were successfully copied into user space, instead of EFAULT. That would be consistent with behavior of read/write() syscalls for example. Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> --- linux/fs/eventpoll.c2006-11-08 15:37:36.0 +0100 +++ linux/fs/eventpoll.c2006-11-08 15:38:31.0 +0100 @@ -1447,7 +1447,7 @@ &events[eventcnt].events) || __put_user(epi->event.data, &events[eventcnt].data)) - return -EFAULT; + return eventcnt ? eventcnt : -EFAULT; if (epi->event.events & EPOLLONESHOT) epi->event.events &= EP_PRIVATE_BITS; eventcnt++;
Re: 2.6.19-rc1: Volanomark slowdown
On Tue, 2006-11-07 at 10:32 -0800, Tim Chen wrote: > The patch > > [TCP]: Send ACKs each 2nd received segment > commit: 1ef9696c909060ccdae3ade245ca88692b49285b > http://kernel.org/git/? > p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ef9696c909060ccdae3ade245ca88692b49285b > > reduced Volanomark benchmark throughput by 10%. > This is because Volanomark sends > short message (<100 bytes) on its TCP > connections. This patch increases the number of ACKs > traffic by 3.5 times. > > By adopting this patch, we assume that with > small segment, having short delay is important > enough that we are willing to reduce bandwidth > with more ACKs. I wonder if it's an option to use low priority QoS fields for these acks (heck I don't even know if ACKs have such fields in their packet) so that they can get dropped if there are more packets then there is bandwidth -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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: Intel 82559 NIC corrupted EEPROM
John wrote: I have a motherboard with three on-board 82559 NICs. o eepro100.ko properly initializes all three NICs o e100.ko fails to initialize one of them NOTE: With kernel 2.6.14, e100.ko fails to initialize the NIC with MAC address 00:30:64:04:E6:E4. With kernel 2.6.18 e100.ko fails to initialize the NIC with MAC address 00:30:64:04:E6:E5. The problem is not an incorrect checksum. (Donald Becker's dump utility reports a correct checksum for all three NICs.) The problem seems to be that e100.ko fails to read the contents of one of the EEPROMs. [snip] 'insmod e100.ko eeprom_bad_csum_allow=1' reports: e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 12 PCI: setting IRQ 12 as level-triggered ACPI: PCI Interrupt :00:08.0[A] -> Link [LNKA] -> GSI 12 (level, low) -> IRQ 12 e100: eth0: e100_probe: addr 0xe530, irq 12, MAC addr 00:30:64:04:E6:E4 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt :00:09.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 e100: :00:09.0: e100_eeprom_load: EEPROM corrupted e100: :00:09.0: e100_probe: Invalid MAC address from EEPROM, aborting. ACPI: PCI interrupt for device :00:09.0 disabled e100: probe of :00:09.0 failed with error -11 This is what I was afraid of: even though the code allows you to bypass the EEPROM checksum, the probe fails on a further check to see if the MAC address is valid. Since something with this NIC specifically made the EEPROM return all 0xff's, the MAC address is automatically invalid, and thus probe fails. It seems that the driver has more problems with this NIC than just the eeprom checksum being bad. Needless to say this might need fixing. Can you load the eepro driver and send me the full eeprom dump? Perhaps I can duplicate things over here. [snip] On a related note, I am concerned by this message: Sleep mode is enabled. This is not recommended. Under high load the card may not respond to PCI requests, and thus cause a master abort. To clear sleep mode use the '-G 0 -w -w -f' options. Intel 82559 EEPROM Map and Programming Information (AP-394) states: http://www.intel.com/design/network/applnots/ap394.htm The Standby Enable bit enables the 82559 to enter standby mode. When this bit equals 1b, the 82559 is able to recognize an idle state and can enter standby mode (some internal clocks are stopped for power saving purposes). The 82559 does not require a PCI clock signal in standby mode. If this bit equals 0b, the idle recognition circuit is disabled and the 82559 always remains in an active state. Thus, the 82559 always requests PCI CLK using the Clockrun mechanism. Auke, do you agree with Donald Becker's warning? If you are using the e100 in a performance situation, I would certainly switch it off :) If I disable STB, the NICs will waste a bit more power when idle, is that correct? Are there other implications? hm, I don't know the power specs of e100 that well, so I can't say that it saves significant amounts of power, but I suspect it would. Power management on nics is hairy business. As suggested, it can take time before the nic powers back up, performance can be impacted, and some commands might return an invalid or unknown value. OTOH our labs here test these things pretty well before they get send out to customers and resales agents, so Beckers cautious wording catches the severity pretty well (recommended). I would say that under most circumstances, it's safe to enable STB, but you might want to disable it for use in routing and other server applications, where most of the time the NIC is active anyway. hth Auke Thanks for reading this far! John - 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.6.19-rc1: Volanomark slowdown
On Wed, Nov 08, 2006 at 04:55:18PM +0100, Arjan van de Ven wrote: > I wonder if it's an option to use low priority QoS fields for these acks > (heck I don't even know if ACKs have such fields in their packet) so > that they can get dropped if there are more packets then there is > bandwidth Is it proven that the number of ACKs actually cause bandwidth problems? I found Volanomark to exercise the scheduler more than anything else, so maybe the slowdown, while triggered by an increased number of ACKs, is caused by something else entirely. Olaf -- Walks like a duck. Quacks like a duck. Must be a chicken. - 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: [take23 3/5] kevent: poll/select() notifications.
On Wed, Nov 08, 2006 at 11:45:54AM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > > Are you sure you can safely call file->f_op->poll() from inside a callback > > based wakeup? The low level driver may be calling the wakeup with one of > > its locks held, and during the file->f_op->poll may be trying to acquire > > the same lock. I remember there was a discussion about this, and assuming > > the above not true, made epoll code more complex (and slower, since an > > extra O(R) loop was needed to fetch events). > > Indeed, I have not paid too much attention to poll/select notifications in > kevent actually. As far as I recall it should be called on behalf of process > doing kevent_get_event(). I will check and fix if that is not correct. > Thanks Davide. Indeed there was a bug. Actually poll/select patch was broken quite noticebly - patchset did not include major changes I made for it. I will put them all into next release. Thanks again Davide for pointing that out. -- 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: Intel 82559 NIC corrupted EEPROM
On 11/8/06, John <[EMAIL PROTECTED]> wrote: Hello all, [ E-mail address is a bit-bucket. I *do* monitor the mailing lists. ] I will try and summarize the problem as I understand it at this point. I've written two messages so far: http://groups.google.com/group/linux.kernel/msg/3a05d819c66474db http://groups.google.com/group/linux.kernel/msg/391aebbb3dfd6039 And here is a link to the complete thread: http://lkml.org/lkml/fancy/2006/11/3/124 I have a motherboard with three on-board 82559 NICs. o eepro100.ko properly initializes all three NICs o e100.ko fails to initialize one of them NOTE: With kernel 2.6.14, e100.ko fails to initialize the NIC with MAC address 00:30:64:04:E6:E4. With kernel 2.6.18 e100.ko fails to initialize the NIC with MAC address 00:30:64:04:E6:E5. The problem is not an incorrect checksum. (Donald Becker's dump utility reports a correct checksum for all three NICs.) The problem seems to be that e100.ko fails to read the contents of one of the EEPROMs. Thanks for the report, I have some thoughts. I suspect that one reason beckers code works is that it uses IO based access (slower, and different method) to the adapter rather than memory mapped access. The second thought is that the adapter is in D3, and something about your kernel or the driver doesn't successfully wake it up to D0. An indication of this would be looking at lspci -vv before/after loading the driver. Also, after loading/unloading eepro100 does the e100 driver work? A third idea is look for a master abort in lspci after e100 fails to load. And a last idea is for us to instrument the reads /writes from/to the device during init and see if everything is returning 0x, as that indicates the I/O and/or memory bar is not enabled, or the address returned from ioremap is invalid. Jesse - 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. Please pull 'upstream' branch of wireless-2.6
John, you just broke a considerable number of prism54 users. It is NOT an error if the MWI set fails. This is just a performance tweak and has NO effect on the driver working. Roger While - 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/3] mlsxfrm: Various fixes
On Wed, 2006-11-08 at 08:34 -0600, Venkat Yekkirala wrote: > > Such duplication can occur among the initial SIDs. > > For some reason I thought that could happen between an initial SID > and a non-initial SID. I think only in the case where a non-initial SID has been invalidated by policy reload that renders its context illegal and is thus remapped to the unlabeled SID. > > Not sure > > though when > > that would apply here, > > It could apply to xfrms if they happen to be using the context > represented by any of the initial SIDs. Which would happen when? > > and it would only apply if both SIDs > > were initial > > SIDs. > > OK. Will narrow the full context comparison to just this case. What's the harm from just using the SID comparison and allowing for the possibility that there might be a few duplicates in rare circumstances? Does it break any assumptions in the rest of the logic? -- Stephen Smalley National Security Agency - 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: SKB BUG: Invalid truesize, current git
On Tue, Nov 07, 2006 at 02:57:24PM -0800, David Miller wrote: > > Since pskb_copy tacks on the non-linear bits from the original > > skb, it needs to count them in the truesize field of the new skb. > > > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> > > Applied, thanks Herbert. This seems to work -- I haven't been able to trigger the message with the patch applied now. -ben -- "Time is of no importance, Mr. President, only life is important." Don't Email: <[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 3/3] mlsxfrm: Various fixes
> > > Not sure > > > though when > > > that would apply here, > > > > It could apply to xfrms if they happen to be using the context > > represented by any of the initial SIDs. > > Which would happen when? If one were attempting to use a context pertaining to the unlabeled init sid in the SPD and/or the SAD. But would I be correct in assuming that the same sid (unlabeled init sid in all likelyhood) would end up being returned when the context is turned into a sid, resulting in the SPD and the SAD using the same init sid, thus making a full-context compare unnecessary? > > > > and it would only apply if both SIDs > > > were initial > > > SIDs. > > > > OK. Will narrow the full context comparison to just this case. > > What's the harm from just using the SID comparison and > allowing for the > possibility that there might be a few duplicates in rare > circumstances? > Does it break any assumptions in the rest of the logic? The best I can think of is if the SA's sid doesn't match the socket's SID, IKE would come into play, if it's configured. I also wanted to conversely ask what harm exists if we did a full-context compare in the event the sids didn't match? Are we just trying to generally avoid extra code? - 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: Re. Please pull 'upstream' branch of wireless-2.6
On Wed, Nov 08, 2006 at 06:27:54PM +0100, Roger While wrote: > John, you just broke a considerable number of prism54 users. > It is NOT an error if the MWI set fails. This is just a > performance tweak and has NO effect on the driver working. Yeah, looks like I was a bit overzealous on the warning squelch... I'll cook-up a new patch that doesn't error-out. 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
General network driver suspend/resume (was e1000 carrier related)
On Wed, 8 Nov 2006 13:04:07 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > >>This behavior differs from every other network card, and is also present > > >>in the > > >>7.3* version of the driver from sourceforge. > > >> > > >>I think the e1000 should try to raise the link during the probe, so that > > >>it > > >>works properly, without having to set ifconfig ethX up first. > > > > > >I think you should cc e1000 maintainers, and perhaps provide a patch > > > > I've read it and not come up with an answer due to some other issues at > > hand. E1000 hardware works differently and this has been asked before, but > > the cards itself are in low power state when down. Changing this to bring > > up the link would make the card start to consume lots more power, which > > would automatically suck enormously for anyone using a laptop. > > Well, maybe E1000 should behave as the other cards behave, and > different solution needs to be found for power saving? ifconfig eth0 > suspend? > > Pavel > > The standard which all network drivers should use is: module insertion: start in initial powerdown state open: power up, bring up link stop: bring down link return to powerdown state unless WOL is set. if doing WOL go to lowest power sensing state suspend: same as stop resume: same as open module removal: stop already called so device should be in power down state. Since suspend is basically same as stop, and resume is open I am going to investigate doing suspend/resume in the network device layer (unless subclassed by driver), so we can rip out the suspend/resume hook from many network drivers. There will still be boards like sky2 that need own suspend/resume to deal with dual port etc. -- Stephen Hemminger <[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: Please pull 'upstream' branch of wireless-2.6
On Tue, Nov 07, 2006 at 11:59:27PM -0500, John W. Linville wrote: > The following changes since commit d4f748365129ccfc9dadf6fb14331e45e33cc4ed: > John W. Linville: > Merge branch 'upstream-fixes' into upstream > > are found in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git > upstream > > John W. Linville: > wireless: clean-up some "check return code" warnings Jeff, hold-off on this pull. You can still go ahead and pull the 'upstream-fixes' branch at your pleasure. 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
e1000: include for IA64
Here's a slightly better patch to fix ia64 not building atm. Jeff, please apply this to netdev-2.6#upstream instead of akpm's patch that I acked earlier. Of course, someone really should come up with an asm version for ia64 of the missing function ;) Cheers, Auke --- e1000: include for IA64 IA64 does not have an optimized asm version for ipv6 csum magic. Fall back to generic implementation. Signed-off-by: Auke Kok <[EMAIL PROTECTED]> diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h index f091042..26e7506 100644 --- a/drivers/net/e1000/e1000.h +++ b/drivers/net/e1000/e1000.h @@ -61,6 +61,7 @@ #include #ifdef NETIF_F_TSO6 #include +#include #endif #include #include - 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: e1000: include for IA64
On Wed, 08 Nov 2006 09:48:35 -0800 Auke Kok <[EMAIL PROTECTED]> wrote: > Here's a slightly better patch to fix ia64 not building atm. fsvo "better". > Jeff, please apply this to netdev-2.6#upstream instead of akpm's patch that I > acked earlier. > > Of course, someone really should come up with an asm version for ia64 of the > missing > function ;) > > Cheers, > > Auke > > --- > > e1000: include for IA64 > > IA64 does not have an optimized asm version for ipv6 csum magic. Fall > back to generic implementation. > > Signed-off-by: Auke Kok <[EMAIL PROTECTED]> > > diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h > index f091042..26e7506 100644 > --- a/drivers/net/e1000/e1000.h > +++ b/drivers/net/e1000/e1000.h > @@ -61,6 +61,7 @@ > #include > #ifdef NETIF_F_TSO6 > #include > +#include > #endif > #include > #include It is noxious of e1000 to do a #include from its driver-wide header file and I refused to be a party to such a thing! Jeff probably won't be able to apply this because, like your other patches, it is space-stuffed. Then again, maybe git understands format=flowed, dunno. - 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.6.19-rc1: Volanomark slowdown
On Wed, 2006-11-08 at 17:29 +0100, Olaf Kirch wrote: > Is it proven that the number of ACKs actually cause bandwidth problems? > I found Volanomark to exercise the scheduler more than anything else, > so maybe the slowdown, while triggered by an increased number of ACKs, > is caused by something else entirely. > The patch in question affects purely TCP and not the scheduler. I don't think the scheduler has anything to do with the slowdown seen after the patch is applied. The total number of messages being exchanged around the chatrooms in Volanomark remain unchanged. But ACKS increase by 3.5 times and segments received increase by 38% from netstat. ACK is comparable in size to the actual Volanomark messages as those are pretty small (<100 byte). So I think it is reasonable to conclude that the increase in TCP traffic reduce the bandwidth and throughput in Volanomark. However, Volanomark is just a benchmark to alert us to changes. If in real applications with small segment, this patch is needed to fix congestion window adjustment as Dave pointed out, and impact on bandwidth not as important, so be it. Tim - 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: New laptop - problems with linux
Francois Romieu wrote: Stephen Clark <[EMAIL PROTECTED]> : [...] No it is not loaded - i did a modprobe on it and it loaded but still no ethx device. Send complete 'dmesg' and 'lspci -vvx' (please Cc: netdev@vger.kernel.org) lspci and dmesg attached below: Thanks, anything else I can do please let me know. 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Capabilities: [e0] Vendor Specific Information 00: 86 80 a0 27 06 00 90 20 03 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 a0 27 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA]) Subsystem: ASUSTeK Computer Inc. Unknown device 1252 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Interrupt: pin A routed to IRQ 169 Region 0: Memory at feb8 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at ec00 [size=8] Region 2: Memory at d000 (32-bit, prefetchable) [size=256M] Region 3: Memory at feb4 (32-bit, non-prefetchable) [size=256K] Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Address: Data: Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 86 80 a2 27 07 00 90 00 03 00 00 03 00 00 80 00 10: 00 00 b8 fe 01 ec 00 00 08 00 00 d0 00 00 b4 fe 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 52 12 30: 00 00 00 00 90 00 00 00 00 00 00 00 05 01 00 00 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) Subsystem: ASUSTeK Computer Inc. Unknown device 1252 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Region 0: Memory at fea8 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 86 80 a6 27 07 00 90 00 03 00 80 03 00 00 80 00 10: 00 00 a8 fe 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 52 12 30: 00 00 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 1343 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 169 Region 0: Memory at feb38000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: Data: Capabilities: [70] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed unknown, Width x0 00: 86 80 d8 27 06 00 10 00 02 00 03 04 08 00 00 00 10: 04 80 b3 fe 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 43 13 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 01 00 00 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
Re: 2.6.19-rc1: Volanomark slowdown
> However, Volanomark is just a benchmark to alert us to changes. > If in real applications with small segment, this patch is > needed to fix congestion window adjustment as Dave pointed > out, and impact on bandwidth not as important, so be it. > > Tim if we can get the best of both worlds (by having the extra acks drop on congestion) it's of course nicer ;) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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: New laptop - problems with linux
On Wed, 08 Nov 2006 14:39:53 -0500 Stephen Clark <[EMAIL PROTECTED]> wrote: > Francois Romieu wrote: > > >Stephen Clark <[EMAIL PROTECTED]> : > >[...] > > > > > >>No it is not loaded - i did a modprobe on it and it loaded but still no > >>ethx device. > >> > >> > > > >Send complete 'dmesg' and 'lspci -vvx' (please Cc: netdev@vger.kernel.org) > > > > > > > lspci and dmesg attached below: > Thanks, anything else I can do please let me know. > 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG > Network Connection (rev 02) > Subsystem: Intel Corporation Unknown device 1000 > Use the ipw3945 driver and binary regulatory daemon from: http://ipw3945.sourceforge.net/#downloads > 05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169SC > Gigabit Ethernet (rev 10) > Subsystem: ASUSTeK Computer Inc. Unknown device 1345 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes > Interrupt: pin A routed to IRQ 11 > Region 0: I/O ports at d800 [size=256] > Region 1: Memory at fe8ffc00 (32-bit, non-prefetchable) [size=256] > Expansion ROM at 8000 [disabled] [size=128K] > Capabilities: [dc] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA > PME(D0-,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 00: ec 10 67 81 17 00 b0 02 10 00 00 02 08 40 00 00 > 10: 01 d8 00 00 00 fc 8f fe 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 45 13 > 30: 00 00 8c fe dc 00 00 00 00 00 00 00 0b 01 20 40 > This PCI ID was added to 2.6.19. You should run 2.6.19-rc5 or backport the changes. - 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: New laptop - problems with linux
On 08/11/06, Stephen Clark <[EMAIL PROTECTED]> wrote: Stephen Hemminger wrote: >On Wed, 08 Nov 2006 14:39:53 -0500 >Stephen Clark <[EMAIL PROTECTED]> wrote: > > >>03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG >>Network Connection (rev 02) >>Subsystem: Intel Corporation Unknown device 1000 >> >> >> > >Use the ipw3945 driver and binary regulatory daemon from: > http://ipw3945.sourceforge.net/#downloads > > Thanks I have that working - I am now struggling with the disk being slower than molasses ( high priority, 1.xx mb/sec ) and the integrated realtek ethernet ( low prioirty - since I got the wifi working ). As Stephen Hemminger wrote, getting your realtek card working should be a simple matter of either backporting the recent change that adds its PCI ID or simply run a 2.6.19-rc5 kernel that includes it. >>05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169SC >>Gigabit Ethernet (rev 10) >>Subsystem: ASUSTeK Computer Inc. Unknown device 1345 >>Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- >>ParErr- Stepping- SERR- FastB2B- >>Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- >>SERR- >Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes >>Interrupt: pin A routed to IRQ 11 >>Region 0: I/O ports at d800 [size=256] >>Region 1: Memory at fe8ffc00 (32-bit, non-prefetchable) [size=256] >>Expansion ROM at 8000 [disabled] [size=128K] >>Capabilities: [dc] Power Management version 2 >>Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA >>PME(D0-,D1+,D2+,D3hot+,D3cold+) >>Status: D0 PME-Enable- DSel=0 DScale=0 PME- >>00: ec 10 67 81 17 00 b0 02 10 00 00 02 08 40 00 00 >>10: 01 d8 00 00 00 fc 8f fe 00 00 00 00 00 00 00 00 >>20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 45 13 >>30: 00 00 8c fe dc 00 00 00 00 00 00 00 0b 01 20 40 >> >> >> > >This PCI ID was added to 2.6.19. You should run 2.6.19-rc5 or backport the changes. > -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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: New laptop - problems with linux
Jesper Juhl wrote: On 08/11/06, Stephen Clark <[EMAIL PROTECTED]> wrote: Stephen Hemminger wrote: On Wed, 08 Nov 2006 14:39:53 -0500 Stephen Clark <[EMAIL PROTECTED]> wrote: 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) Subsystem: Intel Corporation Unknown device 1000 Use the ipw3945 driver and binary regulatory daemon from: http://ipw3945.sourceforge.net/#downloads Thanks I have that working - I am now struggling with the disk being slower than molasses ( high priority, 1.xx mb/sec ) and the integrated realtek ethernet ( low prioirty - since I got the wifi working ). As Stephen Hemminger wrote, getting your realtek card working should be a simple matter of either backporting the recent change that adds its PCI ID or simply run a 2.6.19-rc5 kernel that includes it. Thanks Jesper. - I might do that - but I have to get the disk working the 1.xx mb/sec on my core 2 duo t5600 is killing me. I also want to thank everyone on this list for being so helpful. Steve 05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169SC Gigabit Ethernet (rev 10) Subsystem: ASUSTeK Computer Inc. Unknown device 1345 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- This PCI ID was added to 2.6.19. You should run 2.6.19-rc5 or backport the changes. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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
[RFC] d80211 naming convention
The discussion on another thread about ieee80211_local brought to mind a discussion from a while ago about shortening the prefix 'ieee80211' used in structures, defines, variables, function names, etc. Are people still interested in changing that name to something else? Would switching from using the ieee prefix to just d work? (d80211 vs. ieee80211)? Or perhaps dropping all the way to dot11 (save 4 characters)? I put together the script convert-to-d80211.sh to switch everything in-tree from using d80211's ieee80211 prefix to use d80211. The script, when run, results in a 22.8kl patch changing 61 files. Switching to dot11 can be achieved by running convert-to-d80211.sh and then running convert-to-dot11.sh. The cumulative patch size by running the two scripts is 24.3kl changing 78 files. The scripts assume you have git/cogito installed (they cg-rm and cg-add to migrate the files to use the new names) Cogito complains about files not existing when being removed since they have already been moved on disk to the dot11 directories. Git catches the file/directory renames and retains the history the files moving. I ran the scripts and performed a test build against the wireless subsystem and all wireless drivers and all continued to build. I haven't done any run-time testing. Anyway, if no one ever wants to change the names, no biggie. If it is something people are thinking about maybe doing, the scripts should make that change trivial. Personally I prefer the way things lay out after running both scripts; its nice to have more of the 80 column width for things other than the subsystem prefix :) Its also nice having the subsystem name match the prefix used. James convert-to-d80211.sh Description: application/shellscript convert-to-dot11.sh Description: application/shellscript
RE: [PATCH 3/3] mlsxfrm: Various fixes
On Wed, 2006-11-08 at 13:17 -0600, Venkat Yekkirala wrote: > > > > Not sure > > > > though when > > > > that would apply here, > > > > > > It could apply to xfrms if they happen to be using the context > > > represented by any of the initial SIDs. > > > > Which would happen when? > > If one were attempting to use a context pertaining to the unlabeled init > sid in the SPD and/or the SAD. But would I be correct in assuming that the > same sid (unlabeled init sid in all likelyhood) would end up being returned > when the context is turned into a sid, resulting in the SPD and the SAD > using > the same init sid, thus making a full-context compare unnecessary? Yes. > > What's the harm from just using the SID comparison and > > allowing for the > > possibility that there might be a few duplicates in rare > > circumstances? > > Does it break any assumptions in the rest of the logic? > > The best I can think of is if the SA's sid doesn't match the > socket's SID, IKE would come into play, if it's configured. > > I also wanted to conversely ask what harm exists if we did > a full-context compare in the event the sids didn't match? > > Are we just trying to generally avoid extra code? More complexity and overhead for no real gain. -- Stephen Smalley National Security Agency - 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] glibc: getaddrinfo() dest. addr. selection bugfix
While testing the default address selection support in linux, i found
some issues in the getaddrinfo() implementation of Rule 3 and Rule 7
in the destination address selection process as described in RFC3484.
Rule 3: Avoid deprecated addresses.
---
This one turned out to be a bug in getaddrinfo() routine while looking
for a matching address in the deprecated/temporary address list.
Instead of searching for the source address, the current code uses the
dest. address. The following patch fixes this issue.
=
diff --git a/sysdeps/posix/getaddrinfo.c b/sysdeps/posix/getaddrinfo.c
--- a/sysdeps/posix/getaddrinfo.c
+++ b/sysdeps/posix/getaddrinfo.c
@@ -2085,10 +2085,12 @@ #endif
if (q->ai_family == PF_INET6 && in6ai != NULL)
{
- /* See whether the address is the list of deprecated
-or temporary addresses. */
+ /* See whether the source address is in the list of
+deprecated or temporary addresses. */
struct in6addrinfo tmp;
- memcpy (tmp.addr, q->ai_addr, IN6ADDRSZ);
+ struct sockaddr_in6 *sin6p =
+ (struct sockaddr_in6 *)&results[i].source_addr;
+ memcpy (tmp.addr, &sin6p->sin6_addr, IN6ADDRSZ);
struct in6addrinfo *found
= bsearch (&tmp, in6ai, in6ailen, sizeof (*in6ai),
Rule 7: Prefer native transport.
I don't think checking for IFA_F_TEMPORARY flag is the right thing to do
to figure out if we are using a tunnel transport. The temporary flag is
used to support privacy extensions for stateless address autoconfiguration.
Instead, i think we need a way to determine if a source address belongs
to a configured tunnel link sit. Currently, the kernel doesn't provide a
flag to indicate that an address belongs to a tunnel interface. We could
add a new IFA_F_TUNNEL flag, but it requires kernel changes.
The other option is to get the interface type associated with the address.
Is there a convenient way to get device type associated with a particular
address in the getaddrinfo code path?
Which option is preferable?
Thanks
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
why do we mangle checksums for v6 ICMP?
AFAICS, the rules are: (1) checksum is 16-bit one's complement of the one's complement sum of relevant 16bit words. (2) for v4 UDP all-zeroes has special meaning - no checksum; if you get it from (1), send all-ones instead. (3) for v6 UDP we have the same remapping as in (2), but all-zeroes has different meaning - not "ignore checksum" as in v4, but "reject the packet". (4) there is no (4). IOW, nobody except UDP has any business doing that 0->0x replacement. However, we have if (icmp6h->icmp6_cksum == 0) icmp6h->icmp6_cksum = -1; and similar in net/ipv6/raw.c AFAICS, both went in with (commit ID by linux-hist repository) commit 6bac90985c8b65ffc25839c001aa7ef4831d2915 Author: Kazunori Miyazawa <[EMAIL PROTECTED]> Date: Mon May 12 00:21:19 2003 -0700 [IPV4]: Introduce ip6_append_data. That changeset has very similar changes done in udp.c, icmp.c and raw.c; remapping of UDP checksum used to be in the area affected by the changeset and it looks like it got not just preserved in udp.c (as it should), but copied to icmp.c and raw.c instances. So... is it really needed 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
HTB warnings
Hi all, I use sabishape[1] to shape my traffic that I would normally do, sabishape -i eth1 -u 40 -d 240 for my 256/64 ADSL line , but recently in dmesg I got following warnings: HTB: quantum of class 10031 is small. Consider r2q change. HTB: quantum of class 10032 is small. Consider r2q change. HTB: quantum of class 10033 is small. Consider r2q change. I thought sabishape might be buggy but wondershaper from LARTC gives the same warnings. So I wonder if anyone have any ideas? [1] http://sabi.co.uk/Proj/Small/sabishape-2.1.tar.gz Regards, ismail - 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: why do we mangle checksums for v6 ICMP?
On Wed, Nov 08, 2006 at 10:13:32PM +, Al Viro wrote: > AFAICS, the rules are: > > (1) checksum is 16-bit one's complement of the one's complement sum of > relevant 16bit words. > > (2) for v4 UDP all-zeroes has special meaning - no checksum; if you get > it from (1), send all-ones instead. > > (3) for v6 UDP we have the same remapping as in (2), but all-zeroes has > different meaning - not "ignore checksum" as in v4, but "reject the > packet". > > (4) there is no (4). > > IOW, nobody except UDP has any business doing that 0->0x > replacement. However, we have >if (icmp6h->icmp6_cksum == 0) >icmp6h->icmp6_cksum = -1; > and similar in net/ipv6/raw.c > > AFAICS, both went in with (commit ID by linux-hist repository) > commit 6bac90985c8b65ffc25839c001aa7ef4831d2915 > Author: Kazunori Miyazawa <[EMAIL PROTECTED]> > Date: Mon May 12 00:21:19 2003 -0700 > > [IPV4]: Introduce ip6_append_data. > > That changeset has very similar changes done in udp.c, icmp.c and raw.c; > remapping of UDP checksum used to be in the area affected by the changeset > and it looks like it got not just preserved in udp.c (as it should), but > copied to icmp.c and raw.c instances. > > So... is it really needed there? While we are at it, shouldn't ip_nat_mangle_udp_packet() do the same remapping in } else udph->check = nf_proto_csum_update(*pskb, htons(oldlen) ^ htons(0x), htons(datalen), udph->check, 1); branch? Note that udp_manip_pkt() does it in the same situation... - 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/3] labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]
This patchset is against davem's net-2.6.git. Please apply to 2.6.19. The following are the changes since the previous post of this patchset: 1. Separate BUG_ON usage per Eric's suggestion. 2. Replace security_sid_compare with a simple sid compare check per a suggestion from Paul/Stephen. - 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/3] labeled-ipsec: Fix SA selection semantics
Fix the selection of an SA for an outgoing packet to be at the same
context as the originating socket/flow. This eliminates the SELinux
policy's ability to use/sendto SAs with contexts other than the socket's.
With this patch applied, the SELinux policy will require one or more of the
following for a socket to be able to communicate with/without SAs:
1. To enable a socket to communicate without using labeled-IPSec SAs:
allow socket_t unlabeled_t:association { sendto recvfrom }
2. To enable a socket to communicate with labeled-IPSec SAs:
allow socket_t self:association { sendto };
allow socket_t peer_sa_t:association { recvfrom };
Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
---
include/linux/security.h| 19 -
net/xfrm/xfrm_policy.c |3
security/dummy.c|7 --
security/selinux/hooks.c| 26 +--
security/selinux/include/xfrm.h |7 --
security/selinux/xfrm.c | 101 ++
6 files changed, 70 insertions(+), 93 deletions(-)
--- net-2.6.lx2/include/linux/security.h2006-11-08 09:47:42.0
-0600
+++ net-2.6/include/linux/security.h2006-11-08 16:36:32.0 -0600
@@ -886,11 +886,6 @@ struct request_sock;
* @xp contains the policy to check for a match.
* @fl contains the flow to check for a match.
* Return 1 if there is a match.
- * @xfrm_flow_state_match:
- * @fl contains the flow key to match.
- * @xfrm points to the xfrm_state to match.
- * @xp points to the xfrm_policy to match.
- * Return 1 if there is a match.
* @xfrm_decode_session:
* @skb points to skb to decode.
* @secid points to the flow key secid to set.
@@ -1388,8 +1383,6 @@ struct security_operations {
int (*xfrm_policy_lookup)(struct xfrm_policy *xp, u32 fl_secid, u8 dir);
int (*xfrm_state_pol_flow_match)(struct xfrm_state *x,
struct xfrm_policy *xp, struct flowi *fl);
- int (*xfrm_flow_state_match)(struct flowi *fl, struct xfrm_state *xfrm,
- struct xfrm_policy *xp);
int (*xfrm_decode_session)(struct sk_buff *skb, u32 *secid, int ckall);
#endif /* CONFIG_SECURITY_NETWORK_XFRM */
@@ -3186,12 +3179,6 @@ static inline int security_xfrm_state_po
return security_ops->xfrm_state_pol_flow_match(x, xp, fl);
}
-static inline int security_xfrm_flow_state_match(struct flowi *fl,
- struct xfrm_state *xfrm, struct xfrm_policy *xp)
-{
- return security_ops->xfrm_flow_state_match(fl, xfrm, xp);
-}
-
static inline int security_xfrm_decode_session(struct sk_buff *skb, u32 *secid)
{
return security_ops->xfrm_decode_session(skb, secid, 1);
@@ -3255,12 +3242,6 @@ static inline int security_xfrm_state_po
return 1;
}
-static inline int security_xfrm_flow_state_match(struct flowi *fl,
- struct xfrm_state *xfrm, struct xfrm_policy *xp)
-{
- return 1;
-}
-
static inline int security_xfrm_decode_session(struct sk_buff *skb, u32 *secid)
{
return 0;
--- net-2.6.lx2/net/xfrm/xfrm_policy.c 2006-11-08 09:38:02.0 -0600
+++ net-2.6/net/xfrm/xfrm_policy.c 2006-11-08 16:36:32.0 -0600
@@ -1894,7 +1894,8 @@ int xfrm_bundle_ok(struct xfrm_policy *p
if (fl && !xfrm_selector_match(&dst->xfrm->sel, fl, family))
return 0;
- if (fl && !security_xfrm_flow_state_match(fl, dst->xfrm, pol))
+ if (fl && pol &&
+ !security_xfrm_state_pol_flow_match(dst->xfrm, pol, fl))
return 0;
if (dst->xfrm->km.state != XFRM_STATE_VALID)
return 0;
--- net-2.6.lx2/security/dummy.c2006-11-08 09:47:42.0 -0600
+++ net-2.6/security/dummy.c2006-11-08 16:36:32.0 -0600
@@ -886,12 +886,6 @@ static int dummy_xfrm_state_pol_flow_mat
return 1;
}
-static int dummy_xfrm_flow_state_match(struct flowi *fl, struct xfrm_state
*xfrm,
- struct xfrm_policy *xp)
-{
- return 1;
-}
-
static int dummy_xfrm_decode_session(struct sk_buff *skb, u32 *fl, int ckall)
{
return 0;
@@ -1126,7 +1120,6 @@ void security_fixup_ops (struct security
set_to_dummy_if_null(ops, xfrm_state_delete_security);
set_to_dummy_if_null(ops, xfrm_policy_lookup);
set_to_dummy_if_null(ops, xfrm_state_pol_flow_match);
- set_to_dummy_if_null(ops, xfrm_flow_state_match);
set_to_dummy_if_null(ops, xfrm_decode_session);
#endif /* CONFIG_SECURITY_NETWORK_XFRM */
#ifdef CONFIG_KEYS
--- net-2.6.lx2/security/selinux/include/xfrm.h 2006-11-08 09:47:42.0
-0600
+++ net-2.6/security/selinux/include/xfrm.h 2006-11-08 16:36:32.0
-0600
@@ -19,9 +19,6 @@ int selinux_xfrm_state_delete(struct xfr
int selinux_xfrm_policy_lookup(struct xfrm_policy *xp, u32 fl_secid, u8 dir);
int selinux_xfrm_state_pol_flow_match(stru
[PATCH 2/3] labeled-ipsec: Return correct context for SO_PEERSEC
Fix SO_PEERSEC for tcp sockets to return the security context of
the peer (as represented by the SA from the peer) as opposed to the
SA used by the local/source socket.
Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
---
include/linux/security.h| 14 ++
include/net/request_sock.h |1
net/ipv4/tcp_input.c|2 +
security/dummy.c|6
security/selinux/hooks.c| 21 ---
security/selinux/include/xfrm.h | 12 -
security/selinux/xfrm.c | 40 ++
7 files changed, 49 insertions(+), 47 deletions(-)
--- net-2.6.lx1/include/linux/security.h2006-11-08 09:40:42.0
-0600
+++ net-2.6/include/linux/security.h2006-11-08 09:47:42.0 -0600
@@ -826,6 +826,8 @@ struct request_sock;
* Sets the openreq's sid to socket's sid with MLS portion taken from peer
sid.
* @inet_csk_clone:
* Sets the new child socket's sid to the openreq sid.
+ * @inet_conn_established:
+ * Sets the connection's peersid to the secmark on skb.
* @req_classify_flow:
* Sets the flow's sid to the openreq sid.
*
@@ -1368,6 +1370,7 @@ struct security_operations {
int (*inet_conn_request)(struct sock *sk, struct sk_buff *skb,
struct request_sock *req);
void (*inet_csk_clone)(struct sock *newsk, const struct request_sock
*req);
+ void (*inet_conn_established)(struct sock *sk, struct sk_buff *skb);
void (*req_classify_flow)(const struct request_sock *req, struct flowi
*fl);
#endif /* CONFIG_SECURITY_NETWORK */
@@ -2961,6 +2964,12 @@ static inline void security_inet_csk_clo
{
security_ops->inet_csk_clone(newsk, req);
}
+
+static inline void security_inet_conn_established(struct sock *sk,
+ struct sk_buff *skb)
+{
+ security_ops->inet_conn_established(sk, skb);
+}
#else /* CONFIG_SECURITY_NETWORK */
static inline int security_unix_stream_connect(struct socket * sock,
struct socket * other,
@@ -3110,6 +3119,11 @@ static inline void security_inet_csk_clo
const struct request_sock *req)
{
}
+
+static inline void security_inet_conn_established(struct sock *sk,
+ struct sk_buff *skb)
+{
+}
#endif /* CONFIG_SECURITY_NETWORK */
#ifdef CONFIG_SECURITY_NETWORK_XFRM
--- net-2.6.lx1/include/net/request_sock.h 2006-11-08 09:38:06.0
-0600
+++ net-2.6/include/net/request_sock.h 2006-11-08 09:47:42.0 -0600
@@ -54,6 +54,7 @@ struct request_sock {
struct request_sock_ops *rsk_ops;
struct sock *sk;
u32 secid;
+ u32 peer_secid;
};
static inline struct request_sock *reqsk_alloc(struct request_sock_ops *ops)
--- net-2.6.lx1/net/ipv4/tcp_input.c2006-11-08 09:38:06.0 -0600
+++ net-2.6/net/ipv4/tcp_input.c2006-11-08 09:47:42.0 -0600
@@ -4230,6 +4230,8 @@ static int tcp_rcv_synsent_state_process
mb();
tcp_set_state(sk, TCP_ESTABLISHED);
+ security_inet_conn_established(sk, skb);
+
/* Make sure socket is routed, for correct metrics. */
icsk->icsk_af_ops->rebuild_header(sk);
--- net-2.6.lx1/security/dummy.c2006-11-08 09:40:42.0 -0600
+++ net-2.6/security/dummy.c2006-11-08 09:47:42.0 -0600
@@ -828,6 +828,11 @@ static inline void dummy_inet_csk_clone(
{
}
+static inline void dummy_inet_conn_established(struct sock *sk,
+ struct sk_buff *skb)
+{
+}
+
static inline void dummy_req_classify_flow(const struct request_sock *req,
struct flowi *fl)
{
@@ -1108,6 +1113,7 @@ void security_fixup_ops (struct security
set_to_dummy_if_null(ops, sock_graft);
set_to_dummy_if_null(ops, inet_conn_request);
set_to_dummy_if_null(ops, inet_csk_clone);
+ set_to_dummy_if_null(ops, inet_conn_established);
set_to_dummy_if_null(ops, req_classify_flow);
#endif/* CONFIG_SECURITY_NETWORK */
#ifdef CONFIG_SECURITY_NETWORK_XFRM
--- net-2.6.lx1/security/selinux/include/xfrm.h 2006-11-08 09:40:42.0
-0600
+++ net-2.6/security/selinux/include/xfrm.h 2006-11-08 09:47:42.0
-0600
@@ -39,7 +39,6 @@ int selinux_xfrm_sock_rcv_skb(u32 sid, s
struct avc_audit_data *ad);
int selinux_xfrm_postroute_last(u32 isec_sid, struct sk_buff *skb,
struct avc_audit_data *ad);
-u32 selinux_socket_getpeer_stream(struct sock *sk);
u32 selinux_socket_getpeer_dgram(struct sk_buff *skb);
int selinux_xfrm_decode_session(struct sk_buff *skb, u32 *sid, int ckall);
#else
@@ -55,11 +54,6 @@ static inline int selinux_xfrm_postroute
return 0;
}
-static inline int selinux_socket_getpeer_stream(struct s
[PATCH 1/3] labeled-ipsec: Various fixes
Since the upstreaming of the mlsxfrm modification a few months back,
testing has resulted in the identification of the following issues/bugs that
are resolved in this patch set.
1. Fix the security context used in the IKE negotiation to be the context
of the socket as opposed to the context of the SPD rule.
2. Fix SO_PEERSEC for tcp sockets to return the security context of
the peer as opposed to the source.
3. Fix the selection of an SA for an outgoing packet to be at the same
context as the originating socket/flow.
The following would be the result of applying this patchset:
- SO_PEERSEC will now correctly return the peer's context.
- IKE deamons will receive the context of the source socket/flow
as opposed to the SPD rule's context so that the negotiated SA
will be at the same context as the source socket/flow.
- The SELinux policy will require one or more of the
following for a socket to be able to communicate with/without SAs:
1. To enable a socket to communicate without using labeled-IPSec SAs:
allow socket_t unlabeled_t:association { sendto recvfrom }
2. To enable a socket to communicate with labeled-IPSec SAs:
allow socket_t self:association { sendto };
allow socket_t peer_sa_t:association { recvfrom };
This Patch: Pass correct security context to IKE for use in negotiation
Fix the security context passed to IKE for use in negotiation to be the
context of the socket as opposed to the context of the SPD rule so that
the SA carries the label of the originating socket/flow.
Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
---
include/linux/security.h| 21 --
security/dummy.c|4 +--
security/selinux/include/xfrm.h |4 +--
security/selinux/xfrm.c | 35 +++---
4 files changed, 23 insertions(+), 41 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index b200b98..a509329 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -836,10 +836,8 @@ #ifdef CONFIG_SECURITY
* used by the XFRM system.
* @sec_ctx contains the security context information being provided by
* the user-level policy update program (e.g., setkey).
- * @sk refers to the sock from which to derive the security context.
* Allocate a security structure to the xp->security field; the security
- * field is initialized to NULL when the xfrm_policy is allocated. Only
- * one of sec_ctx or sock can be specified.
+ * field is initialized to NULL when the xfrm_policy is allocated.
* Return 0 if operation was successful (memory to allocate, legal context)
* @xfrm_policy_clone_security:
* @old contains an existing xfrm_policy in the SPD.
@@ -858,9 +856,6 @@ #ifdef CONFIG_SECURITY
* Database by the XFRM system.
* @sec_ctx contains the security context information being provided by
* the user-level SA generation program (e.g., setkey or racoon).
- * @polsec contains the security context information associated with a xfrm
- * policy rule from which to take the base context. polsec must be NULL
- * when sec_ctx is specified.
* @secid contains the secid from which to take the mls portion of the
context.
* Allocate a security structure to the x->security field; the security
* field is initialized to NULL when the xfrm_state is allocated. Set the
@@ -1378,12 +1373,12 @@ #endif /* CONFIG_SECURITY_NETWORK */
#ifdef CONFIG_SECURITY_NETWORK_XFRM
int (*xfrm_policy_alloc_security) (struct xfrm_policy *xp,
- struct xfrm_user_sec_ctx *sec_ctx, struct sock *sk);
+ struct xfrm_user_sec_ctx *sec_ctx);
int (*xfrm_policy_clone_security) (struct xfrm_policy *old, struct
xfrm_policy *new);
void (*xfrm_policy_free_security) (struct xfrm_policy *xp);
int (*xfrm_policy_delete_security) (struct xfrm_policy *xp);
int (*xfrm_state_alloc_security) (struct xfrm_state *x,
- struct xfrm_user_sec_ctx *sec_ctx, struct xfrm_sec_ctx *polsec,
+ struct xfrm_user_sec_ctx *sec_ctx,
u32 secid);
void (*xfrm_state_free_security) (struct xfrm_state *x);
int (*xfrm_state_delete_security) (struct xfrm_state *x);
@@ -3120,7 +3115,7 @@ #endif/* CONFIG_SECURITY_NETWORK */
#ifdef CONFIG_SECURITY_NETWORK_XFRM
static inline int security_xfrm_policy_alloc(struct xfrm_policy *xp, struct
xfrm_user_sec_ctx *sec_ctx)
{
- return security_ops->xfrm_policy_alloc_security(xp, sec_ctx, NULL);
+ return security_ops->xfrm_policy_alloc_security(xp, sec_ctx);
}
static inline int security_xfrm_policy_clone(struct xfrm_policy *old, struct
xfrm_policy *new)
@@ -3141,7 +3136,7 @@ static inline int security_xfrm_policy_d
static inline int security_xfrm_state_alloc(struct xfrm_state *x,
struct xfrm_user_sec_ctx *sec_ctx)
{
- return security
Re: [take23 0/5] kevent: Generic event handling mechanism.
On Wed, 8 Nov 2006 15:51:13 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote: > [PATCH] eventpoll : In case a fault occurs during copy_to_user(), we should > report the count of events that were successfully copied into user space, > instead of EFAULT. That would be consistent with behavior of read/write() > syscalls for example. > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> > > > > [eventpoll.patch text/plain (424B)] > --- linux/fs/eventpoll.c 2006-11-08 15:37:36.0 +0100 > +++ linux/fs/eventpoll.c 2006-11-08 15:38:31.0 +0100 > @@ -1447,7 +1447,7 @@ > &events[eventcnt].events) || > __put_user(epi->event.data, > &events[eventcnt].data)) > - return -EFAULT; > + return eventcnt ? eventcnt : -EFAULT; > if (epi->event.events & EPOLLONESHOT) > epi->event.events &= EP_PRIVATE_BITS; > eventcnt++; > Definitely a better interface, but I wonder if it's too late to change it. An app which does if (epoll_wait(...) == -1) barf(errno); else assume_all_events_were_received(); will now do the wrong thing. otoh, such an applciation basically _has_ to use the epoll_wait() return value to work out how many events it received, so maybe it's OK... - 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.6.19-rc1: Volanomark slowdown
On Wed, Nov 08, 2006 at 10:38:52AM -0800, Tim Chen wrote: > The patch in question affects purely TCP and not the scheduler. I don't I know. > think the scheduler has anything to do with the slowdown seen after > the patch is applied. In fixing performance issues, the most obvious explanation isn't always the right one. It's quite possible you're right, sure. What I'm saying though is that it doesn't rhyme with what I've seen of Volanomark - we ran 2.6.16 on a 4p Intel box for instance and it didn't come close to saturating a Gigabit pipe before it maxed out on CPU load. > The total number of messages being exchanged around the chatrooms in > Volanomark remain unchanged. But ACKS increase by 3.5 times and > segments received increase by 38% from netstat. > So I think it is reasonable to conclude that the increase in TCP traffic > reduce the bandwidth and throughput in Volanomark. You could count the number of outbound packets dropped on the server. Olaf -- Walks like a duck. Quacks like a duck. Must be a chicken. - 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: [take23 0/5] kevent: Generic event handling mechanism.
On Wed, 8 Nov 2006, Andrew Morton wrote: > On Wed, 8 Nov 2006 15:51:13 +0100 > Eric Dumazet <[EMAIL PROTECTED]> wrote: > > > [PATCH] eventpoll : In case a fault occurs during copy_to_user(), we should > > report the count of events that were successfully copied into user space, > > instead of EFAULT. That would be consistent with behavior of read/write() > > syscalls for example. > > > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> > > > > > > > > [eventpoll.patch text/plain (424B)] > > --- linux/fs/eventpoll.c2006-11-08 15:37:36.0 +0100 > > +++ linux/fs/eventpoll.c2006-11-08 15:38:31.0 +0100 > > @@ -1447,7 +1447,7 @@ > >&events[eventcnt].events) || > > __put_user(epi->event.data, > >&events[eventcnt].data)) > > - return -EFAULT; > > + return eventcnt ? eventcnt : -EFAULT; > > if (epi->event.events & EPOLLONESHOT) > > epi->event.events &= EP_PRIVATE_BITS; > > eventcnt++; > > > > Definitely a better interface, but I wonder if it's too late to change it. > > An app which does > > if (epoll_wait(...) == -1) > barf(errno); > else > assume_all_events_were_received(); > > will now do the wrong thing. > > otoh, such an applciation basically _has_ to use the epoll_wait() > return value to work out how many events it received, so maybe it's OK... I don't care about both ways, but sys_poll() does the same thing epoll does right now, so I would not change epoll behaviour. - Davide - 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.6.19-rc1: Volanomark slowdown
On Wed, 2006-11-08 at 23:10 +0100, Olaf Kirch wrote: > > In fixing performance issues, the most obvious explanation isn't always > the right one. It's quite possible you're right, sure. > > What I'm saying though is that it doesn't rhyme with what I've seen of > Volanomark - we ran 2.6.16 on a 4p Intel box for instance and it didn't > come close to saturating a Gigabit pipe before it maxed out on CPU load. > I am running Volanomark in a loopback mode on a 2P woodcrest box (4 cores). So the configuration is a bit different. In my testing, the CPU utilization is at 100%. So increase in ACKs will cost CPU to devote more time to process those ACKs and reduce throughput. > > You could count the number of outbound packets dropped on the server. > As I'm running in loopback mode, there are no dropped packets. Thanks. Tim - 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.6.19-rc1: Volanomark slowdown
On Wed, 08 Nov 2006 14:07:32 -0800 Tim Chen <[EMAIL PROTECTED]> wrote: > On Wed, 2006-11-08 at 23:10 +0100, Olaf Kirch wrote: > > > > > In fixing performance issues, the most obvious explanation isn't always > > the right one. It's quite possible you're right, sure. > > > > What I'm saying though is that it doesn't rhyme with what I've seen of > > Volanomark - we ran 2.6.16 on a 4p Intel box for instance and it didn't > > come close to saturating a Gigabit pipe before it maxed out on CPU load. > > > > I am running Volanomark in a loopback mode on a 2P woodcrest box > (4 cores). So the configuration is a bit different. > > In my testing, the CPU utilization is at 100%. So > increase in ACKs will cost CPU to devote more > time to process those ACKs and reduce throughput. > > > > > You could count the number of outbound packets dropped on the server. > > > > As I'm running in loopback mode, there are no dropped packets. > Optimizing for loopback is perversion; perversion can be fun but it gets to be a obsession then it's sick. -- Stephen Hemminger <[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: 2.6.19-rc1: Volanomark slowdown
On Wed, 8 Nov 2006 23:10:28 +0100 Olaf Kirch <[EMAIL PROTECTED]> wrote: > On Wed, Nov 08, 2006 at 10:38:52AM -0800, Tim Chen wrote: > > The patch in question affects purely TCP and not the scheduler. I don't > > I know. > > > think the scheduler has anything to do with the slowdown seen after > > the patch is applied. > > In fixing performance issues, the most obvious explanation isn't always > the right one. It's quite possible you're right, sure. > > What I'm saying though is that it doesn't rhyme with what I've seen of > Volanomark - we ran 2.6.16 on a 4p Intel box for instance and it didn't > come close to saturating a Gigabit pipe before it maxed out on CPU load. > > > The total number of messages being exchanged around the chatrooms in > > Volanomark remain unchanged. But ACKS increase by 3.5 times and > > segments received increase by 38% from netstat. > > > So I think it is reasonable to conclude that the increase in TCP traffic > > reduce the bandwidth and throughput in Volanomark. > > You could count the number of outbound packets dropped on the server. > > Olaf Also under benchmark stress, the load can get so high that timers go off that normally don't. For example, I have seen delayed ack timer cause extra ack's when at lower loads the response happened quick enough that the ACK was piggybacked. -- Stephen Hemminger <[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: [take23 0/5] kevent: Generic event handling mechanism.
Davide Libenzi a écrit : On Wed, 8 Nov 2006, Andrew Morton wrote: On Wed, 8 Nov 2006 15:51:13 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote: [PATCH] eventpoll : In case a fault occurs during copy_to_user(), we should report the count of events that were successfully copied into user space, instead of EFAULT. That would be consistent with behavior of read/write() syscalls for example. Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> [eventpoll.patch text/plain (424B)] --- linux/fs/eventpoll.c2006-11-08 15:37:36.0 +0100 +++ linux/fs/eventpoll.c2006-11-08 15:38:31.0 +0100 @@ -1447,7 +1447,7 @@ &events[eventcnt].events) || __put_user(epi->event.data, &events[eventcnt].data)) - return -EFAULT; + return eventcnt ? eventcnt : -EFAULT; if (epi->event.events & EPOLLONESHOT) epi->event.events &= EP_PRIVATE_BITS; eventcnt++; Definitely a better interface, but I wonder if it's too late to change it. An app which does if (epoll_wait(...) == -1) barf(errno); else assume_all_events_were_received(); will now do the wrong thing. otoh, such an applciation basically _has_ to use the epoll_wait() return value to work out how many events it received, so maybe it's OK... I don't care about both ways, but sys_poll() does the same thing epoll does right now, so I would not change epoll behaviour. Sure poll() cannot return a partial count, since its return value is : On success, a positive number is returned, where the number returned is the number of structures which have non-zero revents fields (in other words, those descriptors with events or errors reported). poll() is non destructive (it doesnt change any state into kernel). Returning EFAULT in case of an error in the very last bit of user area is mandatory. On the contrary : epoll_wait() does return a count of transfered events, and update some state in kernel (it consume Edge Trigered events : They can be lost forever if not reported to user) So epoll_wait() is much more like read(), that also updates file state in kernel (current file position) - 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.6.19-rc1: Volanomark slowdown
On Wed, 2006-11-08 at 15:00 -0800, Stephen Hemminger wrote: > > Optimizing for loopback is perversion; perversion can be fun but it gets > to be a obsession then it's sick. > It is not my intention to optimize for this case, but rather to detect change in kernel behavior. That's why in my original mail I ask if increase in ACKs could cause problem for any real application. Tim - 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: [take23 0/5] kevent: Generic event handling mechanism.
On Thu, 9 Nov 2006, Eric Dumazet wrote: > Davide Libenzi a ?crit : > > > > I don't care about both ways, but sys_poll() does the same thing epoll does > > right now, so I would not change epoll behaviour. > > > > Sure poll() cannot return a partial count, since its return value is : > > On success, a positive number is returned, where the number returned is >the number of structures which have non-zero revents fields (in other >words, those descriptors with events or errors reported). > > poll() is non destructive (it doesnt change any state into kernel). Returning > EFAULT in case of an error in the very last bit of user area is mandatory. > > On the contrary : > > epoll_wait() does return a count of transfered events, and update some state > in kernel (it consume Edge Trigered events : They can be lost forever if not > reported to user) > > So epoll_wait() is much more like read(), that also updates file state in > kernel (current file position) Lost forever means? If there are more processes watching some fd (external events), they all get their own copy of the events in their own private epoll fd. It's not that we "steal" things out of the kernel, is not a 1:1 producer/consumer thing (one producer, 1 queue). It's one producer, broadcast to all listeners (consumers) thing. The only case where it'd matter is in the case of multiple threads sharing the same epoll fd. In general, I'd be more for having the userspace get his own SEGFAULT instead of letting it go with broken parameters. If I'm coding userspace, and I'm doing something wrong, I like the kernel to let me know, instead of trying to fix things for me. Also, epoll can easily be fixed (add a param to ep_reinject_items() to re-inject items in case of error/EFAULT) to leave events in the ready-list and let the EFAULT emerge. Anyone else has opinions about this? PS: Next time it'd be great if you Cc: me when posting epoll patches, so you avoid Andrew the job of doing it. - Davide
RE: e1000: include for IA64
Auke Kok wrote on Wednesday, November 08, 2006 9:49 AM > Of course, someone really should come up with an asm version for ia64 of the > missing function ;) Sure, absolutely. Here is an implementation for ia64. Tested heavily. Tony, please merge. - Ken [patch] implement csum_ipv6_magic for ia64. The asm version is 3.4 times faster than the generic version. --- ./arch/ia64/lib/ip_fast_csum.S.orig 2006-11-08 12:26:28.0 -0800 +++ ./arch/ia64/lib/ip_fast_csum.S 2006-11-08 16:39:24.0 -0800 @@ -8,8 +8,8 @@ * in0: address of buffer to checksum (char *) * in1: length of the buffer (int) * - * Copyright (C) 2002 Intel Corp. - * Copyright (C) 2002 Ken Chen <[EMAIL PROTECTED]> + * Copyright (C) 2002, 2006 Intel Corp. + * Copyright (C) 2002, 2006 Ken Chen <[EMAIL PROTECTED]> */ #include @@ -25,6 +25,9 @@ #define in0r32 #define in1r33 +#define in2r34 +#define in3r35 +#define in4r36 #define ret0 r8 GLOBAL_ENTRY(ip_fast_csum) @@ -88,3 +91,51 @@ GLOBAL_ENTRY(ip_fast_csum) mov b0=r34 br.ret.sptk.many b0 END(ip_fast_csum) + +GLOBAL_ENTRY(csum_ipv6_magic) + ld4 r20=[in0],4 + ld4 r21=[in1],4 + dep r15=in2,in3,16,16 + ;; + ld4 r22=[in0],4 + ld4 r23=[in1],4 + mux1r15=r15,@rev + ;; + ld4 r24=[in0],4 + ld4 r25=[in1],4 + shr.u r15=r15,32 + add r16=r20,r21 + add r17=r22,r23 + ;; + ld4 r26=[in0],4 + ld4 r27=[in1],4 + add r18=r24,r25 + add r8=r16,r17 + ;; + add r19=r26,r27 + add r8=r8,r18 + ;; + add r8=r8,r19 + add r15=r15,in4 + ;; + add r8=r8,r15 + ;; + shr.u r10=r8,16 // now fold sum into short + zxt2r11=r8 + ;; + add r8=r10,r11 + ;; + shr.u r10=r8,16 // yeah, keep it rolling + zxt2r11=r8 + ;; + add r8=r10,r11 + ;; + shr.u r10=r8,16 // three times lucky + zxt2r11=r8 + ;; + add r8=r10,r11 + mov r9=0x + ;; + andcm r8=r9,r8 + br.ret.sptk.many b0 +END(csum_ipv6_magic) --- ./include/asm-ia64/checksum.h.orig 2006-11-08 16:52:16.0 -0800 +++ ./include/asm-ia64/checksum.h 2006-11-08 17:01:09.0 -0800 @@ -73,4 +73,10 @@ csum_fold (unsigned int sum) return ~sum; } +#define _HAVE_ARCH_IPV6_CSUM 1 +struct in6_addr; +extern unsigned short int csum_ipv6_magic(struct in6_addr *saddr, + struct in6_addr *daddr, __u32 len, unsigned short proto, + unsigned int csum); + #endif /* _ASM_IA64_CHECKSUM_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: e1000: include for IA64
Chen, Kenneth wrote on Wednesday, November 08, 2006 4:10 PM > Auke Kok wrote on Wednesday, November 08, 2006 9:49 AM > > Of course, someone really should come up with an asm version for ia64 of the > > missing function ;) > > Sure, absolutely. Here is an implementation for ia64. Tested heavily. Tony, > please > merge. Hmm. Forgot about the signed-off line. Here it is: Signed-off-by: Ken Chen <[EMAIL PROTECTED]> [patch] implement csum_ipv6_magic for ia64. The asm version is 3.4 times faster than the generic version. --- ./arch/ia64/lib/ip_fast_csum.S.orig 2006-11-08 12:26:28.0 -0800 +++ ./arch/ia64/lib/ip_fast_csum.S 2006-11-08 16:39:24.0 -0800 @@ -8,8 +8,8 @@ * in0: address of buffer to checksum (char *) * in1: length of the buffer (int) * - * Copyright (C) 2002 Intel Corp. - * Copyright (C) 2002 Ken Chen <[EMAIL PROTECTED]> + * Copyright (C) 2002, 2006 Intel Corp. + * Copyright (C) 2002, 2006 Ken Chen <[EMAIL PROTECTED]> */ #include @@ -25,6 +25,9 @@ #define in0r32 #define in1r33 +#define in2r34 +#define in3r35 +#define in4r36 #define ret0 r8 GLOBAL_ENTRY(ip_fast_csum) @@ -88,3 +91,51 @@ GLOBAL_ENTRY(ip_fast_csum) mov b0=r34 br.ret.sptk.many b0 END(ip_fast_csum) + +GLOBAL_ENTRY(csum_ipv6_magic) + ld4 r20=[in0],4 + ld4 r21=[in1],4 + dep r15=in2,in3,16,16 + ;; + ld4 r22=[in0],4 + ld4 r23=[in1],4 + mux1r15=r15,@rev + ;; + ld4 r24=[in0],4 + ld4 r25=[in1],4 + shr.u r15=r15,32 + add r16=r20,r21 + add r17=r22,r23 + ;; + ld4 r26=[in0],4 + ld4 r27=[in1],4 + add r18=r24,r25 + add r8=r16,r17 + ;; + add r19=r26,r27 + add r8=r8,r18 + ;; + add r8=r8,r19 + add r15=r15,in4 + ;; + add r8=r8,r15 + ;; + shr.u r10=r8,16 // now fold sum into short + zxt2r11=r8 + ;; + add r8=r10,r11 + ;; + shr.u r10=r8,16 // yeah, keep it rolling + zxt2r11=r8 + ;; + add r8=r10,r11 + ;; + shr.u r10=r8,16 // three times lucky + zxt2r11=r8 + ;; + add r8=r10,r11 + mov r9=0x + ;; + andcm r8=r9,r8 + br.ret.sptk.many b0 +END(csum_ipv6_magic) --- ./include/asm-ia64/checksum.h.orig 2006-11-08 16:52:16.0 -0800 +++ ./include/asm-ia64/checksum.h 2006-11-08 17:01:09.0 -0800 @@ -73,4 +73,10 @@ csum_fold (unsigned int sum) return ~sum; } +#define _HAVE_ARCH_IPV6_CSUM 1 +struct in6_addr; +extern unsigned short int csum_ipv6_magic(struct in6_addr *saddr, + struct in6_addr *daddr, __u32 len, unsigned short proto, + unsigned int csum); + #endif /* _ASM_IA64_CHECKSUM_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: e1000 driver 2.6.18 - how to waste processor cycles
included netdev... On 11/8/06, Jeff V. Merkey <[EMAIL PROTECTED]> wrote: Is there a good reason the skb refill routine in e1000_alloc_rx_buffers needs to go and touch and remap skb memory on already loaded descriptors/ This seems extremely wasteful of processor cycles when refilling the ring buffer. I note that the archtiecture has changed and is recycling buffers from the rx_irq routine and when the routine is called to refill the ring buffers, a lot of wasteful and needless calls for map_skb is occurring. we have to unmap the descriptor (or at least do pci_dma_sync_single_for_cpu / pci_dma_sync_single_for_device) because the dma API says we can't be guaranteed the cacheable memory is consistent until we do one of the afore mentioned pci dma ops. we have to do *something* before we access it. Simplest path is to unmap it and then recycle/map it. If you can show that it is faster to use pci_dma_sync_single_for_cpu and friends I'd be glad to take a patch. Hope this helps, Jesse - 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.6.19-rc1: Volanomark slowdown
On Wed, 2006-11-08 at 23:10 +0100, Olaf Kirch wrote: > What I'm saying though is that it doesn't rhyme with what I've seen of > Volanomark - we ran 2.6.16 on a 4p Intel box for instance and it didn't > come close to saturating a Gigabit pipe before it maxed out on CPU load. That actually supports the hypothesis doesn't it? The issue being the increased number of ACKs causing additional CPU overhead not saturating a NIC if any involved. One of these days I may have to try to look more closely at what volano does relative to netperf - I remember that someone tried very hard (was it you alexy?) to show a perfomance effect with netperf and it didn't do it :( rick jones - 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] fix up generic csum_ipv6_magic function prototype
The generic version of csum_ipv6_magic has the len argument declared as
__u16, while most arch dependent version declare it as __u32. After
looking at the call site of this function, I come up to a conclusion
that __u32 is a better match with the actual usage.
Hence, patch to change argument type for greater consistency.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
---
asm-m32r and asm-parisc both have it declared as __u16. I think it is a
copy-n-paste error and needs to be fixed by arch maintainer, I hope.
--- ./include/net/ip6_checksum.h.orig 2006-11-08 18:49:50.0 -0800
+++ ./include/net/ip6_checksum.h2006-11-08 18:50:04.0 -0800
@@ -36,7 +36,7 @@
static __inline__ unsigned short int csum_ipv6_magic(struct in6_addr *saddr,
struct in6_addr *daddr,
-__u16 len,
+__u32 len,
unsigned short proto,
unsigned int csum)
{
-
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: e1000: include for IA64
Chen, Kenneth W wrote: Chen, Kenneth wrote on Wednesday, November 08, 2006 4:10 PM Auke Kok wrote on Wednesday, November 08, 2006 9:49 AM Of course, someone really should come up with an asm version for ia64 of the missing function ;) Sure, absolutely. Here is an implementation for ia64. Tested heavily. Tony, please > merge. Applauded-by: Auke Kok <[EMAIL PROTECTED]> ;) Cheers, Auke Hmm. Forgot about the signed-off line. Here it is: Signed-off-by: Ken Chen <[EMAIL PROTECTED]> [patch] implement csum_ipv6_magic for ia64. The asm version is 3.4 times faster than the generic version. --- ./arch/ia64/lib/ip_fast_csum.S.orig 2006-11-08 12:26:28.0 -0800 +++ ./arch/ia64/lib/ip_fast_csum.S 2006-11-08 16:39:24.0 -0800 @@ -8,8 +8,8 @@ * in0: address of buffer to checksum (char *) * in1: length of the buffer (int) * - * Copyright (C) 2002 Intel Corp. - * Copyright (C) 2002 Ken Chen <[EMAIL PROTECTED]> + * Copyright (C) 2002, 2006 Intel Corp. + * Copyright (C) 2002, 2006 Ken Chen <[EMAIL PROTECTED]> */ #include @@ -25,6 +25,9 @@ #define in0 r32 #define in1r33 +#define in2r34 +#define in3r35 +#define in4r36 #define ret0 r8 GLOBAL_ENTRY(ip_fast_csum) @@ -88,3 +91,51 @@ GLOBAL_ENTRY(ip_fast_csum) mov b0=r34 br.ret.sptk.many b0 END(ip_fast_csum) + +GLOBAL_ENTRY(csum_ipv6_magic) + ld4 r20=[in0],4 + ld4 r21=[in1],4 + dep r15=in2,in3,16,16 + ;; + ld4 r22=[in0],4 + ld4 r23=[in1],4 + mux1r15=r15,@rev + ;; + ld4 r24=[in0],4 + ld4 r25=[in1],4 + shr.u r15=r15,32 + add r16=r20,r21 + add r17=r22,r23 + ;; + ld4 r26=[in0],4 + ld4 r27=[in1],4 + add r18=r24,r25 + add r8=r16,r17 + ;; + add r19=r26,r27 + add r8=r8,r18 + ;; + add r8=r8,r19 + add r15=r15,in4 + ;; + add r8=r8,r15 + ;; + shr.u r10=r8,16 // now fold sum into short + zxt2r11=r8 + ;; + add r8=r10,r11 + ;; + shr.u r10=r8,16 // yeah, keep it rolling + zxt2r11=r8 + ;; + add r8=r10,r11 + ;; + shr.u r10=r8,16 // three times lucky + zxt2r11=r8 + ;; + add r8=r10,r11 + mov r9=0x + ;; + andcm r8=r9,r8 + br.ret.sptk.many b0 +END(csum_ipv6_magic) --- ./include/asm-ia64/checksum.h.orig 2006-11-08 16:52:16.0 -0800 +++ ./include/asm-ia64/checksum.h 2006-11-08 17:01:09.0 -0800 @@ -73,4 +73,10 @@ csum_fold (unsigned int sum) return ~sum; } +#define _HAVE_ARCH_IPV6_CSUM 1 +struct in6_addr; +extern unsigned short int csum_ipv6_magic(struct in6_addr *saddr, + struct in6_addr *daddr, __u32 len, unsigned short proto, + unsigned int csum); + #endif /* _ASM_IA64_CHECKSUM_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 - 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: e1000 driver 2.6.18 - how to waste processor cycles
From: "Jesse Brandeburg" <[EMAIL PROTECTED]> Date: Wed, 8 Nov 2006 17:01:44 -0800 > If you can show that it is faster to use pci_dma_sync_single_for_cpu > and friends I'd be glad to take a patch. The problem is if you don't recycle the buffer and really unmap, you'll flush twice. That can potentially be expensive. - 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] sundance: solve host error problem in low performance embedded system when continune down and up
From: Jesse Huang <[EMAIL PROTECTED]>
Solve host error problem in low performance embedded system when continune
down and up. It will cause IP100A DMA TargetAbort. So we need more safe
process to up and down IP100A with wait hardware completely stop and software
cur_tx/ dirty_tx/cur_task/last_tx be clear.
Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/sundance.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff -puN
drivers/net/sundance.c~sundance-solve-host-error-problem-in-low-performance-embedded
drivers/net/sundance.c
---
a/drivers/net/sundance.c~sundance-solve-host-error-problem-in-low-performance-embedded
+++ a/drivers/net/sundance.c
@@ -1643,6 +1643,14 @@ static int netdev_close(struct net_devic
struct sk_buff *skb;
int i;
+ /* Wait and kill tasklet */
+ tasklet_kill(&np->rx_tasklet);
+ tasklet_kill(&np->tx_tasklet);
+ np->cur_tx = 0;
+ np->dirty_tx = 0;
+ np->cur_task = 0;
+ np->last_tx = 0;
+
netif_stop_queue(dev);
if (netif_msg_ifdown(np)) {
@@ -1663,9 +1671,20 @@ static int netdev_close(struct net_devic
/* Stop the chip's Tx and Rx processes. */
iowrite16(TxDisable | RxDisable | StatsDisable, ioaddr + MACCtrl1);
- /* Wait and kill tasklet */
- tasklet_kill(&np->rx_tasklet);
- tasklet_kill(&np->tx_tasklet);
+ for (i = 2000; i > 0; i--) {
+ if ((ioread32(ioaddr + DMACtrl) & 0xc000) == 0)
+ break;
+ mdelay(1);
+ }
+
+ iowrite16(GlobalReset | DMAReset | FIFOReset | NetworkReset,
+ ioaddr +ASICCtrl + 2);
+
+ for (i = 2000; i > 0; i--) {
+ if ((ioread16(ioaddr + ASICCtrl +2) & ResetBusy) == 0)
+ break;
+ mdelay(1);
+ }
#ifdef __i386__
if (netif_msg_hw(np)) {
@@ -1703,6 +1722,7 @@ static int netdev_close(struct net_devic
}
}
for (i = 0; i < TX_RING_SIZE; i++) {
+ np->tx_ring[i].next_desc = 0;
skb = np->tx_skbuff[i];
if (skb) {
pci_unmap_single(np->pci_dev,
_
-
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] drivers cris: return on NULL dev_alloc_skb()
From: David Rientjes <[EMAIL PROTECTED]> If the next descriptor array entry cannot be allocated by dev_alloc_skb(), return immediately so it is not dereferenced later. We cannot register the device with a partial descriptor list. Cc: Mikael Starvik <[EMAIL PROTECTED]> Signed-off-by: David Rientjes <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/cris/eth_v10.c |2 ++ 1 file changed, 2 insertions(+) diff -puN drivers/net/cris/eth_v10.c~drivers-cris-return-on-null-dev_alloc_skb drivers/net/cris/eth_v10.c --- a/drivers/net/cris/eth_v10.c~drivers-cris-return-on-null-dev_alloc_skb +++ a/drivers/net/cris/eth_v10.c @@ -509,6 +509,8 @@ etrax_ethernet_init(void) * does not share cacheline with any other data (to avoid cache bug) */ RxDescList[i].skb = dev_alloc_skb(MAX_MEDIA_DATA_SIZE + 2 * L1_CACHE_BYTES); + if (!RxDescList[i].skb) + return -ENOMEM; RxDescList[i].descr.ctrl = 0; RxDescList[i].descr.sw_len = MAX_MEDIA_DATA_SIZE; RxDescList[i].descr.next = virt_to_phys(&RxDescList[i + 1]); _ - 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 1/5] 8139too: force media setting cleanup
From: Bernard Lee <[EMAIL PROTECTED]>
Setting bit 4 & 5 alone in 8139too module media option does not really
force 100Mbps full-duplex mode. When media option bit 0-3 is cleared,
8139too module does not force media setting. Therefore, bit 0-3 requires
to be set for bit 4 & 5 to take effect. The hidden bit 0-3 setting is not
stated in module description.
It can be fixed by changing rtl8139_private structure default_port bitfield
from 4-bit to 6-bit.
Besides, module media bit 9 is a duplicate of bit 4 (full-duplex). It is
suggested that bit 9 is freed. A remark is added to module description
that bit 0 can be used to force setting. It helps to clarify 10Mbps
half-duplex mode.
Signed-off-by: Bernard Lee <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/8139too.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -puN drivers/net/8139too.c~8139too-force-media-setting-fix
drivers/net/8139too.c
--- a/drivers/net/8139too.c~8139too-force-media-setting-fix
+++ a/drivers/net/8139too.c
@@ -586,7 +586,7 @@ struct rtl8139_private {
signed char phys[4];/* MII device addresses. */
char twistie, twist_row, twist_col; /* Twister tune state. */
unsigned int watchdog_fired : 1;
- unsigned int default_port : 4; /* Last dev->if_port value. */
+ unsigned int default_port : 6; /* Last dev->if_port value. */
unsigned int have_thread : 1;
spinlock_t lock;
spinlock_t rx_lock;
@@ -612,7 +612,7 @@ module_param_array(full_duplex, int, NUL
module_param(debug, int, 0);
MODULE_PARM_DESC (debug, "8139too bitmapped message enable number");
MODULE_PARM_DESC (multicast_filter_limit, "8139too maximum number of filtered
multicast addresses");
-MODULE_PARM_DESC (media, "8139too: Bits 4+9: force full duplex, bit 5:
100Mbps");
+MODULE_PARM_DESC (media, "8139too: bit 0: force setting, bit 4: full duplex,
bit 5: 100Mbps");
MODULE_PARM_DESC (full_duplex, "8139too: Force full duplex for board(s) (1)");
static int read_eeprom (void __iomem *ioaddr, int location, int addr_len);
@@ -1068,8 +1068,8 @@ static int __devinit rtl8139_init_one (s
/* The lower four bits are the media type. */
option = (board_idx >= MAX_UNITS) ? 0 : media[board_idx];
if (option > 0) {
- tp->mii.full_duplex = (option & 0x210) ? 1 : 0;
- tp->default_port = option & 0xFF;
+ tp->mii.full_duplex = (option & 0x10) ? 1 : 0;
+ tp->default_port = option & 0x3F;
if (tp->default_port)
tp->mii.force_media = 1;
}
_
-
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 4/9] lockdep: annotate sk_lock nesting in AF_BLUETOOTH
From: Peter Zijlstra <[EMAIL PROTECTED]>
=
[ INFO: possible recursive locking detected ]
2.6.18-1.2726.fc6 #1
-
hidd/2271 is trying to acquire lock:
(sk_lock-AF_BLUETOOTH){--..}, at: [] bt_accept_dequeue+0x26/0xc6
[bluetooth]
but task is already holding lock:
(sk_lock-AF_BLUETOOTH){--..}, at: [] l2cap_sock_accept+0x41/0x11e
[l2cap]
other info that might help us debug this:
1 lock held by hidd/2271:
#0: (sk_lock-AF_BLUETOOTH){--..}, at: []
l2cap_sock_accept+0x41/0x11e [l2cap]
stack backtrace:
[] show_trace_log_lvl+0x58/0x16a
[] show_trace+0xd/0x10
[] dump_stack+0x19/0x1b
[] __lock_acquire+0x6ea/0x90d
[] lock_acquire+0x4b/0x6b
[] lock_sock+0xac/0xbc
[] bt_accept_dequeue+0x26/0xc6 [bluetooth]
[] l2cap_sock_accept+0xe2/0x11e [l2cap]
[] sys_accept+0xd8/0x179
[] sys_socketcall+0xa7/0x186
[] syscall_call+0x7/0xb
classical case of nesting; bt_accept_dequeue() locks the children of the object
locked by l2cap_sock_accept().
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
Acked-by: Marcel Holtmann <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/net/sock.h|8 +++-
net/bluetooth/l2cap.c |4 ++--
net/core/sock.c |6 +++---
3 files changed, 12 insertions(+), 6 deletions(-)
diff -puN
include/net/sock.h~lockdep-annotate-sk_lock-nesting-in-af_bluetooth-v2
include/net/sock.h
--- a/include/net/sock.h~lockdep-annotate-sk_lock-nesting-in-af_bluetooth-v2
+++ a/include/net/sock.h
@@ -745,7 +745,13 @@ static inline int sk_stream_wmem_schedul
*/
#define sock_owned_by_user(sk) ((sk)->sk_lock.owner)
-extern void FASTCALL(lock_sock(struct sock *sk));
+extern void FASTCALL(lock_sock_nested(struct sock *sk, int subclass));
+
+static inline void lock_sock(struct sock *sk)
+{
+ lock_sock_nested(sk, 0);
+}
+
extern void FASTCALL(release_sock(struct sock *sk));
/* BH context may only use the following locking interface. */
diff -puN
net/bluetooth/l2cap.c~lockdep-annotate-sk_lock-nesting-in-af_bluetooth-v2
net/bluetooth/l2cap.c
--- a/net/bluetooth/l2cap.c~lockdep-annotate-sk_lock-nesting-in-af_bluetooth-v2
+++ a/net/bluetooth/l2cap.c
@@ -770,7 +770,7 @@ static int l2cap_sock_accept(struct sock
long timeo;
int err = 0;
- lock_sock(sk);
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
if (sk->sk_state != BT_LISTEN) {
err = -EBADFD;
@@ -792,7 +792,7 @@ static int l2cap_sock_accept(struct sock
release_sock(sk);
timeo = schedule_timeout(timeo);
- lock_sock(sk);
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
if (sk->sk_state != BT_LISTEN) {
err = -EBADFD;
diff -puN net/core/sock.c~lockdep-annotate-sk_lock-nesting-in-af_bluetooth-v2
net/core/sock.c
--- a/net/core/sock.c~lockdep-annotate-sk_lock-nesting-in-af_bluetooth-v2
+++ a/net/core/sock.c
@@ -1527,7 +1527,7 @@ void sock_init_data(struct socket *sock,
atomic_set(&sk->sk_refcnt, 1);
}
-void fastcall lock_sock(struct sock *sk)
+void fastcall lock_sock_nested(struct sock *sk, int subclass)
{
might_sleep();
spin_lock_bh(&sk->sk_lock.slock);
@@ -1538,11 +1538,11 @@ void fastcall lock_sock(struct sock *sk)
/*
* The sk_lock has mutex_lock() semantics here:
*/
- mutex_acquire(&sk->sk_lock.dep_map, 0, 0, _RET_IP_);
+ mutex_acquire(&sk->sk_lock.dep_map, subclass, 0, _RET_IP_);
local_bh_enable();
}
-EXPORT_SYMBOL(lock_sock);
+EXPORT_SYMBOL(lock_sock_nested);
void fastcall release_sock(struct sock *sk)
{
_
-
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 6/9] bnep endianness annotations
From: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: Marcel Holtmann <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
net/bluetooth/bnep/bnep.h |4 ++--
net/bluetooth/bnep/core.c | 12 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff -puN net/bluetooth/bnep/bnep.h~bnep-endianness-annotations
net/bluetooth/bnep/bnep.h
--- a/net/bluetooth/bnep/bnep.h~bnep-endianness-annotations
+++ a/net/bluetooth/bnep/bnep.h
@@ -95,14 +95,14 @@ struct bnep_setup_conn_req {
struct bnep_set_filter_req {
__u8 type;
__u8 ctrl;
- __u16 len;
+ __be16 len;
__u8 list[0];
} __attribute__((packed));
struct bnep_control_rsp {
__u8 type;
__u8 ctrl;
- __u16 resp;
+ __be16 resp;
} __attribute__((packed));
struct bnep_ext_hdr {
diff -puN net/bluetooth/bnep/core.c~bnep-endianness-annotations
net/bluetooth/bnep/core.c
--- a/net/bluetooth/bnep/core.c~bnep-endianness-annotations
+++ a/net/bluetooth/bnep/core.c
@@ -128,7 +128,7 @@ static inline void bnep_set_default_prot
}
#endif
-static int bnep_ctrl_set_netfilter(struct bnep_session *s, u16 *data, int len)
+static int bnep_ctrl_set_netfilter(struct bnep_session *s, __be16 *data, int
len)
{
int n;
@@ -180,7 +180,7 @@ static int bnep_ctrl_set_mcfilter(struct
if (len < 2)
return -EILSEQ;
- n = ntohs(get_unaligned((u16 *) data));
+ n = ntohs(get_unaligned((__be16 *) data));
data += 2; len -= 2;
if (len < n)
@@ -332,7 +332,7 @@ static inline int bnep_rx_frame(struct b
if (!skb_pull(skb, __bnep_rx_hlen[type & BNEP_TYPE_MASK]))
goto badframe;
- s->eh.h_proto = get_unaligned((u16 *) (skb->data - 2));
+ s->eh.h_proto = get_unaligned((__be16 *) (skb->data - 2));
if (type & BNEP_EXT_HEADER) {
if (bnep_rx_extension(s, skb) < 0)
@@ -343,7 +343,7 @@ static inline int bnep_rx_frame(struct b
if (ntohs(s->eh.h_proto) == 0x8100) {
if (!skb_pull(skb, 4))
goto badframe;
- s->eh.h_proto = get_unaligned((u16 *) (skb->data - 2));
+ s->eh.h_proto = get_unaligned((__be16 *) (skb->data - 2));
}
/* We have to alloc new skb and copy data here :(. Because original skb
@@ -365,7 +365,7 @@ static inline int bnep_rx_frame(struct b
case BNEP_COMPRESSED_SRC_ONLY:
memcpy(__skb_put(nskb, ETH_ALEN), s->eh.h_dest, ETH_ALEN);
memcpy(__skb_put(nskb, ETH_ALEN), skb->mac.raw, ETH_ALEN);
- put_unaligned(s->eh.h_proto, (u16 *) __skb_put(nskb, 2));
+ put_unaligned(s->eh.h_proto, (__be16 *) __skb_put(nskb, 2));
break;
case BNEP_COMPRESSED_DST_ONLY:
@@ -375,7 +375,7 @@ static inline int bnep_rx_frame(struct b
case BNEP_GENERAL:
memcpy(__skb_put(nskb, ETH_ALEN * 2), skb->mac.raw, ETH_ALEN *
2);
- put_unaligned(s->eh.h_proto, (u16 *) __skb_put(nskb, 2));
+ put_unaligned(s->eh.h_proto, (__be16 *) __skb_put(nskb, 2));
break;
}
_
-
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 7/9] rfcomm endianness annotations
From: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: Marcel Holtmann <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/net/bluetooth/rfcomm.h |4 ++--
net/bluetooth/rfcomm/core.c|2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff -puN include/net/bluetooth/rfcomm.h~rfcomm-endianness-annotations
include/net/bluetooth/rfcomm.h
--- a/include/net/bluetooth/rfcomm.h~rfcomm-endianness-annotations
+++ a/include/net/bluetooth/rfcomm.h
@@ -124,7 +124,7 @@ struct rfcomm_pn {
u8 flow_ctrl;
u8 priority;
u8 ack_timer;
- u16 mtu;
+ __le16 mtu;
u8 max_retrans;
u8 credits;
} __attribute__ ((packed));
@@ -136,7 +136,7 @@ struct rfcomm_rpn {
u8 flow_ctrl;
u8 xon_char;
u8 xoff_char;
- u16 param_mask;
+ __le16 param_mask;
} __attribute__ ((packed));
struct rfcomm_rls {
diff -puN net/bluetooth/rfcomm/core.c~rfcomm-endianness-annotations
net/bluetooth/rfcomm/core.c
--- a/net/bluetooth/rfcomm/core.c~rfcomm-endianness-annotations
+++ a/net/bluetooth/rfcomm/core.c
@@ -1018,7 +1018,7 @@ static void rfcomm_make_uih(struct sk_bu
if (len > 127) {
hdr = (void *) skb_push(skb, 4);
- put_unaligned(htobs(__len16(len)), (u16 *) &hdr->len);
+ put_unaligned(htobs(__len16(len)), (__le16 *) &hdr->len);
} else {
hdr = (void *) skb_push(skb, 3);
hdr->len = __len8(len);
_
-
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/9] bnep endianness bug: filtering by packet type
From: Al Viro <[EMAIL PROTECTED]>
<= and => don't work well on net-endian...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: Marcel Holtmann <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
net/bluetooth/bnep/core.c | 16
net/bluetooth/bnep/netdev.c | 11 ++-
2 files changed, 14 insertions(+), 13 deletions(-)
diff -puN
net/bluetooth/bnep/core.c~bnep-endianness-bug-filtering-by-packet-type
net/bluetooth/bnep/core.c
--- a/net/bluetooth/bnep/core.c~bnep-endianness-bug-filtering-by-packet-type
+++ a/net/bluetooth/bnep/core.c
@@ -117,14 +117,14 @@ static int bnep_send_rsp(struct bnep_ses
static inline void bnep_set_default_proto_filter(struct bnep_session *s)
{
/* (IPv4, ARP) */
- s->proto_filter[0].start = htons(0x0800);
- s->proto_filter[0].end = htons(0x0806);
+ s->proto_filter[0].start = ETH_P_IP;
+ s->proto_filter[0].end = ETH_P_ARP;
/* (RARP, AppleTalk) */
- s->proto_filter[1].start = htons(0x8035);
- s->proto_filter[1].end = htons(0x80F3);
+ s->proto_filter[1].start = ETH_P_RARP;
+ s->proto_filter[1].end = ETH_P_AARP;
/* (IPX, IPv6) */
- s->proto_filter[2].start = htons(0x8137);
- s->proto_filter[2].end = htons(0x86DD);
+ s->proto_filter[2].start = ETH_P_IPX;
+ s->proto_filter[2].end = ETH_P_IPV6;
}
#endif
@@ -150,8 +150,8 @@ static int bnep_ctrl_set_netfilter(struc
int i;
for (i = 0; i < n; i++) {
- f[i].start = get_unaligned(data++);
- f[i].end = get_unaligned(data++);
+ f[i].start = ntohs(get_unaligned(data++));
+ f[i].end = ntohs(get_unaligned(data++));
BT_DBG("proto filter start %d end %d",
f[i].start, f[i].end);
diff -puN
net/bluetooth/bnep/netdev.c~bnep-endianness-bug-filtering-by-packet-type
net/bluetooth/bnep/netdev.c
--- a/net/bluetooth/bnep/netdev.c~bnep-endianness-bug-filtering-by-packet-type
+++ a/net/bluetooth/bnep/netdev.c
@@ -158,14 +158,15 @@ static inline int bnep_net_mc_filter(str
static inline u16 bnep_net_eth_proto(struct sk_buff *skb)
{
struct ethhdr *eh = (void *) skb->data;
+ u16 proto = ntohs(eh->h_proto);
- if (ntohs(eh->h_proto) >= 1536)
- return eh->h_proto;
+ if (proto >= 1536)
+ return proto;
- if (get_unaligned((u16 *) skb->data) == 0x)
- return htons(ETH_P_802_3);
+ if (get_unaligned((__be16 *) skb->data) == htons(0x))
+ return ETH_P_802_3;
- return htons(ETH_P_802_2);
+ return ETH_P_802_2;
}
static inline int bnep_net_proto_filter(struct sk_buff *skb, struct
bnep_session *s)
_
-
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 8/9] rfcomm endianness bug: param_mask is little-endian on the wire
From: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: Marcel Holtmann <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
net/bluetooth/rfcomm/core.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff -puN
net/bluetooth/rfcomm/core.c~rfcomm-endianness-bug-param_mask-is-little-endian-on-the-wire
net/bluetooth/rfcomm/core.c
---
a/net/bluetooth/rfcomm/core.c~rfcomm-endianness-bug-param_mask-is-little-endian-on-the-wire
+++ a/net/bluetooth/rfcomm/core.c
@@ -854,7 +854,7 @@ int rfcomm_send_rpn(struct rfcomm_sessio
rpn->flow_ctrl = flow_ctrl_settings;
rpn->xon_char = xon_char;
rpn->xoff_char = xoff_char;
- rpn->param_mask= param_mask;
+ rpn->param_mask= cpu_to_le16(param_mask);
*ptr = __fcs(buf); ptr++;
@@ -1343,7 +1343,7 @@ static int rfcomm_recv_rpn(struct rfcomm
/* Check for sane values, ignore/accept bit_rate, 8 bits, 1 stop bit,
* no parity, no flow control lines, normal XON/XOFF chars */
- if (rpn->param_mask & RFCOMM_RPN_PM_BITRATE) {
+ if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_BITRATE)) {
bit_rate = rpn->bit_rate;
if (bit_rate != RFCOMM_RPN_BR_115200) {
BT_DBG("RPN bit rate mismatch 0x%x", bit_rate);
@@ -1352,7 +1352,7 @@ static int rfcomm_recv_rpn(struct rfcomm
}
}
- if (rpn->param_mask & RFCOMM_RPN_PM_DATA) {
+ if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_DATA)) {
data_bits = __get_rpn_data_bits(rpn->line_settings);
if (data_bits != RFCOMM_RPN_DATA_8) {
BT_DBG("RPN data bits mismatch 0x%x", data_bits);
@@ -1361,7 +1361,7 @@ static int rfcomm_recv_rpn(struct rfcomm
}
}
- if (rpn->param_mask & RFCOMM_RPN_PM_STOP) {
+ if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_STOP)) {
stop_bits = __get_rpn_stop_bits(rpn->line_settings);
if (stop_bits != RFCOMM_RPN_STOP_1) {
BT_DBG("RPN stop bits mismatch 0x%x", stop_bits);
@@ -1370,7 +1370,7 @@ static int rfcomm_recv_rpn(struct rfcomm
}
}
- if (rpn->param_mask & RFCOMM_RPN_PM_PARITY) {
+ if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_PARITY)) {
parity = __get_rpn_parity(rpn->line_settings);
if (parity != RFCOMM_RPN_PARITY_NONE) {
BT_DBG("RPN parity mismatch 0x%x", parity);
@@ -1379,7 +1379,7 @@ static int rfcomm_recv_rpn(struct rfcomm
}
}
- if (rpn->param_mask & RFCOMM_RPN_PM_FLOW) {
+ if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_FLOW)) {
flow_ctrl = rpn->flow_ctrl;
if (flow_ctrl != RFCOMM_RPN_FLOW_NONE) {
BT_DBG("RPN flow ctrl mismatch 0x%x", flow_ctrl);
@@ -1388,7 +1388,7 @@ static int rfcomm_recv_rpn(struct rfcomm
}
}
- if (rpn->param_mask & RFCOMM_RPN_PM_XON) {
+ if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_XON)) {
xon_char = rpn->xon_char;
if (xon_char != RFCOMM_RPN_XON_CHAR) {
BT_DBG("RPN XON char mismatch 0x%x", xon_char);
@@ -1397,7 +1397,7 @@ static int rfcomm_recv_rpn(struct rfcomm
}
}
- if (rpn->param_mask & RFCOMM_RPN_PM_XOFF) {
+ if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_XOFF)) {
xoff_char = rpn->xoff_char;
if (xoff_char != RFCOMM_RPN_XOFF_CHAR) {
BT_DBG("RPN XOFF char mismatch 0x%x", xoff_char);
_
-
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/9] com20020 build fix
From: Randy Dunlap <[EMAIL PROTECTED]>
com20020.c needs to export functions if either of the ISA or PCI modules
are built as loadable modules. Or they could always be exported.
WARNING: "com20020_found" [drivers/net/arcnet/com20020-pci.ko] undefined!
WARNING: "com20020_check" [drivers/net/arcnet/com20020-pci.ko] undefined!
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Cc: Toralf Forster <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/arcnet/com20020.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff -puN drivers/net/arcnet/com20020.c~com20020-build-fix
drivers/net/arcnet/com20020.c
--- a/drivers/net/arcnet/com20020.c~com20020-build-fix
+++ a/drivers/net/arcnet/com20020.c
@@ -337,13 +337,16 @@ static void com20020_set_mc_list(struct
}
}
-#ifdef MODULE
-
+#if defined(CONFIG_ARCNET_COM20020_PCI_MODULE) || \
+defined(CONFIG_ARCNET_COM20020_ISA_MODULE)
EXPORT_SYMBOL(com20020_check);
EXPORT_SYMBOL(com20020_found);
+#endif
MODULE_LICENSE("GPL");
+#ifdef MODULE
+
int init_module(void)
{
BUGLVL(D_NORMAL) printk(VERSION);
_
-
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 1/9] bonding: lockdep annotation
From: Peter Zijlstra <[EMAIL PROTECTED]>
=
[ INFO: possible recursive locking detected ]
2.6.17-1.2600.fc6 #1
-
ifconfig/2411 is trying to acquire lock:
(&dev->_xmit_lock){-...}, at: [] dev_mc_add+0x45/0x15f
but task is already holding lock:
(&dev->_xmit_lock){-...}, at: [] dev_mc_add+0x45/0x15f
other info that might help us debug this:
3 locks held by ifconfig/2411:
#0: (rtnl_mutex){--..}, at: [] mutex_lock+0x2a/0x2e
#1: (&dev->_xmit_lock){-...}, at: [] dev_mc_add+0x45/0x15f
#2: (&bond->lock){-.-+}, at: []
bond_set_multicast_list+0x2c/0x26a [bonding]
stack backtrace:
Call Trace:
[] show_trace+0xae/0x319
[] dump_stack+0x15/0x17
[] __lock_acquire+0x135/0xa64
[] lock_acquire+0x4b/0x69
[] _spin_lock_bh+0x2a/0x36
[] dev_mc_add+0x45/0x15f
[] :bonding:bond_set_multicast_list+0x138/0x26a
[] __dev_mc_upload+0x22/0x24
[] dev_mc_add+0x11a/0x15f
[] igmp_group_added+0x55/0x10f
[] ip_mc_inc_group+0x1d6/0x21a
[] ip_mc_up+0x46/0x61
[] inetdev_init+0x11c/0x136
[] devinet_ioctl+0x3eb/0x5e9
[] inet_ioctl+0x71/0x8f
[] sock_ioctl+0x1e8/0x20a
[] do_ioctl+0x2a/0x77
[] vfs_ioctl+0x25a/0x277
[] sys_ioctl+0x5f/0x82
[] system_call+0x7e/0x83
The bonding driver nests other drivers, give the bonding driver its own
lock class.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c |5 +
1 file changed, 5 insertions(+)
diff -puN drivers/net/bonding/bond_main.c~bonding-lockdep-annotation
drivers/net/bonding/bond_main.c
--- a/drivers/net/bonding/bond_main.c~bonding-lockdep-annotation
+++ a/drivers/net/bonding/bond_main.c
@@ -4692,6 +4692,8 @@ static int bond_check_params(struct bond
return 0;
}
+static struct lock_class_key bonding_netdev_xmit_lock_key;
+
/* Create a new bond based on the specified name and bonding parameters.
* Caller must NOT hold rtnl_lock; we need to release it here before we
* set up our sysfs entries.
@@ -4727,6 +4729,9 @@ int bond_create(char *name, struct bond_
if (res < 0) {
goto out_bond;
}
+
+ lockdep_set_class(&bond_dev->_xmit_lock, &bonding_netdev_xmit_lock_key);
+
if (newbond)
*newbond = bond_dev->priv;
_
-
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/9] iPhase: 64bit cleanup
From: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/atm/Kconfig |2 +-
drivers/atm/iphase.c | 23 ++-
2 files changed, 11 insertions(+), 14 deletions(-)
diff -puN drivers/atm/Kconfig~resend-iphase-64bit-cleanup drivers/atm/Kconfig
--- a/drivers/atm/Kconfig~resend-iphase-64bit-cleanup
+++ a/drivers/atm/Kconfig
@@ -289,7 +289,7 @@ config ATM_HORIZON_DEBUG
config ATM_IA
tristate "Interphase ATM PCI x575/x525/x531"
- depends on PCI && ATM && !64BIT
+ depends on PCI && ATM
---help---
This is a driver for the Interphase (i)ChipSAR adapter cards
which include a variety of variants in term of the size of the
diff -puN drivers/atm/iphase.c~resend-iphase-64bit-cleanup drivers/atm/iphase.c
--- a/drivers/atm/iphase.c~resend-iphase-64bit-cleanup
+++ a/drivers/atm/iphase.c
@@ -93,10 +93,6 @@ module_param(IADebugFlag, uint, 0644);
MODULE_LICENSE("GPL");
-#if BITS_PER_LONG != 32
-# error FIXME: this driver only works on 32-bit platforms
-#endif
-
/ IA_LIB **/
static void ia_init_rtn_q (IARTN_Q *que)
@@ -1408,7 +1404,6 @@ static int rx_init(struct atm_dev *dev)
struct abr_vc_table *abr_vc_table;
u16 *vc_table;
u16 *reass_table;
-u16 *ptr16;
int i,j, vcsize_sel;
u_short freeq_st_adr;
u_short *freeq_start;
@@ -1423,14 +1418,15 @@ static int rx_init(struct atm_dev *dev)
printk(KERN_ERR DEV_LABEL "can't allocate DLEs\n");
goto err_out;
}
- iadev->rx_dle_q.start = (struct dle*)dle_addr;
+ iadev->rx_dle_q.start = (struct dle *)dle_addr;
iadev->rx_dle_q.read = iadev->rx_dle_q.start;
iadev->rx_dle_q.write = iadev->rx_dle_q.start;
- iadev->rx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct
dle)*DLE_ENTRIES);
+ iadev->rx_dle_q.end = (struct dle*)((unsigned
long)dle_addr+sizeof(struct dle)*DLE_ENTRIES);
/* the end of the dle q points to the entry after the last
DLE that can be used. */
/* write the upper 20 bits of the start address to rx list address
register */
+ /* We know this is 32bit bus addressed so the following is safe */
writel(iadev->rx_dle_dma & 0xf000,
iadev->dma + IPHASE5575_RX_LIST_ADDR);
IF_INIT(printk("Tx Dle list addr: 0x%08x value: 0x%0x\n",
@@ -1584,11 +1580,12 @@ static int rx_init(struct atm_dev *dev)
Set Packet Aging Interval count register to overflow in about 4 us
*/
writew(0xF6F8, iadev->reass_reg+PKT_TM_CNT );
-ptr16 = (u16*)j;
-i = ((u32)ptr16 >> 6) & 0xff;
- ptr16 += j - 1;
- i |=(((u32)ptr16 << 2) & 0xff00);
+
+i = (j >> 6) & 0xFF;
+j += 2 * (j - 1);
+i |= ((j << 2) & 0xFF00);
writew(i, iadev->reass_reg+TMOUT_RANGE);
+
/* initiate the desc_tble */
for(i=0; inum_tx_desc;i++)
iadev->desc_tbl[i].timestamp = 0;
@@ -1911,7 +1908,7 @@ static int tx_init(struct atm_dev *dev)
iadev->tx_dle_q.start = (struct dle*)dle_addr;
iadev->tx_dle_q.read = iadev->tx_dle_q.start;
iadev->tx_dle_q.write = iadev->tx_dle_q.start;
- iadev->tx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct
dle)*DLE_ENTRIES);
+ iadev->tx_dle_q.end = (struct dle*)((unsigned
long)dle_addr+sizeof(struct dle)*DLE_ENTRIES);
/* write the upper 20 bits of the start address to tx list address
register */
writel(iadev->tx_dle_dma & 0xf000,
@@ -2913,7 +2910,7 @@ static int ia_pkt_tx (struct atm_vcc *vc
dev_kfree_skb_any(skb);
return 0;
}
-if ((u32)skb->data & 3) {
+if ((unsigned long)skb->data & 3) {
printk("Misaligned SKB\n");
if (vcc->pop)
vcc->pop(vcc, skb);
_
-
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 9/9] net: uninline xfrm_selector_match()
From: Andrew Morton <[EMAIL PROTECTED]>
Six callsites, huge.
Cc: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/net/xfrm.h | 36 ++--
net/xfrm/xfrm_policy.c | 34 ++
2 files changed, 36 insertions(+), 34 deletions(-)
diff -puN include/net/xfrm.h~net-uninline-xfrm_selector_match include/net/xfrm.h
--- a/include/net/xfrm.h~net-uninline-xfrm_selector_match
+++ a/include/net/xfrm.h
@@ -506,40 +506,8 @@ __be16 xfrm_flowi_dport(struct flowi *fl
return port;
}
-static inline int
-__xfrm4_selector_match(struct xfrm_selector *sel, struct flowi *fl)
-{
- return addr_match(&fl->fl4_dst, &sel->daddr, sel->prefixlen_d) &&
- addr_match(&fl->fl4_src, &sel->saddr, sel->prefixlen_s) &&
- !((xfrm_flowi_dport(fl) ^ sel->dport) & sel->dport_mask) &&
- !((xfrm_flowi_sport(fl) ^ sel->sport) & sel->sport_mask) &&
- (fl->proto == sel->proto || !sel->proto) &&
- (fl->oif == sel->ifindex || !sel->ifindex);
-}
-
-static inline int
-__xfrm6_selector_match(struct xfrm_selector *sel, struct flowi *fl)
-{
- return addr_match(&fl->fl6_dst, &sel->daddr, sel->prefixlen_d) &&
- addr_match(&fl->fl6_src, &sel->saddr, sel->prefixlen_s) &&
- !((xfrm_flowi_dport(fl) ^ sel->dport) & sel->dport_mask) &&
- !((xfrm_flowi_sport(fl) ^ sel->sport) & sel->sport_mask) &&
- (fl->proto == sel->proto || !sel->proto) &&
- (fl->oif == sel->ifindex || !sel->ifindex);
-}
-
-static inline int
-xfrm_selector_match(struct xfrm_selector *sel, struct flowi *fl,
- unsigned short family)
-{
- switch (family) {
- case AF_INET:
- return __xfrm4_selector_match(sel, fl);
- case AF_INET6:
- return __xfrm6_selector_match(sel, fl);
- }
- return 0;
-}
+int xfrm_selector_match(struct xfrm_selector *sel, struct flowi *fl,
+ unsigned short family);
#ifdef CONFIG_SECURITY_NETWORK_XFRM
/* If neither has a context --> match
diff -puN net/xfrm/xfrm_policy.c~net-uninline-xfrm_selector_match
net/xfrm/xfrm_policy.c
--- a/net/xfrm/xfrm_policy.c~net-uninline-xfrm_selector_match
+++ a/net/xfrm/xfrm_policy.c
@@ -50,6 +50,40 @@ static void xfrm_policy_put_afinfo(struc
static struct xfrm_policy_afinfo *xfrm_policy_lock_afinfo(unsigned int family);
static void xfrm_policy_unlock_afinfo(struct xfrm_policy_afinfo *afinfo);
+static inline int
+__xfrm4_selector_match(struct xfrm_selector *sel, struct flowi *fl)
+{
+ return addr_match(&fl->fl4_dst, &sel->daddr, sel->prefixlen_d) &&
+ addr_match(&fl->fl4_src, &sel->saddr, sel->prefixlen_s) &&
+ !((xfrm_flowi_dport(fl) ^ sel->dport) & sel->dport_mask) &&
+ !((xfrm_flowi_sport(fl) ^ sel->sport) & sel->sport_mask) &&
+ (fl->proto == sel->proto || !sel->proto) &&
+ (fl->oif == sel->ifindex || !sel->ifindex);
+}
+
+static inline int
+__xfrm6_selector_match(struct xfrm_selector *sel, struct flowi *fl)
+{
+ return addr_match(&fl->fl6_dst, &sel->daddr, sel->prefixlen_d) &&
+ addr_match(&fl->fl6_src, &sel->saddr, sel->prefixlen_s) &&
+ !((xfrm_flowi_dport(fl) ^ sel->dport) & sel->dport_mask) &&
+ !((xfrm_flowi_sport(fl) ^ sel->sport) & sel->sport_mask) &&
+ (fl->proto == sel->proto || !sel->proto) &&
+ (fl->oif == sel->ifindex || !sel->ifindex);
+}
+
+int xfrm_selector_match(struct xfrm_selector *sel, struct flowi *fl,
+ unsigned short family)
+{
+ switch (family) {
+ case AF_INET:
+ return __xfrm4_selector_match(sel, fl);
+ case AF_INET6:
+ return __xfrm6_selector_match(sel, fl);
+ }
+ return 0;
+}
+
int xfrm_register_type(struct xfrm_type *type, unsigned short family)
{
struct xfrm_policy_afinfo *afinfo = xfrm_policy_lock_afinfo(family);
_
-
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/3] mlsxfrm: Various fixes
Venkat Yekkirala wrote: >>>Fix SO_PEERSEC for tcp sockets to return the security context of >>>the peer (as represented by the SA from the peer) as opposed to the >>>SA used by the local/source socket. >> >>What about the case of a localhost TCP connection not using >>xfrm labeling? >> >>Joe Nall raised this as an important requirement. > > Yes. We need to come up with some new ideas on this (the failed > secid-recon patchset sought to do this using the secmark field > on the skb). You mentioned in an earlier thread that it may be possibile to enable XFRM for localhost via a sysctl variable; I would think this would make the most sense. I understand there is a performance hit due to IPsec being used, but I think this solution offers a few advantages: 1. Functionality is available right now, no additional kernel changes needed 2. No special handling for localhost, I tend to like the idea of having consistent behavior for all addresses/interfaces Besides the performance penalty of IPsec and the untested nature of this solution is there some gotcha here which would prevent this from working? -- paul moore linux security @ hp - 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/3] mlsxfrm: Various fixes
On Wed, 8 Nov 2006, Paul Moore wrote: > 1. Functionality is available right now, no additional kernel changes needed > 2. No special handling for localhost, I tend to like the idea of having > consistent behavior for all addresses/interfaces I don't agree. SO_PEERSEC should always just work for loopback, just like with Unix sockets. - James -- James Morris <[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 2/3] mlsxfrm: Various fixes
James Morris wrote: > On Wed, 8 Nov 2006, Paul Moore wrote: > >>1. Functionality is available right now, no additional kernel changes needed >>2. No special handling for localhost, I tend to like the idea of having >>consistent behavior for all addresses/interfaces > > I don't agree. SO_PEERSEC should always just work for loopback, just like > with Unix sockets. My main concern is that we would have "special" behavior for a single IP address and that this behavior wouldn't be subject to the same labeled networking configuration/management methods as the rest of the address space. Treating localhost like any other IP address seems consistent with the way we handle Unix sockets - we don't have any special handling depending on the path of the socket. -- paul moore linux security @ hp - 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: New laptop - problems with linux
Stephen Clark wrote: Thanks I have that working - I am now struggling with the disk being slower than molasses ( high priority, 1.xx mb/sec ) Add 'combined_mode=libata' to kernel parameter and see what happens. This should make libata take care of all ATA ports and your harddisks will appear as /dev/sda and sdb, your cdrom /dev/sr0. So, you might need to adjust root= parameter too. -- tejun - 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/3] mlsxfrm: Various fixes
On Wed, 8 Nov 2006, Paul Moore wrote: > James Morris wrote: > > On Wed, 8 Nov 2006, Paul Moore wrote: > > > >>1. Functionality is available right now, no additional kernel changes needed > >>2. No special handling for localhost, I tend to like the idea of having > >>consistent behavior for all addresses/interfaces > > > > I don't agree. SO_PEERSEC should always just work for loopback, just like > > with Unix sockets. > > My main concern is that we would have "special" behavior for a single IP > address >and that this behavior wouldn't be subject to the same labeled networking > configuration/management methods as the rest of the address space. It's a very special case, and loopack networking has lots of special case handling because of this. It's nearly zero cost to have this work, and then you get full SELinux control over local IP communications. It doesn't prevent the IPsec stuff from working, if you want it to override the default. But would people really run IPsec for localhost communications? Let's keep the simple case simple. > Treating localhost like any other IP address seems consistent with the > way we handle Unix sockets - we don't have any special handling > depending on the path of the socket. Unix sockets can't do both local and remote communication. - James -- James Morris <[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 0/3] labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]
On Wed, 8 Nov 2006, Venkat Yekkirala wrote: > This patchset is against davem's net-2.6.git. Please apply to 2.6.19. > > The following are the changes since the previous post of this patchset: > > 1. Separate BUG_ON usage per Eric's suggestion. > > 2. Replace security_sid_compare with a simple sid compare check per >a suggestion from Paul/Stephen. Applied to: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-net-2.6.20.git I think this should be aimed at 2.6.20, because we are at the last or second-last -rc currently, and I don't think these fixes are urgent enough to justify the risk at this stage. Also, I think this code needs more testing, and more general progress towards code completion. - James -- James Morris <[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 2/3] mlsxfrm: Various fixes
James Morris wrote: > On Wed, 8 Nov 2006, Paul Moore wrote: > >>James Morris wrote: >> >>>On Wed, 8 Nov 2006, Paul Moore wrote: >>> 1. Functionality is available right now, no additional kernel changes needed 2. No special handling for localhost, I tend to like the idea of having consistent behavior for all addresses/interfaces >>> >>>I don't agree. SO_PEERSEC should always just work for loopback, just like >>>with Unix sockets. >> >>My main concern is that we would have "special" behavior for a single IP >>address >> and that this behavior wouldn't be subject to the same labeled networking >>configuration/management methods as the rest of the address space. > > It's a very special case, and loopack networking has lots of special case > handling because of this. It's nearly zero cost to have this work, and > then you get full SELinux control over local IP communications. It sounds like you have an idea of how you would like to see this implemented, can you give me a rough outline? Is this the partitioned SECMARK field you talked about earlier? I'm asking because the only localhost SO_PEERSEC mechanism that I have seen that didn't require explicit packet labeling was the secid approach which I think we gave up on ... -- paul moore linux security @ hp - 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/3] labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]
From: James Morris <[EMAIL PROTECTED]> Date: Thu, 9 Nov 2006 01:30:05 -0500 (EST) > I think this should be aimed at 2.6.20, because we are at the last or > second-last -rc currently, and I don't think these fixes are urgent enough > to justify the risk at this stage. Also, I think this code needs more > testing, and more general progress towards code completion. This is the way I feel too. - 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/9] bnep endianness bug: filtering by packet type
From: [EMAIL PROTECTED] Date: Wed, 08 Nov 2006 19:51:07 -0800 > From: Al Viro <[EMAIL PROTECTED]> > > <= and => don't work well on net-endian... > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > Acked-by: Marcel Holtmann <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Also already in my net-2.6.20 tree - 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/9] bnep endianness annotations
From: [EMAIL PROTECTED] Date: Wed, 08 Nov 2006 19:51:08 -0800 > From: Al Viro <[EMAIL PROTECTED]> > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > Acked-by: Marcel Holtmann <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Also already in my net-2.6.20 tree - 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/9] rfcomm endianness bug: param_mask is little-endian on the wire
From: [EMAIL PROTECTED] Date: Wed, 08 Nov 2006 19:51:10 -0800 > From: Al Viro <[EMAIL PROTECTED]> > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > Acked-by: Marcel Holtmann <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Also already in my net-2.6.20 tree. - 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 7/9] rfcomm endianness annotations
From: [EMAIL PROTECTED] Date: Wed, 08 Nov 2006 19:51:09 -0800 > From: Al Viro <[EMAIL PROTECTED]> > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > Acked-by: Marcel Holtmann <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> This one is in my net-2.6.20 GIT tree already. - 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/9] lockdep: annotate sk_lock nesting in AF_BLUETOOTH
From: [EMAIL PROTECTED]
Date: Wed, 08 Nov 2006 19:51:05 -0800
> From: Peter Zijlstra <[EMAIL PROTECTED]>
>
> =
> [ INFO: possible recursive locking detected ]
> 2.6.18-1.2726.fc6 #1
> -
> hidd/2271 is trying to acquire lock:
> (sk_lock-AF_BLUETOOTH){--..}, at: [] bt_accept_dequeue+0x26/0xc6
> [bluetooth]
>
> but task is already holding lock:
> (sk_lock-AF_BLUETOOTH){--..}, at: [] l2cap_sock_accept+0x41/0x11e
> [l2cap]
>
> other info that might help us debug this:
> 1 lock held by hidd/2271:
> #0: (sk_lock-AF_BLUETOOTH){--..}, at: []
> l2cap_sock_accept+0x41/0x11e [l2cap]
>
> stack backtrace:
> [] show_trace_log_lvl+0x58/0x16a
> [] show_trace+0xd/0x10
> [] dump_stack+0x19/0x1b
> [] __lock_acquire+0x6ea/0x90d
> [] lock_acquire+0x4b/0x6b
> [] lock_sock+0xac/0xbc
> [] bt_accept_dequeue+0x26/0xc6 [bluetooth]
> [] l2cap_sock_accept+0xe2/0x11e [l2cap]
> [] sys_accept+0xd8/0x179
> [] sys_socketcall+0xa7/0x186
> [] syscall_call+0x7/0xb
>
> classical case of nesting; bt_accept_dequeue() locks the children of the
> object
> locked by l2cap_sock_accept().
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> Acked-by: Marcel Holtmann <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[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 9/9] net: uninline xfrm_selector_match()
From: [EMAIL PROTECTED] Date: Wed, 08 Nov 2006 19:51:10 -0800 > From: Andrew Morton <[EMAIL PROTECTED]> > > Six callsites, huge. > > Cc: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Applied, thanks Andrew. - 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] Don't clear memory twice.
From: Ralf Baechle <[EMAIL PROTECTED]> Date: Wed, 8 Nov 2006 15:45:07 + > When dn_neigh.c was converted from kmalloc to kzalloc in commit > 0da974f4f303a6842516b764507e3c0a03f41e5a it was missed that > dn_neigh_seq_open was actually clearing the allocation twice was > missed. > > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> Applied, thanks a lot Ralf. - 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/3] mlsxfrm: Various fixes
On Thu, 9 Nov 2006, Paul Moore wrote: > It sounds like you have an idea of how you would like to see this implemented, > can you give me a rough outline? Is this the partitioned SECMARK field you > talked about earlier? No, just the fact that you are in the same kernel address space and can readily access the security context of the peer. - James -- James Morris <[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] fix up generic csum_ipv6_magic function prototype
From: "Chen, Kenneth W" <[EMAIL PROTECTED]> Date: Wed, 8 Nov 2006 18:02:06 -0800 > The generic version of csum_ipv6_magic has the len argument declared as > __u16, while most arch dependent version declare it as __u32. After > looking at the call site of this function, I come up to a conclusion > that __u32 is a better match with the actual usage. > > Hence, patch to change argument type for greater consistency. > > Signed-off-by: Ken Chen <[EMAIL PROTECTED]> Architecture implementations such as the ones for m32r and parisc have the same problem, so "for consistency" please fix them up as well. Thanks a lot. - 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] fix up generic csum_ipv6_magic function prototype
On Wed, Nov 08, 2006 at 11:00:59PM -0800, David Miller wrote: > From: "Chen, Kenneth W" <[EMAIL PROTECTED]> > Date: Wed, 8 Nov 2006 18:02:06 -0800 > > > The generic version of csum_ipv6_magic has the len argument declared as > > __u16, while most arch dependent version declare it as __u32. After > > looking at the call site of this function, I come up to a conclusion > > that __u32 is a better match with the actual usage. > > > > Hence, patch to change argument type for greater consistency. > > > > Signed-off-by: Ken Chen <[EMAIL PROTECTED]> > > Architecture implementations such as the ones for m32r and parisc have > the same problem, so "for consistency" please fix them up as well. > > Thanks a lot. Please, hold. One of the patches in my queue gets sanitized prototypes for all that stuff and it'll conflict like crazy. I haven't touch that argument yet; if there's an agreement as to what should we switch to, I'll do that. So... does everyone agree that u32 is the way to go? - 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: [take23 0/5] kevent: Generic event handling mechanism.
Davide Libenzi a écrit : On Thu, 9 Nov 2006, Eric Dumazet wrote: Davide Libenzi a ?crit : I don't care about both ways, but sys_poll() does the same thing epoll does right now, so I would not change epoll behaviour. Sure poll() cannot return a partial count, since its return value is : On success, a positive number is returned, where the number returned is the number of structures which have non-zero revents fields (in other words, those descriptors with events or errors reported). poll() is non destructive (it doesnt change any state into kernel). Returning EFAULT in case of an error in the very last bit of user area is mandatory. On the contrary : epoll_wait() does return a count of transfered events, and update some state in kernel (it consume Edge Trigered events : They can be lost forever if not reported to user) So epoll_wait() is much more like read(), that also updates file state in kernel (current file position) Lost forever means? If there are more processes watching some fd (external events), they all get their own copy of the events in their own private epoll fd. It's not that we "steal" things out of the kernel, is not a 1:1 producer/consumer thing (one producer, 1 queue). It's one producer, broadcast to all listeners (consumers) thing. The only case where it'd matter is in the case of multiple threads sharing the same epoll fd. In my particular epoll application, the producer is tcp stack, and I have one consumer. If an network event is lost in the EFAULT handling, its lost forever. In any case, my application do provide a correct user area, so this problem is only theorical. In general, I'd be more for having the userspace get his own SEGFAULT instead of letting it go with broken parameters. If I'm coding userspace, and I'm doing something wrong, I like the kernel to let me know, instead of trying to fix things for me. Also, epoll can easily be fixed (add a param to ep_reinject_items() to re-inject items in case of error/EFAULT) to leave events in the ready-list and let the EFAULT emerge. Please dont slow the hot path for a basically "User Error". It's already tested in the transfert function, with two conditional branches for each transfered event. Anyone else has opinions about this? PS: Next time it'd be great if you Cc: me when posting epoll patches, so you avoid Andrew the job of doing it. Yes, but this particular patch was a followup on own kevent Andrew patch. I have a bunch of patches for epoll I will send to you :) Eric - 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: e1000 driver 2.6.18 - how to waste processor cycles
Jesse Brandeburg wrote: included netdev... On 11/8/06, Jeff V. Merkey <[EMAIL PROTECTED]> wrote: Is there a good reason the skb refill routine in e1000_alloc_rx_buffers needs to go and touch and remap skb memory on already loaded descriptors/ This seems extremely wasteful of processor cycles when refilling the ring buffer. I note that the archtiecture has changed and is recycling buffers from the rx_irq routine and when the routine is called to refill the ring buffers, a lot of wasteful and needless calls for map_skb is occurring. we have to unmap the descriptor (or at least do pci_dma_sync_single_for_cpu / pci_dma_sync_single_for_device) because the dma API says we can't be guaranteed the cacheable memory is consistent until we do one of the afore mentioned pci dma ops. In the case I am referring to, the memory is already mapped with a previous call, which means it may be getting mapped twice. Jeff we have to do *something* before we access it. Simplest path is to unmap it and then recycle/map it. If you can show that it is faster to use pci_dma_sync_single_for_cpu and friends I'd be glad to take a patch. Hope this helps, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - 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: [take23 0/5] kevent: Generic event handling mechanism.
Eric Dumazet a écrit :
Davide Libenzi a écrit :
Lost forever means? If there are more processes watching some fd
(external events), they all get their own copy of the events in their
own private epoll fd. It's not that we "steal" things out of the
kernel, is not a 1:1 producer/consumer thing (one producer, 1 queue).
It's one producer, broadcast to all listeners (consumers) thing. The
only case where it'd matter is in the case of multiple threads sharing
the same epoll fd.
In my particular epoll application, the producer is tcp stack, and I
have one consumer. If an network event is lost in the EFAULT handling,
its lost forever. In any case, my application do provide a correct user
area, so this problem is only theorical.
I realize I was not explicit, and dit not answer your question (Lost forever
means ?)
if (epi->revents) {
if (__put_user(epi->revents,
&events[eventcnt].events) ||
__put_user(epi->event.data,
&events[eventcnt].data))
return -EFAULT;
>>if (epi->event.events & EPOLLONESHOT)
>>epi->event.events &= EP_PRIVATE_BITS;
eventcnt++;
}
If one EPOLLONESHOT event is correctly copied to user space, its status is
updated.
If other ready events in the same epoll_wait() call cannot be transferred
because of an EFAULT (we reach the real end of user provided area), this
EPOLLONESHOT event is lost forever, because it wont be requeued in ready list.
Eric
-
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
