* Re: [v3, 07/10] fsl/fman_port: support getting timestamp
From: kbuild test robot @ 2018-06-08 8:39 UTC (permalink / raw)
To: Yangbo Lu
Cc: kbuild-all, netdev, madalin.bucur, Richard Cochran, Rob Herring,
Shawn Guo, David S . Miller, devicetree, linuxppc-dev,
linux-arm-kernel, linux-kernel, Yangbo Lu
In-Reply-To: <20180607092050.46128-8-yangbo.lu@nxp.com>
Hi Yangbo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on next-20180608]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yangbo-Lu/Support-DPAA-PTP-clock-and-timestamping/20180608-131649
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/freescale/fman/fman_port.c:879:26: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:879:26: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1035:36: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1247:17: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1249:17: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1249:17: sparse: expression using sizeof(void)
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
vim +1739 drivers/net/ethernet/freescale/fman/fman_port.c
1733
1734 int fman_port_get_tstamp(struct fman_port *port, const void *data, u64 *tstamp)
1735 {
1736 if (port->buffer_offsets.time_stamp_offset == ILLEGAL_BASE)
1737 return -EINVAL;
1738
> 1739 *tstamp = be64_to_cpu(*(u64 *)(data +
1740 port->buffer_offsets.time_stamp_offset));
1741
1742 return 0;
1743 }
1744 EXPORT_SYMBOL(fman_port_get_tstamp);
1745
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Kristian Evensen @ 2018-06-08 8:41 UTC (permalink / raw)
To: Tobias Hommel; +Cc: Steffen Klassert, Markus Berner, Network Development
In-Reply-To: <20180606160318.cg556jqobvd5z3ja@delI>
Hi,
On Wed, Jun 6, 2018 at 6:03 PM, Tobias Hommel <netdev-list@genoetigt.de> wrote:
> Sorry no progress until now, I currently do not get time to have a deeper look
> into that. We're back to 4.1.6 right now.
Thanks for letting me know. In the project I am currently involved in,
we unfortunately don't have the option of reverting the kernel, so we
are finding ways to live with the error. We have been looking into the
error a bit more, and have made the following observations:
* First of all, as discussed earlier in the thread, the error is
triggered by dst_orig being NULL. Our current work-around is just to
return from xfrm_lookup if dst_orig is NULL and this seems to work
fine, the error doesn't happen that often (in our use-cases at least).
* The machine we use for testing (and where we first saw the error) is
used as initiator.
* When we compare the logs from Strongswan with the ones from the
kernel, it seems that the error is typically triggered when a tunnels
is teared down/about to come up. We need quite a lot of tunnels for
the error to trigger, usually around 30+. I guess this might point to
some race or some condition not being met when packets are
sent/received.
* We see the error much more frequently when hardware encryption is enabled.
* Yesterday, we upgraded the kernel from 4.14.34 to 4.14.48, and the
error happens much less frequently. I see that 4.14.48 includes
several IPsec fixes (for example the previously mentioned ("xfrm: Fix
a race in the xdst pcpu cache.")).
BR,
Kristian
^ permalink raw reply
* Re: INFO: task hung in ip6gre_exit_batch_net
From: Kirill Tkhai @ 2018-06-08 8:43 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Christian Brauner, David Miller, David Ahern,
Florian Westphal, Jiri Benc, LKML, Xin Long, mschiffer, netdev,
syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <CACT4Y+Zo1e3VFEtXRUToM6Gk_pD7egdi6c-VbAhCOc-=cdfJWA@mail.gmail.com>
On 08.06.2018 11:38, Dmitry Vyukov wrote:
> On Fri, Jun 8, 2018 at 10:31 AM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>>>>>>>>> Hi, Dmirty!
>>>>>>>>>>
>>>>>>>>>> On 04.06.2018 18:22, Dmitry Vyukov wrote:
>>>>>>>>>>> On Mon, Jun 4, 2018 at 5:03 PM, syzbot
>>>>>>>>>>> <syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com> wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> syzbot found the following crash on:
>>>>>>>>>>>>
>>>>>>>>>>>> HEAD commit: bc2dbc5420e8 Merge branch 'akpm' (patches from Andrew)
>>>>>>>>>>>> git tree: upstream
>>>>>>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=164e42b7800000
>>>>>>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
>>>>>>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bf78a74f82c1cf19069e
>>>>>>>>>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>>>>>>>>>>
>>>>>>>>>>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>>>>>>>>>>
>>>>>>>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>>>>>>>>>> Reported-by: syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com
>>>>>>>>>>>
>>>>>>>>>>> Another hang on rtnl lock:
>>>>>>>>>>>
>>>>>>>>>>> #syz dup: INFO: task hung in netdev_run_todo
>>>>>>>>>>>
>>>>>>>>>>> May be related to "unregister_netdevice: waiting for DEV to become free":
>>>>>>>>>>> https://syzkaller.appspot.com/bug?id=1a97a5bd119fd97995f752819fd87840ab9479a9
>>>>>>>>>
>>>>>>>>> netdev_wait_allrefs does not hold rtnl lock during waiting, so it must
>>>>>>>>> be something different.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Any other explanations for massive hangs on rtnl lock for minutes?
>>>>>>>>>>
>>>>>>>>>> To exclude the situation, when a task exists with rtnl_mutex held:
>>>>>>>>>>
>>>>>>>>>> would the pr_warn() from print_held_locks_bug() be included in the console output
>>>>>>>>>> if they appear?
>>>>>>>>>
>>>>>>>>> Yes, everything containing "WARNING:" is detected as bug.
>>>>>>>>
>>>>>>>> OK, then dead task not releasing the lock is excluded.
>>>>>>>>
>>>>>>>> One more assumption: someone corrupted memory around rtnl_mutex and it looks like locked.
>>>>>>>> (I track lockdep "(rtnl_mutex){+.+.}" prints in initial message as "nobody owns rtnl_mutex").
>>>>>>>> There may help a crash dump of the VM.
>>>>>>>
>>>>>>> I can't find any legend for these +'s and .'s, but {+.+.} is present
>>>>>>> in large amounts in just any task hung report for different mutexes,
>>>>>>> so I would not expect that it means corruption.
>>>>>>>
>>>>>>> Are dozens of known corruptions that syzkaller can trigger. But
>>>>>>> usually they are reliably caught by KASAN. If any of them would lead
>>>>>>> to silent memory corruption, we would got dozens of assorted crashes
>>>>>>> throughout the kernel. We've seen that at some points, but not
>>>>>>> recently. So I would assume that memory is not corrupted in all these
>>>>>>> cases:
>>>>>>> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
>>>>>>
>>>>>> This BUG clarifies the {+.+.}:
>>>>>>
>>>>>> 4 locks held by kworker/0:145/381:
>>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] work_static include/linux/workqueue.h:198 [inline]
>>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_data kernel/workqueue.c:619 [inline]
>>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
>>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] process_one_work+0xb12/0x1bb0 kernel/workqueue.c:2084
>>>>>> #1: ((work_completion)(&data->destroy_work)){+.+.}, at: [<00000000bbdd2115>] process_one_work+0xb89/0x1bb0 kernel/workqueue.c:2088
>>>>>> #2: (rtnl_mutex){+.+.}, at: [<000000009c9d14f8>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
>>>>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] exp_funnel_lock kernel/rcu/tree_exp.h:272 [inline]
>>>>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] _synchronize_rcu_expedited.constprop.72+0x9fa/0xac0 kernel/rcu/tree_exp.h:596
>>>>>>
>>>>>> There we have rtnl_mutex locked and the {..} is like above. It's definitely locked
>>>>>> since there is one more lock after it.
>>>>>>
>>>>>> This BUG happen because of there are many rtnl_mutex waiters while owner
>>>>>> is synchronizing RCU. Rather clear for me in comparison to the topic's hung.
>>>>>
>>>>>
>>>>> You mean that it's not hanged, but rather needs more than 2 minutes to
>>>>> complete, right?
>>>>
>>>> Yeah, I think, this is possible. I've seen the situations like that.
>>>> Let synchronize_rcu_expedited() is executed for X seconds. Then,
>>>> it's need just 120/x calls of "this function under rtnl_mutex" to make
>>>> a soft lockup of someone else who wants the mutex too.
>>>>
>>>> Also, despite the CFS is fair scheduler, in case of the calls are
>>>> made from workqueue, every work will cause sleep. So, every work
>>>> will be executed in separate worker task. Every worker will haved its
>>>> own time slice. This increases the probability these tasks will
>>>> take cpu time before the task in the header of the hang.
>>>
>>>
>>> OK, let's stick with this theory for now. Looking at the crash frequencies here:
>>> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
>>> I can actually believe that this is just flakes due to too slow execution.
>>>
>>> I've noted that we need either reduce load and/or increase timeouts:
>>> https://github.com/google/syzkaller/issues/516#issuecomment-395685629
>>
>> Hm, I'm not sure we should hide such the situations from syzbot,
>> because the load like this may occur in real life on real workload.
>> They may help us to understand whether rtnl_mutex already needs
>> a redesign came from this statistics. Also, these hungs may happen
>> in a place, which can be rewritten without rtnl_mutex, so we focus
>> attention on it.
>
> If somebody wants to act on these reports:
> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
> it's even better. The point is that testing must not have false
> positives, one way or another. If we do nothing then syzbot will
> slowly discover all 250 usages of rtnl_lock and produce unique bugs
> for them. Each and every of these bug reports will need to handled by
> somebody.
>
> Does somebody want to act on these and improve rtnl performance in
> foreseeable future?
I just analyzed this question a little bit, and it looks like only
the preparations for improving the performance will take much much time.
And the performance won't change till preparations are finished.
So, this looks like "not a foreseeable future".
Kirill
^ permalink raw reply
* Re: [PATCH] [net-next, wrong] make BPFILTER_UMH depend on X86
From: Geert Uytterhoeven @ 2018-06-08 8:57 UTC (permalink / raw)
To: Arnd Bergmann, Alexei Starovoitov
Cc: David S. Miller, Masahiro Yamada, linux-kbuild, netdev,
Linux Kernel Mailing List
In-Reply-To: <20180528153222.2037158-1-arnd@arndb.de>
Hi Arnd, Alexei,
On Mon, May 28, 2018 at 5:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> When build testing across architectures, I run into a build error on
> all targets other than X86:
>
> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump: net/bpfilter/bpfilter_umh: File format not recognized
> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objcopy:net/bpfilter/bpfilter_umh.o: Invalid bfd target
>
> The problem is that 'hostprogs' get built with 'gcc' rather than
> '$(CROSS_COMPILE)gcc', and my default gcc (as most people's) targets x86.
>
> To work around it, adding an X86 dependency gets randconfigs building
> again on my box.
>
> Clearly, this is not a good solution, since it should actually work fine
> when building native kernels on other architectures but that is now
> disabled, while cross building an x86 kernel on another host is still
> broken after my patch.
>
> What we probably want here is to try out if the compiler is able to build
> executables for the target architecture and not build the helper otherwise,
> at least when compile-testing. No idea how to do that though.
So that was done in commit 819dd92b9c0bc7bc ("bpfilter: switch to CC
from HOSTCC"), but it is not sufficient:
GEN net/bpfilter/bpfilter_umh.o
Usage: m68k-linux-gnu-objcopy [option(s)] in-file [out-file]
Copies a binary file, possibly transforming it in the process
The options are:
[...]
net/bpfilter/Makefile:29: recipe for target 'net/bpfilter/bpfilter_umh.o' failed
make[5]: *** [net/bpfilter/bpfilter_umh.o] Error 1
> --- a/net/bpfilter/Kconfig
> +++ b/net/bpfilter/Kconfig
> @@ -9,6 +9,7 @@ menuconfig BPFILTER
> if BPFILTER
> config BPFILTER_UMH
> tristate "bpfilter kernel module with user mode helper"
> + depends on X86 # actually depends on native builds
No, (currently) it does depend on X86, due to its use of:
$(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT)
with CONFIG_OUTPUT_FORMAT being defined on X86 only...
> default m
> help
> This builds bpfilter kernel module with embedded user mode helper
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v6 net] stmmac: strip all VLAN tag types when kernel 802.1Q support is selected
From: Elad Nachman @ 2018-06-08 9:19 UTC (permalink / raw)
To: Toshiaki Makita, David Miller
Cc: Jose.Abreu, f.fainelli, netdev, peppe.cavallaro, alexandre.torgue,
eladv6
In-Reply-To: <7b97acda-c9c9-2651-6803-22225d7b47f7@lab.ntt.co.jp>
stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
calling napi_gro_receive().
The function assumes VLAN tagged frames are always tagged with
802.1Q protocol, and assigns ETH_P_8021Q to the skb by hard-coding
the parameter on call to __vlan_hwaccel_put_tag() .
This causes packets not to be passed to the VLAN slave if it was created
with 802.1AD protocol
(ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100).
This fix passes the protocol from the VLAN header into
__vlan_hwaccel_put_tag() instead of using the hard-coded value of
ETH_P_8021Q.
NETIF_F_HW_VLAN_CTAG_RX check was removed and instead the strip action
is dependent upon a preprocessor define which is defined when 802.1Q
support is selected in the kernel config.
NETIF_F_HW_VLAN_STAG_RX feature was added to be in line with the driver
actual abilities.
Signed-off-by: Elad Nachman <eladn@gilat.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b65e2d1..707917d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3293,18 +3293,20 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
{
- struct ethhdr *ehdr;
+#ifdef STMMAC_VLAN_TAG_USED
+ struct vlan_ethhdr *veth;
+ __be16 vlan_proto;
u16 vlanid;
- if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
- NETIF_F_HW_VLAN_CTAG_RX &&
- !__vlan_get_tag(skb, &vlanid)) {
+ if (!__vlan_get_tag(skb, &vlanid)) {
/* pop the vlan tag */
- ehdr = (struct ethhdr *)skb->data;
- memmove(skb->data + VLAN_HLEN, ehdr, ETH_ALEN * 2);
+ veth = (struct vlan_ethhdr *)skb->data;
+ vlan_proto = veth->h_vlan_proto;
+ memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
skb_pull(skb, VLAN_HLEN);
- __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
+ __vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
}
+#endif
}
@@ -4344,7 +4346,7 @@ int stmmac_dvr_probe(struct device *device,
ndev->watchdog_timeo = msecs_to_jiffies(watchdog);
#ifdef STMMAC_VLAN_TAG_USED
/* Both mac100 and gmac support receive VLAN tag detection */
- ndev->features |= NETIF_F_HW_VLAN_CTAG_RX;
+ ndev->features |= NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_STAG_RX;
#endif
priv->msg_enable = netif_msg_init(debug, default_msg_level);
--
2.7.4
^ permalink raw reply related
* [PATCH ethtool 1/6] ethtool: fix uninitialized return value
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev
Fixes: b0fe96d ("Ethtool: Implements ETHTOOL_PHY_GTUNABLE/ETHTOOL_PHY_STUNABLE and PHY downshift")
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
ethtool.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 2e87384..e7495fe 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4723,8 +4723,8 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
{
int argc = ctx->argc;
char **argp = ctx->argp;
- int err, i;
u8 downshift_changed = 0;
+ int i;
if (argc < 1)
exit_bad_args();
@@ -4750,8 +4750,7 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
cont.ds.id = ETHTOOL_PHY_DOWNSHIFT;
cont.ds.type_id = ETHTOOL_TUNABLE_U8;
cont.ds.len = 1;
- err = send_ioctl(ctx, &cont.ds);
- if (err < 0) {
+ if (send_ioctl(ctx, &cont.ds) < 0) {
perror("Cannot Get PHY downshift count");
return 87;
}
@@ -4762,7 +4761,7 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
fprintf(stdout, "Downshift disabled\n");
}
- return err;
+ return 0;
}
static __u32 parse_reset(char *val, __u32 bitset, char *arg, __u32 *data)
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 2/6] ethtool: fix RING_VF assignment
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev, Jacob Keller
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
Fixes: 36ee712 ("ethtool: support queue and VF fields for rxclass filters")
Cc: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
rxclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rxclass.c b/rxclass.c
index ce4b382..42d122d 100644
--- a/rxclass.c
+++ b/rxclass.c
@@ -1066,7 +1066,7 @@ static int rxclass_get_val(char *str, unsigned char *p, u32 *flags,
val++;
*(u64 *)&p[opt->offset] &= ~ETHTOOL_RX_FLOW_SPEC_RING_VF;
- *(u64 *)&p[opt->offset] = (u64)val << ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF;
+ *(u64 *)&p[opt->offset] |= (u64)val << ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF;
break;
}
case OPT_RING_QUEUE: {
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 3/6] ethtool: remove unused global variable
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
Fixes: 2c2ee7a ("ethtool: Add support for sfc register dumps")
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
sfc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/sfc.c b/sfc.c
index 9478b38..b4c590f 100644
--- a/sfc.c
+++ b/sfc.c
@@ -3083,9 +3083,6 @@ static const struct efx_nic_reg_field efx_nic_reg_fields_TX_PACE[] = {
REGISTER_FIELD_BZ(TX_PACE_SB_AF),
REGISTER_FIELD_BZ(TX_PACE_SB_NOT_AF),
};
-static const struct efx_nic_reg_field efx_nic_reg_fields_TX_PACE_DROP_QID[] = {
- REGISTER_FIELD_BZ(TX_PACE_QID_DRP_CNT),
-};
static const struct efx_nic_reg_field efx_nic_reg_fields_TX_VLAN[] = {
REGISTER_FIELD_BB(TX_VLAN0),
REGISTER_FIELD_BB(TX_VLAN0_PORT0_EN),
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 4/6] ethtool: several fixes in do_gregs()
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev, David Decotigny
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
- correctly close gregs_dump_file in case of fstat() failure
- check for error from realloc
Fixes: be4c2d0 ("ethtool.c: fix dump_regs heap corruption")
Cc: David Decotigny <decot@googlers.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
ethtool.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/ethtool.c b/ethtool.c
index e7495fe..2b90984 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -3179,17 +3179,26 @@ static int do_gregs(struct cmd_context *ctx)
if (!gregs_dump_raw && gregs_dump_file != NULL) {
/* overwrite reg values from file dump */
FILE *f = fopen(gregs_dump_file, "r");
+ struct ethtool_regs *nregs;
struct stat st;
size_t nread;
if (!f || fstat(fileno(f), &st) < 0) {
fprintf(stderr, "Can't open '%s': %s\n",
gregs_dump_file, strerror(errno));
+ if (f)
+ fclose(f);
free(regs);
return 75;
}
- regs = realloc(regs, sizeof(*regs) + st.st_size);
+ nregs = realloc(regs, sizeof(*regs) + st.st_size);
+ if (!nregs) {
+ perror("Cannot allocate memory for register dump");
+ free(regs); /* was not freed by realloc */
+ return 73;
+ }
+ regs = nregs;
regs->len = st.st_size;
nread = fread(regs->data, regs->len, 1, f);
fclose(f);
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 5/6] ethtool: correctly free hkey when get_stringset() fails
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev, Gal Pressman
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
Memory allocated for 'hkey' is not freed when
get_stringset(..., ETH_SS_RSS_HASH_FUNCS...) fails.
Fixes: b888f35 ("ethtool: Support for configurable RSS hash function")
Cc: Gal Pressman <galp@mellanox.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
ethtool.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 2b90984..fb93ae8 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -3910,7 +3910,7 @@ static int do_srxfhindir(struct cmd_context *ctx, int rxfhindir_default,
static int do_srxfh(struct cmd_context *ctx)
{
struct ethtool_rxfh rss_head = {0};
- struct ethtool_rxfh *rss;
+ struct ethtool_rxfh *rss = NULL;
struct ethtool_rxnfc ring_count;
int rxfhindir_equal = 0, rxfhindir_default = 0;
struct ethtool_gstrings *hfuncs = NULL;
@@ -4064,7 +4064,8 @@ static int do_srxfh(struct cmd_context *ctx)
hfuncs = get_stringset(ctx, ETH_SS_RSS_HASH_FUNCS, 0, 1);
if (!hfuncs) {
perror("Cannot get hash functions names");
- return 1;
+ err = 1;
+ goto free;
}
for (i = 0; i < hfuncs->len && !req_hfunc ; i++) {
@@ -4078,8 +4079,8 @@ static int do_srxfh(struct cmd_context *ctx)
if (!req_hfunc) {
fprintf(stderr,
"Unknown hash function: %s\n", req_hfunc_name);
- free(hfuncs);
- return 1;
+ err = 1;
+ goto free;
}
}
@@ -4120,9 +4121,7 @@ static int do_srxfh(struct cmd_context *ctx)
}
free:
- if (hkey)
- free(hkey);
-
+ free(hkey);
free(rss);
free(hfuncs);
return err;
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 6/6] ethtool: remove unreachable code
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev, Vidya Sagar Ravipati
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
The default switch case is unreachable as the MAX_CHANNEL_NUM == 4.
Fixes: a5e73bb ("ethtool:QSFP Plus/QSFP28 Diagnostics Information Support")
Cc: Vidya Sagar Ravipati <vidya@cumulusnetworks.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
qsfp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/qsfp.c b/qsfp.c
index aecd5bb..32e195d 100644
--- a/qsfp.c
+++ b/qsfp.c
@@ -661,9 +661,6 @@ static void sff8636_dom_parse(const __u8 *id, struct sff_diags *sd)
tx_power_offset = SFF8636_TX_PWR_4_OFFSET;
tx_bias_offset = SFF8636_TX_BIAS_4_OFFSET;
break;
- default:
- printf(" Invalid channel: %d\n", i);
- break;
}
sd->scd[i].bias_cur = OFFSET_TO_U16(tx_bias_offset);
sd->scd[i].rx_power = OFFSET_TO_U16(rx_power_offset);
--
2.16.4
^ permalink raw reply related
* [PATCH] net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode
From: Vadim Lomovtsev @ 2018-06-08 9:27 UTC (permalink / raw)
To: davem, rric, sgoutham, linux-arm-kernel, netdev, linux-kernel
Cc: dnelson, Vadim Lomovtsev
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
For each network interface linux network stack issue ndo_set_rx_mode call
in order to configure MAC address filters (e.g. for multicast filtering).
Currently ThunderX NICVF driver has only one ordered workqueue to process
such requests for all VFs.
And because of that it is possible that subsequent call to
ndo_set_rx_mode would corrupt data which is currently in use
by nicvf_set_rx_mode_task. Which in turn could cause following issue:
[...]
[ 48.978341] Unable to handle kernel paging request at virtual address 1fffff0000000000
[ 48.986275] Mem abort info:
[ 48.989058] Exception class = DABT (current EL), IL = 32 bits
[ 48.994965] SET = 0, FnV = 0
[ 48.998020] EA = 0, S1PTW = 0
[ 49.001152] Data abort info:
[ 49.004022] ISV = 0, ISS = 0x00000004
[ 49.007869] CM = 0, WnR = 0
[ 49.010826] [1fffff0000000000] address between user and kernel address ranges
[ 49.017963] Internal error: Oops: 96000004 [#1] SMP
[...]
[ 49.072138] task: ffff800fdd675400 task.stack: ffff000026440000
[ 49.078051] PC is at prefetch_freepointer.isra.37+0x28/0x3c
[ 49.083613] LR is at kmem_cache_alloc_trace+0xc8/0x1fc
[...]
[ 49.272684] [<ffff0000082738f0>] prefetch_freepointer.isra.37+0x28/0x3c
[ 49.279286] [<ffff000008276bc8>] kmem_cache_alloc_trace+0xc8/0x1fc
[ 49.285455] [<ffff0000082c0c0c>] alloc_fdtable+0x78/0x134
[ 49.290841] [<ffff0000082c15c0>] dup_fd+0x254/0x2f4
[ 49.295709] [<ffff0000080d1954>] copy_process.isra.38.part.39+0x64c/0x1168
[ 49.302572] [<ffff0000080d264c>] _do_fork+0xfc/0x3b0
[ 49.307524] [<ffff0000080d29e8>] SyS_clone+0x44/0x50
[...]
This patch is to prevent such concurrent data write with spinlock.
Reported-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nic.h | 2 +
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 50 +++++++++++++++++-------
2 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 448d1fafc827..f4d81765221e 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -325,6 +325,8 @@ struct nicvf {
struct tasklet_struct qs_err_task;
struct work_struct reset_task;
struct nicvf_work rx_mode_work;
+ /* spinlock to protect workqueue arguments from concurrent access */
+ spinlock_t rx_mode_wq_lock;
/* PTP timestamp */
struct cavium_ptp *ptp_clock;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 7135db45927e..135766c4296b 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1923,17 +1923,12 @@ static int nicvf_ioctl(struct net_device *netdev, struct ifreq *req, int cmd)
}
}
-static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+static void __nicvf_set_rx_mode_task(u8 mode, struct xcast_addr_list *mc_addrs,
+ struct nicvf *nic)
{
- struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
- work.work);
- struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
union nic_mbx mbx = {};
int idx;
- if (!vf_work)
- return;
-
/* From the inside of VM code flow we have only 128 bits memory
* available to send message to host's PF, so send all mc addrs
* one by one, starting from flush command in case if kernel
@@ -1944,7 +1939,7 @@ static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
mbx.xcast.msg = NIC_MBOX_MSG_RESET_XCAST;
nicvf_send_msg_to_pf(nic, &mbx);
- if (vf_work->mode & BGX_XCAST_MCAST_FILTER) {
+ if (mode & BGX_XCAST_MCAST_FILTER) {
/* once enabling filtering, we need to signal to PF to add
* its' own LMAC to the filter to accept packets for it.
*/
@@ -1954,23 +1949,46 @@ static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
}
/* check if we have any specific MACs to be added to PF DMAC filter */
- if (vf_work->mc) {
+ if (mc_addrs) {
/* now go through kernel list of MACs and add them one by one */
- for (idx = 0; idx < vf_work->mc->count; idx++) {
+ for (idx = 0; idx < mc_addrs->count; idx++) {
mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
- mbx.xcast.data.mac = vf_work->mc->mc[idx];
+ mbx.xcast.data.mac = mc_addrs->mc[idx];
nicvf_send_msg_to_pf(nic, &mbx);
}
- kfree(vf_work->mc);
+ kfree(mc_addrs);
}
/* and finally set rx mode for PF accordingly */
mbx.xcast.msg = NIC_MBOX_MSG_SET_XCAST;
- mbx.xcast.data.mode = vf_work->mode;
+ mbx.xcast.data.mode = mode;
nicvf_send_msg_to_pf(nic, &mbx);
}
+static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+{
+ struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
+ work.work);
+ struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
+ u8 mode;
+ struct xcast_addr_list *mc;
+
+ if (!vf_work)
+ return;
+
+ /* Save message data locally to prevent them from
+ * being overwritten by next ndo_set_rx_mode call().
+ */
+ spin_lock(&nic->rx_mode_wq_lock);
+ mode = vf_work->mode;
+ mc = vf_work->mc;
+ vf_work->mc = NULL;
+ spin_unlock(&nic->rx_mode_wq_lock);
+
+ __nicvf_set_rx_mode_task(mode, mc, nic);
+}
+
static void nicvf_set_rx_mode(struct net_device *netdev)
{
struct nicvf *nic = netdev_priv(netdev);
@@ -2004,9 +2022,12 @@ static void nicvf_set_rx_mode(struct net_device *netdev)
}
}
}
+ spin_lock(&nic->rx_mode_wq_lock);
+ kfree(nic->rx_mode_work.mc);
nic->rx_mode_work.mc = mc_list;
nic->rx_mode_work.mode = mode;
- queue_delayed_work(nicvf_rx_mode_wq, &nic->rx_mode_work.work, 2 * HZ);
+ queue_delayed_work(nicvf_rx_mode_wq, &nic->rx_mode_work.work, 0);
+ spin_unlock(&nic->rx_mode_wq_lock);
}
static const struct net_device_ops nicvf_netdev_ops = {
@@ -2163,6 +2184,7 @@ static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
INIT_WORK(&nic->reset_task, nicvf_reset_task);
INIT_DELAYED_WORK(&nic->rx_mode_work.work, nicvf_set_rx_mode_task);
+ spin_lock_init(&nic->rx_mode_wq_lock);
err = register_netdev(netdev);
if (err) {
--
2.14.4
^ permalink raw reply related
* Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)
From: Michael Karcher @ 2018-06-08 9:28 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, netdev, Andrew Lunn, Finn Thain,
Florian Fainelli, Linux/m68k, Michael Karcher, Michael Karcher
In-Reply-To: <643cf1a7-b91c-bda6-d5b0-52b7f84377e6@gmail.com>
Let me add my 2 cents as main author of that code:
Michael Schmitz wrote:
> Am 08.06.2018 um 02:36 schrieb Geert Uytterhoeven:
>> So I was wondering: why is this file included, as XSURF100 selects
>> AX88796,
>> while ax88796.c includes lib8390.c anyway?
>>
>> Apparently lib8390.c is included for register definitions (provided by
>> 8390.h, and can easily be fixed), and for the __NS8390_init()
>> implementation, called below.
>
> Mostly the latter.
>
>>
>>> +static void xs100_block_output(struct net_device *dev, int count,
>>> + const unsigned char *buf, const int
>>> start_page)
>>> +{
>>
>> [...]
>>
>>> + while ((ei_inb(nic_base + EN0_ISR) & ENISR_RDC) == 0) {
>>> + if (jiffies - dma_start > 2 * HZ / 100) { /* 20ms
>>> */
>>> + netdev_warn(dev, "timeout waiting for Tx
>>> RDC.\n");
>>> + ei_local->reset_8390(dev);
>>> + ax_NS8390_init(dev, 1);
>>> + break;
>>> + }
>>> + }
>>> +
>>> + ei_outb(ENISR_RDC, nic_base + EN0_ISR); /* Ack intr. */
>>> + ei_local->dmaing &= ~0x01;
>>> +}
actually, the the block_input / block_output functions were the reason I
included the lib8390.c file. Except for xs100_write / xs100_read, they are
a verbatim copy from ax88796.c I'm not that enthusiastic about that idea
anymore, but did not get around to improve it. I added a customization
point to ax88796 for a custom block_input / block_output, because the 8390
core already provides that customization point. What I really need is a
customization point just for the 8390-remote-DMA-via-MMIO functions (i.e.
xs100_write, xs100_read) instead of the whole block transfer core that
also sets up the remote DMA engine and tries to re-initialize the card in
case of unexplained problems.
This should get rid of
- xs100_block_output
- xs100_block_input (which has the calls to ax_reset_8390 and
ax_NS8390_init)
- ax_reset_8390
- and thus the include of lib8390.c (which should be included only by
ax88796.c, not by xsurf100.c)
Regards,
Michael Karcher
^ permalink raw reply
* Re: [PATCH] [net-next, wrong] make BPFILTER_UMH depend on X86
From: Daniel Borkmann @ 2018-06-08 9:33 UTC (permalink / raw)
To: Geert Uytterhoeven, Arnd Bergmann, Alexei Starovoitov
Cc: David S. Miller, Masahiro Yamada, linux-kbuild, netdev,
Linux Kernel Mailing List
In-Reply-To: <CAMuHMdXy0uHXaGkFBh9_tr2VzmJF+8KtraTuFHJwcmqhcHs4Dg@mail.gmail.com>
Hi Geert,
On 06/08/2018 10:57 AM, Geert Uytterhoeven wrote:
> On Mon, May 28, 2018 at 5:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> When build testing across architectures, I run into a build error on
>> all targets other than X86:
>>
>> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump: net/bpfilter/bpfilter_umh: File format not recognized
>> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objcopy:net/bpfilter/bpfilter_umh.o: Invalid bfd target
>>
>> The problem is that 'hostprogs' get built with 'gcc' rather than
>> '$(CROSS_COMPILE)gcc', and my default gcc (as most people's) targets x86.
>>
>> To work around it, adding an X86 dependency gets randconfigs building
>> again on my box.
>>
>> Clearly, this is not a good solution, since it should actually work fine
>> when building native kernels on other architectures but that is now
>> disabled, while cross building an x86 kernel on another host is still
>> broken after my patch.
>>
>> What we probably want here is to try out if the compiler is able to build
>> executables for the target architecture and not build the helper otherwise,
>> at least when compile-testing. No idea how to do that though.
>
> So that was done in commit 819dd92b9c0bc7bc ("bpfilter: switch to CC
> from HOSTCC"), but it is not sufficient:
>
> GEN net/bpfilter/bpfilter_umh.o
> Usage: m68k-linux-gnu-objcopy [option(s)] in-file [out-file]
> Copies a binary file, possibly transforming it in the process
> The options are:
> [...]
>
> net/bpfilter/Makefile:29: recipe for target 'net/bpfilter/bpfilter_umh.o' failed
> make[5]: *** [net/bpfilter/bpfilter_umh.o] Error 1
>
>> --- a/net/bpfilter/Kconfig
>> +++ b/net/bpfilter/Kconfig
>> @@ -9,6 +9,7 @@ menuconfig BPFILTER
>> if BPFILTER
>> config BPFILTER_UMH
>> tristate "bpfilter kernel module with user mode helper"
>> + depends on X86 # actually depends on native builds
>
> No, (currently) it does depend on X86, due to its use of:
>
> $(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT)
>
> with CONFIG_OUTPUT_FORMAT being defined on X86 only...
That hard dependency should have been fixed with the following patch in -net tree:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=8d97ca6b6755bf7ef57d323642ca9ee80d689782
Thanks,
Daniel
^ permalink raw reply
* [PATCH net] udp: fix rx queue len reported by diag and proc interface
From: Paolo Abeni @ 2018-06-08 9:35 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Eric Dumazet, trevor.francis
After commit 6b229cf77d68 ("udp: add batching to udp_rmem_release()")
the sk_rmem_alloc field does not measure exactly anymore the
receive queue length, because we batch the rmem release. The issue
is really apparent only after commit 0d4a6608f68c ("udp: do rmem bulk
free even if the rx sk queue is empty"): the user space can easily
check for an empty socket with not-0 queue length reported by the 'ss'
tool or the procfs interface.
We need to use a custom UDP helper to report the correct queue length,
taking into account the forward allocation deficit.
Reported-by: trevor.francis@46labs.com
Fixes: 6b229cf77d68 ("UDP: add batching to udp_rmem_release()")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
include/net/transp_v6.h | 11 +++++++++--
include/net/udp.h | 5 +++++
net/ipv4/udp.c | 2 +-
net/ipv4/udp_diag.c | 2 +-
net/ipv6/datagram.c | 6 +++---
net/ipv6/udp.c | 3 ++-
6 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index c4f5caaf3778..f6a3543e5247 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -45,8 +45,15 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk, struct msghdr *msg,
struct flowi6 *fl6, struct ipcm6_cookie *ipc6,
struct sockcm_cookie *sockc);
-void ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
- __u16 srcp, __u16 destp, int bucket);
+void __ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
+ __u16 srcp, __u16 destp, int rqueue, int bucket);
+static inline void
+ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp, __u16 srcp,
+ __u16 destp, int bucket)
+{
+ __ip6_dgram_sock_seq_show(seq, sp, srcp, destp, sk_rmem_alloc_get(sp),
+ bucket);
+}
#define LOOPBACK4_IPV6 cpu_to_be32(0x7f000006)
diff --git a/include/net/udp.h b/include/net/udp.h
index 7ba0ed252c52..b1ea8b0f5e6a 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -247,6 +247,11 @@ static inline __be16 udp_flow_src_port(struct net *net, struct sk_buff *skb,
return htons((((u64) hash * (max - min)) >> 32) + min);
}
+static inline int udp_rqueue_get(struct sock *sk)
+{
+ return sk_rmem_alloc_get(sk) - READ_ONCE(udp_sk(sk)->forward_deficit);
+}
+
/* net/ipv4/udp.c */
void udp_destruct_sock(struct sock *sk);
void skb_consume_udp(struct sock *sk, struct sk_buff *skb, int len);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 3365362cac88..9bb27df4dac5 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2772,7 +2772,7 @@ static void udp4_format_sock(struct sock *sp, struct seq_file *f,
" %02X %08X:%08X %02X:%08lX %08X %5u %8d %lu %d %pK %d",
bucket, src, srcp, dest, destp, sp->sk_state,
sk_wmem_alloc_get(sp),
- sk_rmem_alloc_get(sp),
+ udp_rqueue_get(sp),
0, 0L, 0,
from_kuid_munged(seq_user_ns(f), sock_i_uid(sp)),
0, sock_i_ino(sp),
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index d0390d844ac8..d9ad986c7b2c 100644
--- a/net/ipv4/udp_diag.c
+++ b/net/ipv4/udp_diag.c
@@ -163,7 +163,7 @@ static int udp_diag_dump_one(struct sk_buff *in_skb, const struct nlmsghdr *nlh,
static void udp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
void *info)
{
- r->idiag_rqueue = sk_rmem_alloc_get(sk);
+ r->idiag_rqueue = udp_rqueue_get(sk);
r->idiag_wqueue = sk_wmem_alloc_get(sk);
}
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index a02ad100f0d7..2ee08b6a86a4 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -1019,8 +1019,8 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk,
}
EXPORT_SYMBOL_GPL(ip6_datagram_send_ctl);
-void ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
- __u16 srcp, __u16 destp, int bucket)
+void __ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
+ __u16 srcp, __u16 destp, int rqueue, int bucket)
{
const struct in6_addr *dest, *src;
@@ -1036,7 +1036,7 @@ void ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
dest->s6_addr32[2], dest->s6_addr32[3], destp,
sp->sk_state,
sk_wmem_alloc_get(sp),
- sk_rmem_alloc_get(sp),
+ rqueue,
0, 0L, 0,
from_kuid_munged(seq_user_ns(seq), sock_i_uid(sp)),
0,
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 164afd31aebf..e6645cae403e 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1523,7 +1523,8 @@ int udp6_seq_show(struct seq_file *seq, void *v)
struct inet_sock *inet = inet_sk(v);
__u16 srcp = ntohs(inet->inet_sport);
__u16 destp = ntohs(inet->inet_dport);
- ip6_dgram_sock_seq_show(seq, v, srcp, destp, bucket);
+ __ip6_dgram_sock_seq_show(seq, v, srcp, destp,
+ udp_rqueue_get(v), bucket);
}
return 0;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] [net-next, wrong] make BPFILTER_UMH depend on X86
From: Geert Uytterhoeven @ 2018-06-08 9:40 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Arnd Bergmann, Alexei Starovoitov, David S. Miller,
Masahiro Yamada, linux-kbuild, netdev, Linux Kernel Mailing List
In-Reply-To: <8c0f8cc4-b919-9b69-4144-fd216253aa24@iogearbox.net>
Hi Daniel,
On Fri, Jun 8, 2018 at 11:33 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 06/08/2018 10:57 AM, Geert Uytterhoeven wrote:
>> On Mon, May 28, 2018 at 5:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> When build testing across architectures, I run into a build error on
>>> all targets other than X86:
>>>
>>> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump: net/bpfilter/bpfilter_umh: File format not recognized
>>> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objcopy:net/bpfilter/bpfilter_umh.o: Invalid bfd target
>>>
>>> The problem is that 'hostprogs' get built with 'gcc' rather than
>>> '$(CROSS_COMPILE)gcc', and my default gcc (as most people's) targets x86.
>>>
>>> To work around it, adding an X86 dependency gets randconfigs building
>>> again on my box.
>>>
>>> Clearly, this is not a good solution, since it should actually work fine
>>> when building native kernels on other architectures but that is now
>>> disabled, while cross building an x86 kernel on another host is still
>>> broken after my patch.
>>>
>>> What we probably want here is to try out if the compiler is able to build
>>> executables for the target architecture and not build the helper otherwise,
>>> at least when compile-testing. No idea how to do that though.
>>
>> So that was done in commit 819dd92b9c0bc7bc ("bpfilter: switch to CC
>> from HOSTCC"), but it is not sufficient:
>>
>> GEN net/bpfilter/bpfilter_umh.o
>> Usage: m68k-linux-gnu-objcopy [option(s)] in-file [out-file]
>> Copies a binary file, possibly transforming it in the process
>> The options are:
>> [...]
>>
>> net/bpfilter/Makefile:29: recipe for target 'net/bpfilter/bpfilter_umh.o' failed
>> make[5]: *** [net/bpfilter/bpfilter_umh.o] Error 1
>>
>>> --- a/net/bpfilter/Kconfig
>>> +++ b/net/bpfilter/Kconfig
>>> @@ -9,6 +9,7 @@ menuconfig BPFILTER
>>> if BPFILTER
>>> config BPFILTER_UMH
>>> tristate "bpfilter kernel module with user mode helper"
>>> + depends on X86 # actually depends on native builds
>>
>> No, (currently) it does depend on X86, due to its use of:
>>
>> $(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT)
>>
>> with CONFIG_OUTPUT_FORMAT being defined on X86 only...
>
> That hard dependency should have been fixed with the following patch in -net tree:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=8d97ca6b6755bf7ef57d323642ca9ee80d689782
Thanks, confirmed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH ethtool 5/6] ethtool: correctly free hkey when get_stringset() fails
From: Gal Pressman @ 2018-06-08 9:46 UTC (permalink / raw)
To: Ivan Vecera, linville; +Cc: netdev, Gal Pressman
In-Reply-To: <20180608092010.13041-5-cera@cera.cz>
On 08-Jun-18 12:20, Ivan Vecera wrote:
> Memory allocated for 'hkey' is not freed when
> get_stringset(..., ETH_SS_RSS_HASH_FUNCS...) fails.
>
> Fixes: b888f35 ("ethtool: Support for configurable RSS hash function")
Thanks for fixing this!
Please use the first 12 characters of the sha1 in the Fixes line.
> Cc: Gal Pressman <galp@mellanox.com>
> Signed-off-by: Ivan Vecera <cera@cera.cz>
> ---
> ethtool.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/ethtool.c b/ethtool.c
> index 2b90984..fb93ae8 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -3910,7 +3910,7 @@ static int do_srxfhindir(struct cmd_context *ctx, int rxfhindir_default,
> static int do_srxfh(struct cmd_context *ctx)
> {
> struct ethtool_rxfh rss_head = {0};
> - struct ethtool_rxfh *rss;
> + struct ethtool_rxfh *rss = NULL;
> struct ethtool_rxnfc ring_count;
> int rxfhindir_equal = 0, rxfhindir_default = 0;
> struct ethtool_gstrings *hfuncs = NULL;
> @@ -4064,7 +4064,8 @@ static int do_srxfh(struct cmd_context *ctx)
> hfuncs = get_stringset(ctx, ETH_SS_RSS_HASH_FUNCS, 0, 1);
> if (!hfuncs) {
> perror("Cannot get hash functions names");
> - return 1;
> + err = 1;
> + goto free;
> }
>
> for (i = 0; i < hfuncs->len && !req_hfunc ; i++) {
> @@ -4078,8 +4079,8 @@ static int do_srxfh(struct cmd_context *ctx)
> if (!req_hfunc) {
> fprintf(stderr,
> "Unknown hash function: %s\n", req_hfunc_name);
> - free(hfuncs);
> - return 1;
> + err = 1;
> + goto free;
> }
> }
>
> @@ -4120,9 +4121,7 @@ static int do_srxfh(struct cmd_context *ctx)
> }
>
> free:
> - if (hkey)
> - free(hkey);
> -
> + free(hkey);
> free(rss);
> free(hfuncs);
> return err;
>
^ permalink raw reply
* Re: KASAN: null-ptr-deref Write in xdp_umem_unaccount_pages
From: Daniel Borkmann @ 2018-06-08 9:50 UTC (permalink / raw)
To: syzbot, bjorn.topel, davem, linux-kernel, magnus.karlsson, netdev,
syzkaller-bugs
In-Reply-To: <00000000000037bf29056e114a86@google.com>
On 06/07/2018 08:17 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 1c8c5a9d38f6 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13a72bdf800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=4f1acdf888c9d4e9
> dashboard link: https://syzkaller.appspot.com/bug?extid=979217770b09ebf5c407
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12aca2af800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=161d4ddf800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+979217770b09ebf5c407@syzkaller.appspotmail.com
#syz fix: bpf, xdp: fix crash in xdp_umem_unaccount_pages
^ permalink raw reply
* Re: [PATCH bpf-next v6 1/2] trace_helpers.c: Add helpers to poll multiple perf FDs for events
From: Toke Høiland-Jørgensen @ 2018-06-08 9:52 UTC (permalink / raw)
To: Daniel Borkmann, netdev; +Cc: Jakub Kicinski, Jesper Dangaard Brouer
In-Reply-To: <6eea45bd-6231-9cba-692a-2aefab636c7d@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> Hi Toke,
>
> On 06/06/2018 07:58 PM, Toke Høiland-Jørgensen wrote:
>> Add two new helper functions to trace_helpers that supports polling
>> multiple perf file descriptors for events. These are used to the XDP
>> perf_event_output example, which needs to work with one perf fd per CPU.
>>
>> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>
> Didn't make it in time unfortunately as bpf-next closed, please resend
> these two once merge window is over and bpf-next open again.
Will do!
-Toke
^ permalink raw reply
* Re: KASAN: use-after-free Read in bpf_csum_update
From: Daniel Borkmann @ 2018-06-08 9:52 UTC (permalink / raw)
To: syzbot, ast, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000bec587056dc547ba@google.com>
On 06/04/2018 01:36 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: bcece5dc40b9 bpf: Change bpf_fib_lookup to return -EAFNOSU..
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=161e2c6f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e4078980b886800c
> dashboard link: https://syzkaller.appspot.com/bug?extid=3d0b2441dbb71751615e
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=17cb5adf800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ebf19f800000
#syz fix: bpf: reject passing modified ctx to helper functions
^ permalink raw reply
* Re: KASAN: use-after-free Read in skb_ensure_writable
From: Daniel Borkmann @ 2018-06-08 9:53 UTC (permalink / raw)
To: syzbot, ast, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000bab429056dc547be@google.com>
On 06/04/2018 01:36 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: bcece5dc40b9 bpf: Change bpf_fib_lookup to return -EAFNOSU..
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10ee76b7800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e4078980b886800c
> dashboard link: https://syzkaller.appspot.com/bug?extid=c8504affd4fdd0c1b626
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10d926df800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1778c26f800000
#syz fix: bpf: reject passing modified ctx to helper functions
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in bpf_csum_update
From: Daniel Borkmann @ 2018-06-08 9:53 UTC (permalink / raw)
To: syzbot, ast, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000b2a7ea056dc54779@google.com>
On 06/04/2018 01:36 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 0512e0134582 Merge tag 'xfs-4.17-fixes-3' of git://git.ker..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17eb2d7b800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=968b0b23c7854c0b
> dashboard link: https://syzkaller.appspot.com/bug?extid=efae31b384d5badbd620
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=162c6def800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14fe3db7800000
#syz fix: bpf: reject passing modified ctx to helper functions
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in skb_ensure_writable
From: Daniel Borkmann @ 2018-06-08 9:54 UTC (permalink / raw)
To: syzbot, ast, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000b7be6e056dc547e8@google.com>
On 06/04/2018 01:36 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 0512e0134582 Merge tag 'xfs-4.17-fixes-3' of git://git.ker..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14956af7800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=968b0b23c7854c0b
> dashboard link: https://syzkaller.appspot.com/bug?extid=e5190cb881d8660fb1a3
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=123d9d7b800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=100329d7800000
#syz fix: bpf: reject passing modified ctx to helper functions
^ permalink raw reply
* [PATCH] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Kirill Kranke @ 2018-06-08 9:56 UTC (permalink / raw)
To: andrew, f.fainelli, davem, netdev; +Cc: Kirill Kranke
From: Kirill Kranke <kirill.kranke@gmail.com>
Current generic PHY driver does not work with TJA1100 BroadR-REACH PHY
properly. TJA1100 does not have any standard ability enabled at MII_BMSR
register. Instead it has BroadR-REACH ability at MII_ESTATUS enabled, which
is not handled by generic driver yet. Therefore generic driver is unable to
guess required link speed, duplex etc. Device is started up with 10Mbps
halfduplex which is incorrect.
BroadR-REACH able flag is not specified in IEEE802.3-2015. Which is why I
did not add BroadR-REACH able flag support at generic driver. Once
BroadR-REACH able flag gets into IEEE802.3 it should be reasonable to
support it in the generic PHY driver.
Signed-off-by: Kirill Kranke <kirill.kranke@gmail.com>
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 343989f..7014eb7 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -422,6 +422,14 @@ config TERANETICS_PHY
---help---
Currently supports the Teranetics TN2020
+config TJA1100_PHY
+ tristate "NXP TJA1100 PHY"
+ help
+ Support of NXP TJA1100 BroadR-REACH ethernet PHY.
+ Generic driver is not suitable for TJA1100 PHY while the PHY does not
+ advertise any standard IEEE capabilities. It uses BroadR-REACH able
+ flag instead. This driver configures capabilities of the PHY properly.
+
config VITESSE_PHY
tristate "Vitesse PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b..4d2a69d 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -83,5 +83,6 @@ obj-$(CONFIG_ROCKCHIP_PHY) += rockchip.o
obj-$(CONFIG_SMSC_PHY) += smsc.o
obj-$(CONFIG_STE10XP) += ste10Xp.o
obj-$(CONFIG_TERANETICS_PHY) += teranetics.o
+obj-$(CONFIG_TJA1100_PHY) += tja1100.o
obj-$(CONFIG_VITESSE_PHY) += vitesse.o
obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
diff --git a/drivers/net/phy/tja1100.c b/drivers/net/phy/tja1100.c
new file mode 100644
index 0000000..081b580
--- /dev/null
+++ b/drivers/net/phy/tja1100.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/* tja1100.c: TJA1100 BoardR-REACH PHY driver.
+ *
+ * Copyright (c) 2017 Kirill Kranke <kirill.kranke@gmail.com>
+ * Author: Kirill Kranke <kirill.kranke@gmail.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+
+/* TJA1100 specific registers */
+#define TJA1100_ECTRL 0x11 /* Extended control register */
+#define TJA1100_CFG1 0x12 /* Configuration register 1 */
+#define TJA1100_CFG2 0x13 /* Configuration register 2 */
+#define TJA1100_SERRCNT 0x14 /* Symbol error counter register 2 */
+#define TJA1100_INTST 0x15 /* Interrupt status register */
+#define TJA1100_INTEN 0x16 /* Interrupt enable register */
+#define TJA1100_COMST 0x17 /* Communication status register */
+#define TJA1100_GST 0x18 /* General status register */
+#define TJA1100_EXTST 0x19 /* External status register */
+#define TJA1100_LFCNT 0x1a /* Link fail counter register */
+
+/* Extended control register */
+#define ECTRL_LC 0x8000 /* link control enable */
+#define ECTRL_PM 0x7800 /* operating mode select */
+#define ECTRL_PM_NOCNG 0x0000 /* PM == 0000: no change */
+#define ECTRL_PM_NORMAL 0x1800 /* PM == 0011: Normal mode */
+#define ECTRL_PM_STANBY 0x6000 /* PM == 1100: Standby mode */
+#define ECTRL_PM_SREQ 0x5800 /* PM == 1011: Sleep Request mode */
+#define ECTRL_SJ_TST 0x0400 /* enable/disable Slave jitter test */
+#define ECTRL_TR_RST 0x0200 /* Autonegotiation process restart */
+#define ECTRL_TST_MODE 0x01c0 /* test mode selection */
+#define ECTRL_C_TST 0x0020 /* TDR-based cable test */
+#define ECTRL_LOOPBACK 0x0018 /* loopback mode select */
+#define ECTRL_CFGEN 0x0004 /* configuration register access */
+#define ECTRL_CFGINH 0x0002 /* INH configuration */
+#define ECTRL_WAKE_REQ 0x0001 /* wake-up request configuration */
+
+/* Configuration register 1 */
+#define CFG1_MS 0x8000 /* PHY Master/Slave configuration */
+#define CFG1_AUTO_OP 0x4000 /* managed/autonomous operation */
+#define CFG1_LINKLEN 0x2000 /* cable length: 0 < 15 m; 1 > 15 m */
+#define CFG1_TXAMP 0x0c00 /* nominal transmit amplitude */
+#define CFG1_TXAMP_050 0x0000 /* TXAMP == 00: 500 mV */
+#define CFG1_TXAMP_075 0x0200 /* TXAMP == 01: 750 mV */
+#define CFG1_TXAMP_100 0x0400 /* TXAMP == 10: 1000 mV */
+#define CFG1_TXAMP_125 0x0c00 /* TXAMP == 11: 1250 mV */
+#define CFG1_MODE 0x0300 /* MII/RMII mode */
+#define CFG1_DRIVER 0x0080 /* MII output driver strength */
+#define CFG1_SC 0x0040 /* sleep confirmation setting */
+#define CFG1_LED_MODE 0x0030 /* LED mode */
+#define CFG1_LED_EN 0x0008 /* LED enable */
+#define CFG1_CFG_WAKE 0x0004 /* local wake configuration */
+#define CFG1_APWD 0x0002 /* autonomous power down */
+#define CFG1_LPS 0x0001 /* LPS code group reception */
+
+/* Configuration register 2 */
+#define CFG2_PHYAD_4_0 0xf800 /* PHY address used for the SMI addr */
+#define CFG2_SNR_AVG 0x0600 /* signal-to-noise ratio averaging */
+#define CFG2_SNR_WLIM 0x01c0 /* signal-to-noise ratio warning limit */
+#define CFG2_SNR_FLIM 0x0038 /* signal-to-noise ratio fail limit */
+#define CFG2_JUMBO_EN 0x0004 /* Jumbo packet support */
+#define CFG2_SRTO 0x0003 /* sleep request time-out */
+#define CFG2_SRTO_04 0x0000 /* SRTO == 00: 0.4 ms */
+#define CFG2_SRTO_1 0x0001 /* SRTO == 01: 1 ms */
+#define CFG2_SRTO_4 0x0002 /* SRTO == 10: 4 ms */
+#define CFG2_SRTO_16 0x0003 /* SRTO == 11: 16 ms */
+
+/* Symbol error counter register 2 */
+#define SERRCNT_SEC 0xffff /* The symbol error counter */
+
+/* Interrupt status register */
+#define INTST_PWON 0x8000 /* power-on detected */
+#define INTST_WAKEUP 0x4000 /* local or remote wake-up detected */
+#define INTST_WUR 0x2000 /* dedicated wake-up request detected */
+#define INTST_LPS 0x1000 /* LPS code groups received */
+#define INTST_PIF 0x0800 /* PHY initialization error detected */
+#define INTST_LINK_FAIL 0x0400 /* link status changed to ‘link fail’ */
+#define INTST_LINK_UP 0x0200 /* link status changed to ‘link up’ */
+#define INTST_SYM_ERR 0x0100 /* symbol error detected */
+#define INTST_TF 0x0080 /* training phase failure detected */
+#define INTST_SNRW 0x0040 /* SNR value above warning limit */
+#define INTST_CTRL_ERR 0x0020 /* SMI control error detected */
+#define INTST_TXENC 0x0010 /* TXEN clamping detected */
+#define INTST_UV_ERR 0x0008 /* undervoltage detected */
+#define INTST_UVR 0x0004 /* undervoltage recovery detected */
+#define INTST_TEMP_ERR 0x0002 /* overtemperature error detected */
+#define INTST_SA 0x0001 /* transition to Normal on timer expiring */
+
+/* Interrupt enable register */
+#define INTEN_PWON 0x8000 /* PWON interrupt enable */
+#define INTEN_WAKEUP 0x4000 /* WAKEUP interrupt enable */
+#define INTEN_WUR 0x2000 /* WUR_RECEIVED interrupt enable */
+#define INTEN_LPS 0x1000 /* LPS_RECEIVED interrupt enable */
+#define INTEN_PIF 0x0800 /* PHY_INIT_FAIL interrupt enable */
+#define INTEN_LINK_FAIL 0x0400 /* LINK_STATUS_FAIL interrupt enable */
+#define INTEN_LINK_UP 0x0200 /* LINK_STATUS_UP interrupt enable */
+#define INTEN_SYM_ERR 0x0100 /* SYM_ERR interrupt enable */
+#define INTEN_TF 0x0080 /* TRAINING_FAILED interrupt enable */
+#define INTEN_SNRW 0x0040 /* SNR_WARNING interrupt enable */
+#define INTEN_CTRL_ERR 0x0020 /* CONTROL_ERR interrupt enable */
+#define INTEN_TXENC 0x0010 /* TXEN_CLAMPED interrupt enable */
+#define INTEN_UV_ERR 0x0008 /* UV_ERR interrupt enable */
+#define INTEN_UVR 0x0004 /* UV_RECOVERY interrupt enable */
+#define INTEN_TEMP_ERR 0x0002 /* TEMP_ERR interrupt enable */
+#define INTEN_SA 0x0001 /* SLEEP_ABORT interrupt enable */
+
+/* Communication status register */
+#define COMST_LINK_UP 0x8000 /* link OK */
+#define COMST_TXM 0x6000 /* transmitter mode */
+#define COMST_TXM_DIS 0x0000 /* TXM == 00: transmitter disabled */
+#define COMST_TXM_DIS 0x0000 /* TXM == 01: transmitter in SEND_N mode */
+#define COMST_TXM_DIS 0x0000 /* TXM == 10: transmitter in SEND_I mode */
+#define COMST_TXM_DIS 0x0000 /* TXM == 11: transmitter in SEND_Z mode */
+#define COMST_LR 0x1000 /* local receiver OK */
+#define COMST_RR 0x0800 /* remote receiver OK */
+#define COMST_SCRL 0x0400 /* descrambler locked */
+#define COMST_SSD_ERR 0x0200 /* SSD error detected */
+#define COMST_ESD_ERR 0x0100 /* ESD error detected */
+#define COMST_SNR 0x00e0 /* SNR link status */
+#define COMST_RX_ERR 0x0010 /* receive error detected since last read */
+#define COMST_TX_ERR 0x0080 /* transmit error detected since last read */
+#define COMST_PS 0x0007 /* PHY state */
+
+/* General status register */
+#define GST_INTP 0x8000 /* unmasked interrupt pending */
+#define GST_PLL_LOCKED 0x4000 /* PLL stable and locked */
+#define GST_LWU 0x2000 /* local wake-up detected */
+#define GST_RWU 0x1000 /* remote wake-up detected */
+#define GST_DDWU 0x0800 /* data detected at MDI in Sleep Request mode */
+#define GST_EN 0x0400 /* EN switched LOW since last read */
+#define GST_RST 0x0200 /* hardware reset detected since last read */
+#define GST_LF_CNT 0x00f8 /* number of link fails since last read */
+
+/* External status register */
+#define EXTST_UVDDA_3V3 0x4000 /* undervoltage detected on pin VDDA(3V3) */
+#define EXTST_UVDDD_1V8 0x2000 /* undervoltage detected on pin VDDD(1V8) */
+#define EXTST_UVDDA_1V8 0x1000 /* undervoltage detected on pin VDDA(1V8) */
+#define EXTST_UVDDIO 0x0800 /* undervoltage detected on pin VDD(IO) */
+#define EXTST_TH 0x0400 /* temperature above high level */
+#define EXTST_TW 0x0200 /* temperature above warning level */
+#define EXTST_SD 0x0100 /* short circuit detected since last read */
+#define EXTST_OD 0x0080 /* open circuit detected since last read */
+#define EXTST_INTDET 0x0040 /* interleave order detection */
+
+/* Link fail counter register */
+#define LFCNT_LRC 0xff00 /* incremented when local receiver is NOT_OK */
+#define LFCNT_RRC 0x00ff /* incremented when remote receiver is NOT_OK */
+
+static int tja1100_phy_config_init(struct phy_device *phydev)
+{
+ u32 features;
+
+ /* TJA1100 has only 100BASE-BroadR-REACH ability specified at
+ * MII_ESTATUS register. Standard modes are not supported. Therefore
+ * BroadR-REACH allow only 100Mbps full duplex without autoneg.
+ */
+ features = SUPPORTED_MII;
+ features |= SUPPORTED_100baseT_Full;
+
+ phydev->supported &= features;
+ phydev->advertising &= features;
+ phydev->autoneg = AUTONEG_DISABLE;
+ phydev->speed = SPEED_100;
+ phydev->duplex = DUPLEX_FULL;
+
+ return 0;
+}
+
+static int tja1100_phy_config_aneg(struct phy_device *phydev)
+{
+ if (phydev->autoneg == AUTONEG_ENABLE) {
+ pr_err("TJA1100: autonegotiation is not supported\n");
+ return -1;
+ }
+
+ if (phydev->speed != SPEED_100 || phydev->duplex != DUPLEX_FULL) {
+ pr_err("TJA1100: only 100MBps Full Duplex allowed\n");
+ return -2;
+ }
+
+ return 0;
+}
+
+static struct phy_driver tja1100_phy_driver[] = {
+ {
+ .phy_id = 0x0180dc48,
+ .phy_id_mask = 0xfffffff0,
+ .name = "NXP TJA1100",
+
+ .features = SUPPORTED_100baseT_Full | SUPPORTED_MII,
+
+ .config_aneg = tja1100_phy_config_aneg,
+ .read_status = genphy_read_status,
+ .config_init = tja1100_phy_config_init,
+ .soft_reset = genphy_soft_reset,
+
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ }
+};
+
+module_phy_driver(tja1100_phy_driver);
+
+MODULE_DESCRIPTION("NXP TJA1100 driver");
+MODULE_AUTHOR("Kirill Kranke <kkranke@topcon.com>");
+MODULE_LICENSE("GPL");
+
+static struct mdio_device_id __maybe_unused nxp_tbl[] = {
+ { 0x0180dc48, 0xfffffff0 },
+ {}
+};
+
+MODULE_DEVICE_TABLE(mdio, nxp_tbl);
^ permalink raw reply related
* Re: net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on bound sockets
From: Maciej Żenczykowski @ 2018-06-08 10:07 UTC (permalink / raw)
To: Andrei Vagin; +Cc: David S . Miller, Eric Dumazet, Linux NetDev
In-Reply-To: <20180607055113.GA14073@outlook.office365.com>
I think we probably need to make sk->sk_reuse back into a boolean.
(ie. eliminate SK_FORCE_REUSE)
Then add a new tcp/udp sk->ignore_bind_conflicts boolean setting...
(ie. not just for tcp, but sol_socket) [or perhaps SO_REPAIR,
sk->repair or something]
What I'm not certain of is exactly what sorts of conflicts it should ignore...
all? probably not, still seems utterly wrong to allow creation of 2 connected
tcp sockets with identical 5-tuples.
Would it only ignore conflicts against other i_b_c sockets?
ie. set it on all sockets as we're repairing, then clear it on them
all once we're done?
and ignore all the fast caching when checking conflicts for an i_b_c socket?
For CRIU is it safe to assume we're restoring an entire namespace into
a new namespace?
Could we perhaps instead allow a new namespace to ignore bind conflicts until
we flip it into enforcing mode?
^ 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