Netdev List
 help / color / mirror / Atom feed
* [PATCH 4/5] net: remove the PCI_DMA_BUS_IS_PHYS check in illegal_highdma
From: Christoph Hellwig @ 2018-04-24 18:16 UTC (permalink / raw)
  To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-arch-u79uwXL29TY76Z2rM5mHXA,
	linux-block-u79uwXL29TY76Z2rM5mHXA,
	linux-ide-u79uwXL29TY76Z2rM5mHXA,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
  Cc: David S. Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180424181625.22410-1-hch-jcswGhMUV9g@public.gmane.org>

These days the dma mapping routines must be able to handle any address
supported by the device, be that using an iommu, or swiotlb if none is
supported.  With that the PCI_DMA_BUS_IS_PHYS check in illegal_highdma
is not needed and can be removed.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 net/core/dev.c | 20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index af0558b00c6c..060256cbf4f3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2884,11 +2884,7 @@ void netdev_rx_csum_fault(struct net_device *dev)
 EXPORT_SYMBOL(netdev_rx_csum_fault);
 #endif
 
-/* Actually, we should eliminate this check as soon as we know, that:
- * 1. IOMMU is present and allows to map all the memory.
- * 2. No high memory really exists on this machine.
- */
-
+/* XXX: check that highmem exists at all on the given machine. */
 static int illegal_highdma(struct net_device *dev, struct sk_buff *skb)
 {
 #ifdef CONFIG_HIGHMEM
@@ -2902,20 +2898,6 @@ static int illegal_highdma(struct net_device *dev, struct sk_buff *skb)
 				return 1;
 		}
 	}
-
-	if (PCI_DMA_BUS_IS_PHYS) {
-		struct device *pdev = dev->dev.parent;
-
-		if (!pdev)
-			return 0;
-		for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
-			skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
-			dma_addr_t addr = page_to_phys(skb_frag_page(frag));
-
-			if (!pdev->dma_mask || addr + PAGE_SIZE - 1 > *pdev->dma_mask)
-				return 1;
-		}
-	}
 #endif
 	return 0;
 }
-- 
2.17.0

^ permalink raw reply related

* [PATCH 3/5] ide: remove the PCI_DMA_BUS_IS_PHYS check
From: Christoph Hellwig @ 2018-04-24 18:16 UTC (permalink / raw)
  To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-arch-u79uwXL29TY76Z2rM5mHXA,
	linux-block-u79uwXL29TY76Z2rM5mHXA,
	linux-ide-u79uwXL29TY76Z2rM5mHXA,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
  Cc: David S. Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180424181625.22410-1-hch-jcswGhMUV9g@public.gmane.org>

We now have ways to deal with drainage in the block layer, and libata has
been using it for ages.  We also want to get rid of PCI_DMA_BUS_IS_PHYS
now, so just reduce the PCI transfer size for ide - anyone who cares for
performance on PCI controllers should have switched to libata long ago.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 drivers/ide/ide-probe.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
index 8d8ed036ca0a..56d7bc228cb3 100644
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -796,8 +796,7 @@ static int ide_init_queue(ide_drive_t *drive)
 	 * This will be fixed once we teach pci_map_sg() about our boundary
 	 * requirements, hopefully soon. *FIXME*
 	 */
-	if (!PCI_DMA_BUS_IS_PHYS)
-		max_sg_entries >>= 1;
+	max_sg_entries >>= 1;
 #endif /* CONFIG_PCI */
 
 	blk_queue_max_segments(q, max_sg_entries);
-- 
2.17.0

^ permalink raw reply related

* [PATCH 2/5] ide: kill ide_toggle_bounce
From: Christoph Hellwig @ 2018-04-24 18:16 UTC (permalink / raw)
  To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-arch-u79uwXL29TY76Z2rM5mHXA,
	linux-block-u79uwXL29TY76Z2rM5mHXA,
	linux-ide-u79uwXL29TY76Z2rM5mHXA,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
  Cc: David S. Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180424181625.22410-1-hch-jcswGhMUV9g@public.gmane.org>

ide_toggle_bounce did select various strange block bounce limits, including
not bouncing at all as soon as an iommu is present in the system.  Given
that the dma_map routines now handle any required bounce buffering except
for ISA DMA, and the ide code already must handle either ISA DMA or highmem
at least for iommu equipped systems we can get rid of the block layer
bounce limit setting entirely.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 drivers/ide/ide-dma.c   |  2 --
 drivers/ide/ide-lib.c   | 26 --------------------------
 drivers/ide/ide-probe.c |  3 ---
 include/linux/ide.h     |  2 --
 4 files changed, 33 deletions(-)

diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
index 54d4d78ca46a..6f344654ef22 100644
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -180,7 +180,6 @@ EXPORT_SYMBOL_GPL(ide_dma_unmap_sg);
 void ide_dma_off_quietly(ide_drive_t *drive)
 {
 	drive->dev_flags &= ~IDE_DFLAG_USING_DMA;
-	ide_toggle_bounce(drive, 0);
 
 	drive->hwif->dma_ops->dma_host_set(drive, 0);
 }
@@ -211,7 +210,6 @@ EXPORT_SYMBOL(ide_dma_off);
 void ide_dma_on(ide_drive_t *drive)
 {
 	drive->dev_flags |= IDE_DFLAG_USING_DMA;
-	ide_toggle_bounce(drive, 1);
 
 	drive->hwif->dma_ops->dma_host_set(drive, 1);
 }
diff --git a/drivers/ide/ide-lib.c b/drivers/ide/ide-lib.c
index e1180fa46196..78cb79eddc8b 100644
--- a/drivers/ide/ide-lib.c
+++ b/drivers/ide/ide-lib.c
@@ -6,32 +6,6 @@
 #include <linux/ide.h>
 #include <linux/bitops.h>
 
-/**
- *	ide_toggle_bounce	-	handle bounce buffering
- *	@drive: drive to update
- *	@on: on/off boolean
- *
- *	Enable or disable bounce buffering for the device. Drives move
- *	between PIO and DMA and that changes the rules we need.
- */
-
-void ide_toggle_bounce(ide_drive_t *drive, int on)
-{
-	u64 addr = BLK_BOUNCE_HIGH;	/* dma64_addr_t */
-
-	if (!PCI_DMA_BUS_IS_PHYS) {
-		addr = BLK_BOUNCE_ANY;
-	} else if (on && drive->media == ide_disk) {
-		struct device *dev = drive->hwif->dev;
-
-		if (dev && dev->dma_mask)
-			addr = *dev->dma_mask;
-	}
-
-	if (drive->queue)
-		blk_queue_bounce_limit(drive->queue, addr);
-}
-
 u64 ide_get_lba_addr(struct ide_cmd *cmd, int lba48)
 {
 	struct ide_taskfile *tf = &cmd->tf;
diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
index 2019e66eada7..8d8ed036ca0a 100644
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -805,9 +805,6 @@ static int ide_init_queue(ide_drive_t *drive)
 	/* assign drive queue */
 	drive->queue = q;
 
-	/* needs drive->queue to be set */
-	ide_toggle_bounce(drive, 1);
-
 	return 0;
 }
 
diff --git a/include/linux/ide.h b/include/linux/ide.h
index ca9d34feb572..11f0dd03a4b4 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1508,8 +1508,6 @@ static inline void ide_set_hwifdata (ide_hwif_t * hwif, void *data)
 	hwif->hwif_data = data;
 }
 
-extern void ide_toggle_bounce(ide_drive_t *drive, int on);
-
 u64 ide_get_lba_addr(struct ide_cmd *, int);
 u8 ide_dump_status(ide_drive_t *, const char *, u8);
 
-- 
2.17.0

^ permalink raw reply related

* [PATCH 1/5] scsi: reduce use of block bounce buffers
From: Christoph Hellwig @ 2018-04-24 18:16 UTC (permalink / raw)
  To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-arch-u79uwXL29TY76Z2rM5mHXA,
	linux-block-u79uwXL29TY76Z2rM5mHXA,
	linux-ide-u79uwXL29TY76Z2rM5mHXA,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
  Cc: David S. Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180424181625.22410-1-hch-jcswGhMUV9g@public.gmane.org>

We can rely on the dma-mapping code to handle any DMA limits that is
bigger than the ISA DMA mask for us (either using an iommu or swiotlb),
so remove setting the block layer bounce limit for anything but the
unchecked_isa_dma case, or the bouncing for highmem pages.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 drivers/scsi/scsi_lib.c | 24 ++----------------------
 1 file changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index e9b4f279d29c..e0b614c0b1e6 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2149,27 +2149,6 @@ static int scsi_map_queues(struct blk_mq_tag_set *set)
 	return blk_mq_map_queues(set);
 }
 
-static u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
-{
-	struct device *host_dev;
-	u64 bounce_limit = 0xffffffff;
-
-	if (shost->unchecked_isa_dma)
-		return BLK_BOUNCE_ISA;
-	/*
-	 * Platforms with virtual-DMA translation
-	 * hardware have no practical limit.
-	 */
-	if (!PCI_DMA_BUS_IS_PHYS)
-		return BLK_BOUNCE_ANY;
-
-	host_dev = scsi_get_device(shost);
-	if (host_dev && host_dev->dma_mask)
-		bounce_limit = (u64)dma_max_pfn(host_dev) << PAGE_SHIFT;
-
-	return bounce_limit;
-}
-
 void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
 {
 	struct device *dev = shost->dma_dev;
@@ -2189,7 +2168,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
 	}
 
 	blk_queue_max_hw_sectors(q, shost->max_sectors);
-	blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
+	if (shost->unchecked_isa_dma)
+		blk_queue_bounce_limit(q, BLK_BOUNCE_ISA);
 	blk_queue_segment_boundary(q, shost->dma_boundary);
 	dma_set_seg_boundary(dev, shost->dma_boundary);
 
-- 
2.17.0

^ permalink raw reply related

* remove PCI_DMA_BUS_IS_PHYS V2
From: Christoph Hellwig @ 2018-04-24 18:16 UTC (permalink / raw)
  To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-arch-u79uwXL29TY76Z2rM5mHXA,
	linux-block-u79uwXL29TY76Z2rM5mHXA,
	linux-ide-u79uwXL29TY76Z2rM5mHXA,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
  Cc: David S. Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA

Hi all,

this series tries to get rid of the global and PCI_DMA_BUS_IS_PHYS flag,
which causes the block layer and networking code to bounce buffer memory
above the dma mask in some cases.  It is a leftover from i386 + highmem
days and is obsolete now that we have swiotlb or iommus so that the
dma ops implementations can always (minus the ISA DMA case which
will require further attention) handle memory passed to them.

Changes since V1:
 - dropped all patches not strictly required to remove
   PCI_DMA_BUS_IS_PHYS, those will be resent separately

^ permalink raw reply

* Re: [PATCH] net: phy: allow scanning busses with missing phys
From: Alexandre Belloni @ 2018-04-24 18:09 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Andrew Lunn, David S . Miller, Allan Nielsen, Thomas Petazzoni,
	netdev, linux-kernel
In-Reply-To: <2833f30a-cf95-e5c7-e44f-218929e61024@gmail.com>

On 24/04/2018 09:37:09-0700, Florian Fainelli wrote:
> 
> 
> On 04/24/2018 09:09 AM, Alexandre Belloni wrote:
> > Some MDIO busses will error out when trying to read a phy address with no
> > phy present at that address. In that case, probing the bus will fail
> > because __mdiobus_register() is scanning the bus for all possible phys
> > addresses.
> > 
> > In case MII_PHYSID1 returns -EIO or -ENODEV, consider there is no phy at
> > this address and set the phy ID to 0xffffffff which is then properly
> > handled in get_phy_device().
> 
> Humm, why not have your MDIO bus implementation do the scanning itself
> in a reset() callback, which happens before probing the bus, and based
> on the results, set phy_mask accordingly such that only PHYs present are
> populated?
> 
> My only concern with your change is that we are having a special
> treatment for EIO and ENODEV, so we must make sure MDIO bus drivers are
> all conforming to that.
> 

That was what I was doing in [1] but it seems that Andrew preferred this way.

The third solution I was seeing was to return phy_reg instead of -EIO so
the MDIO driver can return -ENODEV and that would be passed to
get_phy_device(). __mdiobus_register() seems to handle -ENODEV properly.

My coccinelle-fu is not great but the following drivers can return
-ENODEV from their read callback:

drivers/net/ethernet/marvell/mvmdio.c
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c (seeing the error message,
this has probably been copy pasted)

[1] https://marc.info/?l=linux-netdev&m=152183609927933&w=2

> > 
> > Suggested-by: Andrew Lunn <andrew@lunn.ch>
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > ---
> >  drivers/net/phy/phy_device.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > index ac23322a32e1..9e4ba8e80a18 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -535,8 +535,17 @@ static int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id,
> >  
> >  	/* Grab the bits from PHYIR1, and put them in the upper half */
> >  	phy_reg = mdiobus_read(bus, addr, MII_PHYSID1);
> > -	if (phy_reg < 0)
> > +	if (phy_reg < 0) {
> > +		/* if there is no device, return without an error so scanning
> > +		 * the bus works properly
> > +		 */
> > +		if (phy_reg == -EIO || phy_reg == -ENODEV) {
> > +			*phy_id = 0xffffffff;
> > +			return 0;
> > +		}
> > +
> >  		return -EIO;
> > +	}
> >  
> >  	*phy_id = (phy_reg & 0xffff) << 16;
> >  
> > 
> 
> -- 
> Florian

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH] net: nfp: fix nfp_net_tx()'s return type
From: Jakub Kicinski @ 2018-04-24 18:09 UTC (permalink / raw)
  To: Luc Van Oostenryck
  Cc: linux-kernel, David S. Miller, Simon Horman, Daniel Borkmann,
	Dirk van der Merwe, Pablo Cascón, oss-drivers, netdev
In-Reply-To: <20180424131710.4206-1-luc.vanoostenryck@gmail.com>

On Tue, 24 Apr 2018 15:17:07 +0200, Luc Van Oostenryck wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
> 
> Fix this by returning 'netdev_tx_t' in this driver too.
> 
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>

Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>

^ permalink raw reply

* Re: [PATCH V7 net-next 00/14] TLS offload, netdev & MLX5 support
From: David Miller @ 2018-04-24 18:02 UTC (permalink / raw)
  To: borisp; +Cc: netdev, saeedm, davejwatson, ktkhai
In-Reply-To: <1524575585-49541-1-git-send-email-borisp@mellanox.com>

From: Boris Pismenny <borisp@mellanox.com>
Date: Tue, 24 Apr 2018 16:12:51 +0300

> The following series provides TLS TX inline crypto offload.

Unfortunately the mlx5 bits don't apply cleanly to net-next, please
respin.

Thank you.

^ permalink raw reply

* Re: [PATCH] net: phy: allow scanning busses with missing phys
From: Andrew Lunn @ 2018-04-24 18:01 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Alexandre Belloni, David S . Miller, Allan Nielsen,
	Thomas Petazzoni, netdev, linux-kernel
In-Reply-To: <2833f30a-cf95-e5c7-e44f-218929e61024@gmail.com>

On Tue, Apr 24, 2018 at 09:37:09AM -0700, Florian Fainelli wrote:
> 
> 
> On 04/24/2018 09:09 AM, Alexandre Belloni wrote:
> > Some MDIO busses will error out when trying to read a phy address with no
> > phy present at that address. In that case, probing the bus will fail
> > because __mdiobus_register() is scanning the bus for all possible phys
> > addresses.
> > 
> > In case MII_PHYSID1 returns -EIO or -ENODEV, consider there is no phy at
> > this address and set the phy ID to 0xffffffff which is then properly
> > handled in get_phy_device().
> 
> Humm, why not have your MDIO bus implementation do the scanning itself
> in a reset() callback, which happens before probing the bus, and based
> on the results, set phy_mask accordingly such that only PHYs present are
> populated?

Hi Florian

Seems a bit odd have the driver do this, when the core could.

> My only concern with your change is that we are having a special
> treatment for EIO and ENODEV, so we must make sure MDIO bus drivers are
> all conforming to that.
 
I don't see how it could be a problem. It used to be any error was a
real error, and would stop the bus from loading. It now means there is
nothing there. The only possible side effect is an mdio bus driver
might remain loaded without any devices if all reads return
ENODEV/EIO, were as before it would probably never load. 

	    Andrew

^ permalink raw reply

* Re: [PATCH net-next] qed: Fix copying 2 strings
From: David Miller @ 2018-04-24 18:00 UTC (permalink / raw)
  To: denis.bolotin; +Cc: netdev, ariel.elior
In-Reply-To: <20180424123253.2333-1-denis.bolotin@cavium.com>

From: Denis Bolotin <denis.bolotin@cavium.com>
Date: Tue, 24 Apr 2018 15:32:53 +0300

> The strscpy() was a recent fix (net: qed: use correct strncpy() size) to
> prevent passing the length of the source buffer to strncpy() and guarantee
> null termination.
> It misses the goal of overwriting only the first 3 characters in
> "???_BIG_RAM" and "???_RAM" while keeping the rest of the string.
> Use strncpy() with the length of 3, without null termination.
> 
> Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
> Signed-off-by: Ariel Elior <ariel.elior@cavium.com>

Applied, thank you.

^ permalink raw reply

* [net-next v2] ipv6: sr: Compute flowlabel for outer IPv6 header of seg6 encap mode
From: Ahmed Abdelsalam @ 2018-04-24 17:59 UTC (permalink / raw)
  To: davem, dav.lebrun, kuznet, yoshfuji, netdev, linux-kernel
  Cc: Ahmed Abdelsalam

ECMP (equal-cost multipath) hashes are typically computed on the packets'
5-tuple(src IP, dst IP, src port, dst port, L4 proto).

For encapsulated packets, the L4 data is not readily available and ECMP
hashing will often revert to (src IP, dst IP). This will lead to traffic
polarization on a single ECMP path, causing congestion and waste of network
capacity.

In IPv6, the 20-bit flow label field is also used as part of the ECMP
hash. In the lack of L4 data, the hashing will be on (src IP, dst IP,
flow label). Having a non-zero flow label is thus important for proper
traffic load balancing when L4 data is unavailable (i.e., when packets
are encapsulated).

Currently, the seg6_do_srh_encap() function extracts the original packet's
flow label and set it as the outer IPv6 flow label. There are two issues
with this behaviour:

a) There is no guarantee that the inner flow label is set by the source.

b) If the original packet is not IPv6, the flow label will be set to
zero (e.g., IPv4 or L2 encap).

This patch adds a function, named seg6_make_flowlabel(), that computes a
flow label from a given skb. It supports IPv6, IPv4 and L2 payloads, and
leverages the per namespace 'seg6_flowlabel" sysctl value.

The currently support behaviours are as follows:
-1 set flowlabel to zero.
 0 copy flowlabel from Inner paceket in case of Inner IPv6
   (Set flowlabel to 0 in case IPv4/L2)
 1 Compute the flowlabel using seg6_make_flowlabel()

This patch has been tested for IPv6, IPv4, and L2 traffic.

Signed-off-by: Ahmed Abdelsalam <amsalam20@gmail.com>
---
 include/net/netns/ipv6.h   |  1 +
 net/ipv6/seg6_iptunnel.c   | 24 ++++++++++++++++++++++--
 net/ipv6/sysctl_net_ipv6.c |  8 ++++++++
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index 97b3a54..c978a31 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -43,6 +43,7 @@ struct netns_sysctl_ipv6 {
 	int max_hbh_opts_cnt;
 	int max_dst_opts_len;
 	int max_hbh_opts_len;
+	int seg6_flowlabel;
 };
 
 struct netns_ipv6 {
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index 5fe1394..3d9cd86 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -91,6 +91,24 @@ static void set_tun_src(struct net *net, struct net_device *dev,
 	rcu_read_unlock();
 }
 
+/* Compute flowlabel for outer IPv6 header */
+__be32 seg6_make_flowlabel(struct net *net, struct sk_buff *skb,
+			   struct ipv6hdr *inner_hdr)
+{
+	int do_flowlabel = net->ipv6.sysctl.seg6_flowlabel;
+	__be32 flowlabel = 0;
+	u32 hash;
+
+	if (do_flowlabel > 0) {
+		hash = skb_get_hash(skb);
+		rol32(hash, 16);
+		flowlabel = (__force __be32)hash & IPV6_FLOWLABEL_MASK;
+	} else if (!do_flowlabel && skb->protocol == htons(ETH_P_IPV6)) {
+		flowlabel = ip6_flowlabel(inner_hdr);
+	}
+	return flowlabel;
+}
+
 /* encapsulate an IPv6 packet within an outer IPv6 header with a given SRH */
 int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto)
 {
@@ -99,6 +117,7 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto)
 	struct ipv6hdr *hdr, *inner_hdr;
 	struct ipv6_sr_hdr *isrh;
 	int hdrlen, tot_len, err;
+	__be32 flowlabel;
 
 	hdrlen = (osrh->hdrlen + 1) << 3;
 	tot_len = hdrlen + sizeof(*hdr);
@@ -119,12 +138,13 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto)
 	 * decapsulation will overwrite inner hlim with outer hlim
 	 */
 
+	flowlabel = seg6_make_flowlabel(net, skb, inner_hdr);
 	if (skb->protocol == htons(ETH_P_IPV6)) {
 		ip6_flow_hdr(hdr, ip6_tclass(ip6_flowinfo(inner_hdr)),
-			     ip6_flowlabel(inner_hdr));
+			     flowlabel);
 		hdr->hop_limit = inner_hdr->hop_limit;
 	} else {
-		ip6_flow_hdr(hdr, 0, 0);
+		ip6_flow_hdr(hdr, 0, flowlabel);
 		hdr->hop_limit = ip6_dst_hoplimit(skb_dst(skb));
 	}
 
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 6fbdef6..e15cd37 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -152,6 +152,13 @@ static struct ctl_table ipv6_table_template[] = {
 		.extra1		= &zero,
 		.extra2		= &one,
 	},
+	{
+		.procname	= "seg6_flowlabel",
+		.data		= &init_net.ipv6.sysctl.seg6_flowlabel,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec
+	},
 	{ }
 };
 
@@ -217,6 +224,7 @@ static int __net_init ipv6_sysctl_net_init(struct net *net)
 	ipv6_table[12].data = &net->ipv6.sysctl.max_dst_opts_len;
 	ipv6_table[13].data = &net->ipv6.sysctl.max_hbh_opts_len;
 	ipv6_table[14].data = &net->ipv6.sysctl.multipath_hash_policy,
+	ipv6_table[15].data = &net->ipv6.sysctl.seg6_flowlabel;
 
 	ipv6_route_table = ipv6_route_sysctl_init(net);
 	if (!ipv6_route_table)
-- 
2.1.4

^ permalink raw reply related

* Re: [PATCH 2/3] net/unix: hook unix_socketpair() into LSM
From: Paul Moore @ 2018-04-24 17:58 UTC (permalink / raw)
  To: David Miller
  Cc: dh.herrmann, linux-kernel, James Morris, teg, Stephen Smalley,
	selinux, linux-security-module, Eric Paris, serge, netdev
In-Reply-To: <20180424.135651.492329246141701047.davem@davemloft.net>

On Tue, Apr 24, 2018 at 1:56 PM, David Miller <davem@davemloft.net> wrote:
> From: Paul Moore <paul@paul-moore.com>
> Date: Tue, 24 Apr 2018 13:55:31 -0400
>
>> On Mon, Apr 23, 2018 at 9:30 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> Use the newly created LSM-hook for unix_socketpair(). The default hook
>>> return-value is 0, so behavior stays the same unless LSMs start using
>>> this hook.
>>>
>>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>>> ---
>>>  net/unix/af_unix.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>>> index 68bb70a62afe..bc9705ace9b1 100644
>>> --- a/net/unix/af_unix.c
>>> +++ b/net/unix/af_unix.c
>>> @@ -1371,6 +1371,11 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr,
>>>  static int unix_socketpair(struct socket *socka, struct socket *sockb)
>>>  {
>>>         struct sock *ska = socka->sk, *skb = sockb->sk;
>>> +       int err;
>>> +
>>> +       err = security_unix_stream_socketpair(ska, skb);
>>> +       if (err)
>>> +               return err;
>>
>> I recognize that AF_UNIX is really the only protocol that supports
>> socketpair(2) at the moment, but I like to avoid protocol specific LSM
>> hooks whenever possible.  Unless someone can think of a good
>> objection, I would prefer to see the hook placed in __sys_socketpair()
>> instead (and obviously drop the "unix_stream" portion from the hook
>> name).
>
> The counterargument is that after 30 years no other protocol has grown
> usage of this operation. :-)

Call me a an optimist ;)

-- 
paul moore
www.paul-moore.com

^ permalink raw reply

* Re: [PATCH 2/3] net/unix: hook unix_socketpair() into LSM
From: David Miller @ 2018-04-24 17:56 UTC (permalink / raw)
  To: paul
  Cc: dh.herrmann, linux-kernel, jmorris, teg, sds, selinux,
	linux-security-module, eparis, serge, netdev
In-Reply-To: <CAHC9VhSv6tacFb+nEs1cCUOj52Vu+wXD6ZPZ1r1W4pYXo0VJMQ@mail.gmail.com>

From: Paul Moore <paul@paul-moore.com>
Date: Tue, 24 Apr 2018 13:55:31 -0400

> On Mon, Apr 23, 2018 at 9:30 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Use the newly created LSM-hook for unix_socketpair(). The default hook
>> return-value is 0, so behavior stays the same unless LSMs start using
>> this hook.
>>
>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>> ---
>>  net/unix/af_unix.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 68bb70a62afe..bc9705ace9b1 100644
>> --- a/net/unix/af_unix.c
>> +++ b/net/unix/af_unix.c
>> @@ -1371,6 +1371,11 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr,
>>  static int unix_socketpair(struct socket *socka, struct socket *sockb)
>>  {
>>         struct sock *ska = socka->sk, *skb = sockb->sk;
>> +       int err;
>> +
>> +       err = security_unix_stream_socketpair(ska, skb);
>> +       if (err)
>> +               return err;
> 
> I recognize that AF_UNIX is really the only protocol that supports
> socketpair(2) at the moment, but I like to avoid protocol specific LSM
> hooks whenever possible.  Unless someone can think of a good
> objection, I would prefer to see the hook placed in __sys_socketpair()
> instead (and obviously drop the "unix_stream" portion from the hook
> name).

The counterargument is that after 30 years no other protocol has grown
usage of this operation. :-)

^ permalink raw reply

* Re: [PATCH 2/3] net/unix: hook unix_socketpair() into LSM
From: Paul Moore @ 2018-04-24 17:55 UTC (permalink / raw)
  To: David Herrmann
  Cc: linux-kernel, James Morris, teg, Stephen Smalley, selinux,
	linux-security-module, Eric Paris, serge, davem, netdev
In-Reply-To: <20180423133015.5455-3-dh.herrmann@gmail.com>

On Mon, Apr 23, 2018 at 9:30 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Use the newly created LSM-hook for unix_socketpair(). The default hook
> return-value is 0, so behavior stays the same unless LSMs start using
> this hook.
>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> ---
>  net/unix/af_unix.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 68bb70a62afe..bc9705ace9b1 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -1371,6 +1371,11 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr,
>  static int unix_socketpair(struct socket *socka, struct socket *sockb)
>  {
>         struct sock *ska = socka->sk, *skb = sockb->sk;
> +       int err;
> +
> +       err = security_unix_stream_socketpair(ska, skb);
> +       if (err)
> +               return err;

I recognize that AF_UNIX is really the only protocol that supports
socketpair(2) at the moment, but I like to avoid protocol specific LSM
hooks whenever possible.  Unless someone can think of a good
objection, I would prefer to see the hook placed in __sys_socketpair()
instead (and obviously drop the "unix_stream" portion from the hook
name).

>         /* Join our sockets back to back */
>         sock_hold(ska);
> --
> 2.17.0

-- 
paul moore
www.paul-moore.com

^ permalink raw reply

* Re: [PATCH] net: phy: TLK10X initial driver submission
From: Andrew Lunn @ 2018-04-24 17:52 UTC (permalink / raw)
  To: Rob Herring
  Cc: Måns Andersson, Mark Rutland, Florian Fainelli, netdev,
	devicetree, linux-kernel
In-Reply-To: <20180424163455.vmftcg5xbj6svtcu@rob-hp-laptop>

> > +Required properties:
> > +	- reg - The ID number for the phy, usually a small integer
> 
> Isn't this the MDIO bus address?

Hi Rob

Yes. This text has been take direct from the generic PHY binding.
 
> This should have a compatible string too.

Please see Documentation/devicetree/bindings/net/phy.txt

compatible strings are optional. We know what device it is from its ID
registers, which are in a well known location.

	Andrew

^ permalink raw reply

* Re: [PATCH v3 net] sfc: ARFS filter IDs
From: David Miller @ 2018-04-24 17:51 UTC (permalink / raw)
  To: ecree; +Cc: linux-net-drivers, netdev
In-Reply-To: <c3d6d078-2113-8b4c-4c8f-8e7126253092@solarflare.com>

From: Edward Cree <ecree@solarflare.com>
Date: Tue, 24 Apr 2018 17:09:30 +0100

> Associate an arbitrary ID with each ARFS filter, allowing to properly query
>  for expiry.  The association is maintained in a hash table, which is
>  protected by a spinlock.
> 
> v3: fix build warnings when CONFIG_RFS_ACCEL is disabled (thanks lkp-robot).
> v2: fixed uninitialised variable (thanks davem and lkp-robot).
> 
> Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations")
> Signed-off-by: Edward Cree <ecree@solarflare.com>

Applied, thanks Edward.

^ permalink raw reply

* [PATCH net-next v2] ipv6: addrconf: don't evaluate keep_addr_on_down twice
From: Ivan Vecera @ 2018-04-24 17:51 UTC (permalink / raw)
  To: netdev; +Cc: David Ahern

The addrconf_ifdown() evaluates keep_addr_on_down state twice. There
is no need to do it.

Cc: David Ahern <dsahern@gmail.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
 net/ipv6/addrconf.c | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 7b4d7bbf2c17..fbfd71a2d9c8 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3622,8 +3622,7 @@ static int addrconf_ifdown(struct net_device *dev, int how)
 	struct net *net = dev_net(dev);
 	struct inet6_dev *idev;
 	struct inet6_ifaddr *ifa, *tmp;
-	int _keep_addr;
-	bool keep_addr;
+	bool keep_addr = false;
 	int state, i;
 
 	ASSERT_RTNL();
@@ -3649,15 +3648,18 @@ static int addrconf_ifdown(struct net_device *dev, int how)
 
 	}
 
-	/* aggregate the system setting and interface setting */
-	_keep_addr = net->ipv6.devconf_all->keep_addr_on_down;
-	if (!_keep_addr)
-		_keep_addr = idev->cnf.keep_addr_on_down;
-
 	/* combine the user config with event to determine if permanent
 	 * addresses are to be removed from address hash table
 	 */
-	keep_addr = !(how || _keep_addr <= 0 || idev->cnf.disable_ipv6);
+	if (!how && !idev->cnf.disable_ipv6) {
+		/* aggregate the system setting and interface setting */
+		int _keep_addr = net->ipv6.devconf_all->keep_addr_on_down;
+
+		if (!_keep_addr)
+			_keep_addr = idev->cnf.keep_addr_on_down;
+
+		keep_addr = (_keep_addr > 0);
+	}
 
 	/* Step 2: clear hash table */
 	for (i = 0; i < IN6_ADDR_HSIZE; i++) {
@@ -3707,11 +3709,6 @@ static int addrconf_ifdown(struct net_device *dev, int how)
 		write_lock_bh(&idev->lock);
 	}
 
-	/* re-combine the user config with event to determine if permanent
-	 * addresses are to be removed from the interface list
-	 */
-	keep_addr = (!how && _keep_addr > 0 && !idev->cnf.disable_ipv6);
-
 	list_for_each_entry_safe(ifa, tmp, &idev->addr_list, if_list) {
 		struct fib6_info *rt = NULL;
 		bool keep;
-- 
2.16.1

^ permalink raw reply related

* Re: [PATCH net-next] ipv6: addrconf: don't evaluate keep_addr_on_down twice
From: David Ahern @ 2018-04-24 17:44 UTC (permalink / raw)
  To: Ivan Vecera, netdev
In-Reply-To: <20180424073143.18511-1-cera@cera.cz>

On 4/24/18 1:31 AM, Ivan Vecera wrote:
> The addrconf_ifdown() evaluates keep_addr_on_down state twice. There
> is no need to do it.
> 
> Cc: David Ahern <dsahern@gmail.com>
> Signed-off-by: Ivan Vecera <cera@cera.cz>
> ---
>  net/ipv6/addrconf.c | 23 ++++++++++-------------
>  1 file changed, 10 insertions(+), 13 deletions(-)

Looks right to me.

Acked-by: David Ahern <dsahern@gmail.com>

But  ...

> @@ -3697,11 +3699,6 @@ static int addrconf_ifdown(struct net_device *dev, int how)
>  		write_lock_bh(&idev->lock);
>  	}
>  
> -	/* re-combine the user config with event to determine if permanent
> -	 * addresses are to be removed from the interface list
> -	 */
> -	keep_addr = (!how && _keep_addr > 0 && !idev->cnf.disable_ipv6);
> -
>  	list_for_each_entry_safe(ifa, tmp, &idev->addr_list, if_list) {
>  		struct rt6_info *rt = NULL;
>  		bool keep;
> 

you need to rebase to top of tree. That is 'struct fib6_info *rt' now so
the patch does not apply cleanly using git am.

^ permalink raw reply

* Re: [PATCH net-next v2 0/2] openvswitch: Support conntrack zone limit
From: David Miller @ 2018-04-24 17:42 UTC (permalink / raw)
  To: pshelar; +Cc: yihung.wei, netdev, fw
In-Reply-To: <CAOrHB_BSHqsmuYgLOHDTxMSH6=6w+uZ9N0SYy26FpoLj88w0Qg@mail.gmail.com>

From: Pravin Shelar <pshelar@ovn.org>
Date: Mon, 23 Apr 2018 23:34:48 -0700

> OK. Thanks for the info.

So, ACK, Reviewed-by, etc.? :-)

^ permalink raw reply

* Re: [PATCH v2 0/8] ipconfig: NTP server support, bug fixes, documentation improvements
From: David Miller @ 2018-04-24 17:40 UTC (permalink / raw)
  To: chris; +Cc: netdev
In-Reply-To: <20180424025639.2228-1-chris@chrisn.me.uk>

From: Chris Novakovic <chris@chrisn.me.uk>
Date: Tue, 24 Apr 2018 03:56:31 +0100

> This series (against net-next) makes various improvements to ipconfig:
> 
>  - Patch #1 correctly documents the behaviour of parameter 4 in the
>    "ip=" and "nfsaddrs=" command line parameter.
>  - Patch #2 tidies up the printk()s for reporting configured name
>    servers.
>  - Patch #3 fixes a bug in autoconfiguration via BOOTP whereby the IP
>    addresses of IEN-116 name servers are requested from the BOOTP
>    server, rather than those of DNS name servers.
>  - Patch #4 requests the number of DNS servers specified by
>    CONF_NAMESERVERS_MAX when autoconfiguring via BOOTP, rather than
>    hardcoding it to 2.
>  - Patch #5 fully documents the contents and format of /proc/net/pnp in
>    Documentation/filesystems/nfs/nfsroot.txt.
>  - Patch #6 fixes a bug whereby bogus information is written to
>    /proc/net/pnp when ipconfig is not used.
>  - Patch #7 creates a new procfs directory for ipconfig-related
>    configuration reports at /proc/net/ipconfig.
>  - Patch #8 allows for NTP servers to be configured (manually on the
>    kernel command line or automatically via DHCP), enabling systems with
>    an NFS root filesystem to synchronise their clock before mounting
>    their root filesystem. NTP server IP addresses are written to
>    /proc/net/ipconfig/ntp_servers.
> 
> Changes from v1:
> 
>  - David requested that a new directory /proc/net/ipconfig be created to
>    contain ipconfig-related configuration reports, which is implemented
>    in the new patch #7. NTP server IPs are now written to this directory
>    instead of /proc/net/ntp in the new patch #8.
>  - Cong and David both requested that the modification to CREDITS be
>    dropped. This patch has been removed from the series.

Series applied, thank you.

^ permalink raw reply

* Re: [PATCH net v2] net: ethtool: Add missing kernel doc for FEC parameters
From: David Miller @ 2018-04-24 17:38 UTC (permalink / raw)
  To: f.fainelli; +Cc: netdev, vidya.chowdary, dustin, roopa
In-Reply-To: <20180423225138.8238-1-f.fainelli@gmail.com>

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 23 Apr 2018 15:51:38 -0700

> While adding support for ethtool::get_fecparam and set_fecparam, kernel
> doc for these functions was missed, add those.
> 
> Fixes: 1a5f3da20bd9 ("net: ethtool: add support for forward error correction modes")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes in v2:
> 
> - corrected set_fecparam in commit message

Applied, thanks Florian.

^ permalink raw reply

* Re: [PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
From: Michal Hocko @ 2018-04-24 17:38 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Matthew Wilcox, David Miller, Andrew Morton, linux-mm,
	eric.dumazet, edumazet, netdev, linux-kernel, mst, jasowang,
	virtualization, dm-devel, Vlastimil Babka
In-Reply-To: <alpine.LRH.2.02.1804241319390.28995@file01.intranet.prod.int.rdu2.redhat.com>

On Tue 24-04-18 13:28:49, Mikulas Patocka wrote:
> 
> 
> On Tue, 24 Apr 2018, Michal Hocko wrote:
> 
> > On Tue 24-04-18 13:00:11, Mikulas Patocka wrote:
> > > 
> > > 
> > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > > 
> > > > On Tue 24-04-18 11:50:30, Mikulas Patocka wrote:
> > > > > 
> > > > > 
> > > > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > > > > 
> > > > > > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote:
> > > > > > [...]
> > > > > > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f
> > > > > > >  	 */
> > > > > > >  	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
> > > > > > >  
> > > > > > > +#ifdef CONFIG_DEBUG_SG
> > > > > > > +	/* Catch bugs when the caller uses DMA API on the result of kvmalloc. */
> > > > > > > +	if (!(prandom_u32_max(2) & 1))
> > > > > > > +		goto do_vmalloc;
> > > > > > > +#endif
> > > > > > 
> > > > > > I really do not think there is anything DEBUG_SG specific here. Why you
> > > > > > simply do not follow should_failslab path or even reuse the function?
> > > > > 
> > > > > CONFIG_DEBUG_SG is enabled by default in RHEL and Fedora debug kernel (if 
> > > > > you don't like CONFIG_DEBUG_SG, pick any other option that is enabled 
> > > > > there).
> > > > 
> > > > Are you telling me that you are shaping a debugging functionality basing
> > > > on what RHEL has enabled? And you call me evil. This is just rediculous.
> > > > 
> > > > > Fail-injection framework is if off by default and it must be explicitly 
> > > > > enabled and configured by the user - and most users won't enable it.
> > > > 
> > > > It can be enabled easily. And if you care enough for your debugging
> > > > kernel then just make it enabled unconditionally.
> > > 
> > > So, should we add a new option CONFIG_KVMALLOC_FALLBACK_DEFAULT? I'm not 
> > > quite sure if 3 lines of debugging code need an extra option, but if you 
> > > don't want to reuse any existing debug option, it may be possible. Adding 
> > > it to the RHEL debug kernel would be trivial.
> > 
> > Wouldn't it be equally trivial to simply enable the fault injection? You
> > would get additional failure paths testing as a bonus.
> 
> The RHEL and Fedora debugging kernels are compiled with fault injection. 
> But the fault-injection framework will do nothing unless it is enabled by 
> a kernel parameter or debugfs write.
> 
> Most users don't know about the fault injection kernel parameters or 
> debugfs files and won't enabled it. We need a CONFIG_ option to enable it 
> by default in the debugging kernels (and we could add a kernel parameter 
> to override the default, fine-tune the fallback probability etc.)

If it is a real issue to install the debugging kernel with the required
kernel parameter then I a config option for the default on makes sense
to me.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply

* Re: [PATCH 0/4] A few rhashtables cleanups
From: David Miller @ 2018-04-24 17:38 UTC (permalink / raw)
  To: neilb; +Cc: tgraf, herbert, netdev, linux-kernel
In-Reply-To: <152452244405.1456.8175298512483573078.stgit@noble>

From: NeilBrown <neilb@suse.com>
Date: Tue, 24 Apr 2018 08:29:13 +1000

> 2 patches fixes documentation
> 1 fixes a bit in rhashtable_walk_start()
> 1 improves rhashtable_walk stability.
> 
> All reviewed and Acked.

Series applied to net-next, thanks Neil.

^ permalink raw reply

* Re: [PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
From: Mikulas Patocka @ 2018-04-24 17:28 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Matthew Wilcox, David Miller, Andrew Morton, linux-mm,
	eric.dumazet, edumazet, netdev, linux-kernel, mst, jasowang,
	virtualization, dm-devel, Vlastimil Babka
In-Reply-To: <20180424170349.GQ17484@dhcp22.suse.cz>



On Tue, 24 Apr 2018, Michal Hocko wrote:

> On Tue 24-04-18 13:00:11, Mikulas Patocka wrote:
> > 
> > 
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > 
> > > On Tue 24-04-18 11:50:30, Mikulas Patocka wrote:
> > > > 
> > > > 
> > > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > > > 
> > > > > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote:
> > > > > [...]
> > > > > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f
> > > > > >  	 */
> > > > > >  	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
> > > > > >  
> > > > > > +#ifdef CONFIG_DEBUG_SG
> > > > > > +	/* Catch bugs when the caller uses DMA API on the result of kvmalloc. */
> > > > > > +	if (!(prandom_u32_max(2) & 1))
> > > > > > +		goto do_vmalloc;
> > > > > > +#endif
> > > > > 
> > > > > I really do not think there is anything DEBUG_SG specific here. Why you
> > > > > simply do not follow should_failslab path or even reuse the function?
> > > > 
> > > > CONFIG_DEBUG_SG is enabled by default in RHEL and Fedora debug kernel (if 
> > > > you don't like CONFIG_DEBUG_SG, pick any other option that is enabled 
> > > > there).
> > > 
> > > Are you telling me that you are shaping a debugging functionality basing
> > > on what RHEL has enabled? And you call me evil. This is just rediculous.
> > > 
> > > > Fail-injection framework is if off by default and it must be explicitly 
> > > > enabled and configured by the user - and most users won't enable it.
> > > 
> > > It can be enabled easily. And if you care enough for your debugging
> > > kernel then just make it enabled unconditionally.
> > 
> > So, should we add a new option CONFIG_KVMALLOC_FALLBACK_DEFAULT? I'm not 
> > quite sure if 3 lines of debugging code need an extra option, but if you 
> > don't want to reuse any existing debug option, it may be possible. Adding 
> > it to the RHEL debug kernel would be trivial.
> 
> Wouldn't it be equally trivial to simply enable the fault injection? You
> would get additional failure paths testing as a bonus.

The RHEL and Fedora debugging kernels are compiled with fault injection. 
But the fault-injection framework will do nothing unless it is enabled by 
a kernel parameter or debugfs write.

Most users don't know about the fault injection kernel parameters or 
debugfs files and won't enabled it. We need a CONFIG_ option to enable it 
by default in the debugging kernels (and we could add a kernel parameter 
to override the default, fine-tune the fallback probability etc.)

Mikulas

^ permalink raw reply

* Re: mt7601u: phy: mark expected switch fall-through
From: Kalle Valo @ 2018-04-24 17:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Jakub Kicinski, linux-wireless, netdev, linux-kernel,
	Gustavo A. R. Silva
In-Reply-To: <20180330211223.GA22497@embeddedgus>

"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:

> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Acked-by: Jakub Kicinski <kubakici@wp.pl>

Patch applied to wireless-drivers-next.git, thanks.

5156b054bcda mt7601u: phy: mark expected switch fall-through

-- 
https://patchwork.kernel.org/patch/10318419/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox