* Re: FW: ccid2/ccid3 oopses
From: devzero @ 2008-01-09 21:28 UTC (permalink / raw)
To: gerrit; +Cc: Arnaldo Carvalho de Melo, dccp, devzero, netdev
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
> So maybe the cause triggering this oops is somewhere else.
yes, probably.
sorry - i didn`t tell or maybe i didn`t know when writing my first mail to module authors and forget to add that before forwarding here.
for me , the problem does not happen with suse kernel of the day (2.6.24-rc6-git7-20080102160500-default, .config attached) but it happens with vanilla 2.6.24-rc6 (mostly allmodconfig, also attached)
regards
roland
----- Original Message -----
From: "Gerrit Renker" <gerrit@erg.abdn.ac.uk>
To: "Arnaldo Carvalho de Melo" <acme@redhat.com>; <devzero@web.de>; <dccp@vger.kernel.org>; <netdev@vger.kernel.org>
Sent: Wednesday, January 09, 2008 3:17 PM
Subject: Re: FW: ccid2/ccid3 oopses
>| > >> the easiest way to reproduce is:
> | > >>
> | > >> while true;do modprobe dccp_ccid2/3;modprobe -r dccp_ccid2/3;done
> | > >> after short time, the kernel oopses (messages below)
> | > >>
> <snip>
> |
> | Gerrit, the control socket isn't attached to any CCID module, so the
> | CCID modules should be safe to remove, and IIRC they were safe to
> | unload.
> |
> Ah, right. I have misread the email. And can confirm the above: running
> the for-loop at the top of the message (60 seconds uninterrupted for
> CCID2,3 each) brought no oopses.
> So maybe the cause triggering this oops is somewhere else.
_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
[-- Attachment #2: working_config.gz --]
[-- Type: application/x-gzip, Size: 22013 bytes --]
[-- Attachment #3: config_where_problem_exists.gz --]
[-- Type: application/x-gzip, Size: 22143 bytes --]
^ permalink raw reply
* Re: Re : Re : Bonding : Monitoring of 4965 wireless card
From: Andy Gospodarek @ 2008-01-09 21:31 UTC (permalink / raw)
To: patnel972-linux; +Cc: John W. Linville, netdev
In-Reply-To: <168648.20508.qm@web25705.mail.ukl.yahoo.com>
On Wed, Jan 09, 2008 at 09:17:06PM +0000, patnel972-linux@yahoo.fr wrote:
> I ignore it, but it seems like it prevent bonding detect link of wlan0. I enslave wlan0 and i already use use_carrier=1;
> I use bond to have my etherenet ip in wifi at office, else the wireless connection give temporary and you must pass through proxy then.
> I'll try arp monitoring but this is annoying i c'ant test localhost. Is there a way to test localhost with arp, without pass through lo ?
>
>
>
> ----- Message d'origine ----
> De : John W. Linville <linville@tuxdriver.com>
> À : patnel972-linux@yahoo.fr
> Envoyé le : Mercredi, 9 Janvier 2008, 21h24mn 10s
> Objet : Re: Re : Bonding : Monitoring of 4965 wireless card
>
> On Wed, Jan 09, 2008 at 07:31:37PM +0000, patnel972-linux@yahoo.fr
> wrote:
> > I'm doing a bonding with my eth0(e1000 driver) and my wlan
> > card(iwl4965). It work like i want, when i'm in wifi the dhcp give
> > me my ethernet adress. When i unplug the cable, my wlan card become
> > in charge of network. My problem is when i disconnect the wlan card,
> > the bonding does not detect it correctly, and ifplugstatus show me
> > wlan0 not connected and wmaster0 connected!! The bonding module does
> > not say no active interface, it work like wlan is on.
> >
> > Am i clear?
>
> Yes, that is much more clear to me.
>
> What (if anything) are you doing to wmaster0? You should just
> ignore it.
>
> FWIW, miimon is not going to work with a mac80211-based device at
> this time. The miimon option relies on support for either miitool
> or ethtool, and mac80211 device support neither of those.
>
> Hmmm...it looks like there is a use_carrier option for miimon.
> Based on its description I would think it would work. Of course,
> I think it is supposed to be the default and you don't seem to be
> disabling it. So, I'm not sure what is happening.
>
> Are you enslaving wlan0? Or wmaster0? Make sure it is wlan0.
> Also, please add use_carrier=1 to your bonding module options.
> Does this change the behaviour? If not, please open a bug at either
> bugzilla.redhat.com (if you are a Fedora, RHEL, or even CentOS user)
> or bugzilla.kernel.org (otherwise).
>
> In the meantime, you might try using NetworkManger. Or you
> might consider using ARP monitoring. The former probably is the
> best solution if you are mobile (e.g. at a cafe or other hotspot)
> while the latter might be appropriate if you are just plugging and
> un-plugging within the same network (like at home or office).
>
> Hth!
>
John's suggestion to consider using ARP monitoring is a good one. It is
the preferred method to check for failover when link checking is not an
option (which is the case with your current setup).
^ permalink raw reply
* Re: Re : Re : Bonding : Monitoring of 4965 wireless card
From: Jay Vosburgh @ 2008-01-09 21:36 UTC (permalink / raw)
To: patnel972-linux; +Cc: John W. Linville, netdev
In-Reply-To: <168648.20508.qm@web25705.mail.ukl.yahoo.com>
patnel972-linux@yahoo.fr wrote:
>I ignore it, but it seems like it prevent bonding detect link of wlan0. I enslave wlan0 and i already use use_carrier=1;
The default for bonding is use_carrier=1, which makes bonding
use the device driver's netif_carrier_on/off state for link detection.
Bonding only checks via ethtool/mii if use_carrier=0.
>I'll try arp monitoring but this is annoying i c'ant test localhost. Is there a way to test localhost with arp, without pass through lo ?
What do you mean by "test localhost with arp, without pass
through lo"? ARP monitoring issues probes (ARPs) to a remote
destination to confirm that there is connectivity; I'm not sure what
localhost has to do with it.
In general, though, I have not tested bonding with wireless
adapters, so I'm unfamiliar with how well it does or does not work.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re : Re : Re : Bonding : Monitoring of 4965 wireless card
From: patnel972-linux @ 2008-01-09 21:52 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
I mean that instead of arp test an ip in lan or else, i want it to test 127.0.0.1 but in order to do this it must go out and re-enter and then use wlan0 to go out.
----- Message d'origine ----
De : Jay Vosburgh <fubar@us.ibm.com>
À : patnel972-linux@yahoo.fr
Cc : John W. Linville <linville@tuxdriver.com>; netdev@vger.kernel.org
Envoyé le : Mercredi, 9 Janvier 2008, 22h36mn 00s
Objet : Re: Re : Re : Bonding : Monitoring of 4965 wireless card
patnel972-linux@yahoo.fr wrote:
>I ignore it, but it seems like it prevent bonding detect link of
wlan0. I enslave wlan0 and i already use use_carrier=1;
The default for bonding is use_carrier=1, which makes bonding
use the device driver's netif_carrier_on/off state for link detection.
Bonding only checks via ethtool/mii if use_carrier=0.
>I'll try arp monitoring but this is annoying i c'ant test localhost.
Is there a way to test localhost with arp, without pass through lo ?
What do you mean by "test localhost with arp, without pass
through lo"? ARP monitoring issues probes (ARPs) to a remote
destination to confirm that there is connectivity; I'm not sure what
localhost has to do with it.
In general, though, I have not tested bonding with wireless
adapters, so I'm unfamiliar with how well it does or does not work.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
_____________________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Herbert Xu @ 2008-01-09 22:05 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Jay Vosburgh, Krzysztof Oledzki, netdev, Jeff Garzik,
David Miller
In-Reply-To: <20080109201709.GF8728@gospo.usersys.redhat.com>
On Wed, Jan 09, 2008 at 03:17:09PM -0500, Andy Gospodarek wrote:
>
> Agreed. And despite Herbert's opinion that this isn't the correct fix,
> I think this will work fine. This is one of the cases where we can take
> a write_lock(bond->lock) in softirq context, so we need to drop that (or
> make sure all the read_lock's are read_lock_bh's). The latter isn't
> really an option since having a majority of the bonding code run in
> softirq context was what we are trying to avoid with the workqueue
> conversion.
No that's not the point. The point is to move the majority of the code
into process context so that you can take the RTNL. Once you have taken
the RTNL you can disable BH all you want and I don't care one bit.
In any case, fixing a known dead-lock is important.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Jay Vosburgh @ 2008-01-09 23:19 UTC (permalink / raw)
To: Herbert Xu
Cc: Andy Gospodarek, Krzysztof Oledzki, netdev, Jeff Garzik,
David Miller
In-Reply-To: <20080109220534.GA2692@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
>On Wed, Jan 09, 2008 at 03:17:09PM -0500, Andy Gospodarek wrote:
>>
>> Agreed. And despite Herbert's opinion that this isn't the correct fix,
>> I think this will work fine. This is one of the cases where we can take
>> a write_lock(bond->lock) in softirq context, so we need to drop that (or
>> make sure all the read_lock's are read_lock_bh's). The latter isn't
>> really an option since having a majority of the bonding code run in
>> softirq context was what we are trying to avoid with the workqueue
>> conversion.
>
>No that's not the point. The point is to move the majority of the code
>into process context so that you can take the RTNL. Once you have taken
>the RTNL you can disable BH all you want and I don't care one bit.
I'm not sure how we could move more code into a process context;
much of the bonding driver is at the mercy of its callers, as in this
case. The monitoring stuff and enslave / deslave is all in a process
context now (workqueue). The transmit processing functions, for
example, can't be assumed to be in any particular context as they're
called by dev_queue_xmit.
The function in question here is the dev->set_multicast_list
method function, which is sometimes called with RTNL, and sometimes with
other random locks, but seems to always be called with netif_tx_lock_bh.
Then, bonding's bond_set_multicast_list calls dev_set_promiscuity (on
slaves), which I believe is an "RTNL only" function (which is probably
another discussion).
>In any case, fixing a known dead-lock is important.
Agreed.
I'm now thinking for just the topic at hand (the previously
posted lockdep report), something like this will resolve it:
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 77d004d..b7ac10b 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3937,8 +3937,6 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
struct bonding *bond = bond_dev->priv;
struct dev_mc_list *dmi;
- write_lock_bh(&bond->lock);
-
/*
* Do promisc before checking multicast_mode
*/
@@ -3959,6 +3957,8 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
bond_set_allmulti(bond, -1);
}
+ read_lock_bh(&bond->lock);
+
bond->flags = bond_dev->flags;
/* looking for addresses to add to slaves' mc list */
@@ -3979,7 +3979,7 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
bond_mc_list_destroy(bond);
bond_mc_list_copy(bond_dev->mc_list, bond, GFP_ATOMIC);
- write_unlock_bh(&bond->lock);
+ read_unlock_bh(&bond->lock);
}
/*
This (a) converts the write_lock_bh to a read_lock_bh, and moves
it down to not cover the promisc/allmulti code (which is protected by
RTNL). I'm not sure that this is really a signficant alteration, but
it's a bit closer to "correct."
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply related
* Re: Re : Re : Re : Bonding : Monitoring of 4965 wireless card
From: Jay Vosburgh @ 2008-01-09 23:26 UTC (permalink / raw)
To: patnel972-linux; +Cc: netdev
In-Reply-To: <416779.67064.qm@web25704.mail.ukl.yahoo.com>
patnel972-linux@yahoo.fr wrote:
>I mean that instead of arp test an ip in lan or else, i want it to test 127.0.0.1 but in order to do this it must go out and re-enter and then use wlan0 to go out.
In other words, what I think you're saying (and I'm not entirely
sure here) is that you want probes to go to a remote node on the
network, and back, without having to actually know the identity of the
remote node (because, presumably, on a roaming type of wireless
configuration, your gateway and whatnot can change from time to time).
Is that what you're looking for?
That isn't available now, but might be straightforward to plug
into the address update system to keep the arp_ip_target up to date as
the current gateway as the gateway changes. I haven't looked into the
details of doing that, but in theory it sounds straightforward.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>
>----- Message d'origine ----
>De : Jay Vosburgh <fubar@us.ibm.com>
>À : patnel972-linux@yahoo.fr
>Cc : John W. Linville <linville@tuxdriver.com>; netdev@vger.kernel.org
>Envoyé le : Mercredi, 9 Janvier 2008, 22h36mn 00s
>Objet : Re: Re : Re : Bonding : Monitoring of 4965 wireless card
>
>patnel972-linux@yahoo.fr wrote:
>
>>I ignore it, but it seems like it prevent bonding detect link of
> wlan0. I enslave wlan0 and i already use use_carrier=1;
>
> The default for bonding is use_carrier=1, which makes bonding
>use the device driver's netif_carrier_on/off state for link detection.
>Bonding only checks via ethtool/mii if use_carrier=0.
>
>>I'll try arp monitoring but this is annoying i c'ant test localhost.
> Is there a way to test localhost with arp, without pass through lo ?
>
> What do you mean by "test localhost with arp, without pass
>through lo"? ARP monitoring issues probes (ARPs) to a remote
>destination to confirm that there is connectivity; I'm not sure what
>localhost has to do with it.
>
> In general, though, I have not tested bonding with wireless
>adapters, so I'm unfamiliar with how well it does or does not work.
>
> -J
>
>---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>
>
>
>
>
> _____________________________________________________________________________
>Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Bugme-new] [Bug 9719] New: when a system is configured as a bridge, and at the same time configured to have multipath weighted route, with one leg goes thru NAT and another without NAT, the nat path will intermittently get packets leaking out using internal IP without being SNAT-ted
From: Andrew Morton @ 2008-01-09 23:28 UTC (permalink / raw)
To: mingching.tiew; +Cc: bugme-daemon, netdev
In-Reply-To: <bug-9719-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 9 Jan 2008 11:55:50 -0800 (PST)
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9719
>
> Summary: when a system is configured as a bridge, and at the same
> time configured to have multipath weighted route, with
> one leg goes thru NAT and another without NAT, the nat
> path will intermittently get packets leaking out using
> internal IP without being SNAT-ted
> Product: Networking
> Version: 2.5
> KernelVersion: 2.6.22.15 and 2.6.23
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Netfilter/Iptables
> AssignedTo: networking_netfilter-iptables@kernel-bugs.osdl.org
> ReportedBy: mingching.tiew@redtone.com
>
>
> Latest working kernel version: 2.6.23
> Earliest failing kernel version: 2.6.22.15
This doesn't make sense. What we're trying to ask here (and we've been
unable to find a pair of questions which 100% of reporters can successfully
answer) is whether this is a regression, and in which kernel release did we
regress?
In other words: did we break it, and if so, when did we break it?
> Distribution: iptables 1.4.0 was used with kernel 2.6.23 and iptables 1.3.8
> with 2.6.22.15
> Hardware Environment: 3 interfaces, 2 interfaces bridged to form br0, and
> another connects to internet using pppoe.
> Software Environment: bridge, multipath routing
> Problem Description: when a system is configured as a bridge with IP assigned
> to br0 interface, and at the same time it is configured to have multipath
> weighted default route, and one of the default route is NAT-ed and another of
> the default route is not NAT-ed, then it is NAT-ed interface will occasionally
> get packets leaking out to it with packets with private IPs.
>
> Steps to reproduce:
> 1) setup the bridge interface and assign an IP to it
> 2) setup an default gateway on side B of the bridge ( without NAT ) and default
> route the bridge to this gateway.
> 3) Setup a client on side A of the bridge and default route to the bridge br0
> interface.
> 4) Start ping'ing an internet site, for example www.google.com from the client.
> Run the ping continuously, for example :-
> while true
> do
> ping -c 1 www.google.com
> sleep 1
> done
> 5) after successfully and consistently getting a ping response from the
> www.google.com, on the bridge system start up another uplink to the internet,
> but this uplink is SNAT-ed
>
> ( eg iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE )
>
> 6) verify and make sure that the second uplink is working.
> 7) change the default route on the bridge to multipath weighted route with
> equal weight on both the uplinks.
> 8) sniff the NAT-ed inteface for packets coming in from the LAN client.
> Occasionallly packets with private IP leaks to the NAT-ed interface.
>
^ permalink raw reply
* Re: Linux IPv6 DAD not full conform to RFC 4862 ?
From: David Miller @ 2008-01-09 23:32 UTC (permalink / raw)
To: kkeil; +Cc: netdev
In-Reply-To: <20080109153656.GA16962@pingi.kke.suse.de>
From: Karsten Keil <kkeil@suse.de>
Date: Wed, 9 Jan 2008 16:36:56 +0100
> If the address is a link-local address formed from an interface
> identifier based on the hardware address, which is supposed to be
> uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
> operation on the interface SHOULD be disabled. By disabling IP
> operation, the node will then:
>
> - not send any IP packets from the interface,
>
> - silently drop any IP packets received on the interface, and
>
> - not forward any IP packets to the interface (when acting as a
> router or processing a packet with a Routing header).
I question any RFC mandate that shuts down IP communication on a node
because of packets received from remote systems.
If the TAHI test can trigger this, so can a compromised system on your
network and won't that be fun? :-)
^ permalink raw reply
* Re: [PATCH 0/0]: Cassini bug fixes.
From: David Miller @ 2008-01-09 23:33 UTC (permalink / raw)
To: panther; +Cc: netdev, bazsi, hidden
In-Reply-To: <4784F293.9050707@balabit.hu>
From: Laszlo Attila Toth <panther@balabit.hu>
Date: Wed, 09 Jan 2008 17:13:07 +0100
> We tested the card, it works well, all previous bugs are gone (truesize
> bug messages and memory comsumption).
Thank you for testing.
^ permalink raw reply
* Re: Linux IPv6 DAD not full conform to RFC 4862 ?
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-01-09 23:46 UTC (permalink / raw)
To: davem; +Cc: kkeil, netdev, yoshfuji
In-Reply-To: <20080109.153212.144388472.davem@davemloft.net>
In article <20080109.153212.144388472.davem@davemloft.net> (at Wed, 09 Jan 2008 15:32:12 -0800 (PST)), David Miller <davem@davemloft.net> says:
> I question any RFC mandate that shuts down IP communication on a node
> because of packets received from remote systems.
RFC4862 tell us that we SHOULD disable IP communication.
(IP means IPv6 here; IPv4 is out of scope.)
In IETF term, a SHOULD is almost a MUST. We are required to follow
unless we have very good reason to ignore it.
> If the TAHI test can trigger this, so can a compromised system on your
> network and won't that be fun? :-)
So, I know the specification, but I have ignored it.
I think it is fine to implent in some way, but I do think we must have
a switch not to do this.
--yoshfuji
^ permalink raw reply
* Re: [PATCH 1/3] drivers/net/ipg.c: Fix skbuff leak
From: Francois Romieu @ 2008-01-09 23:30 UTC (permalink / raw)
To: linux; +Cc: akpm, davem, netdev
In-Reply-To: <20080109003840.22917.qmail@science.horizon.com>
linux@horizon.com <linux@horizon.com> :
[...]
> That doesn't seem to do it. Not entirely, at least. After downloading
> and partially re-uploading an 800M file, slabtop reports:
Ok, enjoy this one. It is definitely better wrt the current problem.
More work tomorrow.
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..42f300d 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -860,18 +860,18 @@ static void ipg_nic_txfree(struct net_device *dev)
void __iomem *ioaddr = sp->ioaddr;
unsigned int curr;
u64 txd_map;
- unsigned int released, pending;
+ unsigned int released, pending, dirty;
txd_map = (u64)sp->txd_map;
curr = ipg_r32(TFD_LIST_PTR_0) -
do_div(txd_map, sizeof(struct ipg_tx)) - 1;
IPG_DEBUG_MSG("_nic_txfree\n");
pending = sp->tx_current - sp->tx_dirty;
+ dirty = sp->tx_dirty % IPG_TFDLIST_LENGTH;
for (released = 0; released < pending; released++) {
- unsigned int dirty = sp->tx_dirty % IPG_TFDLIST_LENGTH;
struct sk_buff *skb = sp->TxBuff[dirty];
struct ipg_tx *txfd = sp->txd + dirty;
@@ -882,8 +884,11 @@ static void ipg_nic_txfree(struct net_device *dev)
* If the TFDDone bit is set, free the associated
* buffer.
*/
- if (dirty == curr)
+ if (!(txfd->tfc & cpu_to_le64(IPG_TFC_TFDDONE))) {
+ printk(KERN_INFO "%s: released = %d pending = %d\n",
+ dev->name, released, pending);
break;
+ }
/* Setup TFDDONE for compatible issue. */
txfd->tfc |= cpu_to_le64(IPG_TFC_TFDDONE);
@@ -898,6 +903,7 @@ static void ipg_nic_txfree(struct net_device *dev)
sp->TxBuff[dirty] = NULL;
}
+ dirty = (dirty + 1) % IPG_TFDLIST_LENGTH;
}
sp->tx_dirty += released;
@@ -1943,10 +1948,7 @@ static int ipg_nic_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
*/
if (sp->tenmbpsmode)
txfd->tfc |= cpu_to_le64(IPG_TFC_TXINDICATE);
- else if (!((sp->tx_current - sp->tx_dirty + 1) >
- IPG_FRAMESBETWEENTXDMACOMPLETES)) {
- txfd->tfc |= cpu_to_le64(IPG_TFC_TXDMAINDICATE);
- }
+ txfd->tfc |= cpu_to_le64(IPG_TFC_TXDMAINDICATE);
/* Based on compilation option, determine if FCS is to be
* appended to transmit frame by IPG.
*/
@@ -2003,7 +2005,7 @@ static int ipg_nic_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
ipg_w32(IPG_DC_TX_DMA_POLL_NOW, DMA_CTRL);
if (sp->tx_current == (sp->tx_dirty + IPG_TFDLIST_LENGTH))
- netif_wake_queue(dev);
+ netif_stop_queue(dev);
spin_unlock_irqrestore(&sp->lock, flags);
--
Ueimor
Anybody got a battery for my Ultra 10 ?
^ permalink raw reply related
* Re: [PATCH 1/3] drivers/net/ipg.c: Fix skbuff leak
From: Francois Romieu @ 2008-01-09 23:34 UTC (permalink / raw)
To: David Miller; +Cc: linux, akpm, netdev
In-Reply-To: <20080109.003952.25384040.davem@davemloft.net>
David Miller <davem@davemloft.net> :
[...]
> all resolved. All of that code cleanup stuff needs to wait
> until later, let's fix bugs before adding new ones. :-)
Yes.
I should be able to test your r8169 NAPI changes tomorrow.
--
Ueimor
^ permalink raw reply
* Re: Linux IPv6 DAD not full conform to RFC 4862 ?
From: David Miller @ 2008-01-09 23:55 UTC (permalink / raw)
To: yoshfuji; +Cc: kkeil, netdev
In-Reply-To: <20080110.084655.66182071.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Thu, 10 Jan 2008 08:46:55 +0900 (JST)
> In article <20080109.153212.144388472.davem@davemloft.net> (at Wed, 09 Jan 2008 15:32:12 -0800 (PST)), David Miller <davem@davemloft.net> says:
>
> > I question any RFC mandate that shuts down IP communication on a node
> > because of packets received from remote systems.
>
> RFC4862 tell us that we SHOULD disable IP communication.
> (IP means IPv6 here; IPv4 is out of scope.)
> In IETF term, a SHOULD is almost a MUST. We are required to follow
> unless we have very good reason to ignore it.
A DoS by definition is a very good reason.
> > If the TAHI test can trigger this, so can a compromised system on your
> > network and won't that be fun? :-)
>
> So, I know the specification, but I have ignored it.
> I think it is fine to implent in some way, but I do think we must have
> a switch not to do this.
Because of the above, the existing behavior must still stay the
default. I hope this is your plan.
By default Linux will not implement this SHOULD, it's a security
issue.
I more and more do not like these conformance tests, they leave no
room whatsoever for handling bugs or ill-specified features in the
specification.
^ permalink raw reply
* Re: [PATCH 1/3] drivers/net/ipg.c: Fix skbuff leak
From: David Miller @ 2008-01-09 23:56 UTC (permalink / raw)
To: romieu; +Cc: linux, akpm, netdev
In-Reply-To: <20080109233458.GB5673@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 10 Jan 2008 00:34:58 +0100
> David Miller <davem@davemloft.net> :
> [...]
> > all resolved. All of that code cleanup stuff needs to wait
> > until later, let's fix bugs before adding new ones. :-)
>
> Yes.
>
> I should be able to test your r8169 NAPI changes tomorrow.
Thank you.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
From: Andrew Morton @ 2008-01-10 0:03 UTC (permalink / raw)
To: netdev, linux-acpi; +Cc: bugme-daemon, supersud501
In-Reply-To: <bug-9721-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 9 Jan 2008 13:05:34 -0800 (PST)
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9721
>
> Summary: wake on lan fails with sky2 module
> Product: ACPI
> Version: 2.5
> KernelVersion: 2.6.24-rc7
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Power-Sleep-Wake
> AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org
> ReportedBy: supersud501@yahoo.de
This post-2.6.23 regression was assigned to ACPI but is quite possibly a
net driver problem?
>
> Latest working kernel version: 2.6.23.12
> Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel,
> 2.6.24-rc7 still failing)
> Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet
> to make wake on lan work, i.e. network cards are not shutted down on poweroff)
> Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
> Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2
> Software Environment:
> Problem Description:
>
> When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following
> status:
>
> 21:56:29 ~ # sudo ethtool eth0
> Settings for eth0:
> Supported ports: [ TP ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised auto-negotiation: Yes
> Speed: 100Mb/s
> Duplex: Full
> Port: Twisted Pair
> PHYAD: 0
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: pg
> Wake-on: g <---- wol enabled
> Current message level: 0x000000ff (255)
> Link detected: yes
>
> but after shutting down the pc doesn't wake up when magic packet is sent.
>
> the status lights of the network card are still on (so the card seems to be
> online).
>
> same system with only changed kernel to 2.6.23.12 and same procedure like
> above: wake on lan works.
>
> Steps to reproduce: enable wol on your network card using SKY2 module and it
> doesn't work too?
>
> if you need more information, just tell me, it's my first bug report.
> regards
>
>
> --
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: Linux IPv6 DAD not full conform to RFC 4862 ?
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-01-10 0:09 UTC (permalink / raw)
To: davem; +Cc: kkeil, netdev, yoshfuji
In-Reply-To: <20080109.155544.136768603.davem@davemloft.net>
In article <20080109.155544.136768603.davem@davemloft.net> (at Wed, 09 Jan 2008 15:55:44 -0800 (PST)), David Miller <davem@davemloft.net> says:
> Because of the above, the existing behavior must still stay the
> default. I hope this is your plan.
>
> By default Linux will not implement this SHOULD, it's a security
> issue.
Yes so far, though we may have more things to consider.
--yoshfuji
^ permalink raw reply
* Re: [Bugme-new] [Bug 9719] New: when a system is configured as a bridge, and at the same time configured to have multipath weighted route, with one leg goes thru NAT and another without NAT, the nat path will intermittently get packets leaking out using internal IP without being SNAT-ted
From: Ming-Ching Tiew @ 2008-01-10 13:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugme-daemon, netdev
In-Reply-To: <20080109152813.83fb8168.akpm@linux-foundation.org>
Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Wed, 9 Jan 2008 11:55:50 -0800 (PST)
> bugme-daemon@bugzilla.kernel.org wrote:
>
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=9719
>>
>> Summary: when a system is configured as a bridge, and at the same
>> time configured to have multipath weighted route, with
>> one leg goes thru NAT and another without NAT, the nat
>> path will intermittently get packets leaking out using
>> internal IP without being SNAT-ted
>> Product: Networking
>> Version: 2.5
>> KernelVersion: 2.6.22.15 and 2.6.23
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Netfilter/Iptables
>> AssignedTo: networking_netfilter-iptables@kernel-bugs.osdl.org
>> ReportedBy: mingching.tiew@redtone.com
>>
>>
>> Latest working kernel version: 2.6.23
>> Earliest failing kernel version: 2.6.22.15
>>
>
> This doesn't make sense. What we're trying to ask here (and we've been
> unable to find a pair of questions which 100% of reporters can successfully
> answer) is whether this is a regression, and in which kernel release did we
> regress?
>
> In other words: did we break it, and if so, when did we break it?
>
Sorry for the confusion and for such a lousy first time bug reporter.
I realized that mistake immediately after I posted it on the web
interface. However, the web interface does not seem to allow me to
correct that.
What I meant was that it failed on both the kernel versions I tested. I
am afraid it is a problem which exists all a long. Perhaps it has been
broken quite sometime already. I need to go back to try some older
kernel version and see if I could repeat the problem.
Regards.
^ permalink raw reply
* Re: 2.6.24-rc6-mm1
From: FUJITA Tomonori @ 2008-01-10 0:54 UTC (permalink / raw)
To: jarkao2
Cc: fujita.tomonori, mingo, akpm, just.for.lkml, tomof, herbert,
linux-kernel, neilb, bfields, netdev, tom
In-Reply-To: <20080109090442.GA1746@ff.dom.local>
On Wed, 9 Jan 2008 10:04:42 +0100
Jarek Poplawski <jarkao2@gmail.com> wrote:
> On Wed, Jan 09, 2008 at 08:57:53AM +0900, FUJITA Tomonori wrote:
> ...
> > diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> > new file mode 100644
> > index 0000000..495575a
> > --- /dev/null
> > +++ b/lib/iommu-helper.c
> > @@ -0,0 +1,80 @@
> > +/*
> > + * IOMMU helper functions for the free area management
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/bitops.h>
> > +
> > +static unsigned long find_next_zero_area(unsigned long *map,
> > + unsigned long size,
> > + unsigned long start,
> > + unsigned int nr,
> > + unsigned long align_mask)
> > +{
> > + unsigned long index, end, i;
> > +again:
> > + index = find_next_zero_bit(map, size, start);
> > +
> > + /* Align allocation */
> > + index = (index + align_mask) & ~align_mask;
> > +
> > + end = index + nr;
> > + if (end >= size)
> > + return -1;
>
> This '>=' looks doubtful to me, e.g.:
> map points to 0s only, size = 64, nr = 64,
> we get: index = 0; end = 64;
> and: return -1 ?!
You are right. I did it only because I didn't want to change the
original code (iommu_range_alloc in arch/powerpc/kernel/iommu.c). I
thought that there might be a mysterious reason for it so I let it
alone since it's tiny loss.
Thanks,
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Herbert Xu @ 2008-01-10 0:58 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Andy Gospodarek, Krzysztof Oledzki, netdev, Jeff Garzik,
David Miller
In-Reply-To: <7603.1199920750@death>
On Wed, Jan 09, 2008 at 03:19:10PM -0800, Jay Vosburgh wrote:
>
> >No that's not the point. The point is to move the majority of the code
> >into process context so that you can take the RTNL. Once you have taken
> >the RTNL you can disable BH all you want and I don't care one bit.
>
> I'm not sure how we could move more code into a process context;
> much of the bonding driver is at the mercy of its callers, as in this
> case. The monitoring stuff and enslave / deslave is all in a process
> context now (workqueue). The transmit processing functions, for
> example, can't be assumed to be in any particular context as they're
> called by dev_queue_xmit.
No I'm not calling for you to move any more code into process context.
I was replying to the comment that changing the read_lock calls in
process context to read_lock_bh somehow undoes the benefit of moving
softirq code into process context. It does not since the point of the
move is to be able to take the RTNL, which you can still do as long as
you do it before you disable BH.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: AF_UNIX MSG_PEEK bug?
From: Herbert Xu @ 2008-01-10 0:01 UTC (permalink / raw)
To: Brent Casavant; +Cc: penguin-kernel, netdev, davem, linux-kernel
In-Reply-To: <alpine.BSF.1.00.0801091201180.35527@pkunk.americas.sgi.com>
Brent Casavant <bcasavan@sgi.com> wrote:
>
>> Did you try MSG_WAITALL flag? See "man 2 recv".
>> A TCP socket handles data in bytes.
>> You cannot complain if the amount received by recv() is smaller than expected
>> unless you use MSG_WAITALL flag.
>
> Yes. It made no difference, as noted in the comments in the
> provided test program.
The POSIX text for MSG_WAITALL actually says that when used in
conjunction with MSG_PEEK it may not return the full data.
Having said that, I do agree that having TCP and AF_UNIX behave
in the same way is a plus. However, if you really want this to
happen it would help if you had attached a patch :)
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: AF_UNIX MSG_PEEK bug?
From: Brent Casavant @ 2008-01-10 1:19 UTC (permalink / raw)
To: Herbert Xu; +Cc: penguin-kernel, netdev, davem, linux-kernel
In-Reply-To: <E1JCkrp-0000vX-00@gondolin.me.apana.org.au>
On Thu, 10 Jan 2008, Herbert Xu wrote:
> The POSIX text for MSG_WAITALL actually says that when used in
> conjunction with MSG_PEEK it may not return the full data.
That's fine. The problem is that the peek operation returns less
data than requested even when sufficient data is available on the
receive queue.
> However, if you really want this to
> happen it would help if you had attached a patch :)
A patch is definitely in progress. I'm a little confused as
to the difference between unix_detach_fds() and scm_fp_dup()
in the MSG_PEEK versus !MSG_PEEK paths in unix_stream_recvmsg(),
however once I figure that out a patch should be forthcoming.
Brent
--
Brent Casavant All music is folk music. I ain't
bcasavan@sgi.com never heard a horse sing a song.
Silicon Graphics, Inc. -- Louis Armstrong
^ permalink raw reply
* Re: AF_UNIX MSG_PEEK bug?
From: Brent Casavant @ 2008-01-10 2:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: penguin-kernel, netdev, davem, linux-kernel
In-Reply-To: <E1JCkrp-0000vX-00@gondolin.me.apana.org.au>
On Thu, 10 Jan 2008, Herbert Xu wrote:
> Having said that, I do agree that having TCP and AF_UNIX behave
> in the same way is a plus. However, if you really want this to
> happen it would help if you had attached a patch :)
The following patch appears to fix the problem. However, I would
really appreciate if someone more familiar with UNIX credential
passing could review what I did here and provide some feedback.
It wasn't at all clear to me why the MSG_PEEK and !MSG_PEEK code
paths were taking different actions regarding credentials, so I
unified them to behave the same way as the !MSG_PEEK code path.
I haven't tested credential passing under this new code yet, but
hope to do so tomorrow. Again, a review with an eye towards
that area would be most appreciated.
The various test cases I had which tripped this bug now pass without
incident. Also, if netstat is to be believed, quite a few programs
which utilize AF_UNIX sockets (e.g. hald, dbus, acpid) are running
very contentedly on the test system, so at least I didn't severely
break anything, possible UNIX credential issues notwithstanding.
Note: I'm not proposing this patch be integrated yet -- I'm throwing
it out here as a starting point.
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 060bba4..2ffdf5b 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -50,6 +50,9 @@
* Arnaldo C. Melo : Remove MOD_{INC,DEC}_USE_COUNT,
* the core infrastructure is doing that
* for all net proto families now (2.5.69+)
+ * Brent Casavant : SOCK_STREAM MSG_PEEK should peek
+ * far enough ahead to satisfy the request
+ * rather than stop after the first skb.
*
*
* Known differences from reference BSD that was tested:
@@ -1750,6 +1753,8 @@ static int unix_stream_recvmsg(struct ki
int target;
int err = 0;
long timeo;
+ struct sk_buff *skb;
+ struct sk_buff_head peek_stack;
err = -EINVAL;
if (sk->sk_state != TCP_ESTABLISHED)
@@ -1759,6 +1764,9 @@ static int unix_stream_recvmsg(struct ki
if (flags&MSG_OOB)
goto out;
+ if (flags & MSG_PEEK)
+ skb_queue_head_init(&peek_stack);
+
target = sock_rcvlowat(sk, flags&MSG_WAITALL, size);
timeo = sock_rcvtimeo(sk, flags&MSG_DONTWAIT);
@@ -1778,7 +1786,6 @@ static int unix_stream_recvmsg(struct ki
do
{
int chunk;
- struct sk_buff *skb;
unix_state_lock(sk);
skb = skb_dequeue(&sk->sk_receive_queue);
@@ -1845,39 +1852,31 @@ static int unix_stream_recvmsg(struct ki
copied += chunk;
size -= chunk;
- /* Mark read part of skb as used */
- if (!(flags & MSG_PEEK))
- {
- skb_pull(skb, chunk);
-
- if (UNIXCB(skb).fp)
- unix_detach_fds(siocb->scm, skb);
+ /* Credential passing */
+ if (UNIXCB(skb).fp)
+ unix_detach_fds(siocb->scm, skb);
- /* put the skb back if we didn't use it up.. */
+ if (!(flags & MSG_PEEK)) {
+ /* Mark read part of skb as used */
+ skb_pull(skb, chunk);
+ /* Return unused portion or free skb */
if (skb->len)
- {
skb_queue_head(&sk->sk_receive_queue, skb);
- break;
- }
-
- kfree_skb(skb);
-
- if (siocb->scm->fp)
- break;
- }
- else
- {
- /* It is questionable, see note in unix_dgram_recvmsg.
- */
- if (UNIXCB(skb).fp)
- siocb->scm->fp = scm_fp_dup(UNIXCB(skb).fp);
+ else
+ kfree_skb(skb);
+ } else
+ __skb_queue_head(&peek_stack, skb);
- /* put message back and return */
- skb_queue_head(&sk->sk_receive_queue, skb);
+ /* Stop early when passed credentials are encountered */
+ if (siocb->scm->fp)
break;
- }
} while (size);
+ /* Push all peeked skbs back onto receive queue */
+ if (flags & MSG_PEEK)
+ while ((skb = __skb_dequeue(&peek_stack)))
+ skb_queue_head(&sk->sk_receive_queue, skb);
+
mutex_unlock(&u->readlock);
scm_recv(sock, msg, siocb->scm, flags);
out:
^ permalink raw reply related
* Re: AF_UNIX MSG_PEEK bug?
From: Stephen Hemminger @ 2008-01-10 3:05 UTC (permalink / raw)
To: Brent Casavant; +Cc: netdev
In-Reply-To: <alpine.BSF.1.00.0801092031290.35527@pkunk.americas.sgi.com>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 060bba4..2ffdf5b 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -50,6 +50,9 @@
> * Arnaldo C. Melo : Remove MOD_{INC,DEC}_USE_COUNT,
> * the core infrastructure is doing that
> * for all net proto families now (2.5.69+)
> + * Brent Casavant : SOCK_STREAM MSG_PEEK should peek
> + * far enough ahead to satisfy the request
> + * rather than stop after the first skb.
> *
> *
The kernel doesn't use comments as a changlog anymore, that was so last century.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [Bugme-new] [Bug 9719] New: when a system is configured as a bridge, and at the same time configured to have multipath weighted route, with one leg goes thru NAT and another without NAT, the nat path will intermittently get packets leaking out using internal IP without being SNAT-ted
From: Ming-Ching Tiew @ 2008-01-10 16:32 UTC (permalink / raw)
To: Ming-Ching Tiew; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <4786187E.3090000@redtone.com>
Ming-Ching Tiew wrote:
>
> What I meant was that it failed on both the kernel versions I tested.
> I am afraid it is a problem which exists all a long. Perhaps it has
> been broken quite sometime already. I need to go back to try some
> older kernel version and see if I could repeat the problem.
OK based on the I repeat the problem, so far I could not find such
misbehaviour on kernel 2.6.18. I will do more tests to make it more
conclusive.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox