Re: [PATCH] genetlink: fix unsigned int comparison with less than zero
> > I suppose it could be, since family IDs are allocated in a 16-bit > > range > > anyway. But family IDs can also never actually be negative, so > > having > > an unsigned int in the struct makes sense too. > > All idr_* API's accept int, rather than unsigned int. This is my > point. Sure, but that's an internal implementation detail. The struct genl_family is also an external API towards its users, and there negative numbers make no sense whatsoever. johannes
Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
Hi Lino,
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Lino-Sanfilippo/net-ethernet-slicoss-add-slicoss-gigabit-ethernet-driver/20161113-125131
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha
All warnings (new ones prefixed by >>):
drivers/staging/slicoss/slicoss.c: In function 'slic_cmdq_addcmdpage':
>> drivers/staging/slicoss/slicoss.c:1258:2: warning: 'virt_to_bus' is
>> deprecated [-Wdeprecated-declarations]
phys_addr = virt_to_bus((void *)page);
^
In file included from include/linux/io.h:25:0,
from include/linux/irq.h:24,
from include/asm-generic/hardirq.h:12,
from arch/alpha/include/asm/hardirq.h:7,
from include/linux/hardirq.h:8,
from include/linux/interrupt.h:12,
from drivers/staging/slicoss/slicoss.c:71:
arch/alpha/include/asm/io.h:114:42: note: declared here
static inline unsigned long __deprecated virt_to_bus(void *address)
^~~
vim +/virt_to_bus +1258 drivers/staging/slicoss/slicoss.c
4d6ea9c3 Denis Kirjanov 2010-07-10 1242struct slic_hostcmd *cmd;
4d6ea9c3 Denis Kirjanov 2010-07-10 1243struct slic_hostcmd *prev;
4d6ea9c3 Denis Kirjanov 2010-07-10 1244struct slic_hostcmd *tail;
4d6ea9c3 Denis Kirjanov 2010-07-10 1245struct slic_cmdqueue *cmdq;
4d6ea9c3 Denis Kirjanov 2010-07-10 1246int cmdcnt;
4d6ea9c3 Denis Kirjanov 2010-07-10 1247void *cmdaddr;
4d6ea9c3 Denis Kirjanov 2010-07-10 1248ulong phys_addr;
4d6ea9c3 Denis Kirjanov 2010-07-10 1249u32 phys_addrl;
4d6ea9c3 Denis Kirjanov 2010-07-10 1250u32 phys_addrh;
4d6ea9c3 Denis Kirjanov 2010-07-10 1251struct slic_handle
*pslic_handle;
eafe6002 David Matlack 2015-05-11 1252unsigned long flags;
4d6f6af8 Greg Kroah-Hartman 2008-03-19 1253
4d6ea9c3 Denis Kirjanov 2010-07-10 1254cmdaddr = page;
dd146d21 Shraddha Barke 2015-10-15 1255cmd = cmdaddr;
4d6ea9c3 Denis Kirjanov 2010-07-10 1256cmdcnt = 0;
4d6f6af8 Greg Kroah-Hartman 2008-03-19 1257
4d6ea9c3 Denis Kirjanov 2010-07-10 @1258phys_addr = virt_to_bus((void
*)page);
4d6ea9c3 Denis Kirjanov 2010-07-10 1259phys_addrl =
SLIC_GET_ADDR_LOW(phys_addr);
4d6ea9c3 Denis Kirjanov 2010-07-10 1260phys_addrh =
SLIC_GET_ADDR_HIGH(phys_addr);
4d6f6af8 Greg Kroah-Hartman 2008-03-19 1261
4d6ea9c3 Denis Kirjanov 2010-07-10 1262prev = NULL;
4d6ea9c3 Denis Kirjanov 2010-07-10 1263tail = cmd;
4d6ea9c3 Denis Kirjanov 2010-07-10 1264while ((cmdcnt <
SLIC_CMDQ_CMDSINPAGE) &&
4d6ea9c3 Denis Kirjanov 2010-07-10 1265 (adapter->slic_handle_ix
< 256)) {
4d6ea9c3 Denis Kirjanov 2010-07-10 1266/* Allocate and
initialize a SLIC_HANDLE for this command */
:: The code at line 1258 was first introduced by commit
:: 4d6ea9c3223da8d8dc91b369087fa40cc53edd36 Staging: slicoss: kill
functions prototypes and reorder functions
:: TO: Denis Kirjanov
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [iproute PATCH v2 1/2] include: Add linux/sctp.h
On Wed, 9 Nov 2016 12:12:23 +0100 Phil Sutter wrote: > Add sanitized UAPI linux/sctp.h header file. > > Signed-off-by: Phil Sutter Applied both patches.
Re: [PATCH iproute2 1/1] tc: print raw qdisc handle.
On Thu, 10 Nov 2016 10:06:32 -0500
Roman Mashak wrote:
> Resending patch after fixing indentation and spaces.
>
> Signed-off-by: Roman Mashak
> Signed-off-by: Jamal Hadi Salim
iproute2 uses kernel coding style. This patch fails basic checkpatch.
WARNING: suspect code indent for conditional statements (8, 11)
#31: FILE: tc/tc_qdisc.c:241:
+ if (!show_raw) {
+ fprintf(fp, "qdisc %s %x: ", rta_getattr_str(tb[TCA_KIND]),
total: 0 errors, 1 warnings, 15 lines checked
Re: [PATCH] net: bpqether.h: remove if_ether.h guard
From: Baruch Siach Date: Thu, 10 Nov 2016 13:21:42 +0200 > __LINUX_IF_ETHER_H is not defined anywhere, and if_ether.h can keep itself > from > double inclusion, though it uses a single underscore prefix. > > Signed-off-by: Baruch Siach Applied.
Re: [PATCH net-next v1 00/11] amd-xgbe: AMD XGBE driver updates 2016-11-10
From: Tom Lendacky Date: Thu, 10 Nov 2016 17:09:17 -0600 > This patch series is targeted at adding support for a new PCI version > of the hardware. As part of the new PCI device, there is a new PCS/PHY > interaction, ECC support, I2C sideband communication, SFP+ support and > more. > > The following updates and fixes are included in this driver update series: > > - Hardware workaround for possible incorrectly generated interrupts > during software reset > - Hardware workaround for Tx timestamp register access order > - Add support for a PCI version of the device > - Increase the Rx queue limit to take advantage of the increased number > of DMA channels that might be available > - Add support for a new DMA channel interrupt mode > - Add ECC support for the device memory > - Add support for using the integrated I2C controller for sideband > communication > - Expose the phylib phy_aneg_done() function so it can be called by the > driver > - Add support for SFP+ modules > - Add support for MDIO attached PHYs > - Add support for KR re-driver between the PCS/SerDes and an external > PHY > > This patch series is based on net-next. Series applied, thanks Tom.
Re: [PATCH net-next v13 0/8] openvswitch: support for layer 3 encapsulated packets
From: Jiri Benc Date: Thu, 10 Nov 2016 16:28:16 +0100 > At the core of this patch set is removing the assumption in Open vSwitch > datapath that all packets have Ethernet header. > > The implementation relies on the presence of pop_eth and push_eth actions > in datapath flows to facilitate adding and removing Ethernet headers as > appropriate. The construction of such flows is left up to user-space. > > This series is based on work by Simon Horman, Lorand Jakab, Thomas Morin and > others. I kept Lorand's and Simon's s-o-b in the patches that are derived > from v11 to record their authorship of parts of the code. Series applied, thanks.
Re: [PATCH net-next 00/11] Start adding support for mv88e6390 family
From: Andrew Lunn Date: Fri, 11 Nov 2016 03:53:32 +0100 > This is the first patchset implementing support for the mv88e6390 > family. This is a new generation of switch devices and has numerous > incompatible changes to the registers. These patches allow the switch > to the detected during probe, and makes the statistics unit work. > > These patches are insufficient to make the mv88e6390 functional. More > patches will follow. Andrew, this series doesn't apply cleanly to net-next, so you'll need to respin. Thanks.
Re: [PATCH] genetlink: fix unsigned int comparison with less than zero
On Sat, Nov 12, 2016 at 1:37 PM, Johannes Berg wrote: > On Thu, 2016-11-10 at 09:11 -0800, Cong Wang wrote: >> On Thu, Nov 10, 2016 at 7:57 AM, Colin King > > wrote: >> > >> > From: Colin Ian King >> > >> > family->id is unsigned, so the less than zero check for >> > failure return from idr_alloc is never true and so the error exit >> > is never handled. Instead, assign err and check if this is less >> > than zero since this is a signed integer. >> >> Why family->id can't be just signed int? For me it should be. > > I suppose it could be, since family IDs are allocated in a 16-bit range > anyway. But family IDs can also never actually be negative, so having > an unsigned int in the struct makes sense too. All idr_* API's accept int, rather than unsigned int. This is my point.
Re: [PATCH net-next v2] ipv6: sr: fix IPv6 initialization failure without lwtunnels
From: David Miller
Date: Sun, 13 Nov 2016 00:20:55 -0500 (EST)
> From: David Lebrun
> Date: Thu, 10 Nov 2016 13:26:53 +0100
>
>> v2: fix conditional compilation for seg6_iptunnel.o in Makefile
>>
>> This patch compiles SR lwtunnels support only if CONFIG_LWTUNNEL=y.
>>
>> If IPv6 is enabled and CONFIG_LWTUNNEL=n, then seg6_iptunnel_init()
>> fails with EOPNOTSUPP which in turn makes seg6_init() fail, blocking
>> the IPv6 initialization, with the following messages:
>>
>> NET: Registered protocol family 10
>> IPv6: Attempt to unregister permanent protocol 6
>> IPv6: Attempt to unregister permanent protocol 136
>> IPv6: Attempt to unregister permanent protocol 17
>> NET: Unregistered protocol family 10
>>
>> Fix commit 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and
>> injection with lwtunnels")
>>
>> Tested with various combinations of CONFIG_IPV6 and CONFIG_LWTUNNEL.
>>
>> Reported-by: Lorenzo Colitti
>> Signed-off-by: David Lebrun
>
> Applied, thanks David.
Actually reverted, after just doing an "make oldconfig" on an
"make allmodconfig" tree after applying this patch the build
fails to link:
[davem@localhost net-next]$ make -s -j8
DESCEND objtool
net/built-in.o: In function `seg6_build_state':
seg6_iptunnel.c:(.text+0x1b7fbe): undefined reference to `seg6_validate_srh'
net/built-in.o: In function `seg6_do_srh':
seg6_iptunnel.c:(.text+0x1b8ad2): undefined reference to `ipv6_dev_get_saddr'
net/built-in.o: In function `seg6_input':
(.text+0x1b8eeb): undefined reference to `ip6_route_input'
net/built-in.o: In function `seg6_output':
(.text+0x1b9151): undefined reference to `ip6_route_output_flags'
Makefile:959: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
This seems like such a huge mess, quite frankly.
IPV6-SR has so many strange dependencies, a weird Kconfig option that is
simply controlling what a responsible sysadmin should be allow to do if
he chooses anyways.
Every distribution is going to say "¯\_(ツ)_/¯" and just turn the thing
on in their builds.
Re: [PATCH net-next v2] ipv6: sr: fix IPv6 initialization failure without lwtunnels
From: David Lebrun
Date: Thu, 10 Nov 2016 13:26:53 +0100
> v2: fix conditional compilation for seg6_iptunnel.o in Makefile
>
> This patch compiles SR lwtunnels support only if CONFIG_LWTUNNEL=y.
>
> If IPv6 is enabled and CONFIG_LWTUNNEL=n, then seg6_iptunnel_init()
> fails with EOPNOTSUPP which in turn makes seg6_init() fail, blocking
> the IPv6 initialization, with the following messages:
>
> NET: Registered protocol family 10
> IPv6: Attempt to unregister permanent protocol 6
> IPv6: Attempt to unregister permanent protocol 136
> IPv6: Attempt to unregister permanent protocol 17
> NET: Unregistered protocol family 10
>
> Fix commit 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and
> injection with lwtunnels")
>
> Tested with various combinations of CONFIG_IPV6 and CONFIG_LWTUNNEL.
>
> Reported-by: Lorenzo Colitti
> Signed-off-by: David Lebrun
Applied, thanks David.
[PATCH v2 1/2] Revert "bnx2: Reset device during driver initialization"
This reverts commit 3e1be7ad2d38c6bd6aeef96df9bd0a7822f4e51c. When people build bnx2 driver into kernel, it will fail to detect and load firmware because firmware is contained in initramfs and initramfs has not been uncompressed yet during do_initcalls. So revert commit 3e1be7a and work out a new way in the later patch. Signed-off-by: Baoquan He Acked-by: Paul Menzel --- drivers/net/ethernet/broadcom/bnx2.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c index b3791b3..c557972 100644 --- a/drivers/net/ethernet/broadcom/bnx2.c +++ b/drivers/net/ethernet/broadcom/bnx2.c @@ -6361,6 +6361,10 @@ bnx2_open(struct net_device *dev) struct bnx2 *bp = netdev_priv(dev); int rc; + rc = bnx2_request_firmware(bp); + if (rc < 0) + goto out; + netif_carrier_off(dev); bnx2_disable_int(bp); @@ -6429,6 +6433,7 @@ bnx2_open(struct net_device *dev) bnx2_free_irq(bp); bnx2_free_mem(bp); bnx2_del_napi(bp); + bnx2_release_firmware(bp); goto out; } @@ -8575,12 +8580,6 @@ bnx2_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) pci_set_drvdata(pdev, dev); - rc = bnx2_request_firmware(bp); - if (rc < 0) - goto error; - - - bnx2_reset_chip(bp, BNX2_DRV_MSG_CODE_RESET); memcpy(dev->dev_addr, bp->mac_addr, ETH_ALEN); dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | @@ -8613,7 +8612,6 @@ bnx2_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) return 0; error: - bnx2_release_firmware(bp); pci_iounmap(pdev, bp->regview); pci_release_regions(pdev); pci_disable_device(pdev); -- 2.5.5
[PATCH v2 0/2] bnx2: Wait for in-flight DMA to complete at probe stage
This is v2 post.
In commit 3e1be7a ("bnx2: Reset device during driver initialization"),
firmware requesting code was moved from open stage to probe stage.
The reason is in kdump kernel hardware iommu need device be reset in
driver probe stage, otherwise those in-flight DMA from 1st kernel
will continue going and look up into the newly created io-page tables.
However bnx2 chip resetting involves firmware requesting issue, that
need be done in open stage.
Michale Chan suggested we can just wait for the old in-flight DMA to
complete at probe stage, then though without device resetting, we
don't need to worry the old in-flight DMA could continue looking up
the newly created io-page tables.
v1->v2:
Michael suggested to wait for the in-flight DMA to complete at probe
stage. So give up the old method of trying to reset chip at probe
stage, take the new way accordingly.
Baoquan He (2):
Revert "bnx2: Reset device during driver initialization"
bnx2: Wait for in-flight DMA to complete at probe stage
drivers/net/ethernet/broadcom/bnx2.c | 48 +++-
1 file changed, 36 insertions(+), 12 deletions(-)
--
2.5.5
[PATCH v2 2/2] bnx2: Wait for in-flight DMA to complete at probe stage
In-flight DMA from 1st kernel could continue going in kdump kernel.
New io-page table has been created before bnx2 does reset at open stage.
We have to wait for the in-flight DMA to complete to avoid it look up
into the newly created io-page table at probe stage.
Suggested-by: Michael Chan
Signed-off-by: Baoquan He
---
drivers/net/ethernet/broadcom/bnx2.c | 38 ++--
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c
b/drivers/net/ethernet/broadcom/bnx2.c
index c557972..1f7034d 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#if IS_ENABLED(CONFIG_CNIC)
#define BCM_CNIC 1
@@ -4764,15 +4765,16 @@ bnx2_setup_msix_tbl(struct bnx2 *bp)
BNX2_WR(bp, BNX2_PCI_GRC_WINDOW3_ADDR, BNX2_MSIX_PBA_ADDR);
}
-static int
-bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
+static void
+bnx2_wait_dma_complete(struct bnx2 *bp)
{
u32 val;
- int i, rc = 0;
- u8 old_port;
+ int i;
- /* Wait for the current PCI transaction to complete before
-* issuing a reset. */
+ /*
+* Wait for the current PCI transaction to complete before
+* issuing a reset.
+*/
if ((BNX2_CHIP(bp) == BNX2_CHIP_5706) ||
(BNX2_CHIP(bp) == BNX2_CHIP_5708)) {
BNX2_WR(bp, BNX2_MISC_ENABLE_CLR_BITS,
@@ -4796,6 +4798,21 @@ bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
}
}
+ return;
+}
+
+
+static int
+bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
+{
+ u32 val;
+ int i, rc = 0;
+ u8 old_port;
+
+ /* Wait for the current PCI transaction to complete before
+* issuing a reset. */
+ bnx2_wait_dma_complete(bp);
+
/* Wait for the firmware to tell us it is ok to issue a reset. */
bnx2_fw_sync(bp, BNX2_DRV_MSG_DATA_WAIT0 | reset_code, 1, 1);
@@ -8580,6 +8597,15 @@ bnx2_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
pci_set_drvdata(pdev, dev);
+ /*
+* In-flight DMA from 1st kernel could continue going in kdump kernel.
+* New io-page table has been created before bnx2 does reset at open
stage.
+* We have to wait for the in-flight DMA to complete to avoid it look up
+* into the newly created io-page table.
+*/
+ if (is_kdump_kernel())
+ bnx2_wait_dma_complete(bp);
+
memcpy(dev->dev_addr, bp->mac_addr, ETH_ALEN);
dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
--
2.5.5
Re: [PATCH v2 2/2] bnx2: Wait for in-flight DMA to complete at probe stage
On 11/12/16 at 11:40pm, David Miller wrote: > From: Baoquan He > Date: Sun, 13 Nov 2016 12:15:24 +0800 > > > In-flight DMA from 1st kernel could continue going in kdump kernel. > > New io-page table has been created before bnx2 does reset at open stage. > > We have to wait for the in-flight DMA to complete to avoid it look up > > into the newly created io-page table at probe stage. > > > > Suggested-by: Michael Chan > > Signed-off-by: Baoquan He > > --- > > v1->v2: > > Michael suggested to wait for the in-flight DMA to complete at probe > > stage. So give up the old method of trying to reset chip at probe > > stage, take the new way accordingly. > > Patch updates don't work this way. > > When you update a patch that is part of a patch series, you must > resubmit the entire series anew. Thanks for telling, David! Learned it. I am not very sure if this is what Michael is suggesting. Will resubmit the entire patch series. Thanks Baoquan
[net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
Add driver for Alacritech gigabit ethernet cards with SLIC (session-layer interface control) technology. The driver provides basic support without SLIC for the following devices: - Mojave cards (single port PCI Gigabit) both copper and fiber - Oasis cards (single and dual port PCI-x Gigabit) copper and fiber - Kalahari cards (dual and quad port PCI-e Gigabit) copper and fiber Signed-off-by: Lino Sanfilippo --- drivers/net/ethernet/Kconfig |1 + drivers/net/ethernet/Makefile |1 + drivers/net/ethernet/alacritech/Kconfig | 28 + drivers/net/ethernet/alacritech/Makefile |4 + drivers/net/ethernet/alacritech/slic.h| 606 ++ drivers/net/ethernet/alacritech/slicoss.c | 1855 + include/linux/pci_ids.h | 18 + 7 files changed, 2513 insertions(+) create mode 100644 drivers/net/ethernet/alacritech/Kconfig create mode 100644 drivers/net/ethernet/alacritech/Makefile create mode 100644 drivers/net/ethernet/alacritech/slic.h create mode 100644 drivers/net/ethernet/alacritech/slicoss.c diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig index 2ffd634..a4cc87fe 100644 --- a/drivers/net/ethernet/Kconfig +++ b/drivers/net/ethernet/Kconfig @@ -21,6 +21,7 @@ source "drivers/net/ethernet/3com/Kconfig" source "drivers/net/ethernet/adaptec/Kconfig" source "drivers/net/ethernet/aeroflex/Kconfig" source "drivers/net/ethernet/agere/Kconfig" +source "drivers/net/ethernet/alacritech/Kconfig" source "drivers/net/ethernet/allwinner/Kconfig" source "drivers/net/ethernet/alteon/Kconfig" source "drivers/net/ethernet/altera/Kconfig" diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile index 1d349e9..b448027 100644 --- a/drivers/net/ethernet/Makefile +++ b/drivers/net/ethernet/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_NET_VENDOR_8390) += 8390/ obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/ obj-$(CONFIG_GRETH) += aeroflex/ obj-$(CONFIG_NET_VENDOR_AGERE) += agere/ +obj-$(CONFIG_NET_VENDOR_ALACRITECH) += alacritech/ obj-$(CONFIG_NET_VENDOR_ALLWINNER) += allwinner/ obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/ obj-$(CONFIG_ALTERA_TSE) += altera/ diff --git a/drivers/net/ethernet/alacritech/Kconfig b/drivers/net/ethernet/alacritech/Kconfig new file mode 100644 index 000..41000a3 --- /dev/null +++ b/drivers/net/ethernet/alacritech/Kconfig @@ -0,0 +1,28 @@ +config NET_VENDOR_ALACRITECH +bool "Alacritech devices" +default y +---help--- + If you have a network (Ethernet) card belonging to this class, say Y. + + Note that the answer to this question doesn't directly affect the + kernel: saying N will just cause the configurator to skip all + the questions about Renesas devices. If you say Y, you will be asked + for your specific device in the following questions. + +if NET_VENDOR_ALACRITECH + +config SLICOSS + tristate "Alacritech Slicoss support" + depends on PCI + select CRC32 + ---help--- + This driver supports Gigabit Ethernet adapters based on the + Session Layer Interface (SLIC) technology by Alacritech. + + Supported are Mojave (1 port) and Oasis (1, 2 and 4 port) cards, + both copper and fiber. + + To compile this driver as a module, choose M here: the module + will be called slicoss. This is recommended. + +endif # NET_VENDOR_ALACRITECH diff --git a/drivers/net/ethernet/alacritech/Makefile b/drivers/net/ethernet/alacritech/Makefile new file mode 100644 index 000..8790e9e --- /dev/null +++ b/drivers/net/ethernet/alacritech/Makefile @@ -0,0 +1,4 @@ +# +# Makefile for the Alacritech Slicoss driver +# +obj-$(CONFIG_SLICOSS) += slicoss.o diff --git a/drivers/net/ethernet/alacritech/slic.h b/drivers/net/ethernet/alacritech/slic.h new file mode 100644 index 000..963a20d --- /dev/null +++ b/drivers/net/ethernet/alacritech/slic.h @@ -0,0 +1,606 @@ + +#ifndef _SLIC_H +#define _SLIC_H + +#include +#include +#include +#include +#include +#include +#include +#include + +#define SLIC_VGBSTAT_XPERR 0x4000 +#define SLIC_VGBSTAT_XERRSHFT 25 +#define SLIC_VGBSTAT_XCSERR0x23 +#define SLIC_VGBSTAT_XUFLOW0x22 +#define SLIC_VGBSTAT_XHLEN 0x20 +#define SLIC_VGBSTAT_NETERR0x0100 +#define SLIC_VGBSTAT_NERRSHFT 16 +#define SLIC_VGBSTAT_NERRMSK 0x1ff +#define SLIC_VGBSTAT_NCSERR0x103 +#define SLIC_VGBSTAT_NUFLOW0x102 +#define SLIC_VGBSTAT_NHLEN 0x100 +#define SLIC_VGBSTAT_LNKERR0x0080 +#define SLIC_VGBSTAT_LERRMSK 0xff +#define SLIC_VGBSTAT_LDEARLY 0x86 +#define SLIC_VGBSTAT_LBOFLO0x85 +#define SLIC_VGBSTAT_LCODERR 0x84 +#define SLIC_VGBSTAT_LDBLNBL 0x83 +#define SLIC_VGBSTAT_LCRCERR 0x82 +#define SLIC_VGBSTAT_LOFLO 0x81 +#define SLIC
[net-next 2/2] MAINTAINERS: add entry for slicoss ethernet driver
Add myself as maintainer for the slicoss ethernet driver. Signed-off-by: Lino Sanfilippo --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6781a3f..bb9af28 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -562,6 +562,11 @@ T: git git://linuxtv.org/anttip/media_tree.git S: Maintained F: drivers/media/usb/airspy/ +ALACRITECH GIGABIT ETHERNET DRIVER +M: Lino Sanfilippo +S: Maintained +F: drivers/net/ethernet/alacritech/* + ALCATEL SPEEDTOUCH USB DRIVER M: Duncan Sands L: linux-...@vger.kernel.org -- 1.9.1
Gigabit ethernet driver for Alacritechs SLIC devices
Hi, this is a rework of the slicoss gigabit ethernet driver from Alacritech that is currently part of the staging area. The driver is supposed to support Mojave, Oasis and Kalahari cards, for both copper and fiber. If this code is accepted the staging version can be removed (as Greg told me by email, he would do this himself so this is not part of these patches). The driver is tested on a SEN2104ET card (4 Port PCIe copper). Regards, Lino
Re: linux-next: manual merge of the net-next tree with the netfilter tree
From: Pablo Neira Ayuso Date: Thu, 10 Nov 2016 01:31:17 +0100 > I think I cannot help to address this conflict myself. > > 8fbfef7f505b is in my nf tree, while 489111e5c25b is in net-next. So > you will hit this conflict by when you pull net into net-next. > > So please keep this patch from Stephen to resolve the conflict in your > radar to solve this. I will, thank you.
Re: [PATCH net] net: __skb_flow_dissect() must cap its return value
From: Eric Dumazet
Date: Wed, 09 Nov 2016 16:04:46 -0800
> From: Eric Dumazet
>
> After Tom patch, thoff field could point past the end of the buffer,
> this could fool some callers.
>
> If an skb was provided, skb->len should be the upper limit.
> If not, hlen is supposed to be the upper limit.
>
> Fixes: a6e544b0a88b ("flow_dissector: Jump to exit code in
> __skb_flow_dissect")
> Signed-off-by: Eric Dumazet
> Reported-by: Yibin Yang Acked-by: Alexander Duyck
> Acked-by: Willem de Bruijn
> Acked-by: Alexei Starovoitov
Applied and queued up for -stable, thanks Eric.
Re: [PATCH v2 2/2] bnx2: Wait for in-flight DMA to complete at probe stage
From: Baoquan He Date: Sun, 13 Nov 2016 12:15:24 +0800 > In-flight DMA from 1st kernel could continue going in kdump kernel. > New io-page table has been created before bnx2 does reset at open stage. > We have to wait for the in-flight DMA to complete to avoid it look up > into the newly created io-page table at probe stage. > > Suggested-by: Michael Chan > Signed-off-by: Baoquan He > --- > v1->v2: > Michael suggested to wait for the in-flight DMA to complete at probe > stage. So give up the old method of trying to reset chip at probe > stage, take the new way accordingly. Patch updates don't work this way. When you update a patch that is part of a patch series, you must resubmit the entire series anew. Thank you.
Re: [PATCH net 0/2] bpf: Fix bpf_redirect to an ipip/ip6tnl dev
From: Martin KaFai Lau Date: Wed, 9 Nov 2016 15:36:32 -0800 > This patch set fixes a bug in bpf_redirect(dev, flags) when dev is an > ipip/ip6tnl. The current problem is IP-EthHdr-IP is sent out instead of > IP-IP. > > Patch 1 adds a dev->type test similar to dev_is_mac_header_xmit() > in act_mirred.c which is only available in net-next. We can consider to > refactor it once this patch is pulled into net-next from net. Series applied, thanks Martin.
Re: [PATCHv2 net] igmp: do not remove igmp souce list info when set link down
From: Hangbin Liu Date: Wed, 9 Nov 2016 11:16:40 +0800 > In commit 24cf3af(igmp: call ip_mc_clear_src...), we forgot to remove > igmpv3_clear_delrec() in ip_mc_down(), which also called ip_mc_clear_src(). > This make us clear all IGMPv3 source filter info after NETDEV_DOWN. > Move igmpv3_clear_delrec() to ip_mc_destroy_dev() and then no need > ip_mc_clear_src() in ip_mc_destroy_dev(). > > On the other hand, we should restore back instead of free all source filter > info in igmpv3_del_delrec(). Or we will not able to restore IGMPv3 source > filter info after NETDEV_UP and NETDEV_POST_TYPE_CHANGE. > > Signed-off-by: Hangbin Liu Commits must be referenced with 12 characters of significance in the SHA1-ID and appear in an appropriately formed "Fixes: " tag right before the signoffs. As-per Documentation/SubmittingPatches. It also doesn't look so good how you lack a space between the SHA1-ID and the commit message header text reference.
Re: [PATCH net-next] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path
From: Daniel Borkmann
Date: Wed, 9 Nov 2016 22:02:34 +0100
> Commit 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings
> scheme") added a bug in that the prog's reference count is not dropped
> in the error path when mlx4_en_try_alloc_resources() is failing from
> mlx4_xdp_set().
>
> We previously took bpf_prog_add(prog, priv->rx_ring_num - 1), that we
> need to release again. Earlier in the call path, dev_change_xdp_fd()
> itself holds a reference to the prog as well (hence the '- 1' in the
> bpf_prog_add()), so a simple atomic_sub() is safe to use here. When
> an error is propagated, then bpf_prog_put() is called eventually from
> dev_change_xdp_fd()
>
> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> Signed-off-by: Daniel Borkmann
Applied, thanks Daniel.
[PATCH v2 2/2] bnx2: Wait for in-flight DMA to complete at probe stage
In-flight DMA from 1st kernel could continue going in kdump kernel.
New io-page table has been created before bnx2 does reset at open stage.
We have to wait for the in-flight DMA to complete to avoid it look up
into the newly created io-page table at probe stage.
Suggested-by: Michael Chan
Signed-off-by: Baoquan He
---
v1->v2:
Michael suggested to wait for the in-flight DMA to complete at probe
stage. So give up the old method of trying to reset chip at probe
stage, take the new way accordingly.
drivers/net/ethernet/broadcom/bnx2.c | 38 ++--
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c
b/drivers/net/ethernet/broadcom/bnx2.c
index c557972..1f7034d 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#if IS_ENABLED(CONFIG_CNIC)
#define BCM_CNIC 1
@@ -4764,15 +4765,16 @@ bnx2_setup_msix_tbl(struct bnx2 *bp)
BNX2_WR(bp, BNX2_PCI_GRC_WINDOW3_ADDR, BNX2_MSIX_PBA_ADDR);
}
-static int
-bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
+static void
+bnx2_wait_dma_complete(struct bnx2 *bp)
{
u32 val;
- int i, rc = 0;
- u8 old_port;
+ int i;
- /* Wait for the current PCI transaction to complete before
-* issuing a reset. */
+ /*
+* Wait for the current PCI transaction to complete before
+* issuing a reset.
+*/
if ((BNX2_CHIP(bp) == BNX2_CHIP_5706) ||
(BNX2_CHIP(bp) == BNX2_CHIP_5708)) {
BNX2_WR(bp, BNX2_MISC_ENABLE_CLR_BITS,
@@ -4796,6 +4798,21 @@ bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
}
}
+ return;
+}
+
+
+static int
+bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
+{
+ u32 val;
+ int i, rc = 0;
+ u8 old_port;
+
+ /* Wait for the current PCI transaction to complete before
+* issuing a reset. */
+ bnx2_wait_dma_complete(bp);
+
/* Wait for the firmware to tell us it is ok to issue a reset. */
bnx2_fw_sync(bp, BNX2_DRV_MSG_DATA_WAIT0 | reset_code, 1, 1);
@@ -8580,6 +8597,15 @@ bnx2_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
pci_set_drvdata(pdev, dev);
+ /*
+* In-flight DMA from 1st kernel could continue going in kdump kernel.
+* New io-page table has been created before bnx2 does reset at open
stage.
+* We have to wait for the in-flight DMA to complete to avoid it look up
+* into the newly created io-page table.
+*/
+ if (is_kdump_kernel())
+ bnx2_wait_dma_complete(bp);
+
memcpy(dev->dev_addr, bp->mac_addr, ETH_ALEN);
dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
--
2.5.5
Re: [PATCH 0/2] bnx2: Hard reset bnx2 chip at probe stage
Hi Michael,
On 11/11/16 at 09:37am, Michael Chan wrote:
> On Fri, Nov 11, 2016 at 6:02 AM, Baoquan He wrote:
> > On 11/11/16 at 09:46pm, Baoquan He wrote:
> >> Hi bnx2 experts,
> >>
> >> In commit 3e1be7a ("bnx2: Reset device during driver initialization"),
> >> firmware requesting code was moved from open stage to probe stage.
> >> The reason is in kdump kernel hardware iommu need device be reset in
> >> driver probe stage, otherwise those in-flight DMA from 1st kernel
> >> will continue going and look up into the newly created io-page tables.
> >> So we need reset device to stop in-flight DMA as early as possibe.
> >>
> >> But with commit 3e1be7a merged, people reported their bnx2 driver init
> >> failed because of failed firmware loading. After discussion, it's found
> >> that they built bnx2 driver into kernel, and that makes probe function
> >> bnx2_init_one be called in do_initcalls(). But at this time the initramfs
> >> has not been uncompressed yet and mounted, kernel can't detect firmware.
> >>
> >> So there's only one way to cover both. Try to hard reset the bnx2 device
> >> at probe stage, without involving firmware issues. I tried to add function
> >> bnx2_hard_reset_chip() to do this and it's only called in kdump kernel.
> >> The thing is I am not quite familiar with bnx2 chip spec, just abstract
> >> code from bnx2_reset_chip, the testing result is good.
> >
> > Here I changed to send BNX2_MISC_COMMAND_HD_RESET in BNX2_CHIP_5709
> > case.
> >
>
> From my old 5709 Documentation:
>
> Bit 6 HD_RESET: Writing this bit as 1 will cause the chip to do a
> hard reset like bit 5 except the sticky bits in the PCI function are
> not reset.
>
> Bit 5 POR_RESET: Writing this bit as 1 will cause the chip to do an
> internal reset exactly like a power-up reset. There is no protection
> for this request and it may cause any current PCI cycle to lock up.
> This reset is intended for use under manufacturing conditions only.
>
> So it sounds like doing HD_RESET can potentially cause a PCI bus lock up.
>
> Why not just disable DMA gracefully as done at the beginning of
> bnx2_reset_chip()?
Thanks for your suggestion.
If what I undertand is correct, you meant waiting for the current PCI
transaction to complete, right? I tried and it also works. I like this
idea, will repost v2. Please help check if it meets your thoughts.
Thanks
Baoquan
Re: Debugging Ethernet issues
> When connected to a Gigabit switch > 3.4 negotiates a LAN DHCP setup instantly > 4.7 requires over 5 seconds to do so When you run tcpdump on the DHCP server, are you noticing the first request is missing? What can happen is the dhclient gets started immediately and sends out its first request before auto-negotiation has finished. So this first packet gets lost. The retransmit after a few seconds is then successful. Andrew
Re: [PATCH] net: ethernet: ti: davinci_cpdma: free memory while channel destroy
From: Ivan Khoronzhuk Date: Tue, 8 Nov 2016 15:16:05 +0200 > While create/destroy channel operation memory is not freed. It was > supposed that memory is freed while driver remove. But a channel > can be created and destroyed many times while changing number of > channels with ethtool. > > Based on net-next/master > > Signed-off-by: Ivan Khoronzhuk Applied.
Re: [PATCH] r8169: Module parameter for opt-in of ASPM
From: Kast Bernd Date: Fri, 4 Nov 2016 00:33:06 +0100 > This patch adds a module parameter in order to activate ASPM. By that > the CPU can enter deep sleep modes (PC6) and power consumption can be > reduced (for example from 13W to 8W on my notebook with a Haswell CPU). > Basically, it reapplies d64ec841517a25f6d468bde9f67e5b4cffdc67c7, which > was reverted due to delayed link status detection and increased boot > times on some systems. These bugs are avoided by two actions: > 1) ASPM is turned off by default to avoid any problems with the > default configuration. > 2) Flags for ASPM and clock request are set after ephy_init, > which wasn't respected on the previous patch. Thus ASPM with > this patch could work even with previously failing systems. This feels like grasping at straws. If you feel you've corrected a flaw in the previous ASPM support, then let's reinstate it unconditionally without some module parameter. We'll never find out if you actually did fix ASPM support sufficiently if it's off by default. Only experts like you will ever enable the option. It's usage will be minimal, and therefore the benefits will not be sufficient to justify these changes in the first place.
Re: Source address fib invalidation on IPv6
Hi Hannes, On Sun, Nov 13, 2016 at 1:51 AM, Hannes Frederic Sowa wrote: > You probably need some combination of ipv6_chk_addr and/or > ipv6_check_addr_and_flags (where dev can also be NULL). Be careful if a > IFA_HOST or IFA_LINK address switches from one interface to another. I can confirm this trick works beautifully: https://git.zx2c4.com/WireGuard/commit/?id=eb65810fc6350c50b42abedd1291b12337d3dc3d I'll see if I can fold this into the routing function so that it behaves the same as v4, unless David gets there first. Regards, Jason
Re: Source address fib invalidation on IPv6
On Sun, Nov 13, 2016 at 1:43 AM, Jason A. Donenfeld wrote:
> In perusing through the v6 FIB code, I don't even see an analog of
> __ip_dev_find... Hm?
Of all places, the iscsi code actually has a nice side-by-side
comparison. So far as I can see, the other protocols just omit this
check in the v6 case, which I believe to be errant behavior. For
example, grep for ip_dev_find in the sctp v4 code. The equivalent v6
code is missing the dev check. Ugly! Here's the block I found in
cxgbit_cm.c:
static struct net_device *cxgbit_ipv4_netdev(__be32 saddr)
{
struct net_device *ndev;
ndev = __ip_dev_find(&init_net, saddr, false);
if (!ndev)
return NULL;
return cxgbit_get_real_dev(ndev);
}
static struct net_device *cxgbit_ipv6_netdev(struct in6_addr *addr6)
{
struct net_device *ndev = NULL;
bool found = false;
if (IS_ENABLED(CONFIG_IPV6)) {
for_each_netdev_rcu(&init_net, ndev)
if (ipv6_chk_addr(&init_net, addr6, ndev, 1)) {
found = true;
break;
}
}
if (!found)
return NULL;
return cxgbit_get_real_dev(ndev);
}
It seems like __ip6_dev_find could be made out of that inner loop.
Then existing uses like that iscsi code can be replaced with that
helper function, and the existing ip6 route tail function can be
augmented in the manner you recommended. Seem like a decent
implementation strategy?
I might submit some patches, unless you beat me to it.
Jason
Re: Source address fib invalidation on IPv6
On Sun, Nov 13, 2016, at 01:43, Jason A. Donenfeld wrote:
> On Sat, Nov 12, 2016 at 8:08 PM, Jason A. Donenfeld
> wrote:
> >> Gotcha. I don't see any checks that the saddr is valid similar to what
> >> IPv4 does.
> >>
> >> I think the right place to add a check is in ip6_dst_lookup_tail():
> >> if (!ipv6_addr_any(&fl6->saddr)) {
> >> // saddr is valid for L3 domain
> >> }
> >
> > Right. It should probably do the check here, and return
> > ERR_PTR(-EINVAL), the same as the v4 version, so that ret codes can be
> > checked consistently.
> >
> > Thanks for looking into this. If you're backed up and would like me to
> > submit a patch, just let me know, and I'll give it my best shot.
>
> In perusing through the v6 FIB code, I don't even see an analog of
> __ip_dev_find... Hm?
You probably need some combination of ipv6_chk_addr and/or
ipv6_check_addr_and_flags (where dev can also be NULL). Be careful if a
IFA_HOST or IFA_LINK address switches from one interface to another.
Bye,
Hannes
Re: Source address fib invalidation on IPv6
On Sat, Nov 12, 2016 at 8:08 PM, Jason A. Donenfeld wrote:
>> Gotcha. I don't see any checks that the saddr is valid similar to what IPv4
>> does.
>>
>> I think the right place to add a check is in ip6_dst_lookup_tail():
>> if (!ipv6_addr_any(&fl6->saddr)) {
>> // saddr is valid for L3 domain
>> }
>
> Right. It should probably do the check here, and return
> ERR_PTR(-EINVAL), the same as the v4 version, so that ret codes can be
> checked consistently.
>
> Thanks for looking into this. If you're backed up and would like me to
> submit a patch, just let me know, and I'll give it my best shot.
In perusing through the v6 FIB code, I don't even see an analog of
__ip_dev_find... Hm?
Debugging Ethernet issues
Hello everyone,
In a past thread ("Ethernet not working on a different SoC with
same eth HW") I was struggling getting Ethernet to work at all on
a new board using a recent 4.7 kernel.
After much hair-pulling, it turned out that *some* of the breakage
was caused by a local patch which should have been guarded by a
preprocessor macro.
But even after reverting that patch, Ethernet does not work well
on this board with kernel 4.7 whereas if I use an ancient 3.4 kernel,
then Ethernet works much better.
Differences:
When connected to a 100 Mbps switch
3.4 negotiates a LAN DHCP setup instantly
4.7 times out
When connected to a Gigabit switch
3.4 negotiates a LAN DHCP setup instantly
4.7 requires over 5 seconds to do so
(In case it matters, my board is using an Atheros 8035 PHY.)
I am aware that there have been hundreds of patches to the phy
and net frameworks in the 3.4 to 4.7 time-frame. I'm wondering
if there are important events I can log, to see what is going
wrong in the 4.7 case?
Are there kernel debugging options I might turn on, to better
understand what is going wrong?
I would be extremely grateful for any insight on this subject.
Regards.
Re: [PATCH net-next v13 5/8] openvswitch: add processing of L3 packets
On Thu, Nov 10, 2016 at 7:28 AM, Jiri Benc wrote: > Support receiving, extracting flow key and sending of L3 packets (packets > without an Ethernet header). > > Note that even after this patch, non-Ethernet interfaces are still not > allowed to be added to bridges. Similarly, netlink interface for sending and > receiving L3 packets to/from user space is not in place yet. > > Based on previous versions by Lorand Jakab and Simon Horman. > > Signed-off-by: Lorand Jakab > Signed-off-by: Simon Horman > Signed-off-by: Jiri Benc > --- > v13: > - fix incorrect setting of packet to NULL in ovs_packet_cmd_execute > - dropping packet for interfaces with wrong type > --- Thanks for working on this. Acked-by: Pravin B Shelar
Re: [PATCH net-next v13 7/8] openvswitch: add Ethernet push and pop actions
On Thu, Nov 10, 2016 at 7:28 AM, Jiri Benc wrote: > It's not allowed to push Ethernet header in front of another Ethernet > header. > > It's not allowed to pop Ethernet header if there's a vlan tag. This > preserves the invariant that L3 packet never has a vlan tag. > > Based on previous versions by Lorand Jakab and Simon Horman. > > Signed-off-by: Lorand Jakab > Signed-off-by: Simon Horman > Signed-off-by: Jiri Benc Acked-by: Pravin B Shelar
[PATCH] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
VSC8601 can handle this internally. While the VSC8601 can set more
fine-grained delays, the standard skew settings work out of the box.
The same heuristic is used to determine when this skew should be enabled
as in vsc824x_config_init().
Tested on custom board with AM3352 SOC and VSC801 PHY.
Signed-off-by: Alexandru Gagniuc
---
drivers/net/phy/vitesse.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 2e37eb3..7923831 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -62,6 +62,10 @@
/* Vitesse Extended Page Access Register */
#define MII_VSC82X4_EXT_PAGE_ACCESS0x1f
+/* Vitesse VSC8601 Extended PHY Control Register 1 */
+#define MII_VSC8601_EPHY_CTL 0x17
+#define MII_VSC8601_EPHY_CTL_RGMII_SKEW(1 << 8)
+
#define PHY_ID_VSC8234 0x000fc620
#define PHY_ID_VSC8244 0x000fc6c0
#define PHY_ID_VSC8514 0x00070670
@@ -111,6 +115,31 @@ static int vsc824x_config_init(struct phy_device *phydev)
return err;
}
+static int vsc8601_add_skew(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_read(phydev, MII_VSC8601_EPHY_CTL);
+ if (ret < 0)
+ return ret;
+
+ ret |= MII_VSC8601_EPHY_CTL_RGMII_SKEW;
+ return phy_write(phydev, MII_VSC8601_EPHY_CTL, ret);
+}
+
+static int vsc8601_config_init(struct phy_device *phydev)
+{
+ int ret = 0;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ ret = vsc8601_add_skew(phydev);
+
+ if (ret < 0)
+ return ret;
+
+ return genphy_config_init(phydev);
+}
+
static int vsc824x_ack_interrupt(struct phy_device *phydev)
{
int err = 0;
@@ -275,7 +304,7 @@ static struct phy_driver vsc82xx_driver[] = {
.phy_id_mask= 0x0000,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
- .config_init= &genphy_config_init,
+ .config_init= &vsc8601_config_init,
.config_aneg= &genphy_config_aneg,
.read_status= &genphy_read_status,
.ack_interrupt = &vsc824x_ack_interrupt,
--
2.7.4
[PATCH] net: atheros: atl1e: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
The previous implementation of set_settings was modifying
the value of advertising, but with the new API, it's not
possible. The structure ethtool_link_ksettings is defined
as const.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c | 62 +++
1 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
b/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
index 8e3dbd4..cb489e7 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
@@ -26,73 +26,83 @@
#include "atl1e.h"
-static int atl1e_get_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1e_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
{
struct atl1e_adapter *adapter = netdev_priv(netdev);
struct atl1e_hw *hw = &adapter->hw;
+ u32 supported, advertising;
- ecmd->supported = (SUPPORTED_10baseT_Half |
+ supported = (SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
SUPPORTED_Autoneg |
SUPPORTED_TP);
if (hw->nic_type == athr_l1e)
- ecmd->supported |= SUPPORTED_1000baseT_Full;
+ supported |= SUPPORTED_1000baseT_Full;
- ecmd->advertising = ADVERTISED_TP;
+ advertising = ADVERTISED_TP;
- ecmd->advertising |= ADVERTISED_Autoneg;
- ecmd->advertising |= hw->autoneg_advertised;
+ advertising |= ADVERTISED_Autoneg;
+ advertising |= hw->autoneg_advertised;
- ecmd->port = PORT_TP;
- ecmd->phy_address = 0;
- ecmd->transceiver = XCVR_INTERNAL;
+ cmd->base.port = PORT_TP;
+ cmd->base.phy_address = 0;
if (adapter->link_speed != SPEED_0) {
- ethtool_cmd_speed_set(ecmd, adapter->link_speed);
+ cmd->base.speed = adapter->link_speed;
if (adapter->link_duplex == FULL_DUPLEX)
- ecmd->duplex = DUPLEX_FULL;
+ cmd->base.duplex = DUPLEX_FULL;
else
- ecmd->duplex = DUPLEX_HALF;
+ cmd->base.duplex = DUPLEX_HALF;
} else {
- ethtool_cmd_speed_set(ecmd, SPEED_UNKNOWN);
- ecmd->duplex = DUPLEX_UNKNOWN;
+ cmd->base.speed = SPEED_UNKNOWN;
+ cmd->base.duplex = DUPLEX_UNKNOWN;
}
- ecmd->autoneg = AUTONEG_ENABLE;
+ cmd->base.autoneg = AUTONEG_ENABLE;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
+
return 0;
}
-static int atl1e_set_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1e_set_link_ksettings(struct net_device *netdev,
+ const struct ethtool_link_ksettings *cmd)
{
struct atl1e_adapter *adapter = netdev_priv(netdev);
struct atl1e_hw *hw = &adapter->hw;
+ u32 advertising;
+
+ ethtool_convert_link_mode_to_legacy_u32(&advertising,
+ cmd->link_modes.advertising);
while (test_and_set_bit(__AT_RESETTING, &adapter->flags))
msleep(1);
- if (ecmd->autoneg == AUTONEG_ENABLE) {
+ if (cmd->base.autoneg == AUTONEG_ENABLE) {
u16 adv4, adv9;
- if ((ecmd->advertising&ADVERTISE_1000_FULL)) {
+ if (advertising & ADVERTISE_1000_FULL) {
if (hw->nic_type == athr_l1e) {
hw->autoneg_advertised =
- ecmd->advertising & AT_ADV_MASK;
+ advertising & AT_ADV_MASK;
} else {
clear_bit(__AT_RESETTING, &adapter->flags);
return -EINVAL;
}
- } else if (ecmd->advertising&ADVERTISE_1000_HALF) {
+ } else if (advertising & ADVERTISE_1000_HALF) {
clear_bit(__AT_RESETTING, &adapter->flags);
return -EINVAL;
} else {
hw->autoneg_advertised =
- ecmd->advertising & AT_ADV_MASK;
+ advertising & AT_ADV_MASK;
}
- ecmd->
Re: [PATCH] genetlink: fix unsigned int comparison with less than zero
On Thu, 2016-11-10 at 09:11 -0800, Cong Wang wrote: > On Thu, Nov 10, 2016 at 7:57 AM, Colin King > wrote: > > > > From: Colin Ian King > > > > family->id is unsigned, so the less than zero check for > > failure return from idr_alloc is never true and so the error exit > > is never handled. Instead, assign err and check if this is less > > than zero since this is a signed integer. > > Why family->id can't be just signed int? For me it should be. I suppose it could be, since family IDs are allocated in a 16-bit range anyway. But family IDs can also never actually be negative, so having an unsigned int in the struct makes sense too. I tend to think this patch is fine. johannes
Re: Source address fib invalidation on IPv6
Hi David,
On Sat, Nov 12, 2016 at 7:14 PM, David Ahern wrote:
> I believe that is coming from __ip_route_output_key_hash(), line 2232 with
> __ip_dev_find not finding a device with that address.
It's possible we simply are looking at different source trees, but I
have the -EINVAL return in 4.8 route.c sources happening due to the
assignment on line 2175 and the jump on line 2220.
> Not applicable for your use case, but __ip_dev_find does not have any checks
> on which L3 domain the device belongs to so the check does not handle VRF for
> example. I'll take a look at fixing this next week.
Interesting.
>
> Gotcha. I don't see any checks that the saddr is valid similar to what IPv4
> does.
>
> I think the right place to add a check is in ip6_dst_lookup_tail():
> if (!ipv6_addr_any(&fl6->saddr)) {
> // saddr is valid for L3 domain
> }
Right. It should probably do the check here, and return
ERR_PTR(-EINVAL), the same as the v4 version, so that ret codes can be
checked consistently.
Thanks for looking into this. If you're backed up and would like me to
submit a patch, just let me know, and I'll give it my best shot.
Regards,
Jason
Re: Source address fib invalidation on IPv6
On 11/12/16 8:40 AM, Jason A. Donenfeld wrote:
> Hi again,
>
> I've done some pretty in depth debugging now to determine exactly what
> the behavior of ipv6_stub->ipv6_dst_lookup is. First I'll start with
> ip_route_output_flow, which I believe to be well behaved, and then
> I'll show ipv6_stub->ipv6_dst_lookup, which seems ill-behaved:
>
> Userspace:
> ip addr add 192.168.1.2/24 dev eth0
> Kernelspace:
> struct flowi4 fl = {
>.saddr = 192.168.1.2,
>.daddr = 192.168.1.99,
> };
> rt = ip_route_output_flow(sock_net(sock), &fl, sock);
> // rt returns valid rt for routing to 192.168.1.99 from
> 192.168.1.2 using eth0
> Userspace:
> ip addr add 192.168.1.3/24 dev eth0
> ip addr del 192.168.1.2/24 dev eth0
> Kernelspace:
> struct flowi4 fl = {
>.saddr = 192.168.1.2,
>.daddr = 192.168.1.99,
> };
> rt = ip_route_output_flow(sock_net(sock), &fl, sock);
> // PTR_ERR(rt) == -EINVAL
I believe that is coming from __ip_route_output_key_hash(), line 2232 with
__ip_dev_find not finding a device with that address.
Not applicable for your use case, but __ip_dev_find does not have any checks on
which L3 domain the device belongs to so the check does not handle VRF for
example. I'll take a look at fixing this next week.
>
> This seems correct behavior to me, since no interface has 192.168.1.2
> as a source address.
>
> Now for the incorrect IPv6 behavior:
>
> Userspace:
> ip -6 addr add abcd::2/96 dev eth0
> Kernelspace:
> struct flowi6 fl = {
>.saddr = abcd::2,
>.daddr = abcd::99,
> };
> ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
> // ret is 0, and dst is a non-null dst routing to abcd::99 from
> abcd::2 using eth0
> Userspace:
> ip -6 addr add abcd::3/96 dev eth0
> ip -6 addr del abcd::2/96 dev eth0
> Kernelspace:
> struct flowi6 fl = {
>.saddr = abcd::2,
>.daddr = abcd::99,
> };
> ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
> // ret is 0, and dst is a non-null dst routing to abcd::99 from
> abcd::2 using eth0 **INCORRECT BEHAVIOR!**
>
> This seems *INCORRECT* behavior to me, since no interface has abcd::2
> as a source address.
Gotcha. I don't see any checks that the saddr is valid similar to what IPv4
does.
I think the right place to add a check is in ip6_dst_lookup_tail():
if (!ipv6_addr_any(&fl6->saddr)) {
// saddr is valid for L3 domain
}
[PATCH] net: ethernet: ixp4xx_eth: fix spelling mistake in debug message
From: Colin Ian King
Trivial fix to spelling mistake "successed" to "succeeded"
in debug message. Also unwrap multi-line literal string.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/xscale/ixp4xx_eth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c
b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 46cc33b..07d862d 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -708,8 +708,7 @@ static int eth_poll(struct napi_struct *napi, int budget)
if (!qmgr_stat_below_low_watermark(rxq) &&
napi_reschedule(napi)) { /* not empty again */
#if DEBUG_RX
- printk(KERN_DEBUG "%s: eth_poll"
- " napi_reschedule successed\n",
+ printk(KERN_DEBUG "%s: eth_poll napi_reschedule
succeeded\n",
dev->name);
#endif
qmgr_disable_irq(rxq);
--
2.10.2
[PATCH] ps3_gelic: fix spelling mistake in debug message
From: Colin Ian King
Trivial fix to spelling mistake "unmached" to "unmatched" in
debug message.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
index b3abd02..eed18f8 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
@@ -1694,7 +1694,7 @@ struct gelic_wl_scan_info *gelic_wl_find_best_bss(struct
gelic_wl_info *wl)
pr_debug("%s: bssid matched\n", __func__);
break;
} else {
- pr_debug("%s: bssid unmached\n", __func__);
+ pr_debug("%s: bssid unmatched\n", __func__);
continue;
}
}
--
2.10.2
[PATCH] net: atheros: atl1c: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c | 54 +++-
1 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
b/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
index 872b7ab..cfe86a2 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
@@ -26,46 +26,52 @@
#include "atl1c.h"
-static int atl1c_get_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1c_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
{
struct atl1c_adapter *adapter = netdev_priv(netdev);
struct atl1c_hw *hw = &adapter->hw;
+ u32 supported, advertising;
- ecmd->supported = (SUPPORTED_10baseT_Half |
+ supported = (SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
SUPPORTED_Autoneg |
SUPPORTED_TP);
if (hw->link_cap_flags & ATL1C_LINK_CAP_1000M)
- ecmd->supported |= SUPPORTED_1000baseT_Full;
+ supported |= SUPPORTED_1000baseT_Full;
- ecmd->advertising = ADVERTISED_TP;
+ advertising = ADVERTISED_TP;
- ecmd->advertising |= hw->autoneg_advertised;
+ advertising |= hw->autoneg_advertised;
- ecmd->port = PORT_TP;
- ecmd->phy_address = 0;
- ecmd->transceiver = XCVR_INTERNAL;
+ cmd->base.port = PORT_TP;
+ cmd->base.phy_address = 0;
if (adapter->link_speed != SPEED_0) {
- ethtool_cmd_speed_set(ecmd, adapter->link_speed);
+ cmd->base.speed = adapter->link_speed;
if (adapter->link_duplex == FULL_DUPLEX)
- ecmd->duplex = DUPLEX_FULL;
+ cmd->base.duplex = DUPLEX_FULL;
else
- ecmd->duplex = DUPLEX_HALF;
+ cmd->base.duplex = DUPLEX_HALF;
} else {
- ethtool_cmd_speed_set(ecmd, SPEED_UNKNOWN);
- ecmd->duplex = DUPLEX_UNKNOWN;
+ cmd->base.speed = SPEED_UNKNOWN;
+ cmd->base.duplex = DUPLEX_UNKNOWN;
}
- ecmd->autoneg = AUTONEG_ENABLE;
+ cmd->base.autoneg = AUTONEG_ENABLE;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
+
return 0;
}
-static int atl1c_set_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1c_set_link_ksettings(struct net_device *netdev,
+ const struct ethtool_link_ksettings *cmd)
{
struct atl1c_adapter *adapter = netdev_priv(netdev);
struct atl1c_hw *hw = &adapter->hw;
@@ -74,12 +80,12 @@ static int atl1c_set_settings(struct net_device *netdev,
while (test_and_set_bit(__AT_RESETTING, &adapter->flags))
msleep(1);
- if (ecmd->autoneg == AUTONEG_ENABLE) {
+ if (cmd->base.autoneg == AUTONEG_ENABLE) {
autoneg_advertised = ADVERTISED_Autoneg;
} else {
- u32 speed = ethtool_cmd_speed(ecmd);
+ u32 speed = cmd->base.speed;
if (speed == SPEED_1000) {
- if (ecmd->duplex != DUPLEX_FULL) {
+ if (cmd->base.duplex != DUPLEX_FULL) {
if (netif_msg_link(adapter))
dev_warn(&adapter->pdev->dev,
"1000M half is invalid\n");
@@ -88,12 +94,12 @@ static int atl1c_set_settings(struct net_device *netdev,
}
autoneg_advertised = ADVERTISED_1000baseT_Full;
} else if (speed == SPEED_100) {
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
autoneg_advertised = ADVERTISED_100baseT_Full;
else
autoneg_advertised = ADVERTISED_100baseT_Half;
} else {
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
autoneg_advertised = ADVERTISED_10baseT_Full;
else
autoneg_advertised = ADVERTISED_10baseT_Half;
@@ -284,8 +290,6
Re: Spurious code in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37 auto-negotiation"
On 11/12/2016 8:34 AM, Marion & Christophe JAILLET wrote:
> Hi,
>
> in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37
> auto-negotiation"), we can find:
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> index 695e982..8bcf4ef 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
>[...]
>#define XGBE_AN_CL37_PCS_MODE_MASK0x06
>#define XGBE_AN_CL37_PCS_MODE_BASEX0x00
>#define XGBE_AN_CL37_PCS_MODE_SGMII0x04
>#define XGBE_AN_CL37_TX_CONFIG_MASK0x08
>[...]
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> index d5bfbe4..723eb90 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
>[...]
>/* Set up the Control register */
>reg = XMDIO_READ(pdata, MDIO_MMD_VEND2, MDIO_VEND2_AN_CTRL);
>reg &= XGBE_AN_CL37_TX_CONFIG_MASK;
>reg &= XGBE_AN_CL37_PCS_MODE_MASK;
>[...]
>
> the "reg &=" statements look spurious. The 2 constants being 0x06 and
> 0x08, the current code is equivalent to "reg = 0"
>
> It is likely that "reg |=" (or "reg &= ~") was expected here.
Yes, those should have been "reg &= ~". I didn't find this in my testing
because the register is all zeroes after reset. I'll submit a patch to
fix that.
Thanks,
Tom
>
> Best regards,
> CJ
>
Re: Source address fib invalidation on IPv6
Hi again,
I've done some pretty in depth debugging now to determine exactly what
the behavior of ipv6_stub->ipv6_dst_lookup is. First I'll start with
ip_route_output_flow, which I believe to be well behaved, and then
I'll show ipv6_stub->ipv6_dst_lookup, which seems ill-behaved:
Userspace:
ip addr add 192.168.1.2/24 dev eth0
Kernelspace:
struct flowi4 fl = {
.saddr = 192.168.1.2,
.daddr = 192.168.1.99,
};
rt = ip_route_output_flow(sock_net(sock), &fl, sock);
// rt returns valid rt for routing to 192.168.1.99 from
192.168.1.2 using eth0
Userspace:
ip addr add 192.168.1.3/24 dev eth0
ip addr del 192.168.1.2/24 dev eth0
Kernelspace:
struct flowi4 fl = {
.saddr = 192.168.1.2,
.daddr = 192.168.1.99,
};
rt = ip_route_output_flow(sock_net(sock), &fl, sock);
// PTR_ERR(rt) == -EINVAL
This seems correct behavior to me, since no interface has 192.168.1.2
as a source address.
Now for the incorrect IPv6 behavior:
Userspace:
ip -6 addr add abcd::2/96 dev eth0
Kernelspace:
struct flowi6 fl = {
.saddr = abcd::2,
.daddr = abcd::99,
};
ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
// ret is 0, and dst is a non-null dst routing to abcd::99 from
abcd::2 using eth0
Userspace:
ip -6 addr add abcd::3/96 dev eth0
ip -6 addr del abcd::2/96 dev eth0
Kernelspace:
struct flowi6 fl = {
.saddr = abcd::2,
.daddr = abcd::99,
};
ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
// ret is 0, and dst is a non-null dst routing to abcd::99 from
abcd::2 using eth0 **INCORRECT BEHAVIOR!**
This seems *INCORRECT* behavior to me, since no interface has abcd::2
as a source address.
So, to summarize, the problem is that ipv6_dst_lookup will happily
return a dst even though the source IP has been removed from the
interface.
I hope this clarifies things. I await your response.
Regards,
Jason
Spurious code in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37 auto-negotiation"
Hi,
in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37
auto-negotiation"), we can find:
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
index 695e982..8bcf4ef 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
[...]
#define XGBE_AN_CL37_PCS_MODE_MASK0x06
#define XGBE_AN_CL37_PCS_MODE_BASEX0x00
#define XGBE_AN_CL37_PCS_MODE_SGMII0x04
#define XGBE_AN_CL37_TX_CONFIG_MASK0x08
[...]
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
index d5bfbe4..723eb90 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
[...]
/* Set up the Control register */
reg = XMDIO_READ(pdata, MDIO_MMD_VEND2, MDIO_VEND2_AN_CTRL);
reg &= XGBE_AN_CL37_TX_CONFIG_MASK;
reg &= XGBE_AN_CL37_PCS_MODE_MASK;
[...]
the "reg &=" statements look spurious. The 2 constants being 0x06 and
0x08, the current code is equivalent to "reg = 0"
It is likely that "reg |=" (or "reg &= ~") was expected here.
Best regards,
CJ
I Hope You Get My Message This Time
-- This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
Re: [PATCH net 2/2] r8152: rx descriptor check
On 16-11-11 07:13 AM, Francois Romieu wrote: > Hayes Wang : >> For some platforms, the data in memory is not the same with the one >> from the device. That is, the data of memory is unbelievable. The >> check is used to find out this situation. > > Invalid packet size corrupted receive descriptors in Realtek's device > reminds of CVE-2009-4537. > > Is the silicium of both devices different enough to prevent the same > exploit to happen ? I don't know if the hardware can do it, but the existing Linux device driver regularly attempts to process huge unreal packet sizes here. I've had to patch it to reject "packets" larger than the configured MRU. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com
did you receive my previous email ?
-- This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
Re: net/sctp: BUG: KASAN: stack-out-of-bounds in memcmp
On 2016/11/10 13:48, Xin Long wrote:
> On Sat, Oct 15, 2016 at 4:28 PM, Baozeng Ding wrote:
>> Hello Xin Long,
>>
>> On 2016/10/14 19:13, Xin Long wrote:
>>> On Sat, Aug 20, 2016 at 3:51 PM, Baozeng Ding wrote:
Hello all,
The following program triggers stack-out-of-bounds in memcmp. The kernel
version is 4.8.0-rc1+ (on Aug 13 commit
118253a593bd1c57de2d1193df1ccffe1abe745b). Thanks.
>>> ...
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
int main()
{
int fd;
mmap((void *)0x2000ul, 0xff2000ul, 0x3ul, 0x32ul, -1, 0x0ul);
fd = socket(AF_INET6, SOCK_STREAM, IPPROTO_SCTP);
memcpy((void*)0x20f82f80,
"\x0a\x00\xab\x12\x72\xd4\x19\x9a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x85\xda\x00\xa0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
128);
bind(fd, (struct sockaddr*)0x20f82f80ul, 0x80ul);
*(uint64_t*)0x202e1fc8 = (uint64_t)0x20f77f80;
*(uint32_t*)0x202e1fd0 = (uint32_t)0x80;
*(uint64_t*)0x202e1fd8 = (uint64_t)0x20f7dfe0;
*(uint64_t*)0x202e1fe0 = (uint64_t)0x2;
*(uint64_t*)0x202e1fe8 = (uint64_t)0x20f77000;
*(uint64_t*)0x202e1ff0 = (uint64_t)0x3;
*(uint32_t*)0x202e1ff8 = (uint32_t)0x80;
memcpy((void*)0x20f77f80,
"\x0a\x00\xab\x12\xb0\xb3\x20\x7b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xc2\xc2\x0b\xb2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
128);
*(uint64_t*)0x20f7dfe0 = (uint64_t)0x20f77fc5;
*(uint64_t*)0x20f7dfe8 = (uint64_t)0x3b;
*(uint64_t*)0x20f7dff0 = (uint64_t)0x20f77fac;
*(uint64_t*)0x20f7dff8 = (uint64_t)0x54;
memcpy((void*)0x20f77fc5,
"\xa5\x7d\xf3\xc4\xfe\xd3\xfd\x44\x63\x00\x8c\x1e\x4c\x2e\x8d\x8d\x9a\x9c\x9c\x9d\x5b\x7c\xe1\x06\xf7\x15\x16\xed\x68\xd1\xfc\xf4\xa4\x3a\xe4\x69\x51\x16\x74\xf4\x1a\xcf\x0e\x99\xc3\xa3\x87\xe7\x81\x6c\x10\x78\x75\x17\x69\x9d\x11\x0c\xc7",
59);
memcpy((void*)0x20f77fac,
"\x86\x08\x89\x3c\xf3\x58\xea\xe7\x64\x6a\xfb\xb5\xe8\xdd\x5f\x69\xa5\xd4\xdc\xd9\xe7\x71\x95\x07\x78\x7b\x21\xda\x43\x9c\x62\x4d\xca\x64\xb5\x6e\x96\x55\xe9\x58\x76\x66\x1d\xb9\x7b\xe6\x20\xc1\xa9\xed\x70\xc1\x2b\x7c\x86\x8c\xba\x28\xb3\x2c\xb9\x64\xb7\x84\x65\x0d\x7f\xa6\x98\x6f\x49\xcb\x35\xad\x5a\xdf\x13\x75\x99\x57\x7e\xbb\x38\x89",
84);
*(uint64_t*)0x20f77000 = (uint64_t)0x15;
*(uint32_t*)0x20f77008 = (uint32_t)0x1;
*(uint32_t*)0x20f7700c = (uint32_t)0xfffe;
*(uint8_t*)0x20f77010 = (uint8_t)0xbb;
*(uint8_t*)0x20f77011 = (uint8_t)0x2;
*(uint8_t*)0x20f77012 = (uint8_t)0x5;
*(uint8_t*)0x20f77013 = (uint8_t)0x2;
*(uint8_t*)0x20f77014 = (uint8_t)0x8000;
*(uint64_t*)0x20f77015 = (uint64_t)0x10;
*(uint32_t*)0x20f7701d = (uint32_t)0x;
*(uint32_t*)0x20f77021 = (uint32_t)0x1;
*(uint64_t*)0x20f77025 = (uint64_t)0x13;
*(uint32_t*)0x20f7702d = (uint32_t)0x6;
*(uint32_t*)0x20f77031 = (uint32_t)0xfe00;
*(uint8_t*)0x20f77035 = (uint8_t)0x8000;
*(uint8_t*)0x20f77036 = (uint8_t)0xfff8;
sendmmsg(fd, (struct mmsghdr *)0x202e1fc8ul, 0x1ul, 0x1ul);
return 0;
}
>>> Hi, Baozeng, I couldn't reproduce this issue with this script,
>>> even in 118253a593bd1c57de2d1193df1ccffe1abe745b
>>> do I need to do some extra config for this ?
>>>
>> You need config KASAN.
>> CONFIG_HAVE_ARCH_KASAN=y
>> CONFIG_KASAN=y
>> CONFIG_KASAN_INLINE=y
>> CONFIG_KASAN_SHADOW_OFFSET=0xdc00
>>
>> I justed tested with b67be92feb486f800d80d72c67fd87b47b79b18e(Octor 12),
>> it sitll exits. If you still cannot reproduce it, i will send the .config to
>> you privately. Thanks.
>>
>
> Hi Baozeng, sorry for so late. but this issue is always on my radar.
>
> I still couldnot reproduce it, even on
> b67be92feb486f800d80d72c67fd87b47b79b18e in any of
> git://git.kernel.org/pub/
I Hope You Get My Message This Time
-- This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
I Hope You Get My Message This Time
-- This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
I Hope You Get My Message This Time
-- This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
