Re: [PATCH net 0/4] macvlan: Fix some issues with changing mac addresses

On 6/16/17 6:36 AM, Vladislav Yasevich wrote: There are some issues in macvlan wrt to changing it's mac address. * An error is returned in the specified address is the same as an already assigned address. * In passthru mode, the mac address of the macvlan device doesn't change. * After

Re: [PATCH net 4/4] macvlan: Let passthru macvlan correctly restore lower mac address

Sorry, it took sometime to wrap around this patch series since they all change one file and at times the same function :). On 6/16/17 6:36 AM, Vladislav Yasevich wrote: Passthru macvlans directly change the mac address of the lower level device. That's OK, but after the macvlan is deleted,

[PATCH v3] ip6_tunnel: Correct tos value in collect_md mode

Same as ip_gre, geneve and vxlan, use key->tos as traffic class value. CC: Peter Dawson Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets”) Signed-off-by: Haishuang Yan --- Changes since v3: * Add

[PATCH v2 2/2] ip6_tunnel: fix ip6 tunnel lookup in collect_md mode

In collect_md mode, if the tun dev is down, it still can call __ip6_tnl_rcv to receive on packets, and the rx statistics increase improperly. Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels") Cc: Alexei Starovoitov Signed-off-by: Haishuang Yan

[PATCH v2 1/2] ip_tunnel: fix ip tunnel lookup in collect_md mode

In collect_md mode, if the tun dev is down, it still can call ip_tunnel_rcv to receive on packets, and the rx statistics increase improperly. Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.") Cc: Pravin B Shelar Signed-off-by: Haishuang Yan

Re: [PATCH v2] ip6_tunnel: Correct tos value in collect_md mode

> On 16 Jun 2017, at 10:44 PM, Daniel Borkmann wrote: > > On 06/15/2017 05:54 AM, Peter Dawson wrote: >> On Thu, 15 Jun 2017 10:30:29 +0800 >> Haishuang Yan wrote: >> >>> Same as ip_gre, geneve and vxlan, use key->tos as tos value. >>>

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

On 06/16/17 01:58 PM, Stephen Hemminger wrote: > On Wed, 14 Jun 2017 11:37:39 -0700 > Dave Watson wrote: > > > --- /dev/null > > +++ b/net/tls/Kconfig > > @@ -0,0 +1,12 @@ > > +# > > +# TLS configuration > > +# > > +config TLS > > + tristate "Transport Layer Security

Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure

Hello, On 14/06/17 - 11:37:14, Dave Watson wrote: > Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP > sockets. Based on a similar infrastructure in tcp_cong. The idea is that any > ULP can add its own logic by changing the TCP proto_ops structure to its own > methods.

[RFC net-next 3/8] nfp: xdp: move driver XDP setup into a separate function

In preparation of XDP offload flags move the driver setup into a function. Otherwise the number of conditions in one function would make it slightly hard to follow. The offload handler may now be called with NULL prog, even if no offload is currently active, but that's fine, offload code can

[RFC net-next 5/8] nfp: bpf: take a reference on offloaded programs

The xdp_prog member of the adapter's data path structure is used for XDP in driver mode. In case a XDP program is loaded with in HW-only mode, we need to store it somewhere else. Add a new XDP prog pointer in the main structure and use that when we need to know whether any XDP program is loaded,

[RFC net-next 4/8] nfp: bpf: don't offload XDP programs in DRV_MODE

DRV_MODE means that user space wants the program to be run in the driver. Do not try to offload. Only offload if no mode flags have been specified. Remember what the mode is when the program is installed and refuse new setup requests if there is already a program loaded in a different mode.

[RFC net-next 2/8] xdp: add HW offload mode flag for installing programs

Add an installation-time flag for requesting that the program be installed only if it can be offloaded to HW. Internally new command for ndo_xdp is added, this way we avoid putting checks into drivers since they all return -EINVAL on an unknown command. Signed-off-by: Jakub Kicinski

[RFC net-next 8/8] nfp: xdp: report if program is offloaded

Make use of just added XDP_ATTACHED_HW. Signed-off-by: Jakub Kicinski --- drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c

[RFC net-next 7/8] xdp: add reporting of offload mode

Extend the XDP_ATTACHED_* values to include offloaded mode. Let drivers report whether program is installed in the driver or the HW by changing the prog_attached field from bool to u8 (type of the netlink attribute). Exploit the fact that the value of XDP_ATTACHED_DRV is 1, therefore since all

[RFC net-next 0/8] xdp: offload mode

Hi! This set adds XDP flag for forcing offload and a attachement mode for reporting to user space that program has been offloaded. The nfp driver is modified to make use of the new flags, but also to adhere to the DRV_MODE flag which should disable the HW offload. Note that the NFP driver

[RFC net-next 1/8] xdp: pass XDP flags into install handlers

Pass XDP flags to the xdp ndo. This will allow drivers to look at the mode flags and make decisions about offload. Signed-off-by: Jakub Kicinski --- include/linux/netdevice.h | 1 + net/core/dev.c| 5 +++-- 2 files changed, 4 insertions(+), 2

[RFC net-next 6/8] nfp: bpf: add support for XDP_FLAGS_HW_MODE

Respect the XDP_FLAGS_HW_MODE. When it's set install the program on the NIC and skip enabling XDP in the driver. Signed-off-by: Jakub Kicinski --- drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-)

[PATCH net-next] net: dsa: Fix legacy probing

After commit 6d3c8c0dd88a ("net: dsa: Remove master_netdev and use dst->cpu_dp->netdev") and a29342e73911 ("net: dsa: Associate slave network device with CPU port") we would be seeing NULL pointer dereferences when accessing dst->cpu_dp->netdev too early. In the legacy code, we actually know early

Re: [RFC PATCH net-next v2 01/15] bpf: BPF support for socket ops

On 6/16/17, 5:07 AM, "Daniel Borkmann" wrote: On 06/15/2017 10:08 PM, Lawrence Brakmo wrote: > Created a new BPF program type, BPF_PROG_TYPE_SOCKET_OPS, and a corresponding > struct that allows BPF programs of this type to access some of the > socket's

[PATCH net] igb: protect TX timestamping from API misuse

HW timestamping can only be requested for a packet if the NIC is first setup via ioctl(SIOCSHWTSTAMP). If this step was skipped, then the igb driver still allowed TX packets to request HW timestamping. In this situation, the _IGB_PTP_TX_IN_PROGRESS flag was set and would never clear. This

[PATCH net-next 1/1] selftests: Introduce tc testsuite

Add the beginnings of a testsuite for tc functionality in the kernel. These are a series of unit tests that use the tc executable and verify the success of those commands by checking both the exit codes and the output from tc's 'show' operation. To run the tests: # cd

[PATCH net-next 0/1] Introduction of the tc tests

Apologies for sending this as one big patch. I've been sitting on this a little too long, but it's ready and I wanted to get it out. There are a limited number of tests to start - I plan to add more on a regular basis. Lucas Bates (1): selftests: Introduce tc testsuite

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

On Fri, Jun 16, 2017 at 1:56 PM, Arnd Bergmann wrote: > On Fri, Jun 16, 2017 at 7:29 PM, Dmitry Torokhov > wrote: >> On Fri, Jun 16, 2017 at 8:58 AM, Samuel Thibault >> wrote: >>> I'm however afraid we'd have to mark a lot

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

On Wed, 14 Jun 2017 11:37:39 -0700 Dave Watson wrote: > --- /dev/null > +++ b/net/tls/Kconfig > @@ -0,0 +1,12 @@ > +# > +# TLS configuration > +# > +config TLS > + tristate "Transport Layer Security support" > + depends on NET > + default m > + ---help--- > +

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

On Fri, Jun 16, 2017 at 7:29 PM, Dmitry Torokhov wrote: > On Fri, Jun 16, 2017 at 8:58 AM, Samuel Thibault > wrote: >> Arnd Bergmann, on ven. 16 juin 2017 17:41:47 +0200, wrote: >>> The problem are the 'ch' and 'flag' variables that are

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

On Wed, 14 Jun 2017 11:37:39 -0700 Dave Watson wrote: > + > +static inline struct tls_context *tls_get_ctx(const struct sock *sk) > +{ > + struct inet_connection_sock *icsk = inet_csk(sk); > + > + return icsk->icsk_ulp_data; > +} > + > +static inline struct

Re: [PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

On Fri, Jun 16, 2017 at 11:10 AM, Christoph Hellwig wrote: > DMA_ERROR_CODE is not a public API and will go away. Instead properly > unwind based on the loop counter. > > Signed-off-by: Christoph Hellwig > Acked-by: Dave Jiang > Acked-By: Vinod

Re: [PATCH] rtlwifi: rtl8821ae: remove unused variable

On 06/13/2017 03:42 PM, Gustavo A. R. Silva wrote: Remove unused variable rtlhal. Addresses-Coverity-ID: 1248810 Signed-off-by: Gustavo A. R. Silva --- NACK!! That variable is used in file core.c in driver rtlwifi, which is loaded and used by rtl8821ae. Please do

[PATCH] net: introduce SO_PEERGROUPS getsockopt

This adds the new getsockopt(2) option SO_PEERGROUPS on SOL_SOCKET to retrieve the auxiliary groups of the remote peer. It is designed to naturally extend SO_PEERCRED. That is, the underlying data is from the same credentials. Regarding its syntax, it is based on SO_PEERSEC. That is, if the

Re: [PATCH 0/2] Replace driver's usage of hard-coded device IDs to #defines

On Fri, Jun 16, 2017 at 2:08 PM, Bjorn Helgaas wrote: > On Thu, May 25, 2017 at 09:56:55AM -0600, Myron Stowe wrote: >> On Wed, 24 May 2017 20:02:49 -0400 (EDT) >> David Miller wrote: >> >> > From: Myron Stowe >> > Date: Wed, 24

Re: [PATCH 0/2] Replace driver's usage of hard-coded device IDs to #defines

On Thu, May 25, 2017 at 09:56:55AM -0600, Myron Stowe wrote: > On Wed, 24 May 2017 20:02:49 -0400 (EDT) > David Miller wrote: > > > From: Myron Stowe > > Date: Wed, 24 May 2017 16:47:34 -0600 > > > > > Noa Osherovich introduced a series of new

Re: [PATCH 0/5] skb data accessors cleanup

From: Joe Perches Date: Fri, 16 Jun 2017 12:43:23 -0700 > On Fri, 2017-06-16 at 11:50 -0400, David Miller wrote: >> From: Johannes Berg >> Date: Fri, 16 Jun 2017 09:07:42 +0200 >> >> > Over night, Fengguang's bot told me that it compiled all of its

Re: [PATCH 0/5] skb data accessors cleanup

On Fri, 2017-06-16 at 11:50 -0400, David Miller wrote: > From: Johannes Berg > Date: Fri, 16 Jun 2017 09:07:42 +0200 > > > Over night, Fengguang's bot told me that it compiled all of its many > > various configurations successfully, and I had done allyesconfig on > >

Re: [PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

On 06/15/2017 06:00 AM, Nikolay Aleksandrov wrote: > On 15/06/17 14:44, Nikolay Aleksandrov wrote: >> On 15/06/17 14:33, Nikolay Aleksandrov wrote: >>> On 15/06/17 00:51, Julien Gomes wrote: Hi Nikolay, On 06/14/2017 05:04 AM, Nikolay Aleksandrov wrote: > This has been on

Re: [pull request][net-next 00/15] Mellanox mlx5 updates and cleanups 2017-06-16

From: Saeed Mahameed Date: Fri, 16 Jun 2017 00:42:37 +0300 > This series provides updates and cleanups to mlx5 driver. > > For more details please see tag log below. > > Please pull and let me know if there's any problem. > *This series doesn't introduce any conflict with

Re: [PATCH net-next] net: dsa: add cross-chip multicast support

From: Vivien Didelot Date: Thu, 15 Jun 2017 16:14:48 -0400 > Similarly to how cross-chip VLAN works, define a bitmap of multicast > group members for a switch, now including its DSA ports, so that > multicast traffic can be sent to all switches of the fabric.

Re: [PATCH] ibmvnic: driver initialization for kdump/kexec

From: Nathan Fontenot Date: Thu, 15 Jun 2017 14:48:09 -0400 > When booting into the kdump/kexec kernel, pHyp and vios > are not prepared for the initialization crq request and > a failover transport event is generated. This is not > handled correctly. > > At this point

Re: [PATCH v2 0/6] skb data accessor cleanups

On Fri, 2017-06-16 at 14:29 +0200, Johannes Berg wrote: > Changes from v1: > * add skb_put_u8() as suggested by Joe and Bjørn > > Again build-tested by myself and kbuild bot. Now that I think about it, I did something similar in 2015 https://www.spinics.net/lists/netdev/msg327404.html At that

Re: [PATCH net-next 00/21] remove dst garbage collector logic

From: Wei Wang Date: Fri, 16 Jun 2017 10:47:23 -0700 > From: Wei Wang > > The current mechanism of dst release is a bit complicated. It is because > the users of dst get divided into 2 situations: > 1. Most users take the reference count when using a

Re: [PATCH net-next 02/21] udp: call dst_hold_safe() in udp_sk_rx_set_dst()

On Fri, Jun 16, 2017 at 12:02 PM, David Miller wrote: > From: Wei Wang > Date: Fri, 16 Jun 2017 10:47:25 -0700 > >> + if (dst) >> + /* set noref for now. >> + * any place which wants to hold dst has to call >> +

Re: [PATCH net-next 02/21] udp: call dst_hold_safe() in udp_sk_rx_set_dst()

From: Wei Wang Date: Fri, 16 Jun 2017 10:47:25 -0700 > + if (dst) > + /* set noref for now. > + * any place which wants to hold dst has to call > + * dst_hold_safe() > + */ > + skb_dst_set_noref(skb, dst);

Re: [PATCH net] decnet: always not take dst->__refcnt when inserting dst into hash table

From: Wei Wang Date: Fri, 16 Jun 2017 10:46:37 -0700 > From: Wei Wang > > In the existing dn_route.c code, dn_route_output_slow() takes > dst->__refcnt before calling dn_insert_route() while dn_route_input_slow() > does not take dst->__refcnt before

[PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

DMA_ERROR_CODE is not a public API and will go away. Instead properly unwind based on the loop counter. Signed-off-by: Christoph Hellwig Acked-by: Dave Jiang Acked-By: Vinod Koul --- drivers/dma/ioat/init.c | 24

[PATCH 05/44] drm/armada: don't abuse DMA_ERROR_CODE

dev_addr isn't even a dma_addr_t, and DMA_ERROR_CODE has never been a valid driver API. Add a bool mapped flag instead. Signed-off-by: Christoph Hellwig --- drivers/gpu/drm/armada/armada_fb.c | 2 +- drivers/gpu/drm/armada/armada_gem.c | 5 ++---

[PATCH 04/44] drm/exynos: don't use DMA_ERROR_CODE

DMA_ERROR_CODE already isn't a valid API to user for drivers and will go away soon. exynos_drm_fb_dma_addr uses it a an error return when the passed in index is invalid, but the callers never check for it but instead pass the address straight to the hardware. Add a WARN_ON instead and just

[PATCH 07/44] xen-swiotlb: consolidate xen_swiotlb_dma_ops

ARM and x86 had duplicated versions of the dma_ops structure, the only difference is that x86 hasn't wired up the set_dma_mask, mmap, and get_sgtable ops yet. On x86 all of them are identical to the generic version, so they aren't needed but harmless. All the symbols used only for

[PATCH 10/44] ia64: remove DMA_ERROR_CODE

All ia64 dma_mapping_ops instances already have a mapping_error member. Signed-off-by: Christoph Hellwig --- arch/ia64/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/ia64/include/asm/dma-mapping.h b/arch/ia64/include/asm/dma-mapping.h index

[PATCH 08/44] xen-swiotlb: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig Reviewed-by: Konrad Rzeszutek Wilk --- drivers/xen/swiotlb-xen.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git

[PATCH 11/44] m32r: remove DMA_ERROR_CODE

dma-noop is the only dma_mapping_ops instance for m32r and does not return errors. Signed-off-by: Christoph Hellwig --- arch/m32r/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/m32r/include/asm/dma-mapping.h

[PATCH 12/44] microblaze: remove DMA_ERROR_CODE

microblaze does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig --- arch/microblaze/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/microblaze/include/asm/dma-mapping.h b/arch/microblaze/include/asm/dma-mapping.h index

[PATCH 16/44] arm64: remove DMA_ERROR_CODE

The dma alloc interface returns an error by return NULL, and the mapping interfaces rely on the mapping_error method, which the dummy ops already implement correctly. Thus remove the DMA_ERROR_CODE define. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy

[PATCH 18/44] iommu/amd: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- drivers/iommu/amd_iommu.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index

[PATCH 20/44] sparc: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- arch/sparc/include/asm/dma-mapping.h | 2 -- arch/sparc/kernel/iommu.c| 12 +--- arch/sparc/kernel/iommu_common.h |

[PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

Signed-off-by: Christoph Hellwig Acked-by: Richard Kuo --- arch/hexagon/include/asm/dma-mapping.h | 2 -- arch/hexagon/kernel/dma.c | 12 +--- arch/hexagon/kernel/hexagon_ksyms.c| 1 - 3 files changed, 9 insertions(+), 6 deletions(-)

[PATCH 19/44] s390: implement ->mapping_error

s390 can also use noop_dma_ops, and while that currently does not return errors it will so in the future. Implementing the mapping_error method is the proper way to have per-ops error conditions. Signed-off-by: Christoph Hellwig Acked-by: Gerald Schaefer

[PATCH 22/44] x86/pci-nommu: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/pci-nommu.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c index

[PATCH 23/44] x86/calgary: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/pci-calgary_64.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/pci-calgary_64.c

[PATCH 25/44] arm: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 13 +--- arch/arm/include/asm/dma-iommu.h | 2 ++ arch/arm/include/asm/dma-mapping.h | 1 - arch/arm/mm/dma-mapping.c | 41

[PATCH 26/44] dma-mapping: remove DMA_ERROR_CODE

And update the documentation - dma_mapping_error has been supported everywhere for a long time. Signed-off-by: Christoph Hellwig --- Documentation/DMA-API-HOWTO.txt | 31 +-- include/linux/dma-mapping.h | 5 - 2 files changed, 5 insertions(+),

[PATCH 28/44] sparc: remove arch specific dma_supported implementations

Usually dma_supported decisions are done by the dma_map_ops instance. Switch sparc to that model by providing a ->dma_supported instance for sbus that always returns false, and implementations tailored to the sun4u and sun4v cases for sparc64, and leave it unimplemented for PCI on sparc32, which

[PATCH 24/44] x86: remove DMA_ERROR_CODE

All dma_map_ops instances now handle their errors through ->mapping_error. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h index

[PATCH 29/44] dma-noop: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-noop.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-noop.c b/lib/dma-noop.c index de26c8b68f34..643a074f139d 100644 --- a/lib/dma-noop.c +++

[PATCH 27/44] sparc: remove leon_dma_ops

We can just use pci32_dma_ops directly. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- arch/sparc/include/asm/dma-mapping.h | 3 +-- arch/sparc/kernel/ioport.c | 5 + 2 files changed, 2 insertions(+), 6 deletions(-) diff --git

[PATCH 30/44] dma-virt: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-virt.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-virt.c b/lib/dma-virt.c index dcd4df1f7174..5c4f11329721 100644 --- a/lib/dma-virt.c +++

[PATCH 34/44] arm: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that the code seems a little fishy for dmabounce and iommu, but for now I'd like to preserve the existing behavior 1:1. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 1 +

[PATCH 38/44] arm: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c index 6ecd5be5d37e..9a92de63426f 100644 ---

[PATCH 36/44] dma-mapping: remove HAVE_ARCH_DMA_SUPPORTED

Signed-off-by: Christoph Hellwig --- include/linux/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index a57875309bfd..3e5908656226 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h

[PATCH 35/44] x86: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that this also means the arch specific check will be fully instead of partially applied in the AMD iommu driver. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 3 ---

[PATCH 37/44] mips/loongson64: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/mips/loongson64/common/dma-swiotlb.c | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/arch/mips/loongson64/common/dma-swiotlb.c

[PATCH 40/44] tile: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- arch/tile/kernel/pci-dma.c | 30 -- 1 file changed, 30 deletions(-) diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c index

[PATCH 43/44] dma-mapping: remove the set_dma_mask method

Signed-off-by: Christoph Hellwig --- arch/powerpc/kernel/dma.c | 4 include/linux/dma-mapping.h | 6 -- 2 files changed, 10 deletions(-) diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c index 41c749586bd2..466c9f07b288 100644 ---

Re: [PATCH 1/3] dev: Prevent creating network devices with negative ifindex

>> What do you think? > > Passing -1 is an error, it doesn't make sense to try and be > helpful to buggy userland. Here is commit I actually change/fix: commit 9c7dafbfab15 ("net: Allow to create links with given ifindex") In this change done the opposite: check for ifm->ifi_index moved to

[PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

Besides removing the last instance of the set_dma_mask method this also reduced the code duplication. Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/cell/iommu.c | 25 + 1 file changed, 9 insertions(+), 16 deletions(-) diff --git

[PATCH 44/44] powerpc: merge __dma_set_mask into dma_set_mask

Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/dma-mapping.h | 1 - arch/powerpc/kernel/dma.c | 13 - 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/include/asm/dma-mapping.h

[PATCH 41/44] powerpc/cell: clean up fixed mapping dma_ops initialization

By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can have the fixed map_ops set yet as it's only set by the set_dma_mask method. So move the setup for the fixed case to be only called in that place instead of indirecting through cell_dma_dev_setup. Signed-off-by: Christoph

[PATCH 39/44] xen-swiotlb: remove xen_swiotlb_set_dma_mask

This just duplicates the generic implementation. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index c3a04b2d7532..82fc54f8eb77 100644 ---

[PATCH 33/44] openrisc: remove arch-specific dma_supported implementation

This implementation is simply bogus - openrisc only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig --- arch/openrisc/include/asm/dma-mapping.h | 7 --- 1 file changed, 7 deletions(-) diff --git

[PATCH 32/44] hexagon: remove the unused dma_is_consistent prototype

Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/dma-mapping.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/hexagon/include/asm/dma-mapping.h b/arch/hexagon/include/asm/dma-mapping.h index 9c15cb5271a6..463dbc18f853 100644 ---

[PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig Acked-by: Richard Kuo --- arch/hexagon/include/asm/dma-mapping.h | 2 --

[PATCH 13/44] openrisc: remove DMA_ERROR_CODE

openrisc does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig --- arch/openrisc/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/openrisc/include/asm/dma-mapping.h b/arch/openrisc/include/asm/dma-mapping.h index

[PATCH 14/44] sh: remove DMA_ERROR_CODE

sh does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig --- arch/sh/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/sh/include/asm/dma-mapping.h b/arch/sh/include/asm/dma-mapping.h index d99008af5f73..9b06be07db4d 100644 ---

[PATCH 21/44] powerpc: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Instead define a ->mapping_error method for all IOMMU based dma operation instances. The direct ops don't ever return an error and don't need a ->mapping_error method. Signed-off-by: Christoph Hellwig Acked-by: Michael

[PATCH 15/44] xtensa: remove DMA_ERROR_CODE

xtensa already implements the mapping_error method for its only dma_map_ops instance. Signed-off-by: Christoph Hellwig --- arch/xtensa/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/xtensa/include/asm/dma-mapping.h

[PATCH 01/44] firmware/ivc: use dma_mapping_error

DMA_ERROR_CODE is not supposed to be used by drivers. Signed-off-by: Christoph Hellwig Acked-by: Thierry Reding --- drivers/firmware/tegra/ivc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/tegra/ivc.c

[PATCH 02/44] ibmveth: properly unwind on init errors

That way the driver doesn't have to rely on DMA_ERROR_CODE, which is not a public API and going away. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- drivers/net/ethernet/ibm/ibmveth.c | 159 + 1 file changed,

[PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu driver already implements a proper ->mapping_error method, so it's only using the value internally. Add a new local define using the value that arm64 which is the only current user of dma-iommu. Signed-off-by: Christoph

[PATCH 09/44] c6x: remove DMA_ERROR_CODE

Signed-off-by: Christoph Hellwig --- arch/c6x/include/asm/dma-mapping.h | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/c6x/include/asm/dma-mapping.h b/arch/c6x/include/asm/dma-mapping.h index aca9f755e4f8..05daf1038111 100644 --- a/arch/c6x/include/asm/dma-mapping.h

clean up and modularize arch dma_mapping interface V2

Hi all, for a while we have a generic implementation of the dma mapping routines that call into per-arch or per-device operations. But right now there still are various bits in the interfaces where don't clearly operate on these ops. This series tries to clean up a lot of those (but not all

[PATCH net-next 05/21] net: introduce a new function dst_dev_put()

From: Wei Wang This function should be called when removing routes from fib tree after the dst gc is no longer in use. We first mark DST_OBSOLETE_DEAD on this dst to make sure next dst_ops->check() fails and returns NULL. Secondly, as we no longer keep the gc_list, we need to

[PATCH net-next 02/21] udp: call dst_hold_safe() in udp_sk_rx_set_dst()

From: Wei Wang In udp_v4/6_early_demux() code, we try to hold dst->__refcnt for dst with DST_NOCACHE flag. This is because later in udp_sk_rx_dst_set() function, we will try to cache this dst in sk for connected case. However, a better way to achieve this is to not try to hold

[PATCH net-next 04/21] net: introduce DST_NOGC in dst_release() to destroy dst based on refcnt

From: Wei Wang The current mechanism of freeing dst is a bit complicated. dst has its ref count and when user grabs the reference to the dst, the ref count is properly taken in most cases except in IPv4/IPv6/decnet/xfrm routing code due to some historic reasons. If the

[PATCH net-next 21/21] net: add debug atomic_inc_not_zero() in dst_hold()

From: Wei Wang This patch is meant to add a debug warning on the situation where dst is being held during its destroy phase. This could potentially cause double free issue on the dst. Signed-off-by: Wei Wang Acked-by: Martin KaFai Lau ---

[PATCH net-next 11/21] ipv6: call dst_dev_put() properly

From: Wei Wang As the intend of this patch series is to completely remove dst gc, we need to call dst_dev_put() to release the reference to dst->dev when removing routes from fib because we won't keep the gc list anymore and will lose the dst pointer right after removing the

[PATCH net-next 16/21] decnet: take dst->__refcnt when struct dn_route is created

From: Wei Wang struct dn_route is inserted into dn_rt_hash_table but no dst->__refcnt is taken. This patch makes sure the dn_rt_hash_table's reference to the dst is ref counted. As the dst is always ref counted properly, we can safely mark DST_NOGC flag so dst_release() will

[PATCH net-next 09/21] ipv4: mark DST_NOGC and remove the operation of dst_free()

From: Wei Wang With the previous preparation patches, we are ready to get rid of the dst gc operation in ipv4 code and release dst based on refcnt only. So this patch adds DST_NOGC flag for all IPv4 dst and remove the calls to dst_free(). At this point, all dst created in ipv4

[PATCH net-next 07/21] ipv4: call dst_dev_put() properly

From: Wei Wang As the intend of this patch series is to completely remove dst gc, we need to call dst_dev_put() to release the reference to dst->dev when removing routes from fib because we won't keep the gc list anymore and will lose the dst pointer right after removing the

[PATCH net-next 13/21] ipv6: mark DST_NOGC and remove the operation of dst_free()

From: Wei Wang With the previous preparation patches, we are ready to get rid of the dst gc operation in ipv6 code and release dst based on refcnt only. So this patch adds DST_NOGC flag for all IPv6 dst and remove the calls to dst_free() and its related functions. At this

[PATCH net-next 12/21] ipv6: call dst_hold_safe() properly

From: Wei Wang Similar as ipv4, ipv6 path also needs to call dst_hold_safe() when necessary to avoid double free issue on the dst. Signed-off-by: Wei Wang Acked-by: Martin KaFai Lau --- net/ipv6/addrconf.c | 4 ++-- net/ipv6/route.c| 4

[PATCH net-next 18/21] net: remove DST_NOGC flag

From: Wei Wang Now that all the components have been changed to release dst based on refcnt only and not depend on dst gc anymore, we can remove the temporary flag DST_NOGC. Note that we also need to remove the DST_NOCACHE check in dst_release() and dst_hold_safe() because

[PATCH net-next 03/21] net: use loopback dev when generating blackhole route

From: Wei Wang Existing ipv4/6_blackhole_route() code generates a blackhole route with dst->dev pointing to the passed in dst->dev. It is not necessary to hold reference to the passed in dst->dev because the packets going through this route are dropped anyway. A loopback

  1   2   3   >