* Re: [PATCH v2] decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb
From: David Miller @ 2017-06-08 14:39 UTC (permalink / raw)
To: mjurczyk
Cc: fw, pablo, kadlec, netfilter-devel, coreteam, linux-decnet-user,
netdev, linux-kernel
In-Reply-To: <CAPr8fOQNP+y78xJqx5BNUfY6Rmjj2R8+jrz3Ett1SgdY+a5WLw@mail.gmail.com>
From: Mateusz Jurczyk <mjurczyk@google.com>
Date: Wed, 7 Jun 2017 16:41:57 +0200
> On Wed, Jun 7, 2017 at 4:18 PM, Florian Westphal <fw@strlen.de> wrote:
>> Mateusz Jurczyk <mjurczyk@google.com> wrote:
>>> Verify that the length of the socket buffer is sufficient to cover the
>>> nlmsghdr structure before accessing the nlh->nlmsg_len field for further
>>> input sanitization. If the client only supplies 1-3 bytes of data in
>>> sk_buff, then nlh->nlmsg_len remains partially uninitialized and
>>> contains leftover memory from the corresponding kernel allocation.
>>> Operating on such data may result in indeterminate evaluation of the
>>> nlmsg_len < sizeof(*nlh) expression.
>>>
>>> The bug was discovered by a runtime instrumentation designed to detect
>>> use of uninitialized memory in the kernel. The patch prevents this and
>>> other similar tools (e.g. KMSAN) from flagging this behavior in the future.
>>
>> Instead of changing all the internal users wouldn't it be better
>> to add this check once in netlink_unicast_kernel?
>>
>
> Perhaps. I must admit I'm not very familiar with this code
> area/interface, so I preferred to fix the few specific cases instead
> of submitting a general patch, which might have some unexpected side
> effects, e.g. behavior different from one of the internal clients etc.
>
> If you think one check in netlink_unicast_kernel is a better way to do
> it, I'm happy to implement it like that.
Until we decide to add the check to netlink_unicast_kernel(), I'm applying
this and queueing it up for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH 20/44] sparc: implement ->mapping_error
From: David Miller @ 2017-06-08 14:24 UTC (permalink / raw)
To: hch
Cc: linux-mips, linux-samsung-soc, linux-ia64, linux-c6x-dev,
linux-s390, linux-sh, linux-hexagon, linux-xtensa, x86,
linux-tegra, linux-kernel, dri-devel, dmaengine, iommu, openrisc,
netdev, sparclinux, xen-devel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20170608132609.32662-21-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Thu, 8 Jun 2017 15:25:45 +0200
> DMA_ERROR_CODE is going to go away, so don't rely on it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 28/44] sparc: remove arch specific dma_supported implementations
From: David Miller @ 2017-06-08 14:24 UTC (permalink / raw)
To: hch
Cc: linux-mips, linux-samsung-soc, linux-ia64, linux-c6x-dev,
linux-s390, linux-sh, linux-hexagon, linux-xtensa, x86,
linux-tegra, linux-kernel, dri-devel, dmaengine, iommu, openrisc,
netdev, sparclinux, xen-devel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20170608132609.32662-29-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Thu, 8 Jun 2017 15:25:53 +0200
> 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 means always supported.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] net/ethtool: Replace memset with compiler directive
From: David Miller @ 2017-06-08 14:23 UTC (permalink / raw)
To: yuval.shaia
Cc: andrew, allan.nielsen, Raju.Lakkaraju, jakub.kicinski,
steffen.klassert, ast, sgruszka, mlichvar, netdev
In-Reply-To: <20170608133221.608-1-yuval.shaia@oracle.com>
From: Yuval Shaia <yuval.shaia@oracle.com>
Date: Thu, 8 Jun 2017 16:32:21 +0300
> Take advantage of compiler variable zero-ing and remove calls to memset.
>
> Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
That construct looks so ugly, also the memset()'s in some cases are
constrained to the basic blockwhere the variable is used, avoiding an
initialization unnecessarily.
I'm not applying this, sorry.
^ permalink raw reply
* Re: [PATCH 28/44] sparc: remove arch specific dma_supported implementations
From: Julian Calaby @ 2017-06-08 14:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86, Mailing List, Arm, xen-devel, linux-c6x-dev, linux-hexagon,
linux-ia64, linux-mips, openrisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-xtensa, dmaengine, linux-tegra,
dri-devel, linux-samsung-soc, iommu, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <20170608132609.32662-29-hch@lst.de>
Hi Christoph,
On Thu, Jun 8, 2017 at 11:25 PM, Christoph Hellwig <hch@lst.de> wrote:
> 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 means always supported.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/sparc/include/asm/dma-mapping.h | 3 ---
> arch/sparc/kernel/iommu.c | 40 +++++++++++++++---------------------
> arch/sparc/kernel/ioport.c | 22 ++++++--------------
> arch/sparc/kernel/pci_sun4v.c | 17 +++++++++++++++
> 4 files changed, 39 insertions(+), 43 deletions(-)
>
> diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
> index dd081d557609..12894f259bea 100644
> --- a/arch/sparc/kernel/ioport.c
> +++ b/arch/sparc/kernel/ioport.c
> @@ -401,6 +401,11 @@ static void sbus_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
> BUG();
> }
>
> +static int sbus_dma_supported(struct device *dev, u64 mask)
> +{
> + return 0;
> +}
> +
I'm guessing there's a few places that have DMA ops but DMA isn't
actually supported. Why not have a common method for this, maybe
"dma_not_supported"?
> static const struct dma_map_ops sbus_dma_ops = {
> .alloc = sbus_alloc_coherent,
> .free = sbus_free_coherent,
> @@ -410,6 +415,7 @@ static const struct dma_map_ops sbus_dma_ops = {
> .unmap_sg = sbus_unmap_sg,
> .sync_sg_for_cpu = sbus_sync_sg_for_cpu,
> .sync_sg_for_device = sbus_sync_sg_for_device,
> + .dma_supported = sbus_dma_supported,
> };
>
> static int __init sparc_register_ioport(void)
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH 27/44] sparc: remove leon_dma_ops
From: David Miller @ 2017-06-08 14:22 UTC (permalink / raw)
To: hch
Cc: x86, linux-arm-kernel, xen-devel, linux-c6x-dev, linux-hexagon,
linux-ia64, linux-mips, openrisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-xtensa, dmaengine, linux-tegra,
dri-devel, linux-samsung-soc, iommu, netdev, linux-kernel
In-Reply-To: <20170608132609.32662-28-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Thu, 8 Jun 2017 15:25:52 +0200
> We can just use pci32_dma_ops.
>
> Btw, given that leon is 32-bit and appears to be PCI based, do even need
> the special case for it in get_arch_dma_ops at all?
I would need to defer to the LEON developers on that, but they haven't
been very actively lately so whether you'll get a response or not is
hard to predict.
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 02/44] ibmveth: properly unwind on init errors
From: David Miller @ 2017-06-08 14:21 UTC (permalink / raw)
To: hch-jcswGhMUV9g
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-ia64-u79uwXL29TY76Z2rM5mHXA,
linux-c6x-dev-jPsnJVOj+W6hPH1hqNUYSQ,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
linux-hexagon-u79uwXL29TY76Z2rM5mHXA,
linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
openrisc-cunTk1MwBs9a3B2Vnqf2dGD2FQJk+8+b,
netdev-u79uwXL29TY76Z2rM5mHXA, sparclinux-u79uwXL29TY76Z2rM5mHXA,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170608132609.32662-3-hch-jcswGhMUV9g@public.gmane.org>
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Date: Thu, 8 Jun 2017 15:25:27 +0200
> 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 <hch-jcswGhMUV9g@public.gmane.org>
Acked-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
^ permalink raw reply
* Re: clean up and modularize arch dma_mapping interface
From: David Miller @ 2017-06-08 14:21 UTC (permalink / raw)
To: hch-jcswGhMUV9g
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-ia64-u79uwXL29TY76Z2rM5mHXA,
linux-c6x-dev-jPsnJVOj+W6hPH1hqNUYSQ,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
linux-hexagon-u79uwXL29TY76Z2rM5mHXA,
linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
openrisc-cunTk1MwBs9a3B2Vnqf2dGD2FQJk+8+b,
netdev-u79uwXL29TY76Z2rM5mHXA, sparclinux-u79uwXL29TY76Z2rM5mHXA,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170608132609.32662-1-hch-jcswGhMUV9g@public.gmane.org>
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Date: Thu, 8 Jun 2017 15:25:25 +0200
> 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
> yet, but the series is big enough). It gets rid of the DMA_ERROR_CODE
> way of signaling failures of the mapping routines from the
> implementations to the generic code (and cleans up various drivers that
> were incorrectly using it), and gets rid of the ->set_dma_mask routine
> in favor of relying on the ->dma_capable method that can be used in
> the same way, but which requires less code duplication.
There is unlikely to be conflicts for the sparc and net changes, so I
will simply ACK them.
Thanks Christoph.
^ permalink raw reply
* Re: merge net into net-next?
From: David Miller @ 2017-06-08 14:19 UTC (permalink / raw)
To: johannes; +Cc: netdev
In-Reply-To: <1496924055.26119.1.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 08 Jun 2017 14:14:15 +0200
> On Thu, 2017-06-08 at 14:10 +0200, Johannes Berg wrote:
>> Hi Dave,
>>
>> Could you do me a favour and merge net into net-next? I want to merge
>> that back in order to apply a patch to mac80211-next that otherwise
>> conflicts fairly badly with a change in mac80211.
>
> Wait, forget it. You already did, I just managed to somehow miss that -
> sorry for the noise!
Great, nothing for me to do!
^ permalink raw reply
* Re: merge net into net-next?
From: David Miller @ 2017-06-08 14:19 UTC (permalink / raw)
To: johannes; +Cc: netdev
In-Reply-To: <1496923855.26119.0.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 08 Jun 2017 14:10:55 +0200
> Could you do me a favour and merge net into net-next? I want to
> merge that back in order to apply a patch to mac80211-next that
> otherwise conflicts fairly badly with a change in mac80211.
I'll try to do that by the end of today.
^ permalink raw reply
* Re: next-20170608 build: 1 failures 4 warnings (next-20170608)
From: David Miller @ 2017-06-08 14:17 UTC (permalink / raw)
To: sre; +Cc: broonie, kernel-build-reports, linaro-kernel, linux-next, netdev
In-Reply-To: <20170608113326.zo3nqwkbx3k42owz@earth>
From: Sebastian Reichel <sre@kernel.org>
Date: Thu, 8 Jun 2017 13:33:26 +0200
> Hi,
>
> On Thu, Jun 08, 2017 at 11:32:31AM +0100, Mark Brown wrote:
>> On Thu, Jun 08, 2017 at 10:57:50AM +0100, Build bot for Mark Brown wrote:
>>
>> Today's -next fails to build an ARM allmodconfig due to:
>>
>> > arm-allmodconfig
>> > ../drivers/hsi/clients/ssi_protocol.c:1069:5: error: 'struct net_device' has no member named 'destructor'
>>
>> due to cf124db566e6 (net: Fix inconsistent teardown and release of
>> private netdev state.) which missed this instance, presumably due to a
>> combination of it not being in one of the normal networking driver
>> directories and only being buildable on ARM.
>
> I assume, that this will be fixed via the net tree.
> If you Cc me on updated/new patch I will provide Acked-by.
It is fixed in the 'net' tree, don't worry about it :-)
^ permalink raw reply
* Re: next-20170608 build: 1 failures 4 warnings (next-20170608)
From: David Miller @ 2017-06-08 14:16 UTC (permalink / raw)
To: sfr; +Cc: netdev, broonie, linaro-kernel, linux-next
In-Reply-To: <20170608202704.1469d0bf@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Jun 2017 20:27:04 +1000
> Hi Dave,
>
> On Thu, 08 Jun 2017 10:57:50 +0100 Build bot for Mark Brown <broonie@kernel.org> wrote:
>>
>> Tree/Branch: next-20170608
>> Git describe: next-20170608
>> Commit: e4689b9aad Add linux-next specific files for 20170608
>>
>> Build Time: 0 min 12 sec
>>
>> Passed: 6 / 7 ( 85.71 %)
>> Failed: 1 / 7 ( 14.29 %)
>>
>> Errors: 1
>> Warnings: 4
>> Section Mismatches: 0
>>
>> Failed defconfigs:
>> arm-allmodconfig
>>
>> Errors:
>>
>> arm-allmodconfig
>> ../drivers/hsi/clients/ssi_protocol.c:1069:5: error: 'struct net_device' has no member named 'destructor'
>
> Looks like Mark has found another one.
This should fix it, pushed out to 'net'.
Thanks.
====================
[PATCH] hsi: Fix build regression due to netdev destructor fix.
> ../drivers/hsi/clients/ssi_protocol.c:1069:5: error: 'struct net_device' has no member named 'destructor'
Reported-by: Mark Brown <broonie@kernel.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/hsi/clients/ssi_protocol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hsi/clients/ssi_protocol.c b/drivers/hsi/clients/ssi_protocol.c
index 26b0510..93d28c0 100644
--- a/drivers/hsi/clients/ssi_protocol.c
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -1066,7 +1066,7 @@ static void ssip_pn_setup(struct net_device *dev)
dev->addr_len = 1;
dev->tx_queue_len = SSIP_TXQUEUE_LEN;
- dev->destructor = free_netdev;
+ dev->needs_free_netdev = true;
dev->header_ops = &phonet_header_ops;
}
--
2.4.11
^ permalink raw reply related
* Re: kisskb: FAILED linux-next/s390-defconfig/s390x Thu Jun 08, 18:28
From: David Miller @ 2017-06-08 14:14 UTC (permalink / raw)
To: sfr; +Cc: netdev, schwidefsky, heiko.carstens
In-Reply-To: <20170608191143.0d54c17e@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Jun 2017 19:11:43 +1000
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 8 Jun 2017 19:06:29 +1000
> Subject: [PATCH] net: s390: fix up for "Fix inconsistent teardown and release
> of private netdev state"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH 16/44] arm64: remove DMA_ERROR_CODE
From: Robin Murphy @ 2017-06-08 14:02 UTC (permalink / raw)
To: Christoph Hellwig, x86, linux-arm-kernel, xen-devel,
linux-c6x-dev, linux-hexagon, linux-ia64, linux-mips, openrisc,
linuxppc-dev, linux-s390, linux-sh, sparclinux, linux-xtensa,
dmaengine, linux-tegra, dri-devel, linux-samsung-soc, iommu,
netdev
Cc: linux-kernel
In-Reply-To: <20170608132609.32662-17-hch@lst.de>
On 08/06/17 14:25, Christoph Hellwig wrote:
> 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.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/include/asm/dma-mapping.h | 1 -
> arch/arm64/mm/dma-mapping.c | 3 +--
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
> index 5392dbeffa45..cf8fc8f05580 100644
> --- a/arch/arm64/include/asm/dma-mapping.h
> +++ b/arch/arm64/include/asm/dma-mapping.h
> @@ -24,7 +24,6 @@
> #include <xen/xen.h>
> #include <asm/xen/hypervisor.h>
>
> -#define DMA_ERROR_CODE (~(dma_addr_t)0)
> extern const struct dma_map_ops dummy_dma_ops;
>
> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 3216e098c058..147fbb907a2f 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -184,7 +184,6 @@ static void *__dma_alloc(struct device *dev, size_t size,
> no_map:
> __dma_free_coherent(dev, size, ptr, *dma_handle, attrs);
> no_mem:
> - *dma_handle = DMA_ERROR_CODE;
> return NULL;
> }
>
> @@ -487,7 +486,7 @@ static dma_addr_t __dummy_map_page(struct device *dev, struct page *page,
> enum dma_data_direction dir,
> unsigned long attrs)
> {
> - return DMA_ERROR_CODE;
> + return 0;
> }
>
> static void __dummy_unmap_page(struct device *dev, dma_addr_t dev_addr,
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 2/2] ip6_tunnel: fix potential issue in __ip6_tnl_rcv
From: David Miller @ 2017-06-08 13:59 UTC (permalink / raw)
To: yanhaishuang; +Cc: alexei.starovoitov, netdev, edumazet
In-Reply-To: <6CE04FE7-4904-4047-95F5-80461324CDA6@cmss.chinamobile.com>
From: 严海双 <yanhaishuang@cmss.chinamobile.com>
Date: Thu, 8 Jun 2017 15:33:58 +0800
>> On 8 Jun 2017, at 1:00 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>>
>> On Thu, Jun 08, 2017 at 12:56:58PM +0800, 严海双 wrote:
>>>
>>>> On 8 Jun 2017, at 12:38 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>>>>
>>>> On Thu, Jun 08, 2017 at 12:32:44PM +0800, Haishuang Yan wrote:
>>>>> When __ip6_tnl_rcv fails, the tun_dst won't be freed, so call
>>>>> dst_release to free it in error code path.
>>>>>
>>>>> CC: Alexei Starovoitov <ast@fb.com>
>>>>> Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
>>>>> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>>>>
>>>> I don't get it. Why did you send another version of the patch?
>>>> What was wrong with previous approach that myself and Eric acked?
>>>>
>>>>
>>>
>>> Sorry for your confusing, because Pravin Shelar give a feedback in ipv4 patch, see below:
>>
>> hmm. right.
>> Then it raises the question: How did you test this and previous patch?
>>
>> since previous version was sort-of fixing the bug, but completely
>> breaking the logic...
>>
>>
>
> Sorry for my previous fault, I tried to fix this problem in theory without testing carefully.
> I have tested the latest patches, it works ok now.
This does not instill a lot of confidence in us.
I want someone else to test these patches, then you can resubmit them
with proper Tested-by: tags added, since you thought it was OK to submit
a patch without testing in the first place.
^ permalink raw reply
* Re: [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE
From: Robin Murphy @ 2017-06-08 13:59 UTC (permalink / raw)
To: Christoph Hellwig, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b,
linux-c6x-dev-jPsnJVOj+W6hPH1hqNUYSQ,
linux-hexagon-u79uwXL29TY76Z2rM5mHXA,
linux-ia64-u79uwXL29TY76Z2rM5mHXA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
openrisc-cunTk1MwBs9a3B2Vnqf2dGD2FQJk+8+b,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
sparclinux-u79uwXL29TY76Z2rM5mHXA,
linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170608132609.32662-7-hch-jcswGhMUV9g@public.gmane.org>
Hi Christoph,
On 08/06/17 14:25, Christoph Hellwig wrote:
> 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.
It would be fine to just use 0, since dma-iommu already makes sure that
that will never be allocated for a valid DMA address.
Otherwise, looks good!
Robin.
> Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> ---
> drivers/iommu/dma-iommu.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 62618e77bedc..638aea814b94 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -31,6 +31,8 @@
> #include <linux/scatterlist.h>
> #include <linux/vmalloc.h>
>
> +#define IOMMU_MAPPING_ERROR (~(dma_addr_t)0)
> +
> struct iommu_dma_msi_page {
> struct list_head list;
> dma_addr_t iova;
> @@ -500,7 +502,7 @@ void iommu_dma_free(struct device *dev, struct page **pages, size_t size,
> {
> __iommu_dma_unmap(iommu_get_domain_for_dev(dev), *handle, size);
> __iommu_dma_free_pages(pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
> - *handle = DMA_ERROR_CODE;
> + *handle = IOMMU_MAPPING_ERROR;
> }
>
> /**
> @@ -533,7 +535,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
> dma_addr_t iova;
> unsigned int count, min_size, alloc_sizes = domain->pgsize_bitmap;
>
> - *handle = DMA_ERROR_CODE;
> + *handle = IOMMU_MAPPING_ERROR;
>
> min_size = alloc_sizes & -alloc_sizes;
> if (min_size < PAGE_SIZE) {
> @@ -627,11 +629,11 @@ static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
>
> iova = iommu_dma_alloc_iova(domain, size, dma_get_mask(dev), dev);
> if (!iova)
> - return DMA_ERROR_CODE;
> + return IOMMU_MAPPING_ERROR;
>
> if (iommu_map(domain, iova, phys - iova_off, size, prot)) {
> iommu_dma_free_iova(cookie, iova, size);
> - return DMA_ERROR_CODE;
> + return IOMMU_MAPPING_ERROR;
> }
> return iova + iova_off;
> }
> @@ -671,7 +673,7 @@ static int __finalise_sg(struct device *dev, struct scatterlist *sg, int nents,
>
> s->offset += s_iova_off;
> s->length = s_length;
> - sg_dma_address(s) = DMA_ERROR_CODE;
> + sg_dma_address(s) = IOMMU_MAPPING_ERROR;
> sg_dma_len(s) = 0;
>
> /*
> @@ -714,11 +716,11 @@ static void __invalidate_sg(struct scatterlist *sg, int nents)
> int i;
>
> for_each_sg(sg, s, nents, i) {
> - if (sg_dma_address(s) != DMA_ERROR_CODE)
> + if (sg_dma_address(s) != IOMMU_MAPPING_ERROR)
> s->offset += sg_dma_address(s);
> if (sg_dma_len(s))
> s->length = sg_dma_len(s);
> - sg_dma_address(s) = DMA_ERROR_CODE;
> + sg_dma_address(s) = IOMMU_MAPPING_ERROR;
> sg_dma_len(s) = 0;
> }
> }
> @@ -836,7 +838,7 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>
> int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
> {
> - return dma_addr == DMA_ERROR_CODE;
> + return dma_addr == IOMMU_MAPPING_ERROR;
> }
>
> static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
>
^ permalink raw reply
* Re: [patch net-next] net: propagate tc filter chain index down the ndo_setup_tc call
From: David Miller @ 2017-06-08 13:56 UTC (permalink / raw)
To: jiri
Cc: netdev, jhs, xiyou.wangcong, dsa, edumazet, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170606150016.2419-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 6 Jun 2017 17:00:16 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> We need to push the chain index down to the drivers, so they have the
> information to which chain the rule belongs. For now, no driver supports
> multichain offload, so only chain 0 is supported. This is needed to
> prevent chain squashes during offload for now. Later this will be used
> to implement multichain offload.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH] cpsw: cpts: enable HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter
From: David Miller @ 2017-06-08 13:52 UTC (permalink / raw)
To: grygorii.strashko; +Cc: netdev, nsekhar, linux-kernel, linux-omap
In-Reply-To: <20170605232108.13453-1-grygorii.strashko@ti.com>
These two patches do not apply cleanly to my net GIT tree, please respin.
^ permalink raw reply
* [PATCH net] ipv4: igmp: fix a use after free
From: Eric Dumazet @ 2017-06-08 13:43 UTC (permalink / raw)
To: Andrey Konovalov; +Cc: David S. Miller, netdev
In-Reply-To: <CAAeHK+xmSxokDidhzP1VWgmbbwege4OaGvOA4PwTP1scs6J5zA@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
Andrey reported a use-after-free in add_grec(), courtesy of syzkaller.
Problem here is that igmp_stop_timer() uses a del_timer(), so we can not
guarantee that another cpu is not servicing the timer.
Therefore, if igmp_group_dropped() call from ip_mc_dec_group() is
immediately followed by ip_mc_clear_src(), ip_mc_clear_src() might free
memory that could be used by the other cpu servicing the timer.
To fix this issue, we should defer the memory freeing
(ip_mc_clear_src()) to the point all references to (struct
ip_mc_list)->refcnt have been released.
This happens in ip_ma_put()
==================================================================
BUG: KASAN: use-after-free in add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
Read of size 8 at addr ffff88003053c1a0 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.12.0-rc3+ #370
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x292/0x395 lib/dump_stack.c:52
print_address_description+0x73/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x22b/0x340 mm/kasan/report.c:408
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
igmpv3_send_cr net/ipv4/igmp.c:663 [inline]
igmp_ifc_timer_expire+0x46d/0xa80 net/ipv4/igmp.c:768
IPVS: length: 51 != 8
call_timer_fn+0x23f/0x800 kernel/time/timer.c:1268
expire_timers kernel/time/timer.c:1307 [inline]
__run_timers+0x94e/0xcd0 kernel/time/timer.c:1601
run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
__do_softirq+0x2fb/0xb99 kernel/softirq.c:284
invoke_softirq kernel/softirq.c:364 [inline]
irq_exit+0x19e/0x1d0 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:652 [inline]
smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:966
apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:481
RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
RSP: 0018:ffffffff85a079a8 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10
RAX: dffffc0000000020 RBX: 1ffffffff0b40f38 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff85a2a9e4
RBP: ffffffff85a079a8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
R13: ffffffff85a07a60 R14: ffffffff86171338 R15: 1ffffffff0b40f5b
</IRQ>
arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
default_idle+0x8f/0x440 arch/x86/kernel/process.c:341
arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:332
default_idle_call+0x36/0x60 kernel/sched/idle.c:98
cpuidle_idle_call kernel/sched/idle.c:156 [inline]
do_idle+0x348/0x420 kernel/sched/idle.c:245
cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:350
rest_init+0x18d/0x1a0 init/main.c:415
start_kernel+0x747/0x779 init/main.c:679
x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:196
x86_64_start_kernel+0x132/0x141 arch/x86/kernel/head64.c:177
secondary_startup_64+0x9f/0x9f arch/x86/kernel/head_64.S:304
Allocated by task 30543:
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:513
set_track mm/kasan/kasan.c:525 [inline]
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
kmalloc include/linux/slab.h:492 [inline]
kzalloc include/linux/slab.h:665 [inline]
ip_mc_add1_src net/ipv4/igmp.c:1909 [inline]
ip_mc_add_src+0x6cd/0x1020 net/ipv4/igmp.c:2033
ip_mc_msfilter+0x5e5/0xcf0 net/ipv4/igmp.c:2403
do_ip_setsockopt.isra.12+0x2d47/0x38c0 net/ipv4/ip_sockglue.c:959
ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1256
tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2740
sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2844
SYSC_setsockopt net/socket.c:1798 [inline]
SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
entry_SYSCALL_64_fastpath+0x1f/0xbe
Freed by task 30543:
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:513
set_track mm/kasan/kasan.c:525 [inline]
kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
slab_free_hook mm/slub.c:1357 [inline]
slab_free_freelist_hook mm/slub.c:1379 [inline]
slab_free mm/slub.c:2961 [inline]
kfree+0xe8/0x2b0 mm/slub.c:3882
ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
sock_release+0x8d/0x1e0 net/socket.c:597
sock_close+0x16/0x20 net/socket.c:1072
__fput+0x332/0x7f0 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:245
task_work_run+0x19b/0x270 kernel/task_work.c:116
exit_task_work include/linux/task_work.h:21 [inline]
do_exit+0x18a3/0x2820 kernel/exit.c:878
do_group_exit+0x149/0x420 kernel/exit.c:982
get_signal+0x76d/0x1790 kernel/signal.c:2318
do_signal+0xd2/0x2130 arch/x86/kernel/signal.c:808
exit_to_usermode_loop+0x17a/0x210 arch/x86/entry/common.c:157
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
entry_SYSCALL_64_fastpath+0xbc/0xbe
The buggy address belongs to the object at ffff88003053c1a0
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes inside of
64-byte region [ffff88003053c1a0, ffff88003053c1e0)
The buggy address belongs to the page:
page:ffffea0000c14f00 count:1 mapcount:0 mapping: (null)
index:0x0 compound_mapcount: 0
flags: 0x100000000008100(slab|head)
raw: 0100000000008100 0000000000000000 0000000000000000 0000000100140014
raw: ffffea0000c2f520 ffffea0000e20aa0 ffff88003e80f740 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88003053c080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88003053c100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88003053c180: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff88003053c200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88003053c280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
---
net/ipv4/igmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 44fd86de2823dd17de16276a8ec01b190e69b8b4..f172d251c5f2cda8fc8bedd65fa16cdfe33a4d40 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -174,6 +174,7 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
static void ip_ma_put(struct ip_mc_list *im)
{
if (atomic_dec_and_test(&im->refcnt)) {
+ ip_mc_clear_src(im);
in_dev_put(im->interface);
kfree_rcu(im, rcu);
}
@@ -1615,7 +1616,6 @@ void ip_mc_dec_group(struct in_device *in_dev, __be32 addr)
*ip = i->next_rcu;
in_dev->mc_count--;
igmp_group_dropped(i);
- ip_mc_clear_src(i);
if (!in_dev->dead)
ip_rt_multicast_event(in_dev);
^ permalink raw reply related
* (unknown)
From: Yuval Shaia @ 2017-06-08 13:35 UTC (permalink / raw)
To: netdev
subscribe netdev
^ permalink raw reply
* [PATCH] net/ethtool: Replace memset with compiler directive
From: Yuval Shaia @ 2017-06-08 13:32 UTC (permalink / raw)
To: davem, andrew, allan.nielsen, Raju.Lakkaraju, jakub.kicinski,
steffen.klassert, ast, sgruszka, mlichvar, yuval.shaia, netdev
Take advantage of compiler variable zero-ing and remove calls to memset.
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
---
net/core/ethtool.c | 21 +++++++--------------
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 03111a2..051af09 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -559,7 +559,7 @@ int __ethtool_get_link_ksettings(struct net_device *dev,
struct ethtool_link_ksettings *link_ksettings)
{
int err;
- struct ethtool_cmd cmd;
+ struct ethtool_cmd cmd = {0};
ASSERT_RTNL();
@@ -576,7 +576,6 @@ int __ethtool_get_link_ksettings(struct net_device *dev,
if (!dev->ethtool_ops->get_settings)
return -EOPNOTSUPP;
- memset(&cmd, 0, sizeof(cmd));
cmd.cmd = ETHTOOL_GSET;
err = dev->ethtool_ops->get_settings(dev, &cmd);
if (err < 0)
@@ -777,7 +776,7 @@ warn_incomplete_ethtool_legacy_settings_conversion(const char *details)
*/
static int ethtool_get_settings(struct net_device *dev, void __user *useraddr)
{
- struct ethtool_cmd cmd;
+ struct ethtool_cmd cmd = {0};
ASSERT_RTNL();
@@ -808,7 +807,6 @@ static int ethtool_get_settings(struct net_device *dev, void __user *useraddr)
if (!dev->ethtool_ops->get_settings)
return -EOPNOTSUPP;
- memset(&cmd, 0, sizeof(cmd));
cmd.cmd = ETHTOOL_GSET;
err = dev->ethtool_ops->get_settings(dev, &cmd);
if (err < 0)
@@ -870,10 +868,9 @@ static int ethtool_set_settings(struct net_device *dev, void __user *useraddr)
static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev,
void __user *useraddr)
{
- struct ethtool_drvinfo info;
+ struct ethtool_drvinfo info = {0};
const struct ethtool_ops *ops = dev->ethtool_ops;
- memset(&info, 0, sizeof(info));
info.cmd = ETHTOOL_GDRVINFO;
if (ops->get_drvinfo) {
ops->get_drvinfo(dev, &info);
@@ -916,7 +913,7 @@ static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev,
static noinline_for_stack int ethtool_get_sset_info(struct net_device *dev,
void __user *useraddr)
{
- struct ethtool_sset_info info;
+ struct ethtool_sset_info info = {0};
u64 sset_mask;
int i, idx = 0, n_bits = 0, ret, rc;
u32 *info_buf = NULL;
@@ -932,7 +929,6 @@ static noinline_for_stack int ethtool_get_sset_info(struct net_device *dev,
/* calculate size of return buffer */
n_bits = hweight64(sset_mask);
- memset(&info, 0, sizeof(info));
info.cmd = ETHTOOL_GSSET_INFO;
info_buf = kzalloc(n_bits * sizeof(u32), GFP_USER);
@@ -1479,13 +1475,12 @@ static int ethtool_set_wol(struct net_device *dev, char __user *useraddr)
static int ethtool_get_eee(struct net_device *dev, char __user *useraddr)
{
- struct ethtool_eee edata;
+ struct ethtool_eee edata = {0};
int rc;
if (!dev->ethtool_ops->get_eee)
return -EOPNOTSUPP;
- memset(&edata, 0, sizeof(struct ethtool_eee));
edata.cmd = ETHTOOL_GEEE;
rc = dev->ethtool_ops->get_eee(dev, &edata);
@@ -2109,7 +2104,7 @@ static int ethtool_get_dump_data(struct net_device *dev,
{
int ret;
__u32 len;
- struct ethtool_dump dump, tmp;
+ struct ethtool_dump dump, tmp = {0};
const struct ethtool_ops *ops = dev->ethtool_ops;
void *data = NULL;
@@ -2119,7 +2114,6 @@ static int ethtool_get_dump_data(struct net_device *dev,
if (copy_from_user(&dump, useraddr, sizeof(dump)))
return -EFAULT;
- memset(&tmp, 0, sizeof(tmp));
tmp.cmd = ETHTOOL_GET_DUMP_FLAG;
ret = ops->get_dump_flag(dev, &tmp);
if (ret)
@@ -2170,11 +2164,10 @@ static int ethtool_get_dump_data(struct net_device *dev,
static int ethtool_get_ts_info(struct net_device *dev, void __user *useraddr)
{
int err = 0;
- struct ethtool_ts_info info;
+ struct ethtool_ts_info info = {0};
const struct ethtool_ops *ops = dev->ethtool_ops;
struct phy_device *phydev = dev->phydev;
- memset(&info, 0, sizeof(info));
info.cmd = ETHTOOL_GET_TS_INFO;
if (phydev && phydev->drv && phydev->drv->ts_info) {
--
2.9.4
^ permalink raw reply related
* [PATCH 44/44] powerpc: merge __dma_set_mask into dma_set_mask
From: Christoph Hellwig @ 2017-06-08 13:26 UTC (permalink / raw)
To: x86, linux-arm-kernel, xen-devel, linux-c6x-dev, linux-hexagon,
linux-ia64, linux-mips, openrisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-xtensa, dmaengine, linux-tegra,
dri-devel, linux-samsung-soc, iommu, netdev
Cc: linux-kernel
In-Reply-To: <20170608132609.32662-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
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 b/arch/powerpc/include/asm/dma-mapping.h
index 73aedbe6c977..eaece3d3e225 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -112,7 +112,6 @@ static inline void set_dma_offset(struct device *dev, dma_addr_t off)
#define HAVE_ARCH_DMA_SET_MASK 1
extern int dma_set_mask(struct device *dev, u64 dma_mask);
-extern int __dma_set_mask(struct device *dev, u64 dma_mask);
extern u64 __dma_get_required_mask(struct device *dev);
static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 466c9f07b288..4194bbbbdb10 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -314,14 +314,6 @@ EXPORT_SYMBOL(dma_set_coherent_mask);
#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
-int __dma_set_mask(struct device *dev, u64 dma_mask)
-{
- if (!dev->dma_mask || !dma_supported(dev, dma_mask))
- return -EIO;
- *dev->dma_mask = dma_mask;
- return 0;
-}
-
int dma_set_mask(struct device *dev, u64 dma_mask)
{
if (ppc_md.dma_set_mask)
@@ -334,7 +326,10 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
return phb->controller_ops.dma_set_mask(pdev, dma_mask);
}
- return __dma_set_mask(dev, dma_mask);
+ if (!dev->dma_mask || !dma_supported(dev, dma_mask))
+ return -EIO;
+ *dev->dma_mask = dma_mask;
+ return 0;
}
EXPORT_SYMBOL(dma_set_mask);
--
2.11.0
^ permalink raw reply related
* [PATCH 24/44] x86: remove DMA_ERROR_CODE
From: Christoph Hellwig @ 2017-06-08 13:25 UTC (permalink / raw)
To: x86, linux-arm-kernel, xen-devel, linux-c6x-dev, linux-hexagon,
linux-ia64, linux-mips, openrisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-xtensa, dmaengine, linux-tegra,
dri-devel, linux-samsung-soc, iommu, netdev
Cc: linux-kernel
In-Reply-To: <20170608132609.32662-1-hch@lst.de>
All dma_map_ops instances now handle their errors through
->mapping_error.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
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 08a0838b83fb..c35d228aa381 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -19,8 +19,6 @@
# define ISA_DMA_BIT_MASK DMA_BIT_MASK(32)
#endif
-#define DMA_ERROR_CODE 0
-
extern int iommu_merge;
extern struct device x86_dma_fallback_dev;
extern int panic_on_overflow;
--
2.11.0
^ permalink raw reply related
* [PATCH 15/44] xtensa: remove DMA_ERROR_CODE
From: Christoph Hellwig @ 2017-06-08 13:25 UTC (permalink / raw)
To: x86, linux-arm-kernel, xen-devel, linux-c6x-dev, linux-hexagon,
linux-ia64, linux-mips, openrisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-xtensa, dmaengine, linux-tegra,
dri-devel, linux-samsung-soc, iommu, netdev
Cc: linux-kernel
In-Reply-To: <20170608132609.32662-1-hch@lst.de>
xtensa already implements the mapping_error method for its only
dma_map_ops instance.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/xtensa/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/xtensa/include/asm/dma-mapping.h b/arch/xtensa/include/asm/dma-mapping.h
index c6140fa8c0be..269738dc9d1d 100644
--- a/arch/xtensa/include/asm/dma-mapping.h
+++ b/arch/xtensa/include/asm/dma-mapping.h
@@ -16,8 +16,6 @@
#include <linux/mm.h>
#include <linux/scatterlist.h>
-#define DMA_ERROR_CODE (~(dma_addr_t)0x0)
-
extern const struct dma_map_ops xtensa_dma_map_ops;
static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
--
2.11.0
^ permalink raw reply related
* [PATCH 43/44] dma-mapping: remove the set_dma_mask method
From: Christoph Hellwig @ 2017-06-08 13:26 UTC (permalink / raw)
To: x86, linux-arm-kernel, xen-devel, linux-c6x-dev, linux-hexagon,
linux-ia64, linux-mips, openrisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-xtensa, dmaengine, linux-tegra,
dri-devel, linux-samsung-soc, iommu, netdev
Cc: linux-kernel
In-Reply-To: <20170608132609.32662-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
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
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -316,10 +316,6 @@ EXPORT_SYMBOL(dma_set_coherent_mask);
int __dma_set_mask(struct device *dev, u64 dma_mask)
{
- const struct dma_map_ops *dma_ops = get_dma_ops(dev);
-
- if ((dma_ops != NULL) && (dma_ops->set_dma_mask != NULL))
- return dma_ops->set_dma_mask(dev, dma_mask);
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
*dev->dma_mask = dma_mask;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 3e5908656226..527f2ed8c645 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -127,7 +127,6 @@ struct dma_map_ops {
enum dma_data_direction dir);
int (*mapping_error)(struct device *dev, dma_addr_t dma_addr);
int (*dma_supported)(struct device *dev, u64 mask);
- int (*set_dma_mask)(struct device *dev, u64 mask);
#ifdef ARCH_HAS_DMA_GET_REQUIRED_MASK
u64 (*get_required_mask)(struct device *dev);
#endif
@@ -563,11 +562,6 @@ static inline int dma_supported(struct device *dev, u64 mask)
#ifndef HAVE_ARCH_DMA_SET_MASK
static inline int dma_set_mask(struct device *dev, u64 mask)
{
- const struct dma_map_ops *ops = get_dma_ops(dev);
-
- if (ops->set_dma_mask)
- return ops->set_dma_mask(dev, mask);
-
if (!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;
*dev->dma_mask = mask;
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox