* Re: linux-next: build failure after merge of the staging tree
From: Greg KH @ 2011-07-06 15:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Alexey Dobriyan, David Miller, netdev
In-Reply-To: <20110706150249.f2c67b43.sfr@canb.auug.org.au>
On Wed, Jul 06, 2011 at 03:02:49PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:599:24: error: field 'tasklet' has incomplete type
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_bus_stop':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:3068:3: error: implicit declaration of function 'tasklet_kill'
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_probe':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:5376:3: error: implicit declaration of function 'tasklet_init'
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_probe_attach':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:5505:14: warning: cast to pointer from integer of different size
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_chip_recognition':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:6056:19: warning: cast from pointer to integer of different size
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_dpc_tasklet':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:6593:4: error: implicit declaration of function 'tasklet_schedule'
>
> Caused by commit a6b7a407865a ("net: remove interrupt.h inclusion from netdevice.h") from the net tree interacting with commit ("") from the atsging tree.
>
> I have applied the following merge fixup patch for today (it should be
> applicable to the staging tree directly).
Ok, I'll go queue this up right now so this doesn't cause a problem in
the future.
greg k-h
^ permalink raw reply
* Re: FW: Re: [PATCH v3 4/4] packet: Add pre-defragmentation support for ipv4
From: Eric Dumazet @ 2011-07-06 15:18 UTC (permalink / raw)
To: Penttilä Mika; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <1A61D8EA6755AF458F06EA669A4EC8182F05BCB0@JKLMAIL02.ixonos.local>
Le mercredi 06 juillet 2011 à 14:06 +0000, Penttilä Mika a écrit :
>
> > +static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
> > +{
> > + const struct iphdr *iph;
> > + u32 len;
> > +
> > + if (skb->protocol != htons(ETH_P_IP))
> > + return skb;
> > +
> > + if (!pskb_may_pull(skb, sizeof(struct iphdr)))
> > + return skb;
> > +
> > + iph = ip_hdr(skb);
> > + if (iph->ihl < 5 || iph->version != 4)
> > + return skb;
> > + if (!pskb_may_pull(skb, iph->ihl*4))
> > + return skb;
> > + iph = ip_hdr(skb);
> > + len = ntohs(iph->tot_len);
> > + if (skb->len < len || len < (iph->ihl * 4))
> > + return skb;
> > +
> > + if (ip_is_fragment(ip_hdr(skb))) {
> > + skb = skb_clone(skb, GFP_ATOMIC);
>
> Isn't this leaking the original skb?
Yes, there are several problems here.
More fundamentally, there is a problem if two (or more) applications use
FANOUT sockets.
Only one will get the defragmented packet.
We probably need to have separate frag lists, or adding/using skb->sk as
a key.
Thanks
[PATCH] packet: fix a leak in fanout_check_defrag()
Reported-by: Penttilä Mika <mika.penttila@ixonos.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/packet/af_packet.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 41f0489..69238f6 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -476,15 +476,20 @@ static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
return skb;
if (ip_is_fragment(ip_hdr(skb))) {
- skb = skb_clone(skb, GFP_ATOMIC);
- if (skb) {
- if (pskb_trim_rcsum(skb, len))
- return skb;
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- if (ip_defrag(skb, IP_DEFRAG_AF_PACKET))
- return NULL;
- skb->rxhash = 0;
+ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
+
+ if (!nskb)
+ return skb;
+ if (pskb_trim_rcsum(nskb, len)) {
+ kfree_skb(nskb);
+ return skb;
}
+ kfree_skb(skb);
+ skb = nskb;
+ memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ if (ip_defrag(skb, IP_DEFRAG_AF_PACKET))
+ return NULL;
+ skb->rxhash = 0;
}
return skb;
}
^ permalink raw reply related
* Re: [PATCH v3 4/4] packet: Add pre-defragmentation support for ipv4
From: David Miller @ 2011-07-06 15:20 UTC (permalink / raw)
To: eric.dumazet; +Cc: mika.penttila, netdev
In-Reply-To: <1309965489.2292.27.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Jul 2011 17:18:09 +0200
> [PATCH] packet: fix a leak in fanout_check_defrag()
>
> Reported-by: Penttilä Mika <mika.penttila@ixonos.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Eric, see what I commited, it's much simpler than all
of this code movement you added, ala skb_share_check()
:-)
^ permalink raw reply
* Re: 3.0.0rc6: ethtool not working without a cable
From: Ben Hutchings @ 2011-07-06 15:26 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: netdev, e1000-devel
In-Reply-To: <201107061653.04689.a.miskiewicz@gmail.com>
On Wed, 2011-07-06 at 16:53 +0200, Arkadiusz Miskiewicz wrote:
> On Wednesday 06 of July 2011, Ben Hutchings wrote:
> > On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > > 3.0.0rc6, thinkpad t400 notebook.
> > >
> > > If there is no cable then ethtool reports no device. It wasn't that
> > > before AFAIK.
> > >
> > > ethtool version 2.6.36
> > >
> > >
> > > cable disconnected:
> > >
> > > [root@t400 ~]# ethtool eth0
> > > Settings for eth0:
> > > Cannot get device settings: No such device
> > > Cannot get wake-on-lan settings: No such device
> > > Cannot get message level: No such device
> > > Cannot get link status: No such device
> > > No data available
> > > zsh: exit 75 ethtool eth0
> > > [root@t400 ~]# ethtool -i eth0
> > > Cannot get driver information: No such device
> > > zsh: exit 71 ethtool -i eth0
> >
> > [...]
> >
> > Then there really isn't a device under that name. Maybe the driver is
> > getting a bogus MAC address, so that the device is renamed by udev.
>
> No, no, device exists:
>
> [arekm@t400 ~]$ ip l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state
> DOWN qlen 1000
> link/ether 00:21:86:a2:19:06 brd ff:ff:ff:ff:ff:ff
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc sfq state UP qlen
> 1000
> link/ether 00:16:eb:05:5d:08 brd ff:ff:ff:ff:ff:ff
> [arekm@t400 ~]$ ethtool eth0
> Settings for eth0:
> Cannot get device settings: No such device
> Cannot get wake-on-lan settings: No such device
> Cannot get message level: No such device
> Cannot get link status: No such device
> No data available
> zsh: exit 75 ethtool eth0
> [arekm@t400 ~]$
Then the only other explanation I can think of is that the driver has
'detached' the device due to some kind of error. The ethtool core does
have a check for that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [PATCH RFC] igb: Fix false positive return of igb_get_auto_rd_done for 82580
From: Wyborny, Carolyn @ 2011-07-06 15:28 UTC (permalink / raw)
To: Guenter Roeck, Kirsher, Jeffrey T
Cc: Brandeburg, Jesse, Duyck, Alexander H, Ronciak, John,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Tong Ho
In-Reply-To: <20110705143105.GA27454@ericsson.com>
>-----Original Message-----
>From: Guenter Roeck [mailto:guenter.roeck@ericsson.com]
>Sent: Tuesday, July 05, 2011 7:31 AM
>To: Kirsher, Jeffrey T
>Cc: Brandeburg, Jesse; Wyborny, Carolyn; Duyck, Alexander H; Ronciak,
>John; e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Tong Ho
>Subject: Re: [PATCH RFC] igb: Fix false positive return of
>igb_get_auto_rd_done for 82580
>
>On Tue, Jun 21, 2011 at 05:17:26PM -0400, Jeff Kirsher wrote:
>> On Tue, 2011-06-21 at 12:02 -0700, Guenter Roeck wrote:
>> > From: Tong Ho <tong.ho@ericsson.com>
>> >
>> > 82580 re-reads the port specific portion of eeprom after port reset.
>> > If called immediately after a reset, igb_get_auto_rd_done() returns
>> > false positive because the done bit has yet to transition from 1 to
>0.
>> >
>> > Add wrfl() immediately after resetting 82580 port or device,
>> > plus a 1ms delay, to avoid the problem.
>> >
>> > Signed-off-by: Tong Ho <tong.ho@ericsson.com>
>> > Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
>> > ---
>> > Sent as RFC since I am not entirely sure if the solution is the
>> > correct one
>> > to address the problem we are seeing. If there is a better solution,
>> > please
>> > let me know.
>>
>> Thank you for the suggested patch. Carolyn is the maintainer for igb
>> and we will look into this issue you are seeing and the suggested fix.
>
>Hi Jeff and Carolyn,
>
>Any update ?
>
>Thanks,
>Guenter
Sorry for the delay, we've had some holidays, its just passed internal testing and should be coming upstream shortly.
Thanks,
Carolyn
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply
* Re: [PATCH v3 4/4] packet: Add pre-defragmentation support for ipv4
From: Eric Dumazet @ 2011-07-06 15:27 UTC (permalink / raw)
To: David Miller; +Cc: mika.penttila, netdev
In-Reply-To: <20110706.082040.1487690721120263418.davem@davemloft.net>
Le mercredi 06 juillet 2011 à 08:20 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 06 Jul 2011 17:18:09 +0200
>
> > [PATCH] packet: fix a leak in fanout_check_defrag()
> >
> > Reported-by: Penttilä Mika <mika.penttila@ixonos.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Eric, see what I commited, it's much simpler than all
> of this code movement you added, ala skb_share_check()
> :-)
I tried to not lose the original packet and let application catch it ;)
We probably need to add some atomic_inc(&sk->sk_drops) to at least warn
the application.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Michael Büsch @ 2011-07-06 15:32 UTC (permalink / raw)
To: Neil Horman
Cc: Eric Dumazet, Alexey Zaytsev, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110705220644.GB12118@hmsreliant.think-freely.org>
On Tue, 5 Jul 2011 18:06:44 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> On Tue, Jul 05, 2011 at 10:15:40PM +0200, Eric Dumazet wrote:
> > Le mardi 05 juillet 2011 à 22:02 +0200, Eric Dumazet a écrit :
> > > Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> > > > I think this is a goo idea, at least for testing. It seems odd to me that we
> > > > have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> > > > descriptor to be processed next (the documentation isnt' very verbose on the
> > > > subject), along with the EOT bit on a descriptor. It seems like both the
> > > > register and the bit are capable of conveying the same (or at least overlapping)
> > > > information.
> > > >
> > > > I think what I'm having the most trouble with is understanding when the hw looks
> > > > at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
> > > > set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> > > > register? Of does it stall until such time as the DMARX_PTR register is rotated
> > > > around? What if it doesn't see the EOT bit set? Does it just keep going with
> > > > the next descriptor?
> >
> > Since there is no OWN bit (at least not on the online doc I got : it
> > says the rx_ring is read only by the NIC), I would say we really need to
> > advance DMARX_PTR to signal NIC a new entry is available for following
> > incoming frames.
> >
> > This is the reason rx_pending max value is B44_RX_RING_SIZE - 1, or else
> > chip could loop on a circular rx_ring.
> >
> Agree, although that still leaves open the question of what exactly should get
> written into the DMARX_PTR. Is it an index of the descriptor number, or a byte
> offset.
>
> Regardless, I think we ned to fix up the looping so as to prevent an EOT reset
> jumping outside of our valid ring window. Alexey, theres better ways to do
> this, but if in the interim, you could please try this patch, it makes the valid
> receive window for b44 cover the entire ring, so as to avoid this problem. It
> will at least help support or refute this theory. Note its not exactly the same
> as my previous patch. If you set the default ring pending to 512, the math in
> the b44_alloc_rx_skb path is wrong, we skip the EOT bit as well as the first
> entry in the ring. At 511 it should work out properly.
>
> Thanks
> Neil
>
>
> diff --git a/drivers/net/b44.c b/drivers/net/b44.c
> index 3d247f3..b7f5ed1 100644
> --- a/drivers/net/b44.c
> +++ b/drivers/net/b44.c
> @@ -57,7 +57,7 @@
> #define B44_MAX_MTU 1500
>
> #define B44_RX_RING_SIZE 512
> -#define B44_DEF_RX_RING_PENDING 200
> +#define B44_DEF_RX_RING_PENDING 511
> #define B44_RX_RING_BYTES (sizeof(struct dma_desc) * \
> B44_RX_RING_SIZE)
> #define B44_TX_RING_SIZE 512
You guys are mixing up quite a bit of stuff here...
The EOT bit has _nothing_ to do with the descriptor pointers.
It simply marks the last descriptor in the (linear) descriptor
page, so that it becomes an actual ring:
DDDDDDDDDDDDDDDDDDDDDDDDDDDE
| O
| T
^--------------------------|
It doesn't say anything about the read and write pointers
to the ring.
The B44_DMARX_PTR is the write-end pointer. It points one entry
beyond the end of the write area. Then there's the software pointer
where we keep track of the read position.
-rx_cons DMARX_PTR-
v v
DDDDDDDDDDDDDDDDDDDDDDDDDDE
^ ^ O
| | T
Device might write from
here to here.
On an RX interrupt (or poll), we read the _actual_ device write
pointer. (B44_DMARX_STAT & DMARX_STAT_CDMASK). If that is equal
to our stored rx_cons, the device didn't write anything.
So we read buffers until we hit the _actual_ device write pointer.
So rx_cons is equal to (B44_DMARX_STAT & DMARX_STAT_CDMASK), except
that it lags behind by one IRQ/poll.
If we read are done, we set the DMARX_PTR write pointer to one desc
beyond the buffer that we just ate. So the device is free to continue
writing the ring _up to_ the position we left.
I don't know why b44 sets the DMARX_PTR to 200 initially (which is 40
descriptors, as this is a byte pointer). This seems kind of arbitrary.
In b43 we set it to (NR_OF_DESCRIPTORS - 1) * sizeof(descriptor).
But I don't think it really matters. It only limits the usable DMA
area before the first interrupt (or poll) occurs. After the final
B44_DMARX_PTR write in b44_rx(), the full descriptor range (well, minus one)
will be usable.
Summary: I don't see where the DMA engine code is broken (except for
the minor missing wmb(), which doesn't trigger this memory corruption, though)
I hope that helps to clear up stuff...
^ permalink raw reply
* Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown
From: Thomas Graf @ 2011-07-06 15:49 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, davem, Wei Yongjun, Sridhar Samudrala, linux-sctp
In-Reply-To: <4E1471DC.2090407@hp.com>
On Wed, Jul 06, 2011 at 10:31:56AM -0400, Vladislav Yasevich wrote:
> >>> + *
> >>> + * Allow the association to timeout if SHUTDOWN is
> >>> + * pending in case the receiver stays in zero window
> >>> + * mode forever.
> >>> */
> >>> if (!q->asoc->peer.rwnd &&
> >>> !list_empty(&tlist) &&
> >>> - (sack_ctsn+2 == q->asoc->next_tsn)) {
> >>> + (sack_ctsn+2 == q->asoc->next_tsn) &&
> >>> + !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) {
> >>
> >> Would a test for (q->asoc->state != SCTP_STATE_SHUTDOWN_PENDING) be clearer? We only
> >> care about the PENDING state here.
> >
> > I think SHUTDOWN_RECEIVED should also be included. We continue to transmit and
> > process SACKs after receiving a SHUTDOWN.
>
> I am not sure about SHUTDOWN_RECEIVED. If we received shutdown, then we are not in
> a 0 window situation. Additionally, the sender of the SHUTDOWN started the GUARD timer
> and will abort after it expires. So there is no special handling on our part.
Why can't we be in a 0 window situation? A well behaving sctp peer may not,
but we're on the Internet, everyone behaves at their worst :-)
Seriously, this would make for a simple dos. Establish a stream, don't ack any
data to make sure there is something on the retransmission queue of the peer.
Immediately shutdown the stream and ack any retransmission attempt with
a_rwnd=0 to keep the association around forever.
Starting the T5 SHUTDOWN GUARD timer is specified as MAY and not MUST so even in
a well behaving world we could not really rely on it.
Alternatively the peer could just be buggy as well.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-06 16:00 UTC (permalink / raw)
To: Michael Büsch
Cc: Neil Horman, Alexey Zaytsev, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110706173243.404d8599@maggie>
Le mercredi 06 juillet 2011 à 17:32 +0200, Michael Büsch a écrit :
> You guys are mixing up quite a bit of stuff here...
>
> The EOT bit has _nothing_ to do with the descriptor pointers.
> It simply marks the last descriptor in the (linear) descriptor
> page, so that it becomes an actual ring:
>
> DDDDDDDDDDDDDDDDDDDDDDDDDDDE
> | O
> | T
> ^--------------------------|
>
> It doesn't say anything about the read and write pointers
> to the ring.
>
> The B44_DMARX_PTR is the write-end pointer. It points one entry
> beyond the end of the write area. Then there's the software pointer
> where we keep track of the read position.
>
> -rx_cons DMARX_PTR-
> v v
> DDDDDDDDDDDDDDDDDDDDDDDDDDE
> ^ ^ O
> | | T
> Device might write from
> here to here.
>
> On an RX interrupt (or poll), we read the _actual_ device write
> pointer. (B44_DMARX_STAT & DMARX_STAT_CDMASK). If that is equal
> to our stored rx_cons, the device didn't write anything.
> So we read buffers until we hit the _actual_ device write pointer.
> So rx_cons is equal to (B44_DMARX_STAT & DMARX_STAT_CDMASK), except
> that it lags behind by one IRQ/poll.
> If we read are done, we set the DMARX_PTR write pointer to one desc
> beyond the buffer that we just ate. So the device is free to continue
> writing the ring _up to_ the position we left.
Not exactly :
If we read one skb at descriptor 0, we prepare a new buffer on slot 200,
and advance DMARX_PTR to 201*sizeof(descriptor).
>
> I don't know why b44 sets the DMARX_PTR to 200 initially (which is 40
> descriptors, as this is a byte pointer). This seems kind of arbitrary.
> In b43 we set it to (NR_OF_DESCRIPTORS - 1) * sizeof(descriptor).
> But I don't think it really matters. It only limits the usable DMA
> area before the first interrupt (or poll) occurs. After the final
> B44_DMARX_PTR write in b44_rx(), the full descriptor range (well, minus one)
> will be usable.
Yes, this is probably a small bug, we should fix it for correctness.
>
> Summary: I don't see where the DMA engine code is broken (except for
> the minor missing wmb(), which doesn't trigger this memory corruption, though)
>
> I hope that helps to clear up stuff...
Well, you describe (nicely, thanks !) your understanding of how work the
driver and chip.
Problem is we suspect a wrong statement or wrong hardware ;)
Another problem is Alexey doesnt answer anymore, and I dont have this
(old) hardware...
Other point : Do you know why b44_get_ringparam() doesnt set
ering->tx_max_pending and ering->tx_pending
The comment seems wrong :
/* XXX ethtool lacks a tx_max_pending, oops... */
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Michael Büsch @ 2011-07-06 16:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: Neil Horman, Alexey Zaytsev, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309968019.2292.44.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, 06 Jul 2011 18:00:19 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Not exactly :
>
> If we read one skb at descriptor 0, we prepare a new buffer on slot 200,
> and advance DMARX_PTR to 201*sizeof(descriptor).
I don't think so. Why do you think this is the case?
We allocate a new descriptor buffer for the consumed buffer at exactly
the same place (which is "cons").
(Alternatively, we leave the buffer in place, and just copy the data to a new buffer).
And DMARX_PTR is updated to the last "cons", which is one beyond
the last buffer that we consumed (and pushed up the net stack).
(Note that "beyond" always means "beyond" in the sense of a DMA _ring_,
which honors the EOT bit. This is done by masking cons with RX_RING_SIZE-1,
which is thus assumed to be a power of two).
> > I don't know why b44 sets the DMARX_PTR to 200 initially (which is 40
> > descriptors, as this is a byte pointer). This seems kind of arbitrary.
> > In b43 we set it to (NR_OF_DESCRIPTORS - 1) * sizeof(descriptor).
> > But I don't think it really matters. It only limits the usable DMA
> > area before the first interrupt (or poll) occurs. After the final
> > B44_DMARX_PTR write in b44_rx(), the full descriptor range (well, minus one)
> > will be usable.
>
> Yes, this is probably a small bug, we should fix it for correctness.
I wouldn't call this a bug.
> > Summary: I don't see where the DMA engine code is broken (except for
> > the minor missing wmb(), which doesn't trigger this memory corruption, though)
> >
> > I hope that helps to clear up stuff...
>
> Well, you describe (nicely, thanks !) your understanding of how work the
> driver and chip.
>
> Problem is we suspect a wrong statement or wrong hardware ;)
>
> Another problem is Alexey doesnt answer anymore, and I dont have this
> (old) hardware...
I do really think that either
1) His device is broken. Chips break. I already saw several devices
with HND DMA engine that broke down after some time of use.
or
2) The bug is at another place, but not in the lowlevel DMA handling.
Could this possibly be some kind of context issue? threaded IRQs?
The net subsys was rather picky about context, last time I looked
into it. see the .._ni() style functions.
> Other point : Do you know why b44_get_ringparam() doesnt set
> ering->tx_max_pending and ering->tx_pending
>
> The comment seems wrong :
> /* XXX ethtool lacks a tx_max_pending, oops... */
Well, I _guess_ that ering->tx_max_pending was added later? (I didn't
even check if it's there _now_, though.)
^ permalink raw reply
* [PATCH RESEND v2 3/3] net/fec: add device tree probe support
From: Shawn Guo @ 2011-07-06 16:22 UTC (permalink / raw)
To: netdev
Cc: devicetree-discuss, linux-arm-kernel, patches, Shawn Guo,
Jason Liu, David S. Miller, Grant Likely
In-Reply-To: <1309878839-25743-4-git-send-email-shawn.guo@linaro.org>
It adds device tree probe support for fec driver.
Signed-off-by: Jason Liu <jason.hui@linaro.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
Resend with changes:
* use of_get_named_gpio for phy-reset-gpios
Documentation/devicetree/bindings/net/fsl-fec.txt | 24 +++++
drivers/net/fec.c | 98 +++++++++++++++++++-
2 files changed, 117 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/fsl-fec.txt
diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
new file mode 100644
index 0000000..de43951
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -0,0 +1,24 @@
+* Freescale Fast Ethernet Controller (FEC)
+
+Required properties:
+- compatible : Should be "fsl,<soc>-fec"
+- reg : Address and length of the register set for the device
+- interrupts : Should contain fec interrupt
+- phy-mode : String, operation mode of the PHY interface.
+ Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
+ "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
+- phy-reset-gpios : Should specify the gpio for phy reset
+
+Optional properties:
+- local-mac-address : 6 bytes, mac address
+
+Example:
+
+fec@83fec000 {
+ compatible = "fsl,imx51-fec", "fsl,imx27-fec";
+ reg = <0x83fec000 0x4000>;
+ interrupts = <87>;
+ phy-mode = "mii";
+ phy-reset-gpios = <&gpio1 14 0>; /* GPIO2_14 */
+ local-mac-address = [00 04 9F 01 1B B9];
+};
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 7ae3f28..720aa63 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -44,6 +44,10 @@
#include <linux/platform_device.h>
#include <linux/phy.h>
#include <linux/fec.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/of_net.h>
#include <asm/cacheflush.h>
@@ -78,6 +82,17 @@ static struct platform_device_id fec_devtype[] = {
{ }
};
+enum fec_type {
+ IMX27_FEC,
+ IMX28_FEC,
+};
+
+static const struct of_device_id fec_dt_ids[] = {
+ { .compatible = "fsl,imx27-fec", .data = &fec_devtype[IMX27_FEC], },
+ { .compatible = "fsl,imx28-fec", .data = &fec_devtype[IMX28_FEC], },
+ { /* sentinel */ }
+};
+
static unsigned char macaddr[ETH_ALEN];
module_param_array(macaddr, byte, NULL, 0);
MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
@@ -734,8 +749,22 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
*/
iap = macaddr;
+#ifdef CONFIG_OF
+ /*
+ * 2) from device tree data
+ */
+ if (!is_valid_ether_addr(iap)) {
+ struct device_node *np = fep->pdev->dev.of_node;
+ if (np) {
+ const char *mac = of_get_mac_address(np);
+ if (mac)
+ iap = (unsigned char *) mac;
+ }
+ }
+#endif
+
/*
- * 2) from flash or fuse (via platform data)
+ * 3) from flash or fuse (via platform data)
*/
if (!is_valid_ether_addr(iap)) {
#ifdef CONFIG_M5272
@@ -748,7 +777,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
}
/*
- * 3) FEC mac registers set by bootloader
+ * 4) FEC mac registers set by bootloader
*/
if (!is_valid_ether_addr(iap)) {
*((unsigned long *) &tmpaddr[0]) =
@@ -1358,6 +1387,52 @@ static int fec_enet_init(struct net_device *ndev)
return 0;
}
+#ifdef CONFIG_OF
+static int __devinit fec_get_phy_mode_dt(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+
+ if (np)
+ return of_get_phy_mode(np);
+
+ return -ENODEV;
+}
+
+static int __devinit fec_reset_phy(struct platform_device *pdev)
+{
+ int err, phy_reset;
+ struct device_node *np = pdev->dev.of_node;
+
+ if (!np)
+ return -ENODEV;
+
+ phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
+ err = gpio_request_one(phy_reset, GPIOF_OUT_INIT_LOW, "phy-reset");
+ if (err) {
+ pr_warn("FEC: failed to get gpio phy-reset: %d\n", err);
+ return err;
+ }
+
+ gpio_set_value(phy_reset, 1);
+
+ return 0;
+}
+#else /* CONFIG_OF */
+static inline int fec_get_phy_mode_dt(struct platform_device *pdev)
+{
+ return -ENODEV;
+}
+
+static inline int fec_reset_phy(struct platform_device *pdev)
+{
+ /*
+ * In case of platform probe, the reset has been done
+ * by machine code.
+ */
+ return 0;
+}
+#endif /* CONFIG_OF */
+
static int __devinit
fec_probe(struct platform_device *pdev)
{
@@ -1366,6 +1441,11 @@ fec_probe(struct platform_device *pdev)
struct net_device *ndev;
int i, irq, ret = 0;
struct resource *r;
+ const struct of_device_id *of_id;
+
+ of_id = of_match_device(fec_dt_ids, &pdev->dev);
+ if (of_id)
+ pdev->id_entry = of_id->data;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r)
@@ -1397,9 +1477,16 @@ fec_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ndev);
- pdata = pdev->dev.platform_data;
- if (pdata)
- fep->phy_interface = pdata->phy;
+ fep->phy_interface = fec_get_phy_mode_dt(pdev);
+ if (fep->phy_interface < 0) {
+ pdata = pdev->dev.platform_data;
+ if (pdata)
+ fep->phy_interface = pdata->phy;
+ else
+ fep->phy_interface = PHY_INTERFACE_MODE_MII;
+ }
+
+ fec_reset_phy(pdev);
/* This device has up to three irqs on some platforms */
for (i = 0; i < 3; i++) {
@@ -1534,6 +1621,7 @@ static struct platform_driver fec_driver = {
#ifdef CONFIG_PM
.pm = &fec_pm_ops,
#endif
+ .of_match_table = fec_dt_ids,
},
.id_table = fec_devtype,
.probe = fec_probe,
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown
From: Vladislav Yasevich @ 2011-07-06 16:23 UTC (permalink / raw)
To: netdev, davem, Wei Yongjun, Sridhar Samudrala, linux-sctp
In-Reply-To: <20110706154900.GB17652@canuck.infradead.org>
On 07/06/2011 11:49 AM, Thomas Graf wrote:
> On Wed, Jul 06, 2011 at 10:31:56AM -0400, Vladislav Yasevich wrote:
>>>>> + *
>>>>> + * Allow the association to timeout if SHUTDOWN is
>>>>> + * pending in case the receiver stays in zero window
>>>>> + * mode forever.
>>>>> */
>>>>> if (!q->asoc->peer.rwnd &&
>>>>> !list_empty(&tlist) &&
>>>>> - (sack_ctsn+2 == q->asoc->next_tsn)) {
>>>>> + (sack_ctsn+2 == q->asoc->next_tsn) &&
>>>>> + !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) {
>>>>
>>>> Would a test for (q->asoc->state != SCTP_STATE_SHUTDOWN_PENDING) be clearer? We only
>>>> care about the PENDING state here.
>>>
>>> I think SHUTDOWN_RECEIVED should also be included. We continue to transmit and
>>> process SACKs after receiving a SHUTDOWN.
>>
>> I am not sure about SHUTDOWN_RECEIVED. If we received shutdown, then we are not in
>> a 0 window situation. Additionally, the sender of the SHUTDOWN started the GUARD timer
>> and will abort after it expires. So there is no special handling on our part.
>
> Why can't we be in a 0 window situation? A well behaving sctp peer may not,
> but we're on the Internet, everyone behaves at their worst :-)
>
> Seriously, this would make for a simple dos. Establish a stream, don't ack any
> data to make sure there is something on the retransmission queue of the peer.
> Immediately shutdown the stream and ack any retransmission attempt with
> a_rwnd=0 to keep the association around forever.
>
> Starting the T5 SHUTDOWN GUARD timer is specified as MAY and not MUST so even in
> a well behaving world we could not really rely on it.
>
> Alternatively the peer could just be buggy as well.
>
You are right. Without a receiver patch, a linux receiver would stay in 0-window condition
while sending a SHUTDOWN with a_rwnd of 0.
How about instead of checking for "Not greater then or equals", we instead simply test for
"less then"?
-vlad
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-06 16:35 UTC (permalink / raw)
To: Michael Büsch
Cc: Neil Horman, Alexey Zaytsev, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110706181258.57b3c112@maggie>
Le mercredi 06 juillet 2011 à 18:12 +0200, Michael Büsch a écrit :
> On Wed, 06 Jul 2011 18:00:19 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Not exactly :
> >
> > If we read one skb at descriptor 0, we prepare a new buffer on slot 200,
> > and advance DMARX_PTR to 201*sizeof(descriptor).
>
> I don't think so. Why do you think this is the case?
> We allocate a new descriptor buffer for the consumed buffer at exactly
> the same place (which is "cons").
> (Alternatively, we leave the buffer in place, and just copy the data to a new buffer).
> And DMARX_PTR is updated to the last "cons", which is one beyond
> the last buffer that we consumed (and pushed up the net stack).
Not at all.
If it was true, b44_recycle_rx() would not even exist as is.
When we allocate a new buffer, we put it at rx_prod index, which is the
slot _after_ window, not the first slot.
First time we dequeue a packet from NIC, rx_prod is something like 200
Oh, it seems we do the following in b44_init_hw()
bp->rx_prod = bp->rx_pending;
But this seems completely wrong, if b44_init_rings() was not able to
allocate rx_pending buffers (b44_alloc_rx_skb() can return NULL)
^ permalink raw reply
* Re: 3.0.0rc6: ethtool not working without a cable
From: Brandeburg, Jesse @ 2011-07-06 16:52 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Arkadiusz Miskiewicz, netdev@vger.kernel.org, e1000-devel
In-Reply-To: <1309966010.2712.4.camel@bwh-desktop>
On Wed, 2011-07-06 at 08:26 -0700, Ben Hutchings wrote:
> On Wed, 2011-07-06 at 16:53 +0200, Arkadiusz Miskiewicz wrote:
> > On Wednesday 06 of July 2011, Ben Hutchings wrote:
> > > On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > > > 3.0.0rc6, thinkpad t400 notebook.
> > > >
> > > > If there is no cable then ethtool reports no device. It wasn't that
> > > > before AFAIK.
> > > >
> > > > ethtool version 2.6.36
snip
> Then the only other explanation I can think of is that the driver has
> 'detached' the device due to some kind of error. The ethtool core does
> have a check for that.
could it be that aspm is enabled or that you've enabled runtime power
management?
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-06 16:56 UTC (permalink / raw)
To: Michael Büsch
Cc: Neil Horman, Alexey Zaytsev, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110706173243.404d8599@maggie>
Le mercredi 06 juillet 2011 à 17:32 +0200, Michael Büsch a écrit :
> You guys are mixing up quite a bit of stuff here...
Well
>
> The EOT bit has _nothing_ to do with the descriptor pointers.
> It simply marks the last descriptor in the (linear) descriptor
> page, so that it becomes an actual ring:
>
> DDDDDDDDDDDDDDDDDDDDDDDDDDDE
> | O
> | T
> ^--------------------------|
>
> It doesn't say anything about the read and write pointers
> to the ring.
>
> The B44_DMARX_PTR is the write-end pointer. It points one entry
> beyond the end of the write area. Then there's the software pointer
> where we keep track of the read position.
>
Thats not how b44_rx() works :
It writes on DMARX_PTR the last slot that driver _dequeued_ in its NAPI
run. Its not the end of the window that device is allowed to use.
bw32(bp, B44_DMARX_PTR, cons * sizeof(struct dma_desc));
The end of the 'allocated buffers' is in rx_prod. Problem is NIC have no
idea of where is the end of window. We never give rx_prod to NIC.
So NIC actually read old descriptors value. We need to clear them to
avoid memory corruption.
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 6c4ef96..ec9773b 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -725,6 +725,7 @@ static void b44_recycle_rx(struct b44 *bp, int src_idx, u32 dest_idx_unmasked)
DMA_BIDIRECTIONAL);
ctrl = src_desc->ctrl;
+ src_desc->ctrl = ctrl & cpu_to_le32(DESC_CTRL_EOT);
if (dest_idx == (B44_RX_RING_SIZE - 1))
ctrl |= cpu_to_le32(DESC_CTRL_EOT);
else
@@ -732,6 +733,7 @@ static void b44_recycle_rx(struct b44 *bp, int src_idx, u32 dest_idx_unmasked)
dest_desc->ctrl = ctrl;
dest_desc->addr = src_desc->addr;
+ src_desc->addr = 0;
src_map->skb = NULL;
@@ -1118,6 +1120,7 @@ static void b44_init_rings(struct b44 *bp)
if (b44_alloc_rx_skb(bp, -1, i) < 0)
break;
}
+ bp->rx_prod = i;
}
/*
@@ -1406,7 +1409,6 @@ static void b44_init_hw(struct b44 *bp, int reset_kind)
bw32(bp, B44_DMARX_ADDR, bp->rx_ring_dma + bp->dma_offset);
bw32(bp, B44_DMARX_PTR, bp->rx_pending);
- bp->rx_prod = bp->rx_pending;
bw32(bp, B44_MIB_CTRL, MIB_CTRL_CLR_ON_READ);
}
^ permalink raw reply related
* Re: 3.0.0rc6: ethtool not working without a cable
From: Arkadiusz Miskiewicz @ 2011-07-06 16:57 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: Ben Hutchings, netdev@vger.kernel.org, e1000-devel
In-Reply-To: <1309971146.6217.0.camel@jbrandeb-mobl.amr.corp.intel.com>
On Wednesday 06 of July 2011, Brandeburg, Jesse wrote:
> On Wed, 2011-07-06 at 08:26 -0700, Ben Hutchings wrote:
> > On Wed, 2011-07-06 at 16:53 +0200, Arkadiusz Miskiewicz wrote:
> > > On Wednesday 06 of July 2011, Ben Hutchings wrote:
> > > > On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > > > > 3.0.0rc6, thinkpad t400 notebook.
> > > > >
> > > > > If there is no cable then ethtool reports no device. It wasn't that
> > > > > before AFAIK.
> > > > >
> > > > > ethtool version 2.6.36
>
> snip
>
> > Then the only other explanation I can think of is that the driver has
> > 'detached' the device due to some kind of error. The ethtool core does
> > have a check for that.
>
> could it be that aspm is enabled
I have CONFIG_PCIEASPM=y
> or that you've enabled runtime power
> management?
In e1000e? no (unless it's default somehow).
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* [PATCH 00/10] dynamic_debug: various fixes
From: Jason Baron @ 2011-07-06 17:24 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
Hi,
Various dynamic debug fixes and cleanups, and a patch to add myself as
maintainer. Hopefully, nobody will object too loudly :)
Thanks,
-Jason
Joe Perches (4):
dynamic_debug: Add __dynamic_dev_dbg
dynamic_debug: Consolidate prefix output to single routine
dynamic_debug: Remove uses of KERN_CONT in dynamic_emit_prefix
dynamic_debug: Convert printks to pr_<level>
Jason Baron (6):
dynamic_debug: remove unused control variables
dynamic_debug: add myslef as maintainer
dynamic_debug: make netdev_dbg() call __netdev_printk()
dynamic_debug: make netif_dbg() call __netdev_printk()
dynamic_debug: consolidate repetitive struct _ddebug descriptor
definitions
dynamic_debug: remove num_enabled accounting
MAINTAINERS | 6 ++
drivers/base/core.c | 5 +-
include/linux/device.h | 5 +
include/linux/dynamic_debug.h | 58 ++++++++++-----
include/linux/netdevice.h | 12 ++--
lib/dynamic_debug.c | 165 ++++++++++++++++++++++++++++-------------
net/core/dev.c | 3 +-
7 files changed, 172 insertions(+), 82 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH 01/10] dynamic_debug: Add __dynamic_dev_dbg
From: Jason Baron @ 2011-07-06 17:24 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1309967232.git.root@dhcp-100-18-164.bos.redhat.com>
From: Joe Perches <joe@perches.com>
Unlike dynamic_pr_debug, dynamic uses of dev_dbg can not
currently add task_pid/KBUILD_MODNAME/__func__/__LINE__
to selected debug output.
Add a new function similar to dynamic_pr_debug to
optionally emit these prefixes.
Cc: Aloisio Almeida <aloisio.almeida@openbossa.org>
Noticed-by: Aloisio Almeida <aloisio.almeida@openbossa.org>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
drivers/base/core.c | 5 +++--
include/linux/device.h | 5 +++++
include/linux/dynamic_debug.h | 10 ++++++++--
lib/dynamic_debug.c | 38 ++++++++++++++++++++++++++++++++++++++
4 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bc8729d..82c8654 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1764,8 +1764,8 @@ void device_shutdown(void)
#ifdef CONFIG_PRINTK
-static int __dev_printk(const char *level, const struct device *dev,
- struct va_format *vaf)
+int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf)
{
if (!dev)
return printk("%s(NULL device *): %pV", level, vaf);
@@ -1773,6 +1773,7 @@ static int __dev_printk(const char *level, const struct device *dev,
return printk("%s%s %s: %pV",
level, dev_driver_string(dev), dev_name(dev), vaf);
}
+EXPORT_SYMBOL(__dev_printk);
int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
diff --git a/include/linux/device.h b/include/linux/device.h
index 553fd37..5a9c8b5 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -786,6 +786,8 @@ extern const char *dev_driver_string(const struct device *dev);
#ifdef CONFIG_PRINTK
+extern int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf);
extern int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
@@ -806,6 +808,9 @@ extern int _dev_info(const struct device *dev, const char *fmt, ...)
#else
+static inline int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf)
+ { return 0; }
static inline int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index e747ecd..bdf1531 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -47,6 +47,13 @@ extern int ddebug_remove_module(const char *mod_name);
extern int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
__attribute__ ((format (printf, 2, 3)));
+struct device;
+
+extern int __dynamic_dev_dbg(struct _ddebug *descriptor,
+ const struct device *dev,
+ const char *fmt, ...)
+ __attribute__ ((format (printf, 3, 4)));
+
#define dynamic_pr_debug(fmt, ...) do { \
static struct _ddebug descriptor \
__used \
@@ -57,7 +64,6 @@ extern int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
__dynamic_pr_debug(&descriptor, pr_fmt(fmt), ##__VA_ARGS__); \
} while (0)
-
#define dynamic_dev_dbg(dev, fmt, ...) do { \
static struct _ddebug descriptor \
__used \
@@ -65,7 +71,7 @@ extern int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
{ KBUILD_MODNAME, __func__, __FILE__, fmt, __LINE__, \
_DPRINTK_FLAGS_DEFAULT }; \
if (unlikely(descriptor.enabled)) \
- dev_printk(KERN_DEBUG, dev, fmt, ##__VA_ARGS__); \
+ __dynamic_dev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__); \
} while (0)
#else
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 75ca78f..5c5f8f9 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -30,6 +30,7 @@
#include <linux/jump_label.h>
#include <linux/hardirq.h>
#include <linux/sched.h>
+#include <linux/device.h>
extern struct _ddebug __start___verbose[];
extern struct _ddebug __stop___verbose[];
@@ -456,6 +457,43 @@ int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
}
EXPORT_SYMBOL(__dynamic_pr_debug);
+int __dynamic_dev_dbg(struct _ddebug *descriptor,
+ const struct device *dev, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ int res;
+
+ BUG_ON(!descriptor);
+ BUG_ON(!fmt);
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ res = printk(KERN_DEBUG);
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_TID) {
+ if (in_interrupt())
+ res += printk(KERN_CONT "<intr> ");
+ else
+ res += printk(KERN_CONT "[%d] ", task_pid_vnr(current));
+ }
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_MODNAME)
+ res += printk(KERN_CONT "%s:", descriptor->modname);
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_FUNCNAME)
+ res += printk(KERN_CONT "%s:", descriptor->function);
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_LINENO)
+ res += printk(KERN_CONT "%d ", descriptor->lineno);
+
+ res += __dev_printk("", dev, &vaf);
+
+ va_end(args);
+
+ return res;
+}
+EXPORT_SYMBOL(__dynamic_dev_dbg);
+
static __initdata char ddebug_setup_string[1024];
static __init int ddebug_setup_query(char *str)
{
--
1.7.5.4
^ permalink raw reply related
* [PATCH 07/10] dynamic_debug: make netdev_dbg() call __netdev_printk()
From: Jason Baron @ 2011-07-06 17:25 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1309967232.git.root@dhcp-100-18-164.bos.redhat.com>
From: Jason Baron <jbaron@redhat.com>
Previously, if dynamic debug was enabled netdev_dbg() was using
dynamic_dev_dbg() to print out the underlying msg. Fix this by making
sure netdev_dbg() uses __netdev_printk().
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
include/linux/dynamic_debug.h | 17 +++++++++++++++++
include/linux/netdevice.h | 6 ++++--
lib/dynamic_debug.c | 25 +++++++++++++++++++++++++
net/core/dev.c | 3 ++-
4 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 843cb9e..feaac1e 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -47,6 +47,13 @@ extern int __dynamic_dev_dbg(struct _ddebug *descriptor,
const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
+struct net_device;
+
+extern int __dynamic_netdev_dbg(struct _ddebug *descriptor,
+ const struct net_device *dev,
+ const char *fmt, ...)
+ __attribute__ ((format (printf, 3, 4)));
+
#define dynamic_pr_debug(fmt, ...) do { \
static struct _ddebug descriptor \
__used \
@@ -67,6 +74,16 @@ extern int __dynamic_dev_dbg(struct _ddebug *descriptor,
__dynamic_dev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__); \
} while (0)
+#define dynamic_netdev_dbg(dev, fmt, ...) do { \
+ static struct _ddebug descriptor \
+ __used \
+ __attribute__((section("__verbose"), aligned(8))) = \
+ { KBUILD_MODNAME, __func__, __FILE__, fmt, __LINE__, \
+ _DPRINTK_FLAGS_DEFAULT }; \
+ if (unlikely(descriptor.enabled)) \
+ __dynamic_netdev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__);\
+ } while (0)
+
#else
static inline int ddebug_remove_module(const char *mod)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 54b8b4d..9b132ef 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2635,6 +2635,9 @@ static inline const char *netdev_name(const struct net_device *dev)
return dev->name;
}
+extern int __netdev_printk(const char *level, const struct net_device *dev,
+ struct va_format *vaf);
+
extern int netdev_printk(const char *level, const struct net_device *dev,
const char *format, ...)
__attribute__ ((format (printf, 3, 4)));
@@ -2662,8 +2665,7 @@ extern int netdev_info(const struct net_device *dev, const char *format, ...)
#elif defined(CONFIG_DYNAMIC_DEBUG)
#define netdev_dbg(__dev, format, args...) \
do { \
- dynamic_dev_dbg((__dev)->dev.parent, "%s: " format, \
- netdev_name(__dev), ##args); \
+ dynamic_netdev_dbg(__dev, format, ##args); \
} while (0)
#else
#define netdev_dbg(__dev, format, args...) \
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index e627874..db66a48 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -33,6 +33,7 @@
#include <linux/hardirq.h>
#include <linux/sched.h>
#include <linux/device.h>
+#include <linux/netdevice.h>
extern struct _ddebug __start___verbose[];
extern struct _ddebug __stop___verbose[];
@@ -503,6 +504,30 @@ int __dynamic_dev_dbg(struct _ddebug *descriptor,
}
EXPORT_SYMBOL(__dynamic_dev_dbg);
+int __dynamic_netdev_dbg(struct _ddebug *descriptor,
+ const struct net_device *dev, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ int res;
+
+ BUG_ON(!descriptor);
+ BUG_ON(!fmt);
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ res = dynamic_emit_prefix(descriptor);
+ res += __netdev_printk("", dev, &vaf);
+
+ va_end(args);
+
+ return res;
+}
+EXPORT_SYMBOL(__dynamic_netdev_dbg);
+
static __initdata char ddebug_setup_string[1024];
static __init int ddebug_setup_query(char *str)
{
diff --git a/net/core/dev.c b/net/core/dev.c
index 9c58c1e..d6d48b2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6288,7 +6288,7 @@ const char *netdev_drivername(const struct net_device *dev)
return empty;
}
-static int __netdev_printk(const char *level, const struct net_device *dev,
+int __netdev_printk(const char *level, const struct net_device *dev,
struct va_format *vaf)
{
int r;
@@ -6303,6 +6303,7 @@ static int __netdev_printk(const char *level, const struct net_device *dev,
return r;
}
+EXPORT_SYMBOL(__netdev_printk);
int netdev_printk(const char *level, const struct net_device *dev,
const char *format, ...)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 08/10] dynamic_debug: make netif_dbg() call __netdev_printk()
From: Jason Baron @ 2011-07-06 17:25 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1309967232.git.root@dhcp-100-18-164.bos.redhat.com>
From: Jason Baron <jbaron@redhat.com>
Previously, netif_dbg() was using dynamic_dev_dbg() to perform
the underlying printk. Fix it to use __netdev_printk(), instead.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
include/linux/dynamic_debug.h | 12 ++++++++++++
include/linux/netdevice.h | 6 ++----
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index feaac1e..7048e64 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -84,6 +84,18 @@ extern int __dynamic_netdev_dbg(struct _ddebug *descriptor,
__dynamic_netdev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__);\
} while (0)
+#define dynamic_netif_dbg(dev, cond, fmt, ...) do { \
+ static struct _ddebug descriptor \
+ __used \
+ __attribute__((section("__verbose"), aligned(8))) = \
+ { KBUILD_MODNAME, __func__, __FILE__, fmt, __LINE__, \
+ _DPRINTK_FLAGS_DEFAULT }; \
+ if (unlikely(descriptor.enabled)) { \
+ if (cond) \
+ __dynamic_netdev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__);\
+ } \
+ } while (0)
+
#else
static inline int ddebug_remove_module(const char *mod)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9b132ef..99c358f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2731,10 +2731,8 @@ do { \
#elif defined(CONFIG_DYNAMIC_DEBUG)
#define netif_dbg(priv, type, netdev, format, args...) \
do { \
- if (netif_msg_##type(priv)) \
- dynamic_dev_dbg((netdev)->dev.parent, \
- "%s: " format, \
- netdev_name(netdev), ##args); \
+ dynamic_netif_dbg(netdev, (netif_msg_##type(priv)), \
+ format, ##args); \
} while (0)
#else
#define netif_dbg(priv, type, dev, format, args...) \
--
1.7.5.4
^ permalink raw reply related
* Re: Getting the correct asix AX88178 usb gige driver in mainline?
From: Marc MERLIN @ 2011-07-06 17:25 UTC (permalink / raw)
To: netdev; +Cc: greg
In-Reply-To: <20110629033025.GA32153@merlins.org>
Howdy netdev folks,
On Tue, Jul 05, 2011 at 08:35:19AM -0700, Greg KH wrote:
> I looked at this and it seems they took a very old version of the driver
> (from 2003) and somehow changed it to work for this device. I can't
> really tell what they changed unless I were to dig through the original
> version.
>
> I suggest you post your original message to the
> mailing list. The network developers there should be able to help you
> out as I can't at the moment due to real-work and travel.
Here are the details. If somehow their driver could be integrated in
mainline by putting the relevant bits in the current driver, that would be
fantastic :)
(obviously it would have been better if they had done that themselves to
start with, no idea why they didn't).
----------------------------------------------------------------------------
I just bought a USB gige ethernet adapter from 'winstars' called 'delphi g
usb 2.0 gigabit lan'.
Linux 2.6.39.1 says:
usb 8-1: Product: AX88178
usb 8-1: Manufacturer: ASIX Elec. Corp.
usb 8-1: SerialNumber: 000002
asix 8-1:1.0: eth1: register 'asix' at usb-0000:00:1d.7-1, ASIX AX88178 USB 2.0 Ethernet, 00:0e:c6:88:7c:ae
usbcore: registered new interface driver asix
but that driver brings up an eth1 that cannot send data.
Google showed me the vendor website with a working linux driver:
http://www.asix.com.tw/FrootAttach/driver/AX88772_772A_178_LINUX2.6.9_REV122.zip
Their driver which compiled out of tree easily and said:
ASIX USB Ethernet Adapter:v4.1.0 19:16:59 Jun 28 2011
<6> http://www.asix.com.tw
eth%d: status ep1in, 8 bytes period 11
eth1: register 'asix' at usb-0000:00:1d.7-1, ASIX AX88178 USB 2.0 Ethernet, 00:0e:c6:88:7c:ae
usbcore: registered new interface driver asix
eth1: rxqlen 0 --> 5
eth1: ax88178 - Link status is: 0
eth1: kevent 4 scheduled
eth1: ax88178 - Link status is: 1
eth1: no IPv6 routers present
It worked fine with dhcp (which the stock driver sure didn't).
Is there someone who can see if that driver can be merged in mainline to
replace the non working one?
For comparison, the mainline one also outputted a traceback. The full relevant logs are below:
usb 8-1: new high speed USB device number 8 using ehci_hcd
usb 8-1: New USB device found, idVendor=0b95, idProduct=1780
usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 8-1: Product: AX88178
usb 8-1: Manufacturer: ASIX Elec. Corp.
usb 8-1: SerialNumber: 000002
asix 8-1:1.0: eth1: register 'asix' at usb-0000:00:1d.7-1, ASIX AX88178 USB 2.0 Ethernet, 00:0e:c6:88:7c:ae
usbcore: registered new interface driver asix
asix 8-1:1.0: eth1: link down
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
asix 8-1:1.0: eth1: link up, 1000Mbps, full-duplex, lpa 0xC5E1
eth1: no IPv6 routers present
gandalfthegrey:~# ifconfig eth1 192.168.205.10
gandalfthegrey:~# ping 192.168.205.254
PING 192.168.205.254 (192.168.205.254) 56(84) bytes of data.
>From 192.168.205.10 icmp_seq=3 Destination Host Unreachable
>From 192.168.205.10 icmp_seq=4 Destination Host Unreachable
(tcpdump showed some traffic though)
Later, I found this in dmesg:
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x113/0x1a9()
Hardware name: 4063FM6
NETDEV WATCHDOG: eth1 (asix): transmit queue 0 timed out
Modules linked in: asix usbnet nfs fscache usb_storage usb_libusual uas xt_tcpudp xt_state nls_iso8859_1 nls_cp437 vfat fat vboxnetadp vboxnetflt vboxdrv fuse nfsd lockd nfs_acl auth_rpcgss sunrpc autofs4 acpi_cpufreq mperf cpufreq_conservative cpufreq_powersave ipt_REJECT cpufreq_stats cpufreq_userspace cpufreq_ondemand freq_table ipt_MASQUERADE ipt_LOG iptable_mangle iptable_filter rfcomm bnep binfmt_misc fbcon tileblit font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor iptable_nat nf_nat nf_conntrack_ipv4 i915 drm_kms_helper nf_conntrack drm fb fbdev nf_defrag_ipv4 i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect ip_tables x_tables ipv6 btusb bluetooth snd_hda_codec_conexant msr snd_hda_intel coretemp snd_hda_codec snd_hwdep snd_pcm_oss input_polldev snd_mixer_oss thinkpad_a
cpi snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq uvcvideo videodev media pcmcia arc4 snd_timer snd_seq_device r852 sm_common nand nand_ids yenta_socket pcmcia_rsrc iwlagn mac80211 nand_bch pcmcia_core rtc_cmos snd ppdev ehci_hcd bch sdhci_pci sdhci nand_ecc mtd mmc_core parport_pc r592 rtc_core uhci_hcd memstick cfg80211 snd_page_alloc rfkill e1000e soundcore processor battery rtc_lib usbcore psmouse lp ac nvram tpm_tis serio_raw sr_mod cdrom wmi evdev sg parport raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx multipath sha256_generic dm_crypt dm_mod aes_i586 aes_generic ecb cbc intel_agp intel_gtt video agpgart backlight thermal thermal_sys hwmon button
Pid: 0, comm: swapper Not tainted 2.6.39.1-core2-volpreempt-noide-hm64-20110620 #2
Call Trace:
[<c0133599>] warn_slowpath_common+0x60/0x75
[<c0133612>] warn_slowpath_fmt+0x26/0x2a
[<c03c8a35>] dev_watchdog+0x113/0x1a9
[<c012dd94>] ? try_to_wake_up+0x321/0x32c
[<c024f023>] ? jbd2_journal_force_commit_nested+0x6e/0x6e
[<c03c8922>] ? __netdev_watchdog_up+0x52/0x52
[<c013c8c1>] run_timer_softirq+0x139/0x1b5
[<c01380c1>] __do_softirq+0x7a/0x110
[<c0138047>] ? __local_bh_enable+0x6c/0x6c
<IRQ> [<c0137f7a>] ? irq_exit+0x3d/0x8b
[<c01039f1>] ? do_IRQ+0x7b/0x91
[<c0443bb0>] ? common_interrupt+0x30/0x38
[<c014007b>] ? get_signal_to_deliver+0x18d/0x32a
[<f8b82fc9>] ? acpi_idle_enter_simple+0x136/0x16a [processor]
[<c03a1a6f>] ? cpuidle_idle_call+0x6f/0xa0
[<c0101b91>] ? cpu_idle+0x8b/0xa6
[<c042a560>] ? rest_init+0x58/0x5a
[<c06257d6>] ? start_kernel+0x313/0x318
[<c06250a8>] ? i386_start_kernel+0xa8/0xb0
---[ end trace 0c6c364f0d69b5d1 ]---
device eth1 entered promiscuous mode
device eth1 left promiscuous mode
usbcore: deregistering interface driver asix
asix 8-1:1.0: eth1: unregister 'asix' usb-0000:00:1d.7-1, ASIX AX88178 USB 2.0 Ethernet
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
^ permalink raw reply
* Re: [PATCH 00/10] dynamic_debug: various fixes
From: Jim Cromie @ 2011-07-06 17:57 UTC (permalink / raw)
To: Jason Baron
Cc: gregkh, joe, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1309967232.git.root@dhcp-100-18-164.bos.redhat.com>
On Wed, Jul 6, 2011 at 11:24 AM, Jason Baron <jbaron@redhat.com> wrote:
> Hi,
>
> Various dynamic debug fixes and cleanups, and a patch to add myself as
> maintainer. Hopefully, nobody will object too loudly :)
>
do you have this in a git-tree somewhere I can pull ?
> Thanks,
>
> -Jason
>
>
> Joe Perches (4):
> dynamic_debug: Add __dynamic_dev_dbg
> dynamic_debug: Consolidate prefix output to single routine
> dynamic_debug: Remove uses of KERN_CONT in dynamic_emit_prefix
> dynamic_debug: Convert printks to pr_<level>
>
> Jason Baron (6):
> dynamic_debug: remove unused control variables
> dynamic_debug: add myslef as maintainer
> dynamic_debug: make netdev_dbg() call __netdev_printk()
> dynamic_debug: make netif_dbg() call __netdev_printk()
> dynamic_debug: consolidate repetitive struct _ddebug descriptor
> definitions
> dynamic_debug: remove num_enabled accounting
>
> MAINTAINERS | 6 ++
> drivers/base/core.c | 5 +-
> include/linux/device.h | 5 +
> include/linux/dynamic_debug.h | 58 ++++++++++-----
> include/linux/netdevice.h | 12 ++--
> lib/dynamic_debug.c | 165 ++++++++++++++++++++++++++++-------------
> net/core/dev.c | 3 +-
> 7 files changed, 172 insertions(+), 82 deletions(-)
>
> --
> 1.7.5.4
>
>
^ permalink raw reply
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Loke, Chetan @ 2011-07-06 18:12 UTC (permalink / raw)
To: Dan Magenheimer, netdev; +Cc: Konrad Wilk, linux-mm
In-Reply-To: <d19811cc-a722-4d30-8a43-aedb1cd978c9@default>
> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
> Sent: July 05, 2011 9:06 PM
> To: Loke, Chetan; netdev@vger.kernel.org
> Cc: Konrad Wilk; linux-mm
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
>
> > From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]
> > Subject: RE: [RFC] non-preemptible kernel socket for RAMster
> >
> > > From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
>
> > How often are you going to re-size your remote-SWAP?
>
> is "as often as the working set changes on any machine in the
> cluster", meaning *constantly*, entirely dynamically! How
> about a more specific example: Suppose you have 2 machines,
> each with 8GB of memory. 99% of the time each machine is
> chugging along just fine and doesn't really need more than 4GB,
> and may even use less than 1GB a large part of the time.
> But very now and then, one of the machines randomly needs
> 9GB, 10GB, maybe even 12GB of memory. This would normally
> result in swapping. (Most system administrators won't even
> have this much information... they'll just know they are
> seeing swapping and decide they need to buy more RAM.)
>
Ok, I understand there is interest in implementing
'remote-volatile-ballooning-variant' but how do you pick a remote
candidate(hypervisor)? Let's say, memory could be available on remote
system but what if the remote-p{NIC,CPU} is overloaded? Sure, sysadmins
won't have this info because this so dynamic(and it's quite possible as
you mentioned above). But does the trans-remote-API know about this
resource-availability before opening a remote-channel?
Stressing the remote-p{NIC/CPU} might trick hypervisor-vmotion-plugin to
vmotion VM[s] to another hypervisor. How is trans-remote-API integrating
with remote/global vmotion policies to avoid this false vmotion?
> Dan
Chetan Loke
^ permalink raw reply
* Re: [PATCH 00/10] dynamic_debug: various fixes
From: Jason Baron @ 2011-07-06 18:18 UTC (permalink / raw)
To: Jim Cromie
Cc: gregkh, joe, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <CAJfuBxyfA=Hjr8HEp47mKyr9fSdRGhppKr_-755vHQqn_RB=8Q@mail.gmail.com>
On Wed, Jul 06, 2011 at 11:57:21AM -0600, Jim Cromie wrote:
> >
> > Various dynamic debug fixes and cleanups, and a patch to add myself as
> > maintainer. Hopefully, nobody will object too loudly :)
> >
>
> do you have this in a git-tree somewhere I can pull ?
>
its only in a local tree...if you really need it, I can set something
up, but these are all the patches I have pending.
thanks,
-Jason
^ permalink raw reply
* Re: [PATCH V7 4/4 net-next] vhost: vhost TX zero-copy support
From: Shirley Ma @ 2011-07-06 19:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, Eric Dumazet, Avi Kivity, Arnd Bergmann, netdev,
kvm, linux-kernel
In-Reply-To: <20110629091300.GC14627@redhat.com>
On Wed, 2011-06-29 at 12:13 +0300, Michael S. Tsirkin wrote:
> On Sat, May 28, 2011 at 12:34:27PM -0700, Shirley Ma wrote:
> > Hello Michael,
> >
> > In order to use wait for completion in shutting down, seems to me
> > another work thread is needed to call vhost_zerocopy_add_used,
>
> Hmm I don't see vhost_zerocopy_add_used here.
I put the call in vhost_set_vring.
>
> > it seems
> > too much work to address a minor issue here. Do we really need it?
>
> Assuming you mean vhost_zerocopy_signal_used, here's how I would do
> it:
> add a kref and a completion, signal completion in kref_put
> callback, when backend is set - kref_get, on cleanup,
> kref_put and then wait_for_completion_interruptible.
> Where's the need for another thread coming from?
>
> If you like, post a patch with busywait + a FIXME comment,
> and I can write up a patch on top.
I might not have time to finish this during my vacation, so I am
putting busywait + a FIXME comment.
> (BTW, ideally the function that does the signalling should be
> in core networking bits so that it's still around
> even if the vhost module gets removed).
Thanks
Shirley
^ 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