* Re: [RFC v3 1/6] can: extend sockaddr_can to include j1939 members
From: Kurt Van Dijck @ 2011-03-14 14:53 UTC (permalink / raw)
To: Eric Dumazet
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1300112100.3423.24.camel@edumazet-laptop>
On Mon, Mar 14, 2011 at 03:15:00PM +0100, Eric Dumazet wrote:
> > +/*
> > + * required_size
> > + * macro to find the minimum size of a struct
> > + * that includes a requested member
> > + */
> > +#define required_size(member, struct_type) \
> > + (offsetof(typeof(struct_type), member) + \
> > + sizeof(((typeof(struct_type) *)(0))->member))
> > +
>
> Hmm, most similar macros reverse arguments.
>
> (For example : offsetof())
I had 'list_entry' in mind.
>
> What about
>
> #define required_size(TYPE, MEMBER) ...
I'm not against that ...
If I receive no complaint for that, I can alter this in the next series.
>
>
Thanks,
Kurt
^ permalink raw reply
* [PATCH] Fix "possible circular locking dependency" in rfcomm
From: Ferraton, Jean RegisX @ 2011-03-14 14:56 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: marcel@holtmann.org, davem@davemloft.net, eric.dumazet@gmail.com,
xiaosuo@gmail.com, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <6E42A1B4DD2F7B4D80A1F26BB498BF9F8C9F86D162@irsmsx501.ger.corp.intel.com>
No response from original post, submit again, more details below:
Changes in sock.c in function __rfcomm_sock_close, to release sock before calling rfcomm_dlc_close to avoid possible deadlock when calling rfcomm_lock (in rfcomm_dlc_close).
Signed-off-by: Jean Regis Ferraton <jrferraton@gmail.com>
---
net/bluetooth/rfcomm/sock.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c index 66cc1f0..3b5ec09 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -234,7 +234,10 @@ static void __rfcomm_sock_close(struct sock *sk)
case BT_CONNECT2:
case BT_CONFIG:
case BT_CONNECTED:
+ /* release_sock to avoid deadlock when calling rfcomm_lock() */
+ release_sock(sk);
rfcomm_dlc_close(d, 0);
+ lock_sock(sk);
default:
sock_set_flag(sk, SOCK_ZAPPED);
--
1.6.2.5
This patch solves a problem of "possible circular locking dependency" related to rfcomm. Problem seen on kernel 2.6.37. Maybe it's not a bug, just a warning, see the trace below.
This problem occurs in 2 cases:
1- When initiating a connection from the remote device
2- When browsing my BT device from my PC
My analysis is the following:
1- We call the function rfcomm_sock_shutdown() which locks a socket, an after calls __rfcomm_sock_close()
lock_sock(sk);
if (!sk->sk_shutdown) {
sk->sk_shutdown = SHUTDOWN_MASK;
__rfcomm_sock_close(sk);
2- In the function __rfcomm_sock_close(), we call rfcomm_dlc_close()
case BT_CONNECTED:
rfcomm_dlc_close(d, 0);
3- In the function rfcomm_dlc_close(), we call rfcomm_lock() which locks a mutex on rfcomm, and this second lock causes the problem.
rfcomm_lock();
r = __rfcomm_dlc_close(d, err);
My message trace is the following (for remote connect):
[ 113.995511] =======================================================
[ 114.001897] [ INFO: possible circular locking dependency detected ]
[ 114.008157] 2.6.37.3jrf_fix #1
[ 114.011196] -------------------------------------------------------
[ 114.017457] bluetoothd/511 is trying to acquire lock:
[ 114.022499] (rfcomm_mutex){+.+.+.}, at: [<c14f281a>] rfcomm_dlc_close+0x15/0x30
[ 114.029887]
[ 114.029892] but task is already holding lock:
[ 114.035713] (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c14f4cfe>] rfcomm_sock_shutdown+0x17/0x5d
[ 114.044147]
[ 114.044152] which lock already depends on the new lock.
[ 114.044158]
[ 114.052319]
[ 114.052324] the existing dependency chain (in reverse order) is:
[ 114.059796]
[ 114.059801] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
[ 114.065967] [<c105d660>] lock_acquire+0xf9/0x135
[ 114.071184] [<c1445cf3>] lock_sock_nested+0x55/0x65
[ 114.076662] [<c14ed17d>] l2cap_sock_sendmsg+0x3f/0x606
[ 114.082400] [<c1443775>] sock_sendmsg+0xc9/0xe0
[ 114.087530] [<c14437b4>] kernel_sendmsg+0x28/0x37
[ 114.092833] [<c14f2278>] rfcomm_send_frame+0x2f/0x37
[ 114.098398] [<c14f232c>] rfcomm_send_ua+0x57/0x59
[ 114.103701] [<c14f3884>] rfcomm_run+0x431/0xb06
[ 114.108830] [<c104bc8f>] kthread+0x5f/0x64
[ 114.113525] [<c1002b7a>] kernel_thread_helper+0x6/0x1a
[ 114.119265]
[ 114.119270] -> #0 (rfcomm_mutex){+.+.+.}:
[ 114.124739] [<c105cff1>] __lock_acquire+0xe03/0x1379
[ 114.130304] [<c105d660>] lock_acquire+0xf9/0x135
[ 114.135522] [<c1522bf3>] mutex_lock_nested+0x45/0x286
[ 114.141171] [<c14f281a>] rfcomm_dlc_close+0x15/0x30
[ 114.146650] [<c14f4cdb>] __rfcomm_sock_close+0x5e/0x6a
[ 114.152388] [<c14f4d12>] rfcomm_sock_shutdown+0x2b/0x5d
[ 114.158212] [<c14f4d5d>] rfcomm_sock_release+0x19/0x60
[ 114.163951] [<c14445da>] sock_release+0x14/0x5b
[ 114.169080] [<c144463d>] sock_close+0x1c/0x20
[ 114.174037] [<c10bdd19>] fput+0xfa/0x19e
[ 114.178557] [<c10bb3c5>] filp_close+0x51/0x5b
[ 114.183512] [<c10bb488>] sys_close+0xb9/0xee
[ 114.188381] [<c1002650>] sysenter_do_call+0x12/0x36
[ 114.193858]
[ 114.193863] other info that might help us debug this:
[ 114.193870]
[ 114.201860] 1 lock held by bluetoothd/511:
[ 114.205945] #0: (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c14f4cfe>] rfcomm_sock_shutdown+0x17/0x5d
[ 114.214811]
[ 114.214816] stack backtrace:
[ 114.219167] Pid: 511, comm: bluetoothd Tainted: G WC 2.6.37.3jrf_fix #1
[ 114.226463] Call Trace:
[ 114.228913] [<c152108a>] ? printk+0xf/0x11
[ 114.233086] [<c105bc3b>] print_circular_bug+0x90/0x9c
[ 114.238211] [<c105cff1>] __lock_acquire+0xe03/0x1379
[ 114.243260] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
[ 114.248382] [<c105d660>] lock_acquire+0xf9/0x135
[ 114.253079] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
[ 114.258208] [<c1522bf3>] mutex_lock_nested+0x45/0x286
[ 114.263338] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
[ 114.268469] [<c105b68d>] ? trace_hardirqs_on_caller+0x100/0x121
[ 114.274467] [<c1445cf8>] ? lock_sock_nested+0x5a/0x65
[ 114.279597] [<c105b6b9>] ? trace_hardirqs_on+0xb/0xd
[ 114.284639] [<c14f281a>] rfcomm_dlc_close+0x15/0x30
[ 114.289594] [<c14f4cdb>] __rfcomm_sock_close+0x5e/0x6a
[ 114.294811] [<c14f4d12>] rfcomm_sock_shutdown+0x2b/0x5d
[ 114.300115] [<c14f4d5d>] rfcomm_sock_release+0x19/0x60
[ 114.305331] [<c14445da>] sock_release+0x14/0x5b
[ 114.309937] [<c144463d>] sock_close+0x1c/0x20
[ 114.314373] [<c10bdd19>] fput+0xfa/0x19e
[ 114.318371] [<c10bb3c5>] filp_close+0x51/0x5b
[ 114.322804] [<c10bb488>] sys_close+0xb9/0xee
[ 114.327151] [<c1002650>] sysenter_do_call+0x12/0x36
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: [RFC v3 3/6] can: make struct proto const
From: Kurt Van Dijck @ 2011-03-14 15:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1300111755.3423.20.camel@edumazet-laptop>
On Mon, Mar 14, 2011 at 03:09:15PM +0100, Eric Dumazet wrote:
> Le lundi 14 mars 2011 à 14:47 +0100, Kurt Van Dijck a écrit :
> > can_ioctl is the only reason for struct proto to be non-const.
> > script/check-patch.pl suggests struct proto be const.
> > This patch performs the necessary change.
> >
> > static void can_sock_destruct(struct sock *sk)
> > {
> > @@ -720,10 +721,6 @@ int can_proto_register(const struct can_proto *cp)
> > err = -EBUSY;
> > } else {
> > proto_tab[proto] = cp;
> > -
> > - /* use generic ioctl function if not defined by module */
> > - if (!cp->ops->ioctl)
> > - cp->ops->ioctl = can_ioctl;
>
> Hmm, you actually fixed a race / bug, since we installed in proto_tab[]
> a pointer to a not yet initted ops structure.
I see your point.
The reason I modified this was, as described, checkpatch.pl was complaining.
Anyway, this sequence was protected by a spinlock 'proto_tab_lock'.
I don't think it was a race.
Did I miss something?
Kurt
_______________________________________________
Socketcan-core mailing list
Socketcan-core@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [patch net-next-2.6 1/6] af_packet: use skb->skb_iif instead of orig_dev->ifindex
From: Changli Gao @ 2011-03-14 15:10 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet,
nicolas.2p.debian, andy
In-Reply-To: <20110314074342.GB2751@psychotron.redhat.com>
On Mon, Mar 14, 2011 at 3:43 PM, Jiri Pirko <jpirko@redhat.com> wrote:
> Mon, Mar 14, 2011 at 07:59:39AM CET, xiaosuo@gmail.com wrote:
>>>
>>
>>1557 static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
>>....
>>
>>1571 if (pt_prev) {
>>1572 deliver_skb(skb2, pt_prev, skb->dev);
>>1573 pt_prev = ptype;
>>1574 continue;
>>1575 }
>>...
>>1603 }
>>1604 if (pt_prev)
>>1605 pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);
>>1606 rcu_read_unlock();
>>1607 }
>
> I'm probably missign something but I do not see the connection between
> this and setting up sll->sll_ifindex in net/packet/af_packet.c
>
Think about a packet socket(with origdev set) for packets emitted via
NIC eth0, and sll->sll_ifindex is eth0->ifindex, but after your patch,
sll->sll_ifindex may be ZERO or the ifindex of the RX NIC for the
forwarded packets. However, I don't know if this origdev usage is
valid. Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH 2/2] dev : fix mtu check when TSO is enabled
From: Daniel Lezcano @ 2011-03-14 16:08 UTC (permalink / raw)
To: davem; +Cc: kaber, nightnord, netdev
In-Reply-To: <1300118888-2311-1-git-send-email-daniel.lezcano@free.fr>
In case the device where is coming from the packet has TSO enabled,
we should not check the mtu size value as this one could be bigger
than the expected value.
This is the case for the macvlan driver when the lower device has
TSO enabled. The macvlan inherit this feature and forward the packets
without fragmenting them. Then the packets go through dev_forward_skb
and are dropped. This patch fix this by checking TSO is not enabled
when we want to check the mtu size.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Andrian Nord <nightnord@gmail.com>
---
net/core/dev.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 6561021..010a0a9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1526,8 +1526,10 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
skb_orphan(skb);
nf_reset(skb);
- if (unlikely(!(dev->flags & IFF_UP) ||
- (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
+ if (unlikely(!(skb->dev->features & NETIF_F_TSO) &&
+ (!(dev->flags & IFF_UP) ||
+ (skb->len > (dev->mtu +
+ dev->hard_header_len + VLAN_HLEN))))) {
atomic_long_inc(&dev->rx_dropped);
kfree_skb(skb);
return NET_RX_DROP;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] macvlan : fix checksums error when we are in bridge mode
From: Daniel Lezcano @ 2011-03-14 16:08 UTC (permalink / raw)
To: davem; +Cc: kaber, nightnord, netdev
When the lower device has offloading capabilities, the packets checksums
are not computed. That leads to have any macvlan port in bridge mode to
not work because the packets are dropped due to a bad checksum.
If the macvlan is in bridge mode, the packet is forwarded to another
macvlan port and reach the network stack where it looks for a checksum
but this one was not computed due to the offloading of the lower device.
In this case, we have to set the packet with CHECKSUM_UNNECESSARY
when it is forwarded to a bridged port and restore the previous value of
ip_summed when the packet goes to the lowerdev.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Andrian Nord <nightnord@gmail.com>
---
drivers/net/macvlan.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 6ed577b..497991b 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -219,9 +219,11 @@ static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
const struct macvlan_dev *vlan = netdev_priv(dev);
const struct macvlan_port *port = vlan->port;
const struct macvlan_dev *dest;
+ __u8 ip_summed = skb->ip_summed;
if (vlan->mode == MACVLAN_MODE_BRIDGE) {
const struct ethhdr *eth = (void *)skb->data;
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
/* send to other bridge ports directly */
if (is_multicast_ether_addr(eth->h_dest)) {
@@ -241,6 +243,7 @@ static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
}
xmit_world:
+ skb->ip_summed = ip_summed;
skb_set_dev(skb, vlan->lowerdev);
return dev_queue_xmit(skb);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 0/3] bonding: various fixes
From: Phil Oester @ 2011-03-14 16:22 UTC (permalink / raw)
To: netdev; +Cc: fubar, andy
A few collected fixes to bonding. Patches are against net-next,
but should apply fine to 38-rc.
Phil
bond_main.c | 15 +++++++++++----
bond_sysfs.c | 5 ++++-
2 files changed, 15 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 2/3] bonding: Call netif_carrier_off after register_netdevice
From: Phil Oester @ 2011-03-14 16:22 UTC (permalink / raw)
To: netdev; +Cc: fubar, andy, Phil Oester
In-Reply-To: <1300119726-17529-1-git-send-email-kernel@linuxace.com>
Bringing up a bond interface with all network cables disconnected
does not properly set the interface as DOWN because the call to
netif_carrier_off occurs too early in bond_init. The call needs
to occur after register_netdevice has set dev->reg_state to
NETREG_REGISTERED, so that netif_carrier_off will trigger the
call to linkwatch_fire_event.
Signed-off-by: Phil Oester <kernel@linuxace.com>
---
drivers/net/bonding/bond_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a93d941..66c98e6 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4980,8 +4980,6 @@ static int bond_init(struct net_device *bond_dev)
bond_set_lockdep_class(bond_dev);
- netif_carrier_off(bond_dev);
-
bond_create_proc_entry(bond);
list_add_tail(&bond->bond_list, &bn->dev_list);
@@ -5051,6 +5049,8 @@ int bond_create(struct net *net, const char *name)
res = register_netdevice(bond_dev);
+ netif_carrier_off(bond_dev);
+
out:
rtnl_unlock();
if (res < 0)
--
1.7.4
^ permalink raw reply related
* [PATCH 3/3] bonding: Improve syslog message at device creation time
From: Phil Oester @ 2011-03-14 16:22 UTC (permalink / raw)
To: netdev; +Cc: fubar, andy, Phil Oester
In-Reply-To: <1300119726-17529-1-git-send-email-kernel@linuxace.com>
When the bonding module is loaded, it creates bond0 by default.
Then, when attempting to create bond0, the following messages
are printed to syslog:
kernel: bonding: bond0 is being created...
kernel: bonding: Bond creation failed.
Which seems to indicate a problem, when in reality there is no
problem. Since the actual error code is passed down from bond_create,
make use of it to print a bit less ominous message:
kernel: bonding: bond0 is being created...
kernel: bond0 already exists.
Signed-off-by: Phil Oester <kernel@linuxace.com>
---
drivers/net/bonding/bond_sysfs.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 72bb0f6..e718144 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -118,7 +118,10 @@ static ssize_t bonding_store_bonds(struct class *cls,
pr_info("%s is being created...\n", ifname);
rv = bond_create(net, ifname);
if (rv) {
- pr_info("Bond creation failed.\n");
+ if (rv == -EEXIST)
+ pr_info("%s already exists.\n", ifname);
+ else
+ pr_info("%s creation failed.\n", ifname);
res = rv;
}
} else if (command[0] == '-') {
--
1.7.4
^ permalink raw reply related
* [PATCH 1/3] bonding: Incorrect TX queue offset
From: Phil Oester @ 2011-03-14 16:22 UTC (permalink / raw)
To: netdev; +Cc: fubar, andy, Phil Oester
In-Reply-To: <1300119726-17529-1-git-send-email-kernel@linuxace.com>
When packets come in from a device with >= 16 receive queues
headed out a bonding interface, syslog gets filled with this:
kernel: bond0 selects TX queue 16, but real number of TX queues is 16
because queue_mapping is offset by 1. Adjust return value
to account for the offset.
This is a revision of my earlier patch (which did not use the
skb_rx_queue_* helpers - thanks to Ben for the suggestion).
Andy submitted a similar patch which emits a pr_warning on
invalid queue selection, but I believe the log spew is
not useful. We can revisit that question in the future,
but in the interim I believe fixing the core problem is
worthwhile.
Signed-off-by: Phil Oester <kernel@linuxace.com>
---
drivers/net/bonding/bond_main.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 3ad4f50..a93d941 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4341,11 +4341,18 @@ static u16 bond_select_queue(struct net_device *dev, struct sk_buff *skb)
{
/*
* This helper function exists to help dev_pick_tx get the correct
- * destination queue. Using a helper function skips the a call to
+ * destination queue. Using a helper function skips a call to
* skb_tx_hash and will put the skbs in the queue we expect on their
* way down to the bonding driver.
*/
- return skb->queue_mapping;
+ u16 txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
+
+ if (unlikely(txq >= dev->real_num_tx_queues)) {
+ do
+ txq -= dev->real_num_tx_queues;
+ while (txq >= dev->real_num_tx_queues);
+ }
+ return txq;
}
static netdev_tx_t bond_start_xmit(struct sk_buff *skb, struct net_device *dev)
--
1.7.4
^ permalink raw reply related
* Re: [RFC v3 3/6] can: make struct proto const
From: Eric Dumazet @ 2011-03-14 16:42 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: socketcan-core, netdev
In-Reply-To: <20110314150227.GJ333@e-circ.dyndns.org>
Le lundi 14 mars 2011 à 16:02 +0100, Kurt Van Dijck a écrit :
> I see your point.
> The reason I modified this was, as described, checkpatch.pl was complaining.
> Anyway, this sequence was protected by a spinlock 'proto_tab_lock'.
> I don't think it was a race.
>
> Did I miss something?
As soon as proto_tab[proto] = cp; is done, another thread on another cpu
can read the pointer and follow it.
Hmm, I missed can_create() also uses the spinlock protection, so you're
probably right.
It seems a bit overkill :(
phonet uses RCU for example.
^ permalink raw reply
* Re: [PATCH 2/2] dev : fix mtu check when TSO is enabled
From: Eric Dumazet @ 2011-03-14 17:01 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: davem, kaber, nightnord, netdev
In-Reply-To: <1300118888-2311-2-git-send-email-daniel.lezcano@free.fr>
Le lundi 14 mars 2011 à 17:08 +0100, Daniel Lezcano a écrit :
> In case the device where is coming from the packet has TSO enabled,
> we should not check the mtu size value as this one could be bigger
> than the expected value.
>
> This is the case for the macvlan driver when the lower device has
> TSO enabled. The macvlan inherit this feature and forward the packets
> without fragmenting them. Then the packets go through dev_forward_skb
> and are dropped. This patch fix this by checking TSO is not enabled
> when we want to check the mtu size.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Andrian Nord <nightnord@gmail.com>
> ---
> net/core/dev.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 6561021..010a0a9 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1526,8 +1526,10 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
> skb_orphan(skb);
> nf_reset(skb);
>
> - if (unlikely(!(dev->flags & IFF_UP) ||
> - (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
> + if (unlikely(!(skb->dev->features & NETIF_F_TSO) &&
Sorry, this needs a comment at least, or even better a helper function
on its own.
We test both skb->dev & dev, pointing to different devices, this is
really error prone.
Are we sure all callers set skb->dev before calling dev_forward_skb() ?
> + (!(dev->flags & IFF_UP) ||
> + (skb->len > (dev->mtu +
> + dev->hard_header_len + VLAN_HLEN))))) {
> atomic_long_inc(&dev->rx_dropped);
> kfree_skb(skb);
> return NET_RX_DROP;
^ permalink raw reply
* Re: [PATCH 1/2] macvlan : fix checksums error when we are in bridge mode
From: Eric Dumazet @ 2011-03-14 17:04 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: davem, kaber, nightnord, netdev
In-Reply-To: <1300118888-2311-1-git-send-email-daniel.lezcano@free.fr>
Le lundi 14 mars 2011 à 17:08 +0100, Daniel Lezcano a écrit :
> When the lower device has offloading capabilities, the packets checksums
> are not computed. That leads to have any macvlan port in bridge mode to
> not work because the packets are dropped due to a bad checksum.
>
> If the macvlan is in bridge mode, the packet is forwarded to another
> macvlan port and reach the network stack where it looks for a checksum
> but this one was not computed due to the offloading of the lower device.
> In this case, we have to set the packet with CHECKSUM_UNNECESSARY
> when it is forwarded to a bridged port and restore the previous value of
> ip_summed when the packet goes to the lowerdev.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Andrian Nord <nightnord@gmail.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* [PATCH net-next] tipc: delete extra semicolon blocking node deletion
From: Paul Gortmaker @ 2011-03-14 17:11 UTC (permalink / raw)
To: davem; +Cc: netdev, Allan.Stephens, Paul Gortmaker
Remove bogus semicolon only recently introduced in 34e46258cb9f5
that blocks cleanup of nodes for N>1 on shutdown.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Also available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/net-next-2.6.git tipc-Mar14-2011
net/tipc/net.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/tipc/net.c b/net/tipc/net.c
index 8fbc7e6..68b3dd6 100644
--- a/net/tipc/net.c
+++ b/net/tipc/net.c
@@ -221,7 +221,7 @@ void tipc_net_stop(void)
tipc_bearer_stop();
tipc_mode = TIPC_NODE_MODE;
tipc_bclink_stop();
- list_for_each_entry_safe(node, t_node, &tipc_node_list, list);
+ list_for_each_entry_safe(node, t_node, &tipc_node_list, list)
tipc_node_delete(node);
write_unlock_bh(&tipc_net_lock);
info("Left network mode\n");
--
1.7.3.3
^ permalink raw reply related
* Re: [RFC v3 3/6] can: make struct proto const
From: Kurt Van Dijck @ 2011-03-14 17:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1300120943.3423.121.camel@edumazet-laptop>
On Mon, Mar 14, 2011 at 05:42:23PM +0100, Eric Dumazet wrote:
> Le lundi 14 mars 2011 à 16:02 +0100, Kurt Van Dijck a écrit :
>
> > I see your point.
> > The reason I modified this was, as described, checkpatch.pl was complaining.
> > Anyway, this sequence was protected by a spinlock 'proto_tab_lock'.
> > I don't think it was a race.
> >
> > Did I miss something?
>
> As soon as proto_tab[proto] = cp; is done, another thread on another cpu
> can read the pointer and follow it.
>
> Hmm, I missed can_create() also uses the spinlock protection, so you're
> probably right.
>
> It seems a bit overkill :(
> phonet uses RCU for example.
I'll keep that in mind.
Switching CAN protos to RCU is far beyond to goal of this patch :-)
Thanks,
Kurt
_______________________________________________
Socketcan-core mailing list
Socketcan-core@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH] macb: detect IP version to determin if we are on at91 or avr32
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-14 17:24 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: netdev, Nicolas Ferre, linux-kernel, Jamie Iles,
Hans-Christian Egtvedt, linux-arm-kernel
In-Reply-To: <20110314101512.GA26085@n2100.arm.linux.org.uk>
On 10:15 Mon 14 Mar , Russell King - ARM Linux wrote:
> On Fri, Mar 11, 2011 at 06:13:05PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > + if (macb_is_at91(bp)) {
> > + bp->pclk = clk_get(&pdev->dev, "macb_clk");
> > + if (IS_ERR(bp->pclk)) {
> > + dev_err(&pdev->dev, "failed to get macb_clk\n");
> > + goto err_out_free_dev;
> > + }
> > + clk_enable(bp->pclk);
> > + } else {
> > + bp->pclk = clk_get(&pdev->dev, "pclk");
> > + if (IS_ERR(bp->pclk)) {
> > + dev_err(&pdev->dev, "failed to get pclk\n");
> > + goto err_out_free_dev;
> > + }
> > + bp->hclk = clk_get(&pdev->dev, "hclk");
> > + if (IS_ERR(bp->hclk)) {
> > + dev_err(&pdev->dev, "failed to get hclk\n");
> > + goto err_out_put_pclk;
> > + }
> > +
> > + clk_enable(bp->pclk);
> > + clk_enable(bp->hclk);
> > + }
>
> This is the same kind of sillyness that started getting OMAP into problems
> with the clk API. Just do this instead:
>
> bp->pclk = clk_get(&pdev->dev, "pclk");
> if (IS_ERR(bp->pclk)) {
> dev_err(&pdev->dev, "failed to get pclk\n");
> goto err_out_free_dev;
> }
> bp->hclk = clk_get(&pdev->dev, "hclk");
> if (IS_ERR(bp->hclk)) {
> dev_err(&pdev->dev, "failed to get hclk\n");
> goto err_out_put_pclk;
> }
>
> clk_enable(bp->pclk);
> clk_enable(bp->hclk);
>
> And then require _all_ platforms using this driver to provide a pclk and
> a hclk for this device, whether they exist in the SoC or not. Where they
> don't, provide dummy clocks for it.
>
> This probably means you end up with _less_ bloat overall because you're
> not having to build the above code. You've less lines of source code to
> maintain. You have a simplified dirver with consistent requirements
> across all platforms. You don't need to read the version register, and
> you don't need macb_is_at91() and macb_is_avr32().
no we do need it for some of the register IP implementation related to the MII
at least
>
> With clkdev it's _cheap_ to provide these dummy clocks once you have one
> dummy clock already in place.
I known and already agree about the clock, Jamie Patches will take care about it
this patch remove the ifdef ARCH and now detect the IP revision to determin
the IP specific implementation
Best Regards,
J.
^ permalink raw reply
* [PATCH 2/7] tcp_cubic: fix comparison of jiffies
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-jiffies-wrap.patch --]
[-- Type: text/plain, Size: 1021 bytes --]
Jiffies wraps around therefore the correct way to compare is
to use cast to signed value.
Note: cubic is not using full jiffies value on 64 bit arch
because using full unsigned long makes struct bictcp grow too
large for the available ca_priv area.
Includes correction from Sangtae Ha to improve ack train detection.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/ipv4/tcp_cubic.c 2011-03-11 09:00:06.856664687 -0800
+++ b/net/ipv4/tcp_cubic.c 2011-03-11 09:02:11.685796371 -0800
@@ -342,9 +342,11 @@ static void hystart_update(struct sock *
u32 curr_jiffies = jiffies;
/* first detection parameter - ack-train detection */
- if (curr_jiffies - ca->last_jiffies <= msecs_to_jiffies(2)) {
+ if ((s32)(curr_jiffies - ca->last_jiffies) <=
+ msecs_to_jiffies(2)) {
ca->last_jiffies = curr_jiffies;
- if (curr_jiffies - ca->round_start >= ca->delay_min>>4)
+ if ((s32) (curr_jiffies - ca->round_start) >
+ ca->delay_min >> 4)
ca->found |= HYSTART_ACK_TRAIN;
}
^ permalink raw reply
* [PATCH 1/7] tcp: fix RTT for quick packets in congestion control
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-input-rtt.patch --]
[-- Type: text/plain, Size: 967 bytes --]
In the congestion control interface, the callback for each ACK
includes an estimated round trip time in microseconds.
Some algorithms need high resolution (Vegas style) but most only
need jiffie resolution. If RTT is not accurate (like a retransmission)
-1 is used as a flag value.
When doing coarse resolution if RTT is less than a a jiffie
then 0 should be returned rather than no estimate. Otherwise algorithms
that expect good ack's to trigger slow start (like CUBIC Hystart)
will be confused.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/ipv4/tcp_input.c 2011-03-14 08:31:35.442834792 -0700
+++ b/net/ipv4/tcp_input.c 2011-03-14 08:31:40.078917049 -0700
@@ -3350,7 +3350,7 @@ static int tcp_clean_rtx_queue(struct so
net_invalid_timestamp()))
rtt_us = ktime_us_delta(ktime_get_real(),
last_ackt);
- else if (ca_seq_rtt > 0)
+ else if (ca_seq_rtt >= 0)
rtt_us = jiffies_to_usecs(ca_seq_rtt);
}
^ permalink raw reply
* [PATCH 4/7] tcp_cubic: fix clock dependency
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-minrtt.patch --]
[-- Type: text/plain, Size: 2977 bytes --]
The hystart code was written with assumption that HZ=1000.
Replace the use of jiffies with bictcp_clock as a millisecond
real time clock.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Reported-by: Lucas Nussbaum <lucas.nussbaum@loria.fr>
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:19:18.000000000 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:22:42.486690594 -0700
@@ -88,7 +88,7 @@ struct bictcp {
u32 last_time; /* time when updated last_cwnd */
u32 bic_origin_point;/* origin point of bic function */
u32 bic_K; /* time to origin point from the beginning of the current epoch */
- u32 delay_min; /* min delay */
+ u32 delay_min; /* min delay (msec << 3) */
u32 epoch_start; /* beginning of an epoch */
u32 ack_cnt; /* number of acks */
u32 tcp_cwnd; /* estimated tcp cwnd */
@@ -98,7 +98,7 @@ struct bictcp {
u8 found; /* the exit point is found? */
u32 round_start; /* beginning of each round */
u32 end_seq; /* end_seq of the round */
- u32 last_jiffies; /* last time when the ACK spacing is close */
+ u32 last_ack; /* last time when the ACK spacing is close */
u32 curr_rtt; /* the minimum rtt of current round */
};
@@ -119,12 +119,21 @@ static inline void bictcp_reset(struct b
ca->found = 0;
}
+static inline u32 bictcp_clock(void)
+{
+#if HZ < 1000
+ return ktime_to_ms(ktime_get_real());
+#else
+ return jiffies_to_msecs(jiffies);
+#endif
+}
+
static inline void bictcp_hystart_reset(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
struct bictcp *ca = inet_csk_ca(sk);
- ca->round_start = ca->last_jiffies = jiffies;
+ ca->round_start = ca->last_ack = bictcp_clock();
ca->end_seq = tp->snd_nxt;
ca->curr_rtt = 0;
ca->sample_cnt = 0;
@@ -239,8 +248,8 @@ static inline void bictcp_update(struct
*/
/* change the unit from HZ to bictcp_HZ */
- t = ((tcp_time_stamp + (ca->delay_min>>3) - ca->epoch_start)
- << BICTCP_HZ) / HZ;
+ t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3)
+ - ca->epoch_start) << BICTCP_HZ) / HZ;
if (t < ca->bic_K) /* t - K */
offs = ca->bic_K - t;
@@ -342,14 +351,12 @@ static void hystart_update(struct sock *
struct bictcp *ca = inet_csk_ca(sk);
if (!(ca->found & hystart_detect)) {
- u32 curr_jiffies = jiffies;
+ u32 now = bictcp_clock();
/* first detection parameter - ack-train detection */
- if ((s32)(curr_jiffies - ca->last_jiffies) <=
- msecs_to_jiffies(hystart_ack_delta)) {
- ca->last_jiffies = curr_jiffies;
- if ((s32) (curr_jiffies - ca->round_start) >
- ca->delay_min >> 4)
+ if ((s32)(now - ca->last_ack) <= hystart_ack_delta) {
+ ca->last_ack = now;
+ if ((s32)(now - ca->round_start) > ca->delay_min >> 4)
ca->found |= HYSTART_ACK_TRAIN;
}
@@ -396,7 +403,7 @@ static void bictcp_acked(struct sock *sk
if ((s32)(tcp_time_stamp - ca->epoch_start) < HZ)
return;
- delay = usecs_to_jiffies(rtt_us) << 3;
+ delay = (rtt_us << 3) / USEC_PER_MSEC;
if (delay == 0)
delay = 1;
^ permalink raw reply
* [PATCH 3/7] tcp_cubic: make ack train delta value a parameter
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-ackdelta.patch --]
[-- Type: text/plain, Size: 1432 bytes --]
Make the spacing between ACK's that indicates a train a tuneable
value like other hystart values.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:19:15.697936023 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:19:18.361944814 -0700
@@ -52,6 +52,7 @@ static int tcp_friendliness __read_mostl
static int hystart __read_mostly = 1;
static int hystart_detect __read_mostly = HYSTART_ACK_TRAIN | HYSTART_DELAY;
static int hystart_low_window __read_mostly = 16;
+static int hystart_ack_delta __read_mostly = 2;
static u32 cube_rtt_scale __read_mostly;
static u32 beta_scale __read_mostly;
@@ -75,6 +76,8 @@ MODULE_PARM_DESC(hystart_detect, "hyrbri
" 1: packet-train 2: delay 3: both packet-train and delay");
module_param(hystart_low_window, int, 0644);
MODULE_PARM_DESC(hystart_low_window, "lower bound cwnd for hybrid slow start");
+module_param(hystart_ack_delta, int, 0644);
+MODULE_PARM_DESC(hystart_ack_delta, "spacing between ack's indicating train (msecs)");
/* BIC TCP Parameters */
struct bictcp {
@@ -343,7 +346,7 @@ static void hystart_update(struct sock *
/* first detection parameter - ack-train detection */
if ((s32)(curr_jiffies - ca->last_jiffies) <=
- msecs_to_jiffies(2)) {
+ msecs_to_jiffies(hystart_ack_delta)) {
ca->last_jiffies = curr_jiffies;
if ((s32) (curr_jiffies - ca->round_start) >
ca->delay_min >> 4)
^ permalink raw reply
* [PATCH 0/7] TCP CUBIC Hystart fixes
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
This is the merge of my patches and recent update Sangtae.
It addresses the problems reported by Lucas Nussbaum that Hystart causes
poor startup performance over links with lots of buffering.
^ permalink raw reply
* [PATCH 5/7] tcp_cubic: enable high resolution ack time if needed
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-rtt-cong.patch --]
[-- Type: text/plain, Size: 726 bytes --]
This is a refined version of an earlier patch by Lucas Nussbaum.
Cubic needs RTT values in milliseconds. If HZ < 1000 then
the values will be too coarse.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Reported-by: Lucas Nussbaum <lucas.nussbaum@loria.fr>
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:22:42.486690594 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:27:24.435852847 -0700
@@ -459,6 +459,10 @@ static int __init cubictcp_register(void
/* divide by bic_scale and by constant Srtt (100ms) */
do_div(cube_factor, bic_scale * 10);
+ /* hystart needs ms clock resolution */
+ if (hystart && HZ < 1000)
+ cubictcp.flags |= TCP_CONG_RTT_STAMP;
+
return tcp_register_congestion_control(&cubictcp);
}
^ permalink raw reply
* [PATCH 7/7] tcp_cubic: fix low utilization of CUBIC with HyStart
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Sangtae Ha
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-initial-growth.patch --]
[-- Type: text/plain, Size: 1077 bytes --]
From: Sangtae Ha <sangtae.ha@gmail.com>
HyStart sets the initial exit point of slow start.
Suppose that HyStart exits at 0.5BDP in a BDP network and no history exists.
If the BDP of a network is large, CUBIC's initial cwnd growth may be
too conservative to utilize the link.
CUBIC increases the cwnd 20% per RTT in this case.
Signed-off-by: Sangtae Ha <sangtae.ha@gmail.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/ipv4/tcp_cubic.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:32:46.347993869 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 10:57:00.846549449 -0700
@@ -270,6 +270,13 @@ static inline void bictcp_update(struct
ca->cnt = 100 * cwnd; /* very small increment*/
}
+ /*
+ * The initial growth of cubic function may be too conservative
+ * when the available bandwidth is still unknown.
+ */
+ if (ca->loss_cwnd == 0 && ca->cnt > 20)
+ ca->cnt = 20; /* increase cwnd 5% per RTT */
+
/* TCP Friendly */
if (tcp_friendliness) {
u32 scale = beta_scale;
^ permalink raw reply
* [PATCH 6/7] tcp_cubic: make the delay threshold of HyStart less sensitive
From: Stephen Hemminger @ 2011-03-14 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Sangtae Ha
In-Reply-To: <20110314175211.788224699@vyatta.com>
[-- Attachment #1: tcp-cubic-increase-delay.patch --]
[-- Type: text/plain, Size: 795 bytes --]
From: Sangtae Ha <sangtae.ha@gmail.com>
Make HyStart less sensitive to abrupt delay variations due to buffer bloat.
Signed-off-by: Sangtae Ha <sangtae.ha@gmail.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Reported-by: Lucas Nussbaum <lucas.nussbaum@loria.fr>
---
net/ipv4/tcp_cubic.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--- a/net/ipv4/tcp_cubic.c 2011-03-14 08:27:24.435852847 -0700
+++ b/net/ipv4/tcp_cubic.c 2011-03-14 08:27:29.043872578 -0700
@@ -39,7 +39,7 @@
/* Number of delay samples for detecting the increase of delay */
#define HYSTART_MIN_SAMPLES 8
-#define HYSTART_DELAY_MIN (2U<<3)
+#define HYSTART_DELAY_MIN (4U<<3)
#define HYSTART_DELAY_MAX (16U<<3)
#define HYSTART_DELAY_THRESH(x) clamp(x, HYSTART_DELAY_MIN, HYSTART_DELAY_MAX)
^ permalink raw reply
* Re: how to utilize multi tx queue to sent packets
From: Stephen Hemminger @ 2011-03-14 18:14 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24FB47E9EE@MILEXCH2.ds.jdsu.net>
On Sun, 13 Mar 2011 01:06:11 -0800
Jon Zhou <Jon.Zhou@jdsu.com> wrote:
>
>
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> > Sent: Saturday, March 12, 2011 1:07 AM
> > To: Jon Zhou
> > Cc: netdev@vger.kernel.org
> > Subject: Re: how to utilize multi tx queue to sent packets
> >
> > On Thu, 10 Mar 2011 22:52:30 -0800
> > Jon Zhou <Jon.Zhou@jdsu.com> wrote:
> >
> > > hi
> > >
> > > I am doing some test according to the
> > > website:http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap
> > >
> > > use packet_mmap tx_ring to send packet.
> > >
> > > I modified the sample code "packetmmap.c" to make it send packets
> > have different outer ip.
> > > so that with the help of RSS, I can achieve higher throughput.
> > >
> > > but one thing I saw at the tx side, is that all the packets are sent
> > via the same tx_queue,
> > > which is conflict with what I saw at the rx side.
> > > any idea to make it sent packets via different tx_queues? (spread
> > across the tx_queues)
> >
> > You need to have multiple threads to get Tx scaling.
> > In you case that also means multiple AF_PACKET sockets and separate
> > rings.
> >
> > Or just run multiple copies of the same test each with a different IP
>
> How does kernel know which tx_queue to use?
> Will dev_queue_xmit determine tx_queue(sw queue) to send packets?
> Or just let NIC select a tx_queue(hardware) ?
>
On most hardware, with multi-queue there is one queue per CPU.
In that case the queue selected corresponds to the CPU.
--
^ 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