* [PATCH net-next 0/2] xen-netback: windows frontend compatibility fixes
From: Paul Durrant @ 2013-09-20 13:57 UTC (permalink / raw)
To: netdev, xen-devel
The following patches fix a couple more issues found when testing with
Windows frontends.
v2:
- Add comment in 2/2 to note that state transitions from Connected to Closed
are incorrect.
^ permalink raw reply
* Re: [PATCH 13/51] DMA-API: net: sfc/efx.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Ben Hutchings @ 2013-09-20 13:55 UTC (permalink / raw)
To: Russell King; +Cc: netdev, Solarflare linux maintainers
In-Reply-To: <E1VMlvE-0007gc-B5@rmk-PC.arm.linux.org.uk>
[Trimmed cc's]
On Thu, 2013-09-19 at 22:38 +0100, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> drivers/net/ethernet/sfc/efx.c | 12 +-----------
> 1 files changed, 1 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
> index 07c9bc4..2e27837 100644
> --- a/drivers/net/ethernet/sfc/efx.c
> +++ b/drivers/net/ethernet/sfc/efx.c
> @@ -1121,7 +1121,7 @@ static int efx_init_io(struct efx_nic *efx)
> */
> while (dma_mask > 0x7fffffffUL) {
> if (dma_supported(&pci_dev->dev, dma_mask)) {
> - rc = dma_set_mask(&pci_dev->dev, dma_mask);
> + rc = dma_set_mask_and_coherent(&pci_dev->dev, dma_mask);
> if (rc == 0)
> break;
> }
> @@ -1134,16 +1134,6 @@ static int efx_init_io(struct efx_nic *efx)
> }
> netif_dbg(efx, probe, efx->net_dev,
> "using DMA mask %llx\n", (unsigned long long) dma_mask);
> - rc = dma_set_coherent_mask(&pci_dev->dev, dma_mask);
> - if (rc) {
> - /* dma_set_coherent_mask() is not *allowed* to
> - * fail with a mask that dma_set_mask() accepted,
> - * but just in case...
> - */
> - netif_err(efx, probe, efx->net_dev,
> - "failed to set consistent DMA mask\n");
> - goto fail2;
> - }
>
> efx->membase_phys = pci_resource_start(efx->pci_dev, EFX_MEM_BAR);
> rc = pci_request_region(pci_dev, EFX_MEM_BAR, "sfc");
--
Ben Hutchings, Staff 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 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
From: Russell King - ARM Linux @ 2013-09-20 13:49 UTC (permalink / raw)
To: Felipe Balbi
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, linux-crypto,
Greg Kroah-Hartman, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130920131125.GO26101@radagast>
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > Use platform_device_register_full() for those drivers which can, to
> > avoid messing directly with DMA masks. This can only be done when
> > the driver does not need to access the allocated musb platform device
> > from within its callbacks, which may be called during the musb
> > device probing.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> you want me to carry this one through my tree or you prefer getting my
> Acked-by ? Either way works for me:
>
> Acked-by: Felipe Balbi <balbi@ti.com>
>
> there's also the third option of me setting up a branch with only this
> patch and we both merge it, that'd also work.
I think this patch is sufficiently stand-alone that it should be fine
if you want to take it through your tree. That may be better in the
long run to avoid conflicts with this patch and any future work in
this area during this cycle.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] xen-netback: handle frontends that fail to transition through Closing
From: Wei Liu @ 2013-09-20 13:48 UTC (permalink / raw)
To: David Vrabel; +Cc: Wei Liu, Paul Durrant, netdev, xen-devel, Ian Campbell
In-Reply-To: <523C4FE6.30309@citrix.com>
On Fri, Sep 20, 2013 at 02:38:46PM +0100, David Vrabel wrote:
> On 20/09/13 14:34, Wei Liu wrote:
> > On Fri, Sep 20, 2013 at 01:56:31PM +0100, Paul Durrant wrote:
> >> Some old Windows frontends fail to transition through the xenbus Closing
> >> state and move directly from Connected to Closed. Handle this case properly.
> >>
> >> --- a/drivers/net/xen-netback/xenbus.c
> >> +++ b/drivers/net/xen-netback/xenbus.c
> >> @@ -265,6 +265,8 @@ static void frontend_changed(struct xenbus_device *dev,
> >> break;
> >>
> >> case XenbusStateClosed:
> >> + if (dev->state == XenbusStateConnected)
> >> + disconnect_backend(dev);
> >
> > Could you please add a comment above this change stating that this is a
> > workaround for some old frontend that we cannot fix / upgrade.
>
> Handling frontend CONNECTED -> CLOSED is a sensible thing for a backend
> to do regardless of whether there are old frontends that do this or not.
>
I agree handling connected -> closed is sensible here based on the fact
that old frontends could do such state change. However If the state
machine was documented well enough then I think connected -> closed
would not be considered sensible.
This code snippet without comment will cause confusion / encourage wrong
usage of state machine if someone comes here for reference.
> > We would still like to later frontend goes through the normal connected
> > -> closing -> closed path.
>
> This should be documented as a full description of the two state
> machines in public/io/netif.h in Xen. Not scattered about in comments
Sure.
> in a particular backend implementation.
>
The comment in implementation is still worthwhile in case someone comes
here for reference and gets confused.
Wei.
> David
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: Jiri Slaby @ 2013-09-20 13:44 UTC (permalink / raw)
To: Ben Hutchings, akpm, jeffm
Cc: davem, netdev, isdn4linux, isdn, sergei.shtylyov
In-Reply-To: <1379201336.19779.35.camel@deadeye.wl.decadent.org.uk>
On 09/15/2013 01:28 AM, Ben Hutchings wrote:
>> @@ -694,6 +699,10 @@ base_sock_ioctl(struct socket *sock, uns
>> case IMSETDEVNAME: { struct mISDN_devrename dn; + if
>> (!capable(CAP_SYS_ADMIN) && + !gid_eq(misdn_permitted_gid,
>> current_gid()) && + !in_group_p(misdn_permitted_gid)) +
>> return -EPERM; if (copy_from_user(&dn, (void __user *)arg,
>> sizeof(dn))) { err = -EFAULT;
>
> This seems to be the important bit: renaming of devices (if allowed
> at all) ought to be limited to CAP_SYS_ADMIN or possibly
> CAP_NET_ADMIN. But why should the group that is allowed to use
> mISDN data sockets also be allowed to do this?
This is based on an old patch we are dragging in SUSE since 2009:
http://www.isdn4linux.de/pipermail/isdn4linux/2009-December/004493.html
https://bugzilla.novell.com/show_bug.cgi?id=564423
The whole point of the gid-based access was to still allow some user
group to manipulate the device in an arbitrary way.
So if everybody agrees I will just disallow rename to
non-CAP_NET_ADMIN users and we are done?
thanks,
--
js
suse labs
^ permalink raw reply
* RE: [PATCH net-next 2/2] xen-netback: handle frontends that fail to transition through Closing
From: Paul Durrant @ 2013-09-20 13:40 UTC (permalink / raw)
To: David Vrabel, Wei Liu
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org, Ian Campbell
In-Reply-To: <523C4FE6.30309@citrix.com>
> -----Original Message-----
> From: David Vrabel
> Sent: 20 September 2013 14:39
> To: Wei Liu
> Cc: Paul Durrant; netdev@vger.kernel.org; xen-devel@lists.xen.org; Ian
> Campbell
> Subject: Re: [PATCH net-next 2/2] xen-netback: handle frontends that fail to
> transition through Closing
>
> On 20/09/13 14:34, Wei Liu wrote:
> > On Fri, Sep 20, 2013 at 01:56:31PM +0100, Paul Durrant wrote:
> >> Some old Windows frontends fail to transition through the xenbus Closing
> >> state and move directly from Connected to Closed. Handle this case
> properly.
> >>
> >> --- a/drivers/net/xen-netback/xenbus.c
> >> +++ b/drivers/net/xen-netback/xenbus.c
> >> @@ -265,6 +265,8 @@ static void frontend_changed(struct
> xenbus_device *dev,
> >> break;
> >>
> >> case XenbusStateClosed:
> >> + if (dev->state == XenbusStateConnected)
> >> + disconnect_backend(dev);
> >
> > Could you please add a comment above this change stating that this is a
> > workaround for some old frontend that we cannot fix / upgrade.
>
> Handling frontend CONNECTED -> CLOSED is a sensible thing for a backend
> to do regardless of whether there are old frontends that do this or not.
>
Agreed, but probably still worth the comment in case someone gets the wrong idea.
Paul
> > We would still like to later frontend goes through the normal connected
> > -> closing -> closed path.
>
> This should be documented as a full description of the two state
> machines in public/io/netif.h in Xen. Not scattered about in comments
> in a particular backend implementation.
>
> David
^ permalink raw reply
* Re: [PATCH net-next 2/2] xen-netback: handle frontends that fail to transition through Closing
From: David Vrabel @ 2013-09-20 13:38 UTC (permalink / raw)
To: Wei Liu; +Cc: Paul Durrant, netdev, xen-devel, Ian Campbell
In-Reply-To: <20130920133448.GC457@zion.uk.xensource.com>
On 20/09/13 14:34, Wei Liu wrote:
> On Fri, Sep 20, 2013 at 01:56:31PM +0100, Paul Durrant wrote:
>> Some old Windows frontends fail to transition through the xenbus Closing
>> state and move directly from Connected to Closed. Handle this case properly.
>>
>> --- a/drivers/net/xen-netback/xenbus.c
>> +++ b/drivers/net/xen-netback/xenbus.c
>> @@ -265,6 +265,8 @@ static void frontend_changed(struct xenbus_device *dev,
>> break;
>>
>> case XenbusStateClosed:
>> + if (dev->state == XenbusStateConnected)
>> + disconnect_backend(dev);
>
> Could you please add a comment above this change stating that this is a
> workaround for some old frontend that we cannot fix / upgrade.
Handling frontend CONNECTED -> CLOSED is a sensible thing for a backend
to do regardless of whether there are old frontends that do this or not.
> We would still like to later frontend goes through the normal connected
> -> closing -> closed path.
This should be documented as a full description of the two state
machines in public/io/netif.h in Xen. Not scattered about in comments
in a particular backend implementation.
David
^ permalink raw reply
* RE: [PATCH net-next 2/2] xen-netback: handle frontends that fail to transition through Closing
From: Paul Durrant @ 2013-09-20 13:38 UTC (permalink / raw)
To: Wei Liu
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org, David Vrabel,
Wei Liu, Ian Campbell
In-Reply-To: <20130920133448.GC457@zion.uk.xensource.com>
> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: 20 September 2013 14:35
> To: Paul Durrant
> Cc: netdev@vger.kernel.org; xen-devel@lists.xen.org; David Vrabel; Wei Liu;
> Ian Campbell
> Subject: Re: [PATCH net-next 2/2] xen-netback: handle frontends that fail to
> transition through Closing
>
> On Fri, Sep 20, 2013 at 01:56:31PM +0100, Paul Durrant wrote:
> > Some old Windows frontends fail to transition through the xenbus Closing
> > state and move directly from Connected to Closed. Handle this case
> properly.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Cc: David Vrabel <david.vrabel@citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > ---
> > drivers/net/xen-netback/xenbus.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-
> netback/xenbus.c
> > index a53782e..bcaa25b 100644
> > --- a/drivers/net/xen-netback/xenbus.c
> > +++ b/drivers/net/xen-netback/xenbus.c
> > @@ -265,6 +265,8 @@ static void frontend_changed(struct xenbus_device
> *dev,
> > break;
> >
> > case XenbusStateClosed:
> > + if (dev->state == XenbusStateConnected)
> > + disconnect_backend(dev);
>
> Could you please add a comment above this change stating that this is a
> workaround for some old frontend that we cannot fix / upgrade.
>
> We would still like to later frontend goes through the normal connected
> -> closing -> closed path.
>
Sure. I'll re-post the series with that change.
Paul
^ permalink raw reply
* Re: [PATCH net-next 2/2] xen-netback: handle frontends that fail to transition through Closing
From: Wei Liu @ 2013-09-20 13:34 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, xen-devel, David Vrabel, Wei Liu, Ian Campbell
In-Reply-To: <1379681791-21842-3-git-send-email-paul.durrant@citrix.com>
On Fri, Sep 20, 2013 at 01:56:31PM +0100, Paul Durrant wrote:
> Some old Windows frontends fail to transition through the xenbus Closing
> state and move directly from Connected to Closed. Handle this case properly.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
> drivers/net/xen-netback/xenbus.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index a53782e..bcaa25b 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -265,6 +265,8 @@ static void frontend_changed(struct xenbus_device *dev,
> break;
>
> case XenbusStateClosed:
> + if (dev->state == XenbusStateConnected)
> + disconnect_backend(dev);
Could you please add a comment above this change stating that this is a
workaround for some old frontend that we cannot fix / upgrade.
We would still like to later frontend goes through the normal connected
-> closing -> closed path.
Wei.
> xenbus_switch_state(dev, XenbusStateClosed);
> if (xenbus_dev_is_online(dev))
> break;
> --
> 1.7.10.4
^ permalink raw reply
* Re: [PATCH net-next 1/2] xen-netback: add a vif-is-connected flag
From: Wei Liu @ 2013-09-20 13:31 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, xen-devel, David Vrabel, Wei Liu, Ian Campbell
In-Reply-To: <1379681791-21842-2-git-send-email-paul.durrant@citrix.com>
On Fri, Sep 20, 2013 at 01:56:30PM +0100, Paul Durrant wrote:
> Having applied my patch to separate vif disconnect and free, I ran into a
> BUG when testing resume from S3 with a Windows frontend because the vif task
> pointer was not cleared by xenvif_disconnect() and so a double call to this
> function tries to stop the thread twice.
> Rather than applying a point fix for that issue it seems better to introduce
> a boolean to indicate whether the vif is connected or not such that repeated
> calls to either xenvif_connect() or xenvif_disconnect() behave appropriately.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
Reasonable change.
Acked-by: Wei Liu <wei.liu2@citrix.com>
Thanks
Wei.
> ---
> drivers/net/xen-netback/common.h | 1 +
> drivers/net/xen-netback/interface.c | 24 +++++++++++++-----------
> 2 files changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index 5715318..860d92c 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -169,6 +169,7 @@ struct xenvif {
>
> /* Miscellaneous private stuff. */
> struct net_device *dev;
> + bool connected;
> };
>
> static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 01bb854..94b47f5 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -366,7 +366,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
> int err = -ENOMEM;
>
> /* Already connected through? */
> - if (vif->tx_irq)
> + if (vif->connected)
> return 0;
>
> err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
> @@ -425,6 +425,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
>
> wake_up_process(vif->task);
>
> + vif->connected = 1;
> return 0;
>
> err_rx_unbind:
> @@ -453,23 +454,24 @@ void xenvif_carrier_off(struct xenvif *vif)
>
> void xenvif_disconnect(struct xenvif *vif)
> {
> + if (!vif->connected)
> + return;
> +
> if (netif_carrier_ok(vif->dev))
> xenvif_carrier_off(vif);
>
> - if (vif->tx_irq) {
> - if (vif->tx_irq == vif->rx_irq)
> - unbind_from_irqhandler(vif->tx_irq, vif);
> - else {
> - unbind_from_irqhandler(vif->tx_irq, vif);
> - unbind_from_irqhandler(vif->rx_irq, vif);
> - }
> - vif->tx_irq = 0;
> + if (vif->tx_irq == vif->rx_irq)
> + unbind_from_irqhandler(vif->tx_irq, vif);
> + else {
> + unbind_from_irqhandler(vif->tx_irq, vif);
> + unbind_from_irqhandler(vif->rx_irq, vif);
> }
>
> - if (vif->task)
> - kthread_stop(vif->task);
> + kthread_stop(vif->task);
>
> xenvif_unmap_frontend_rings(vif);
> +
> + vif->connected = 0;
> }
>
> void xenvif_free(struct xenvif *vif)
> --
> 1.7.10.4
^ permalink raw reply
* IPv6 kernel warning
From: Russell King - ARM Linux @ 2013-09-20 13:11 UTC (permalink / raw)
To: netdev
While running v3.11 on my firewall, I saw this warning. I'm not sure
what it means or what its implications are:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at /home/rmk/git/linux-rmk/net/ipv4/tcp_input.c:2711 tcp_fastretrans_alert+0x178/0x840()
Modules linked in: ipt_REJECT xt_multiport iptable_filter ipt_MASQUERADE xt_nat
xt_mark iptable_nat nf_nat_ipv4 nf_nat ip6table_mangle xt_LOG xt_limit nf_conntrack_ipv6 nf_defrag_ipv6 xt_state ip6table_filter pata_pcmcia libata scsi_mod 3c589_cs ide_gd_mod ide_cs ide_core sa1111_cs sa1100_cs sa11xx_base soc_common sa11x0_dma virt_dma usbcore usb_common
CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0+ #15
Backtrace:
[<c02111a8>] (dump_backtrace+0x0/0x114) from [<c02115a0>] (show_stack+0x18/0x1c) r6:c0520824 r5:00000009 r4:00000000
[<c0211588>] (show_stack+0x0/0x1c) from [<c04d65e0>] (dump_stack+0x20/0x28)
[<c04d65c0>] (dump_stack+0x0/0x28) from [<c021bfb0>] (warn_slowpath_common+0x68/0x88)
[<c021bf48>] (warn_slowpath_common+0x0/0x88) from [<c021bff4>] (warn_slowpath_null+0x24/0x28)
r8:00000000 r7:00000001 r6:00000006 r5:00004320 r4:c11c6580
[<c021bfd0>] (warn_slowpath_null+0x0/0x28) from [<c04515bc>] (tcp_fastretrans_alert+0x178/0x840)
[<c0451444>] (tcp_fastretrans_alert+0x0/0x840) from [<c045273c>] (tcp_ack+0xa14/0xc18)
[<c0451d28>] (tcp_ack+0x0/0xc18) from [<c0453138>] (tcp_rcv_established+0x494/0x594)
[<c0452ca4>] (tcp_rcv_established+0x0/0x594) from [<c04a977c>] (tcp_v6_do_rcv+0xd0/0x428)
[<c04a96ac>] (tcp_v6_do_rcv+0x0/0x428) from [<c04a9e70>] (tcp_v6_rcv+0x340/0x63c)
[<c04a9b30>] (tcp_v6_rcv+0x0/0x63c) from [<c048b334>] (ip6_input_finish+0x214/0x3c4)
[<c048b120>] (ip6_input_finish+0x0/0x3c4) from [<c048ba60>] (ip6_input+0x64/0x74)
[<c048b9fc>] (ip6_input+0x0/0x74) from [<c048b564>] (ip6_rcv_finish+0x80/0x8c)
r4:c1c9ee20
[<c048b4e4>] (ip6_rcv_finish+0x0/0x8c) from [<c048b994>] (ipv6_rcv+0x424/0x48c)
r4:c1c9ee20
[<c048b570>] (ipv6_rcv+0x0/0x48c) from [<c0407624>] (__netif_receive_skb_core+0x618/0x688)
r8:0000dd86 r7:00000000 r6:c11f6800 r5:c05ee6cc r4:c05f1b98
[<c040700c>] (__netif_receive_skb_core+0x0/0x688) from [<c040770c>] (__netif_receive_skb+0x78/0x80)
[<c0407694>] (__netif_receive_skb+0x0/0x80) from [<c04077a8>] (process_backlog+0x94/0x14c)
r5:c06091e0 r4:c0609220
[<c0407714>] (process_backlog+0x0/0x14c) from [<c0407af4>] (net_rx_action+0x78/0x1ac)
[<c0407a7c>] (net_rx_action+0x0/0x1ac) from [<c021f500>] (__do_softirq+0xb4/0x198)
[<c021f44c>] (__do_softirq+0x0/0x198) from [<c021f90c>] (irq_exit+0x74/0xc8)
[<c021f898>] (irq_exit+0x0/0xc8) from [<c020f1ac>] (handle_IRQ+0x68/0x88)
r4:0000000b
[<c020f144>] (handle_IRQ+0x0/0x88) from [<c0208210>] (asm_do_IRQ+0x10/0x14)
r5:60000013 r4:c0246818
[<c0208200>] (asm_do_IRQ+0x0/0x14) from [<c0211fcc>] (__irq_svc+0x2c/0x98)
Exception stack(0xc05e7f54 to 0xc05e7f9c)
7f40: 00000000 00000000 00000000
7f60: 60000013 c05e6000 c06092a4 c05ee080 00000001 c0204000 6901b115 c05e0800
7f80: c05e7fb8 c05e7f9c c05e7f9c c020f348 c0246818 60000013 ffffffff
[<c0246794>] (cpu_startup_entry+0x0/0xe8) from [<c04d4d70>] (rest_init+0x64/0x7c)
r7:c05f3940 r6:c0922200 r5:c0609340 r4:c05ee0c0
[<c04d4d0c>] (rest_init+0x0/0x7c) from [<c05c3acc>] (start_kernel+0x350/0x3ac)
[<c05c377c>] (start_kernel+0x0/0x3ac) from [<c0208040>] (0xc0208040)
---[ end trace ab55f0e3f592fa5e ]---
^ permalink raw reply
* Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
From: Felipe Balbi @ 2013-09-20 13:11 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Felipe Balbi, linux-crypto,
Greg Kroah-Hartman, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <E1VMnQk-0007sX-Ty@rmk-PC.arm.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 731 bytes --]
Hi,
On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> Use platform_device_register_full() for those drivers which can, to
> avoid messing directly with DMA masks. This can only be done when
> the driver does not need to access the allocated musb platform device
> from within its callbacks, which may be called during the musb
> device probing.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
you want me to carry this one through my tree or you prefer getting my
Acked-by ? Either way works for me:
Acked-by: Felipe Balbi <balbi@ti.com>
there's also the third option of me setting up a branch with only this
patch and we both merge it, that'd also work.
cheers
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()
From: Felipe Balbi @ 2013-09-20 13:10 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, Alexander Shishkin, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, linux-scsi,
e1000-devel, Alan Stern, b43-dev, linux-media, devicetree,
Stephen Warren, Kukjin Kim, dri-devel, linux-tegra, linux-omap,
linux-arm-kernel, Solarflare linux maintainers, netdev, linux-usb,
linux-wireless, Felipe Balbi, linux-crypto
In-Reply-To: <E1VMmIV-0007jw-Gq@rmk-PC.arm.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1432 bytes --]
Hi,
On Thu, Sep 19, 2013 at 11:02:03PM +0100, Russell King wrote:
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index c10b324..8b20c70 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -119,9 +119,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
> * Since shared usb code relies on it, set it here for now.
> * Once we move to full device tree support this will vanish off.
> */
> - if (!dev->dma_mask)
> - dev->dma_mask = &dev->coherent_dma_mask;
> - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
> if (ret)
> goto err1;
>
> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
> index d0759c5..6fa82d6 100644
> --- a/drivers/usb/host/ehci-omap.c
> +++ b/drivers/usb/host/ehci-omap.c
> @@ -144,9 +144,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
> * Since shared usb code relies on it, set it here for now.
> * Once we have dma capability bindings this can go away.
> */
> - if (!dev->dma_mask)
> - dev->dma_mask = &dev->coherent_dma_mask;
> - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
> if (ret)
> return ret;
for dwc3 and ehci-omap:
Acked-by: Felipe Balbi <balbi@ti.com>
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
From: Felipe Balbi @ 2013-09-20 13:08 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, Alexander Shishkin, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, linux-scsi,
e1000-devel, Alan Stern, b43-dev, linux-media, devicetree,
Stephen Warren, Kukjin Kim, dri-devel, linux-tegra, linux-omap,
linux-arm-kernel, Solarflare linux maintainers, netdev, linux-usb,
linux-wireless, Felipe Balbi, linux-crypto
In-Reply-To: <E1VMmHX-0007jq-Cj@rmk-PC.arm.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1358 bytes --]
Hi,
On Thu, Sep 19, 2013 at 11:01:03PM +0100, Russell King wrote:
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index 2f2e88a..c10b324 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -121,8 +121,9 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
> */
> if (!dev->dma_mask)
> dev->dma_mask = &dev->coherent_dma_mask;
> - if (!dev->coherent_dma_mask)
> - dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> + if (ret)
> + goto err1;
>
> platform_set_drvdata(pdev, exynos);
>
> diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx_udc.c
> index 67128be..6a2a65a 100644
> --- a/drivers/usb/gadget/lpc32xx_udc.c
> +++ b/drivers/usb/gadget/lpc32xx_udc.c
> @@ -3078,7 +3078,9 @@ static int __init lpc32xx_udc_probe(struct platform_device *pdev)
> udc->isp1301_i2c_client->addr);
>
> pdev->dev.dma_mask = &lpc32xx_usbd_dmamask;
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + if (retval)
> + goto resource_fail;
>
> udc->board = &lpc32xx_usbddata;
>
for dwc3 and drivers/usb/gadget:
Acked-by: Felipe Balbi <balbi@ti.com>
pretty cool work :-)
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next 2/2] xen-netback: handle frontends that fail to transition through Closing
From: Paul Durrant @ 2013-09-20 12:56 UTC (permalink / raw)
To: netdev, xen-devel; +Cc: Paul Durrant, David Vrabel, Wei Liu, Ian Campbell
In-Reply-To: <1379681791-21842-1-git-send-email-paul.durrant@citrix.com>
Some old Windows frontends fail to transition through the xenbus Closing
state and move directly from Connected to Closed. Handle this case properly.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
drivers/net/xen-netback/xenbus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index a53782e..bcaa25b 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -265,6 +265,8 @@ static void frontend_changed(struct xenbus_device *dev,
break;
case XenbusStateClosed:
+ if (dev->state == XenbusStateConnected)
+ disconnect_backend(dev);
xenbus_switch_state(dev, XenbusStateClosed);
if (xenbus_dev_is_online(dev))
break;
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next 1/2] xen-netback: add a vif-is-connected flag
From: Paul Durrant @ 2013-09-20 12:56 UTC (permalink / raw)
To: netdev, xen-devel; +Cc: Paul Durrant, David Vrabel, Wei Liu, Ian Campbell
In-Reply-To: <1379681791-21842-1-git-send-email-paul.durrant@citrix.com>
Having applied my patch to separate vif disconnect and free, I ran into a
BUG when testing resume from S3 with a Windows frontend because the vif task
pointer was not cleared by xenvif_disconnect() and so a double call to this
function tries to stop the thread twice.
Rather than applying a point fix for that issue it seems better to introduce
a boolean to indicate whether the vif is connected or not such that repeated
calls to either xenvif_connect() or xenvif_disconnect() behave appropriately.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
drivers/net/xen-netback/common.h | 1 +
drivers/net/xen-netback/interface.c | 24 +++++++++++++-----------
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 5715318..860d92c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -169,6 +169,7 @@ struct xenvif {
/* Miscellaneous private stuff. */
struct net_device *dev;
+ bool connected;
};
static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 01bb854..94b47f5 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -366,7 +366,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
int err = -ENOMEM;
/* Already connected through? */
- if (vif->tx_irq)
+ if (vif->connected)
return 0;
err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
@@ -425,6 +425,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
wake_up_process(vif->task);
+ vif->connected = 1;
return 0;
err_rx_unbind:
@@ -453,23 +454,24 @@ void xenvif_carrier_off(struct xenvif *vif)
void xenvif_disconnect(struct xenvif *vif)
{
+ if (!vif->connected)
+ return;
+
if (netif_carrier_ok(vif->dev))
xenvif_carrier_off(vif);
- if (vif->tx_irq) {
- if (vif->tx_irq == vif->rx_irq)
- unbind_from_irqhandler(vif->tx_irq, vif);
- else {
- unbind_from_irqhandler(vif->tx_irq, vif);
- unbind_from_irqhandler(vif->rx_irq, vif);
- }
- vif->tx_irq = 0;
+ if (vif->tx_irq == vif->rx_irq)
+ unbind_from_irqhandler(vif->tx_irq, vif);
+ else {
+ unbind_from_irqhandler(vif->tx_irq, vif);
+ unbind_from_irqhandler(vif->rx_irq, vif);
}
- if (vif->task)
- kthread_stop(vif->task);
+ kthread_stop(vif->task);
xenvif_unmap_frontend_rings(vif);
+
+ vif->connected = 0;
}
void xenvif_free(struct xenvif *vif)
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next 0/2] xen-netback: windows frontend compatibility fixes
From: Paul Durrant @ 2013-09-20 12:56 UTC (permalink / raw)
To: netdev, xen-devel
The following patches fix a couple more issues found when testing with Windows
frontends.
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Tejun Heo @ 2013-09-20 12:18 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel, Inki Dae, Joonyoung Shim, Seung-Woo Kim, Kyun
In-Reply-To: <20130920121652.GA7630@mtj.dyndns.org>
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code should access this
> > member directly.
> >
> > Convert all direct write accesses to using the correct API.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> The patch is pretty widely spread. I don't mind how it gets routed
> but what's the plan?
Hmm... maybe hte pata_ixp4xx_cf.c part should be moved to the one
which updates pata_octeon_cf.c?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Tejun Heo @ 2013-09-20 12:16 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, David Airlie, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, Joonyoung Shim,
linux-scsi, e1000-devel, Seung-Woo Kim, b43-dev, linux-media,
devicetree, Inki Dae, Kukjin Kim, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Kyungmin Park
In-Reply-To: <E1VMnNq-0007s4-HN@rmk-PC.arm.linux.org.uk>
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> The correct way for a driver to specify the coherent DMA mask is
> not to directly access the field in the struct device, but to use
> dma_set_coherent_mask(). Only arch and bus code should access this
> member directly.
>
> Convert all direct write accesses to using the correct API.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Tejun Heo <tj@kernel.org>
The patch is pretty widely spread. I don't mind how it gets routed
but what's the plan?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v2] ip6tnl: do route updating for redirect in ip6_tnl_err()
From: Duan Jiong @ 2013-09-20 10:43 UTC (permalink / raw)
To: David Miller; +Cc: djduanjiong, netdev
In-Reply-To: <20130919.140213.417316271045370155.davem@davemloft.net>
于 2013年09月20日 02:02, David Miller 写道:
> From: Duan Jiong <djduanjiong@gmail.com>
> Date: Tue, 17 Sep 2013 20:27:57 -0700
>
>> After the ip6_tnl_err() is called, the rel_msg is assigned to
>> 0, and the ip4ip6_err() will return directly, the instruction
>> below will not be executed.
>>
>> In rfc2473, we can know that the tunnel ICMP redirect message
>> should not be reported to the source of the original packet,
>> so we can handle it in ip6_tnl_err().
>>
>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> I do not think this change is correct.
>
>> @@ -576,9 +579,6 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
>> rel_type = ICMP_DEST_UNREACH;
>> rel_code = ICMP_FRAG_NEEDED;
>> break;
>> - case NDISC_REDIRECT:
>> - rel_type = ICMP_REDIRECT;
>> - rel_code = ICMP_REDIR_HOST;
>> default:
>> return 0;
>> }
>
> The bug is a missing "break;" statement for this case, and:
You can read the ip6_tnl_err(). when the message is NDISC_REDIRECT, the
rel_msg is assigned to 0, then
561 if (rel_msg == 0)
562 return 0;
the function ip4ip6_err() return directly. so even though you add "break;"
statement for this case, the redirect message will not be handled.
>
>> @@ -637,8 +637,6 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
>>
>> skb_dst(skb2)->ops->update_pmtu(skb_dst(skb2), NULL, skb2, rel_info);
>> }
>> - if (rel_type == ICMP_REDIRECT)
>> - skb_dst(skb2)->ops->redirect(skb_dst(skb2), NULL, skb2);
>>
>
> We absolutely must run the ipv4 dst_ops redirect handler here so you must
> keep this code around as well.
>
Because the Redirect Message is sent to tunnel entry-point, so the target address in
Redirect ICMPv6 Message is an ipv6 address, then we could not run the ipv4 dst_ops
redirect handler here.
Thanks,
Duan
> The only change you need to make is to add the missing break;
> statement to ip4ip6_err() and then also add appropriate NDISC_REDIRECT
> handling to ip6ip6_err().
^ permalink raw reply
* [PATCH ] net: raw: do not report ICMP redirects to user space
From: Duan Jiong @ 2013-09-20 10:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Redirect isn't an error condition, it should leave
the error handler without touching the socket.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv4/raw.c | 4 +++-
net/ipv6/raw.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index bfec521..193db03 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -218,8 +218,10 @@ static void raw_err(struct sock *sk, struct sk_buff *skb, u32 info)
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED)
ipv4_sk_update_pmtu(skb, sk, info);
- else if (type == ICMP_REDIRECT)
+ else if (type == ICMP_REDIRECT) {
ipv4_sk_redirect(skb, sk);
+ return;
+ }
/* Report error on raw socket, if:
1. User requested ip_recverr.
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 58916bb..a4ed241 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -335,8 +335,10 @@ static void rawv6_err(struct sock *sk, struct sk_buff *skb,
ip6_sk_update_pmtu(skb, sk, info);
harderr = (np->pmtudisc == IPV6_PMTUDISC_DO);
}
- if (type == NDISC_REDIRECT)
+ if (type == NDISC_REDIRECT) {
ip6_sk_redirect(skb, sk);
+ return;
+ }
if (np->recverr) {
u8 *payload = skb->data;
if (!inet->hdrincl)
--
1.8.3.1
^ permalink raw reply related
* [PATCH ] net: udp: do not report ICMP redirects to user space
From: Duan Jiong @ 2013-09-20 10:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Redirect isn't an error condition, it should leave
the error handler without touching the socket.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv4/udp.c | 2 +-
net/ipv6/udp.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 74d2c95..0ca44df 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -658,7 +658,7 @@ void __udp4_lib_err(struct sk_buff *skb, u32 info, struct udp_table *udptable)
break;
case ICMP_REDIRECT:
ipv4_sk_redirect(skb, sk);
- break;
+ goto out;
}
/*
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index f405815..72b7eaa 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -525,8 +525,10 @@ void __udp6_lib_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
if (type == ICMPV6_PKT_TOOBIG)
ip6_sk_update_pmtu(skb, sk, info);
- if (type == NDISC_REDIRECT)
+ if (type == NDISC_REDIRECT) {
ip6_sk_redirect(skb, sk);
+ goto out;
+ }
np = inet6_sk(sk);
--
1.8.3.1
^ permalink raw reply related
* Re: [GIT PULL 0/5] IPVS fixes for v3.12
From: Pablo Neira Ayuso @ 2013-09-20 10:07 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
In-Reply-To: <1379533542-9891-1-git-send-email-horms@verge.net.au>
On Wed, Sep 18, 2013 at 02:45:37PM -0500, Simon Horman wrote:
> please consider the following fixes for IPVS for v3.12.
>
> The following changes since commit 61c5923a2f2d8ab98a1e3c76f17e0f4a871ec75b:
>
> Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf (2013-09-17 20:22:53 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs.git tags/ipvs-fixes-for-v3.12
Pulled, thanks Simon.
^ permalink raw reply
* RE: [PATCH net-next v4] Don't destroy the netdev until the vif is shut down
From: Paul Durrant @ 2013-09-20 8:10 UTC (permalink / raw)
To: David Miller
Cc: xen-devel@lists.xen.org, netdev@vger.kernel.org, David Vrabel,
Wei Liu, Ian Campbell
In-Reply-To: <20130919.140513.2047786411565716987.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: 19 September 2013 19:05
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; David Vrabel; Wei Liu;
> Ian Campbell
> Subject: Re: [PATCH net-next v4] Don't destroy the netdev until the vif is
> shut down
>
> From: Paul Durrant <paul.durrant@citrix.com>
> Date: Tue, 17 Sep 2013 17:46:08 +0100
>
> > Without this patch, if a frontend cycles through states Closing
> > and Closed (which Windows frontends need to do) then the netdev
> > will be destroyed and requires re-invocation of hotplug scripts
> > to restore state before the frontend can move to Connected. Thus
> > when udev is not in use the backend gets stuck in InitWait.
> >
> > With this patch, the netdev is left alone whilst the backend is
> > still online and is only de-registered and freed just prior to
> > destroying the vif (which is also nicely symmetrical with the
> > netdev allocation and registration being done during probe) so
> > no re-invocation of hotplug scripts is required.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>
> I think all of the testing requests have been satisfied so I have
> applied this.
>
> But _please_ write a more proper subject line in future patch
> submissions. You have to provide a subsystem prefix in the
> subject line, here I added "xen-netback: ", otherwise someone
> skimming the shortlog has no idea what area of code this change
> touches.
>
Ok. Will do. Thanks,
Paul
^ permalink raw reply
* Re: [PATCH 1/2] remove all uses of printf's %n
From: Jiri Slaby @ 2013-09-20 8:08 UTC (permalink / raw)
To: Tetsuo Handa, viro, xemul, remi.denis-courmont
Cc: keescook, linux-kernel, netdev, linux-sctp, linux, akpm,
dan.carpenter, geert, JBeulich, joe, kosaki.motohiro
In-Reply-To: <201309201309.GFB52620.OQOtSFLMJVHOFF@I-love.SAKURA.ne.jp>
On 09/20/2013 06:09 AM, Tetsuo Handa wrote:
> --- a/fs/proc/consoles.c
> +++ b/fs/proc/consoles.c
...
> @@ -47,11 +46,10 @@ static int show_console_dev(struct seq_file *m, void *v)
> con_flags[a].name : ' ';
> flags[a] = 0;
>
> - seq_printf(m, "%s%d%n", con->name, con->index, &len);
> - len = 21 - len;
> - if (len < 1)
> - len = 1;
> - seq_printf(m, "%*c%c%c%c (%s)", len, ' ', con->read ? 'R' : '-',
> + seq_setwidth(m, 21 - 1);
> + seq_printf(m, "%s%d", con->name, con->index);
> + seq_pad(m, ' ');
> + seq_printf(m, "%c%c%c (%s)", con->read ? 'R' : '-',
> con->write ? 'W' : '-', con->unblank ? 'U' : '-',
> flags);
Hello, do you really need seq_setwidth? It makes it really ugly...
Or do we need that all? Couldn't we simply have seq_printf_padded? Or
maybe some % modifier in seq_printf to pad the string?
> --- a/net/ipv4/fib_trie.c
> +++ b/net/ipv4/fib_trie.c
...
> @@ -2548,15 +2549,15 @@ static int fib_route_seq_show(struct seq_file *seq, void *v)
> (fi->fib_advmss ?
> fi->fib_advmss + 40 : 0),
> fi->fib_window,
> - fi->fib_rtt >> 3, &len);
> + fi->fib_rtt >> 3);
> else
> seq_printf(seq,
> "*\t%08X\t%08X\t%04X\t%d\t%u\t"
> - "%d\t%08X\t%d\t%u\t%u%n",
> + "%d\t%08X\t%d\t%u\t%u",
> prefix, 0, flags, 0, 0, 0,
> - mask, 0, 0, 0, &len);
> + mask, 0, 0, 0);
>
> - seq_printf(seq, "%*s\n", 127 - len, "");
> + seq_pad(seq, '\n');
Hmm, seq_pad is unintuitive. I would say it pads the string by '\n'. Of
course it does not, but...
thanks,
--
js
suse labs
^ 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