linux-next: manual merge of the cgroup tree with the net-next tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the cgroup tree got a conflict in:

  include/linux/cgroup.h
  kernel/cgroup.c

between commit:

  bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup")

from the net-next tree and commit:

  f176ae3a5df6 ("cgroup: introduce cgroup namespaces")

from the cgroup tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/linux/cgroup.h
index 322a28482745,6d0992f3543d..
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@@ -577,45 -569,47 +569,88 @@@ static inline int cgroup_init(void) { r
  
  #endif /* !CONFIG_CGROUPS */
  
 +/*
 + * sock->sk_cgrp_data handling.  For more info, see sock_cgroup_data
 + * definition in cgroup-defs.h.
 + */
 +#ifdef CONFIG_SOCK_CGROUP_DATA
 +
 +#if defined(CONFIG_CGROUP_NET_PRIO) || defined(CONFIG_CGROUP_NET_CLASSID)
 +extern spinlock_t cgroup_sk_update_lock;
 +#endif
 +
 +void cgroup_sk_alloc_disable(void);
 +void cgroup_sk_alloc(struct sock_cgroup_data *skcd);
 +void cgroup_sk_free(struct sock_cgroup_data *skcd);
 +
 +static inline struct cgroup *sock_cgroup_ptr(struct sock_cgroup_data *skcd)
 +{
 +#if defined(CONFIG_CGROUP_NET_PRIO) || defined(CONFIG_CGROUP_NET_CLASSID)
 +  unsigned long v;
 +
 +  /*
 +   * @skcd->val is 64bit but the following is safe on 32bit too as we
 +   * just need the lower ulong to be written and read atomically.
 +   */
 +  v = READ_ONCE(skcd->val);
 +
 +  if (v & 1)
 +  return _dfl_root.cgrp;
 +
 +  return (struct cgroup *)(unsigned long)v ?: _dfl_root.cgrp;
 +#else
 +  return (struct cgroup *)(unsigned long)skcd->val;
 +#endif
 +}
 +
 +#else /* CONFIG_CGROUP_DATA */
 +
 +static inline void cgroup_sk_alloc(struct sock_cgroup_data *skcd) {}
 +static inline void cgroup_sk_free(struct sock_cgroup_data *skcd) {}
 +
 +#endif/* CONFIG_CGROUP_DATA */
 +
+ struct cgroup_namespace {
+   atomic_tcount;
+   struct ns_commonns;
+   struct user_namespace   *user_ns;
+   struct css_set  *root_cset;
+ };
+ 
+ extern struct cgroup_namespace init_cgroup_ns;
+ 
+ #ifdef CONFIG_CGROUPS
+ 
+ void free_cgroup_ns(struct cgroup_namespace *ns);
+ 
+ struct cgroup_namespace *
+ copy_cgroup_ns(unsigned long flags, struct user_namespace *user_ns,
+  struct cgroup_namespace *old_ns);
+ 
+ char *cgroup_path(struct cgroup *cgrp, char *buf, size_t buflen);
+ 
+ #else /* !CONFIG_CGROUPS */
+ 
+ static inline void free_cgroup_ns(struct cgroup_namespace *ns) { }
+ static inline struct cgroup_namespace *
+ copy_cgroup_ns(unsigned long flags, struct user_namespace *user_ns,
+  struct cgroup_namespace *old_ns)
+ {
+   return old_ns;
+ }
+ 
+ #endif /* !CONFIG_CGROUPS */
+ 
+ static inline void get_cgroup_ns(struct cgroup_namespace *ns)
+ {
+   if (ns)
+   atomic_inc(>count);
+ }
+ 
+ static inline void put_cgroup_ns(struct cgroup_namespace *ns)
+ {
+   if (ns && atomic_dec_and_test(>count))
+   free_cgroup_ns(ns);
+ }
+ 
  #endif /* _LINUX_CGROUP_H */
diff --cc kernel/cgroup.c
index fe95970b1f79,7eb1d9de2afa..
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@@ -57,8 -57,11 +57,12 @@@
  #include  /* TODO: replace with more sophisticated array */
  #include 
  #include 
+ #include 
+ #include 
+ #include 
+ 
  #include 
 +#include 
  
  /*
   * pidlists linger the following amount before being destroyed.  The goal
@@@ -5839,59 -5900,134 +5901,187 @@@ struct cgroup *cgroup_get_from_path(con
  }
  EXPORT_SYMBOL_GPL(cgroup_get_from_path);
  
 +/*
 + * sock->sk_cgrp_data handling.  For more info, see sock_cgroup_data
 + * definition in cgroup-defs.h.
 + */
 +#ifdef CONFIG_SOCK_CGROUP_DATA
 +
 +#if defined(CONFIG_CGROUP_NET_PRIO) || defined(CONFIG_CGROUP_NET_CLASSID)
 +
 +DEFINE_SPINLOCK(cgroup_sk_update_lock);
 +static bool cgroup_sk_alloc_disabled __read_mostly;
 +
 +void cgroup_sk_alloc_disable(void)
 +{
 +  if (cgroup_sk_alloc_disabled)
 +  return;
 +  pr_info("cgroup: disabling cgroup2 socket matching due to net_prio or 
net_cls activation\n");
 +  cgroup_sk_alloc_disabled = true;
 +}
 +
 +#else
 +
 +#define cgroup_sk_alloc_disabled  false
 +
 +#endif
 +
 +void cgroup_sk_alloc(struct sock_cgroup_data *skcd)
 +{
 +  if (cgroup_sk_alloc_disabled)
 +  return;
 +
 +  rcu_read_lock();
 +
 +  while (true) {
 +  struct css_set *cset;
 +
 +  cset = task_css_set(current);
 +  if (likely(cgroup_tryget(cset->dfl_cgrp))) {
 +  skcd->val = (unsigned long)cset->dfl_cgrp;
 +  break;
 +  }
 +  cpu_relax();
 +  }
 +
 +  rcu_read_unlock();
 +}
 +
 +void cgroup_sk_free(struct sock_cgroup_data *skcd)
 +{
 +  cgroup_put(sock_cgroup_ptr(skcd));
 +}
 +
 +#endif/* CONFIG_SOCK_CGROUP_DATA */
 +

Re: [PATCH 5/9] ipw2x00: sdhci-pci: use to_pci_dev()

[Kalle Valo]

Geliang Tang  writes:

> Use to_pci_dev() instead of open-coding it.
>
> Signed-off-by: Geliang Tang 

The title is wrong, it should be just "ipw2x00: use to_pci_dev()".

And please state clearly to what tree you are planning to submit these.
I only saw this patch 5, not rest of the patches, so I have no clue
what's going to happen with this patchset. Please resend.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wlcore/wl12xx: spi: fix NULL pointer dereference (Oops)

[Kalle Valo]

> Fix the below Oops when trying to modprobe wlcore_spi.
> The oops occurs because the wl1271_power_{off,on}()
> function doesn't check the power() function pointer.
> 
> [   23.401447] Unable to handle kernel NULL pointer dereference at
> virtual address 
> [   23.409954] pgd = c0004000
> [   23.412922] [] *pgd=
> [   23.416693] Internal error: Oops: 8007 [#1] SMP ARM
> [   23.422168] Modules linked in: wl12xx wlcore mac80211 cfg80211
> musb_dsps musb_hdrc usbcore usb_common snd_soc_simple_card evdev joydev
> omap_rng wlcore_spi snd_soc_tlv320aic23_i2c rng_core snd_soc_tlv320aic23
> c_can_platform c_can can_dev snd_soc_davinci_mcasp snd_soc_edma
> snd_soc_omap omap_wdt musb_am335x cpufreq_dt thermal_sys hwmon
> [   23.453253] CPU: 0 PID: 36 Comm: kworker/0:2 Not tainted
> 4.2.0-2-g951efee-dirty #233
> [   23.461720] Hardware name: Generic AM33XX (Flattened Device Tree)
> [   23.468123] Workqueue: events request_firmware_work_func
> [   23.473690] task: de32efc0 ti: de4ee000 task.ti: de4ee000
> [   23.479341] PC is at 0x0
> [   23.482112] LR is at wl12xx_set_power_on+0x28/0x124 [wlcore]
> [   23.488074] pc : [<>]lr : []psr: 6013
> [   23.488074] sp : de4efe50  ip : 0002  fp : 
> [   23.500162] r10: de7cdd00  r9 : dc848800  r8 : bf27af00
> [   23.505663] r7 : bf27a1a8  r6 : dcbd8a80  r5 : dce0e2e0  r4 :
> dce0d2e0
> [   23.512536] r3 :   r2 :   r1 : 0001  r0 :
> dc848810
> [   23.519412] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> Segment kernel
> [   23.527109] Control: 10c5387d  Table: 9cb78019  DAC: 0015
> [   23.533160] Process kworker/0:2 (pid: 36, stack limit = 0xde4ee218)
> [   23.539760] Stack: (0xde4efe50 to 0xde4f)
> 
> [...]
> 
> [   23.665030] [] (wl12xx_set_power_on [wlcore]) from
> [] (wlcore_nvs_cb+0x118/0xa4c [wlcore])
> [   23.675604] [] (wlcore_nvs_cb [wlcore]) from []
> (request_firmware_work_func+0x30/0x58)
> [   23.685784] [] (request_firmware_work_func) from
> [] (process_one_work+0x1b4/0x4b4)
> [   23.695591] [] (process_one_work) from []
> (worker_thread+0x3c/0x4a4)
> [   23.704124] [] (worker_thread) from []
> (kthread+0xd4/0xf0)
> [   23.711747] [] (kthread) from []
> (ret_from_fork+0x14/0x3c)
> [   23.719357] Code: bad PC value
> [   23.722760] ---[ end trace 981be8510db9b3a9 ]---
> 
> Prevent oops by validationg power() pointer value before
> calling the function.
> 
> Signed-off-by: Uri Mashiach 
> Cc: sta...@vger.kernel.org
> Acked-by: Igor Grinberg 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: prism54: fix checks for dma mapping errors

[Kalle Valo]

> prism54 checks for dma mapping errors by comparison returned address
> with zero, while pci_dma_mapping_error() should be used.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] unix: properly account for FDs passed over unix sockets

[One Thousand Gnomes]

On Thu, 31 Dec 2015 08:12:53 +0100
Willy Tarreau  wrote:

> On Thu, Dec 31, 2015 at 03:08:53PM +0900, Tetsuo Handa wrote:
> > Willy Tarreau wrote:
> > > On Wed, Dec 30, 2015 at 09:58:42AM +0100, Hannes Frederic Sowa wrote:
> > > > The MSG_PEEK code should not be harmful and the patch is good as is. I 
> > > > first understood from the published private thread, that it is possible 
> > > > for a program to exceed the rlimit of fds. But the DoS is only by 
> > > > keeping the fds in flight and not attaching them to any program.
> > > 
> > > Exactly. The real issue is when these FDs become very expensive such as
> > > pipes full of data.
> > > 
> > 
> > As you wrote how to abuse this vulnerability which exists in Linux 2.0
> > and later kernel, I quote a short description from private thread.
> > 
> >   "an unprivileged user consumes all file descriptors so that other
> >   unprivileged user cannot work" and "an unprivileged user consumes all
> >   kernel memory so that the OOM killer kills almost all processes before
> >   the culprit process is killed (CVE-2013-4312)".
> > 
> > Reported-by: Tetsuo Handa 
> > Mitigates: CVE-2013-4312 (Linux 2.0+)
> 
> Well I didn't reveal any secret as it was publicly reported first
> in 2010, it's only that Mark sent us the proof of concept exploit
> on the security list recently :-)

There were demonstrations of this bug posted for BSD unixes before Linux
even existed. It and "run the box out of socket buffers" are older than
Linux 8)

Alan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next] ppp: rtnetlink device handling

[Guillaume Nault]

On Thu, Dec 31, 2015 at 12:01:40PM +0100, Sedat Dilek wrote:
> On Thu, Dec 31, 2015 at 11:41 AM, Guillaume Nault  
> wrote:
> > On Thu, Dec 31, 2015 at 08:46:59AM +0100, Sedat Dilek wrote:
> >> Hi Guillaume,
> >>
> >> can you explain why you moved ppp to rtnetlink device handling?
> >> Benefits, etc.?
> >>
> > The objective is to bring all the flexibility of rtnetlink device
> > creation to ppp interfaces. This is particularly useful for Network
> > Access Servers which need to define device properties at creation
> > time. My use case includes setting device name and netns, which is
> > impossible with the ioctl-based interface without generating transient
> > effects.
> >
> 
> What do you mean by "my use-case"?
> Example?
> 
A NAS that terminates connections of PPP clients (usually transported
over PPPoE or L2TP). Clients may have different routing needs so each
PPP device is created in the appropriate network namespace. Without
rtnl the PPP device has to be created in the PPPoE/L2TP server's
namespace and then moved to the client's one. With rtnl, the PPP device
can be directly created in the right namespace.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next] ppp: rtnetlink device handling

[Guillaume Nault]

On Thu, Dec 31, 2015 at 08:46:59AM +0100, Sedat Dilek wrote:
> Hi Guillaume,
> 
> can you explain why you moved ppp to rtnetlink device handling?
> Benefits, etc.?
> 
The objective is to bring all the flexibility of rtnetlink device
creation to ppp interfaces. This is particularly useful for Network
Access Servers which need to define device properties at creation
time. My use case includes setting device name and netns, which is
impossible with the ioctl-based interface without generating transient
effects.

> Does anything change when using NetworkManager/ModemManager/pppd for
> my network setup/handling (here: Ubuntu/precise AMD64)?
> 
No. The ioctl-based ABI remains unchanged, so programs using it won't
see any difference. The rtnl ABI only brings a new way to create PPP
devices.

Whether a ppp device is created with the ioctl or rtnl ABI doesn't
change its behaviour. In particular ppp devices created with rtnl can
still be configured with the old ioctls. The only difference I can
think of, is that managing ppp devices with rtnl allows a user to
remove it with "ip link del", while this is not possible with ppp
devices created with ioctl.

> Thanks in advance.
> 
You're welcome.

Guillaume
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next] ixgbe: Extend trust to allow guest to set unicast address

[Chas Williams]

When running certain routing protocols like VRRP, VF guests need the
ability to set the unicast address of the interface.  Extend the new ndo
trust feature to let the hypervisor trust a guest to set/update its own
unicast address.

Signed-off-by: Chas Williams <3ch...@gmail.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index eeff3d0..63cff17 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -887,7 +887,7 @@ static int ixgbe_set_vf_mac_addr(struct ixgbe_adapter 
*adapter,
return -1;
}
 
-   if (adapter->vfinfo[vf].pf_set_mac &&
+   if (adapter->vfinfo[vf].pf_set_mac && !adapter->vfinfo[vf].trusted &&
!ether_addr_equal(adapter->vfinfo[vf].vf_mac_addresses, new_mac)) {
e_warn(drv,
   "VF %d attempted to override administratively set MAC 
address\n"
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath9k_htc: fix handling return value of ath9k_hw_calibrate

[Kalle Valo]

Andrzej Hajda  writes:

> The function can return negative values in case of error.
> Its result should be then tested for such case.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>
> Signed-off-by: Andrzej Hajda 

Applied to ath.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] vhost: basic device IOTLB support

[Michael S. Tsirkin]

On Thu, Dec 31, 2015 at 03:13:45PM +0800, Jason Wang wrote:
> This patch tries to implement an device IOTLB for vhost. This could be
> used with for co-operation with userspace(qemu) implementation of
> iommu for a secure DMA environment in guest.
> 
> The idea is simple. When vhost meets an IOTLB miss, it will request
> the assistance of userspace to do the translation, this is done
> through:
> 
> - Fill the translation request in a preset userspace address (This
>   address is set through ioctl VHOST_SET_IOTLB_REQUEST_ENTRY).
> - Notify userspace through eventfd (This eventfd was set through ioctl
>   VHOST_SET_IOTLB_FD).
> 
> When userspace finishes the translation, it will update the vhost
> IOTLB through VHOST_UPDATE_IOTLB ioctl. Userspace is also in charge of
> snooping the IOTLB invalidation of IOMMU IOTLB and use
> VHOST_UPDATE_IOTLB to invalidate the possible entry in vhost.
> 
> For simplicity, IOTLB was implemented with a simple hash array. The
> index were calculated from IOVA page frame number which can only works
> at PAGE_SIZE level.
> 
> An qemu implementation (for reference) is available at:
> g...@github.com:jasowang/qemu.git iommu
> 
> TODO & Known issues:
> 
> - read/write permission validation was not implemented.
> - no feature negotiation.
> - VHOST_SET_MEM_TABLE is not reused (maybe there's a chance).
> - working at PAGE_SIZE level, don't support large mappings.
> - better data structure for IOTLB instead of simple hash array.
> - better API, e.g using mmap() instead of preset userspace address.
> 
> Signed-off-by: Jason Wang 

Interesting. I'm working on a slightly different approach
which is direct vt-d support in vhost.
This one has the advantage of being more portable.

> ---
>  drivers/vhost/net.c|   2 +-
>  drivers/vhost/vhost.c  | 190 
> -
>  drivers/vhost/vhost.h  |  13 
>  include/uapi/linux/vhost.h |  26 +++
>  4 files changed, 229 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 9eda69e..a172be9 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -1083,7 +1083,7 @@ static long vhost_net_ioctl(struct file *f, unsigned 
> int ioctl,
>   r = vhost_dev_ioctl(>dev, ioctl, argp);
>   if (r == -ENOIOCTLCMD)
>   r = vhost_vring_ioctl(>dev, ioctl, argp);
> - else
> + else if (ioctl != VHOST_UPDATE_IOTLB)
>   vhost_net_flush(n);
>   mutex_unlock(>dev.mutex);
>   return r;
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index eec2f11..729fe05 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -113,6 +113,11 @@ static void vhost_init_is_le(struct vhost_virtqueue *vq)
>  }
>  #endif /* CONFIG_VHOST_CROSS_ENDIAN_LEGACY */
>  
> +static inline int vhost_iotlb_hash(u64 iova)
> +{
> + return (iova >> PAGE_SHIFT) & (VHOST_IOTLB_SIZE - 1);
> +}
> +
>  static void vhost_poll_func(struct file *file, wait_queue_head_t *wqh,
>   poll_table *pt)
>  {
> @@ -384,8 +389,14 @@ void vhost_dev_init(struct vhost_dev *dev,
>   dev->memory = NULL;
>   dev->mm = NULL;
>   spin_lock_init(>work_lock);
> + spin_lock_init(>iotlb_lock);
> + mutex_init(>iotlb_req_mutex);
>   INIT_LIST_HEAD(>work_list);
>   dev->worker = NULL;
> + dev->iotlb_request = NULL;
> + dev->iotlb_ctx = NULL;
> + dev->iotlb_file = NULL;
> + dev->pending_request.flags.type = VHOST_IOTLB_INVALIDATE;
>  
>   for (i = 0; i < dev->nvqs; ++i) {
>   vq = dev->vqs[i];
> @@ -393,12 +404,17 @@ void vhost_dev_init(struct vhost_dev *dev,
>   vq->indirect = NULL;
>   vq->heads = NULL;
>   vq->dev = dev;
> + vq->iotlb_request = NULL;
>   mutex_init(>mutex);
>   vhost_vq_reset(dev, vq);
>   if (vq->handle_kick)
>   vhost_poll_init(>poll, vq->handle_kick,
>   POLLIN, dev);
>   }
> +
> + init_completion(>iotlb_completion);
> + for (i = 0; i < VHOST_IOTLB_SIZE; i++)
> + dev->iotlb[i].flags.valid = VHOST_IOTLB_INVALID;
>  }
>  EXPORT_SYMBOL_GPL(vhost_dev_init);
>  
> @@ -940,9 +956,10 @@ long vhost_dev_ioctl(struct vhost_dev *d, unsigned int 
> ioctl, void __user *argp)
>  {
>   struct file *eventfp, *filep = NULL;
>   struct eventfd_ctx *ctx = NULL;
> + struct vhost_iotlb_entry entry;
>   u64 p;
>   long r;
> - int i, fd;
> + int index, i, fd;
>  
>   /* If you are not the owner, you can become one */
>   if (ioctl == VHOST_SET_OWNER) {
> @@ -1008,6 +1025,80 @@ long vhost_dev_ioctl(struct vhost_dev *d, unsigned int 
> ioctl, void __user *argp)
>   if (filep)
>   fput(filep);
>   break;
> + case VHOST_SET_IOTLB_FD:
> +   

Re: [net-next] ppp: rtnetlink device handling

[Sedat Dilek]

On Thu, Dec 31, 2015 at 12:01 PM, Sedat Dilek <sedat.di...@gmail.com> wrote:
> On Thu, Dec 31, 2015 at 11:41 AM, Guillaume Nault <g.na...@alphalink.fr> 
> wrote:
>> On Thu, Dec 31, 2015 at 08:46:59AM +0100, Sedat Dilek wrote:
>>> Hi Guillaume,
>>>
>>> can you explain why you moved ppp to rtnetlink device handling?
>>> Benefits, etc.?
>>>
>> The objective is to bring all the flexibility of rtnetlink device
>> creation to ppp interfaces. This is particularly useful for Network
>> Access Servers which need to define device properties at creation
>> time. My use case includes setting device name and netns, which is
>> impossible with the ioctl-based interface without generating transient
>> effects.
>>
>
> What do you mean by "my use-case"?
> Example?
>
>>> Does anything change when using NetworkManager/ModemManager/pppd for
>>> my network setup/handling (here: Ubuntu/precise AMD64)?
>>>
>> No. The ioctl-based ABI remains unchanged, so programs using it won't
>> see any difference. The rtnl ABI only brings a new way to create PPP
>> devices.
>>
>> Whether a ppp device is created with the ioctl or rtnl ABI doesn't
>> change its behaviour. In particular ppp devices created with rtnl can
>> still be configured with the old ioctls. The only difference I can
>> think of, is that managing ppp devices with rtnl allows a user to
>> remove it with "ip link del", while this is not possible with ppp
>> devices created with ioctl.
>>
>
> That all sounds like an improvement.
>
>>> Thanks in advance.
>>>
>> You're welcome.
>>
>
> Building net-next-20151231 with your 3 patches on top...
>
> Guillaume Nault (8):
>   ppp: don't set sk_state to PPPOX_ZOMBIE in pppoe_disc_rcv()
>   ppp: remove PPPOX_ZOMBIE socket state
>   pppox: use standard module auto-loading feature
>   ppp: define "ppp" device type
>   ppp: declare ppp devices as enumerated interfaces
>   ppp: define reusable device creation functions <--- (1)
>   ppp: implement rtnetlink device handling <--- (2)
>   l2tp: rely on ppp layer for skb scrubbing <--- (3)
>
> ...will report.
>
> - Sedat -

# LC_ALL=C ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN mode DEFAULT qlen 1000
link/ether e8:03:9a:36:17:a9 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 88:53:2e:ac:c3:12 brd ff:ff:ff:ff:ff:ff
4: wwan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 02:50:f3:00:00:00 brd ff:ff:ff:ff:ff:ff
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN mode DEFAULT qlen 3
link/ppp

- Sedat -


run_htb-with-fq_codel_ppp0.sh
Description: Bourne shell script

net/tipc: memory leak in tipc_release

[Dmitry Vyukov]

Hello,

The following program, if run a parallel loop, leads to a leak of 2
objects allocated in tipc_release:

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include 
#include 
#include 
#include 
#include 

long r[86];

int main()
{
memset(r, -1, sizeof(r));
r[0] = syscall(SYS_mmap, 0x2000ul, 0x11000ul, 0x3ul,
0x32ul, 0xul, 0x0ul);
r[1] = syscall(SYS_eventfd, 0x7ul, 0, 0, 0, 0, 0);
r[2] = syscall(SYS_close, r[1], 0, 0, 0, 0, 0);
r[3] = syscall(SYS_socket, 0x1eul, 0x2ul, 0x0ul, 0, 0, 0);
r[4] = syscall(SYS_io_setup, 0x5ul, 0x20001d8bul, 0, 0, 0, 0);
if (r[4] != -1)
r[5] = *(uint64_t*)0x20001d8b;
r[6] = syscall(SYS_fcntl, r[1], 0x406ul, r[3], 0, 0, 0);
*(uint16_t*)0x20007000 = (uint16_t)0x27;
*(uint32_t*)0x20007002 = (uint32_t)0x3;
*(uint32_t*)0x20007006 = (uint32_t)0x6;
*(uint32_t*)0x2000700a = (uint32_t)0x1;
r[11] = syscall(SYS_connect, r[6], 0x20007000ul, 0x10ul, 0, 0, 0);
r[12] = syscall(SYS_dup3, r[6], r[1], 0x8ul, 0, 0, 0);
*(uint64_t*)0x20002000 = (uint64_t)0x20002fc0;
*(uint64_t*)0x20002008 = (uint64_t)0x20002fd8;
*(uint64_t*)0x20002010 = (uint64_t)0x2000246d;
*(uint64_t*)0x20002fc0 = (uint64_t)0x8;
*(uint32_t*)0x20002fc8 = (uint32_t)0x0;
*(uint32_t*)0x20002fcc = (uint32_t)0x9;
*(uint16_t*)0x20002fd0 = (uint16_t)0x5;
*(uint16_t*)0x20002fd2 = (uint16_t)0x0;
*(uint32_t*)0x20002fd4 = r[1];
*(uint64_t*)0x20002fd8 = (uint64_t)0x20002934;
*(uint64_t*)0x20002fe0 = (uint64_t)0x5e;
*(uint64_t*)0x20002fe8 = (uint64_t)0xfff7;
*(uint64_t*)0x20002ff0 = (uint64_t)0x20002000;
*(uint32_t*)0x20002ff8 = (uint32_t)0x0;
*(uint32_t*)0x20002ffc = r[1];
*(uint64_t*)0x20002000 = (uint64_t)0x20003000;
*(uint32_t*)0x20002008 = (uint32_t)0x5;
*(uint32_t*)0x2000200c = (uint32_t)0x2;
*(uint64_t*)0x20002010 = (uint64_t)0x1;
*(uint64_t*)0x20002018 = (uint64_t)0x7;
*(uint64_t*)0x20002020 = (uint64_t)0x2;
*(uint64_t*)0x20002028 = (uint64_t)0x4;
*(uint64_t*)0x20002030 = (uint64_t)0x0;
*(uint64_t*)0x20002038 = (uint64_t)0x1;
*(uint64_t*)0x20002040 = (uint64_t)0x4;
*(uint64_t*)0x20002048 = (uint64_t)0x9;
*(uint64_t*)0x20002fd8 = (uint64_t)0x5;
*(uint32_t*)0x20002fe0 = (uint32_t)0x0;
*(uint32_t*)0x20002fe4 = (uint32_t)0x8;
*(uint16_t*)0x20002fe8 = (uint16_t)0x7;
*(uint16_t*)0x20002fea = (uint16_t)0x;
*(uint32_t*)0x20002fec = (uint32_t)0x;
*(uint64_t*)0x20002ff0 = (uint64_t)0x20005fe3;
*(uint64_t*)0x20002ff8 = (uint64_t)0x2e;
*(uint64_t*)0x20003000 = (uint64_t)0x8;
*(uint64_t*)0x20003008 = (uint64_t)0x20002a50;
*(uint32_t*)0x20003010 = (uint32_t)0x1;
*(uint32_t*)0x20003014 = r[1];
*(uint64_t*)0x20002a50 = (uint64_t)0x20003000;
*(uint32_t*)0x20002a58 = (uint32_t)0xb;
*(uint32_t*)0x20002a5c = (uint32_t)0x1;
*(uint64_t*)0x20002a60 = (uint64_t)0x5;
*(uint64_t*)0x20002a68 = (uint64_t)0xacf;
*(uint64_t*)0x20002a70 = (uint64_t)0x8a;
*(uint64_t*)0x20002a78 = (uint64_t)0x3;
*(uint64_t*)0x20002a80 = (uint64_t)0x8d;
*(uint64_t*)0x20002a88 = (uint64_t)0xf5a;
*(uint64_t*)0x20002a90 = (uint64_t)0xd94;
*(uint64_t*)0x20002a98 = (uint64_t)0x9;
*(uint64_t*)0x2000246d = (uint64_t)0x0;
*(uint32_t*)0x20002475 = (uint32_t)0x0;
*(uint32_t*)0x20002479 = (uint32_t)0x2;
*(uint16_t*)0x2000247d = (uint16_t)0x2;
*(uint16_t*)0x2000247f = (uint16_t)0x0;
*(uint32_t*)0x20002481 = r[1];
*(uint64_t*)0x20002485 = (uint64_t)0x20002d52;
*(uint64_t*)0x2000248d = (uint64_t)0x11;
*(uint64_t*)0x20002495 = (uint64_t)0x4;
*(uint64_t*)0x2000249d = (uint64_t)0x20002fb0;
*(uint32_t*)0x200024a5 = (uint32_t)0x1;
*(uint32_t*)0x200024a9 = r[1];
*(uint64_t*)0x20002fb0 = (uint64_t)0x20003000;
*(uint32_t*)0x20002fb8 = (uint32_t)0x4;
*(uint32_t*)0x20002fbc = (uint32_t)0x2;
*(uint64_t*)0x20002fc0 = (uint64_t)0x3;
*(uint64_t*)0x20002fc8 = (uint64_t)0x6;
*(uint64_t*)0x20002fd0 = (uint64_t)0xe3;
*(uint64_t*)0x20002fd8 = (uint64_t)0xee;
*(uint64_t*)0x20002fe0 = (uint64_t)0x8;
*(uint64_t*)0x20002fe8 = (uint64_t)0x1;
*(uint64_t*)0x20002ff0 = (uint64_t)0x4;
*(uint64_t*)0x20002ff8 = (uint64_t)0x8;
r[85] = syscall(SYS_io_submit, r[5], 0x3ul, 0x20002000ul, 0, 0, 0);
return 0;
}


unreferenced object 0x88004be2cf00 (size 456):
  comm "syz-executor", pid 26609, jiffies 4295874528 (age 578.093s)
  hex dump (first 32 bytes):
f8 7a f3 4b 00 88 ff ff f8 7a f3 4b 00 88 ff ff  .z.K.z.K
00 00 00 

Re: [PATCH v2] net, socket, socket_wq: fix missing initialization of flags

[Nicolai Stange]

David Miller  writes:

> From: Nicolai Stange 
> Date: Tue, 29 Dec 2015 13:29:55 +0100
>
>> Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection")
>> 
>> Commit ceb5d58b2170 ("net: fix sock_wake_async() rcu protection") from
>> the current 4.4 release cycle introduced a new flags member in
>> struct socket_wq and moved SOCKWQ_ASYNC_NOSPACE and SOCKWQ_ASYNC_WAITDATA
>> from struct socket's flags member into that new place.
>> 
>> Unfortunately, the new flags field is never initialized properly, at least
>> not for the struct socket_wq instance created in sock_alloc_inode().
>> 
>> One particular issue I encountered because of this is that my GNU Emacs
>> failed to draw anything on my desktop -- i.e. what I got is a transparent
>> window, including the title bar. Bisection lead to the commit mentioned
>> above and further investigation by means of strace told me that Emacs
>> is indeed speaking to my Xorg through an O_ASYNC AF_UNIX socket. This is
>> reproducible 100% of times and the fact that properly initializing the
>> struct socket_wq ->flags fixes the issue leads me to the conclusion that
>> somehow SOCKWQ_ASYNC_WAITDATA got set in the uninitialized ->flags,
>> preventing my Emacs from receiving any SIGIO's due to data becoming
>> available and it got stuck.
>> 
>> Make sock_alloc_inode() set the newly created struct socket_wq's ->flags
>> member to zero.
>> 
>> Signed-off-by: Nicolai Stange 
>
> Applied, but please in the future please put the Fixes: tag right
> above the first signoff/ack, like this:
>
> Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection")
> Signed-off-by: Nicolai Stange 

Thank you very much!

Regarding the correct position of the "Fixes:" tag: lesson learned.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next] ppp: rtnetlink device handling

[Sedat Dilek]

On Thu, Dec 31, 2015 at 11:41 AM, Guillaume Nault <g.na...@alphalink.fr> wrote:
> On Thu, Dec 31, 2015 at 08:46:59AM +0100, Sedat Dilek wrote:
>> Hi Guillaume,
>>
>> can you explain why you moved ppp to rtnetlink device handling?
>> Benefits, etc.?
>>
> The objective is to bring all the flexibility of rtnetlink device
> creation to ppp interfaces. This is particularly useful for Network
> Access Servers which need to define device properties at creation
> time. My use case includes setting device name and netns, which is
> impossible with the ioctl-based interface without generating transient
> effects.
>

What do you mean by "my use-case"?
Example?

>> Does anything change when using NetworkManager/ModemManager/pppd for
>> my network setup/handling (here: Ubuntu/precise AMD64)?
>>
> No. The ioctl-based ABI remains unchanged, so programs using it won't
> see any difference. The rtnl ABI only brings a new way to create PPP
> devices.
>
> Whether a ppp device is created with the ioctl or rtnl ABI doesn't
> change its behaviour. In particular ppp devices created with rtnl can
> still be configured with the old ioctls. The only difference I can
> think of, is that managing ppp devices with rtnl allows a user to
> remove it with "ip link del", while this is not possible with ppp
> devices created with ioctl.
>

That all sounds like an improvement.

>> Thanks in advance.
>>
> You're welcome.
>

Building net-next-20151231 with your 3 patches on top...

Guillaume Nault (8):
  ppp: don't set sk_state to PPPOX_ZOMBIE in pppoe_disc_rcv()
  ppp: remove PPPOX_ZOMBIE socket state
  pppox: use standard module auto-loading feature
  ppp: define "ppp" device type
  ppp: declare ppp devices as enumerated interfaces
  ppp: define reusable device creation functions <--- (1)
  ppp: implement rtnetlink device handling <--- (2)
  l2tp: rely on ppp layer for skb scrubbing <--- (3)

...will report.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] connector: bump skb->users before callback invocation

[Florian Westphal]

Dmitry reports memleak with syskaller program.
Problem is that connector bumps skb usecount but might not invoke callback.

So move skb_get to where we invoke the callback.

Reported-by: Dmitry Vyukov 
Signed-off-by: Florian Westphal 
---
 I wonder wth userspace can cram skb->len < NLMSG_HDRLEN
 down the kernel, it seems to beg for trouble...

diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index d7373ca..25693b0 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -179,26 +179,21 @@ static int cn_call_callback(struct sk_buff *skb)
  *
  * It checks skb, netlink header and msg sizes, and calls callback helper.
  */
-static void cn_rx_skb(struct sk_buff *__skb)
+static void cn_rx_skb(struct sk_buff *skb)
 {
struct nlmsghdr *nlh;
-   struct sk_buff *skb;
int len, err;
 
-   skb = skb_get(__skb);
-
if (skb->len >= NLMSG_HDRLEN) {
nlh = nlmsg_hdr(skb);
len = nlmsg_len(nlh);
 
if (len < (int)sizeof(struct cn_msg) ||
skb->len < nlh->nlmsg_len ||
-   len > CONNECTOR_MAX_MSG_SIZE) {
-   kfree_skb(skb);
+   len > CONNECTOR_MAX_MSG_SIZE)
return;
-   }
 
-   err = cn_call_callback(skb);
+   err = cn_call_callback(skb_get(skb));
if (err < 0)
kfree_skb(skb);
}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

net/netlink: memory leak in netlink_sendmsg

[Dmitry Vyukov]

Hello,

The following program causes leak on 2 objects allocated in netlink_sendmsg:

https://gist.githubusercontent.com/dvyukov/e840d00cfefe66c5e064/raw/6e5343a936bd3edd1b0803941cf7c1427050d9a5/gistfile1.txt

unreferenced object 0x880014f54840 (size 224):
  comm "a.out", pid 11468, jiffies 4301602943 (age 29.985s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 10 3b 9d 3d 00 88 ff ff  .;.=
  backtrace:
[< inline >] kmemleak_alloc_recursive include/linux/kmemleak.h:47
[< inline >] slab_post_alloc_hook mm/slub.c:1335
[< inline >] slab_alloc_node mm/slub.c:2594
[] kmem_cache_alloc_node+0x16d/0x2e0 mm/slub.c:2630
[] __alloc_skb+0xba/0x5f0 net/core/skbuff.c:216
[< inline >] alloc_skb include/linux/skbuff.h:814
[< inline >] netlink_alloc_large_skb net/netlink/af_netlink.c:1695
[] netlink_sendmsg+0xfd4/0x1760
net/netlink/af_netlink.c:2486
[< inline >] sock_sendmsg_nosec net/socket.c:610
[] sock_sendmsg+0xca/0x110 net/socket.c:620
[] ___sys_sendmsg+0x309/0x840 net/socket.c:1946
[] __sys_sendmmsg+0x134/0x330 net/socket.c:2031
[< inline >] SYSC_sendmmsg net/socket.c:2059
[] SyS_sendmmsg+0x35/0x60 net/socket.c:2054
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
unreferenced object 0x880014facf60 (size 512):
  comm "a.out", pid 11468, jiffies 4301602943 (age 29.985s)
  hex dump (first 32 bytes):
48 ea fa 14 00 88 ff ff 00 00 00 00 ad 4e ad de  HN..
ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff  
  backtrace:
[< inline >] kmemleak_alloc_recursive include/linux/kmemleak.h:47
[< inline >] slab_post_alloc_hook mm/slub.c:1335
[< inline >] slab_alloc_node mm/slub.c:2594
[] __kmalloc_node_track_caller+0x217/0x3e0 mm/slub.c:4096
[] __kmalloc_reserve.isra.31+0x41/0xe0
net/core/skbuff.c:135
[] __alloc_skb+0xf0/0x5f0 net/core/skbuff.c:228
[< inline >] alloc_skb include/linux/skbuff.h:814
[< inline >] netlink_alloc_large_skb net/netlink/af_netlink.c:1695
[] netlink_sendmsg+0xfd4/0x1760
net/netlink/af_netlink.c:2486
[< inline >] sock_sendmsg_nosec net/socket.c:610
[] sock_sendmsg+0xca/0x110 net/socket.c:620
[] ___sys_sendmsg+0x309/0x840 net/socket.c:1946
[] __sys_sendmmsg+0x134/0x330 net/socket.c:2031
[< inline >] SYSC_sendmmsg net/socket.c:2059
[] SyS_sendmmsg+0x35/0x60 net/socket.c:2054
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185

On commit 8513342170278468bac126640a5d2d12ffbff106 (Dec 28).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: bluetooth-next 2015-12-31

[David Miller]

From: Johan Hedberg 
Date: Thu, 31 Dec 2015 18:28:32 +0200

> Here's (probably) the last bluetooth-next pull request for the 4.5
> kernel:
> 
>  - Add support for BCM2E65 ACPI ID
>  - Minor fixes/cleanups in the bcm203x & bfusb drivers
>  - Minor debugfs related fix in 6lowpan code
> 
> Please let me know if there are any issues pulling. Thanks.

Pulled, thanks Johan.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Dec 31 (net/xfrm/xfrm_input.c)

[Randy Dunlap]

On 12/31/15 04:30, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20151223:
> 


seen on i386 or x86_64:

In file included from ../net/xfrm/xfrm_input.c:17:0:
../include/net/ip6_tunnel.h: In function 'ip6tunnel_xmit':
../include/net/ip6_tunnel.h:93:2: error: implicit declaration of function 
'iptunnel_xmit_stats' [-Werror=implicit-function-declaration]
  iptunnel_xmit_stats(dev, pkt_len);
  ^



-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT] [4.5] NFC update

[Samuel Ortiz]

Hi David,

This is the first NFC pull request for 4.5 and it brings:

- A new driver for the STMicroelectronics ST95HF NFC chipset.
  The ST95HF is an NFC digital transceiver with an embedded analog
  front-end and as such relies on the Linux NFC digital
  implementation. This is the 3rd user of the NFC digital stack.

- ACPI support for the ST st-nci and st21nfca drivers.

- A small improvement for the nfcsim driver, as we can now tune
  the Rx delay through sysfs.

- A bunch of minor cleanups and small fixes from Christophe Ricard,
  for a few drivers and the NFC core code.


The following changes since commit 7f151f1d8abb7d5930b49d4796b463dca1673cb7:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-11-17 
13:52:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git 
tags/nfc-next-4.5-1

for you to fetch changes up to c6dc65d885b98898bf287aaf44e020077b41769f:

  NFC: nci: memory leak in nci_core_conn_create() (2015-12-29 19:06:23 +0100)


Christophe Ricard (27):
  nfc: st-nci: Remove useless #include "ndlc.h"
  nfc: st-nci: Remove unneeded CONFIG_OF switches
  nfc: st21nfca: Remove unneeded CONFIG_OF switches
  nfc: nxp-nci: Remove #ifdef CONFIG_OF
  nfc: pn544: Remove #ifdef CONFIG_OF
  nfc: st-nci: Group device table together
  nfc: st21nfca: Group device table together
  nfc: st-nci: Add macro for gpio name
  nfc: st21nfca: Add macro for gpio name
  nfc: st-nci: Add support for acpi probing for i2c device.
  nfc: st-nci: Add support for acpi probing for spi device.
  nfc: st21nfca: Add support for acpi probing for i2c device.
  nfc: st-nci: Code cleanup
  nfc: st21nfca: Code cleanup
  nfc: st21nfca: Remove useless pr_info in st21nfca_hci_i2c_disable
  NFC: nci: Fix error check of nci_hci_create_pipe() result
  NFC: st-nci: Auto-select core module
  NFC: st21nfca: Auto-select core module
  nfc: netlink: HCI event connectivity implementation
  nfc: st-nci: Add support for HCI event connectivity
  nfc: st21nfca: Add support for HCI event connectivity
  MAINTAINERS: nfc: Add missing platform_data files references
  nfc: fdp: Move i2c client irq checking
  nfc: microread: Remove useless irq field
  nfc: microread: Fix header comment
  nfc: nxp-nci: Remove i2c client gpio irq configuration
  nfc: pn544: Remove i2c client gpio irq configuration

Dan Carpenter (1):
  NFC: nci: memory leak in nci_core_conn_create()

Fabio Estevam (1):
  nxp-nci: i2c: Do not check specifically for -EREMOTEIO error

Geliang Tang (1):
  NFC: trf7970a: use to_spi_device

Julia Lawall (1):
  nfc: s3fwrn5: constify s3fwrn5_phy_ops structures

Saurabh Sengar (1):
  NFC: add rx delay sysfs parameter for nfcsim workqueue

Shikha Singh (4):
  NFC: digital: Add Type4A tags support
  NFC: Add STMicroelectronics ST95HF driver
  DT: bindings: net: nfc: Add ST95HF binding doc
  NFC: st95hf: Fix build error

 .../devicetree/bindings/net/nfc/st95hf.txt |   50 +
 MAINTAINERS|5 +
 drivers/nfc/Kconfig|1 +
 drivers/nfc/Makefile   |1 +
 drivers/nfc/fdp/i2c.c  |   12 +-
 drivers/nfc/microread/i2c.c|2 -
 drivers/nfc/nfcsim.c   |   10 +-
 drivers/nfc/nxp-nci/i2c.c  |   34 +-
 drivers/nfc/pn544/i2c.c|   46 +-
 drivers/nfc/s3fwrn5/core.c |2 +-
 drivers/nfc/s3fwrn5/i2c.c  |2 +-
 drivers/nfc/s3fwrn5/s3fwrn5.h  |4 +-
 drivers/nfc/st-nci/Kconfig |   18 +-
 drivers/nfc/st-nci/i2c.c   |   80 +-
 drivers/nfc/st-nci/ndlc.c  |1 -
 drivers/nfc/st-nci/se.c|3 +-
 drivers/nfc/st-nci/spi.c   |   81 +-
 drivers/nfc/st21nfca/Kconfig   |   13 +-
 drivers/nfc/st21nfca/i2c.c |   80 +-
 drivers/nfc/st21nfca/se.c  |5 +-
 drivers/nfc/st95hf/Kconfig |   10 +
 drivers/nfc/st95hf/Makefile|6 +
 drivers/nfc/st95hf/core.c  | 1273 
 drivers/nfc/st95hf/spi.c   |  167 +++
 drivers/nfc/st95hf/spi.h   |   64 +
 drivers/nfc/trf7970a.c |8 +-
 include/linux/platform_data/microread.h|2 +-
 include/net/nfc/nfc.h  |1 +
 net/nfc/core.c |   13 +
 net/nfc/digital_core.c |3 +-
 

Re: [PATCH] af_unix: Fix splice-bind deadlock

[Rainer Weikusat]

Hannes Frederic Sowa  writes:
> On 27.12.2015 21:13, Rainer Weikusat wrote:
>> -static int unix_mknod(const char *sun_path, umode_t mode, struct path *res)
>> +static int unix_mknod(struct dentry *dentry, struct path *path, umode_t 
>> mode,
>> +  struct path *res)
>>   {
>> -struct dentry *dentry;
>> -struct path path;
>> -int err = 0;
>> -/*
>> - * Get the parent directory, calculate the hash for last
>> - * component.
>> - */
>> -dentry = kern_path_create(AT_FDCWD, sun_path, , 0);
>> -err = PTR_ERR(dentry);
>> -if (IS_ERR(dentry))
>> -return err;
>> +int err;
>>
>> -/*
>> - * All right, let's create it.
>> - */
>> -err = security_path_mknod(, dentry, mode, 0);
>> +err = security_path_mknod(path, dentry, mode, 0);
>>  if (!err) {
>> -err = vfs_mknod(d_inode(path.dentry), dentry, mode, 0);
>> +err = vfs_mknod(d_inode(path->dentry), dentry, mode, 0);
>>  if (!err) {
>> -res->mnt = mntget(path.mnt);
>> +res->mnt = mntget(path->mnt);
>>  res->dentry = dget(dentry);
>>  }
>>  }
>> -done_path_create(, dentry);
>> +
>
> The reordered call to done_path_create will change the locking
> ordering between the i_mutexes and the unix readlock. Can you comment
> on this? On a first sight this looks like a much more dangerous change
> than the original deadlock report. Can't this also conflict with
> splice code deep down in vfs layer?

Practical consideration
---

kern_path_create acquires the i_mutex of the parent directory of the
to-be-created directory entry (via filename_create/ namei.c), as
required for reading a directory or creating a new entry in a directory
(as per Documentation/filesystems/directory-locking). A deadlock was
possible here if the thread doing the bind then blocked when trying to
acquire the readlock while the thread holding the readlock is blocked on
another lock held by a thread trying to perform an operation on the same
directory as the bind (possibly with some indirection). The only 'other
lock' which could come into play here is the pipe lock of a pipe
partaking in a splice_to_pipe from the same AF_UNIX socket. But the idea
that some thread would need to take a pipe lock prior to performing a
directory operation is quite odd (splice_from_pipe_to_directory?
openatparentoffifo?). I've also checked all existing users
of pipe_lock and at least, I didn't find one performing a directory
operation.


Theoretical consideration
-

NB: The text below represents my opinion on this after spending a few
days thinking about it (on and of, of course). Making an argument for
the opposite position is also possible.

The filesystem (namespace) is a shared namespace accessible to all
currently running threads/ processes. Whoever uses the filesystem may
have to wait for other filesystem users but threads not using it
shouldn't have to. Because of this and because the filesystem is a
pretty central facility, an operation needing 'some filesystem lock' and
also some other lock (or locks) should always acquire the filesystem
ones before any more specialized locks (as do_splice does when splicing
to a file). If 'filesystem locks' are always acquired first, there's
also no risk of a deadlock because code holding a filesystem lock is
blocked on a more specialized lock (eg, a pipe lock or the readlock
mutx) while some other thread holding the/ a more specialized lock wants
the already held filesystem lock.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT] Networking

[David Miller]

1) Prevent XFRM per-cpu counter updates for one namespace from
   being applied to another namespace.  Fix from DanS treetman.

2) Fix RCU de-reference in iwl_mvm_get_key_sta_id(), from Johannes
   Berg.

3) Remove ethernet header assumption in nft_do_chain_netdev(), from
   Pablo Neira Ayuso.

4) Fix cpsw PHY ident with multiple slaves and fixed-phy, from
   Pascal Speck.

5) Fix use after free in sixpack_close and mkiss_close.

6) Fix VXLAN fw assertion on bnx2x, from Yuval Mintz.

7) natsemi doesn't check for DMA mapping errors, from Alexey
   Khoroshilov.

8) Fix inverted test in ip6addrlbl_get(), from ANdrey Ryabinin.

9) Missing initialization of needed_headroom in geneve tunnel
   driver, from Paolo Abeni.

10) Fix conntrack template leak in openvswitch, from Joe Stringer.

11) Mission initialization of wq->flags in sock_alloc_inode(), from
Nicolai Stange.

Please pull, thanks a lot!

The following changes since commit 73796d8bf27372e26c2b79881947304c14c2d353:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-12-17 
14:05:22 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 068d8bd338e855286aea54e70d1c101569284b21:

  sctp: sctp should release assoc when sctp_make_abort_user return NULL in 
sctp_close (2015-12-30 16:57:16 -0500)


Alexey Khoroshilov (1):
  natsemi: add checks for dma mapping errors

Andrey Ryabinin (1):
  ipv6/addrlabel: fix ip6addrlbl_get()

Bjørn Mork (1):
  net: cdc_ncm: avoid changing RX/TX buffers on MTU changes

Dan Carpenter (1):
  qlcnic: fix a loop exit condition better

Dan Streetman (1):
  xfrm: dst_entries_init() per-net dst_ops

Daniele Palmas (2):
  net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband Card
  net: usb: cdc_ncm: Adding Dell DW5813 LTE AT Mobile Broadband Card

David Miller (2):
  6pack: Fix use after free in sixpack_close().
  mkiss: Fix use after free in mkiss_close().

David Rivshin (2):
  drivers: net: cpsw: fix RMII/RGMII mode when used with fixed-link PHY
  drivers: net: cpsw: increment reference count on fixed-link PHY node

David S. Miller (6):
  Merge branch 'cpsw-fixed-phy-dt-bugs'
  Merge branch 'mlx4-time-stamping-fixes'
  Merge branch 'cdc_ncm-new-Dell-devices'
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
  Merge tag 'wireless-drivers-for-davem-2015-12-28' of 
git://git.kernel.org/.../kvalo/wireless-drivers

Eugenia Emantayev (2):
  net/mlx4_en: Remove dependency between timestamping capability and 
service_task
  net/mlx4_en: Fix HW timestamp init issue upon system startup

Florian Westphal (1):
  netfilter: nft_ct: include direction when dumping NFT_CT_L3PROTOCOL key

Hannes Frederic Sowa (1):
  ipv6: honor ifindex in case we receive ll addresses in router 
advertisements

Herbert Xu (1):
  rhashtable: Kill harmless RCU warning in rhashtable_walk_init

Ido Schimmel (1):
  switchdev: bridge: Pass ageing time as clock_t instead of jiffies

Joe Stringer (1):
  openvswitch: Fix template leak in error cases.

Johannes Berg (2):
  iwlwifi: separate firmware version for 7260 devices
  iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id

Julia Lawall (1):
  drivers: net: cpsw: fix error return code

Kalle Valo (1):
  Merge tag 'iwlwifi-for-kalle-2015-12-16' of 
https://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Marcelo Ricardo Leitner (2):
  sctp: use GFP_USER for user-controlled kmalloc
  sctp: label accepted/peeled off sockets

Nicolai Stange (1):
  net, socket, socket_wq: fix missing initialization of flags

Pablo Neira Ayuso (1):
  netfilter: nf_tables: use skb->protocol instead of assuming ethernet 
header

Paolo Abeni (1):
  geneve: initialize needed_headroom

Pascal Speck (Iktek) (1):
  ethernet:ti:cpsw: fix phy identification with multiple slaves on fixed-phy

Pravin B Shelar (1):
  ipip: ioctl: Remove superfluous IP-TTL handling.

Sergei Shtylyov (1):
  sh_eth: fix 16-bit descriptor field access endianness too

Simon Horman (1):
  openvswitch: correct encoding of set tunnel action attributes

Venkat Duvvuru (1):
  be2net: Avoid accessing eq object in be_msix_register routine, when i < 0.

Vijay Pandurangan (1):
  veth: don’t modify ip_summed; doing so treats packets with bad checksums 
as good.

WANG Cong (1):
  addrconf: always initialize sysctl table data

Xin Long (1):
  sctp: sctp should release assoc when sctp_make_abort_user return NULL in 
sctp_close

Yuval Mintz (1):
  bnx2x: Prevent FW assertion when using Vxlan

 Documentation/devicetree/bindings/net/cpsw.txt|  6 +++---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c   | 22 
+-
 

pull request: bluetooth-next 2015-12-31

[Johan Hedberg]

Hi Dave,

Here's (probably) the last bluetooth-next pull request for the 4.5
kernel:

 - Add support for BCM2E65 ACPI ID
 - Minor fixes/cleanups in the bcm203x & bfusb drivers
 - Minor debugfs related fix in 6lowpan code

Please let me know if there are any issues pulling. Thanks.

Johan

---
The following changes since commit 07f6f4a31e5a8dee67960fc07bb0b37c5f879d4d:

  tcp: diag: add support for request sockets to tcp_abort() (2015-12-18 
16:06:39 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git 
for-upstream

for you to fetch changes up to 7ddb69222d0fdc0bc83b60dbb21d9864ebf2907e:

  Bluetooth: bfusb: Fix the return error code (2015-12-22 15:25:33 +0100)


Alexander Aring (1):
  6lowpan: fix debugfs interface entry name

Geliang Tang (1):
  Bluetooth: use list_for_each_entry*

Luka Karinja (1):
  Bluetooth: hci_bcm: Add BCM2E65 ACPI ID

Syam Sidhardhan (3):
  Bluetooth: bcm203x: Remove redundant error message
  Bluetooth: bfusb: Remove redundant error message
  Bluetooth: bfusb: Fix the return error code

 drivers/bluetooth/bcm203x.c  |  4 +---
 drivers/bluetooth/bfusb.c|  6 ++
 drivers/bluetooth/hci_bcm.c  |  1 +
 net/6lowpan/core.c   |  6 +++---
 net/bluetooth/af_bluetooth.c | 12 +--
 net/bluetooth/cmtp/capi.c|  8 ++--
 net/bluetooth/hci_core.c |  8 +++-
 net/bluetooth/rfcomm/core.c  | 46 +-
 8 files changed, 32 insertions(+), 59 deletions(-)


signature.asc
Description: PGP signature

Re: [net-next] ppp: rtnetlink device handling

[David Miller]

From: Sedat Dilek 
Date: Thu, 31 Dec 2015 15:06:18 +0100

> Just off-topic...

Please do not hijack a thread discussing a patch series like this to
talk about something completely unrelated.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: emac: emac gigabit ethernet controller driver

[Rob Herring]

On Tue, Dec 15, 2015 at 4:49 PM, Gilad Avidov  wrote:
> On Mon, 14 Dec 2015 17:39:09 -0800
> Florian Fainelli  wrote:
>
>> On 14/12/15 16:19, Gilad Avidov wrote:
>>
>> [snip]
>>
>> > +   "sgmii_irq";
>> > +   qcom,emac-gpio-mdc = < 123 0>;
>> > +   qcom,emac-gpio-mdio = < 124 0>;
>> > +   qcom,emac-tstamp-en;
>> > +   qcom,emac-ptp-frac-ns-adj = <12500 1>;
>> > +   phy-addr = <0>;
>>
>> Please use the standard Ethernet PHY and MDIO device tree bindings to
>> describe your MAC to PHY connection here, that includes using a
>> phy-connection-type property to describe the (x)MII lanes.
>>
>
>
> Hi Florian,
>
> Thank you for the review.
>
> Unfortunately this Ethernet controller's PHY is non standard and fits
> poorly into the standard MDIO framework layer. Rather than read/writs
> over MDIO only, this hw have some of the PHY registers internal and
> accessed by memory mapped IO, while others are accessed over the MDIO.
> Some standard functions requires using both. Additionally a number
> of different functions are controlled from different fields of the
> same register.

Even so, the bindings should follow the standard binding for MDIO bus
whether you can use the common kernel infrastructure or not.

Having internal phy connected to external phy is pretty common for
10G. Not sure if that is what you mean here or not.

Rob
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux 4.4-rc4 regression, bisected to "net: fix sock_wake_async() rcu protection"

[Linus Torvalds]

On Wed, Dec 30, 2015 at 5:55 AM, Eric Dumazet  wrote:
> On Wed, 2015-12-30 at 12:32 +0100, Nicolai Stange wrote:
>>
>> Please have a look at https://lkml.kernel.org/g/87ege73bma@gmail.com
>>
>> I ran into the same issue and this one fixes it for me.
>
> Right, and the ozlabs pointers for this were :
> v2:
> https://patchwork.ozlabs.org/patch/561553/

Ok, that's merged into my tree through the networking merge today.

Andy, if you still see it with current -git, holler.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] be2net: Delete an unnecessary check in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 1 Jan 2016 00:11:57 +0100

Remove two checks for null pointers which would be handled by usual
error detection before.

Signed-off-by: Markus Elfring 
---
 drivers/net/ethernet/emulex/benet/be_cmds.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c 
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index b63d8ad..ba98297 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -4366,9 +4366,7 @@ int be_cmd_get_profile_config(struct be_adapter *adapter,
if (vf_res)
res->vf_if_cap_flags = vf_res->cap_flags;
 err:
-   if (cmd.va)
-   dma_free_coherent(>pdev->dev, cmd.size, cmd.va,
- cmd.dma);
+   dma_free_coherent(>pdev->dev, cmd.size, cmd.va, cmd.dma);
return status;
 }
 
@@ -4398,10 +4396,7 @@ static int be_cmd_set_profile_config(struct be_adapter 
*adapter, void *desc,
memcpy(req->desc, desc, size);
 
status = be_cmd_notify_wait(adapter, );
-
-   if (cmd.va)
-   dma_free_coherent(>pdev->dev, cmd.size, cmd.va,
- cmd.dma);
+   dma_free_coherent(>pdev->dev, cmd.size, cmd.va, cmd.dma);
return status;
 }
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next] ppp: rtnetlink device handling

[Sedat Dilek]

On Thu, Dec 31, 2015 at 6:10 PM, David Miller  wrote:
> From: Sedat Dilek 
> Date: Thu, 31 Dec 2015 15:06:18 +0100
>
>> Just off-topic...
>
> Please do not hijack a thread discussing a patch series like this to
> talk about something completely unrelated.

Yes, you are right.

Happy new 2016,
- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net-thunder: One check less in nicvf_register_interrupts() after error detection

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 31 Dec 2015 22:40:39 +0100

Adjust a jump target to eliminate a check before error logging.
Use the identifier "report_failure" instead of "err".

Signed-off-by: Markus Elfring 
---
 drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c 
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index c24cb2a..21e1579 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -922,7 +922,7 @@ static int nicvf_register_interrupts(struct nicvf *nic)
ret = request_irq(vector, nicvf_intr_handler,
  0, nic->irq_name[irq], nic->napi[irq]);
if (ret)
-   goto err;
+   goto report_failure;
nic->irq_allocated[irq] = true;
}
 
@@ -933,7 +933,7 @@ static int nicvf_register_interrupts(struct nicvf *nic)
ret = request_irq(vector, nicvf_rbdr_intr_handler,
  0, nic->irq_name[irq], nic);
if (ret)
-   goto err;
+   goto report_failure;
nic->irq_allocated[irq] = true;
}
 
@@ -944,13 +944,12 @@ static int nicvf_register_interrupts(struct nicvf *nic)
ret = request_irq(nic->msix_entries[irq].vector,
  nicvf_qs_err_intr_handler,
  0, nic->irq_name[irq], nic);
-   if (!ret)
+   if (!ret) {
nic->irq_allocated[irq] = true;
-
-err:
-   if (ret)
-   netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq);
-
+   return 0;
+   }
+report_failure:
+   netdev_err(nic->netdev, "request_irq failed, vector %d\n", irq);
return ret;
 }
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

[Rob Herring]

On Tue, Dec 29, 2015 at 06:48:55PM -0700, Gilad Avidov wrote:
> Add supports for ethernet controller HW on Qualcomm Technologies, Inc. SoC.
> This driver supports the following features:
> 1) Checksum offload.
> 2) Runtime power management support.
> 3) Interrupt coalescing support.
> 4) SGMII phy.
> 5) SGMII direct connection without external phy.
> 
> Based on a driver by Niranjana Vishwanathapura
> .

[...]

> diff --git a/Documentation/devicetree/bindings/net/qcom-emac.txt 
> b/Documentation/devicetree/bindings/net/qcom-emac.txt
> new file mode 100644
> index 000..8d58a40
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/qcom-emac.txt
> @@ -0,0 +1,68 @@
> +Qualcomm EMAC Gigabit Ethernet Controller
> +
> +Required properties:
> +- cell-index : EMAC controller instance number.
> +- compatible : Should be "qcom,emac".

This should be more specific with the SOC name.

> +- reg : Offset and length of the register regions for the device
> +- reg-names : Register region names referenced in 'reg' above.
> + Required register resource entries are:
> + "base"   : EMAC controller base register block.
> + "csr": EMAC wrapper register block.
> + Optional register resource entries are:
> + "ptp": EMAC PTP (1588) register block.
> +Required if 'qcom,emac-tstamp-en' is present.
> + "sgmii"  : EMAC SGMII PHY register block.
> +- interrupts : Interrupt numbers used by this controller
> +- interrupt-names : Interrupt resource names referenced in 'interrupts' 
> above.
> + Required interrupt resource entries are:
> + "emac_core0"   : EMAC core0 interrupt.
> + "sgmii_irq"   : EMAC SGMII interrupt.
> +- qcom,emac-gpio-mdc  : GPIO pin number of the MDC line of MDIO bus.
> +- qcom,emac-gpio-mdio : GPIO pin number of the MDIO line of MDIO bus.

Use the standard binding for GPIO controlled MDIO bus.

> +- phy-addr: Specifies phy address on MDIO bus.
> + Required if the optional property "qcom,no-external-phy"
> + is not specified.

Don't you think you will need to know the specific phy device or other 
properties of the phy?

> +
> +Optional properties:
> +- qcom,emac-tstamp-en   : Enables the PTP (1588) timestamping feature.
> +   Include this only if PTP (1588) timestamping
> +   feature is needed. If included, "ptp" register
> +   base should be specified.

Isn't this a user enabled feature if the h/w supports it?

> +- mac-address   : The 6-byte MAC address. If present, it is the
> +   default MAC address.
> +- qcom,no-external-phy  : Indicates there is no external PHY connected to
> +   EMAC. Include this only if the EMAC is directly
> +   connected to the peer end without EPHY.
> +- qcom,emac-ptp-grandmaster : Enable the PTP (1588) grandmaster mode.
> +   Include this only if PTP (1588) is configured as
> +   grandmaster.
> +- qcom,emac-ptp-frac-ns-adj : The vector table to adjust the fractional ns 
> per
> +   RTC clock cycle.
> +   Include this only if there is accuracy loss of
> +   fractional ns per RTC clock cycle. For individual
> +   table entry, the first field indicates the RTC
> +   reference clock rate. The second field indicates
> +   the number of adjustment in 2 ^ -26 ns.
> +Example:
> + emac0: qcom,emac@feb2 {
> + cell-index = <0>;
> + compatible = "qcom,emac";
> + reg-names = "base", "csr", "ptp", "sgmii";
> + reg =   <0xfeb2 0x1>,
> + <0xfeb36000 0x1000>,
> + <0xfeb3c000 0x4000>,
> + <0xfeb38000 0x400>;
> + #address-cells = <0>;
> + interrupt-parent = <>;
> + #interrupt-cells = <1>;
> + interrupts = <0 1>;
> + interrupt-map-mask = <0x>;
> + interrupt-map = <0  0 76 0
> +  1  0 80 0>;
> + interrupt-names = "emac_core0", "sgmii_irq";
> + qcom,emac-gpio-mdc = < 123 0>;
> + qcom,emac-gpio-mdio = < 124 0>;
> + qcom,emac-tstamp-en;
> + qcom,emac-ptp-frac-ns-adj = <12500 1>;
> + phy-addr = <0>;
> + };
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

THIS BUSINESS WE BENEFIT US.>reply with(safi.kabo...@gmail.com)

[Safi Kabore]

Dear friend,

I need your help for Transferring(US$4.5M DOLLARS)to your Bank Account.
Reply Me back lets proceed also send the below requirement so i can 
reply you with more details so i can advice you on how to apply to the 
Bank for the transfer.


1)Full names.
2)country of origin.
3)Your Mobile No.
4)Your Age.
5)occupation.

Reply Me with this email(safi.kabo...@gmail.com)

Thanks.

Miss Safi kabore


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 06/12] net: sched: support qdisc_reset on NOLOCK qdisc

[Alexei Starovoitov]

On Wed, Dec 30, 2015 at 09:53:13AM -0800, John Fastabend wrote:
> The qdisc_reset operation depends on the qdisc lock at the moment
> to halt any additions to gso_skb and statistics while the list is
> free'd and the stats zeroed.
> 
> Without the qdisc lock we can not guarantee another cpu is not in
> the process of adding a skb to one of the "cells". Here are the
> two cases we have to handle.
> 
>  case 1: qdisc_graft operation. In this case a "new" qdisc is attached
>and the 'qdisc_destroy' operation is called on the old qdisc.
>The destroy operation will wait a rcu grace period and call
>qdisc_rcu_free(). At which point gso_cpu_skb is free'd along
>with all stats so no need to zero stats and gso_cpu_skb from
>the reset operation itself.
> 
>Because we can not continue to call qdisc_reset before waiting
>an rcu grace period so that the qdisc is detached from all
>cpus simply do not call qdisc_reset() at all and let the
>qdisc_destroy operation clean up the qdisc. Note, a refcnt
>greater than 1 would cause the destroy operation to be
>aborted however if this ever happened the reference to the
>qdisc would be lost and we would have a memory leak.
> 
>  case 2: dev_deactivate sequence. This can come from a user bringing
>the interface down which causes the gso_skb list to be flushed
>and the qlen zero'd. At the moment this is protected by the
>qdisc lock so while we clear the qlen/gso_skb fields we are
>guaranteed no new skbs are added. For the lockless case
>though this is not true. To resolve this move the qdisc_reset
>call after the new qdisc is assigned and a grace period is
>exercised to ensure no new skbs can be enqueued. Further
>the RTNL lock is held so we can not get another call to
>activate the qdisc while the skb lists are being free'd.
> 
>Finally, fix qdisc_reset to handle the per cpu stats and
>skb lists.
> 
> Signed-off-by: John Fastabend 
...
> - /* Prune old scheduler */
> - if (oqdisc && atomic_read(>refcnt) <= 1)
> - qdisc_reset(oqdisc);
> -
...
> - sync_needed |= !dev->dismantle;
> + sync_needed = true;

I think killing above <=1 check and forcing synchronize_net() will
make qdisc destruction more reliable than it's right now.
Your commit log sounds too pessimistic :)

btw, sync_needed variable can be removed as well.

All other patches look good. Great stuff overall!

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: refactor icmp_global_allow to improve readability and performance.

[Mike Danese]

We can reduce the number of operations performed by icmp_global_allow
and make the routine more readable by refactoring it in two ways:

First, this patch refactors the meaning of the "delta" variable. Before
this change, it meant min("time since last refill of token bucket", HZ).
After this change, it means "time since last refill". The original
definition is required only once but was being calculated twice. The new
meaning is also more intuitive for a variable named "delta".

Second, by calculating "delta" (time since last refill of token bucket)
and "cbr" (token bucket can be refilled) at the beginning of the
routine, we reduce the number of repeated calculations of these two
variables.

There should be no functional difference.

Signed-off-by: Mike Danese 
---
 net/ipv4/icmp.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 36e2697..4e5942d 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -252,22 +252,21 @@ static struct {
  */
 bool icmp_global_allow(void)
 {
-   u32 credit, delta, incr = 0, now = (u32)jiffies;
+   u32 credit, incr = 0, now = (u32)jiffies;
+   u32 delta = now - icmp_global.stamp;
bool rc = false;
+   /* Token bucket can be refilled every (HZ/50) jiffies if necessary. */
+   bool cbr = delta >= HZ / 50;
 
/* Check if token bucket is empty and cannot be refilled
 * without taking the spinlock.
 */
-   if (!icmp_global.credit) {
-   delta = min_t(u32, now - icmp_global.stamp, HZ);
-   if (delta < HZ / 50)
-   return false;
-   }
+   if (!icmp_global.credit && !cbr)
+   return false;
 
spin_lock(_global.lock);
-   delta = min_t(u32, now - icmp_global.stamp, HZ);
-   if (delta >= HZ / 50) {
-   incr = sysctl_icmp_msgs_per_sec * delta / HZ ;
+   if (cbr) {
+   incr = sysctl_icmp_msgs_per_sec * min_t(u32, delta, HZ) / HZ;
if (incr)
icmp_global.stamp = now;
}
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html