Netdev List
 help / color / mirror / Atom feed
* Vital Information
From: Google Registered Office @ 2012-11-01  5:51 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 119 bytes --]



Dear Google User,
See attached document for details on Google winning Reward.

Heiko Thaemlitz
Google Representative

[-- Attachment #2: Google  Reward..doc --]
[-- Type: application/msword, Size: 94720 bytes --]

^ permalink raw reply

* linux-next: manual merge of the drop-experimental tree with the net-next tree
From: Stephen Rothwell @ 2012-11-02  4:55 UTC (permalink / raw)
  To: Kees Cook; +Cc: linux-next, linux-kernel, Ben Hutchings, David Miller, netdev

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

Hi Kees,

Today's linux-next merge of the drop-experimental tree got a conflict in
drivers/net/ethernet/intel/Kconfig between commit a24006ed1261 ("ptp:
Enable clock drivers along with associated net/PHY drivers") from the
net-next tree and commit 70c5056f413d ("drivers/net/ethernet/intel:
remove depends on CONFIG_EXPERIMENTAL") from the drop-experimental tree.

The former removed some code that was changed by the latter, so I did
that and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: switching network namespace midway
From: Eric W. Biederman @ 2012-11-02  6:18 UTC (permalink / raw)
  To: Benjamin LaHaise; +Cc: rsa, netdev
In-Reply-To: <20121102022542.GD18091@kvack.org>

Benjamin LaHaise <bcrl@kvack.org> writes:

> On Thu, Oct 25, 2012 at 09:15:34AM -0700, Eric W. Biederman wrote:
>> > I've read IPv4 gre code, and it appears to do the right thing on rx, but it 
>> > does *not* appear to handle namespaces correctly on transmit.  In general, 
>> > I would expect pretty much all code to get namespace handling correct for 
>> > the rx case.  I'll have a closer look at fixing this tomorrow if nobody else 
>> > beats me to it.
>> 
>> It will be interesting to see what you come up with. 
>
> Well, I finally had some time to work on the ip_gre module a bit today, 
> and here's what I came up with.  The basic idea is to store the network 
> namespace in the ip_tunnel structure at creation time for use in sending 
> and receiving packets, allowing the gre network device to be safely moved 
> into another network namespace.  This works for me in moving a gre tunnel 
> into an lxc container, and survives module unload and namespace 
> destruction.  I'll try to spend a bit more time adding similar support to 
> the other ip_tunnel devices over the next few days.  Comments/thoughts?
>
> 		-ben

You need a per network namespace exit function to delete the tunnel when
the xmit direction goes away.  Otherwise we have a very nasty race if
the original network namespace exits.

NETNS_LOCAL may make sense on the reference device that is used to
support ioctls for creating devices.

ipgre_open ?  It looks like it needs to be handled.  Probably that
ip_route_output_gre needs to be moved.

ipv6?

Eric

> -- 
> "Thought is the essence of where you are now."
> 
> 
> diff --git a/include/net/ipip.h b/include/net/ipip.h
> index ddc077c..9cfba92 100644
> --- a/include/net/ipip.h
> +++ b/include/net/ipip.h
> @@ -19,6 +19,7 @@ struct ip_tunnel_6rd_parm {
>  struct ip_tunnel {
>  	struct ip_tunnel __rcu	*next;
>  	struct net_device	*dev;
> +	struct net		*net;		/* Namespace for packet i/o */
>  
>  	int			err_count;	/* Number of arrived ICMP errors */
>  	unsigned long		err_time;	/* Time when the last ICMP error arrived */
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 7240f8e..705dc66 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -461,6 +461,7 @@ static struct ip_tunnel *ipgre_tunnel_locate(struct net *net,
>  	dev_net_set(dev, net);
>  
>  	nt = netdev_priv(dev);
> +	nt->net = net;
>  	nt->parms = *parms;
>  	dev->rtnl_link_ops = &ipgre_link_ops;
>  
> @@ -484,8 +485,10 @@ failed_free:
>  
>  static void ipgre_tunnel_uninit(struct net_device *dev)
>  {
> -	struct net *net = dev_net(dev);
> -	struct ipgre_net *ign = net_generic(net, ipgre_net_id);
> +	struct ip_tunnel *tunnel = netdev_priv(dev);
> +	struct ipgre_net *ign;
> +
> +	ign = net_generic(tunnel->net, ipgre_net_id);
>  
>  	ipgre_tunnel_unlink(ign, netdev_priv(dev));
>  	dev_put(dev);
> @@ -837,7 +840,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
>  			tos = ipv6_get_dsfield((const struct ipv6hdr *)old_iph);
>  	}
>  
> -	rt = ip_route_output_gre(dev_net(dev), &fl4, dst, tiph->saddr,
> +	rt = ip_route_output_gre(tunnel->net, &fl4, dst, tiph->saddr,
>  				 tunnel->parms.o_key, RT_TOS(tos),
>  				 tunnel->parms.link);
>  	if (IS_ERR(rt)) {
> @@ -1010,7 +1013,7 @@ static int ipgre_tunnel_bind_dev(struct net_device *dev)
>  		struct flowi4 fl4;
>  		struct rtable *rt;
>  
> -		rt = ip_route_output_gre(dev_net(dev), &fl4,
> +		rt = ip_route_output_gre(tunnel->net, &fl4,
>  					 iph->daddr, iph->saddr,
>  					 tunnel->parms.o_key,
>  					 RT_TOS(iph->tos),
> @@ -1341,7 +1344,6 @@ static void ipgre_tunnel_setup(struct net_device *dev)
>  	dev->flags		= IFF_NOARP;
>  	dev->iflink		= 0;
>  	dev->addr_len		= 4;
> -	dev->features		|= NETIF_F_NETNS_LOCAL;
>  	dev->priv_flags		&= ~IFF_XMIT_DST_RELEASE;
>  
>  	dev->features		|= GRE_FEATURES;
> @@ -1432,6 +1434,7 @@ static void ipgre_destroy_tunnels(struct ipgre_net *ign, struct list_head *head)
>  static int __net_init ipgre_init_net(struct net *net)
>  {
>  	struct ipgre_net *ign = net_generic(net, ipgre_net_id);
> +	struct ip_tunnel *tunnel;
>  	int err;
>  
>  	ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip_tunnel), "gre0",
> @@ -1445,6 +1448,9 @@ static int __net_init ipgre_init_net(struct net *net)
>  	ipgre_fb_tunnel_init(ign->fb_tunnel_dev);
>  	ign->fb_tunnel_dev->rtnl_link_ops = &ipgre_link_ops;
>  
> +	tunnel = netdev_priv(ign->fb_tunnel_dev);
> +	tunnel->net = net;
> +
>  	if ((err = register_netdev(ign->fb_tunnel_dev)))
>  		goto err_reg_dev;
>  

^ permalink raw reply

* Re: [v6 PATCH 0/8] csiostor: Chelsio FCoE offload driver submission
From: Naresh Kumar Inna @ 2012-11-02  7:23 UTC (permalink / raw)
  To: JBottomley@parallels.com
  Cc: Naresh Kumar Inna, linux-scsi@vger.kernel.org,
	Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
	Chethan Seshadri
In-Reply-To: <1351158621-32222-1-git-send-email-naresh@chelsio.com>

Hi James,

Could you please let me know where we are with the review of this driver?

Thanks,
Naresh.

On 10/25/2012 3:20 PM, Naresh Kumar Inna wrote:
> This is the initial submission of the Chelsio FCoE offload driver (csiostor)
> to the upstream kernel. This driver currently supports FCoE offload
> functionality over Chelsio T4-based 10Gb Converged Network Adapters.
> 
> The following patches contain the driver sources for csiostor driver and
> updates to firmware/hardware header files shared between csiostor,
> cxgb4 (Chelsio T4-based NIC driver) and cxgb4vf (Chelsio T4-based Virtual
> Function NIC driver). The csiostor driver is dependent on these
> header updates. These patches have been generated against scsi 'misc' branch.
> 
> csiostor is a low level SCSI driver that interfaces with PCI, SCSI midlayer and
> FC transport subsystems. This driver claims the FCoE PCIe function on
> Chelsio Converged Network Adapters. It relies on firmware events for slow path
> operations like discovery, thereby offloading session management. The driver
> programs firmware via Work Request interfaces for fast path I/O offload
> features.
> 
> v6 has changes to make csiostor work with cxgb4 header files post 3.6 merge, as
> well as a few bug fixes in csiostor.
> 
> Here is the brief description of patches:
> [v6 PATCH 1/8]: Updates to header files shared between cxgb4, cxgb4vf and
>                 csiostor.
> [v6 PATCH 2/8]: Header files part 1.
> [v6 PATCH 3/8]: Header files part 2.
> [v6 PATCH 4/8]: Driver initialization and Work Request services.
> [v6 PATCH 5/8]: FC transport interfaces and mailbox services.
> [v6 PATCH 6/8]: Local and remote port state tracking functionality.
> [v6 PATCH 7/8]: Interrupt handling and fast path I/O functionality.
> [v6 PATCH 8/8]: Hardware interface, Makefile and Kconfig changes.
> 
> Naresh Kumar Inna (8):
>   cxgb4/cxgb4vf: Chelsio FCoE offload driver submission (common header
>     updates).
>   csiostor: Chelsio FCoE offload driver submission (headers part 1).
>   csiostor: Chelsio FCoE offload driver submission (headers part 2).
>   csiostor: Chelsio FCoE offload driver submission (sources part 1).
>   csiostor: Chelsio FCoE offload driver submission (sources part 2).
>   csiostor: Chelsio FCoE offload driver submission (sources part 3).
>   csiostor: Chelsio FCoE offload driver submission (sources part 4).
>   csiostor: Chelsio FCoE offload driver submission (sources part 5).
> 
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c |    8 +-
>  drivers/net/ethernet/chelsio/cxgb4/sge.c        |    6 +-
>  drivers/net/ethernet/chelsio/cxgb4/t4_hw.c      |   20 +-
>  drivers/net/ethernet/chelsio/cxgb4/t4_msg.h     |    1 +
>  drivers/net/ethernet/chelsio/cxgb4/t4_regs.h    |   36 +-
>  drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h   |   41 +-
>  drivers/net/ethernet/chelsio/cxgb4vf/sge.c      |    8 +-
>  drivers/scsi/Kconfig                            |    1 +
>  drivers/scsi/Makefile                           |    1 +
>  drivers/scsi/csiostor/Kconfig                   |   19 +
>  drivers/scsi/csiostor/Makefile                  |   11 +
>  drivers/scsi/csiostor/csio_attr.c               |  796 ++++
>  drivers/scsi/csiostor/csio_defs.h               |  121 +
>  drivers/scsi/csiostor/csio_hw.c                 | 4395 +++++++++++++++++++++++
>  drivers/scsi/csiostor/csio_hw.h                 |  667 ++++
>  drivers/scsi/csiostor/csio_init.c               | 1274 +++++++
>  drivers/scsi/csiostor/csio_init.h               |  158 +
>  drivers/scsi/csiostor/csio_isr.c                |  624 ++++
>  drivers/scsi/csiostor/csio_lnode.c              | 2133 +++++++++++
>  drivers/scsi/csiostor/csio_lnode.h              |  255 ++
>  drivers/scsi/csiostor/csio_mb.c                 | 1770 +++++++++
>  drivers/scsi/csiostor/csio_mb.h                 |  278 ++
>  drivers/scsi/csiostor/csio_rnode.c              |  912 +++++
>  drivers/scsi/csiostor/csio_rnode.h              |  141 +
>  drivers/scsi/csiostor/csio_scsi.c               | 2555 +++++++++++++
>  drivers/scsi/csiostor/csio_scsi.h               |  342 ++
>  drivers/scsi/csiostor/csio_wr.c                 | 1632 +++++++++
>  drivers/scsi/csiostor/csio_wr.h                 |  512 +++
>  drivers/scsi/csiostor/t4fw_api_stor.h           |  578 +++
>  29 files changed, 19267 insertions(+), 28 deletions(-)
>  create mode 100644 drivers/scsi/csiostor/Kconfig
>  create mode 100644 drivers/scsi/csiostor/Makefile
>  create mode 100644 drivers/scsi/csiostor/csio_attr.c
>  create mode 100644 drivers/scsi/csiostor/csio_defs.h
>  create mode 100644 drivers/scsi/csiostor/csio_hw.c
>  create mode 100644 drivers/scsi/csiostor/csio_hw.h
>  create mode 100644 drivers/scsi/csiostor/csio_init.c
>  create mode 100644 drivers/scsi/csiostor/csio_init.h
>  create mode 100644 drivers/scsi/csiostor/csio_isr.c
>  create mode 100644 drivers/scsi/csiostor/csio_lnode.c
>  create mode 100644 drivers/scsi/csiostor/csio_lnode.h
>  create mode 100644 drivers/scsi/csiostor/csio_mb.c
>  create mode 100644 drivers/scsi/csiostor/csio_mb.h
>  create mode 100644 drivers/scsi/csiostor/csio_rnode.c
>  create mode 100644 drivers/scsi/csiostor/csio_rnode.h
>  create mode 100644 drivers/scsi/csiostor/csio_scsi.c
>  create mode 100644 drivers/scsi/csiostor/csio_scsi.h
>  create mode 100644 drivers/scsi/csiostor/csio_wr.c
>  create mode 100644 drivers/scsi/csiostor/csio_wr.h
>  create mode 100644 drivers/scsi/csiostor/t4fw_api_stor.h
> 


^ permalink raw reply

* Re: [3.5/6.x][e1000e] - Regression - Unable to receive packets if MTU == 1500
From: Jeff Kirsher @ 2012-11-02  8:40 UTC (permalink / raw)
  To: Shawn Starr; +Cc: netdev, e1000-devel
In-Reply-To: <1570009.hYb0226lHg@segfault.sh0n.net>

[-- Attachment #1: Type: text/plain, Size: 3542 bytes --]

On 11/01/2012 10:58 AM, Shawn Starr wrote:
> Hello network driver folks,
>
> I recently decided to reinstall my Lenovo W500 laptop and found I wasn't able 
> to get DHCP leases, I wasn't able to install over PXE (when getting the IP a 
> second time within the OS)
>
> Fedora is currently using kernel-3.6.2-2.fc18.x86_64 (Pre-beta)
>
> The only difference I noticed was in my old install of Fedora, I had added 
> MTU=9000 to the interface config while using a 3.5 kernel, not knowing 3.6.x 
> seems to break things.
>
> My Cisco DPC3825 Switch/Cable modem has an MTU setting but this is from Cable 
> provider <-> WAN interface only. I tried changing to 1500 but by default it 
> uses this anyway.
>
> I had noticed tx unit hang errors sometimes, but not when MTU is above 1500.
>
> PCI info:
>
> 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network 
> Connection (rev 03)
>         Subsystem: Lenovo Device 20ee
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR+ FastB2B- DisINTx+
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0
>         Interrupt: pin A routed to IRQ 46
>         Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=128K]
>         Region 1: Memory at fc025000 (32-bit, non-prefetchable) [size=4K]
>         Region 2: I/O ports at 1840 [size=32]
>         Capabilities: [c8] Power Management version 2
>                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>         Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>                 Address: 00000000fee0100c  Data: 41a2
>         Capabilities: [e0] PCI Advanced Features
>                 AFCap: TP+ FLR+
>                 AFCtrl: FLR-
>                 AFStatus: TP-
>         Kernel driver in use: e1000e
>
> e1000e conversation log:
>
> [   12.653816] e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
> [   12.653819] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
> [   12.653855] e1000e 0000:00:19.0: setting latency timer to 64
> [   12.653938] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set 
> to dynamic conservative mode
> [   12.653980] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
> [   12.844121] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 
> 00:22:68:0c:96:e3
> [   12.844124] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> [   12.844150] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 1008FF-0FF
> [   17.459570] e1000e 0000:00:19.0: eth0: changing MTU from 1500 to 9000
> [   17.459577] e1000e 0000:00:19.0: Interrupt Throttle Rate turned off
> [   17.948121] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
> [   18.049164] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
> [   20.442936] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
> Control: Rx/Tx
>
> When I set MTU = 1500 (2000 works), it will stop receiving packets, it also 
> disables Interrupt Throttling when MTU is set higher.
>
> After testing reasons why it wasn't get a DHCP lease, I decided to bump the 
> MTU to 9000 for Jumbo Frames and as soon as I did this, I was able to get a 
> lease and the network functioned resumes receiving packets.
>
> Can anyone else report regressions or might know whats going on?
>
> Thanks,
> Shawn.
Adding e1000-devel mailing list


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

^ permalink raw reply

* Re: [PATCH 0/4] Support the MX6 FEC as a PTP hardware clock
From: Richard Cochran @ 2012-11-02  8:43 UTC (permalink / raw)
  To: Frank Li; +Cc: David Miller, Frank.Li, shawn.guo, linux-arm-kernel, netdev
In-Reply-To: <CAHrpEqRuy=kewK-592RphVfJnNoma2CPZytoTqLc45HeT53hRQ@mail.gmail.com>

On Fri, Nov 02, 2012 at 10:36:09AM +0800, Frank Li wrote:
> >
> > All applied to net-next.
> >
> > Please make sure your changes are in sync with Ben's PTP/PPS
> > Kconfig changes of today, and send me any changes if necessary.
> >
> 
> Thank you very much.
> I checked Ben's patch, which not affect FEC.

Maybe just remove the Kconfig line "select PPS".

Thanks,
Richard

^ permalink raw reply

* RE: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: N, Mugunthan V @ 2012-11-02  8:46 UTC (permalink / raw)
  To: Cousson, Benoit, Hiremath, Vaibhav
  Cc: netdev@vger.kernel.org, paul@pwsan.com,
	linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	Richard Cochran
In-Reply-To: <50914107.2090909@ti.com>

> -----Original Message-----
> From: Cousson, Benoit
> Sent: Wednesday, October 31, 2012 8:47 PM
> To: Hiremath, Vaibhav
> Cc: netdev@vger.kernel.org; paul@pwsan.com; linux-arm-
> kernel@lists.infradead.org; linux-omap@vger.kernel.org; N, Mugunthan V;
> Richard Cochran
> Subject: Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module
> nodes for AM33XX
> > +			compatible = "ti,cpsw";
> > +			ti,hwmods = "cpgmac0";
> > +			cpdma_channels = <8>;
> > +			host_port_no = <0>;
> > +			cpdma_reg_ofs = <0x800>;
> > +			cpdma_sram_ofs = <0xa00>;
> > +			ale_reg_ofs = <0xd00>;
> > +			ale_entries = <1024>;
> > +			host_port_reg_ofs = <0x108>;
> > +			hw_stats_reg_ofs = <0x900>;
> > +			bd_ram_ofs = <0x2000>;
> > +			bd_ram_size = <0x2000>;
> > +			no_bd_ram = <0>;
> > +			rx_descs = <64>;
> > +			mac_control = <0x20>;
> 
> Do you have to store all these data in the DTS? Cannot it be in the
> driver?
> 
> Do you expect to have several instance of the same IP with different
> parameters here?

Though CPSW is a single IP in AM335X, CPSW has sub modules like CPDMA, ALE,
SLIVER, CPTS and SLAVES where is IP integrator can locate it at different
offsets. For example comparing the CPSW ip in TI814X and AM335X all the
above offsets are changed. So I have kept all these offsets in DT as driver
should not hold any SoC related informations

> > +			cpsw_emac0: slave@0 {
> 
> Mmm, you are using some address later and here some relative number,
> that does not looks very consistent.
> 
> > +				slave_reg_ofs = <0x208>;
> 
> Is it an offset from 4a100000? Cannot you use the address for the slave
> name?
> 
> Something like that: cpsw_emac0: slave@4a100208
> 

I have followed the naming convention as per the TRM which is mentioned as
Slave 0 and Slave 1 and its offset is from 0x4a100000. I have taken the
reference from  arch/arm/boot/dts/picoxcell-pc3x2.dtsi+167 and followed
the same naming convention from TRM. There is one more method to implement
in reference from arch/arm/boot/dts/imx6q.dtsi+408 as below

+			cpsw_emac0: slave@208 {
+				slave_reg_ofs = <0x208>;
+				sliver_reg_ofs = <0xd80>;
+				/* Filled in by U-Boot */
+				mac-address = [ 00 00 00 00 00 00 ];
+			};

Regards
Mugunthan V N 


^ permalink raw reply

* [RESEND PATCH net-next] ipv6/multipath: remove flag NLM_F_EXCL after the first nexthop
From: Nicolas Dichtel @ 2012-11-02  8:58 UTC (permalink / raw)
  To: davem
  Cc: shemminger, netdev, joe, bernat, eric.dumazet, yoshfuji,
	Nicolas Dichtel
In-Reply-To: <50896D47.7030500@6wind.com>

fib6_add_rt2node() will reject the nexthop if this flag is set, so
we perform the check only for the first nexthop.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 net/ipv6/route.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c42650c..9c7b5d8 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2449,6 +2449,12 @@ beginning:
 				goto beginning;
 			}
 		}
+		/* Because each route is added like a single route we remove
+		 * this flag after the first nexthop (if there is a collision,
+		 * we have already fail to add the first nexthop:
+		 * fib6_add_rt2node() has reject it).
+		 */
+		cfg->fc_nlinfo.nlh->nlmsg_flags &= ~NLM_F_EXCL;
 		rtnh = rtnh_next(rtnh, &remaining);
 	}
 
-- 
1.7.12

^ permalink raw reply related

* [PATCH] net-ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-02  8:55 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: netdev

Hello Eric Dumazet:

1) This time (the first time):
   A) I have done according to what you have suggested.
      i)   git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
      ii)  format with `git format-patch -s --summary --stat`
      iii) cc to netdev@vger.kernel.org (not to linux-kernle@vger.kernel.org)  
   B) please check the 'Main Contents' (below of this mail).
   C) thank you for your original information again, they are truly useful for me.

2) Next time (if also for net/ipv6):
   A) I will send mail according to MAINTAINERS (which also you suggested)
      M:      "David S. Miller" <davem@davemloft.net>
      M:      Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      M:      James Morris <jmorris@namei.org>
      M:      Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      M:      Patrick McHardy <kaber@trash.net>
      L:      netdev@vger.kernel.org
      T:      git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
   B) Only have 'Main Content' in next time.


Main Contents:
-----------------------------------------------------------------------------------
From: Chen Gang <gang.chen@asianux.com>
Date: Fri, 2 Nov 2012 16:02:11 +0800
Subject: [PATCH] net-ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route

  the length of rt->dst.dev->name is 16 (IFNAMSIZ)
  in seq_printf, it is not suitable to use %8s for rt->dst.dev->name.
  so change it to %s, since each line has not been solid any more.

  additional information:

    %8s  limit the width, not for the original string output length
         if name length is more than 8, it still can be fully displayed.
         if name length is less than 8, the ' ' will be filled before name.

    %.8s truly limit the original string output length (precision)


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 net/ipv6/route.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c42650c..b60bc52 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2835,7 +2835,7 @@ static int rt6_info_route(struct rt6_info *rt, void *p_arg)
        } else {
                seq_puts(m, "00000000000000000000000000000000");
        }
-       seq_printf(m, " %08x %08x %08x %08x %8s\n",
+       seq_printf(m, " %08x %08x %08x %08x %s\n",
                   rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
                   rt->dst.__use, rt->rt6i_flags,
                   rt->dst.dev ? rt->dst.dev->name : "");
-- 
1.7.9.5




-- 
Chen Gang

Asianux Corporation

^ permalink raw reply related

* Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Richard Cochran @ 2012-11-02  8:56 UTC (permalink / raw)
  To: N, Mugunthan V
  Cc: Cousson, Benoit, Hiremath, Vaibhav, netdev@vger.kernel.org,
	paul@pwsan.com, linux-arm-kernel@lists.infradead.org,
	linux-omap@vger.kernel.org
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293EA08F53@DBDE01.ent.ti.com>

On Fri, Nov 02, 2012 at 08:46:46AM +0000, N, Mugunthan V wrote:
> > 
> > Do you expect to have several instance of the same IP with different
> > parameters here?
> 
> Though CPSW is a single IP in AM335X, CPSW has sub modules like CPDMA, ALE,
> SLIVER, CPTS and SLAVES where is IP integrator can locate it at different
> offsets. For example comparing the CPSW ip in TI814X and AM335X all the
> above offsets are changed. So I have kept all these offsets in DT as driver
> should not hold any SoC related informations

Did you see the two messages on this point from yesterday?

Thanks,
Richard

^ permalink raw reply

* Re: [net-next:master 122/152] drivers/ptp/ptp_chardev.c:36 ptp_ioctl() warn: 'sysoff' puts 832 bytes on stack
From: Richard Cochran @ 2012-11-02  8:59 UTC (permalink / raw)
  To: Yuanhan Liu; +Cc: changlongx.xie, fengguang.wu, netdev
In-Reply-To: <20121102020631.GI16883@yliu-dev.sh.intel.com>

On Fri, Nov 02, 2012 at 10:06:31AM +0800, Yuanhan Liu wrote:
> 
> Hi Richard,
> 
> _just_ FYI and let you aware of it, there are new smatch warnings show up in
> 
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
> head:   b77bc2069d1e437d5a1a71bb5cfcf4556ee40015
> commit: 215b13dd288c2e1e4461c1530a801f5f83e8cd90 [122/152] ptp: add an ioctl to compare PHC time with system time
> 
> + drivers/ptp/ptp_chardev.c:36 ptp_ioctl() warn: 'sysoff' puts 832 bytes on stack
>   drivers/ptp/ptp_chardev.c:144 ptp_read() warn: 'event' puts 960 bytes on stack

I am aware that these methods use large stack buffers, but I thought
it was okay seeing as they are both under the 1k limit.

Thanks,
Richard

^ permalink raw reply

* Re: [PATCH 4/4] FEC: Add time stamping code and a PTP hardware clock
From: Richard Cochran @ 2012-11-02  9:19 UTC (permalink / raw)
  To: Frank Li; +Cc: lznua, shawn.guo, linux-arm-kernel, netdev, davem
In-Reply-To: <1351657531-25989-1-git-send-email-Frank.Li@freescale.com>

On Wed, Oct 31, 2012 at 12:25:31PM +0800, Frank Li wrote:

> diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
> index feff516..ff3be53 100644
> --- a/drivers/net/ethernet/freescale/Kconfig
> +++ b/drivers/net/ethernet/freescale/Kconfig
> @@ -92,4 +92,13 @@ config GIANFAR
>  	  This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx,
>  	  and MPC86xx family of chips, and the FEC on the 8540.
>  
> +config FEC_PTP
> +	bool "PTP Hardware Clock (PHC)"
> +	depends on FEC
> +	select PPS
> +	select PTP_1588_CLOCK
> +	--help---
> +	  Say Y here if you want to use PTP Hardware Clock (PHC) in the
> +	  driver.  Only the basic clock operations have been implemented.
> +

Does the PTP function work with every FEC on ColdFire and i.MX?

Or do you need to limit this option in some way?

>  endif # NET_VENDOR_FREESCALE

...

> diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
> new file mode 100644
> index 0000000..9b91da9
> --- /dev/null
> +++ b/drivers/net/ethernet/freescale/fec_ptp.c

...

> +/**
> + * fec_ptp_adjfreq - adjust ptp cycle frequency
> + * @ptp: the ptp clock structure
> + * @ppb: parts per billion adjustment from base
> + *
> + * Adjust the frequency of the ptp cycle counter by the
> + * indicated ppb from the base frequency.
> + *
> + * Because ENET hardware frequency adjust is complex,
> + * using software method to do that.
> + */
> +static int fec_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
> +{
> +	u64 diff;
> +	unsigned long flags;
> +	int neg_adj = 0;
> +
> +	struct fec_enet_private *fep =
> +	    container_of(ptp, struct fec_enet_private, ptp_caps);
> +
> +	if (ppb < 0) {
> +		ppb = -ppb;
> +		neg_adj = 1;
> +	}
> +
> +	spin_lock_irqsave(&fep->tmreg_lock, flags);
> +	/*
> +	 * dummy read to set cycle_last in tc to now.
> +	 * So use adjusted mult to calculate when next call
> +	 * timercounter_read.
> +	 */
> +	timecounter_read(&fep->tc);

You can reduce the time that the spin lock is held by moving the next
four lines before the locked region:

> +	fep->cc.mult = FEC_CC_MULT;
> +	diff = fep->cc.mult;
> +	diff *= ppb;
> +	diff = div_u64(diff, 1000000000ULL);

> +
> +	if (neg_adj)
> +		fep->cc.mult -= diff;
> +	else
> +		fep->cc.mult += diff;
> +
> +	spin_unlock_irqrestore(&fep->tmreg_lock, flags);
> +
> +	return 0;
> +}

Thanks,
Richard

^ permalink raw reply

* [PATCH] net-ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-02  9:28 UTC (permalink / raw)
  To: Eric Dumazet, netdev
In-Reply-To: <50938A65.6040507@asianux.com>

Hello Eric Dumazet:

1) This time (the first time):
   A) I have done according to what you have suggested.
      i)   git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
      ii)  format with `git format-patch -s --summary --stat`
      iii) cc to netdev@vger.kernel.org (not to linux-kernle@vger.kernel.org)  
   B) please check the 'Main Contents' (below of this mail).
   C) thank you for your original information again, they are truly useful for me.

2) Next time (if also for net/ipv6):
   A) I will send mail according to MAINTAINERS (which also you suggested)
      M:      "David S. Miller" <davem@davemloft.net>
      M:      Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      M:      James Morris <jmorris@namei.org>
      M:      Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      M:      Patrick McHardy <kaber@trash.net>
      L:      netdev@vger.kernel.org
      T:      git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
   B) Only have 'Main Content' in next time.


Main Contents:
-----------------------------------------------------------------------------------
From: Chen Gang <gang.chen@asianux.com>
Date: Fri, 2 Nov 2012 16:02:11 +0800
Subject: [PATCH] net-ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route

  the length of rt->dst.dev->name is 16 (IFNAMSIZ)
  in seq_printf, it is not suitable to use %8s for rt->dst.dev->name.
  so change it to %s, since each line has not been solid any more.

  additional information:

    %8s  limit the width, not for the original string output length
         if name length is more than 8, it still can be fully displayed.
         if name length is less than 8, the ' ' will be filled before name.

    %.8s truly limit the original string output length (precision)


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 net/ipv6/route.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c42650c..b60bc52 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2835,7 +2835,7 @@ static int rt6_info_route(struct rt6_info *rt, void *p_arg)
        } else {
                seq_puts(m, "00000000000000000000000000000000");
        }
-       seq_printf(m, " %08x %08x %08x %08x %8s\n",
+       seq_printf(m, " %08x %08x %08x %08x %s\n",
                   rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
                   rt->dst.__use, rt->rt6i_flags,
                   rt->dst.dev ? rt->dst.dev->name : "");
-- 
1.7.9.5




-- 
Chen Gang

Asianux Corporation

^ permalink raw reply related

* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Pavel Emelyanov @ 2012-11-02  9:36 UTC (permalink / raw)
  To: Brian Haley; +Cc: David Miller, Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <509184D9.8030103@hp.com>

> +static int sock_getbindtodevice(struct sock *sk, char __user *optval,
> +				int __user *optlen, int len)
> +{
> +	int ret = -ENOPROTOOPT;
> +#ifdef CONFIG_NETDEVICES
> +	struct net *net = sock_net(sk);
> +	struct net_device *dev;
> +	char devname[IFNAMSIZ];
> +
> +	if (sk->sk_bound_dev_if == 0) {
> +		len = 0;
> +		goto zero;
> +	}
> +
> +	ret = -EINVAL;
> +	if (len < IFNAMSIZ)
> +		goto out;
> +
> +	rcu_read_lock();
> +	dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
> +	if (dev)
> +		strcpy(devname, dev->name);

This still races with the device name change, potentially providing
a name which never existed in the system, doesn't it?

> +	rcu_read_unlock();
> +	ret = -ENODEV;
> +	if (!dev)
> +		goto out;
> +
> +	len = strlen(devname) + 1;
> +
> +	ret = -EFAULT;
> +	if (copy_to_user(optval, devname, len))
> +		goto out;
> +
> +zero:
> +	ret = -EFAULT;
> +	if (put_user(len, optlen))
> +		goto out;
> +
> +	ret = 0;
> +
> +out:
> +#endif
> +
> +	return ret;
> +}

Thanks,
Pavel

^ permalink raw reply

* Re: [PATCH v2 2/3] pppoatm: fix race condition with destroying of vcc
From: Krzysztof Mazur @ 2012-11-02  9:40 UTC (permalink / raw)
  To: chas williams - CONTRACTOR; +Cc: davem, dwmw2, netdev, linux-kernel
In-Reply-To: <20121101102628.6e3d3cae@thirdoffive.cmf.nrl.navy.mil>

On Thu, Nov 01, 2012 at 10:26:28AM -0400, chas williams - CONTRACTOR wrote:
> On Wed, 31 Oct 2012 23:04:35 +0100
> Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> 
> > There are also some minor potential issues in pppoatm driver:
> > 
> > 	- locking issues, but now only between pppoatm_send() and
> > 	  vcc_sendmsg() and maybe some other functions,
> 
> these have been around for a while.  i agree that something should be
> done about it.  just not sure what should be synchronizing this mess.

I think the ATM socket lock should be used. I'm sending the latest
patch that adds this locking after David Woodhouse's comments. The vcc->flags
check is now probably unnecessary.

> 
> > 	- missing check for SS_CONNECTED in pppoatm_ioctl,
> 
> in practice you will never run into this because a pvc is immediately
> put into SS_CONNECTED mode (right before the userspace open()
> returns).  however, should it check?  yes.  i dont see anything
> preventing you from running ppp on svc's.

I can confirm that the problem really exists, without connect() in pppoatm
plugin in pppd, I have seen an Oops and panic. I will send appropriate
patch.

Thanks.

Krzysiek

-- >8 --
diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index f27a07a..ef19436 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -269,10 +269,23 @@ static inline int pppoatm_may_send(struct pppoatm_vcc *pvcc, int size)
 static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
 {
 	struct pppoatm_vcc *pvcc = chan_to_pvcc(chan);
+	struct atm_vcc *vcc;
+	int ret;
+
 	ATM_SKB(skb)->vcc = pvcc->atmvcc;
 	pr_debug("(skb=0x%p, vcc=0x%p)\n", skb, pvcc->atmvcc);
 	if (skb->data[0] == '\0' && (pvcc->flags & SC_COMP_PROT))
 		(void) skb_pull(skb, 1);
+
+	vcc = ATM_SKB(skb)->vcc;
+	bh_lock_sock(sk_atm(vcc));
+	if (sock_owned_by_user(sk_atm(vcc)))
+		goto nospace;
+	if (test_bit(ATM_VF_RELEASED, &vcc->flags)
+			|| test_bit(ATM_VF_CLOSE, &vcc->flags)
+			|| !test_bit(ATM_VF_READY, &vcc->flags))
+		goto nospace;
+
 	switch (pvcc->encaps) {		/* LLC encapsulation needed */
 	case e_llc:
 		if (skb_headroom(skb) < LLC_LEN) {
@@ -285,8 +298,10 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
 			}
 			consume_skb(skb);
 			skb = n;
-			if (skb == NULL)
+			if (skb == NULL) {
+				bh_unlock_sock(sk_atm(vcc));
 				return DROP_PACKET;
+			}
 		} else if (!pppoatm_may_send(pvcc, skb->truesize))
 			goto nospace;
 		memcpy(skb_push(skb, LLC_LEN), pppllc, LLC_LEN);
@@ -296,6 +311,7 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
 			goto nospace;
 		break;
 	case e_autodetect:
+		bh_unlock_sock(sk_atm(vcc));
 		pr_debug("Trying to send without setting encaps!\n");
 		kfree_skb(skb);
 		return 1;
@@ -305,9 +321,12 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
 	ATM_SKB(skb)->atm_options = ATM_SKB(skb)->vcc->atm_options;
 	pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n",
 		 skb, ATM_SKB(skb)->vcc, ATM_SKB(skb)->vcc->dev);
-	return ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
+	ret = ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
 	    ? DROP_PACKET : 1;
+	bh_unlock_sock(sk_atm(vcc));
+	return ret;
 nospace:
+	bh_unlock_sock(sk_atm(vcc));
 	/*
 	 * We don't have space to send this SKB now, but we might have
 	 * already applied SC_COMP_PROT compression, so may need to undo

^ permalink raw reply related

* [PATCH net-next] ptp: fixup Kconfig for two PHC drivers.
From: Richard Cochran @ 2012-11-02  9:57 UTC (permalink / raw)
  To: netdev; +Cc: David Miller

Ben Hutchings recently came up with a better way to handle the kconfig
dependencies for the PTP hardware clocks. This patch converts one new and
one older driver to the new scheme.

Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
 drivers/net/ethernet/adi/Kconfig |    2 +-
 drivers/net/ethernet/ti/Kconfig  |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig
index 175c38c..e49c0ef 100644
--- a/drivers/net/ethernet/adi/Kconfig
+++ b/drivers/net/ethernet/adi/Kconfig
@@ -61,7 +61,7 @@ config BFIN_RX_DESC_NUM
 
 config BFIN_MAC_USE_HWSTAMP
 	bool "Use IEEE 1588 hwstamp"
-	depends on BFIN_MAC && BF518 && PTP_1588_CLOCK && !(BFIN_MAC=y && PTP_1588_CLOCK=m)
+	select PTP_1588_CLOCK
 	default y
 	---help---
 	  To support the IEEE 1588 Precision Time Protocol (PTP), select y here
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index cbc3905..14297ff 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -62,7 +62,7 @@ config TI_CPSW
 
 config TI_CPTS
 	boolean "TI Common Platform Time Sync (CPTS) Support"
-	depends on TI_CPSW && PTP_1588_CLOCK && !(TI_CPSW=y && PTP_1588_CLOCK=m)
+	select PTP_1588_CLOCK
 	---help---
 	  This driver supports the Common Platform Time Sync unit of
 	  the CPSW Ethernet Switch. The unit can time stamp PTP UDP/IPv4
-- 
1.7.2.5

^ permalink raw reply related

* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Eric Dumazet @ 2012-11-02 10:23 UTC (permalink / raw)
  To: Pavel Emelyanov; +Cc: Brian Haley, David Miller, netdev@vger.kernel.org
In-Reply-To: <5093940B.6020207@parallels.com>

On Fri, 2012-11-02 at 13:36 +0400, Pavel Emelyanov wrote:

> This still races with the device name change, potentially providing
> a name which never existed in the system, doesn't it?

It does.

Maybe add a seqlock_t, to avoid taking rtnl here.
(as it could bring interesting lockdep/deadlock issues)

Here is the write side. Read side is trivial.

diff --git a/net/core/dev.c b/net/core/dev.c
index b4978e2..0184ec9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -201,6 +201,8 @@ static struct list_head ptype_all __read_mostly;	/* Taps */
 DEFINE_RWLOCK(dev_base_lock);
 EXPORT_SYMBOL(dev_base_lock);
 
+DEFINE_SEQLOCK(devnet_rename_seq);
+
 static inline void dev_base_seq_inc(struct net *net)
 {
 	while (++net->dev_base_seq == 0);
@@ -1018,17 +1020,22 @@ int dev_change_name(struct net_device *dev, const char *newname)
 
 	memcpy(oldname, dev->name, IFNAMSIZ);
 
+	write_seqlock(&devnet_rename_seq);
 	err = dev_get_valid_name(net, dev, newname);
-	if (err < 0)
+	if (err < 0) {
+		write_sequnlock(&devnet_rename_seq);
 		return err;
-
+	}
 rollback:
 	ret = device_rename(&dev->dev, dev->name);
 	if (ret) {
 		memcpy(dev->name, oldname, IFNAMSIZ);
+		write_sequnlock(&devnet_rename_seq);
 		return ret;
 	}
 
+	write_sequnlock(&devnet_rename_seq);
+
 	write_lock_bh(&dev_base_lock);
 	hlist_del_rcu(&dev->name_hlist);
 	write_unlock_bh(&dev_base_lock);
@@ -1046,6 +1053,7 @@ rollback:
 		/* err >= 0 after dev_alloc_name() or stores the first errno */
 		if (err >= 0) {
 			err = ret;
+			write_seqlock(&devnet_rename_seq);
 			memcpy(dev->name, oldname, IFNAMSIZ);
 			goto rollback;
 		} else {

^ permalink raw reply related

* RE: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: N, Mugunthan V @ 2012-11-02 10:42 UTC (permalink / raw)
  To: Richard Cochran
  Cc: Cousson, Benoit, Hiremath, Vaibhav, netdev@vger.kernel.org,
	paul@pwsan.com, linux-arm-kernel@lists.infradead.org,
	linux-omap@vger.kernel.org
In-Reply-To: <20121102085616.GB2486@netboy.at.omicron.at>

> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Friday, November 02, 2012 2:26 PM
> To: N, Mugunthan V
> Cc: Cousson, Benoit; Hiremath, Vaibhav; netdev@vger.kernel.org;
> paul@pwsan.com; linux-arm-kernel@lists.infradead.org; linux-
> omap@vger.kernel.org
> Subject: Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module
> nodes for AM33XX
> 
> On Fri, Nov 02, 2012 at 08:46:46AM +0000, N, Mugunthan V wrote:
> > >
> > > Do you expect to have several instance of the same IP with
> different
> > > parameters here?
> >
> > Though CPSW is a single IP in AM335X, CPSW has sub modules like
> CPDMA, ALE,
> > SLIVER, CPTS and SLAVES where is IP integrator can locate it at
> different
> > offsets. For example comparing the CPSW ip in TI814X and AM335X all
> the
> > above offsets are changed. So I have kept all these offsets in DT as
> driver
> > should not hold any SoC related informations
> 
> Did you see the two messages on this point from yesterday?

I saw those posts. The CPSW ip version changes tracks the internal IP
changes and there is no possible way to track the offset changes. For
example CPTS sub module offsets in DM814x and AM335x are different
though the CPTS version is same in both IP versions. So keeping these
offset in DT will make the same driver works directly with DT changes
for future SoC.

Regards
Mugunthan V N

^ permalink raw reply

* [PATCH] smsc95xx: fix tx checksum offload for big endian
From: Steve Glendinning @ 2012-11-02 10:44 UTC (permalink / raw)
  To: netdev; +Cc: jose.ventura, Steve Glendinning

f7b2927 introduced tx checksum offload support for smsc95xx,
and enabled it by default. This feature doesn't take
endianness into account, so causes most tx to fail on
those platforms.

This patch fixes the problem fully by adding the missing
conversion.

An alternate workaround is to disable TX checksum offload
on those platforms. The cpu impact of this feature is very low.

Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
---
 drivers/net/usb/smsc95xx.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 46cd784..34f2e78 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1398,6 +1398,7 @@ static struct sk_buff *smsc95xx_tx_fixup(struct usbnet *dev,
 		} else {
 			u32 csum_preamble = smsc95xx_calc_csum_preamble(skb);
 			skb_push(skb, 4);
+			cpu_to_le32s(&csum_preamble);
 			memcpy(skb->data, &csum_preamble, 4);
 		}
 	}
-- 
1.7.10.4

^ permalink raw reply related

* Re: [PATCH v2 2/3] pppoatm: fix race condition with destroying of vcc
From: Krzysztof Mazur @ 2012-11-02 10:54 UTC (permalink / raw)
  To: chas williams - CONTRACTOR; +Cc: davem, dwmw2, netdev, linux-kernel
In-Reply-To: <20121102094018.GA14960@shrek.podlesie.net>

On Fri, Nov 02, 2012 at 10:40:18AM +0100, Krzysztof Mazur wrote:
> On Thu, Nov 01, 2012 at 10:26:28AM -0400, chas williams - CONTRACTOR wrote:
> > On Wed, 31 Oct 2012 23:04:35 +0100
> > Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> > > 	- missing check for SS_CONNECTED in pppoatm_ioctl,
> > 
> > in practice you will never run into this because a pvc is immediately
> > put into SS_CONNECTED mode (right before the userspace open()
> > returns).  however, should it check?  yes.  i dont see anything
> > preventing you from running ppp on svc's.
> 
> I can confirm that the problem really exists, without connect() in pppoatm
> plugin in pppd, I have seen an Oops and panic. I will send appropriate
> patch.

I'm sending the patch that fixes this issue. Works correctly with original
pppd, and does not crash with pppd without connect() - the pppd just
logs:

pppd[3460]: ioctl(ATM_SETBACKEND): Invalid argument

and exits.

Krzysiek

-- >8 --
Subject: [PATCH] pppoatm: allow assign only on a connected socket

The pppoatm does not check if the used vcc is in connected state,
causing an Oops in pppoatm_send() when vcc->send() is called
on not fully connected socket.

Now pppoatm can be assigned only on connected sockets; otherwise
-EINVAL error is returned.

Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [<  (null)>]   (null)
*pde = 00000000 
Oops: 0000 [#1] PREEMPT 
Pid: 4154, comm: pppd Not tainted 3.6.0-krzysiek-00002-g3ff1093 #95    /AK32 
EIP: 0060:[<00000000>] EFLAGS: 00010202 CPU: 0
EIP is at 0x0
EAX: d95f7800 EBX: d9d4ba80 ECX: d95f7800 EDX: d9d4ba80
ESI: ffffffff EDI: 00000001 EBP: 000001c0 ESP: d9823f34
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 1e7b6000 CR4: 000007d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process pppd (pid: 4154, ti=d9822000 task=d99918a0 task.ti=d9822000)
Stack:
 c060cd9b c043a2ca d99ed860 d99ed864 d9d4ba80 08094f22 c043a228 d9d4ba80
 d99ed860 0000000c c043a347 ffffffff 0000000c d94311a0 08094f22 c043a290
 c019f72e d9823f9c 00000003 09df1090 d94311a0 08094f22 00000008 d9822000
Call Trace:
 [<c060cd9b>] ? pppoatm_send+0x6b/0x300
 [<c043a2ca>] ? ppp_write+0x3a/0xe0
 [<c043a228>] ? ppp_channel_push+0x38/0xa0
 [<c043a347>] ? ppp_write+0xb7/0xe0
 [<c043a290>] ? ppp_channel_push+0xa0/0xa0
 [<c019f72e>] ? vfs_write+0x8e/0x140
 [<c019f88c>] ? sys_write+0x3c/0x70
 [<c062ab50>] ? sysenter_do_call+0x12/0x26
Code:  Bad EIP value.
EIP: [<00000000>] 0x0 SS:ESP 0068:d9823f34
CR2: 0000000000000000
---[ end trace e29cf1805f576278 ]---
Kernel panic - not syncing: Fatal exception in interrupt

 net/atm/pppoatm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index 226dca9..f27a07a 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -406,6 +406,8 @@ static int pppoatm_ioctl(struct socket *sock, unsigned int cmd,
 			return -ENOIOCTLCMD;
 		if (!capable(CAP_NET_ADMIN))
 			return -EPERM;
+		if (sock->state != SS_CONNECTED)
+			return -EINVAL;
 		return pppoatm_assign_vcc(atmvcc, argp);
 		}
 	case PPPIOCGCHAN:
-- 
1.8.0.172.g62af90c

^ permalink raw reply related

* [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info_route
From: Chen Gang @ 2012-11-02 12:18 UTC (permalink / raw)
  To: davem, kuznet, jmorris, yoshfuji, kaber; +Cc: netdev
In-Reply-To: <50938A65.6040507@asianux.com>


  the length of rt->dst.dev->name is 16 (IFNAMSIZ)
  in seq_printf, it is not suitable to use %8s for rt->dst.dev->name.
  so change it to %s, since each line has not been solid any more.

  additional information:

    %8s  limit the width, not for the original string output length
         if name length is more than 8, it still can be fully displayed.
         if name length is less than 8, the ' ' will be filled before name.

    %.8s truly limit the original string output length (precision)


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 net/ipv6/route.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c42650c..b60bc52 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2835,7 +2835,7 @@ static int rt6_info_route(struct rt6_info *rt, void *p_arg)
        } else {
                seq_puts(m, "00000000000000000000000000000000");
        }
-       seq_printf(m, " %08x %08x %08x %08x %8s\n",
+       seq_printf(m, " %08x %08x %08x %08x %s\n",
                   rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
                   rt->dst.__use, rt->rt6i_flags,
                   rt->dst.dev ? rt->dst.dev->name : "");
-- 
1.7.9.5




-- 
Chen Gang

Asianux Corporation

^ permalink raw reply related

* Re: [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-02 14:01 UTC (permalink / raw)
  To: Jesse Gross
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, Shan Wei, David Miller,
	Kernel-Maillist, NetDev
In-Reply-To: <CAEP_g=-GSpSJkeZbwDpBwo-in0FYD=LjWdCFsdo7-a=ssL41nA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Thu, 1 Nov 2012, Jesse Gross wrote:

> On Thu, Nov 1, 2012 at 7:33 AM, Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote:
> > On Thu, 1 Nov 2012, Shan Wei wrote:
> >
> >> But for different field in same per-cpu variable, how to guarantee n_missed
> >> and n_hit are from same cpu?
> >> this_cpu_read(dp->stats_percpu->n_missed);
> >> [processor changed]
> >> this_cpu_read(dp->stats_percpu->n_hit);
> >
> > What does current guarantee that? If it is guaranteed then you can use the
> > __this_cpu_xxx ops.
>
> Preemption is disabled in all of the places where writes are done and
> all of the reads are from foreign CPUs.

Since preemption is disabled no processor change can occur. So its safe to
use __this_cpu ops throughout and they will operate on the current per cpu
area.

^ permalink raw reply

* Re: switching network namespace midway
From: Benjamin LaHaise @ 2012-11-02 14:03 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: rsa, netdev
In-Reply-To: <87k3u4il2l.fsf@xmission.com>

On Thu, Nov 01, 2012 at 11:18:58PM -0700, Eric W. Biederman wrote:
> You need a per network namespace exit function to delete the tunnel when
> the xmit direction goes away.  Otherwise we have a very nasty race if
> the original network namespace exits.

That already exists as ipgre_exit_net().  Since the ip_tunnel structure 
remains hashed in the network namespace that creation occurred in, this 
case should be covered.

> NETNS_LOCAL may make sense on the reference device that is used to
> support ioctls for creating devices.

*nod*  That makes sense.

> ipgre_open ?  It looks like it needs to be handled.  Probably that
> ip_route_output_gre needs to be moved.

Good catch.  Will respin with that changed.

> ipv6?

That's next on the list.  There are also issues with ipip, ipmr and 
ipvti, as well as their ipv6 versions.

		-ben
-- 
"Thought is the essence of where you are now."

^ permalink raw reply

* [PATCH] [trivial] net: bnx2x: Fix typo in bnx2x driver
From: Masanari Iida @ 2012-11-02 14:36 UTC (permalink / raw)
  To: trivial, linux-kernel, eilong, netdev; +Cc: Masanari Iida

Correct spelling typo in bnx2x driver

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c    | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index c65295d..6e5bdd1 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -1702,7 +1702,7 @@ static int bnx2x_set_eee(struct net_device *dev, struct ethtool_eee *edata)
 				      SHMEM_EEE_ADV_STATUS_SHIFT);
 	if ((advertised != (eee_cfg & SHMEM_EEE_ADV_STATUS_MASK))) {
 		DP(BNX2X_MSG_ETHTOOL,
-		   "Direct manipulation of EEE advertisment is not supported\n");
+		   "Direct manipulation of EEE advertisement is not supported\n");
 		return -EINVAL;
 	}
 
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index e2e45ee..5be223e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -9878,7 +9878,7 @@ static int bnx2x_848x3_config_init(struct bnx2x_phy *phy,
 		else
 			rc = bnx2x_8483x_disable_eee(phy, params, vars);
 		if (rc) {
-			DP(NETIF_MSG_LINK, "Failed to set EEE advertisment\n");
+			DP(NETIF_MSG_LINK, "Failed to set EEE advertisement\n");
 			return rc;
 		}
 	} else {
@@ -12919,7 +12919,7 @@ static u8 bnx2x_analyze_link_error(struct link_params *params,
 		DP(NETIF_MSG_LINK, "Analyze TX Fault\n");
 		break;
 	default:
-		DP(NETIF_MSG_LINK, "Analyze UNKOWN\n");
+		DP(NETIF_MSG_LINK, "Analyze UNKNOWN\n");
 	}
 	DP(NETIF_MSG_LINK, "Link changed:[%x %x]->%x\n", vars->link_up,
 	   old_status, status);
-- 
1.8.0.rc3.16.g8ead1bf

^ permalink raw reply related

* Re: [PATCH 3/3] net: neterion: Do not break word unregister.
From: YOSHIFUJI Hideaki @ 2012-11-02 14:43 UTC (permalink / raw)
  To: davem; +Cc: YOSHIFUJI Hideaki, netdev
In-Reply-To: <201211021439.qA2EdkbO004741@94.43.138.210.xn.2iij.net>

Sorry, subject and date are strange.  I'm resending...

--yoshfuji

YOSHIFUJI Hideaki wrote:
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> ---
>  drivers/net/ethernet/neterion/s2io.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/neterion/s2io.c b/drivers/net/ethernet/neterion/s2io.c
> index de50547..c98decb 100644
> --- a/drivers/net/ethernet/neterion/s2io.c
> +++ b/drivers/net/ethernet/neterion/s2io.c
> @@ -8239,7 +8239,8 @@ static int __init s2io_starter(void)
>  
>  /**
>   * s2io_closer - Cleanup routine for the driver
> - * Description: This function is the cleanup routine for the driver. It unregist * ers the driver.
> + * Description: This function is the cleanup routine for the driver. It
> + * unregisters the driver.
>   */
>  
>  static __exit void s2io_closer(void)
> 

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox