[PATCH] crypto: ccp - fix uninitialized list head
A NULL-pointer dereference was reported in fedora bz#1762199 while reshaping a raid6 array after adding a fifth drive to an existing array. [ 47.343549] md/raid:md0: raid level 6 active with 3 out of 5 devices, algorithm 2 [ 47.804017] md0: detected capacity change from 0 to 7885289422848 [ 47.822083] Unable to handle kernel read from unreadable memory at virtual address ... [ 47.940477] CPU: 1 PID: 14210 Comm: md0_raid6 Tainted: GW 5.2.18-200.fc30.aarch64 #1 [ 47.949594] Hardware name: AMD Overdrive/Supercharger/To be filled by O.E.M., BIOS ROD1002C 04/08/2016 [ 47.958886] pstate: 00400085 (nzcv daIf +PAN -UAO) [ 47.963668] pc : __list_del_entry_valid+0x2c/0xa8 [ 47.968366] lr : ccp_tx_submit+0x84/0x168 [ccp] [ 47.972882] sp : 1369b970 [ 47.976184] x29: 1369b970 x28: 1369bdb8 [ 47.981483] x27: x26: 8003b758af70 [ 47.986782] x25: 8003b758b2d8 x24: 8003e6245818 [ 47.992080] x23: x22: 8003e62450c0 [ 47.997379] x21: 8003dfd6add8 x20: 0003 [ 48.002678] x19: 8003e6245100 x18: [ 48.007976] x17: x16: [ 48.013274] x15: x14: [ 48.018572] x13: 7e000ef83a00 x12: 0001 [ 48.023870] x11: 10eff998 x10: 19a0 [ 48.029169] x9 : x8 : 8003e6245180 [ 48.034467] x7 : x6 : 003f [ 48.039766] x5 : 0040 x4 : 8003e0145080 [ 48.045064] x3 : dead0200 x2 : [ 48.050362] x1 : x0 : 8003e62450c0 [ 48.055660] Call trace: [ 48.058095] __list_del_entry_valid+0x2c/0xa8 [ 48.062442] ccp_tx_submit+0x84/0x168 [ccp] [ 48.066615] async_tx_submit+0x224/0x368 [async_tx] [ 48.071480] async_trigger_callback+0x68/0xfc [async_tx] [ 48.076784] ops_run_biofill+0x178/0x1e8 [raid456] [ 48.081566] raid_run_ops+0x248/0x818 [raid456] [ 48.086086] handle_stripe+0x864/0x1208 [raid456] [ 48.090781] handle_active_stripes.isra.0+0xb0/0x278 [raid456] [ 48.096604] raid5d+0x378/0x618 [raid456] [ 48.100602] md_thread+0xa0/0x150 [ 48.103905] kthread+0x104/0x130 [ 48.107122] ret_from_fork+0x10/0x18 [ 48.110686] Code: d2804003 f2fbd5a3 eb03003f 54000320 (f9400021) [ 48.116766] ---[ end trace 23f390a527f7ad77 ]--- ccp_tx_submit is passed a dma_async_tx_descriptor which is contained in a ccp_dma_desc and adds it to a ccp channel's pending list: list_del(&desc->entry); list_add_tail(&desc->entry, &chan->pending); The problem is that desc->entry may be uninitialized in the async_trigger_callback path where the descriptor was gotten from ccp_prep_dma_interrupt which got it from ccp_alloc_dma_desc which doesn't initialize the desc->entry list head. So, just initialize the list head to avoid the problem. Reported-by: Sahaj Sarup Signed-off-by: Mark Salter --- drivers/crypto/ccp/ccp-dmaengine.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/crypto/ccp/ccp-dmaengine.c b/drivers/crypto/ccp/ccp-dmaengine.c index a54f9367a580..0770a83bf1a5 100644 --- a/drivers/crypto/ccp/ccp-dmaengine.c +++ b/drivers/crypto/ccp/ccp-dmaengine.c @@ -342,6 +342,7 @@ static struct ccp_dma_desc *ccp_alloc_dma_desc(struct ccp_dma_chan *chan, desc->tx_desc.flags = flags; desc->tx_desc.tx_submit = ccp_tx_submit; desc->ccp = chan->ccp; + INIT_LIST_HEAD(&desc->entry); INIT_LIST_HEAD(&desc->pending); INIT_LIST_HEAD(&desc->active); desc->status = DMA_IN_PROGRESS; -- 2.21.0
Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object
On Wed, 2015-06-03 at 09:37 -0500, Suravee Suthikulanit wrote: > On 5/28/2015 9:38 PM, Mark Salter wrote: > > On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote: > >> >Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, > >> >section 6.2.17 _CCA states that ARM platforms require ACPI _CCA > >> >object to be specified for DMA-cabpable devices. Therefore, this patch > >> >specifies ACPI_CCA_REQUIRED in arm64 Kconfig. > >> > > >> >In addition, to handle the case when _CCA is missing, arm64 would assign > >> >dummy_dma_ops to disable DMA capability of the device. > >> > > >> >Acked-by: Catalin Marinas > >> >Signed-off-by: Mark Salter > >> >Signed-off-by: Suravee Suthikulpanit > >> >--- > >> > arch/arm64/Kconfig | 1 + > >> > arch/arm64/include/asm/dma-mapping.h | 18 ++- > >> > arch/arm64/mm/dma-mapping.c | 92 > >> > > >> > 3 files changed, 109 insertions(+), 2 deletions(-) > >> > > >> >diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > >> >index 4269dba..95307b4 100644 > >> >--- a/arch/arm64/Kconfig > >> >+++ b/arch/arm64/Kconfig > >> >@@ -1,5 +1,6 @@ > >> > config ARM64 > >> > def_bool y > >> >+ select ACPI_CCA_REQUIRED if ACPI > >> > select ACPI_GENERIC_GSI if ACPI > >> > select ACPI_REDUCED_HARDWARE_ONLY if ACPI > >> > select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE > >> >diff --git a/arch/arm64/include/asm/dma-mapping.h > >> >b/arch/arm64/include/asm/dma-mapping.h > >> >index 9437e3d..f0d6d0b 100644 > >> >--- a/arch/arm64/include/asm/dma-mapping.h > >> >+++ b/arch/arm64/include/asm/dma-mapping.h > >> >@@ -18,6 +18,7 @@ > >> > > >> > #ifdef __KERNEL__ > >> > > >> >+#include > >> > #include > >> > #include > >> > > > ^^^ This hunk causes build issues with a couple of drivers: > > > > drivers/scsi/megaraid/megaraid_sas_fp.c:69:0: warning: "FALSE" redefined > > [enabled by default] > > #define FALSE 0 > > ^ > > In file included from include/acpi/acpi.h:58:0, > > from include/linux/acpi.h:37, > > from ./arch/arm64/include/asm/dma-mapping.h:21, > > from include/linux/dma-mapping.h:86, > > from ./arch/arm64/include/asm/pci.h:7, > > from include/linux/pci.h:1460, > > from drivers/scsi/megaraid/megaraid_sas_fp.c:37: > > include/acpi/actypes.h:433:0: note: this is the location of the previous > > definition > > #define FALSE (1 == 0) > > ^ > > > > > > In file included from include/acpi/acpi.h:58:0, > > from include/linux/acpi.h:37, > > from ./arch/arm64/include/asm/dma-mapping.h:21, > > from include/linux/dma-mapping.h:86, > > from include/scsi/scsi_cmnd.h:4, > > from drivers/scsi/ufs/ufshcd.h:60, > > from drivers/scsi/ufs/ufshcd.c:43: > > include/acpi/actypes.h:433:41: error: expected identifier before ‘(’ token > > #define FALSE (1 == 0) > > ^ > > drivers/scsi/ufs/unipro.h:203:2: note: in expansion of macro ‘FALSE’ > >FALSE = 0, > >^ > > > > This happens because the ACPI definitions of TRUE and FALSE conflict > > with local definitions in megaraid and enum declaration in ufs. > > > Mark, > > Thanks for pointing this out. Although, I would think that the > megaraid_sas_fp.c should have had the #ifndef to check before defining > the TRUE and FALSE as following. > > #ifndef TRUE > #define TRUE 1 > #endif > #ifndef FALSE > #define FALSE 0 > #endif > > This seems to be what other drivers are also doing. If this is okay, I > can send out a fix-up patch for the megaraid driver. > Yeah, or #undef them if defined so megaraid defines them as desired. And #undef if defined would work for unipro.h as well. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object
On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote:
> From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
> section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
> object to be specified for DMA-cabpable devices. Therefore, this patch
> specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
>
> In addition, to handle the case when _CCA is missing, arm64 would assign
> dummy_dma_ops to disable DMA capability of the device.
>
> Acked-by: Catalin Marinas
> Signed-off-by: Mark Salter
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/dma-mapping.h | 18 ++-
> arch/arm64/mm/dma-mapping.c | 92
>
> 3 files changed, 109 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 4269dba..95307b4 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1,5 +1,6 @@
> config ARM64
> def_bool y
> + select ACPI_CCA_REQUIRED if ACPI
> select ACPI_GENERIC_GSI if ACPI
> select ACPI_REDUCED_HARDWARE_ONLY if ACPI
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> diff --git a/arch/arm64/include/asm/dma-mapping.h
> b/arch/arm64/include/asm/dma-mapping.h
> index 9437e3d..f0d6d0b 100644
> --- a/arch/arm64/include/asm/dma-mapping.h
> +++ b/arch/arm64/include/asm/dma-mapping.h
> @@ -18,6 +18,7 @@
>
> #ifdef __KERNEL__
>
> +#include
> #include
> #include
>
^^^ This hunk causes build issues with a couple of drivers:
drivers/scsi/megaraid/megaraid_sas_fp.c:69:0: warning: "FALSE" redefined
[enabled by default]
#define FALSE 0
^
In file included from include/acpi/acpi.h:58:0,
from include/linux/acpi.h:37,
from ./arch/arm64/include/asm/dma-mapping.h:21,
from include/linux/dma-mapping.h:86,
from ./arch/arm64/include/asm/pci.h:7,
from include/linux/pci.h:1460,
from drivers/scsi/megaraid/megaraid_sas_fp.c:37:
include/acpi/actypes.h:433:0: note: this is the location of the previous
definition
#define FALSE (1 == 0)
^
In file included from include/acpi/acpi.h:58:0,
from include/linux/acpi.h:37,
from ./arch/arm64/include/asm/dma-mapping.h:21,
from include/linux/dma-mapping.h:86,
from include/scsi/scsi_cmnd.h:4,
from drivers/scsi/ufs/ufshcd.h:60,
from drivers/scsi/ufs/ufshcd.c:43:
include/acpi/actypes.h:433:41: error: expected identifier before ‘(’ token
#define FALSE (1 == 0)
^
drivers/scsi/ufs/unipro.h:203:2: note: in expansion of macro ‘FALSE’
FALSE = 0,
^
This happens because the ACPI definitions of TRUE and FALSE conflict
with local definitions in megaraid and enum declaration in ufs.
> @@ -28,13 +29,23 @@
>
> #define DMA_ERROR_CODE (~(dma_addr_t)0)
> extern struct dma_map_ops *dma_ops;
> +extern struct dma_map_ops dummy_dma_ops;
>
> static inline struct dma_map_ops *__generic_dma_ops(struct device *dev)
> {
> - if (unlikely(!dev) || !dev->archdata.dma_ops)
> + if (unlikely(!dev))
> return dma_ops;
> - else
> + else if (dev->archdata.dma_ops)
> return dev->archdata.dma_ops;
> + else if (acpi_disabled)
> + return dma_ops;
> +
> + /*
> + * When ACPI is enabled, if arch_set_dma_ops is not called,
> + * we will disable device DMA capability by setting it
> + * to dummy_dma_ops.
> + */
> + return &dummy_dma_ops;
> }
>
> static inline struct dma_map_ops *get_dma_ops(struct device *dev)
> @@ -48,6 +59,9 @@ static inline struct dma_map_ops *get_dma_ops(struct device
> *dev)
> static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64
> size,
> struct iommu_ops *iommu, bool coherent)
> {
> + if (!acpi_disabled && !dev->archdata.dma_ops)
> + dev->archdata.dma_ops = dma_ops;
> +
> dev->archdata.dma_coherent = coherent;
> }
> #define arch_setup_dma_ops arch_setup_dma_ops
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index ef7d112..6e6d6ad 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -415,6 +415,98 @@ out:
> return -ENOMEM;
> }
>
> +/
> + * The following APIs are for dummy DMA ops *
> + /
> +
> +static void *__dummy_alloc(struct device *dev
