* [PATCH net-next 0/2] vxlan updates
From: Daniel Borkmann @ 2014-01-13 17:41 UTC (permalink / raw)
To: davem; +Cc: netdev
Did the split into two patches upon request from Cong Wang.
Changelog:
v1->v2:
- Removed BUG_ON as it's not needed.
v2->v3:
- Removed dev->reg_state check for netns.
v3->v4:
- Removed list_del(), we seem to do it in some places and
in some others not; we agreed it's not really necessary.
- Split patch into 2 patches, notifier part and module
unload cleanup part.
Daniel Borkmann (2):
net: vxlan: when lower dev unregisters remove vxlan dev as well
net: vxlan: properly cleanup devs on module unload
drivers/net/vxlan.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 51 insertions(+), 7 deletions(-)
--
1.7.11.7
^ permalink raw reply
* Re: [PATCH net 0/2] bonding: fix the sysfs warning when change the master's name
From: Veaceslav Falico @ 2014-01-13 17:24 UTC (permalink / raw)
To: Ding Tianhong; +Cc: Jay Vosburgh, David S. Miller, Netdev, Eric Dumazet
In-Reply-To: <52D3E536.8080404@huawei.com>
On Mon, Jan 13, 2014 at 09:08:06PM +0800, Ding Tianhong wrote:
>When I change the master's name, and then rebuild the master and ensalve a nic again,
>than I got the calltrace:
>
>[329215.749344] WARNING: CPU: 0 PID: 4778 at fs/sysfs/dir.c:486 sysfs_warn_dup+0x87/0xa0()
>[329215.749347] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:03.0/0000:02:00.0/net/eth100/upper_bond0'
...snip...
>[329215.749494] [<ffffffff81205b27>] sysfs_warn_dup+0x87/0xa0
>[329215.749500] [<ffffffff81205eed>] sysfs_add_one+0x4d/0x50
>[329215.749505] [<ffffffff81206f9e>] sysfs_do_create_link_sd+0xbe/0x210
>[329215.749511] [<ffffffff812951a0>] ? sprintf+0x40/0x50
>[329215.749516] [<ffffffff8120714b>] sysfs_create_link+0x2b/0x30
>[329215.749523] [<ffffffff8140a708>] __netdev_adjacent_dev_insert+0x1b8/0x270
>[329215.749528] [<ffffffff8140a7f8>] __netdev_adjacent_dev_link_lists+0x38/0x90
>[329215.749533] [<ffffffff8140a98b>] __netdev_upper_dev_link+0x13b/0x470
>[329215.749538] [<ffffffff8141319c>] ? __ethtool_get_settings+0x5c/0x90
>[329215.749547] [<ffffffffa0722179>] ? bond_update_speed_duplex+0x29/0x70 [bonding]
>[329215.749552] [<ffffffff8140acd1>] netdev_master_upper_dev_link_private+0x11/0x20
>[329215.749561] [<ffffffffa0729246>] bond_enslave+0x806/0xe40 [bonding]
>[329215.749570] [<ffffffffa073241f>] bonding_store_slaves+0x18f/0x1c0 [bonding]
>[329215.749576] [<ffffffff813757ab>] dev_attr_store+0x1b/0x20
>[329215.749581] [<ffffffff812049cc>] sysfs_write_file+0x15c/0x1f0
>[329215.749587] [<ffffffff81188897>] vfs_write+0xc7/0x1e0
It's unrelated to bonding, as it touches any device that uses netdev_adjacent
logic.
This case (renaming stale sysfs links) should be properly handled in
dev_change_name().
^ permalink raw reply
* [PATCH net-next v2] IPv6: enable bind() to assign an anycast address
From: Francois-Xavier Le Bail @ 2014-01-13 16:59 UTC (permalink / raw)
To: netdev
Cc: Hannes Frederic Sowa, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki Yoshifuji, Patrick McHardy,
Francois-Xavier Le Bail
- Use ipv6_chk_acast_addr_src() in inet6_bind().
Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
---
Tested with SOCK_DGRAM and SOCK_STREAM sockets.
Tested with link-local and global anycast addresses.
net/ipv6/af_inet6.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index c921d5d..68b81e9 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -347,7 +347,9 @@ int inet6_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
if (!(addr_type & IPV6_ADDR_MULTICAST)) {
if (!(inet->freebind || inet->transparent) &&
!ipv6_chk_addr(net, &addr->sin6_addr,
- dev, 0)) {
+ dev, 0) &&
+ !ipv6_chk_acast_addr_src(net, dev,
+ &addr->sin6_addr)) {
err = -EADDRNOTAVAIL;
goto out_unlock;
}
^ permalink raw reply related
* [PATCH net-next] IPv6: add a function to check for a valid anycast source address
From: Francois-Xavier Le Bail @ 2014-01-13 16:44 UTC (permalink / raw)
To: netdev
Cc: Hannes Frederic Sowa, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki Yoshifuji, Patrick McHardy,
Francois-Xavier Le Bail
- Add ipv6_chk_acast_addr_src() to check if an anycast address is link-local
on given interface or is global (on any interface).
Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
---
include/net/addrconf.h | 5 +++--
net/ipv6/anycast.c | 11 +++++++++++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 66c4a44..50e39a8 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -205,8 +205,9 @@ void ipv6_sock_ac_close(struct sock *sk);
int ipv6_dev_ac_inc(struct net_device *dev, const struct in6_addr *addr);
int __ipv6_dev_ac_dec(struct inet6_dev *idev, const struct in6_addr *addr);
bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
- const struct in6_addr *addr);
-
+ const struct in6_addr *addr);
+bool ipv6_chk_acast_addr_src(struct net *net, struct net_device *dev,
+ const struct in6_addr *addr);
/* Device notifier */
int register_inet6addr_notifier(struct notifier_block *nb);
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 5a80f15..4f2c62a 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -383,6 +383,17 @@ bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
return found;
}
+/* check if address is link-local on given interface
+ * or is global (on any interface)
+ */
+bool ipv6_chk_acast_addr_src(struct net *net, struct net_device *dev,
+ const struct in6_addr *addr)
+{
+ if (ipv6_addr_type(addr) & IPV6_ADDR_LINKLOCAL)
+ return ipv6_chk_acast_dev(dev, addr);
+ else
+ return ipv6_chk_acast_addr(net, NULL, addr);
+}
#ifdef CONFIG_PROC_FS
struct ac6_iter_state {
^ permalink raw reply related
* Re: [PATCH v4 0/3] Send audit/procinfo/cgroup data in socket-level control message
From: Tejun Heo @ 2014-01-13 16:55 UTC (permalink / raw)
To: Jan Kaluza
Cc: rgb-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
eparis-H+wXaHxf7aLQT0dZR+AlfA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
cgroups-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1389600109-30739-1-git-send-email-jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hello,
On Mon, Jan 13, 2014 at 09:01:46AM +0100, Jan Kaluza wrote:
> this patchset against net-next (applies also to linux-next) adds 3 new types
> of "Socket"-level control message (SCM_AUDIT, SCM_PROCINFO and SCM_CGROUP).
>
> Server-like processes in many cases need credentials and other
> metadata of the peer, to decide if the calling process is allowed to
> request a specific action, or the server just wants to log away this
> type of information for auditing tasks.
>
> The current practice to retrieve such process metadata is to look that
> information up in procfs with the $PID received over SCM_CREDENTIALS.
> This is sufficient for long-running tasks, but introduces a race which
> cannot be worked around for short-living processes; the calling
> process and all the information in /proc/$PID/ is gone before the
> receiver of the socket message can look it up.
>
> Changes introduced in this patchset can also increase performance
> of such server-like processes, because current way of opening and
> parsing /proc/$PID/* files is much more expensive than receiving these
> metadata using SCM.
Closing the race sounds like a good idea to me. What do net people
think?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v4 3/3] Send cgroup_path in SCM_CGROUP
From: Tejun Heo @ 2014-01-13 16:52 UTC (permalink / raw)
To: Jan Kaluza
Cc: rgb-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
eparis-H+wXaHxf7aLQT0dZR+AlfA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
cgroups-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1389600109-30739-4-git-send-email-jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Mon, Jan 13, 2014 at 09:01:49AM +0100, Jan Kaluza wrote:
> Server-like processes in many cases need credentials and other
> metadata of the peer, to decide if the calling process is allowed to
> request a specific action, or the server just wants to log away this
> type of information for auditing tasks.
>
> The current practice to retrieve such process metadata is to look that
> information up in procfs with the $PID received over SCM_CREDENTIALS.
> This is sufficient for long-running tasks, but introduces a race which
> cannot be worked around for short-living processes; the calling
> process and all the information in /proc/$PID/ is gone before the
> receiver of the socket message can look it up.
>
> This introduces a new SCM type called SCM_CGROUP to allow the direct
> attaching of "cgroup_path" to SCM, which is significantly more
> efficient and will reliably avoid the race with the round-trip over
> procfs.
>
> Signed-off-by: Jan Kaluza <jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
For cgroup related part:
Acked-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] sh_eth: fix garbled TX error message
From: Joe Perches @ 2014-01-13 16:51 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Simon Horman, netdev, linux-sh
In-Reply-To: <52D41117.3040809@cogentembedded.com>
On Mon, 2014-01-13 at 20:15 +0400, Sergei Shtylyov wrote:
> On 13-012014 5:24, Joe Perches wrote:
> >>> sh_eth_error() in case of a TX error tries to print a message using 2 dev_err()
> >>> calls with the first string not finished by '\n', so that the resulting message
> >>> would inevitably come out garbled, with something like "3net eth0: " inserted
> >>> in the middle. Avoid that by merging 2 calls into one.
>
> > I believe this interleaving should not happen since
> > commit e28d713704117bca0820c732210df6075b09f13b
> > (2.6.31 days)
>
> I believe you have given me the wrong commit, which has nothing to do the
> the newline problem per se. It just adds KERN_DEFAULT. I was able to find the
> correct commit though: it's the parent of the commit you cited,
Yeah, I was just scanning the printk commit logs
and looked for the first one that said something
like force newline.
> I should have tested my assumption beforehand...
Always a good thing.
> (I'd like to merge these
> dev_err() calls still though).
Yes, the dev_err calls should be merged.
About the other stuff, what/when ever...
cheers, Joe
^ permalink raw reply
* Re: [PATCH 0/2] tun: add the RFS support
From: Tom Herbert @ 2014-01-13 16:49 UTC (permalink / raw)
To: Zhi Yong Wu; +Cc: David Miller, Linux Netdev List, Eric Dumazet, Zhi Yong Wu
In-Reply-To: <CAEH94LjdMyZ_SVf5YvzqEhPzYanFQUwLsm+e8Hp_Y5XU4_hkeA@mail.gmail.com>
On Mon, Jan 13, 2014 at 5:29 AM, Zhi Yong Wu <zwu.kernel@gmail.com> wrote:
> On Wed, Jan 1, 2014 at 6:33 AM, Tom Herbert <therbert@google.com> wrote:
>> Zhi,
> HI, Tom
>>
>> Thanks for following up on these patches. It would still be nice to
>> have performance numbers to show the impact. These will be helpful for
>> the next task of integrating RFS into virtio-net.
> I don't get why RFS need to be integrated into virtio-net since
> virtio-net has supported mq. Can you give some clue? thanks.
>
In this case RFS would be the mechanism for selecting the RX queue. We
can either use the tun approach which is to match the RX queue to the
TX queue for a flow, or expose it as accelerated RFS to the guest.
Fine grained control of the queue selection should have value.
>>
>> Tom
>>
>> On Tue, Dec 31, 2013 at 10:32 AM, David Miller <davem@davemloft.net> wrote:
>>> From: Zhi Yong Wu <zwu.kernel@gmail.com>
>>> Date: Sun, 22 Dec 2013 18:54:30 +0800
>>>
>>>> Since Tom Herbert's hash related patchset was modified and got merged,
>>>> his pachset about adding support for RFS on tun flows also need to get
>>>> adjusted accordingly. I tried to update them, and before i will start
>>>> to do some perf tests, i hope to get one correct code base, so it's time
>>>> to post them out now. Any constructive comments are welcome, thanks.
>>>
>>> Series applied to net-next, thanks.
>
>
>
> --
> Regards,
>
> Zhi Yong Wu
^ permalink raw reply
* Re: [RFC net] tcp: metrics: Avoid duplicate entries with the same destination-IP
From: Eric Dumazet @ 2014-01-13 16:47 UTC (permalink / raw)
To: Christoph Paasch; +Cc: netdev, David Miller
In-Reply-To: <1389626736-3143-1-git-send-email-christoph.paasch@uclouvain.be>
On Mon, 2014-01-13 at 16:25 +0100, Christoph Paasch wrote:
> Another solution might be to leave tcp_get_metrics() as it is, and in
> tcpm_new do another call to __tcp_get_metrics() while holding the
> spin-lock. We would then check __tcp_get_metrics twice for new entries
> but we won't hold the spin-lock needlessly anymore.
This is the only solution if you want to fix this.
Cost of lookup are the cache line misses.
Avoiding the spinlock is a must.
The second 'lookup' is basically free, as the first one have populated
cpu caches.
^ permalink raw reply
* Re: [PATCH net-next] IPv6: enable bind() to assign an anycast address
From: François-Xavier Le Bail @ 2014-01-13 16:43 UTC (permalink / raw)
To: netdev
Cc: Hannes Frederic Sowa, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki Yoshifuji, Patrick McHardy,
Francois-Xavier Le Bail
In-Reply-To: <1389377544-3119-1-git-send-email-fx.lebail@yahoo.com>
On Fri, 1/10/14, Francois-Xavier Le Bail <fx.lebail@yahoo.com> wrote:
> - Add ipv6_chk_acast_addr_src() to check if an anycast address is link-local
> on given interface or is global (on any interface).
> - Use it in inet6_bind().
>
> Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
> ---
I will divide this patch in 2 patches : one for adding ipv6_chk_acast_addr_src(), one (v2) for updating bind().
^ permalink raw reply
* [PATCH 3/4] brcmsmac: delete useless variable
From: Julia Lawall @ 2014-01-13 16:17 UTC (permalink / raw)
To: Brett Rudley
Cc: kernel-janitors, Arend van Spriel, Franky (Zhenhui) Lin,
Hante Meuleman, John W. Linville, linux-wireless,
brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <1389629847-5330-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Delete a variable that is at most only assigned to a constant, but never
used otherwise.
A simplified version of the semantic patch that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
type T;
identifier i;
constant c;
@@
-T i;
<... when != i
-i = c;
...>
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
I don't know whether the comment before the removed assignment should also
be adjusted.
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index 8138f1c..9417cb5 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -7108,7 +7108,6 @@ prep_mac80211_status(struct brcms_c_info *wlc, struct d11rxhdr *rxh,
struct sk_buff *p,
struct ieee80211_rx_status *rx_status)
{
- int preamble;
int channel;
u32 rspec;
unsigned char *plcp;
@@ -7191,7 +7190,6 @@ prep_mac80211_status(struct brcms_c_info *wlc, struct d11rxhdr *rxh,
rx_status->rate_idx -= BRCMS_LEGACY_5G_RATE_OFFSET;
/* Determine short preamble and rate_idx */
- preamble = 0;
if (is_cck_rate(rspec)) {
if (rxh->PhyRxStatus_0 & PRXS0_SHORTH)
rx_status->flag |= RX_FLAG_SHORTPRE;
^ permalink raw reply related
* [PATCH 1/4] ksz884x: delete useless variable
From: Julia Lawall @ 2014-01-13 16:17 UTC (permalink / raw)
To: netdev; +Cc: kernel-janitors, linux-kernel
In-Reply-To: <1389629847-5330-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Delete a variable that is at most only assigned to a constant, but never
used otherwise. In this code, it is the variable result that is used for
the return code, not rc.
A simplified version of the semantic patch that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
type T;
identifier i;
constant c;
@@
-T i;
<... when != i
-i = c;
...>
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/net/ethernet/micrel/ksz884x.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ksz884x.c b/drivers/net/ethernet/micrel/ksz884x.c
index 8e9dad7..ce84dc2 100644
--- a/drivers/net/ethernet/micrel/ksz884x.c
+++ b/drivers/net/ethernet/micrel/ksz884x.c
@@ -5853,15 +5853,12 @@ static int netdev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
struct dev_info *hw_priv = priv->adapter;
struct ksz_hw *hw = &hw_priv->hw;
struct ksz_port *port = &priv->port;
- int rc;
int result = 0;
struct mii_ioctl_data *data = if_mii(ifr);
if (down_interruptible(&priv->proc_sem))
return -ERESTARTSYS;
- /* assume success */
- rc = 0;
switch (cmd) {
/* Get address of MII PHY in use. */
case SIOCGMIIPHY:
^ permalink raw reply related
* [PATCH 0/4] delete useless variable
From: Julia Lawall @ 2014-01-13 16:17 UTC (permalink / raw)
To: brcm80211-dev-list
Cc: devel, linux-fbdev, kernel-janitors, linux-wireless, linux-kernel,
netdev
These patches delete declarations and initializations of variables that are
only assigned to constants but never used otherwise.
The complete semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
type T;
identifier i,i2;
position p;
@@
T i@p;
...
i = i2
@@
type r.T;
identifier r.i;
constant c;
position p != r.p;
@@
-T i@p;
<... when != i
-i = c;
...>
// </smpl>
^ permalink raw reply
* Re: [PATCH] xprtrdma: silence frame size warning
From: Chuck Lever @ 2014-01-13 16:17 UTC (permalink / raw)
To: Trond Myklebust, Paul Bolle
Cc: J. Bruce Fields, Miller David S., Linux NFS Mailing List, netdev,
LKML Kernel
In-Reply-To: <CDD9CEF2-F91A-4ABA-8DA7-53AF8A749194@primarydata.com>
Hi-
On Jan 13, 2014, at 10:59 AM, Trond Myklebust <trond.myklebust@primarydata.com> wrote:
>
> On Jan 13, 2014, at 10:45, Paul Bolle <pebolle@tiscali.nl> wrote:
>
>> Building verbs.o on 32 bits x86, with CONFIG_FRAME_WARN set to 1024, its
>> default value, triggers this GCC warning:
>> net/sunrpc/xprtrdma/verbs.c: In function ‘rpcrdma_register_default_external’:
>> net/sunrpc/xprtrdma/verbs.c:1774:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>
>> Silence this warning by allocating "ipb" dynamically.
>>
>> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
>> ---
>> 0) Compile tested only (on 32 bits x86). I don't have access to
>> Infiniband hardware.
>>
>> 1) Please note that this is not a new warning. The oldest build log I
>> have still available on this machine is for a v3.8 rc, and it already
>> showed this warning.
>>
>> 2) I do hope my choice for the GFP_KERNEL flag is correct here.
>>
>> net/sunrpc/xprtrdma/verbs.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
>> index 93726560..939ccc8 100644
>> --- a/net/sunrpc/xprtrdma/verbs.c
>> +++ b/net/sunrpc/xprtrdma/verbs.c
>> @@ -1736,11 +1736,14 @@ rpcrdma_register_default_external(struct rpcrdma_mr_seg *seg,
>> int mem_priv = (writing ? IB_ACCESS_REMOTE_WRITE :
>> IB_ACCESS_REMOTE_READ);
>> struct rpcrdma_mr_seg *seg1 = seg;
>> - struct ib_phys_buf ipb[RPCRDMA_MAX_DATA_SEGS];
>> + struct ib_phys_buf *ipb;
>> int len, i, rc = 0;
>>
>> if (*nsegs > RPCRDMA_MAX_DATA_SEGS)
>> *nsegs = RPCRDMA_MAX_DATA_SEGS;
>> + ipb = kmalloc(sizeof(*ipb) * *nsegs, GFP_KERNEL);
>> + if (ipb == NULL)
>> + return -ENOMEM;
>> for (len = 0, i = 0; i < *nsegs;) {
>> rpcrdma_map_one(ia, seg, writing);
>> ipb[i].addr = seg->mr_dma;
>> @@ -1770,6 +1773,7 @@ rpcrdma_register_default_external(struct rpcrdma_mr_seg *seg,
>> seg1->mr_len = len;
>> }
>> *nsegs = i;
>> + kfree(ipb);
>> return rc;
>> }
>
> Hi Paul,
>
> Unfortunately, the above could be called from a file write back context, so we cannot use GFP_KERNEL allocations. In fact, I suspect we should only use GFP_ATOMIC, and then have the rpc_task delay and retry if the allocation fails.
>
> The problem is that it looks to me as if xprt_rdma_send_request will currently fail, if we return an error from rpcrdma_register_default_external.
>
> Chuck, will you be able to look into the above issue as part of your RDMA work?
I’m building a queue of NFS/RDMA work on bugzilla.kernel.org. Let’s create a defect report there to document this, and it will get prioritized with the rest. Paul, can you do that to start us off? Product “File system”, Component “NFS”.
I can’t say that a warning on 32-bit x86 is going to be an especially high priority. However, the underlying issue of allocating arrays of data segments on the stack is something that needs extended attention, and is already in plan.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: [PATCH] sh_eth: fix garbled TX error message
From: Sergei Shtylyov @ 2014-01-13 16:15 UTC (permalink / raw)
To: Joe Perches, Simon Horman; +Cc: netdev, linux-sh
In-Reply-To: <1389576241.24849.10.camel@joe-AO722>
Hello.
On 13-012014 5:24, Joe Perches wrote:
>>> sh_eth_error() in case of a TX error tries to print a message using 2 dev_err()
>>> calls with the first string not finished by '\n', so that the resulting message
>>> would inevitably come out garbled, with something like "3net eth0: " inserted
>>> in the middle. Avoid that by merging 2 calls into one.
> I believe this interleaving should not happen since
> commit e28d713704117bca0820c732210df6075b09f13b
> (2.6.31 days)
I believe you have given me the wrong commit, which has nothing to do the
the newline problem per se. It just adds KERN_DEFAULT. I was able to find the
correct commit though: it's the parent of the commit you cited,
5fd29d6ccbc98884569d6f3105aeca70858b3e0f -- so you're probably right, and I
should have tested my assumption beforehand... (I'd like to merge these
dev_err() calls still though).
> Perhaps it'd be better to use netdev_<level> and
> netif_<level> instead of dev_<level> and pr_<level>.
Thank you, I got it the first time you suggested it, I just haven't had
time to implement it yet.
> uncompiled/untested...
Thanks for the patch. I don't agree with all of it though...
> ---
>
> drivers/net/ethernet/renesas/sh_eth.c | 63 ++++++++++++++++-------------------
> 1 file changed, 28 insertions(+), 35 deletions(-)
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index 8884107..6baad48 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
[...]
> @@ -2691,9 +2683,10 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
> /* read and set MAC address */
> read_mac_address(ndev, pd->mac_addr);
> if (!is_valid_ether_addr(ndev->dev_addr)) {
> - dev_warn(&pdev->dev,
> - "no valid MAC address supplied, using a random one.\n");
> eth_hw_addr_random(ndev);
> + dev_warn(&pdev->dev,
> + "no valid MAC address supplied, using random %pM\n",
> + ndev->dev_addr);
There's no need to print random MAC address twice. It's already printed
right below.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] xprtrdma: silence frame size warning
From: Trond Myklebust @ 2014-01-13 15:59 UTC (permalink / raw)
To: Paul Bolle, Lever Charles Edward
Cc: Dr Fields James Bruce, Miller David S., Linux NFS Mailing List,
netdev, linux-kernel
In-Reply-To: <1389627955.20467.9.camel@x41>
On Jan 13, 2014, at 10:45, Paul Bolle <pebolle@tiscali.nl> wrote:
> Building verbs.o on 32 bits x86, with CONFIG_FRAME_WARN set to 1024, its
> default value, triggers this GCC warning:
> net/sunrpc/xprtrdma/verbs.c: In function ‘rpcrdma_register_default_external’:
> net/sunrpc/xprtrdma/verbs.c:1774:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
> Silence this warning by allocating "ipb" dynamically.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> 0) Compile tested only (on 32 bits x86). I don't have access to
> Infiniband hardware.
>
> 1) Please note that this is not a new warning. The oldest build log I
> have still available on this machine is for a v3.8 rc, and it already
> showed this warning.
>
> 2) I do hope my choice for the GFP_KERNEL flag is correct here.
>
> net/sunrpc/xprtrdma/verbs.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
> index 93726560..939ccc8 100644
> --- a/net/sunrpc/xprtrdma/verbs.c
> +++ b/net/sunrpc/xprtrdma/verbs.c
> @@ -1736,11 +1736,14 @@ rpcrdma_register_default_external(struct rpcrdma_mr_seg *seg,
> int mem_priv = (writing ? IB_ACCESS_REMOTE_WRITE :
> IB_ACCESS_REMOTE_READ);
> struct rpcrdma_mr_seg *seg1 = seg;
> - struct ib_phys_buf ipb[RPCRDMA_MAX_DATA_SEGS];
> + struct ib_phys_buf *ipb;
> int len, i, rc = 0;
>
> if (*nsegs > RPCRDMA_MAX_DATA_SEGS)
> *nsegs = RPCRDMA_MAX_DATA_SEGS;
> + ipb = kmalloc(sizeof(*ipb) * *nsegs, GFP_KERNEL);
> + if (ipb == NULL)
> + return -ENOMEM;
> for (len = 0, i = 0; i < *nsegs;) {
> rpcrdma_map_one(ia, seg, writing);
> ipb[i].addr = seg->mr_dma;
> @@ -1770,6 +1773,7 @@ rpcrdma_register_default_external(struct rpcrdma_mr_seg *seg,
> seg1->mr_len = len;
> }
> *nsegs = i;
> + kfree(ipb);
> return rc;
> }
Hi Paul,
Unfortunately, the above could be called from a file write back context, so we cannot use GFP_KERNEL allocations. In fact, I suspect we should only use GFP_ATOMIC, and then have the rpc_task delay and retry if the allocation fails.
The problem is that it looks to me as if xprt_rdma_send_request will currently fail, if we return an error from rpcrdma_register_default_external.
Chuck, will you be able to look into the above issue as part of your RDMA work?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
^ permalink raw reply
* [PATCH] xprtrdma: silence frame size warning
From: Paul Bolle @ 2014-01-13 15:45 UTC (permalink / raw)
To: Trond Myklebust, J. Bruce Fields, David S. Miller
Cc: linux-nfs, netdev, linux-kernel
Building verbs.o on 32 bits x86, with CONFIG_FRAME_WARN set to 1024, its
default value, triggers this GCC warning:
net/sunrpc/xprtrdma/verbs.c: In function ‘rpcrdma_register_default_external’:
net/sunrpc/xprtrdma/verbs.c:1774:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Silence this warning by allocating "ipb" dynamically.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) Compile tested only (on 32 bits x86). I don't have access to
Infiniband hardware.
1) Please note that this is not a new warning. The oldest build log I
have still available on this machine is for a v3.8 rc, and it already
showed this warning.
2) I do hope my choice for the GFP_KERNEL flag is correct here.
net/sunrpc/xprtrdma/verbs.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
index 93726560..939ccc8 100644
--- a/net/sunrpc/xprtrdma/verbs.c
+++ b/net/sunrpc/xprtrdma/verbs.c
@@ -1736,11 +1736,14 @@ rpcrdma_register_default_external(struct rpcrdma_mr_seg *seg,
int mem_priv = (writing ? IB_ACCESS_REMOTE_WRITE :
IB_ACCESS_REMOTE_READ);
struct rpcrdma_mr_seg *seg1 = seg;
- struct ib_phys_buf ipb[RPCRDMA_MAX_DATA_SEGS];
+ struct ib_phys_buf *ipb;
int len, i, rc = 0;
if (*nsegs > RPCRDMA_MAX_DATA_SEGS)
*nsegs = RPCRDMA_MAX_DATA_SEGS;
+ ipb = kmalloc(sizeof(*ipb) * *nsegs, GFP_KERNEL);
+ if (ipb == NULL)
+ return -ENOMEM;
for (len = 0, i = 0; i < *nsegs;) {
rpcrdma_map_one(ia, seg, writing);
ipb[i].addr = seg->mr_dma;
@@ -1770,6 +1773,7 @@ rpcrdma_register_default_external(struct rpcrdma_mr_seg *seg,
seg1->mr_len = len;
}
*nsegs = i;
+ kfree(ipb);
return rc;
}
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH net-next v2 4/4] virtio-net: initial debugfs support, export mergeable rx buffer size
From: Ben Hutchings @ 2014-01-13 15:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Michael Dalton, Jason Wang, David S. Miller, netdev, Eric Dumazet,
Rusty Russell, lf-virt
In-Reply-To: <20140113094018.GA22726@redhat.com>
On Mon, 2014-01-13 at 11:40 +0200, Michael S. Tsirkin wrote:
> On Sun, Jan 12, 2014 at 03:32:28PM -0800, Michael Dalton wrote:
[...]
> > The last issue is how the rx_queue_attribute 'show' function
> > implementation for mergeable_rx_buffer_size will access the appropriate
> > per-receive queue EWMA data. The arguments to the show function will be
> > the netdev_rx_queue and the attribute itself. We can get to the
> > struct net_device from the netdev_rx_queue. If we extended
> > netdev_rx_queue to indicate the queue_index or to store a void *priv_data
> > pointer, that would be sufficient to allow us to resolve this issue.
>
> Hmm netdev_rx_queue is not defined unless CONFIG_RPS is set.
> Maybe we should use a different structure.
[...]
I don't think RPS should own this structure. It's just that there are
currently no per-RX-queue attributes other than those defined by RPS.
By the way, CONFIG_RPS is equivalent to CONFIG_SMP so will likely be
enabled already in most places where virtio_net is used.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v4 0/2] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes
From: Jiri Pirko @ 2014-01-13 15:31 UTC (permalink / raw)
To: David Miller; +Cc: thaller, hannes, netdev, stephen, dcbw
In-Reply-To: <20140110.181030.2081631538801450145.davem@davemloft.net>
Sat, Jan 11, 2014 at 12:10:30AM CET, davem@davemloft.net wrote:
>From: Thomas Haller <thaller@redhat.com>
>Date: Thu, 9 Jan 2014 01:30:02 +0100
>
>> v1 -> v2: add a second commit, handling NOPREFIXROUTE in ip6_del_addr.
>> v2 -> v3: reword commit messages, code comments and some refactoring.
>> v3 -> v4: refactor, rename variables, add enum
>>
>> Thomas Haller (2):
>> ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of
>> IP6 routes
>> ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE
>
>Series applied, thanks Thomas.
Hi Dave. Have you pushed this already? I can't see these patches in
net-next.
Thanks
^ permalink raw reply
* [RFC net] tcp: metrics: Avoid duplicate entries with the same destination-IP
From: Christoph Paasch @ 2014-01-13 15:25 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
Note: This patch is based on "net" and so the source-IP is not yet part
of the tcp-metrics.
Because the tcp-metrics is an RCU-list, it may be that two
soft-interrupts are inside __tcp_get_metrics() for the same
destination-IP at the same time. If this destination-IP is not yet part of
the tcp-metrics, both soft-interrupts will end up in tcpm_new and create
a new entry for this IP.
So, we will have two tcp-metrics with the same destination-IP in the list.
This patch now takes the tcp_metrics_lock before calling
__tcp_get_metrics().
I post this as an RFC, because this patch will make the TCP-stack take
the tcp_metrics_lock even if the metric is already in the cache.
I tested it with apache-benchmark on a short file with
ab -c 100 -n 100000 server/1KB
IMO this should stress the code most, but there was no significant
performance regression.
Another solution might be to leave tcp_get_metrics() as it is, and in
tcpm_new do another call to __tcp_get_metrics() while holding the
spin-lock. We would then check __tcp_get_metrics twice for new entries
but we won't hold the spin-lock needlessly anymore.
So, it's a tradeoff between taking the tcp_metrics_lock more often vs.
calling __tcp_get_metrics twice for new entries.
Suggestions are very welcome.
Fixes: 51c5d0c4b169b (tcp: Maintain dynamic metrics in local cache.)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
net/ipv4/tcp_metrics.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 06493736fbc8..7748a5d9f37a 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -138,7 +138,6 @@ static struct tcp_metrics_block *tcpm_new(struct dst_entry *dst,
struct tcp_metrics_block *tm;
struct net *net;
- spin_lock_bh(&tcp_metrics_lock);
net = dev_net(dst->dev);
if (unlikely(reclaim)) {
struct tcp_metrics_block *oldest;
@@ -153,7 +152,7 @@ static struct tcp_metrics_block *tcpm_new(struct dst_entry *dst,
} else {
tm = kmalloc(sizeof(*tm), GFP_ATOMIC);
if (!tm)
- goto out_unlock;
+ return NULL;
}
tm->tcpm_addr = *addr;
@@ -164,8 +163,6 @@ static struct tcp_metrics_block *tcpm_new(struct dst_entry *dst,
rcu_assign_pointer(net->ipv4.tcp_metrics_hash[hash].chain, tm);
}
-out_unlock:
- spin_unlock_bh(&tcp_metrics_lock);
return tm;
}
@@ -303,6 +300,8 @@ static struct tcp_metrics_block *tcp_get_metrics(struct sock *sk,
net = dev_net(dst->dev);
hash = hash_32(hash, net->ipv4.tcp_metrics_hash_log);
+ spin_lock_bh(&tcp_metrics_lock);
+
tm = __tcp_get_metrics(&addr, net, hash);
reclaim = false;
if (tm == TCP_METRICS_RECLAIM_PTR) {
@@ -314,6 +313,8 @@ static struct tcp_metrics_block *tcp_get_metrics(struct sock *sk,
else
tcpm_check_stamp(tm, dst);
+ spin_unlock_bh(&tcp_metrics_lock);
+
return tm;
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH net] net: avoid reference counter overflows on fib_rules in multicast forwarding
From: Eric Dumazet @ 2014-01-13 15:18 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Bob Falken, Julian Anastasov, netdev, kaber, tgraf
In-Reply-To: <20140113014522.GH6586@order.stressinduktion.org>
On Mon, 2014-01-13 at 02:45 +0100, Hannes Frederic Sowa wrote:
> Bob Falken reported that after 4G packets, multicast forwarding stopped
> working. This was because of a rule reference counter overflow which
> freed the rule as soon as the overflow happend.
>
> This patch solves this by adding the FIB_LOOKUP_NOREF flag to
> fib_rules_lookup calls. This is safe even from non-rcu locked sections
> as in this case the flag only implies not taking a reference to the rule,
> which we don't need at all.
We need to not forget this when/if we remove FIB_LOOKUP_NOREF flag,
as all callers use it : We'll have to keep rcu_read_lock() in
fib_rules_lookup()
>
> Rules only hold references to the namespace, which are guaranteed to be
> available during the call of the non-rcu protected function reg_vif_xmit
> because of the interface reference which itself holds a reference to
> the net namespace.
>
> Fixes: f0ad0860d01e47 ("ipv4: ipmr: support multiple tables")
> Fixes: d1db275dd3f6e4 ("ipv6: ip6mr: support multiple tables")
> Reported-by: Bob Falken <NetFestivalHaveFun@gmx.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Thomas Graf <tgraf@suug.ch>
> Cc: Julian Anastasov <ja@ssi.bg>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> Bob Falken already tested this patch, as it is similar to my first
> attempt but the additional and similar fix for ipv6.
>
> We need an additional fix for kernels without FIB_LOOKUP_NOREF, but I'll
> move that to tomorrow, as it is already late here.
Acked-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* [PATCH net-next] IPv6: move the anycast_src_echo_reply sysctl to netns_sysctl_ipv6
From: Francois-Xavier Le Bail @ 2014-01-13 14:59 UTC (permalink / raw)
To: netdev
Cc: Hannes Frederic Sowa, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki Yoshifuji, Patrick McHardy,
Francois-Xavier Le Bail
This change move anycast_src_echo_reply sysctl with other ipv6 sysctls.
Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
---
include/net/netns/ipv6.h | 2 +-
net/ipv6/icmp.c | 2 +-
net/ipv6/sysctl_net_ipv6.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index 76fc7d1..592fecd 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -28,6 +28,7 @@ struct netns_sysctl_ipv6 {
int ip6_rt_mtu_expires;
int ip6_rt_min_advmss;
int icmpv6_time;
+ int anycast_src_echo_reply;
};
struct netns_ipv6 {
@@ -73,7 +74,6 @@ struct netns_ipv6 {
#endif
atomic_t dev_addr_genid;
atomic_t rt_genid;
- int anycast_src_echo_reply;
};
#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6)
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 9a809a4..13640f2 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -557,7 +557,7 @@ static void icmpv6_echo_reply(struct sk_buff *skb)
saddr = &ipv6_hdr(skb)->daddr;
if (!ipv6_unicast_destination(skb) &&
- !(net->ipv6.anycast_src_echo_reply &&
+ !(net->ipv6.sysctl.anycast_src_echo_reply &&
ipv6_anycast_destination(skb)))
saddr = NULL;
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 6b6a2c8..b51b268 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -26,7 +26,7 @@ static struct ctl_table ipv6_table_template[] = {
},
{
.procname = "anycast_src_echo_reply",
- .data = &init_net.ipv6.anycast_src_echo_reply,
+ .data = &init_net.ipv6.sysctl.anycast_src_echo_reply,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec
@@ -58,7 +58,7 @@ static int __net_init ipv6_sysctl_net_init(struct net *net)
if (!ipv6_table)
goto out;
ipv6_table[0].data = &net->ipv6.sysctl.bindv6only;
- ipv6_table[1].data = &net->ipv6.anycast_src_echo_reply;
+ ipv6_table[1].data = &net->ipv6.sysctl.anycast_src_echo_reply;
ipv6_route_table = ipv6_route_sysctl_init(net);
if (!ipv6_route_table)
^ permalink raw reply related
* Re: [PATCH] sctp: remove a redundant NULL check
From: Neil Horman @ 2014-01-13 14:02 UTC (permalink / raw)
To: Dan Carpenter
Cc: Vlad Yasevich, David S. Miller, linux-sctp, netdev,
kernel-janitors
In-Reply-To: <20140113134608.GA5232@elgon.mountain>
On Mon, Jan 13, 2014 at 04:46:08PM +0300, Dan Carpenter wrote:
> It confuses Smatch when we check "sinit" for NULL and then non-NULL and
> that causes a false positive warning later.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index d32dae78a486..27f1717170c2 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -1743,7 +1743,7 @@ static int sctp_sendmsg(struct kiocb *iocb, struct sock *sk,
> * either the default or the user specified stream counts.
> */
> if (sinfo) {
> - if (!sinit || (sinit && !sinit->sinit_num_ostreams)) {
> + if (!sinit || !sinit->sinit_num_ostreams) {
> /* Check against the defaults. */
> if (sinfo->sinfo_stream >=
> sp->initmsg.sinit_num_ostreams) {
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" 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 net-next] ipv4: remove the useless argument from ip_tunnel_hash()
From: Sergei Shtylyov @ 2014-01-13 13:55 UTC (permalink / raw)
To: Duan Jiong, David Miller; +Cc: netdev
In-Reply-To: <52D2689A.4040800@cn.fujitsu.com>
Hello.
On 12-01-2014 14:04, Duan Jiong wrote:
> Since commit c544193214 introduced function ip_tunnel_hash(), the argument
Please also specify that commit's summary line in parens.
> itn is no longer in use, so remove it.
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/1] When timestamping is enabled, stmmac_tx_clean will call stmmac_get_tx_hwtstamp to get tx TS. It's possible that skb is NULL because there are other network frames that use several descriptors. So we must return immediately in stmmac_get_tx_hwtstamp if skb is NULL to avoid system crash.
From: Bruce Liu @ 2014-01-13 13:54 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: peppe.cavallaro, netdev, linux-kernel
In-Reply-To: <52D27EB4.9050909@redhat.com>
On Sun, Jan 12, 2014 at 12:38:28PM +0100, Daniel Borkmann wrote:
> On 01/12/2014 10:39 AM, Bruce Liu wrote:
> > When timestamping is enabled, stmmac_tx_clean will call stmmac_get_tx_hwtstamp to get tx TS.
> > It's possible that skb is NULL because there are other network frames that use several descriptors.
> > So we must return immediately in stmmac_get_tx_hwtstamp if skb is NULL to avoid system crash.
> >
> >
> >Signed-off-by: Bruce Liu <damuzi000@gmail.com>
>
> Please see Documentation/SubmittingPatches +489
>
> You subject line is way too long and should just be something like:
>
> [PATCH net-next] net: stmmac: fix NULL pointer dereference in stmmac_get_tx_hwtstamp
>
> Don't indent your actual commit message with whitespaces as prefix,
> and do a line break after around 70 chars.
>
> Btw, I mentioned net-next in the subject since merge window will
> open soon anyway.
>
Thanks, and I'll resend the patch.
Bruce.
^ 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