* Re: [PATCH 1/2] net: if_arp: add ARPHRD_RAWIP type
From: David Miller @ 2013-10-30 21:25 UTC (permalink / raw)
To: jukka.rissanen; +Cc: netdev
In-Reply-To: <1383124271-15290-2-git-send-email-jukka.rissanen@linux.intel.com>
From: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Date: Wed, 30 Oct 2013 11:11:10 +0200
> This is used when there is no L2 header before IP header.
> Example of this is Bluetooth 6LoWPAN network.
>
> The RAWIP header type value is already used in some Android kernels
> so same value is used here in order not to break userspace.
>
> Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
I'm not applying patches like this until there is an actual user,
and this therefore goes for patch #2 as well.
^ permalink raw reply
* Re: [PATCH] bnx2: Use dev_kfree_skb_any() in bnx2_tx_int()
From: David Miller @ 2013-10-30 21:32 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: tdmackey, mchan, netdev, linux-kernel
In-Reply-To: <CAM_iQpV6ufX5-OOrNQtsXH0_9itjU-FriOoutyKfDEWdg-irQw@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 30 Oct 2013 12:23:52 -0700
> On Tue, Oct 29, 2013 at 11:40 PM, David Miller <davem@davemloft.net> wrote:
>> From: Cong Wang <xiyou.wangcong@gmail.com>
>> Date: Tue, 29 Oct 2013 20:50:08 -0700
>>
>>> Normally ->poll() is called in softirq context, while netpoll could
>>> be called in any context depending on its caller.
>>
>> It still makes amends to make the execution context still looks
>> "compatible" as far as locking et al. is concerned.
>
> Adjusting netpoll code for IRQ context is much harder
> than just calling dev_kfree_skb_any()...
>
> What's more, we have similar change before:
>
> commit ed79bab847d8e5a2986d8ff43c49c6fb8ee3265f
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed Oct 14 14:36:43 2009 +0000
>
> virtio_net: use dev_kfree_skb_any() in free_old_xmit_skbs()
Explain to me then why other ethernet drivers implemented identically,
such as tg3, can use plain dev_kfree_skb() just fine?
^ permalink raw reply
* Re: [PATCH net-next] ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE
From: David Miller @ 2013-10-30 21:36 UTC (permalink / raw)
To: hannes; +Cc: netdev, fweimer
In-Reply-To: <20131030200725.GB9093@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 30 Oct 2013 21:07:25 +0100
> On Tue, Oct 29, 2013 at 01:04:25PM +0100, Hannes Frederic Sowa wrote:
>> I really tried hard to find alternatives or even a way to enable
>> the protection automatically given that at least unbound does apply
>> IP_PMTUDISC_DONT to its sockets already. These are the reasons why I
>> came up with the new IP_PMTUDISC_INTERFACE value:
>
> Sorry to bother you but I would really love to hear your feedback on my
> reasoning so I can try to come up with a solution you would be happy with.
All I've read is that administrators cannot be relied upon to
configure their systems properly for the requirements they have.
And that is a non-argument for adding this new socket option as far as
I'm concerned.
"I strongly do not trust path MTU information" has a scope as small as
a route or an interface, it doesn't go down to the socket or
application level at all.
Please stop pretending that it does.
^ permalink raw reply
* Re: 3.12-rc7 regression - network panic from ipv6
From: mroos @ 2013-10-30 21:41 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, hannes, Linux Kernel list, netdev
In-Reply-To: <20131030130945.GJ31491@secunet.com>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Works fine, thanks!
Tested-by: Meelis Roos <mroos@linux.ee>
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: RFC [PATCH 2/3] PTP: use flags to request HW features
From: Flavio Leitner @ 2013-10-30 21:48 UTC (permalink / raw)
To: linuxptp-devel; +Cc: netdev
In-Reply-To: <1383159637-8165-3-git-send-email-fbl@redhat.com>
Adding CC to netdev.
On Wed, Oct 30, 2013 at 05:00:36PM -0200, Flavio Leitner wrote:
> Currently the user space can't tell which delay mechanism
> (E2E/P2P) or transport is needed in the ioctl(). Therefore,
> PTP silently fails when the hardware doesn't support a
> certain delay mechanism or transport.
>
> This patch uses the ioctl flags field to pass that information
> from the user space to kernel. If the hardware supports all
> the desired features, the ioctl continues as before, otherwise
> the unsupported bits are reseted to 0 and this information is
> returned to user space.
>
> It's backwards compatible. If an older PTP applications calls
> the ioctl(), the flags field will be zero and no feature is
> checked.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
> ---
> include/uapi/linux/net_tstamp.h | 21 +++++++++++++++++++++
> net/core/dev_ioctl.c | 3 ---
> 2 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
> index ae5df12..d63f8e9 100644
> --- a/include/uapi/linux/net_tstamp.h
> +++ b/include/uapi/linux/net_tstamp.h
> @@ -44,6 +44,27 @@ struct hwtstamp_config {
> int rx_filter;
> };
>
> +/* possible values for hwtstamp_config->flags */
> +#define HWTSTAMP_FEATURE_FLAGS_MASK 0xFFFF
> +enum hwtstamp_feature_flags {
> + /* End-to-End Delay Mechanism */
> + HWTSTAMP_DM_E2E = (1<<0),
> + /* Peer-to-Peer Delay Mechanism */
> + HWTSTAMP_DM_P2P = (1<<1),
> + /* hole: 3 bits for additional mechanisms */
> +
> + HWTSTAMP_TRANS_UDS = (1<<5),
> + /* Message Transport: UDP over IPv4 */
> + HWTSTAMP_TRANS_UDP_IPV4 = (1<<6),
> + /* Message Transport: UDP over IPv6 */
> + HWTSTAMP_TRANS_UDP_IPV6 = (1<<7),
> + /* Message Transport: IEEE 802.3 Ethernet */
> + HWTSTAMP_TRANS_IEEE_802_3 = (1<<8),
> + HWTSTAMP_TRANS_DEVICENET = (1<<9),
> + HWTSTAMP_TRANS_CONTROLNET = (1<<10),
> + HWTSTAMP_TRANS_PROFINET = (1<<11),
> +};
> +
> /* possible values for hwtstamp_config->tx_type */
> enum hwtstamp_tx_types {
> /*
> diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
> index 5b7d0e1..9e2407e 100644
> --- a/net/core/dev_ioctl.c
> +++ b/net/core/dev_ioctl.c
> @@ -193,9 +193,6 @@ static int net_hwtstamp_validate(struct ifreq *ifr)
> if (copy_from_user(&cfg, ifr->ifr_data, sizeof(cfg)))
> return -EFAULT;
>
> - if (cfg.flags) /* reserved for future extensions */
> - return -EINVAL;
> -
> tx_type = cfg.tx_type;
> rx_filter = cfg.rx_filter;
>
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH] bnx2: Use dev_kfree_skb_any() in bnx2_tx_int()
From: Cong Wang @ 2013-10-30 22:01 UTC (permalink / raw)
To: David Miller; +Cc: TD Mackey, mchan, Linux Kernel Network Developers, LKML
In-Reply-To: <20131030.173200.2256841895208134119.davem@davemloft.net>
On Wed, Oct 30, 2013 at 2:32 PM, David Miller <davem@davemloft.net> wrote:
>
> Explain to me then why other ethernet drivers implemented identically,
> such as tg3, can use plain dev_kfree_skb() just fine?
I don't think they are fine, I just don't see bug reports
for them. At very least, I saw a same bug report for be2net too.
To reproduce this bug, we need to find some one calling printk()
within IRQ handler, which seems rare? It seems there are few
people using hpsa driver together with netconsole.
^ permalink raw reply
* Re: [PATCH 1/2] net: if_arp: add ARPHRD_RAWIP type
From: Marcel Holtmann @ 2013-10-30 22:26 UTC (permalink / raw)
To: David S. Miller; +Cc: Jukka Rissanen, netdev
In-Reply-To: <20131030.172556.454916501978452298.davem@davemloft.net>
Hi Dave,
>> This is used when there is no L2 header before IP header.
>> Example of this is Bluetooth 6LoWPAN network.
>>
>> The RAWIP header type value is already used in some Android kernels
>> so same value is used here in order not to break userspace.
>>
>> Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
>
> I'm not applying patches like this until there is an actual user,
> and this therefore goes for patch #2 as well.
patches for Bluetooth 6loWPAN have been posted to linux-bluetooth for review. So there is an actual user here.
If you do not want to merge these patches at this point, that is totally fine. We can happily carry them through bluetooth-next and wireless-next trees as well.
Posting them on netdev is mainly for checking that the changes we have to make outside the Bluetooth subsystem are in sync. So that they are reviewed and have been seen before. If you have any general objections to these assignments or changes, please let us now.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/3] e1000e: PTP: provide hardware features
From: Flavio Leitner @ 2013-10-30 21:50 UTC (permalink / raw)
To: linuxptp-devel; +Cc: netdev
In-Reply-To: <1383159637-8165-4-git-send-email-fbl@redhat.com>
Adding CC to netdev.
The first patch [1/3] is the userlevel linuxptp patch, so
I am not forwarding to netdev.
This is just an example which I used for testing locally. If
the idea is acceptable, this patch must be replaced since the
card does support more features than what is listed below.
fbl
On Wed, Oct 30, 2013 at 05:00:37PM -0200, Flavio Leitner wrote:
> Provide the modes and transports supported by the hardware.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 4ef7867..8bcf167 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -3498,10 +3498,6 @@ static int e1000e_config_hwtstamp(struct e1000_adapter *adapter)
> if (!(adapter->flags & FLAG_HAS_HW_TIMESTAMP))
> return -EINVAL;
>
> - /* flags reserved for future extensions - must be zero */
> - if (config->flags)
> - return -EINVAL;
> -
> switch (config->tx_type) {
> case HWTSTAMP_TX_OFF:
> tsync_tx_ctl = 0;
> @@ -5772,6 +5768,9 @@ static int e1000_mii_ioctl(struct net_device *netdev, struct ifreq *ifr,
> return 0;
> }
>
> +#define E1000E_HWSTAMP_FLAGS_MASK (HWTSTAMP_DM_E2E | HWTSTAMP_DM_P2P |\
> + HWTSTAMP_TRANS_IEEE_802_3 |\
> + HWTSTAMP_TRANS_UDP_IPV4)
> /**
> * e1000e_hwtstamp_ioctl - control hardware time stamping
> * @netdev: network interface device structure
> @@ -5792,11 +5791,23 @@ static int e1000e_hwtstamp_ioctl(struct net_device *netdev, struct ifreq *ifr)
> {
> struct e1000_adapter *adapter = netdev_priv(netdev);
> struct hwtstamp_config config;
> + int flags_req;
> + int flags_unsup;
> int ret_val;
>
> if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
> return -EFAULT;
>
> + if (config.flags & ~HWTSTAMP_FEATURE_FLAGS_MASK)
> + return -EINVAL;
> +
> + flags_req = config.flags & HWTSTAMP_FEATURE_FLAGS_MASK;
> + flags_unsup = flags_req & ~E1000E_HWSTAMP_FLAGS_MASK;
> + if (flags_unsup) {
> + config.flags &= ~flags_unsup;
> + goto out;
> + }
> +
> adapter->hwtstamp_config = config;
>
> ret_val = e1000e_config_hwtstamp(adapter);
> @@ -5823,6 +5834,7 @@ static int e1000e_hwtstamp_ioctl(struct net_device *netdev, struct ifreq *ifr)
> break;
> }
>
> +out:
> return copy_to_user(ifr->ifr_data, &config,
> sizeof(config)) ? -EFAULT : 0;
> }
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH net-next] ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE
From: Hannes Frederic Sowa @ 2013-10-30 22:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev, fweimer
In-Reply-To: <20131030.173608.2156276556221568210.davem@davemloft.net>
On Wed, Oct 30, 2013 at 05:36:08PM -0400, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Wed, 30 Oct 2013 21:07:25 +0100
>
> > On Tue, Oct 29, 2013 at 01:04:25PM +0100, Hannes Frederic Sowa wrote:
> >> I really tried hard to find alternatives or even a way to enable
> >> the protection automatically given that at least unbound does apply
> >> IP_PMTUDISC_DONT to its sockets already. These are the reasons why I
> >> came up with the new IP_PMTUDISC_INTERFACE value:
> >
> > Sorry to bother you but I would really love to hear your feedback on my
> > reasoning so I can try to come up with a solution you would be happy with.
Thanks for the answer but I still tend to disagree:
> All I've read is that administrators cannot be relied upon to
> configure their systems properly for the requirements they have.
>
> And that is a non-argument for adding this new socket option as far as
> I'm concerned.
First of, it is pretty hard to do it correct. Before writing this patch I
thought that ip_no_pmtu_disc does not honour pmtu updates at all. But as
soon as one fragmentation needed ICMP enters the box the mtu is reduced
to pmin_mtu. This was very counterintuitive for me (I don't know if this is
actually intended). Also we honour per application settings for TCP and DCCP
sockets, but I totally understand if you take this as a non-argument.
But that is not that important. Documentation can fix this.
> "I strongly do not trust path MTU information" has a scope as small as
> a route or an interface, it doesn't go down to the socket or
> application level at all.
I still disagree here. We can prevent generating UDP fragments if we
lock the mtu on the route, I agree and somehow missed that before (even
though I already used that myself once).
DNS resolver can fallback to TCP for querying where we can honour the
path MTU because it won't do any harm and ensures connectivity.
Also for TCP the socket is matched on the whole 4-tuple and we may
fallback to a 2-tuple lookup on unconnected UDP sockets. The new socket
option would let an application programmer choose to do path mtu discovery
because it knows it will only use a connected socket. On unconnected
sockets one can specify IP_PMTUDISC_INTERFACE to suppress the path MTU
updates and always use the interface MTU without the DF-bit set.
I really am open to suggestions. The socket option could be renamed or
we can transform IP_PMTUDISC_DONT to what I think it actually should
do. Per route or interface settings to enable the acceptance of path
MTU updates per protocol would be ok, too, but more complex.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH iproute2 v2] vxlan: add ipv6 support
From: Stephen Hemminger @ 2013-10-30 23:37 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David S. Miller
In-Reply-To: <1381986228-5780-1-git-send-email-xiyou.wangcong@gmail.com>
On Wed, 16 Oct 2013 22:03:48 -0700
Cong Wang <xiyou.wangcong@gmail.com> wrote:
> The kernel already supports it, so add the support
> to iproute2 as well.
>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>
Applied
^ permalink raw reply
* Re: [patch iproute2] iplink: add support for bonding netlink
From: Stephen Hemminger @ 2013-10-30 23:46 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, fubar, vfalico, andy, vyasevic
In-Reply-To: <1382111401-1233-1-git-send-email-jiri@resnulli.us>
On Fri, 18 Oct 2013 17:50:01 +0200
Jiri Pirko <jiri@resnulli.us> wrote:
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied to the net-next-3.11 branch
^ permalink raw reply
* Re: [PATCH iproute2] tc: add cls_bpf frontend
From: Stephen Hemminger @ 2013-10-30 23:46 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, Thomas Graf
In-Reply-To: <1382960133-2240-1-git-send-email-dborkman@redhat.com>
On Mon, 28 Oct 2013 12:35:33 +0100
Daniel Borkmann <dborkman@redhat.com> wrote:
> This is the iproute2 part of the kernel patch "net: sched:
> add BPF-based traffic classifier".
>
Applied to net-next-3.11 branch
^ permalink raw reply
* RE: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
From: Du, ChangbinX @ 2013-10-31 3:06 UTC (permalink / raw)
To: Bj?rn Mork
Cc: oliver@neukum.org, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <87wqkwii4p.fsf@nemi.mork.no>
> From: Bjørn Mork [mailto:bjorn@mork.no]
> Sent: Tuesday, October 29, 2013 4:41 PM
> To: Du, ChangbinX
> Cc: oliver@neukum.org; linux-usb@vger.kernel.org; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
>
> "Du, ChangbinX" <changbinx.du@intel.com> writes:
>
> > From: "Du, Changbin" <changbinx.du@intel.com>
> >
> > In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
> > But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
> > be called which calls free_netdev(net).
>
> I am sure you are right, but I really don't see how that can happen.
>
> AFAICS, we ensure that the intfdata is set to NULL before calling
> usb_driver_release_interface() in the error cleanup in
> cdc_ncm_bind_common():
>
>
> error2:
> usb_set_intfdata(ctx->control, NULL);
> usb_set_intfdata(ctx->data, NULL);
> if (ctx->data != ctx->control)
> usb_driver_release_interface(driver, ctx->data);
> error:
> cdc_ncm_free((struct cdc_ncm_ctx *)dev->data[0]);
> dev->data[0] = 0;
> dev_info(&dev->udev->dev, "bind() failure\n");
> return -ENODEV;
>
>
> Thus we hit the test in disconnect, and usbnet_disconnect() is never
> called:
>
> static void cdc_ncm_disconnect(struct usb_interface *intf)
> {
> struct usbnet *dev = usb_get_intfdata(intf);
>
> if (dev == NULL)
> return; /* already disconnected */
>
> usbnet_disconnect(intf);
> }
>
> So we should really be OK, but we are not???? I would appreciate it if
> anyone took the time to feed me why, with a very small spoon...
>
Yes, you are right. It should not happen if cdc_ncm_disconnect is not called. But this really happened.
It produced on kernel 3.10. Here is the full panic message for you to refer. I will get a method try to
reproduce it.
[ 15.635727] BUG: Bad page state in process khubd pfn:31994
[ 15.641989] page:f3ad9280 count:0 mapcount:0 mapping:00000020 index:0x0
[ 15.649384] page flags: 0x40000000()
[ 15.670096] BUG: unable to handle kernel NULL pointer dereference at 00000078
[ 15.678078] IP: [<c24b7f5e>] usbnet_link_change+0x1e/0x80
[ 15.684120] *pde = 00000000
[ 15.687339] Oops: 0000 [#1] SMP
[ 15.690953] Modules linked in: atmel_mxt_ts vxd392 videobuf_vmalloc videobuf_core bcm_bt_lpm bcm432)
[ 15.702658] CPU: 0 PID: 573 Comm: khubd Tainted: G B W O 3.10.1+ #1
[ 15.710241] task: f27e8f30 ti: f2084000 task.ti: f2084000
[ 15.716270] EIP: 0060:[<c24b7f5e>] EFLAGS: 00010246 CPU: 0
[ 15.722396] EIP is at usbnet_link_change+0x1e/0x80
[ 15.727747] EAX: f18524c0 EBX: 00000000 ECX: f18524c0 EDX: 00000000
[ 15.734746] ESI: f18524c0 EDI: 00000000 EBP: f2085b7c ESP: f2085b70
[ 15.741746] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 15.747775] CR0: 8005003b CR2: 00000078 CR3: 02c3b000 CR4: 001007d0
[ 15.754774] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 15.761774] DR6: ffff0ff0 DR7: 00000400
[ 15.766054] Stack:
[ 15.768295] 00000000 f18524c0 c2a03818 f2085b8c c24bc69a f1852000 f1f52e00 f2085be0
[ 15.776991] c24b8d32 00000000 00000001 00000000 c2167f2c f2085bb4 c2821253 f2085bec
[ 15.785687] 00000246 00000246 f18d8088 f1f52e1c f1fce464 f1fce400 f18524c0 c28a06e0
[ 15.794376] Call Trace:
[ 15.797109] [<c24bc69a>] cdc_ncm_bind+0x3a/0x50
[ 15.802267] [<c24b8d32>] usbnet_probe+0x282/0x7d0
[ 15.807621] [<c2167f2c>] ? sysfs_new_dirent+0x6c/0x100
[ 15.813460] [<c2821253>] ? mutex_lock+0x13/0x40
[ 15.818618] [<c24bb278>] cdc_ncm_probe+0x8/0x10
[ 15.823777] [<c24e0ef7>] usb_probe_interface+0x187/0x2c0
[ 15.829811] [<c23caa8a>] ? driver_sysfs_add+0x6a/0x90
[ 15.835550] [<c23cb290>] ? __driver_attach+0x90/0x90
[ 15.841192] [<c23caf14>] driver_probe_device+0x74/0x360
[ 15.847127] [<c24e07b1>] ? usb_match_id+0x41/0x60
[ 15.852479] [<c24e081e>] ? usb_device_match+0x4e/0x90
[ 15.858219] [<c23cb290>] ? __driver_attach+0x90/0x90
[ 15.863861] [<c23cb2c9>] __device_attach+0x39/0x50
[ 15.869311] [<c23c93f4>] bus_for_each_drv+0x34/0x70
[ 15.874856] [<c23cae2b>] device_attach+0x7b/0x90
[ 15.880109] [<c23cb290>] ? __driver_attach+0x90/0x90
[ 15.885752] [<c23ca38f>] bus_probe_device+0x6f/0x90
[ 15.891298] [<c23c8a08>] device_add+0x558/0x630
[ 15.896457] [<c24e4821>] ? usb_create_ep_devs+0x71/0xd0
[ 15.902391] [<c24dd0db>] ? create_intf_ep_devs+0x4b/0x70
[ 15.908422] [<c24df2bf>] usb_set_configuration+0x4bf/0x800
[ 15.914648] [<c23cb290>] ? __driver_attach+0x90/0x90
[ 15.920292] [<c24e809b>] generic_probe+0x2b/0x90
[ 15.925546] [<c24e105c>] usb_probe_device+0x2c/0x70
[ 15.931091] [<c23caf14>] driver_probe_device+0x74/0x360
[ 15.943345] [<c2272102>] ? kobject_uevent_env+0x182/0x620
[ 15.949473] [<c2272102>] ? kobject_uevent_env+0x182/0x620
[ 15.955601] [<c23cb290>] ? __driver_attach+0x90/0x90
[ 15.961242] [<c23cb2c9>] __device_attach+0x39/0x50
[ 15.966692] [<c23c93f4>] bus_for_each_drv+0x34/0x70
[ 15.972238] [<c23cae2b>] device_attach+0x7b/0x90
[ 15.977492] [<c23cb290>] ? __driver_attach+0x90/0x90
[ 15.983135] [<c23ca38f>] bus_probe_device+0x6f/0x90
[ 15.988682] [<c23c8a08>] device_add+0x558/0x630
[ 15.993841] [<c2320b10>] ? add_device_randomness+0x60/0x70
[ 16.000069] [<c24d642f>] usb_new_device+0x1df/0x360
[ 16.005616] [<c24e81f6>] ? usb_detect_quirks+0x16/0x70
[ 16.011454] [<c24d7a9f>] hub_thread+0xd2f/0x1540
[ 16.016710] [<c20573a0>] ? finish_wait+0x60/0x60
[ 16.021965] [<c24d6d70>] ? hub_port_debounce+0x130/0x130
[ 16.027996] [<c2056f1f>] kthread+0x8f/0xa0
[ 16.032669] [<c282a237>] ret_from_kernel_thread+0x1b/0x28
[ 16.038798] [<c2056e90>] ? kthread_create_on_node+0xc0/0xc0
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2013-10-31 4:19 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Vlad Yasevich, Joe Perches
[-- Attachment #1: Type: text/plain, Size: 4940 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/bridge/br_private.h between commit 06499098a02b ("bridge: pass
correct vlan id to multicast code") from the net tree and commit
348662a1429f ("net: 8021q/bluetooth/bridge/can/ceph: Remove extern from
function prototypes") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/bridge/br_private.h
index 2e8244efb262,d1ca6d956633..000000000000
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@@ -449,44 -434,40 +434,40 @@@ int br_ioctl_deviceless_stub(struct ne
/* br_multicast.c */
#ifdef CONFIG_BRIDGE_IGMP_SNOOPING
extern unsigned int br_mdb_rehash_seq;
- extern int br_multicast_rcv(struct net_bridge *br,
- struct net_bridge_port *port,
- struct sk_buff *skb,
- u16 vid);
- extern struct net_bridge_mdb_entry *br_mdb_get(struct net_bridge *br,
- struct sk_buff *skb, u16 vid);
- extern void br_multicast_add_port(struct net_bridge_port *port);
- extern void br_multicast_del_port(struct net_bridge_port *port);
- extern void br_multicast_enable_port(struct net_bridge_port *port);
- extern void br_multicast_disable_port(struct net_bridge_port *port);
- extern void br_multicast_init(struct net_bridge *br);
- extern void br_multicast_open(struct net_bridge *br);
- extern void br_multicast_stop(struct net_bridge *br);
- extern void br_multicast_deliver(struct net_bridge_mdb_entry *mdst,
- struct sk_buff *skb);
- extern void br_multicast_forward(struct net_bridge_mdb_entry *mdst,
- struct sk_buff *skb, struct sk_buff *skb2);
- extern int br_multicast_set_router(struct net_bridge *br, unsigned long val);
- extern int br_multicast_set_port_router(struct net_bridge_port *p,
- unsigned long val);
- extern int br_multicast_toggle(struct net_bridge *br, unsigned long val);
- extern int br_multicast_set_querier(struct net_bridge *br, unsigned long val);
- extern int br_multicast_set_hash_max(struct net_bridge *br, unsigned long val);
- extern struct net_bridge_mdb_entry *br_mdb_ip_get(
- struct net_bridge_mdb_htable *mdb,
- struct br_ip *dst);
- extern struct net_bridge_mdb_entry *br_multicast_new_group(struct net_bridge *br,
- struct net_bridge_port *port, struct br_ip *group);
- extern void br_multicast_free_pg(struct rcu_head *head);
- extern struct net_bridge_port_group *br_multicast_new_port_group(
- struct net_bridge_port *port,
- struct br_ip *group,
- struct net_bridge_port_group __rcu *next,
- unsigned char state);
- extern void br_mdb_init(void);
- extern void br_mdb_uninit(void);
- extern void br_mdb_notify(struct net_device *dev, struct net_bridge_port *port,
- struct br_ip *group, int type);
+ int br_multicast_rcv(struct net_bridge *br, struct net_bridge_port *port,
- struct sk_buff *skb);
++ struct sk_buff *skb, u16 vid);
+ struct net_bridge_mdb_entry *br_mdb_get(struct net_bridge *br,
+ struct sk_buff *skb, u16 vid);
+ void br_multicast_add_port(struct net_bridge_port *port);
+ void br_multicast_del_port(struct net_bridge_port *port);
+ void br_multicast_enable_port(struct net_bridge_port *port);
+ void br_multicast_disable_port(struct net_bridge_port *port);
+ void br_multicast_init(struct net_bridge *br);
+ void br_multicast_open(struct net_bridge *br);
+ void br_multicast_stop(struct net_bridge *br);
+ void br_multicast_deliver(struct net_bridge_mdb_entry *mdst,
+ struct sk_buff *skb);
+ void br_multicast_forward(struct net_bridge_mdb_entry *mdst,
+ struct sk_buff *skb, struct sk_buff *skb2);
+ int br_multicast_set_router(struct net_bridge *br, unsigned long val);
+ int br_multicast_set_port_router(struct net_bridge_port *p, unsigned long val);
+ int br_multicast_toggle(struct net_bridge *br, unsigned long val);
+ int br_multicast_set_querier(struct net_bridge *br, unsigned long val);
+ int br_multicast_set_hash_max(struct net_bridge *br, unsigned long val);
+ struct net_bridge_mdb_entry *
+ br_mdb_ip_get(struct net_bridge_mdb_htable *mdb, struct br_ip *dst);
+ struct net_bridge_mdb_entry *
+ br_multicast_new_group(struct net_bridge *br, struct net_bridge_port *port,
+ struct br_ip *group);
+ void br_multicast_free_pg(struct rcu_head *head);
+ struct net_bridge_port_group *
+ br_multicast_new_port_group(struct net_bridge_port *port, struct br_ip *group,
+ struct net_bridge_port_group __rcu *next,
+ unsigned char state);
+ void br_mdb_init(void);
+ void br_mdb_uninit(void);
+ void br_mdb_notify(struct net_device *dev, struct net_bridge_port *port,
+ struct br_ip *group, int type);
#define mlock_dereference(X, br) \
rcu_dereference_protected(X, lockdep_is_held(&br->multicast_lock))
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ipv6: remove the unnecessary statement in find_match()
From: David Miller @ 2013-10-31 4:22 UTC (permalink / raw)
To: hannes; +Cc: duanj.fnst, netdev
In-Reply-To: <20131030211157.GA13902@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 30 Oct 2013 22:11:57 +0100
> On Wed, Oct 30, 2013 at 05:08:37PM -0400, David Miller wrote:
>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>> Date: Wed, 30 Oct 2013 15:39:26 +0800
>>
>> >
>> > After reading the function rt6_check_neigh(), we can
>> > know that the RT6_NUD_FAIL_SOFT can be returned only
>> > when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
>> > so in function find_match(), there is no need to execute
>> > the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
>> >
>> > Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>
>> Applied to net-next, thanks.
>>
>> CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
>> removal. I know we've had several bugs that only apply when
>> this option is on vs. off. We're maintaining two different
>> code paths, for really no good reason.
>
> I agree and actually thought about that yesterday. Do you think a sysctl
> is a good option?
Every distribution ships with the Kconfig option on, and no sysctl
exists currently to control it.
So I'd say it's not necessary at all, or at the very least let's have
someone come forward with a real rather than theoretical use case for
such a feature before adding it.
Actually, if RFC 4191 has the usual language like "there SHOULD be
an administrative mechanism to disable blah blah blah" I could
be convinced to add it now. Can someone take a look?
Either way it'd probably be a per-inet6_dev option, right?
^ permalink raw reply
* Re: [PATCH] bnx2: Use dev_kfree_skb_any() in bnx2_tx_int()
From: David Miller @ 2013-10-31 4:26 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: tdmackey, mchan, netdev, linux-kernel
In-Reply-To: <CAM_iQpWAbSWVeAMwhQADTwO_RdYUXfog-wG9gs4+Zek0g_5Oyg@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 30 Oct 2013 15:01:12 -0700
> On Wed, Oct 30, 2013 at 2:32 PM, David Miller <davem@davemloft.net> wrote:
>>
>> Explain to me then why other ethernet drivers implemented identically,
>> such as tg3, can use plain dev_kfree_skb() just fine?
>
> I don't think they are fine, I just don't see bug reports
> for them. At very least, I saw a same bug report for be2net too.
>
> To reproduce this bug, we need to find some one calling printk()
> within IRQ handler, which seems rare? It seems there are few
> people using hpsa driver together with netconsole.
We've had this conversation before I believe, and I absolutely do not
want to have to add IRQ safety to every ->poll() implementation.
We have to provide a softint compatible environment for this callback
to run in else everything is completely broken.
All these drivers can safely assume softirq safe locking is
sufficient, you're suggesting we need to take this hardirq safety and
I'm really not willing to allow things to go that far. A lot of
effort has been expended precisely to avoid that kind of overhead and
cost.
^ permalink raw reply
* Re: [PATCH 1/2] net: if_arp: add ARPHRD_RAWIP type
From: David Miller @ 2013-10-31 4:27 UTC (permalink / raw)
To: marcel; +Cc: jukka.rissanen, netdev
In-Reply-To: <C93A6A6E-D5BF-4008-8B4B-496A551DF70F@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Wed, 30 Oct 2013 23:26:37 +0100
> Posting them on netdev is mainly for checking that the changes we
> have to make outside the Bluetooth subsystem are in sync.
Changes without use context and examples cannot be reviewed.
You have to provide those example users here, not on some external
list for us to look at.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE
From: David Miller @ 2013-10-31 4:29 UTC (permalink / raw)
To: hannes; +Cc: netdev, fweimer
In-Reply-To: <20131030225851.GB13902@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 30 Oct 2013 23:58:51 +0100
> DNS resolver can fallback to TCP for querying where we can honour the
> path MTU because it won't do any harm and ensures connectivity.
>
> Also for TCP the socket is matched on the whole 4-tuple and we may
> fallback to a 2-tuple lookup on unconnected UDP sockets. The new socket
> option would let an application programmer choose to do path mtu discovery
> because it knows it will only use a connected socket. On unconnected
> sockets one can specify IP_PMTUDISC_INTERFACE to suppress the path MTU
> updates and always use the interface MTU without the DF-bit set.
This still sounds like a route scope policy with two binary states,
one for connected sockets and one for unconnected ones.
^ permalink raw reply
* Re: 3.12-rc7 regression - network panic from ipv6
From: David Miller @ 2013-10-31 4:35 UTC (permalink / raw)
To: mroos; +Cc: steffen.klassert, hannes, linux-kernel, netdev
In-Reply-To: <alpine.SOC.1.00.1310302340170.24516@math.ut.ee>
From: mroos@linux.ee
Date: Wed, 30 Oct 2013 23:41:09 +0200 (EET)
>> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> Works fine, thanks!
>
> Tested-by: Meelis Roos <mroos@linux.ee>
Thanks for reporting the bug and testing the fix.
^ permalink raw reply
* Re: [net-next PATCH] net: codel: Avoid undefined behavior from signed overflow
From: Paul E. McKenney @ 2013-10-31 4:55 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Jesper Dangaard Brouer, netdev, Eric Dumazet, Dave Taht
In-Reply-To: <1383164352.1601.38.camel@bwh-desktop.uk.level5networks.com>
On Wed, Oct 30, 2013 at 08:19:12PM +0000, Ben Hutchings wrote:
> On Wed, 2013-10-30 at 13:13 -0700, Paul E. McKenney wrote:
> > On Wed, Oct 30, 2013 at 07:35:48PM +0000, Ben Hutchings wrote:
> > > On Wed, 2013-10-30 at 18:23 +0100, Jesper Dangaard Brouer wrote:
> > > > From: Jesper Dangaard Brouer <netoptimizer@brouer.com>
> > > >
> > > > As described in commit 5a581b367 (jiffies: Avoid undefined
> > > > behavior from signed overflow), according to the C standard
> > > > 3.4.3p3, overflow of a signed integer results in undefined
> > > > behavior.
> > > [...]
> > >
> > > According to the real processors that Linux runs on, signed arithmetic
> > > uses 2's complement representation and overflow wraps accordingly. And
> > > we rely on that behaviour in many places, so we use
> > > '-fno-strict-overflow' to tell gcc not to assume we avoid signed
> > > overflow. (There is also '-fwrapv' which tells gcc to assume the
> > > processor behaves this way, but shouldn't it already know how the target
> > > machine works?)
> >
> > We should still fix them as we come across them. There are a few types
> > of loops where '-fno-strict-overflow' results in more instructions
> > being generated.
>
> I realise there's an opportunity for optimisation, but if these cases
> are fixed on an ad-hoc basis, how will we know we're ready to make the
> switch?
I believe that there are some tools that check for code that relies on
signed integer overflow. Probably not yet up to dealing with the
kernel. In the meantime, fixing them as we come across them is not
a bad approach.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH v2 00/19] Enable various Renesas drivers on all ARM platforms
From: Simon Horman @ 2013-10-31 5:52 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev, Wolfram Sang, Linus Walleij, Guennadi Liakhovetski,
Thierry Reding, linux-mtd, linux-i2c, Vinod Koul, Joerg Roedel,
linux-sh, Magnus Damm, Eduardo Valentin, Tomi Valkeinen,
linux-serial, linux-input, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard, linux-media, linux-pwm,
Samuel Ortiz, linux-pm, Ian Molton, Mark Brown, linux-arm-kernel,
Ser
In-Reply-To: <1383086274-11049-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Tue, Oct 29, 2013 at 11:37:35PM +0100, Laurent Pinchart wrote:
> Hello,
>
> This patch series, based on v3.12-rc7, prepares various Renesas drivers
> for migration to multiplatform kernels by enabling their compilation or
> otherwise fixing them on all ARM platforms. The patches are pretty
> straightforward and are described in their commit message.
>
> Changes since v1:
>
> - The drivers can also be selected when COMPILE_TEST is enabled, regardless of
> the architecture. This should provide a good compromise between wide build
> test coverage and not clobbering configuration with drivers useless on
> non-SuperH, non-ARM platforms.
>
> - DMA configuration is now unconditional in patch 08/19
>
> I'd like to get all these patches merged in v3.14. As they will need to go
> through their respective subsystems' trees, I would appreciate if all
> maintainers involved could notify me when they merge patches from this series
> in their tree to help me tracking the merge status. I don't plan to send pull
> requests individually for these patches, and I will repost patches
> individually if changes are requested during review.
>
> If you believe the issue should be solved in a different way please reply to
> the cover letter to let other maintainers chime in.
All patches, including the v3 ones present in the thread at this time:
Acked-by: Simon Horman <horms@verge.net.au>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Eduardo Valentin <eduardo.valentin@ti.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
> Cc: Ian Molton <ian@mnementh.co.uk>
> Cc: iommu@lists.linux-foundation.org
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: Samuel Ortiz <samuel@sortiz.org>
> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: dmaengine@vger.kernel.org
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-i2c@vger.kernel.org
> Cc: linux-input@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> Cc: linux-mmc@vger.kernel.org
> Cc: linux-mtd@lists.infradead.org
> Cc: linux-pm@vger.kernel.org
> Cc: linux-pwm@vger.kernel.org
> Cc: linux-serial@vger.kernel.org
> Cc: linux-spi@vger.kernel.org
> Cc: netdev@vger.kernel.org
>
> Laurent Pinchart (19):
> serial: sh-sci: Enable the driver on all ARM platforms
> DMA: shdma: Enable the driver on all ARM platforms
> i2c: sh_mobile: Enable the driver on all ARM platforms
> input: sh_keysc: Enable the driver on all ARM platforms
> iommu: shmobile: Enable the driver on all ARM platforms
> i2c: rcar: Enable the driver on all ARM platforms
> v4l: sh_vou: Enable the driver on all ARM platforms
> mmc: sdhi: Enable the driver on all ARM platforms
> mmc: sh_mmcif: Enable the driver on all ARM platforms
> mtd: sh_flctl: Enable the driver on all ARM platforms
> net: sh_eth: Set receive alignment correctly on all ARM platforms
> irda: sh_irda: Enable the driver on all ARM platforms
> pinctrl: sh-pfc: Enable the driver on all ARM platforms
> pwm: pwm-renesas-tpu: Enable the driver on all ARM platforms
> sh: intc: Enable the driver on all ARM platforms
> spi: sh_msiof: Enable the driver on all ARM platforms
> spi: sh_hspi: Enable the driver on all ARM platforms
> thermal: rcar-thermal: Enable the driver on all ARM platforms
> fbdev: sh-mobile-lcdcfb: Enable the driver on all ARM platforms
>
> drivers/dma/sh/Kconfig | 2 +-
> drivers/dma/sh/shdmac.c | 6 +++---
> drivers/i2c/busses/Kconfig | 4 ++--
> drivers/input/keyboard/Kconfig | 2 +-
> drivers/iommu/Kconfig | 2 +-
> drivers/media/platform/Kconfig | 2 +-
> drivers/mmc/host/Kconfig | 4 ++--
> drivers/mmc/host/tmio_mmc_dma.c | 4 +---
> drivers/mtd/nand/Kconfig | 2 +-
> drivers/net/ethernet/renesas/sh_eth.c | 2 +-
> drivers/net/ethernet/renesas/sh_eth.h | 2 +-
> drivers/net/irda/Kconfig | 2 +-
> drivers/pinctrl/Makefile | 2 +-
> drivers/pinctrl/sh-pfc/Kconfig | 2 +-
> drivers/pwm/Kconfig | 2 +-
> drivers/sh/intc/Kconfig | 2 +-
> drivers/spi/Kconfig | 4 ++--
> drivers/thermal/Kconfig | 2 +-
> drivers/tty/serial/Kconfig | 2 +-
> drivers/video/Kconfig | 6 +++---
> 20 files changed, 27 insertions(+), 29 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
>
>
> _______________________________________________
> 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 net v2 2/3] r8152: modify the tx flow
From: hayeswang @ 2013-10-31 5:52 UTC (permalink / raw)
To: 'David Miller'
Cc: netdev, 'nic_swsd', linux-kernel, linux-usb
In-Reply-To: <20131030.170441.2031802071448773661.davem@davemloft.net>
From: David Miller [mailto:davem@davemloft.net]
Sent: Thursday, October 31, 2013 5:05 AM
>
> From: Hayes Wang <hayeswang@realtek.com>
> Date: Wed, 30 Oct 2013 15:13:39 +0800
[...]
> Basically, your driver will now queue up to 1,000 packets onto
> this tx_queue list, because that is what tx_queue_len will be
> for alloc_etherdev() allocated network devices.
>
> In my previous reply to you about this patch, I asked you to
> quantify and study the effects of using a limit of 60. I said
> that 60 might be too large.
>
> You've responded by removing the limit completely, which is exactly
> the opposite of what I've asked you to do. Why did you do this?
Excuse me. My question is that the original code doesn't stop the tx queue
either, so I don't understand why it is necessary for this patch.
I don't say I wouldn't find the suitable value for the tx queue length.
I feel I need some time to think how to find the reasonable value. And
I don't hope it influences the submission of the other patches, so I
remove it first. Or, may I submit the other two patches first?
^ permalink raw reply
* Re: [PATCH] ipv6: remove the unnecessary statement in find_match()
From: Duan Jiong @ 2013-10-31 6:02 UTC (permalink / raw)
To: David Miller; +Cc: hannes, netdev
In-Reply-To: <20131031.002234.45924350853188128.davem@davemloft.net>
于 2013年10月31日 12:22, David Miller 写道:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Wed, 30 Oct 2013 22:11:57 +0100
>
>> On Wed, Oct 30, 2013 at 05:08:37PM -0400, David Miller wrote:
>>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>> Date: Wed, 30 Oct 2013 15:39:26 +0800
>>>
>>>>
>>>> After reading the function rt6_check_neigh(), we can
>>>> know that the RT6_NUD_FAIL_SOFT can be returned only
>>>> when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
>>>> so in function find_match(), there is no need to execute
>>>> the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
>>>>
>>>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>>
>>> Applied to net-next, thanks.
>>>
>>> CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
>>> removal. I know we've had several bugs that only apply when
>>> this option is on vs. off. We're maintaining two different
>>> code paths, for really no good reason.
>>
>> I agree and actually thought about that yesterday. Do you think a sysctl
>> is a good option?
>
> Every distribution ships with the Kconfig option on, and no sysctl
> exists currently to control it.
>
> So I'd say it's not necessary at all, or at the very least let's have
> someone come forward with a real rather than theoretical use case for
> such a feature before adding it.
>
> Actually, if RFC 4191 has the usual language like "there SHOULD be
> an administrative mechanism to disable blah blah blah" I could
> be convinced to add it now. Can someone take a look?
It seems that there is no such an administrative mechanism in RFC 4191.
By the way, if the sysctl is used, we are still maintaining two different
code paths, isn't it? so i think David's idea is good.
Thanks,
Duan
>
> Either way it'd probably be a per-inet6_dev option, right?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v3] sh_eth: check platform data pointer
From: Simon Horman @ 2013-10-31 6:05 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, nobuhiro.iwamatsu.yj, linux-sh, 'David Miller'
In-Reply-To: <201310302330.19491.sergei.shtylyov@cogentembedded.com>
[ Cc Dave Miller ]
On Wed, Oct 30, 2013 at 11:30:19PM +0300, Sergei Shtylyov wrote:
> Check the platform data pointer before dereferencing it and error out of the
> probe() method if it's NULL.
>
> This has additional effect of preventing kernel oops with outdated platform data
> containing zero PHY address instead (such as on SolutionEngine7710).
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Dave, is it too late to for this to be considered for net-next?
>
> ---
> This patch is against David Miller's 'net-next.git' repo.
>
> Changes in version 3:
> - refreshed the patch.
>
> Changes in version 2:
> - refreshed the patch.
>
> drivers/net/ethernet/renesas/sh_eth.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
> ===================================================================
> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
> +++ net-next/drivers/net/ethernet/renesas/sh_eth.c
> @@ -2663,6 +2663,12 @@ static int sh_eth_drv_probe(struct platf
> pm_runtime_enable(&pdev->dev);
> pm_runtime_resume(&pdev->dev);
>
> + if (!pd) {
> + dev_err(&pdev->dev, "no platform data\n");
> + ret = -EINVAL;
> + goto out_release;
> + }
> +
> /* get PHY ID */
> mdp->phy_id = pd->phy;
> mdp->phy_interface = pd->phy_interface;
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Linuxptp-devel] RFC [PATCH 2/3] PTP: use flags to request HW features
From: Richard Cochran @ 2013-10-31 7:12 UTC (permalink / raw)
To: linuxptp-devel, netdev; +Cc: Ben Hutchings
In-Reply-To: <20131030214841.GZ13373@plex.lan>
On Wed, Oct 30, 2013 at 07:48:41PM -0200, Flavio Leitner wrote:
> On Wed, Oct 30, 2013 at 05:00:36PM -0200, Flavio Leitner wrote:
> > Currently the user space can't tell which delay mechanism
> > (E2E/P2P) or transport is needed in the ioctl(). Therefore,
> > PTP silently fails when the hardware doesn't support a
> > certain delay mechanism or transport.
[ For netdev readers, the text below repeats what I posted to the
linuxptp-devel list. ]
SIOCSHWTSTAMP is bad enough already. Let's not make it even
uglier. ETHTOOL is a better place for this kind of thing. The
ethtool_ts_info has plenty of reserved fields, and drivers could
use them to advertise these capabilities without the risk of
breaking user space.
We already check each port's capabilities using the ethtool ioctl.
It makes perfect sense to have two calls. First, tell me what is
available, then, I'll tell you what I want. That is easy.
In contrast, the closed loop feedback of SIOCSHWTSTAMP is really
awful. The whole rx_filter field is designed around the inadequacies
of an early intel card, and the choices are obsolete and mostly
useless. There isn't even any mention of pdelay. Ptp4l is already
bad enough with the filter1, filter2 probing. Let's just leave that
ioctl alone.
On Wed, Oct 30, 2013 at 07:46:58PM -0200, Flavio Leitner wrote:
> What about the transport?
I suggest offering the following bits in the ethtool rx|tx_reserved
fields:
TS_SYNC (1<<0) /* silly, PTP is not possible without this */
TS_DELAY_REQ (1<<1)
TS_PDELAY_REQ (1<<2)
TS_PDELAY_RESP (1<<3)
TS_ON_LAYER2 (1<<4)
TS_ON_IPV4 (1<<5)
TS_ON_IPV6 (1<<6)
> And feature combination?
My goal for linuxptp (and for the PHC subsystem) is to offer a kind of
reference implementation. I have no inclination to support every last
broken hardware out there. However, I agree that we should try to
support poorly designed cards if we can, but not at the price of
making ugly interfaces for the everyone.
Drivers with weird restrictions (for example, supports PDelay_Req but
only on IPv6) will have to just advertise one working combination.
The intel ixp465 is an example of design that we cannot ever support
in linuxptp. It can time stamp *either* the master role's events or
the slave role's events, but not both. Brilliant.
[ This chip is thankfully now obsolete, but the time stamping IP core
found its way into the phc_gbe, but with the worst mistakes
corrected. ]
Thanks,
Richard
^ 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