* [PATCH 1/2] af_ieee802154: fix ioctl processing
From: Dmitry Eremin-Solenikov @ 2009-08-06 12:26 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249561586-26927-1-git-send-email-dbaryshkov@gmail.com>
fix two errors in ioctl processing:
1) if the ioctl isn't supported one should return -ENOIOCTLCMD
2) don't call ndo_do_ioctl if the device doesn't provide it
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
net/ieee802154/af_ieee802154.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/af_ieee802154.c b/net/ieee802154/af_ieee802154.c
index 3bb6bdb..af66180 100644
--- a/net/ieee802154/af_ieee802154.c
+++ b/net/ieee802154/af_ieee802154.c
@@ -136,7 +136,7 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
unsigned int cmd)
{
struct ifreq ifr;
- int ret = -EINVAL;
+ int ret = -ENOIOCTLCMD;
struct net_device *dev;
if (copy_from_user(&ifr, arg, sizeof(struct ifreq)))
@@ -146,8 +146,10 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
dev_load(sock_net(sk), ifr.ifr_name);
dev = dev_get_by_name(sock_net(sk), ifr.ifr_name);
- if (dev->type == ARPHRD_IEEE802154 ||
- dev->type == ARPHRD_IEEE802154_PHY)
+
+ if ((dev->type == ARPHRD_IEEE802154 ||
+ dev->type == ARPHRD_IEEE802154_PHY) &&
+ dev->netdev_ops->ndo_do_ioctl)
ret = dev->netdev_ops->ndo_do_ioctl(dev, &ifr, cmd);
if (!ret && copy_to_user(arg, &ifr, sizeof(struct ifreq)))
--
1.6.3.3
^ permalink raw reply related
* [GIT PULL 0/2] IEEE 802.15.4 last-minute fixes v3
From: Dmitry Eremin-Solenikov @ 2009-08-06 12:26 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
I hope in this try I don't make any mistakes...
The following changes since commit 0bf52b981770cbf006323bab5177f2858a196766:
Ingo Molnar (1):
net: Fix spinlock use in alloc_netdev_mq()
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-linus
Dmitry Eremin-Solenikov (2):
af_ieee802154: fix ioctl processing
af_ieee802154: provide dummy get/setsockopt
net/ieee802154/af_ieee802154.c | 8 +++++---
net/ieee802154/dgram.c | 14 ++++++++++++++
net/ieee802154/raw.c | 14 ++++++++++++++
3 files changed, 33 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Michael S. Tsirkin @ 2009-08-06 12:24 UTC (permalink / raw)
To: Gregory Haskins; +Cc: alacrityvm-devel, kvm, linux-kernel, netdev
In-Reply-To: <4A7A8F7B0200005A00051B84@sinclair.provo.novell.com>
On Thu, Aug 06, 2009 at 06:08:27AM -0600, Gregory Haskins wrote:
> Hi Michael,
>
> >>> On 8/6/2009 at 4:19 AM, in message <20090806081955.GA9752@redhat.com>,
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
> >> (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
> >
> > These are guest drivers, right?
>
> Yep.
>
> > Merging the guest first means relying on
> > kernel interface from an out of tree driver, which well might change
> > before it goes in.
>
> ABI compatibility is already addressed/handled, so even if that is true its not a problem.
It is? With versioning? Presumably this:
+ params.devid = vdev->id;
+ params.version = version;
+
+ ret = vbus_pci_hypercall(VBUS_PCI_HC_DEVOPEN,
+ ¶ms, sizeof(params));
+ if (ret < 0)
+ return ret;
Even assuming host even knows how to decode this structure (e.g. some
other host module doesn't use VBUS_PCI_HC_DEVOPEN), checks the version
and denies older guests, this might help guest not to crash, but guest
still won't work.
> > Would it make more sense to start merging with the host side of the project?
>
> Not necessarily, no. These are drivers for a "device", so its no
> different than merging any other driver really. This is especially
> true since the hypervisor is also already published and freely
> available today, so anyone can start using it.
The difference is clear to me: devices do not get to set kernel/userspace
interfaces. This "device" depends on a specific interface between
kernel and (guest) userspace.
--
MST
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Gregory Haskins @ 2009-08-06 12:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: alacrityvm-devel, kvm, linux-kernel, netdev
In-Reply-To: <20090806101702.GA10605@redhat.com>
>>> On 8/6/2009 at 6:17 AM, in message <20090806101702.GA10605@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Aug 06, 2009 at 11:19:56AM +0300, Michael S. Tsirkin wrote:
>> On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
>> > (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
>>
>> These are guest drivers, right? Merging the guest first means relying on
>> kernel interface from an out of tree driver, which well might change
>> before it goes in. Would it make more sense to start merging with the
>> host side of the project?
>>
>> > This series implements the guest-side drivers for accelerated IO
>> > when running on top of the AlacrityVM hypervisor, the details of
>> > which you can find here:
>> >
>> > http://developer.novell.com/wiki/index.php/AlacrityVM
>>
>> Since AlacrityVM is kvm based, Cc kvm@vger.kernel.org.
>>
>> > This series includes the basic plumbing, as well as the driver for
>> > accelerated 802.x (ethernet) networking.
>>
>> The graphs comparing virtio with vbus look interesting.
>> However, they do not compare apples to apples, do they?
>> These compare userspace virtio with kernel vbus, where for
>> apples to apples comparison one would need to compare
>> kernel virtio with kernel vbus. Right?
>
> Or userspace virtio with userspace vbus.
Note: That would be pointless.
-Greg
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Gregory Haskins @ 2009-08-06 12:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: alacrityvm-devel, kvm, linux-kernel, netdev
In-Reply-To: <20090806081955.GA9752@redhat.com>
Hi Michael,
>>> On 8/6/2009 at 4:19 AM, in message <20090806081955.GA9752@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
>> (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
>
> These are guest drivers, right?
Yep.
> Merging the guest first means relying on
> kernel interface from an out of tree driver, which well might change
> before it goes in.
ABI compatibility is already addressed/handled, so even if that is true its not a problem.
> Would it make more sense to start merging with the host side of the project?
Not necessarily, no. These are drivers for a "device", so its no different than merging any other driver really. This is especially true since the hypervisor is also already published and freely available today, so anyone can start using it.
>
>> This series implements the guest-side drivers for accelerated IO
>> when running on top of the AlacrityVM hypervisor, the details of
>> which you can find here:
>>
>> http://developer.novell.com/wiki/index.php/AlacrityVM
>
> Since AlacrityVM is kvm based, Cc kvm@vger.kernel.org.
I *can* do that, but there is nothing in these drivers that is KVM specific (its all pure PCI and VBUS). I've already made the general announcement about the project/ml cross posted to KVM for anyone that might be interested, but I figure I will spare the general KVM list the details unless something specifically pertains to, or affects, KVM. For instance, when I get to pushing the hypervisor side, I still need to work on getting that 'xinterface' patch to you guys. I would certainly be CC'ing kvm@vger when that happens since it modifies the KVM code.
So instead, I would just encourage anyone interested (such as yourself) to join the alacrity list so I don't bother the KVM community unless absolutely necessary.
>
>> This series includes the basic plumbing, as well as the driver for
>> accelerated 802.x (ethernet) networking.
>
> The graphs comparing virtio with vbus look interesting.
> However, they do not compare apples to apples, do they?
Yes, I believe they do. They represent the best that KVM has to offer (to my knowledge) vs the best that alacrityvm has to offer.
> These compare userspace virtio with kernel vbus,
vbus is a device model (akin to QEMU's device model). Technically, it was a comparison of userspace virtio-net (via QEMU), to kernel venet (via vbus),
which I again stress is the state of the art for both to my knowledge.
As I have explained before in earlier threads on kvm@vger, virtio is not mutually exclusive here. You can run the virtio protocol over the vbus model if someone were so inclined. In fact, I proposed this very idea to you a month or two ago but I believe you decided to go your own way and reinvent some other in-kernel model instead for your own reasons.
>where for apples to apples comparison one would need to compare
> kernel virtio with kernel vbus. Right?
Again, it already *is* apples to apples as far as I am concerned.
At the time I ran those numbers, there was certainly no in-kernel virtio model to play with. And to my knowledge, there isn't one now (I was never CC'd on the patches, and a cursory search of the KVM list isn't revealing one that was posted recently).
To reiterate: kernel virtio-net (using ??) to kernel venet (vbus based) to kernel virtio-net (vbus, but doesnt exist yet) would be a fun bakeoff. If you have something for the kernel virtio-net, point me at it and I will try to include it in the comparison next time.
Kind Regards,
-Greg
^ permalink raw reply
* Re: [PATCH 5/5] net: smsc911x: switch to new dev_pm_ops
From: Steve.Glendinning @ 2009-08-06 11:53 UTC (permalink / raw)
To: David Miller
Cc: daniel, linux-kernel, linux-pm, netdev, linux-sh, Ian.Saturley
In-Reply-To: <20090805.202922.241102337.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 06/08/2009 04:29:22:
> From: Daniel Mack <daniel@caiaq.de>
> Date: Wed, 5 Aug 2009 20:29:31 +0200
>
> > Hibernation is unsupported for now, which meets the actual
> > implementation in the driver. For free/thaw, the chip's D2 state
should
> > be entered.
> >
> > Signed-off-by: Daniel Mack <daniel@caiaq.de>
>
> Steve, if it looks good to you I can toss this into net-next-2.6
>
> Just let me know.
Looks fine. Compiles ok and doesn't actually change any PM
implementation.
Acked-by: <steve.glendinning@smsc.com>
Unfortunately I can't test it. The only dev platform I have in front of
me
is SH7709S, which doesn't boot since
4ff29ff8e8723a41e7defd8bc78a7b16cbf940a2
(the sh maintainers are aware and working on it:
http://marc.info/?l=linux-sh&m=124891631203530&w=2)
Steve
^ permalink raw reply
* [PATCH ver2] Avoid enqueuing skb for default qdiscs
From: Krishna Kumar @ 2009-08-06 11:44 UTC (permalink / raw)
To: davem; +Cc: Jarek Poplawski, netdev, herbert, Krishna Kumar, kaber
From: Krishna Kumar <krkumar2@in.ibm.com>
dev_queue_xmit enqueue's a skb and calls qdisc_run which
dequeue's the skb and xmits it. In most cases, the skb that
is enqueue'd is the same one that is dequeue'd (unless the
queue gets stopped or multiple cpu's write to the same queue
and ends in a race with qdisc_run). For default qdiscs, we
can remove the redundant enqueue/dequeue and simply xmit the
skb since the default qdisc is work-conserving.
The patch uses a new flag - TCQ_F_CAN_BYPASS to identify the
default fast queue. The controversial part of the patch is
incrementing qlen when a skb is requeued - this is to avoid
checks like the second line below:
+ } else if ((q->flags & TCQ_F_CAN_BYPASS) && !qdisc_qlen(q) &&
>> !q->gso_skb &&
+ !test_and_set_bit(__QDISC_STATE_RUNNING, &q->state)) {
Results of a 2 hour testing for multiple netperf sessions (1,
2, 4, 8, 12 sessions on a 4 cpu system-X). The BW numbers are
aggregate Mb/s across iterations tested with this version on
System-X boxes with Chelsio 10gbps cards:
----------------------------------
Size | ORG BW NEW BW |
----------------------------------
128K | 156964 159381 |
256K | 158650 162042 |
----------------------------------
Changes from ver1:
1. Move sch_direct_xmit declaration from sch_generic.h to
pkt_sched.h
2. Update qdisc basic statistics for direct xmit path.
3. Set qlen to zero in qdisc_reset.
4. Changed some function names to more meaningful ones.
Thanks,
- KK
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
---
include/net/pkt_sched.h | 3 +
include/net/sch_generic.h | 15 +++++
net/core/dev.c | 48 +++++++++++++-----
net/sched/sch_generic.c | 93 ++++++++++++++++++++++--------------
4 files changed, 108 insertions(+), 51 deletions(-)
diff -ruNp org2/include/net/pkt_sched.h new6/include/net/pkt_sched.h
--- org2/include/net/pkt_sched.h 2009-08-04 11:41:21.000000000 +0530
+++ new6/include/net/pkt_sched.h 2009-08-05 22:24:41.000000000 +0530
@@ -87,6 +87,9 @@ extern struct qdisc_rate_table *qdisc_ge
extern void qdisc_put_rtab(struct qdisc_rate_table *tab);
extern void qdisc_put_stab(struct qdisc_size_table *tab);
extern void qdisc_warn_nonwc(char *txt, struct Qdisc *qdisc);
+extern int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
+ struct net_device *dev, struct netdev_queue *txq,
+ spinlock_t *root_lock);
extern void __qdisc_run(struct Qdisc *q);
diff -ruNp org2/include/net/sch_generic.h new6/include/net/sch_generic.h
--- org2/include/net/sch_generic.h 2009-03-24 08:54:16.000000000 +0530
+++ new6/include/net/sch_generic.h 2009-08-05 22:26:40.000000000 +0530
@@ -45,6 +45,7 @@ struct Qdisc
#define TCQ_F_BUILTIN 1
#define TCQ_F_THROTTLED 2
#define TCQ_F_INGRESS 4
+#define TCQ_F_CAN_BYPASS 8
#define TCQ_F_WARN_NONWC (1 << 16)
int padded;
struct Qdisc_ops *ops;
@@ -182,6 +183,11 @@ struct qdisc_skb_cb {
char data[];
};
+static inline int qdisc_qlen(struct Qdisc *q)
+{
+ return q->q.qlen;
+}
+
static inline struct qdisc_skb_cb *qdisc_skb_cb(struct sk_buff *skb)
{
return (struct qdisc_skb_cb *)skb->cb;
@@ -387,13 +393,18 @@ static inline int qdisc_enqueue_root(str
return qdisc_enqueue(skb, sch) & NET_XMIT_MASK;
}
+static inline void __qdisc_update_bstats(struct Qdisc *sch, unsigned int len)
+{
+ sch->bstats.bytes += len;
+ sch->bstats.packets++;
+}
+
static inline int __qdisc_enqueue_tail(struct sk_buff *skb, struct Qdisc *sch,
struct sk_buff_head *list)
{
__skb_queue_tail(list, skb);
sch->qstats.backlog += qdisc_pkt_len(skb);
- sch->bstats.bytes += qdisc_pkt_len(skb);
- sch->bstats.packets++;
+ __qdisc_update_bstats(sch, qdisc_pkt_len(skb));
return NET_XMIT_SUCCESS;
}
diff -ruNp org2/net/core/dev.c new6/net/core/dev.c
--- org2/net/core/dev.c 2009-07-27 09:08:24.000000000 +0530
+++ new6/net/core/dev.c 2009-08-06 11:34:21.000000000 +0530
@@ -1786,6 +1786,40 @@ static struct netdev_queue *dev_pick_tx(
return netdev_get_tx_queue(dev, queue_index);
}
+static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
+ struct net_device *dev,
+ struct netdev_queue *txq)
+{
+ spinlock_t *root_lock = qdisc_lock(q);
+ int rc;
+
+ spin_lock(root_lock);
+ if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
+ kfree_skb(skb);
+ rc = NET_XMIT_DROP;
+ } else if ((q->flags & TCQ_F_CAN_BYPASS) && !qdisc_qlen(q) &&
+ !test_and_set_bit(__QDISC_STATE_RUNNING, &q->state)) {
+ /*
+ * This is a work-conserving queue; there are no old skbs
+ * waiting to be sent out; and the qdisc is not running -
+ * xmit the skb directly.
+ */
+ __qdisc_update_bstats(q, skb->len);
+ if (sch_direct_xmit(skb, q, dev, txq, root_lock))
+ __qdisc_run(q);
+ else
+ clear_bit(__QDISC_STATE_RUNNING, &q->state);
+
+ rc = NET_XMIT_SUCCESS;
+ } else {
+ rc = qdisc_enqueue_root(skb, q);
+ qdisc_run(q);
+ }
+ spin_unlock(root_lock);
+
+ return rc;
+}
+
/**
* dev_queue_xmit - transmit a buffer
* @skb: buffer to transmit
@@ -1859,19 +1893,7 @@ gso:
skb->tc_verd = SET_TC_AT(skb->tc_verd,AT_EGRESS);
#endif
if (q->enqueue) {
- spinlock_t *root_lock = qdisc_lock(q);
-
- spin_lock(root_lock);
-
- if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
- kfree_skb(skb);
- rc = NET_XMIT_DROP;
- } else {
- rc = qdisc_enqueue_root(skb, q);
- qdisc_run(q);
- }
- spin_unlock(root_lock);
-
+ rc = __dev_xmit_skb(skb, q, dev, txq);
goto out;
}
diff -ruNp org2/net/sched/sch_generic.c new6/net/sched/sch_generic.c
--- org2/net/sched/sch_generic.c 2009-05-25 07:48:07.000000000 +0530
+++ new6/net/sched/sch_generic.c 2009-08-05 22:24:41.000000000 +0530
@@ -37,15 +37,11 @@
* - updates to tree and tree walking are only done under the rtnl mutex.
*/
-static inline int qdisc_qlen(struct Qdisc *q)
-{
- return q->q.qlen;
-}
-
static inline int dev_requeue_skb(struct sk_buff *skb, struct Qdisc *q)
{
q->gso_skb = skb;
q->qstats.requeues++;
+ q->q.qlen++; /* it's still part of the queue */
__netif_schedule(q);
return 0;
@@ -61,9 +57,11 @@ static inline struct sk_buff *dequeue_sk
/* check the reason of requeuing without tx lock first */
txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
- if (!netif_tx_queue_stopped(txq) && !netif_tx_queue_frozen(txq))
+ if (!netif_tx_queue_stopped(txq) &&
+ !netif_tx_queue_frozen(txq)) {
q->gso_skb = NULL;
- else
+ q->q.qlen--;
+ } else
skb = NULL;
} else {
skb = q->dequeue(q);
@@ -103,44 +101,23 @@ static inline int handle_dev_cpu_collisi
}
/*
- * NOTE: Called under qdisc_lock(q) with locally disabled BH.
- *
- * __QDISC_STATE_RUNNING guarantees only one CPU can process
- * this qdisc at a time. qdisc_lock(q) serializes queue accesses for
- * this queue.
- *
- * netif_tx_lock serializes accesses to device driver.
- *
- * qdisc_lock(q) and netif_tx_lock are mutually exclusive,
- * if one is grabbed, another must be free.
- *
- * Note, that this procedure can be called by a watchdog timer
+ * Transmit one skb, and handle the return status as required. Holding the
+ * __QDISC_STATE_RUNNING bit guarantees that only one CPU can execute this
+ * function.
*
* Returns to the caller:
* 0 - queue is empty or throttled.
* >0 - queue is not empty.
- *
*/
-static inline int qdisc_restart(struct Qdisc *q)
+int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
+ struct net_device *dev, struct netdev_queue *txq,
+ spinlock_t *root_lock)
{
- struct netdev_queue *txq;
int ret = NETDEV_TX_BUSY;
- struct net_device *dev;
- spinlock_t *root_lock;
- struct sk_buff *skb;
-
- /* Dequeue packet */
- if (unlikely((skb = dequeue_skb(q)) == NULL))
- return 0;
-
- root_lock = qdisc_lock(q);
/* And release qdisc */
spin_unlock(root_lock);
- dev = qdisc_dev(q);
- txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
-
HARD_TX_LOCK(dev, txq, smp_processor_id());
if (!netif_tx_queue_stopped(txq) &&
!netif_tx_queue_frozen(txq))
@@ -177,6 +154,44 @@ static inline int qdisc_restart(struct Q
return ret;
}
+/*
+ * NOTE: Called under qdisc_lock(q) with locally disabled BH.
+ *
+ * __QDISC_STATE_RUNNING guarantees only one CPU can process
+ * this qdisc at a time. qdisc_lock(q) serializes queue accesses for
+ * this queue.
+ *
+ * netif_tx_lock serializes accesses to device driver.
+ *
+ * qdisc_lock(q) and netif_tx_lock are mutually exclusive,
+ * if one is grabbed, another must be free.
+ *
+ * Note, that this procedure can be called by a watchdog timer
+ *
+ * Returns to the caller:
+ * 0 - queue is empty or throttled.
+ * >0 - queue is not empty.
+ *
+ */
+static inline int qdisc_restart(struct Qdisc *q)
+{
+ struct netdev_queue *txq;
+ struct net_device *dev;
+ spinlock_t *root_lock;
+ struct sk_buff *skb;
+
+ /* Dequeue packet */
+ skb = dequeue_skb(q);
+ if (unlikely(!skb))
+ return 0;
+
+ root_lock = qdisc_lock(q);
+ dev = qdisc_dev(q);
+ txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
+
+ return sch_direct_xmit(skb, q, dev, txq, root_lock);
+}
+
void __qdisc_run(struct Qdisc *q)
{
unsigned long start_time = jiffies;
@@ -547,8 +562,11 @@ void qdisc_reset(struct Qdisc *qdisc)
if (ops->reset)
ops->reset(qdisc);
- kfree_skb(qdisc->gso_skb);
- qdisc->gso_skb = NULL;
+ if (qdisc->gso_skb) {
+ kfree_skb(qdisc->gso_skb);
+ qdisc->gso_skb = NULL;
+ qdisc->q.qlen = 0;
+ }
}
EXPORT_SYMBOL(qdisc_reset);
@@ -605,6 +623,9 @@ static void attach_one_default_qdisc(str
printk(KERN_INFO "%s: activation failed\n", dev->name);
return;
}
+
+ /* Can by-pass the queue discipline for default qdisc */
+ qdisc->flags |= TCQ_F_CAN_BYPASS;
} else {
qdisc = &noqueue_qdisc;
}
^ permalink raw reply
* [PATCH] sky2: Serialize access to PCI config space
From: Mike McCormack @ 2009-08-06 11:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Rene Mayrhofer, Richard Leitner
PCI config space may be shared across two device instances,
or accessed from an interrupt
, so serialize access so
read-update-write operations do not interfere with each other.
Only tested on a single port card, as my sky2 doesn't have dual ports.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
---
drivers/net/sky2.c | 23 ++++++++++++++++-------
drivers/net/sky2.h | 1 +
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 1415a83..4d09632 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -618,6 +618,7 @@ static void sky2_phy_power_up(struct sky2_hw *hw, unsigned port)
{
u32 reg1;
+ spin_lock(&hw->pci_cfg_lock);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
reg1 &= ~phy_power[port];
@@ -628,6 +629,7 @@ static void sky2_phy_power_up(struct sky2_hw *hw, unsigned port)
sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
sky2_pci_read32(hw, PCI_DEV_REG1);
+ spin_unlock(&hw->pci_cfg_lock);
if (hw->chip_id == CHIP_ID_YUKON_FE)
gm_phy_write(hw, port, PHY_MARV_CTRL, PHY_CT_ANE);
@@ -681,11 +683,13 @@ static void sky2_phy_power_down(struct sky2_hw *hw, unsigned port)
gm_phy_write(hw, port, PHY_MARV_CTRL, PHY_CT_PDOWN);
}
+ spin_lock(&hw->pci_cfg_lock);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
reg1 |= phy_power[port]; /* set PHY to PowerDown/COMA Mode */
sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ spin_unlock(&hw->pci_cfg_lock);
}
/* Force a renegotiation */
@@ -2596,30 +2600,34 @@ static void sky2_hw_intr(struct sky2_hw *hw)
if (status & (Y2_IS_MST_ERR | Y2_IS_IRQ_STAT)) {
u16 pci_err;
+ spin_lock(&hw->pci_cfg_lock);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
pci_err = sky2_pci_read16(hw, PCI_STATUS);
- if (net_ratelimit())
- dev_err(&pdev->dev, "PCI hardware error (0x%x)\n",
- pci_err);
-
sky2_pci_write16(hw, PCI_STATUS,
pci_err | PCI_STATUS_ERROR_BITS);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ spin_unlock(&hw->pci_cfg_lock);
+
+ if (net_ratelimit())
+ dev_err(&pdev->dev, "PCI hardware error (0x%x)\n",
+ pci_err);
}
if (status & Y2_IS_PCI_EXP) {
/* PCI-Express uncorrectable Error occurred */
u32 err;
+ spin_lock(&hw->pci_cfg_lock);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
err = sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
sky2_write32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS,
0xfffffffful);
- if (net_ratelimit())
- dev_err(&pdev->dev, "PCI Express error (0x%x)\n", err);
-
sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ spin_unlock(&hw->pci_cfg_lock);
+
+ if (net_ratelimit())
+ dev_err(&pdev->dev, "PCI Express error (0x%x)\n", err);
}
if (status & Y2_HWE_L1_MASK)
@@ -4485,6 +4493,7 @@ static int __devinit sky2_probe(struct pci_dev *pdev,
}
hw->pdev = pdev;
+ spin_lock_init(&hw->pci_cfg_lock);
hw->regs = ioremap_nocache(pci_resource_start(pdev, 0), 0x4000);
if (!hw->regs) {
diff --git a/drivers/net/sky2.h b/drivers/net/sky2.h
index 4486b06..5a9b0cf 100644
--- a/drivers/net/sky2.h
+++ b/drivers/net/sky2.h
@@ -2087,6 +2087,7 @@ struct sky2_hw {
struct timer_list watchdog_timer;
struct work_struct restart_work;
wait_queue_head_t msi_wait;
+ spinlock_t pci_cfg_lock;
};
static inline int sky2_is_copper(const struct sky2_hw *hw)
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH, RFC] bonding: prevent outgoing packets on inactive slaves
From: Jiri Bohac @ 2009-08-06 10:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jiri Bohac, fubar, davem, netdev
In-Reply-To: <4A79BA01.502@gmail.com>
On Wed, Aug 05, 2009 at 06:57:37PM +0200, Eric Dumazet wrote:
> Jiri Bohac a écrit :
> > This patch makes sure the TX queues on inactive slaves are
> > deactivated.
> >
>
> Wont this break ARP link monitoring ?
No, ARP monitoring sends the ARP requests from the active slave.
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Eric W. Biederman @ 2009-08-06 10:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: Paul Moore, netdev, David Miller
In-Reply-To: <20090806101044.GA26589@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Wed, Aug 05, 2009 at 05:38:42PM -0400, Paul Moore wrote:
>>
>> My concern is that I believe that if the kernel fails at an operation it
>> should do all it can to unwind any actions it took in the course of attempting
>> to perform the requested operation. Leaving a TUN device around in the case
>> of a tun_attach() failure seems like the kernel is being lazy, sure a user can
>> cleanup the device but why should they have to?
>
> That particular tun_attach should never fail. Perhaps you can
> just add a WARN_ON.
Two threads one file descriptor. Both simultaneously attempt to
attach to a tun device. One will fail, the other succeed.
At least that is how I read the locking.
Eric
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Michael S. Tsirkin @ 2009-08-06 10:17 UTC (permalink / raw)
To: Gregory Haskins; +Cc: linux-kernel, alacrityvm-devel, netdev, kvm
In-Reply-To: <20090806081955.GA9752@redhat.com>
On Thu, Aug 06, 2009 at 11:19:56AM +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
> > (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
>
> These are guest drivers, right? Merging the guest first means relying on
> kernel interface from an out of tree driver, which well might change
> before it goes in. Would it make more sense to start merging with the
> host side of the project?
>
> > This series implements the guest-side drivers for accelerated IO
> > when running on top of the AlacrityVM hypervisor, the details of
> > which you can find here:
> >
> > http://developer.novell.com/wiki/index.php/AlacrityVM
>
> Since AlacrityVM is kvm based, Cc kvm@vger.kernel.org.
>
> > This series includes the basic plumbing, as well as the driver for
> > accelerated 802.x (ethernet) networking.
>
> The graphs comparing virtio with vbus look interesting.
> However, they do not compare apples to apples, do they?
> These compare userspace virtio with kernel vbus, where for
> apples to apples comparison one would need to compare
> kernel virtio with kernel vbus. Right?
Or userspace virtio with userspace vbus.
> > Regards,
> > -Greg
> >
> > ---
> >
> > Gregory Haskins (7):
> > venet: add scatter-gather/GSO support
> > net: Add vbus_enet driver
> > ioq: add driver-side vbus helpers
> > vbus-proxy: add a pci-to-vbus bridge
> > vbus: add a "vbus-proxy" bus model for vbus_driver objects
> > ioq: Add basic definitions for a shared-memory, lockless queue
> > shm-signal: shared-memory signals
> >
> >
> > arch/x86/Kconfig | 2
> > drivers/Makefile | 1
> > drivers/net/Kconfig | 14 +
> > drivers/net/Makefile | 1
> > drivers/net/vbus-enet.c | 899 +++++++++++++++++++++++++++++++++++++++++++
> > drivers/vbus/Kconfig | 24 +
> > drivers/vbus/Makefile | 6
> > drivers/vbus/bus-proxy.c | 216 ++++++++++
> > drivers/vbus/pci-bridge.c | 824 +++++++++++++++++++++++++++++++++++++++
> > include/linux/Kbuild | 4
> > include/linux/ioq.h | 415 ++++++++++++++++++++
> > include/linux/shm_signal.h | 189 +++++++++
> > include/linux/vbus_driver.h | 80 ++++
> > include/linux/vbus_pci.h | 127 ++++++
> > include/linux/venet.h | 84 ++++
> > lib/Kconfig | 21 +
> > lib/Makefile | 2
> > lib/ioq.c | 294 ++++++++++++++
> > lib/shm_signal.c | 192 +++++++++
> > 19 files changed, 3395 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/net/vbus-enet.c
> > create mode 100644 drivers/vbus/Kconfig
> > create mode 100644 drivers/vbus/Makefile
> > create mode 100644 drivers/vbus/bus-proxy.c
> > create mode 100644 drivers/vbus/pci-bridge.c
> > create mode 100644 include/linux/ioq.h
> > create mode 100644 include/linux/shm_signal.h
> > create mode 100644 include/linux/vbus_driver.h
> > create mode 100644 include/linux/vbus_pci.h
> > create mode 100644 include/linux/venet.h
> > create mode 100644 lib/ioq.c
> > create mode 100644 lib/shm_signal.c
> >
> > --
> > Signature
> > --
> > 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: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Herbert Xu @ 2009-08-06 10:10 UTC (permalink / raw)
To: Paul Moore; +Cc: Eric W. Biederman, netdev, David Miller
In-Reply-To: <200908051738.43134.paul.moore@hp.com>
On Wed, Aug 05, 2009 at 05:38:42PM -0400, Paul Moore wrote:
>
> My concern is that I believe that if the kernel fails at an operation it
> should do all it can to unwind any actions it took in the course of attempting
> to perform the requested operation. Leaving a TUN device around in the case
> of a tun_attach() failure seems like the kernel is being lazy, sure a user can
> cleanup the device but why should they have to?
That particular tun_attach should never fail. Perhaps you can
just add a WARN_ON.
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 3/3] documentation: fix wrt. headers rename
From: Dmitry Eremin-Solenikov @ 2009-08-06 9:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <20090805.202226.24204308.davem@davemloft.net>
On Wed, Aug 05, 2009 at 08:22:26PM -0700, David Miller wrote:
> From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Date: Wed, 5 Aug 2009 11:28:17 +0400
>
> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>
> What are you generating these patches against?
>
> > @@ -72,5 +72,4 @@ SoftMAC
> > We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
> > in software. This is currently WIP.
> >
> > -See header include/net/ieee802154/mac802154.h and several drivers in
> > -drivers/ieee802154/
> > +See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
>
> In net-2.6, and in Linus's tree as well, that first sentence quoted has
> a typo, "implementing" is misspelled, but in whatever you're patching
> against the misspelling is fixed.
>
> Looking at your pull request:
>
> --------------------
> The following changes since commit db71789c01ae7b641f83c5aa64e7df25122f4b28:
> David S. Miller (1):
> xfrm6: Fix xfrm6_policy.c build when SYSCTL disabled.
> --------------------
>
> You're submitting these for net-next-2.6? Didn't we just go back and
> forth about trimming this patch series down to only pure bug fixes so
> that they could go into net-2.6? Given that, why are you generating
> this stuff against net-next-2.6?
Damn. It seems I missed the difference between net-next-2.6 and net-2.6.
BTW: how should I differentiate my poll requests for net-next-2.6 and
for net-2.6 ?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] xfrm: xfrm hash to use Jenkins' hash
From: Jussi Maki @ 2009-08-06 8:58 UTC (permalink / raw)
To: Jussi Maki; +Cc: David Miller, netdev
In-Reply-To: <ce10d01f0908052332o1db16460k58ed47849670c6de@mail.gmail.com>
Hi,
Did some testing and one possible fix to this problem
would be to change the xor to addition. Would this be OK?
---
net/xfrm/xfrm_hash.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
index d401dc8..e5195c9 100644
--- a/net/xfrm/xfrm_hash.h
+++ b/net/xfrm/xfrm_hash.h
@@ -16,7 +16,7 @@ static inline unsigned int __xfrm6_addr_hash(xfrm_address_t *addr)
static inline unsigned int __xfrm4_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
{
- return ntohl(daddr->a4 ^ saddr->a4);
+ return ntohl(daddr->a4 + saddr->a4);
}
static inline unsigned int __xfrm6_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
--
1.5.6.5
On Thu, 6 Aug 2009, Jussi Maki wrote:
> Hi David,
>
> Changing the (h >> 16) to ((h >> 16) ^ (h >> 24)) still has the same
> problem as given in the example,
> that is if you have a set of transports with incrementing addresses
> (192.168.0.1-172.16.0.1, 192.168.0.2-172.16.0.2,..) they
> still hash to the same value. The reason to this is that it's doing
> src^dst in __xfrm4_daddr_saddr_hash.
>
> Should I pursue with fixing the inlining issue in my patch or would
> you have any suggestions how I could
> fix this by perhaps modifying __xfrm4_daddr_saddr_hash?
^ permalink raw reply related
* some bug in iproute2
From: Sergey Popov @ 2009-08-06 8:50 UTC (permalink / raw)
To: netdev
# tc f add dev eth0 parent 1: proto ip prio 2 u32 match u32 0 0 action ipt -j MARK --set-mark 1
/usr/lib64/iptables/libipt_mark.so: cannot open shared object file: No such file or directory
failed to find target MARK
bad action parsing
parse_action: bad value (5:ipt)!
Illegal "action"
But mark target is compiled in kernel (not a module)
# iptables -t mangle -A PREROUTING -i eth1 -j MARK --set-mark 1
# iptables -t mangle -L PREROUTING
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK all -- anywhere anywhere MARK xset
0x1/0xffffffff
This shouldn't be.
^ permalink raw reply
* Re: system hangs while executing 'rmmod ehea'
From: Hannes Hering @ 2009-08-06 8:33 UTC (permalink / raw)
To: Pavan Naregundi; +Cc: netdev, HERING2, THEMANN, TKLEIN
In-Reply-To: <4A699E70.2090900@linux.vnet.ibm.com>
Hello,
this problem has been fixed by a patch I sent out on tuesday:
http://lkml.org/lkml/2009/8/4/174
Thanks for pointing out this.
Regards
Hannes
^ permalink raw reply
* Re: [PATCH] net: Fix spinlock use in alloc_netdev_mq()
From: Jiri Pirko @ 2009-08-06 8:31 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, David Miller, Peter Zijlstra, torvalds, netdev,
linux-kernel, eric.dumazet
In-Reply-To: <20090805101327.2c49cc62.akpm@linux-foundation.org>
Wed, Aug 05, 2009 at 07:13:27PM CEST, akpm@linux-foundation.org wrote:
>On Wed, 5 Aug 2009 10:47:47 +0200 Jiri Pirko <jpirko@redhat.com> wrote:
>
>> >it's using an zero-initialized spinlock. This is a side-effect of:
>> >
>> > dev_unicast_init(dev);
>> >
>> >in alloc_netdev_mq() making use of dev->addr_list_lock.
>> >
>> >The device has just been allocated freshly, it's not accessible
>> >anywhere yet so no locking is needed at all - in fact it's wrong
>> >to lock it here (the lock isnt initialized yet).
>>
>> Yes this looks like the right approach. Sorry for this bug :(
>
>Really?
>
>> >--- a/net/core/dev.c
>> >+++ b/net/core/dev.c
>> >@@ -4007,9 +4007,7 @@ static void dev_unicast_flush(struct net_device *dev)
>> >
>> > static void dev_unicast_init(struct net_device *dev)
>> > {
>> >- netif_addr_lock_bh(dev);
>> > __hw_addr_init(&dev->uc);
>> >- netif_addr_unlock_bh(dev);
>> > }
>
>This means that the net_device is still floating around for quite a
>long time with an uninitialised spinlock, so it will be quite easy for
>the same problem to reoccur as the code evolves.
>
>It would be more robust were we to initialise that lock close to the
>netdev's allocation site.
Hmm, I see your point here. Eric previously posted patch which moved spin lock
init into alloc_netdev_mq(). But he was worried about having it here and
netdev_set_addr_lockdep_class() in register_netdevice() (because before
dev_unicast_init() dev->type is not set). So how about the following patch?
[PATCH net-2.6] net: move address lists spinlock closer to alloc and do unicast_init locking
Move spin_lock_init(), netdev_set_addr_lockdep_class() and dev_unicast_init()
right after setup is called from alloc_netdev_mq(). In that moment dev->type is
initialized. List is not needed to be initialized earlier. Also restore
previously removed locking in dev_unicast_init().
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/net/core/dev.c b/net/core/dev.c
index 6a94475..916a6d0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4007,7 +4007,9 @@ static void dev_unicast_flush(struct net_device *dev)
static void dev_unicast_init(struct net_device *dev)
{
+ netif_addr_lock_bh(dev);
__hw_addr_init(&dev->uc);
+ netif_addr_unlock_bh(dev);
}
@@ -4726,8 +4728,6 @@ int register_netdevice(struct net_device *dev)
BUG_ON(dev->reg_state != NETREG_UNINITIALIZED);
BUG_ON(!net);
- spin_lock_init(&dev->addr_list_lock);
- netdev_set_addr_lockdep_class(dev);
netdev_init_queue_locks(dev);
dev->iflink = -1;
@@ -5107,8 +5107,6 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
if (dev_addr_init(dev))
goto free_tx;
- dev_unicast_init(dev);
-
dev_net_set(dev, &init_net);
dev->_tx = tx;
@@ -5123,6 +5121,11 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
dev->priv_flags = IFF_XMIT_DST_RELEASE;
setup(dev);
strcpy(dev->name, name);
+
+ spin_lock_init(&dev->addr_list_lock);
+ netdev_set_addr_lockdep_class(dev);
+ dev_unicast_init(dev);
+
return dev;
free_tx:
>
^ permalink raw reply related
* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Michael S. Tsirkin @ 2009-08-06 8:19 UTC (permalink / raw)
To: Gregory Haskins; +Cc: linux-kernel, alacrityvm-devel, netdev, kvm
In-Reply-To: <20090803171030.17268.26962.stgit@dev.haskins.net>
On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
> (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
These are guest drivers, right? Merging the guest first means relying on
kernel interface from an out of tree driver, which well might change
before it goes in. Would it make more sense to start merging with the
host side of the project?
> This series implements the guest-side drivers for accelerated IO
> when running on top of the AlacrityVM hypervisor, the details of
> which you can find here:
>
> http://developer.novell.com/wiki/index.php/AlacrityVM
Since AlacrityVM is kvm based, Cc kvm@vger.kernel.org.
> This series includes the basic plumbing, as well as the driver for
> accelerated 802.x (ethernet) networking.
The graphs comparing virtio with vbus look interesting.
However, they do not compare apples to apples, do they?
These compare userspace virtio with kernel vbus, where for
apples to apples comparison one would need to compare
kernel virtio with kernel vbus. Right?
> Regards,
> -Greg
>
> ---
>
> Gregory Haskins (7):
> venet: add scatter-gather/GSO support
> net: Add vbus_enet driver
> ioq: add driver-side vbus helpers
> vbus-proxy: add a pci-to-vbus bridge
> vbus: add a "vbus-proxy" bus model for vbus_driver objects
> ioq: Add basic definitions for a shared-memory, lockless queue
> shm-signal: shared-memory signals
>
>
> arch/x86/Kconfig | 2
> drivers/Makefile | 1
> drivers/net/Kconfig | 14 +
> drivers/net/Makefile | 1
> drivers/net/vbus-enet.c | 899 +++++++++++++++++++++++++++++++++++++++++++
> drivers/vbus/Kconfig | 24 +
> drivers/vbus/Makefile | 6
> drivers/vbus/bus-proxy.c | 216 ++++++++++
> drivers/vbus/pci-bridge.c | 824 +++++++++++++++++++++++++++++++++++++++
> include/linux/Kbuild | 4
> include/linux/ioq.h | 415 ++++++++++++++++++++
> include/linux/shm_signal.h | 189 +++++++++
> include/linux/vbus_driver.h | 80 ++++
> include/linux/vbus_pci.h | 127 ++++++
> include/linux/venet.h | 84 ++++
> lib/Kconfig | 21 +
> lib/Makefile | 2
> lib/ioq.c | 294 ++++++++++++++
> lib/shm_signal.c | 192 +++++++++
> 19 files changed, 3395 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/vbus-enet.c
> create mode 100644 drivers/vbus/Kconfig
> create mode 100644 drivers/vbus/Makefile
> create mode 100644 drivers/vbus/bus-proxy.c
> create mode 100644 drivers/vbus/pci-bridge.c
> create mode 100644 include/linux/ioq.h
> create mode 100644 include/linux/shm_signal.h
> create mode 100644 include/linux/vbus_driver.h
> create mode 100644 include/linux/vbus_pci.h
> create mode 100644 include/linux/venet.h
> create mode 100644 lib/ioq.c
> create mode 100644 lib/shm_signal.c
>
> --
> Signature
> --
> 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
* mii ioctls and copy_to_user
From: John Paul Foster @ 2009-08-06 7:42 UTC (permalink / raw)
To: Netdev
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
Hello all,
I've written a program that uses SIOCGMIIREG to query
various mii interfaces on my board. We have a switch chip
with multiple PHYs MACs and switch fabrics on the mii bus.
I'm using kernel 2.6.23
I set the ifru_data up like this in user space
#include <linux/mii.h> // The user side if.h
struct mii_ioctl_data mii;
mii.phy_addr=myphy;
mii.reg_num=myreg;
ifr.ifr_data=(__caddr_t)&mii;
as according to my libc (uclibc) <net/if.h> that is what ifr_data is a
pointer not a structure.
This doesn't work. I get garbage in the ifr_data used by the network
driver. (kernel space)
If I add a copy_from/to_user around the call to generic_mii_ioctl(),
then it works. My driver isn't in the main kernel it is the stmmac
driver at stlinux.org but the ioctl function is the same as many in main
tree, pcnet32_ioctl() for example.
mii-tool works without me patching the driver.
mii-tool sets the ioctl up like this.
#include "mii.h" // it's own mmi structure
struct mii_data *mii = (struct mii_data *)&ifr.ifr_data;
mii->reg_num = location;
in mii-tool ifr_data is a pointer not allocated storage so you shouldn't
do that. However ifr_data is part of a union and the biggest thing in it
is bigger than struct mii_data, so we are not going to crap on our
stack/heap. Not safe though if the structure of mii_data grows, or the
union changes size.
looking at <linux/if.h> (the kernel side if.h)
ifru_data is a
void __user *ifru_data;
i.e. it needs copy_to/from_user.
Are the drivers AND mii-tool wrong? I'm feeling like either I've
uncovered a long standing bug (in both mii ioctls and mmi-tool) or I'm
missing something.
Apologies for the verbose message but I'm trying to tell it
as thoroughly as I can.
Cross posted on the linux-net list but it looks a pretty dead list.
JP
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Fwd: [RFC v3] net: Introduce recvmmsg socket syscall
From: Nir Tzachar @ 2009-08-06 7:15 UTC (permalink / raw)
To: netdev
In-Reply-To: <9b2db90b0908060014r6a1763e8t1b3ee9310e012c25@mail.gmail.com>
Hello.
Is there anything new with this patch? What are the plans for merging
it upstream?
Cheers.
p.s. please cc me, I am not registered to linux-netdev.
^ permalink raw reply
* Re: [PATCH] xfrm: xfrm hash to use Jenkins' hash
From: Jussi Maki @ 2009-08-06 6:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090805.120831.66033097.davem@davemloft.net>
Hi David,
Changing the (h >> 16) to ((h >> 16) ^ (h >> 24)) still has the same
problem as given in the example,
that is if you have a set of transports with incrementing addresses
(192.168.0.1-172.16.0.1, 192.168.0.2-172.16.0.2,..) they
still hash to the same value. The reason to this is that it's doing
src^dst in __xfrm4_daddr_saddr_hash.
Should I pursue with fixing the inlining issue in my patch or would
you have any suggestions how I could
fix this by perhaps modifying __xfrm4_daddr_saddr_hash?
On Wed, Aug 5, 2009 at 10:08 PM, David Miller<davem@davemloft.net> wrote:
> From: Jussi Mäki <joamaki@gmail.com>
> Date: Wed, 5 Aug 2009 10:41:42 +0300
>
>> Hi,
>>
>> The current xfrm hash functions perform very poorly when a number of
>> policies have the same
>> last byte in source and destination addresses.
>>
>> For example with __xfrm_dst_hash, hmask of 0xfff:
>>
>> 192.168.0.1-172.16.0.1 hashes to 3258
>> 192.168.0.2-172.16.0.2 hashes to 3258
>> ... and so on.
>>
>> This patch addresses the issue by rewriting the xfrm
>> hash functions to use the Jenkins' hash function.
>>
>> Signed-off-by: Jussi Maki <joamaki@gmail.com>
>
> jhash expands to a lot of code, and given your description of the
> problem, you could have fixed it by adding 2 instructions (see below)
> instead of 20 or 30 (jhash instruction count) at every hash
> calculation site.
>
> Simply change every instance of:
>
> (h >> 16)
>
> with
>
> ((h >> 16) ^ (h >> 24))
>
> As much as I love jhash, it's overkill for fixing this problem.
>
> And if we do end up using jhash, it should get inlined into a
> seperate non-inline function instead of expanding that monster
> 4 or 5 times throughout the XFRM code.
>
> I'm not applying this, either make the simple one-liner fix I
> suggested above work or move the jhash into a non-inline expansion.
>
^ permalink raw reply
* Re: [PATCH 1/2] net/rds: Use AF_INET for sin_family field
From: David Miller @ 2009-08-06 3:30 UTC (permalink / raw)
To: julia; +Cc: andy.grover, netdev, rds-devel, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0908051434110.20453@pc-004.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 5 Aug 2009 14:34:34 +0200 (CEST)
> Elsewhere the sin_family field holds a value with a name of the form
> AF_..., so it seems reasonable to do so here as well. Also the values of
> PF_INET and AF_INET are the same.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
..
> Signed-off-by: Julia Lawall <julia@diku.dk>
This is obvious enough that I've just tossed it into net-next-2.6
Thanks!
^ permalink raw reply
* Re: [PATCH 5/5] net: smsc911x: switch to new dev_pm_ops
From: David Miller @ 2009-08-06 3:29 UTC (permalink / raw)
To: daniel; +Cc: linux-kernel, linux-pm, steve.glendinning, netdev
In-Reply-To: <1249496971-9019-5-git-send-email-daniel@caiaq.de>
From: Daniel Mack <daniel@caiaq.de>
Date: Wed, 5 Aug 2009 20:29:31 +0200
> Hibernation is unsupported for now, which meets the actual
> implementation in the driver. For free/thaw, the chip's D2 state should
> be entered.
>
> Signed-off-by: Daniel Mack <daniel@caiaq.de>
Steve, if it looks good to you I can toss this into net-next-2.6
Just let me know.
^ permalink raw reply
* Re: [PATCH net-next-2.6] cxgb3: fix 2 ports 1G regression
From: David Miller @ 2009-08-06 3:28 UTC (permalink / raw)
To: divy; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20090805215923.21467.99484.stgit@speedy5>
From: Divy Le Ray <divy@chelsio.com>
Date: Wed, 05 Aug 2009 14:59:23 -0700
> commit 88045b3cf0f8981129cb489c7b6bc36c21dd33a7
> cxgb3: fix mac index mapping
>
> Override the mac index computation for the gen2 adapter,
> as each port is expected to use index 0.
>
> introduces a regression on 2 port 1G adapter
> as its xauicfg vpd value is null.
> Add a check on the device id.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Add IDs for 3C905B-TX Fast Etherlink XL PCI
From: David Miller @ 2009-08-06 3:24 UTC (permalink / raw)
To: klassert; +Cc: pterjan, netdev
In-Reply-To: <20090805144100.GA9346@skl-net.de>
From: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Date: Wed, 5 Aug 2009 16:41:00 +0200
> On Wed, Aug 05, 2009 at 04:11:39PM +0200, Pascal Terjan wrote:
>> We found this old card which was not supported, and physically
>> looks similar to the other 3C905B we have (9055).
>>
>> After adding the IDs it seems to work fine (MII report, dhcp, scp, ...)
>
> The patch looks sane.
> Btw. you should add a Signed-off-by line to your patches.
>
> Acked-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Applied, and yes please provide a proper Signed-off-by tag
in your commit message next time.
^ 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