* Re: net/dccp: dccp_create_openreq_child freed held lock
From: David Miller @ 2017-05-04 13:53 UTC (permalink / raw)
To: andreyknvl
Cc: acme, arnaldo.melo, dvyukov, gerrit, dccp, netdev, linux-kernel,
edumazet, xiyou.wangcong, syzkaller
In-Reply-To: <CAAeHK+wSrkrooaK=d6Od85hNNQbTSuPxe55DFFYWEuE5zSqmSw@mail.gmail.com>
From: Andrey Konovalov <andreyknvl@google.com>
Date: Thu, 4 May 2017 15:36:37 +0200
> On Wed, Mar 1, 2017 at 4:40 PM, Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
>> Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu:
>>> > Hello,
>>> >
>>> > I've got the following report while running syzkaller fuzzer on
>>> > 86292b33d4b79ee03e2f43ea0381ef85f077c760:
>>> >
>>> >
>>> > It seems that dccp_create_openreq_child needs to unlock the sock if
>>> > dccp_feat_activate_values fails.
>>>
>>> Yeah, can you please use the patch below, that mimics the error paths in
>>> sk_clone_new(), from where I think even the comment about it being a raw
>>
>> Argh, s/sk_clone_new()/sk_clone_lock()/g
>
> Hi Arnaldo,
>
> Could you send the patch?
>
> We haven't seen these reports since we applied it.
It isn't necessary in the current tree.
Arnaldo created a helper sk_free_unlock_clone() which handles this situation
properly, and calls it from dccp_create_openreq_child().
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Bjorn Helgaas @ 2017-05-04 13:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: alsa-devel, Heikki Krogerus, Liam Girdwood,
linux-pci@vger.kernel.org, Amir Goldstein, Jarkko Sakkinen,
Adrian Hunter, Benjamin Tissoires, Joerg Roedel,
linux-acpi@vger.kernel.org, tpmdd-devel, Ben Skeggs,
nouveau@lists.freedesktop.org, linux-mmc, Zhang Rui,
Borislav Petkov, Yisen Zhuang, Mathias Nyman, intel-gfx,
linux-input@vger.kernel.org
In-Reply-To: <20170504092151.88646-1-andriy.shevchenko@linux.intel.com>
On Thu, May 4, 2017 at 4:21 AM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Amir Goldstein <amir73il@gmail.com>
> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Felipe Balbi <balbi@kernel.org>
> Cc: Mathias Nyman <mathias.nyman@intel.com>
> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
For the drivers/pci parts:
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/acpi/acpi_extlog.c | 10 +++---
> drivers/acpi/bus.c | 29 ++--------------
> drivers/acpi/nfit/core.c | 40 +++++++++++-----------
> drivers/acpi/nfit/nfit.h | 3 +-
> drivers/acpi/utils.c | 4 +--
> drivers/char/tpm/tpm_crb.c | 9 +++--
> drivers/char/tpm/tpm_ppi.c | 20 +++++------
> drivers/gpu/drm/i915/intel_acpi.c | 14 +++-----
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 20 +++++------
> drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c | 9 +++--
> drivers/hid/i2c-hid/i2c-hid.c | 9 +++--
> drivers/iommu/dmar.c | 11 +++---
> drivers/mmc/host/sdhci-pci-core.c | 9 +++--
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 15 ++++----
> drivers/pci/pci-acpi.c | 11 +++---
> drivers/pci/pci-label.c | 4 +--
> drivers/thermal/int340x_thermal/int3400_thermal.c | 8 ++---
> drivers/usb/dwc3/dwc3-pci.c | 6 ++--
> drivers/usb/host/xhci-pci.c | 9 +++--
> drivers/usb/misc/ucsi.c | 2 +-
> drivers/usb/typec/typec_wcove.c | 4 +--
> include/acpi/acpi_bus.h | 9 ++---
> include/linux/acpi.h | 4 +--
> include/linux/pci-acpi.h | 2 +-
> sound/soc/intel/skylake/skl-nhlt.c | 7 ++--
> tools/testing/nvdimm/test/iomap.c | 2 +-
> tools/testing/nvdimm/test/nfit.c | 2 +-
> 27 files changed, 116 insertions(+), 156 deletions(-)
>
> diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
> index 502ea4dc2080..69d6140b6afa 100644
> --- a/drivers/acpi/acpi_extlog.c
> +++ b/drivers/acpi/acpi_extlog.c
> @@ -182,17 +182,17 @@ static int extlog_print(struct notifier_block *nb, unsigned long val,
>
> static bool __init extlog_get_l1addr(void)
> {
> - u8 uuid[16];
> + uuid_le uuid;
> acpi_handle handle;
> union acpi_object *obj;
>
> - acpi_str_to_uuid(extlog_dsm_uuid, uuid);
> -
> + if (uuid_le_to_bin(extlog_dsm_uuid, &uuid))
> + return false;
> if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
> return false;
> - if (!acpi_check_dsm(handle, uuid, EXTLOG_DSM_REV, 1 << EXTLOG_FN_ADDR))
> + if (!acpi_check_dsm(handle, &uuid, EXTLOG_DSM_REV, 1 << EXTLOG_FN_ADDR))
> return false;
> - obj = acpi_evaluate_dsm_typed(handle, uuid, EXTLOG_DSM_REV,
> + obj = acpi_evaluate_dsm_typed(handle, &uuid, EXTLOG_DSM_REV,
> EXTLOG_FN_ADDR, NULL, ACPI_TYPE_INTEGER);
> if (!obj) {
> return false;
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 784bda663d16..e8130a4873e9 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -196,42 +196,19 @@ static void acpi_print_osc_error(acpi_handle handle,
> pr_debug("\n");
> }
>
> -acpi_status acpi_str_to_uuid(char *str, u8 *uuid)
> -{
> - int i;
> - static int opc_map_to_uuid[16] = {6, 4, 2, 0, 11, 9, 16, 14, 19, 21,
> - 24, 26, 28, 30, 32, 34};
> -
> - if (strlen(str) != 36)
> - return AE_BAD_PARAMETER;
> - for (i = 0; i < 36; i++) {
> - if (i == 8 || i == 13 || i == 18 || i == 23) {
> - if (str[i] != '-')
> - return AE_BAD_PARAMETER;
> - } else if (!isxdigit(str[i]))
> - return AE_BAD_PARAMETER;
> - }
> - for (i = 0; i < 16; i++) {
> - uuid[i] = hex_to_bin(str[opc_map_to_uuid[i]]) << 4;
> - uuid[i] |= hex_to_bin(str[opc_map_to_uuid[i] + 1]);
> - }
> - return AE_OK;
> -}
> -EXPORT_SYMBOL_GPL(acpi_str_to_uuid);
> -
> acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
> {
> acpi_status status;
> struct acpi_object_list input;
> union acpi_object in_params[4];
> union acpi_object *out_obj;
> - u8 uuid[16];
> + uuid_le uuid;
> u32 errors;
> struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
>
> if (!context)
> return AE_ERROR;
> - if (ACPI_FAILURE(acpi_str_to_uuid(context->uuid_str, uuid)))
> + if (uuid_le_to_bin(context->uuid_str, &uuid))
> return AE_ERROR;
> context->ret.length = ACPI_ALLOCATE_BUFFER;
> context->ret.pointer = NULL;
> @@ -241,7 +218,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
> input.pointer = in_params;
> in_params[0].type = ACPI_TYPE_BUFFER;
> in_params[0].buffer.length = 16;
> - in_params[0].buffer.pointer = uuid;
> + in_params[0].buffer.pointer = (u8 *)&uuid;
> in_params[1].type = ACPI_TYPE_INTEGER;
> in_params[1].integer.value = context->rev;
> in_params[2].type = ACPI_TYPE_INTEGER;
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 0f7982a1caaf..bd3e45ede056 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -74,11 +74,11 @@ struct nfit_table_prev {
> struct list_head flushes;
> };
>
> -static u8 nfit_uuid[NFIT_UUID_MAX][16];
> +static uuid_le nfit_uuid[NFIT_UUID_MAX];
>
> -const u8 *to_nfit_uuid(enum nfit_uuids id)
> +const uuid_le *to_nfit_uuid(enum nfit_uuids id)
> {
> - return nfit_uuid[id];
> + return &nfit_uuid[id];
> }
> EXPORT_SYMBOL(to_nfit_uuid);
>
> @@ -207,7 +207,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
> u32 offset, fw_status = 0;
> acpi_handle handle;
> unsigned int func;
> - const u8 *uuid;
> + const uuid_le *uuid;
> int rc, i;
>
> func = cmd;
> @@ -394,7 +394,7 @@ int nfit_spa_type(struct acpi_nfit_system_address *spa)
> int i;
>
> for (i = 0; i < NFIT_UUID_MAX; i++)
> - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0)
> + if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le *)spa->range_guid))
> return i;
> return -1;
> }
> @@ -1400,7 +1400,7 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc,
> struct acpi_device *adev, *adev_dimm;
> struct device *dev = acpi_desc->dev;
> unsigned long dsm_mask;
> - const u8 *uuid;
> + const uuid_le *uuid = to_nfit_uuid(NFIT_DEV_DIMM);
> int i;
> int family = -1;
>
> @@ -1596,7 +1596,7 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc *acpi_desc)
> static void acpi_nfit_init_dsms(struct acpi_nfit_desc *acpi_desc)
> {
> struct nvdimm_bus_descriptor *nd_desc = &acpi_desc->nd_desc;
> - const u8 *uuid = to_nfit_uuid(NFIT_DEV_BUS);
> + const uuid_le *uuid = to_nfit_uuid(NFIT_DEV_BUS);
> struct acpi_device *adev;
> int i;
>
> @@ -3036,19 +3036,19 @@ static __init int nfit_init(void)
> BUILD_BUG_ON(sizeof(struct acpi_nfit_control_region) != 80);
> BUILD_BUG_ON(sizeof(struct acpi_nfit_data_region) != 40);
>
> - acpi_str_to_uuid(UUID_VOLATILE_MEMORY, nfit_uuid[NFIT_SPA_VOLATILE]);
> - acpi_str_to_uuid(UUID_PERSISTENT_MEMORY, nfit_uuid[NFIT_SPA_PM]);
> - acpi_str_to_uuid(UUID_CONTROL_REGION, nfit_uuid[NFIT_SPA_DCR]);
> - acpi_str_to_uuid(UUID_DATA_REGION, nfit_uuid[NFIT_SPA_BDW]);
> - acpi_str_to_uuid(UUID_VOLATILE_VIRTUAL_DISK, nfit_uuid[NFIT_SPA_VDISK]);
> - acpi_str_to_uuid(UUID_VOLATILE_VIRTUAL_CD, nfit_uuid[NFIT_SPA_VCD]);
> - acpi_str_to_uuid(UUID_PERSISTENT_VIRTUAL_DISK, nfit_uuid[NFIT_SPA_PDISK]);
> - acpi_str_to_uuid(UUID_PERSISTENT_VIRTUAL_CD, nfit_uuid[NFIT_SPA_PCD]);
> - acpi_str_to_uuid(UUID_NFIT_BUS, nfit_uuid[NFIT_DEV_BUS]);
> - acpi_str_to_uuid(UUID_NFIT_DIMM, nfit_uuid[NFIT_DEV_DIMM]);
> - acpi_str_to_uuid(UUID_NFIT_DIMM_N_HPE1, nfit_uuid[NFIT_DEV_DIMM_N_HPE1]);
> - acpi_str_to_uuid(UUID_NFIT_DIMM_N_HPE2, nfit_uuid[NFIT_DEV_DIMM_N_HPE2]);
> - acpi_str_to_uuid(UUID_NFIT_DIMM_N_MSFT, nfit_uuid[NFIT_DEV_DIMM_N_MSFT]);
> + uuid_le_to_bin(UUID_VOLATILE_MEMORY, &nfit_uuid[NFIT_SPA_VOLATILE]);
> + uuid_le_to_bin(UUID_PERSISTENT_MEMORY, &nfit_uuid[NFIT_SPA_PM]);
> + uuid_le_to_bin(UUID_CONTROL_REGION, &nfit_uuid[NFIT_SPA_DCR]);
> + uuid_le_to_bin(UUID_DATA_REGION, &nfit_uuid[NFIT_SPA_BDW]);
> + uuid_le_to_bin(UUID_VOLATILE_VIRTUAL_DISK, &nfit_uuid[NFIT_SPA_VDISK]);
> + uuid_le_to_bin(UUID_VOLATILE_VIRTUAL_CD, &nfit_uuid[NFIT_SPA_VCD]);
> + uuid_le_to_bin(UUID_PERSISTENT_VIRTUAL_DISK, &nfit_uuid[NFIT_SPA_PDISK]);
> + uuid_le_to_bin(UUID_PERSISTENT_VIRTUAL_CD, &nfit_uuid[NFIT_SPA_PCD]);
> + uuid_le_to_bin(UUID_NFIT_BUS, &nfit_uuid[NFIT_DEV_BUS]);
> + uuid_le_to_bin(UUID_NFIT_DIMM, &nfit_uuid[NFIT_DEV_DIMM]);
> + uuid_le_to_bin(UUID_NFIT_DIMM_N_HPE1, &nfit_uuid[NFIT_DEV_DIMM_N_HPE1]);
> + uuid_le_to_bin(UUID_NFIT_DIMM_N_HPE2, &nfit_uuid[NFIT_DEV_DIMM_N_HPE2]);
> + uuid_le_to_bin(UUID_NFIT_DIMM_N_MSFT, &nfit_uuid[NFIT_DEV_DIMM_N_MSFT]);
>
> nfit_wq = create_singlethread_workqueue("nfit");
> if (!nfit_wq)
> diff --git a/drivers/acpi/nfit/nfit.h b/drivers/acpi/nfit/nfit.h
> index 58fb7d68e04a..2f233b28709f 100644
> --- a/drivers/acpi/nfit/nfit.h
> +++ b/drivers/acpi/nfit/nfit.h
> @@ -18,7 +18,6 @@
> #include <linux/libnvdimm.h>
> #include <linux/ndctl.h>
> #include <linux/types.h>
> -#include <linux/uuid.h>
> #include <linux/acpi.h>
> #include <acpi/acuuid.h>
>
> @@ -237,7 +236,7 @@ static inline struct acpi_nfit_desc *to_acpi_desc(
> return container_of(nd_desc, struct acpi_nfit_desc, nd_desc);
> }
>
> -const u8 *to_nfit_uuid(enum nfit_uuids id);
> +const uuid_le *to_nfit_uuid(enum nfit_uuids id);
> int acpi_nfit_init(struct acpi_nfit_desc *acpi_desc, void *nfit, acpi_size sz);
> void acpi_nfit_shutdown(void *data);
> void __acpi_nfit_notify(struct device *dev, acpi_handle handle, u32 event);
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 27d0dcfcf47d..bbe8a950e508 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -625,7 +625,7 @@ acpi_status acpi_evaluate_lck(acpi_handle handle, int lock)
> * some old BIOSes do expect a buffer or an integer etc.
> */
> union acpi_object *
> -acpi_evaluate_dsm(acpi_handle handle, const u8 *uuid, u64 rev, u64 func,
> +acpi_evaluate_dsm(acpi_handle handle, const uuid_le *uuid, u64 rev, u64 func,
> union acpi_object *argv4)
> {
> acpi_status ret;
> @@ -674,7 +674,7 @@ EXPORT_SYMBOL(acpi_evaluate_dsm);
> * functions. Currently only support 64 functions at maximum, should be
> * enough for now.
> */
> -bool acpi_check_dsm(acpi_handle handle, const u8 *uuid, u64 rev, u64 funcs)
> +bool acpi_check_dsm(acpi_handle handle, const uuid_le *uuid, u64 rev, u64 funcs)
> {
> int i;
> u64 mask = 0;
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index b917b9d5f710..f789f7e5a17d 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -27,10 +27,9 @@
>
> #define ACPI_SIG_TPM2 "TPM2"
>
> -static const u8 CRB_ACPI_START_UUID[] = {
> - /* 0000 */ 0xAB, 0x6C, 0xBF, 0x6B, 0x63, 0x54, 0x14, 0x47,
> - /* 0008 */ 0xB7, 0xCD, 0xF0, 0x20, 0x3C, 0x03, 0x68, 0xD4
> -};
> +static const uuid_le crb_acpi_start_uuid =
> + UUID_LE(0x6BBF6CAB, 0x5463, 0x4714,
> + 0xB7, 0xCD, 0xF0, 0x20, 0x3C, 0x03, 0x68, 0xD4);
>
> enum crb_defaults {
> CRB_ACPI_START_REVISION_ID = 1,
> @@ -266,7 +265,7 @@ static int crb_do_acpi_start(struct tpm_chip *chip)
> int rc;
>
> obj = acpi_evaluate_dsm(chip->acpi_dev_handle,
> - CRB_ACPI_START_UUID,
> + &crb_acpi_start_uuid,
> CRB_ACPI_START_REVISION_ID,
> CRB_ACPI_START_INDEX,
> NULL);
> diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
> index 692a2c6ae036..7cf682426361 100644
> --- a/drivers/char/tpm/tpm_ppi.c
> +++ b/drivers/char/tpm/tpm_ppi.c
> @@ -32,20 +32,16 @@
> #define PPI_VS_REQ_START 128
> #define PPI_VS_REQ_END 255
>
> -static const u8 tpm_ppi_uuid[] = {
> - 0xA6, 0xFA, 0xDD, 0x3D,
> - 0x1B, 0x36,
> - 0xB4, 0x4E,
> - 0xA4, 0x24,
> - 0x8D, 0x10, 0x08, 0x9D, 0x16, 0x53
> -};
> +static const uuid_le tpm_ppi_uuid =
> + UUID_LE(0x3DDDFAA6, 0x361B, 0x4EB4,
> + 0xA4, 0x24, 0x8D, 0x10, 0x08, 0x9D, 0x16, 0x53);
>
> static inline union acpi_object *
> tpm_eval_dsm(acpi_handle ppi_handle, int func, acpi_object_type type,
> union acpi_object *argv4)
> {
> BUG_ON(!ppi_handle);
> - return acpi_evaluate_dsm_typed(ppi_handle, tpm_ppi_uuid,
> + return acpi_evaluate_dsm_typed(ppi_handle, &tpm_ppi_uuid,
> TPM_PPI_REVISION_ID,
> func, argv4, type);
> }
> @@ -107,7 +103,7 @@ static ssize_t tpm_store_ppi_request(struct device *dev,
> * is updated with function index from SUBREQ to SUBREQ2 since PPI
> * version 1.1
> */
> - if (acpi_check_dsm(chip->acpi_dev_handle, tpm_ppi_uuid,
> + if (acpi_check_dsm(chip->acpi_dev_handle, &tpm_ppi_uuid,
> TPM_PPI_REVISION_ID, 1 << TPM_PPI_FN_SUBREQ2))
> func = TPM_PPI_FN_SUBREQ2;
>
> @@ -268,7 +264,7 @@ static ssize_t show_ppi_operations(acpi_handle dev_handle, char *buf, u32 start,
> "User not required",
> };
>
> - if (!acpi_check_dsm(dev_handle, tpm_ppi_uuid, TPM_PPI_REVISION_ID,
> + if (!acpi_check_dsm(dev_handle, &tpm_ppi_uuid, TPM_PPI_REVISION_ID,
> 1 << TPM_PPI_FN_GETOPR))
> return -EPERM;
>
> @@ -341,12 +337,12 @@ void tpm_add_ppi(struct tpm_chip *chip)
> if (!chip->acpi_dev_handle)
> return;
>
> - if (!acpi_check_dsm(chip->acpi_dev_handle, tpm_ppi_uuid,
> + if (!acpi_check_dsm(chip->acpi_dev_handle, &tpm_ppi_uuid,
> TPM_PPI_REVISION_ID, 1 << TPM_PPI_FN_VERSION))
> return;
>
> /* Cache PPI version string. */
> - obj = acpi_evaluate_dsm_typed(chip->acpi_dev_handle, tpm_ppi_uuid,
> + obj = acpi_evaluate_dsm_typed(chip->acpi_dev_handle, &tpm_ppi_uuid,
> TPM_PPI_REVISION_ID, TPM_PPI_FN_VERSION,
> NULL, ACPI_TYPE_STRING);
> if (obj) {
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
> index eb638a1e69d2..72bfe6ceadf8 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -15,13 +15,9 @@ static struct intel_dsm_priv {
> acpi_handle dhandle;
> } intel_dsm_priv;
>
> -static const u8 intel_dsm_guid[] = {
> - 0xd3, 0x73, 0xd8, 0x7e,
> - 0xd0, 0xc2,
> - 0x4f, 0x4e,
> - 0xa8, 0x54,
> - 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
> -};
> +static const uuid_le intel_dsm_guid =
> + UUID_LE(0x7ed873d3, 0xc2d0, 0x4e4f,
> + 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
>
> static char *intel_dsm_port_name(u8 id)
> {
> @@ -80,7 +76,7 @@ static void intel_dsm_platform_mux_info(void)
> int i;
> union acpi_object *pkg, *connector_count;
>
> - pkg = acpi_evaluate_dsm_typed(intel_dsm_priv.dhandle, intel_dsm_guid,
> + pkg = acpi_evaluate_dsm_typed(intel_dsm_priv.dhandle, &intel_dsm_guid,
> INTEL_DSM_REVISION_ID, INTEL_DSM_FN_PLATFORM_MUX_INFO,
> NULL, ACPI_TYPE_PACKAGE);
> if (!pkg) {
> @@ -118,7 +114,7 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
> if (!dhandle)
> return false;
>
> - if (!acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
> + if (!acpi_check_dsm(dhandle, &intel_dsm_guid, INTEL_DSM_REVISION_ID,
> 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
> DRM_DEBUG_KMS("no _DSM method for intel device\n");
> return false;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index 39468c218027..faea23276d4a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -60,15 +60,13 @@ bool nouveau_is_v1_dsm(void) {
> }
>
> #ifdef CONFIG_VGA_SWITCHEROO
> -static const char nouveau_dsm_muid[] = {
> - 0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
> - 0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
> -};
> +static const uuid_le nouveau_dsm_muid =
> + UUID_LE(0x9D95A0A0, 0x0060, 0x4D48,
> + 0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4);
>
> -static const char nouveau_op_dsm_muid[] = {
> - 0xF8, 0xD8, 0x86, 0xA4, 0xDA, 0x0B, 0x1B, 0x47,
> - 0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
> -};
> +static const uuid_le nouveau_op_dsm_muid =
> + UUID_LE(0xA486D8F8, 0x0BDA, 0x471B,
> + 0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0);
>
> static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t *result)
> {
> @@ -86,7 +84,7 @@ static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t *
> args_buff[i] = (arg >> i * 8) & 0xFF;
>
> *result = 0;
> - obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid, 0x00000100,
> + obj = acpi_evaluate_dsm_typed(handle, &nouveau_op_dsm_muid, 0x00000100,
> func, &argv4, ACPI_TYPE_BUFFER);
> if (!obj) {
> acpi_handle_info(handle, "failed to evaluate _DSM\n");
> @@ -138,7 +136,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int arg)
> .integer.value = arg,
> };
>
> - obj = acpi_evaluate_dsm_typed(handle, nouveau_dsm_muid, 0x00000102,
> + obj = acpi_evaluate_dsm_typed(handle, &nouveau_dsm_muid, 0x00000102,
> func, &argv4, ACPI_TYPE_INTEGER);
> if (!obj) {
> acpi_handle_info(handle, "failed to evaluate _DSM\n");
> @@ -259,7 +257,7 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev, acpi_handle *dhandle_out
> if (!acpi_has_method(dhandle, "_DSM"))
> return;
>
> - supports_mux = acpi_check_dsm(dhandle, nouveau_dsm_muid, 0x00000102,
> + supports_mux = acpi_check_dsm(dhandle, &nouveau_dsm_muid, 0x00000102,
> 1 << NOUVEAU_DSM_POWER);
> optimus_funcs = nouveau_dsm_get_optimus_functions(dhandle);
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c
> index e3e2f5e83815..cc95b8150a86 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/base.c
> @@ -81,10 +81,9 @@ mxm_shadow_dsm(struct nvkm_mxm *mxm, u8 version)
> {
> struct nvkm_subdev *subdev = &mxm->subdev;
> struct nvkm_device *device = subdev->device;
> - static char muid[] = {
> - 0x00, 0xA4, 0x04, 0x40, 0x7D, 0x91, 0xF2, 0x4C,
> - 0xB8, 0x9C, 0x79, 0xB6, 0x2F, 0xD5, 0x56, 0x65
> - };
> + static uuid_le muid =
> + UUID_LE(0x4004A400, 0x917D, 0x4CF2,
> + 0xB8, 0x9C, 0x79, 0xB6, 0x2F, 0xD5, 0x56, 0x65);
> u32 mxms_args[] = { 0x00000000 };
> union acpi_object argv4 = {
> .buffer.type = ACPI_TYPE_BUFFER,
> @@ -105,7 +104,7 @@ mxm_shadow_dsm(struct nvkm_mxm *mxm, u8 version)
> * unless you pass in exactly the version it supports..
> */
> rev = (version & 0xf0) << 4 | (version & 0x0f);
> - obj = acpi_evaluate_dsm(handle, muid, rev, 0x00000010, &argv4);
> + obj = acpi_evaluate_dsm(handle, &muid, rev, 0x00000010, &argv4);
> if (!obj) {
> nvkm_debug(subdev, "DSM MXMS failed\n");
> return false;
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 8daa8ce64ebb..f83bd717cdd5 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -872,10 +872,9 @@ static int i2c_hid_fetch_hid_descriptor(struct i2c_hid *ihid)
> static int i2c_hid_acpi_pdata(struct i2c_client *client,
> struct i2c_hid_platform_data *pdata)
> {
> - static u8 i2c_hid_guid[] = {
> - 0xF7, 0xF6, 0xDF, 0x3C, 0x67, 0x42, 0x55, 0x45,
> - 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE,
> - };
> + static uuid_le i2c_hid_guid =
> + UUID_LE(0x3CDFF6F7, 0x4267, 0x4555,
> + 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
> union acpi_object *obj;
> struct acpi_device *adev;
> acpi_handle handle;
> @@ -884,7 +883,7 @@ static int i2c_hid_acpi_pdata(struct i2c_client *client,
> if (!handle || acpi_bus_get_device(handle, &adev))
> return -ENODEV;
>
> - obj = acpi_evaluate_dsm_typed(handle, i2c_hid_guid, 1, 1, NULL,
> + obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
> ACPI_TYPE_INTEGER);
> if (!obj) {
> dev_err(&client->dev, "device _DSM execution failed\n");
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index cbf7763d8091..420d51b286ad 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1808,10 +1808,9 @@ IOMMU_INIT_POST(detect_intel_iommu);
> * for Directed-IO Architecture Specifiction, Rev 2.2, Section 8.8
> * "Remapping Hardware Unit Hot Plug".
> */
> -static u8 dmar_hp_uuid[] = {
> - /* 0000 */ 0xA6, 0xA3, 0xC1, 0xD8, 0x9B, 0xBE, 0x9B, 0x4C,
> - /* 0008 */ 0x91, 0xBF, 0xC3, 0xCB, 0x81, 0xFC, 0x5D, 0xAF
> -};
> +static uuid_le dmar_hp_uuid =
> + UUID_LE(0xD8C1A3A6, 0xBE9B, 0x4C9B,
> + 0x91, 0xBF, 0xC3, 0xCB, 0x81, 0xFC, 0x5D, 0xAF);
>
> /*
> * Currently there's only one revision and BIOS will not check the revision id,
> @@ -1824,7 +1823,7 @@ static u8 dmar_hp_uuid[] = {
>
> static inline bool dmar_detect_dsm(acpi_handle handle, int func)
> {
> - return acpi_check_dsm(handle, dmar_hp_uuid, DMAR_DSM_REV_ID, 1 << func);
> + return acpi_check_dsm(handle, &dmar_hp_uuid, DMAR_DSM_REV_ID, 1 << func);
> }
>
> static int dmar_walk_dsm_resource(acpi_handle handle, int func,
> @@ -1843,7 +1842,7 @@ static int dmar_walk_dsm_resource(acpi_handle handle, int func,
> if (!dmar_detect_dsm(handle, func))
> return 0;
>
> - obj = acpi_evaluate_dsm_typed(handle, dmar_hp_uuid, DMAR_DSM_REV_ID,
> + obj = acpi_evaluate_dsm_typed(handle, &dmar_hp_uuid, DMAR_DSM_REV_ID,
> func, NULL, ACPI_TYPE_BUFFER);
> if (!obj)
> return -ENODEV;
> diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
> index 92fc3f7c538d..262b8c320d7c 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -404,10 +404,9 @@ struct intel_host {
> bool d3_retune;
> };
>
> -const u8 intel_dsm_uuid[] = {
> - 0xA5, 0x3E, 0xC1, 0xF6, 0xCD, 0x65, 0x1F, 0x46,
> - 0xAB, 0x7A, 0x29, 0xF7, 0xE8, 0xD5, 0xBD, 0x61,
> -};
> +const uuid_le intel_dsm_uuid =
> + UUID_LE(0xF6C13EA5, 0x65CD, 0x461F,
> + 0xAB, 0x7A, 0x29, 0xF7, 0xE8, 0xD5, 0xBD, 0x61);
>
> static int __intel_dsm(struct intel_host *intel_host, struct device *dev,
> unsigned int fn, u32 *result)
> @@ -416,7 +415,7 @@ static int __intel_dsm(struct intel_host *intel_host, struct device *dev,
> int err = 0;
> size_t len;
>
> - obj = acpi_evaluate_dsm(ACPI_HANDLE(dev), intel_dsm_uuid, 0, fn, NULL);
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(dev), &intel_dsm_uuid, 0, fn, NULL);
> if (!obj)
> return -EOPNOTSUPP;
>
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> index e13aa064a8e9..02842fe7f1d0 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> @@ -29,10 +29,9 @@ enum _dsm_rst_type {
> HNS_ROCE_RESET_FUNC = 0x7,
> };
>
> -const u8 hns_dsaf_acpi_dsm_uuid[] = {
> - 0x1A, 0xAA, 0x85, 0x1A, 0x93, 0xE2, 0x5E, 0x41,
> - 0x8E, 0x28, 0x8D, 0x69, 0x0A, 0x0F, 0x82, 0x0A
> -};
> +const uuid_le hns_dsaf_acpi_dsm_uuid =
> + UUID_LE(0x1A85AA1A, 0xE293, 0x415E,
> + 0x8E, 0x28, 0x8D, 0x69, 0x0A, 0x0F, 0x82, 0x0A);
>
> static void dsaf_write_sub(struct dsaf_device *dsaf_dev, u32 reg, u32 val)
> {
> @@ -151,7 +150,7 @@ static void hns_dsaf_acpi_srst_by_port(struct dsaf_device *dsaf_dev, u8 op_type,
> argv4.package.elements = obj_args;
>
> obj = acpi_evaluate_dsm(ACPI_HANDLE(dsaf_dev->dev),
> - hns_dsaf_acpi_dsm_uuid, 0, op_type, &argv4);
> + &hns_dsaf_acpi_dsm_uuid, 0, op_type, &argv4);
> if (!obj) {
> dev_warn(dsaf_dev->dev, "reset port_type%d port%d fail!",
> port_type, port);
> @@ -434,7 +433,7 @@ static phy_interface_t hns_mac_get_phy_if_acpi(struct hns_mac_cb *mac_cb)
> argv4.package.elements = &obj_args,
>
> obj = acpi_evaluate_dsm(ACPI_HANDLE(mac_cb->dev),
> - hns_dsaf_acpi_dsm_uuid, 0,
> + &hns_dsaf_acpi_dsm_uuid, 0,
> HNS_OP_GET_PORT_TYPE_FUNC, &argv4);
>
> if (!obj || obj->type != ACPI_TYPE_INTEGER)
> @@ -474,7 +473,7 @@ int hns_mac_get_sfp_prsnt_acpi(struct hns_mac_cb *mac_cb, int *sfp_prsnt)
> argv4.package.elements = &obj_args,
>
> obj = acpi_evaluate_dsm(ACPI_HANDLE(mac_cb->dev),
> - hns_dsaf_acpi_dsm_uuid, 0,
> + &hns_dsaf_acpi_dsm_uuid, 0,
> HNS_OP_GET_SFP_STAT_FUNC, &argv4);
>
> if (!obj || obj->type != ACPI_TYPE_INTEGER)
> @@ -565,7 +564,7 @@ hns_mac_config_sds_loopback_acpi(struct hns_mac_cb *mac_cb, bool en)
> argv4.package.elements = obj_args;
>
> obj = acpi_evaluate_dsm(ACPI_HANDLE(mac_cb->dsaf_dev->dev),
> - hns_dsaf_acpi_dsm_uuid, 0,
> + &hns_dsaf_acpi_dsm_uuid, 0,
> HNS_OP_SERDES_LP_FUNC, &argv4);
> if (!obj) {
> dev_warn(mac_cb->dsaf_dev->dev, "set port%d serdes lp fail!",
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index 001860361434..eb612123e0dd 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -24,10 +24,9 @@
> * The UUID is defined in the PCI Firmware Specification available here:
> * https://www.pcisig.com/members/downloads/pcifw_r3_1_13Dec10.pdf
> */
> -const u8 pci_acpi_dsm_uuid[] = {
> - 0xd0, 0x37, 0xc9, 0xe5, 0x53, 0x35, 0x7a, 0x4d,
> - 0x91, 0x17, 0xea, 0x4d, 0x19, 0xc3, 0x43, 0x4d
> -};
> +const uuid_le pci_acpi_dsm_uuid =
> + UUID_LE(0xe5c937d0, 0x3553, 0x4d7a,
> + 0x91, 0x17, 0xea, 0x4d, 0x19, 0xc3, 0x43, 0x4d);
>
> #if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_ARM64)
> static int acpi_get_rc_addr(struct acpi_device *adev, struct resource *res)
> @@ -680,7 +679,7 @@ void acpi_pci_add_bus(struct pci_bus *bus)
> if (!pci_is_root_bus(bus))
> return;
>
> - obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), pci_acpi_dsm_uuid, 3,
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), &pci_acpi_dsm_uuid, 3,
> RESET_DELAY_DSM, NULL);
> if (!obj)
> return;
> @@ -745,7 +744,7 @@ static void pci_acpi_optimize_delay(struct pci_dev *pdev,
> if (bridge->ignore_reset_delay)
> pdev->d3cold_delay = 0;
>
> - obj = acpi_evaluate_dsm(handle, pci_acpi_dsm_uuid, 3,
> + obj = acpi_evaluate_dsm(handle, &pci_acpi_dsm_uuid, 3,
> FUNCTION_DELAY_DSM, NULL);
> if (!obj)
> return;
> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
> index 51357377efbc..a2c04229f1dc 100644
> --- a/drivers/pci/pci-label.c
> +++ b/drivers/pci/pci-label.c
> @@ -172,7 +172,7 @@ static int dsm_get_label(struct device *dev, char *buf,
> if (!handle)
> return -1;
>
> - obj = acpi_evaluate_dsm(handle, pci_acpi_dsm_uuid, 0x2,
> + obj = acpi_evaluate_dsm(handle, &pci_acpi_dsm_uuid, 0x2,
> DEVICE_LABEL_DSM, NULL);
> if (!obj)
> return -1;
> @@ -212,7 +212,7 @@ static bool device_has_dsm(struct device *dev)
> if (!handle)
> return false;
>
> - return !!acpi_check_dsm(handle, pci_acpi_dsm_uuid, 0x2,
> + return !!acpi_check_dsm(handle, &pci_acpi_dsm_uuid, 0x2,
> 1 << DEVICE_LABEL_DSM);
> }
>
> diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c b/drivers/thermal/int340x_thermal/int3400_thermal.c
> index 9413c4abf0b9..c0eb3bb19b23 100644
> --- a/drivers/thermal/int340x_thermal/int3400_thermal.c
> +++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
> @@ -23,7 +23,7 @@ enum int3400_thermal_uuid {
> INT3400_THERMAL_MAXIMUM_UUID,
> };
>
> -static u8 *int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
> +static const char *int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
> "42A441D6-AE6A-462b-A84B-4A8CE79027D3",
> "3A95C389-E4B8-4629-A526-C52C88626BAE",
> "97C68AE7-15FA-499c-B8C9-5DA81D606E0A",
> @@ -141,10 +141,10 @@ static int int3400_thermal_get_uuids(struct int3400_thermal_priv *priv)
> }
>
> for (j = 0; j < INT3400_THERMAL_MAXIMUM_UUID; j++) {
> - u8 uuid[16];
> + uuid_le u;
>
> - acpi_str_to_uuid(int3400_thermal_uuids[j], uuid);
> - if (!strncmp(uuid, objb->buffer.pointer, 16)) {
> + uuid_le_to_bin(int3400_thermal_uuids[j], &u);
> + if (!uuid_le_cmp(*(uuid_le *)objb->buffer.pointer), u) {
> priv->uuid_bitmap |= (1 << j);
> break;
> }
> diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> index a15ec71d0423..6b5284ec76df 100644
> --- a/drivers/usb/dwc3/dwc3-pci.c
> +++ b/drivers/usb/dwc3/dwc3-pci.c
> @@ -56,7 +56,7 @@ struct dwc3_pci {
> struct platform_device *dwc3;
> struct pci_dev *pci;
>
> - u8 uuid[16];
> + uuid_le uuid;
>
> unsigned int has_dsm_for_pm:1;
> };
> @@ -118,7 +118,7 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
>
> if (pdev->device == PCI_DEVICE_ID_INTEL_BXT ||
> pdev->device == PCI_DEVICE_ID_INTEL_BXT_M) {
> - acpi_str_to_uuid(PCI_INTEL_BXT_DSM_UUID, dwc->uuid);
> + uuid_le_to_bin(PCI_INTEL_BXT_DSM_UUID, &dwc->uuid);
> dwc->has_dsm_for_pm = true;
> }
>
> @@ -288,7 +288,7 @@ static int dwc3_pci_dsm(struct dwc3_pci *dwc, int param)
> tmp.type = ACPI_TYPE_INTEGER;
> tmp.integer.value = param;
>
> - obj = acpi_evaluate_dsm(ACPI_HANDLE(&dwc->pci->dev), dwc->uuid,
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(&dwc->pci->dev), &dwc->uuid,
> 1, PCI_INTEL_BXT_FUNC_PMU_PWR, &argv4);
> if (!obj) {
> dev_err(&dwc->pci->dev, "failed to evaluate _DSM\n");
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 7b86508ac8cf..93b4f0de9418 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -210,13 +210,12 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
> #ifdef CONFIG_ACPI
> static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
> {
> - static const u8 intel_dsm_uuid[] = {
> - 0xb7, 0x0c, 0x34, 0xac, 0x01, 0xe9, 0xbf, 0x45,
> - 0xb7, 0xe6, 0x2b, 0x34, 0xec, 0x93, 0x1e, 0x23,
> - };
> + static const uuid_le intel_dsm_uuid =
> + UUID_LE(0xac340cb7, 0xe901, 0x45bf,
> + 0xb7, 0xe6, 0x2b, 0x34, 0xec, 0x93, 0x1e, 0x23);
> union acpi_object *obj;
>
> - obj = acpi_evaluate_dsm(ACPI_HANDLE(&dev->dev), intel_dsm_uuid, 3, 1,
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(&dev->dev), &intel_dsm_uuid, 3, 1,
> NULL);
> ACPI_FREE(obj);
> }
> diff --git a/drivers/usb/misc/ucsi.c b/drivers/usb/misc/ucsi.c
> index 07397bddefa3..49e32ffbe59f 100644
> --- a/drivers/usb/misc/ucsi.c
> +++ b/drivers/usb/misc/ucsi.c
> @@ -61,7 +61,7 @@ static int ucsi_acpi_cmd(struct ucsi *ucsi, struct ucsi_control *ctrl)
>
> ucsi->data->ctrl.raw_cmd = ctrl->raw_cmd;
>
> - obj = acpi_evaluate_dsm(ACPI_HANDLE(ucsi->dev), uuid.b, 1, 1, NULL);
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(ucsi->dev), &uuid, 1, 1, NULL);
> if (!obj) {
> dev_err(ucsi->dev, "%s: failed to evaluate _DSM\n", __func__);
> return -EIO;
> diff --git a/drivers/usb/typec/typec_wcove.c b/drivers/usb/typec/typec_wcove.c
> index d5a7b21fa3f1..5ce93e0a15ca 100644
> --- a/drivers/usb/typec/typec_wcove.c
> +++ b/drivers/usb/typec/typec_wcove.c
> @@ -118,7 +118,7 @@ static int wcove_typec_func(struct wcove_typec *wcove,
> tmp.type = ACPI_TYPE_INTEGER;
> tmp.integer.value = param;
>
> - obj = acpi_evaluate_dsm(ACPI_HANDLE(wcove->dev), uuid.b, 1, func,
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(wcove->dev), &uuid, 1, func,
> &argv4);
> if (!obj) {
> dev_err(wcove->dev, "%s: failed to evaluate _DSM\n", __func__);
> @@ -314,7 +314,7 @@ static int wcove_typec_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - if (!acpi_check_dsm(ACPI_HANDLE(&pdev->dev), uuid.b, 0, 0x1f)) {
> + if (!acpi_check_dsm(ACPI_HANDLE(&pdev->dev), &uuid, 0, 0x1f)) {
> dev_err(&pdev->dev, "Missing _DSM functions\n");
> return -ENODEV;
> }
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 197f3fffc9a7..0682942d6a76 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -61,13 +61,14 @@ bool acpi_ata_match(acpi_handle handle);
> bool acpi_bay_match(acpi_handle handle);
> bool acpi_dock_match(acpi_handle handle);
>
> -bool acpi_check_dsm(acpi_handle handle, const u8 *uuid, u64 rev, u64 funcs);
> -union acpi_object *acpi_evaluate_dsm(acpi_handle handle, const u8 *uuid,
> +bool acpi_check_dsm(acpi_handle handle, const uuid_le *uuid, u64 rev, u64 funcs);
> +union acpi_object *acpi_evaluate_dsm(acpi_handle handle, const uuid_le *uuid,
> u64 rev, u64 func, union acpi_object *argv4);
>
> static inline union acpi_object *
> -acpi_evaluate_dsm_typed(acpi_handle handle, const u8 *uuid, u64 rev, u64 func,
> - union acpi_object *argv4, acpi_object_type type)
> +acpi_evaluate_dsm_typed(acpi_handle handle, const uuid_le *uuid, u64 rev,
> + u64 func, union acpi_object *argv4,
> + acpi_object_type type)
> {
> union acpi_object *obj;
>
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 137e4a3d89c5..66d135003780 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -39,6 +39,7 @@
> #include <linux/dynamic_debug.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> +#include <linux/uuid.h>
>
> #include <acpi/acpi_bus.h>
> #include <acpi/acpi_drivers.h>
> @@ -457,7 +458,6 @@ struct acpi_osc_context {
> struct acpi_buffer ret; /* free by caller if success */
> };
>
> -acpi_status acpi_str_to_uuid(char *str, u8 *uuid);
> acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
>
> /* Indexes into _OSC Capabilities Buffer (DWORDs 2 & 3 are device-specific) */
> @@ -741,7 +741,7 @@ static inline bool acpi_driver_match_device(struct device *dev,
> }
>
> static inline union acpi_object *acpi_evaluate_dsm(acpi_handle handle,
> - const u8 *uuid,
> + const uuid_le *uuid,
> int rev, int func,
> union acpi_object *argv4)
> {
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 7a4e83a8c89c..917a6ad0f24d 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -105,7 +105,7 @@ static inline void acpiphp_remove_slots(struct pci_bus *bus) { }
> static inline void acpiphp_check_host_bridge(struct acpi_device *adev) { }
> #endif
>
> -extern const u8 pci_acpi_dsm_uuid[];
> +extern const uuid_le pci_acpi_dsm_uuid;
> #define DEVICE_LABEL_DSM 0x07
> #define RESET_DELAY_DSM 0x08
> #define FUNCTION_DELAY_DSM 0x09
> diff --git a/sound/soc/intel/skylake/skl-nhlt.c b/sound/soc/intel/skylake/skl-nhlt.c
> index e3f06672fd6d..b95f659dced5 100644
> --- a/sound/soc/intel/skylake/skl-nhlt.c
> +++ b/sound/soc/intel/skylake/skl-nhlt.c
> @@ -21,8 +21,9 @@
> #include "skl.h"
>
> /* Unique identification for getting NHLT blobs */
> -static u8 OSC_UUID[16] = {0x6E, 0x88, 0x9F, 0xA6, 0xEB, 0x6C, 0x94, 0x45,
> - 0xA4, 0x1F, 0x7B, 0x5D, 0xCE, 0x24, 0xC5, 0x53};
> +static uuid_le osc_uuid =
> + UUID_LE(0xA69F886E, 0x6CEB, 0x4594,
> + 0xA4, 0x1F, 0x7B, 0x5D, 0xCE, 0x24, 0xC5, 0x53);
>
> struct nhlt_acpi_table *skl_nhlt_init(struct device *dev)
> {
> @@ -37,7 +38,7 @@ struct nhlt_acpi_table *skl_nhlt_init(struct device *dev)
> return NULL;
> }
>
> - obj = acpi_evaluate_dsm(handle, OSC_UUID, 1, 1, NULL);
> + obj = acpi_evaluate_dsm(handle, &osc_uuid, 1, 1, NULL);
> if (obj && obj->type == ACPI_TYPE_BUFFER) {
> nhlt_ptr = (struct nhlt_resource_desc *)obj->buffer.pointer;
> nhlt_table = (struct nhlt_acpi_table *)
> diff --git a/tools/testing/nvdimm/test/iomap.c b/tools/testing/nvdimm/test/iomap.c
> index 64cae1a5deff..f190f22c53dd 100644
> --- a/tools/testing/nvdimm/test/iomap.c
> +++ b/tools/testing/nvdimm/test/iomap.c
> @@ -370,7 +370,7 @@ acpi_status __wrap_acpi_evaluate_object(acpi_handle handle, acpi_string path,
> }
> EXPORT_SYMBOL(__wrap_acpi_evaluate_object);
>
> -union acpi_object * __wrap_acpi_evaluate_dsm(acpi_handle handle, const u8 *uuid,
> +union acpi_object * __wrap_acpi_evaluate_dsm(acpi_handle handle, const uuid_le *uuid,
> u64 rev, u64 func, union acpi_object *argv4)
> {
> union acpi_object *obj = ERR_PTR(-ENXIO);
> diff --git a/tools/testing/nvdimm/test/nfit.c b/tools/testing/nvdimm/test/nfit.c
> index c2187178fb13..145f6ee0234f 100644
> --- a/tools/testing/nvdimm/test/nfit.c
> +++ b/tools/testing/nvdimm/test/nfit.c
> @@ -1559,7 +1559,7 @@ static unsigned long nfit_ctl_handle;
> union acpi_object *result;
>
> static union acpi_object *nfit_test_evaluate_dsm(acpi_handle handle,
> - const u8 *uuid, u64 rev, u64 func, union acpi_object *argv4)
> + const uuid_le *uuid, u64 rev, u64 func, union acpi_object *argv4)
> {
> if (handle != &nfit_ctl_handle)
> return ERR_PTR(-ENXIO);
> --
> 2.11.0
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: net: possible deadlock in skb_queue_tail
From: Andrey Konovalov @ 2017-05-04 13:49 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, Paolo Abeni, Jozsef Kadlecsik, David S. Miller,
netfilter-devel, netdev, LKML, Dmitry Vyukov, Kostya Serebryany,
Eric Dumazet, syzkaller
In-Reply-To: <20170224025650.GA16439@breakpoint.cc>
On Fri, Feb 24, 2017 at 3:56 AM, Florian Westphal <fw@strlen.de> wrote:
> Andrey Konovalov <andreyknvl@google.com> wrote:
>
> [ CC Paolo ]
>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit c470abd4fde40ea6a0846a2beab642a578c0b8cd (4.10).
>>
>> Unfortunately I can't reproduce it.
>
> This needs NETLINK_BROADCAST_ERROR enabled on a netlink socket
> that then subscribes to netfilter conntrack (ctnetlink) events.
> probably syzkaller did this by accident -- impressive.
>
> (one task is the ctnetlink event redelivery worker
> which won't be scheduled otherwise).
>
>> ======================================================
>> [ INFO: possible circular locking dependency detected ]
>> 4.10.0-rc8+ #201 Not tainted
>> -------------------------------------------------------
>> kworker/0:2/1404 is trying to acquire lock:
>> (&(&list->lock)->rlock#3){+.-...}, at: [<ffffffff8335b23f>]
>> skb_queue_tail+0xcf/0x2f0 net/core/skbuff.c:2478
>>
>> but task is already holding lock:
>> (&(&pcpu->lock)->rlock){+.-...}, at: [<ffffffff8366b55f>] spin_lock
>> include/linux/spinlock.h:302 [inline]
>> (&(&pcpu->lock)->rlock){+.-...}, at: [<ffffffff8366b55f>]
>> ecache_work_evict_list+0xaf/0x590
>> net/netfilter/nf_conntrack_ecache.c:48
>>
>> which lock already depends on the new lock.
>
> Cong is correct, this is a false positive.
>
> However we should fix this splat.
>
> Paolo, this happens since 7c13f97ffde63cc792c49ec1513f3974f2f05229
> ('udp: do fwd memory scheduling on dequeue'), before this
> commit kfree_skb() was invoked outside of the locked section in
> first_packet_length().
>
> cpu 0 call chain:
> - first_packet_length (hold udp sk_receive_queue lock)
> - kfree_skb
> - nf_conntrack_destroy
> - spin_lock(net->ct.pcpu->lock)
>
> cpu 1 call chain:
> - ecache_work_evict_list
> - spin_lock( net->ct.pcpu->lock)
> - nf_conntrack_event
> - aquire netlink socket sk_receive_queue
>
> So this could only ever deadlock if a netlink socket
> calls kfree_skb while holding its sk_receive_queue lock, but afaics
> this is never the case.
>
> There are two ways to avoid this splat (other than lockdep annotation):
>
> 1. re-add the list to first_packet_length() and free the
> skbs outside of locked section.
>
> 2. change ecache_work_evict_list to not call nf_conntrack_event()
> while holding the pcpu lock.
>
> doing #2 might be a good idea anyway to avoid potential deadlock
> when kfree_skb gets invoked while other cpu holds its sk_receive_queue
> lock, I'll have a look if this is feasible.
Hi!
Any updates on this?
I might have missed the patch if there was one.
Thanks!
^ permalink raw reply
* Re: [[NET-NEXT]] Added dump function to recognise rpl extension header option(63)
From: David Miller @ 2017-05-04 13:49 UTC (permalink / raw)
To: bardoutsos; +Cc: netdev, mcr
In-Reply-To: <a712ff423471e02a533650ce6d64dc85@ceid.upatras.gr>
From: Andreas Bardoutsos <bardoutsos@ceid.upatras.gr>
Date: Thu, 04 May 2017 14:06:32 +0200
> Signed-off-by: Andreas Bardoutsos <bardoutsos@ceid.upatras.gr>
First of all, the net-next tree is closed. You will need to resubmit
this when the net-next tree opens back up.
Second of all, your Subject line is malformed. Please format it like this:
[PATCH net-next] ipv6: Add dump function to recognise rpl extension header option(63)
Thank you.
^ permalink raw reply
* Re: [PATCH net] ah: use crypto_memneq to check the ICV
From: Sabrina Dubroca @ 2017-05-04 13:43 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev, Herbert Xu
In-Reply-To: <20170504104124.GV2649@secunet.com>
2017-05-04, 12:41:24 +0200, Steffen Klassert wrote:
> On Wed, May 03, 2017 at 04:57:57PM +0200, Sabrina Dubroca wrote:
> > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> > ---
> > net/ipv4/ah4.c | 5 +++--
> > net/ipv6/ah6.c | 5 +++--
> > 2 files changed, 6 insertions(+), 4 deletions(-)
>
> Is this a fix for something? If so, please describe what it fixes.
> If not, it can wait until after the merge window and merged into
> ipsec-next then.
Yeah, not really. I suppose you could see it as a fix for the commit
that introduced crypto_memneq and did some conversions (6bf37e5aa90f
("crypto: crypto_memneq - add equality testing of memory regions w/o
timing leaks")), but that may be a bit of a stretch.
I can repost that for ipsec-next in a couple of weeks.
Thanks,
--
Sabrina
^ permalink raw reply
* Re: [PATCH net 2/3] qed: Fix overriding of supported autoneg value.
From: David Miller @ 2017-05-04 13:40 UTC (permalink / raw)
To: Sudarsana.Kalluru; +Cc: leon, netdev, Yuval.Mintz
In-Reply-To: <CY4PR07MB3048164CC90E3486981CDA5F8AEA0@CY4PR07MB3048.namprd07.prod.outlook.com>
From: "Kalluru, Sudarsana" <Sudarsana.Kalluru@cavium.com>
Date: Thu, 4 May 2017 08:02:52 +0000
> Dave, please let us know if re-spin is required for this. If not required, will plan to clean it up in the next series.
Please fix this now.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64__
From: David Miller @ 2017-05-04 13:37 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev
In-Reply-To: <d809baa4-c864-af99-38af-fbcb6637ca2b@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Wed, 3 May 2017 20:30:22 -0700
> I would buy that debian folks indeed care about multi-arch, but
> what above does is making #include <linux/types.h> to be a nop
> for any cross-compiler on sparc that included it.
No, if you installed cross compiler for arch X it would add
another stanza doing that "ifdef __ARCH__, include blah, endif"
dance.
> You're right that we cannot assume much about /usr/include craziness.
> In that sense adding __native_arch__ macro is also wrong, since
> it assumes sane /usr/include without inline asm or other things
> that clang for bpf arch can consume.
You can assume that it's for the ARCH we are trying to run tests
for, which needs to be in the family of the kernel arch.
> In that sense the only way to be independent from arch dependent
> things in /usr/include is to put all arch specific headers
> into our own dir in tools/selftests/ (or may be tools/bpf/include)
> and point clang to that. I think the list of .h in there will be
> limited. Only things like linux/types.h and gnu/stubs.h,
> so it will be manageable.
> Thoughts?
No, this way lies madness.
If you want to get the kernel headers, set up the proper environment
instead of constantly trying to fight it.
^ permalink raw reply
* Re: net/dccp: dccp_create_openreq_child freed held lock
From: Andrey Konovalov @ 2017-05-04 13:36 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Arnaldo Carvalho de Melo, Dmitry Vyukov, Gerrit Renker,
David Miller, dccp, netdev, LKML, Eric Dumazet, Cong Wang,
syzkaller
In-Reply-To: <20170301154011.GF15145@kernel.org>
On Wed, Mar 1, 2017 at 4:40 PM, Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
> Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu:
>> > Hello,
>> >
>> > I've got the following report while running syzkaller fuzzer on
>> > 86292b33d4b79ee03e2f43ea0381ef85f077c760:
>> >
>> >
>> > It seems that dccp_create_openreq_child needs to unlock the sock if
>> > dccp_feat_activate_values fails.
>>
>> Yeah, can you please use the patch below, that mimics the error paths in
>> sk_clone_new(), from where I think even the comment about it being a raw
>
> Argh, s/sk_clone_new()/sk_clone_lock()/g
Hi Arnaldo,
Could you send the patch?
We haven't seen these reports since we applied it.
Thanks!
>
> - Arnaldo
>
>> copy came, but the bh_unlock_sock() didn't?
>>
>> - Arnaldo
>>
>> diff --git a/net/dccp/minisocks.c b/net/dccp/minisocks.c
>> index 53eddf99e4f6..d20d948a98ed 100644
>> --- a/net/dccp/minisocks.c
>> +++ b/net/dccp/minisocks.c
>> @@ -122,6 +122,7 @@ struct sock *dccp_create_openreq_child(const struct sock *sk,
>> /* It is still raw copy of parent, so invalidate
>> * destructor and make plain sk_free() */
>> newsk->sk_destruct = NULL;
>> + bh_unlock_sock(newsk);
>> sk_free(newsk);
>> return NULL;
>> }
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH iproute] tc: Reflect HW offload status
From: Or Gerlitz @ 2017-05-04 13:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Roi Dayan, Paul Blakey, Or Gerlitz
Currently there is no way of querying whether a filter is
offloaded to HW or not when using "both" policy (where none
of skip_sw or skip_hw flags are set by user-space).
Add two new flags, "in hw" and "not in hw" such that user
space can determine if a filter is actually offloaded to
hw or not. The "in hw" UAPI semantics was chosen so it's
similar to the "skip hw" flag logic.
If none of these two flags are set, this signals running
over older kernel.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
tc/f_bpf.c | 5 +++++
tc/f_flower.c | 5 +++++
tc/f_matchall.c | 5 +++++
tc/f_u32.c | 5 +++++
4 files changed, 20 insertions(+)
diff --git a/tc/f_bpf.c b/tc/f_bpf.c
index df8a259..75c44c0 100644
--- a/tc/f_bpf.c
+++ b/tc/f_bpf.c
@@ -210,6 +210,11 @@ static int bpf_print_opt(struct filter_util *qu, FILE *f,
fprintf(f, "skip_hw ");
if (flags & TCA_CLS_FLAGS_SKIP_SW)
fprintf(f, "skip_sw ");
+
+ if (flags & TCA_CLS_FLAGS_IN_HW)
+ fprintf(f, "in_hw ");
+ else if (flags & TCA_CLS_FLAGS_NOT_IN_HW)
+ fprintf(f, "not_in_hw ");
}
if (tb[TCA_BPF_OPS] && tb[TCA_BPF_OPS_LEN])
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 5aac4a0..ebc63ca 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -1171,6 +1171,11 @@ static int flower_print_opt(struct filter_util *qu, FILE *f,
fprintf(f, "\n skip_hw");
if (flags & TCA_CLS_FLAGS_SKIP_SW)
fprintf(f, "\n skip_sw");
+
+ if (flags & TCA_CLS_FLAGS_IN_HW)
+ fprintf(f, "\n in_hw");
+ else if (flags & TCA_CLS_FLAGS_NOT_IN_HW)
+ fprintf(f, "\n not_in_hw");
}
if (tb[TCA_FLOWER_ACT])
diff --git a/tc/f_matchall.c b/tc/f_matchall.c
index ac48630..5a51e75 100644
--- a/tc/f_matchall.c
+++ b/tc/f_matchall.c
@@ -137,6 +137,11 @@ static int matchall_print_opt(struct filter_util *qu, FILE *f,
fprintf(f, "\n skip_hw");
if (flags & TCA_CLS_FLAGS_SKIP_SW)
fprintf(f, "\n skip_sw");
+
+ if (flags & TCA_CLS_FLAGS_IN_HW)
+ fprintf(f, "\n in_hw");
+ else if (flags & TCA_CLS_FLAGS_NOT_IN_HW)
+ fprintf(f, "\n not_in_hw");
}
if (tb[TCA_MATCHALL_ACT])
diff --git a/tc/f_u32.c b/tc/f_u32.c
index 92c1fcd..ff700e9 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -1264,6 +1264,11 @@ static int u32_print_opt(struct filter_util *qu, FILE *f, struct rtattr *opt,
fprintf(f, "skip_hw ");
if (flags & TCA_CLS_FLAGS_SKIP_SW)
fprintf(f, "skip_sw ");
+
+ if (flags & TCA_CLS_FLAGS_IN_HW)
+ fprintf(f, "in_hw ");
+ else if (flags & TCA_CLS_FLAGS_NOT_IN_HW)
+ fprintf(f, "not_in_hw ");
}
if (tb[TCA_U32_PCNT]) {
--
2.3.7
^ permalink raw reply related
* Re: net/smc and the RDMA core
From: Leon Romanovsky @ 2017-05-04 13:15 UTC (permalink / raw)
To: Ursula Braun
Cc: hch-jcswGhMUV9g@public.gmane.org, Sagi Grimberg, Bart Van Assche,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <efa9bd6d-1df9-952a-7f32-c2ee6bffcae5-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]
On Thu, May 04, 2017 at 03:08:39PM +0200, Ursula Braun wrote:
>
>
> On 05/04/2017 10:48 AM, hch-jcswGhMUV9g@public.gmane.org wrote:
> > On Thu, May 04, 2017 at 11:43:50AM +0300, Sagi Grimberg wrote:
> >> I would also suggest that you stop exposing the DMA MR for remote
> >> access (at least by default) and use a proper reg_mr operations with a
> >> limited lifetime on a properly sized buffer.
> >
> > Yes, exposing the default DMA MR is a _major_ security risk. As soon
> > as SMC is enabled this will mean a remote system has full read/write
> > access to the local systems memory.
> >
> > There іs a reason why I removed the ib_get_dma_mr function and replaced
> > it with the IB_PD_UNSAFE_GLOBAL_RKEY key that has _UNSAFE_ in the name
> > and a very long comment explaining why, and I'm really disappointed that
> > we got a driver merged that instead of asking on the relevant list on
> > why a change unexpertong a function it needed happened and instead
> > tried the hard way to keep a security vulnerarbility alive.
> >
> Thanks for pointing out these problems. We will address them.
>
Out of curiosity, when do you plan to address all this?
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()
From: Kalle Valo @ 2017-05-04 13:13 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Johannes Berg, k.eugene.e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Andy Gross, David Brown,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
wcn36xx-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
nicolas.dechesne-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
In-Reply-To: <20170428234247.GQ15143@minitux>
Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> On Thu 27 Apr 01:22 PDT 2017, Johannes Berg wrote:
>
>>
>> > @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn,
>> > struct wcn36xx_dxe_ch *ch)
>> > info = IEEE80211_SKB_CB(ctl->skb);
>> > if (!(info->flags &
>> > IEEE80211_TX_CTL_REQ_TX_STATUS)) {
>> > /* Keep frame until TX status comes
>> > */
>> > - ieee80211_free_txskb(wcn->hw, ctl-
>> > >skb);
>> > + ieee80211_tx_status(wcn->hw, ctl-
>> > >skb);
>> >
>>
>> I don't think this is a good idea.
>
> Thanks for letting me know :)
>
>> This code intentionally checked if TX status was requested, and if not
>> then it doesn't go to the effort of building it.
>>
>
> What I'm finding puzzling is the fact that the only caller of
> ieee80211_led_tx() is ieee80211_tx_status() and it seems like drivers,
> such as ath10k, call this for each packet handled - but I'm likely
> missing something.
>
>> As it is with your patch, it'll go and report the TX status without any
>> TX status information - which is handled in wcn36xx_dxe_tx_ack_ind()
>> for those frames needing it.
>>
>
> Right, it doesn't sound desired. However, during normal operation I'm
> not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such
> ieee80211_led_tx() is never called.
So what's the conclusion? How do we get leds working?
--
Kalle Valo
^ permalink raw reply
* Re: net/smc and the RDMA core
From: Ursula Braun @ 2017-05-04 13:08 UTC (permalink / raw)
To: hch@lst.de, Sagi Grimberg
Cc: Bart Van Assche, davem@davemloft.net, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <20170504084825.GA5399@lst.de>
On 05/04/2017 10:48 AM, hch@lst.de wrote:
> On Thu, May 04, 2017 at 11:43:50AM +0300, Sagi Grimberg wrote:
>> I would also suggest that you stop exposing the DMA MR for remote
>> access (at least by default) and use a proper reg_mr operations with a
>> limited lifetime on a properly sized buffer.
>
> Yes, exposing the default DMA MR is a _major_ security risk. As soon
> as SMC is enabled this will mean a remote system has full read/write
> access to the local systems memory.
>
> There іs a reason why I removed the ib_get_dma_mr function and replaced
> it with the IB_PD_UNSAFE_GLOBAL_RKEY key that has _UNSAFE_ in the name
> and a very long comment explaining why, and I'm really disappointed that
> we got a driver merged that instead of asking on the relevant list on
> why a change unexpertong a function it needed happened and instead
> tried the hard way to keep a security vulnerarbility alive.
>
Thanks for pointing out these problems. We will address them.
^ permalink raw reply
* RE: Donation Award
From: Mayrhofer Family @ 2017-05-04 11:45 UTC (permalink / raw)
To: Recipients
Good Day,
My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from part of our Jackpot Lottery of 50 Million Dollars, respond with your details for claims.
We await your earliest response and God Bless you.
Friedrich And Annand Mayrhofer.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [[NET-NEXT]] Added dump function to recognise rpl extension header option(63)
From: Florian Westphal @ 2017-05-04 12:57 UTC (permalink / raw)
To: Stefan Schmidt
Cc: Florian Westphal, Andreas Bardoutsos, netdev, Michael Richardson,
linux-wpan@vger.kernel.org
In-Reply-To: <20170504125101.GD31463@work.Speedport_W_724V_09011603_05_010>
Stefan Schmidt <stefan@osg.samsung.com> wrote:
> > The kernel tosses it because the RPL option/RFC says so
> > ('nodes that do not understand this option on a received
> > packet MUST discard the packet.').
>
> What we might need is a way to let the kernel know we have a RPL running with
> support for this option. Would that meet your concern?
Sure.
^ permalink raw reply
* Re: [[NET-NEXT]] Added dump function to recognise rpl extension header option(63)
From: Stefan Schmidt @ 2017-05-04 12:51 UTC (permalink / raw)
To: Florian Westphal
Cc: Stefan Schmidt, Andreas Bardoutsos, netdev, Michael Richardson,
linux-wpan@vger.kernel.org
In-Reply-To: <20170504123337.GE13320@breakpoint.cc>
Hello.
On Thu, 2017-05-04 at 14:33, Florian Westphal wrote:
> Stefan Schmidt <stefan@osg.samsung.com> wrote:
> > ipv6: ext_header: add function to handle RPL option 0x63
>
> But its not handled, is it?
Its not handled in the kernel. The RPL daemon would run in userspace in this
case.
>From my understanding unstrung (or any other RPL implementation) needs this
packet. Right now the kernel silently drops it. Michael would know best
about the details here and if we need some more logic in the kernel itself.
Maybe just some sanity checking of the TLV.
> The kernel tosses it because the RPL option/RFC says so
> ('nodes that do not understand this option on a received
> packet MUST discard the packet.').
What we might need is a way to let the kernel know we have a RPL running with
support for this option. Would that meet your concern?
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Joerg Roedel @ 2017-05-04 12:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-acpi, tpmdd-devel, intel-gfx, nouveau, linux-input, iommu,
linux-mmc, netdev, linux-pci, linux-usb, alsa-devel, linux-kernel,
Rafael J . Wysocki, Mika Westerberg, Borislav Petkov,
Dan Williams, Amir Goldstein, Jarkko Sakkinen, Jani Nikula,
Ben Skeggs, Benjamin Tissoires, Adrian Hunter
In-Reply-To: <20170504092151.88646-1-andriy.shevchenko@linux.intel.com>
On Thu, May 04, 2017 at 12:21:51PM +0300, Andy Shevchenko wrote:
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index cbf7763d8091..420d51b286ad 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1808,10 +1808,9 @@ IOMMU_INIT_POST(detect_intel_iommu);
> * for Directed-IO Architecture Specifiction, Rev 2.2, Section 8.8
> * "Remapping Hardware Unit Hot Plug".
> */
> -static u8 dmar_hp_uuid[] = {
> - /* 0000 */ 0xA6, 0xA3, 0xC1, 0xD8, 0x9B, 0xBE, 0x9B, 0x4C,
> - /* 0008 */ 0x91, 0xBF, 0xC3, 0xCB, 0x81, 0xFC, 0x5D, 0xAF
> -};
> +static uuid_le dmar_hp_uuid =
> + UUID_LE(0xD8C1A3A6, 0xBE9B, 0x4C9B,
> + 0x91, 0xBF, 0xC3, 0xCB, 0x81, 0xFC, 0x5D, 0xAF);
>
> /*
> * Currently there's only one revision and BIOS will not check the revision id,
> @@ -1824,7 +1823,7 @@ static u8 dmar_hp_uuid[] = {
>
> static inline bool dmar_detect_dsm(acpi_handle handle, int func)
> {
> - return acpi_check_dsm(handle, dmar_hp_uuid, DMAR_DSM_REV_ID, 1 << func);
> + return acpi_check_dsm(handle, &dmar_hp_uuid, DMAR_DSM_REV_ID, 1 << func);
> }
>
> static int dmar_walk_dsm_resource(acpi_handle handle, int func,
> @@ -1843,7 +1842,7 @@ static int dmar_walk_dsm_resource(acpi_handle handle, int func,
> if (!dmar_detect_dsm(handle, func))
> return 0;
>
> - obj = acpi_evaluate_dsm_typed(handle, dmar_hp_uuid, DMAR_DSM_REV_ID,
> + obj = acpi_evaluate_dsm_typed(handle, &dmar_hp_uuid, DMAR_DSM_REV_ID,
> func, NULL, ACPI_TYPE_BUFFER);
> if (!obj)
> return -ENODEV;
DMAR part is
Acked-by: Joerg Roedel <jroedel@suse.de>
^ permalink raw reply
* Re: [[NET-NEXT]] Added dump function to recognise rpl extension header option(63)
From: Florian Westphal @ 2017-05-04 12:33 UTC (permalink / raw)
To: Stefan Schmidt
Cc: Andreas Bardoutsos, netdev, Michael Richardson,
linux-wpan@vger.kernel.org
In-Reply-To: <af9727bf-9987-1046-c2aa-2a8695447fde@osg.samsung.com>
Stefan Schmidt <stefan@osg.samsung.com> wrote:
> ipv6: ext_header: add function to handle RPL option 0x63
But its not handled, is it?
The kernel tosses it because the RPL option/RFC says so
('nodes that do not understand this option on a received
packet MUST discard the packet.').
^ permalink raw reply
* Re: x86: warning: kernel stack regs has bad 'bp' value
From: Andrey Konovalov @ 2017-05-04 12:32 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, LKML,
Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
Marcelo Ricardo Leitner, Dmitry Vyukov, Kostya Serebryany,
syzkaller, Eric Dumazet, Cong Wang
In-Reply-To: <CAAeHK+x_ka0XqQiAg5jrqQUSk2Ri0Ab-A62NTKYWj=i0TXQqZQ@mail.gmail.com>
On Wed, May 3, 2017 at 5:50 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, May 3, 2017 at 3:30 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> On Wed, May 03, 2017 at 02:48:28PM +0200, Andrey Konovalov wrote:
>>> Hi,
>>>
>>> I've got the following error report while fuzzing the kernel with syzkaller.
>>>
>>> On commit 89c9fea3c8034cdb2fd745f551cde0b507fd6893 (4.11.0+).
>>>
>>> A reproducer and .config are attached.
>>>
>>> The reproducer open SCTP sockets and sends data to it in a loop.
>>> I'm not sure whether this is an issue with SCTP or with something else.
>>>
>>> WARNING: kernel stack regs at ffff8800686869f8 in a.out:4933 has bad
>>> 'bp' value c3fc855a10167ec0
>>
>> Hi Andrey,
>>
>> Can you test this patch?
>
> Hi Josh,
>
> This seems to be fixing the reports caused by the reproducers.
>
> I'll keep fuzzing though with syzkaller to make sure.
Hi Josh
I didn't see any more reports over the night.
Could you mail the patch?
Thanks!
>
> Thanks!
>
>>
>>
>> diff --git a/arch/x86/lib/csum-copy_64.S b/arch/x86/lib/csum-copy_64.S
>> index 7e48807..45a53df 100644
>> --- a/arch/x86/lib/csum-copy_64.S
>> +++ b/arch/x86/lib/csum-copy_64.S
>> @@ -55,7 +55,7 @@ ENTRY(csum_partial_copy_generic)
>> movq %r12, 3*8(%rsp)
>> movq %r14, 4*8(%rsp)
>> movq %r13, 5*8(%rsp)
>> - movq %rbp, 6*8(%rsp)
>> + movq %r15, 6*8(%rsp)
>>
>> movq %r8, (%rsp)
>> movq %r9, 1*8(%rsp)
>> @@ -74,7 +74,7 @@ ENTRY(csum_partial_copy_generic)
>> /* main loop. clear in 64 byte blocks */
>> /* r9: zero, r8: temp2, rbx: temp1, rax: sum, rcx: saved length */
>> /* r11: temp3, rdx: temp4, r12 loopcnt */
>> - /* r10: temp5, rbp: temp6, r14 temp7, r13 temp8 */
>> + /* r10: temp5, r15: temp6, r14 temp7, r13 temp8 */
>> .p2align 4
>> .Lloop:
>> source
>> @@ -89,7 +89,7 @@ ENTRY(csum_partial_copy_generic)
>> source
>> movq 32(%rdi), %r10
>> source
>> - movq 40(%rdi), %rbp
>> + movq 40(%rdi), %r15
>> source
>> movq 48(%rdi), %r14
>> source
>> @@ -103,7 +103,7 @@ ENTRY(csum_partial_copy_generic)
>> adcq %r11, %rax
>> adcq %rdx, %rax
>> adcq %r10, %rax
>> - adcq %rbp, %rax
>> + adcq %r15, %rax
>> adcq %r14, %rax
>> adcq %r13, %rax
>>
>> @@ -121,7 +121,7 @@ ENTRY(csum_partial_copy_generic)
>> dest
>> movq %r10, 32(%rsi)
>> dest
>> - movq %rbp, 40(%rsi)
>> + movq %r15, 40(%rsi)
>> dest
>> movq %r14, 48(%rsi)
>> dest
>> @@ -203,7 +203,7 @@ ENTRY(csum_partial_copy_generic)
>> movq 3*8(%rsp), %r12
>> movq 4*8(%rsp), %r14
>> movq 5*8(%rsp), %r13
>> - movq 6*8(%rsp), %rbp
>> + movq 6*8(%rsp), %r15
>> addq $7*8, %rsp
>> ret
>>
^ permalink raw reply
* Re: [Patch net] ipv6: initialize route null entry in addrconf_init()
From: Andrey Konovalov @ 2017-05-04 12:28 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David Ahern
In-Reply-To: <1493874452-3050-1-git-send-email-xiyou.wangcong@gmail.com>
On Thu, May 4, 2017 at 7:07 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> Andrey reported a crash on init_net.ipv6.ip6_null_entry->rt6i_idev
> since it is always NULL.
>
> This is clearly wrong, we have code to initialize it to loopback_dev,
> unfortunately the order is still not correct.
>
> loopback_dev is registered very early during boot, we lose a chance
> to re-initialize it in notifier. addrconf_init() is called after
> ip6_route_init(), which means we have no chance to correct it.
>
> Fix it by moving this initialization explicitly after
> ipv6_add_dev(init_net.loopback_dev) in addrconf_init().
>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Hi Cong,
This fixes the bug triggered by my reproducer.
Thanks!
Tested-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> include/net/ip6_route.h | 1 +
> net/ipv6/addrconf.c | 2 ++
> net/ipv6/route.c | 26 +++++++++++++++-----------
> 3 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> index 9dc2c18..f5e625f 100644
> --- a/include/net/ip6_route.h
> +++ b/include/net/ip6_route.h
> @@ -84,6 +84,7 @@ struct dst_entry *ip6_route_lookup(struct net *net, struct flowi6 *fl6,
> struct rt6_info *ip6_pol_route(struct net *net, struct fib6_table *table,
> int ifindex, struct flowi6 *fl6, int flags);
>
> +void ip6_route_init_special_entries(void);
> int ip6_route_init(void);
> void ip6_route_cleanup(void);
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index a2a370b..77a4bd5 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -6573,6 +6573,8 @@ int __init addrconf_init(void)
> goto errlo;
> }
>
> + ip6_route_init_special_entries();
> +
> for (i = 0; i < IN6_ADDR_HSIZE; i++)
> INIT_HLIST_HEAD(&inet6_addr_lst[i]);
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index a1bf426..2f11366 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -4027,6 +4027,21 @@ static struct notifier_block ip6_route_dev_notifier = {
> .priority = 0,
> };
>
> +void __init ip6_route_init_special_entries(void)
> +{
> + /* Registering of the loopback is done before this portion of code,
> + * the loopback reference in rt6_info will not be taken, do it
> + * manually for init_net */
> + init_net.ipv6.ip6_null_entry->dst.dev = init_net.loopback_dev;
> + init_net.ipv6.ip6_null_entry->rt6i_idev = in6_dev_get(init_net.loopback_dev);
> + #ifdef CONFIG_IPV6_MULTIPLE_TABLES
> + init_net.ipv6.ip6_prohibit_entry->dst.dev = init_net.loopback_dev;
> + init_net.ipv6.ip6_prohibit_entry->rt6i_idev = in6_dev_get(init_net.loopback_dev);
> + init_net.ipv6.ip6_blk_hole_entry->dst.dev = init_net.loopback_dev;
> + init_net.ipv6.ip6_blk_hole_entry->rt6i_idev = in6_dev_get(init_net.loopback_dev);
> + #endif
> +}
> +
> int __init ip6_route_init(void)
> {
> int ret;
> @@ -4053,17 +4068,6 @@ int __init ip6_route_init(void)
>
> ip6_dst_blackhole_ops.kmem_cachep = ip6_dst_ops_template.kmem_cachep;
>
> - /* Registering of the loopback is done before this portion of code,
> - * the loopback reference in rt6_info will not be taken, do it
> - * manually for init_net */
> - init_net.ipv6.ip6_null_entry->dst.dev = init_net.loopback_dev;
> - init_net.ipv6.ip6_null_entry->rt6i_idev = in6_dev_get(init_net.loopback_dev);
> - #ifdef CONFIG_IPV6_MULTIPLE_TABLES
> - init_net.ipv6.ip6_prohibit_entry->dst.dev = init_net.loopback_dev;
> - init_net.ipv6.ip6_prohibit_entry->rt6i_idev = in6_dev_get(init_net.loopback_dev);
> - init_net.ipv6.ip6_blk_hole_entry->dst.dev = init_net.loopback_dev;
> - init_net.ipv6.ip6_blk_hole_entry->rt6i_idev = in6_dev_get(init_net.loopback_dev);
> - #endif
> ret = fib6_init();
> if (ret)
> goto out_register_subsys;
> --
> 2.5.5
>
^ permalink raw reply
* Re: [[NET-NEXT]] Added dump function to recognise rpl extension header option(63)
From: Stefan Schmidt @ 2017-05-04 12:27 UTC (permalink / raw)
To: Andreas Bardoutsos, netdev; +Cc: Michael Richardson, linux-wpan@vger.kernel.org
In-Reply-To: <a712ff423471e02a533650ce6d64dc85@ceid.upatras.gr>
Hello.
Lets do the review here on netdev.
Some general things first. You might want to use git send-email to make
sure the formatting does not get screwed up from your mailer. Another
thing to keep in mind is that net-next is closed right now (we are in
the 4.12 merge window right now) and Dave will most likely as you to
re-submit once it opens up again. On the other hand I would go as far as
calling this a fix as it makes sure the needed packet does not get
dropped in kernel space and unstrung as RPL daemon can work with it. It
also fixes the RPL communication with Contiki.
Your subject line also needs a prefix like "ipv6: ext_header:". Maybe
something like this is better:
ipv6: ext_header: add function to handle RPL option 0x63
On 05/04/2017 02:06 PM, Andreas Bardoutsos wrote:
> Signed-off-by: Andreas Bardoutsos <bardoutsos@ceid.upatras.gr>
> ---
> I have added a dump function(always return true) to recognise RPL
> extension header(RFC6553)
> Otherwise packet was dropped by kernel resulting in impossible
> communication in RPL DAG's between
> linux running border routers and devices in the graph,which may run
> different OS(contiki os for example)
Please put this useful information in the commit message.
> include/uapi/linux/in6.h | 1 +
> net/ipv6/exthdrs.c | 13 +++++++++++++
> 2 files changed, 14 insertions(+)
>
> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
> index 46444f8fbee4..5cc12d309dfe 100644
> --- a/include/uapi/linux/in6.h
> +++ b/include/uapi/linux/in6.h
> @@ -146,6 +146,7 @@ struct in6_flowlabel_req {
> #define IPV6_TLV_CALIPSO 7 /* RFC 5570 */
> #define IPV6_TLV_JUMBO 194
> #define IPV6_TLV_HAO 201 /* home address option */
> +#define IPV6_TLV_RPL 99 /* RFC 6553 */
>
> /*
> * IPV6 socket options
> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
> index b636f1da9aec..82ed60d3180e 100644
> --- a/net/ipv6/exthdrs.c
> +++ b/net/ipv6/exthdrs.c
> @@ -785,6 +785,15 @@ static bool ipv6_hop_calipso(struct sk_buff *skb,
> int optoff)
> return false;
> }
>
> +/* RPL RFC 6553 */
> +
> +static bool ipv6_hop_rpl(struct sk_buff *skb, int optoff)
> +{
> + /*Dump function which always return true
> + *when rpl option is detected*/
> + return true;
We might need to do some more processing later here. For now it should
be good as a fix to get the RPL communication between Linux and Contiki
working again. Michael, what extra checks would you need in the kernel here?
> +}
> +
> static const struct tlvtype_proc tlvprochopopt_lst[] = {
> {
> .type = IPV6_TLV_ROUTERALERT,
> @@ -798,6 +807,10 @@ static const struct tlvtype_proc
> tlvprochopopt_lst[] = {
> .type = IPV6_TLV_CALIPSO,
> .func = ipv6_hop_calipso,
> },
> + {
> + .type = IPV6_TLV_RPL,
> + .func = ipv6_hop_rpl,
> + },
> { -1, }
> };
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
regards
Stefan Schmidt
^ permalink raw reply
* [PATCH] xen-netfront: avoid crashing on resume after a failure in talk_to_netback()
From: Vitaly Kuznetsov @ 2017-05-04 12:23 UTC (permalink / raw)
To: xen-devel; +Cc: netdev, linux-kernel, Boris Ostrovsky, Juergen Gross
Unavoidable crashes in netfront_resume() and netback_changed() after a
previous fail in talk_to_netback() (e.g. when we fail to read MAC from
xenstore) were discovered. The failure path in talk_to_netback() does
unregister/free for netdev but we don't reset drvdata and we try accessing
it again after resume.
Reset drvdata in netback_changed() the same way we reset it in
netfront_probe() and check for NULL in both netfront_resume() and
netback_changed() to properly handle the situation.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
I apologize for sending this during the merge window, I'm not sure if this
needs to go through xen or netdev tree. I think the fix is simple enough
and it would make sense to squeeze it in 4.12 if possible. Thanks.
---
drivers/net/xen-netfront.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 6ffc482..92f746c 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1426,6 +1426,9 @@ static int netfront_resume(struct xenbus_device *dev)
{
struct netfront_info *info = dev_get_drvdata(&dev->dev);
+ if (!info)
+ return 0;
+
dev_dbg(&dev->dev, "%s\n", dev->nodename);
xennet_disconnect_backend(info);
@@ -1936,6 +1939,7 @@ static int talk_to_netback(struct xenbus_device *dev,
out:
unregister_netdev(info->netdev);
xennet_free_netdev(info->netdev);
+ dev_set_drvdata(&dev->dev, NULL);
return err;
}
@@ -1997,7 +2001,12 @@ static void netback_changed(struct xenbus_device *dev,
enum xenbus_state backend_state)
{
struct netfront_info *np = dev_get_drvdata(&dev->dev);
- struct net_device *netdev = np->netdev;
+ struct net_device *netdev;
+
+ if (!np)
+ return;
+
+ netdev = np->netdev;
dev_dbg(&dev->dev, "%s\n", xenbus_strstate(backend_state));
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Heikki Krogerus @ 2017-05-04 12:14 UTC (permalink / raw)
To: Andy Shevchenko
Cc: alsa-devel, Liam Girdwood, linux-pci, Amir Goldstein,
Jarkko Sakkinen, Adrian Hunter, Benjamin Tissoires, Joerg Roedel,
linux-acpi, tpmdd-devel, Ben Skeggs, nouveau, linux-mmc,
Zhang Rui, Borislav Petkov, Yisen Zhuang, Mathias Nyman,
intel-gfx, linux-input, Mark Brown, Bjorn Helgaas, Dan Williams,
Mika Westerberg, Felipe Balbi, netdev
In-Reply-To: <20170504092151.88646-1-andriy.shevchenko@linux.intel.com>
On Thu, May 04, 2017 at 12:21:51PM +0300, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Amir Goldstein <amir73il@gmail.com>
> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Felipe Balbi <balbi@kernel.org>
> Cc: Mathias Nyman <mathias.nyman@intel.com>
> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
OK by me, FWIW:
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Thanks,
--
heikki
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [[NET-NEXT]] Added dump function to recognise rpl extension header option(63)
From: Andreas Bardoutsos @ 2017-05-04 12:06 UTC (permalink / raw)
To: netdev; +Cc: Michael Richardson
Signed-off-by: Andreas Bardoutsos <bardoutsos@ceid.upatras.gr>
---
I have added a dump function(always return true) to recognise RPL
extension header(RFC6553)
Otherwise packet was dropped by kernel resulting in impossible
communication in RPL DAG's between
linux running border routers and devices in the graph,which may run
different OS(contiki os for example)
include/uapi/linux/in6.h | 1 +
net/ipv6/exthdrs.c | 13 +++++++++++++
2 files changed, 14 insertions(+)
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index 46444f8fbee4..5cc12d309dfe 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
@@ -146,6 +146,7 @@ struct in6_flowlabel_req {
#define IPV6_TLV_CALIPSO 7 /* RFC 5570 */
#define IPV6_TLV_JUMBO 194
#define IPV6_TLV_HAO 201 /* home address option */
+#define IPV6_TLV_RPL 99 /* RFC 6553 */
/*
* IPV6 socket options
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index b636f1da9aec..82ed60d3180e 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -785,6 +785,15 @@ static bool ipv6_hop_calipso(struct sk_buff *skb,
int optoff)
return false;
}
+/* RPL RFC 6553 */
+
+static bool ipv6_hop_rpl(struct sk_buff *skb, int optoff)
+{
+ /*Dump function which always return true
+ *when rpl option is detected*/
+ return true;
+}
+
static const struct tlvtype_proc tlvprochopopt_lst[] = {
{
.type = IPV6_TLV_ROUTERALERT,
@@ -798,6 +807,10 @@ static const struct tlvtype_proc
tlvprochopopt_lst[] = {
.type = IPV6_TLV_CALIPSO,
.func = ipv6_hop_calipso,
},
+ {
+ .type = IPV6_TLV_RPL,
+ .func = ipv6_hop_rpl,
+ },
{ -1, }
};
^ permalink raw reply related
* Re: [PATCH v4 net-next 08/10] net/ncsi: Support NCSI packet generation
From: Andrew Lunn @ 2017-05-04 12:00 UTC (permalink / raw)
To: Gavin Shan; +Cc: netdev, joe, kubakici, f.fainelli, davem
In-Reply-To: <20170504063156.GA7620@gwshan>
On Thu, May 04, 2017 at 04:31:57PM +1000, Gavin Shan wrote:
> On Wed, May 03, 2017 at 02:52:54PM +0200, Andrew Lunn wrote:
> >On Wed, May 03, 2017 at 02:44:39PM +1000, Gavin Shan wrote:
> >> This introduces /sys/kernel/debug/ncsi/eth0/pkt. The debugfs entry
> >> can accept parameters to produce NCSI command packet. The received
> >> NCSI response packet is dumped on read. Below is an example to send
> >> CIS command and dump its response.
> >>
> >> # echo CIS,0,0 > /sys/kernel/debug/ncsi/eth0/pkt
> >> # cat /sys/kernel/debug/ncsi/eth0/pkt
> >> NCSI response [CIS] packet received
> >>
> >> 00 01 dd 80 00 0004 0000 0000
> >
> >Could this be done with a raw socket for Tx and
> >libpcap/tcpdump/wireshart for Rx?
> >
>
> Andrew, it's really good question. Unfortunately, I don't think it can
> be done solely by raw socket to transmit NCSI command packet because the
> [packet sequence number] field in the packet can't be same to any used ones.
> Otherwise the remote NIC will be confused and start to reponse abnormally.
Just to make sure i'm on the same page. We are talking about:
https://www.dmtf.org/sites/default/files/standards/documents/DSP0222_1.0.1.pdf
and the sequence number is the Instance ID. This is an 8-bit number,
and if it receives a message with the previously used IID, it should
assume it is a re-transmit of the request and send back the old
response. It is a very simple scheme, no windowing, only one
outstanding command/response, just one response buffered in case of a
re-transmit.
> We could reserve some sequence number to be used by raw socket.
I don't think that works. You can only have one command
'inflight'. Packets from a raw socket would have to go through your
state machine. Which makes it complex.
libpcap should however still work. So you should probably do all the
receive side in user space.
Andrew
^ permalink raw reply
* Re: [PATCH net] ah: use crypto_memneq to check the ICV
From: Steffen Klassert @ 2017-05-04 10:41 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: netdev, Herbert Xu
In-Reply-To: <c53afb48648b2727f6272053f6100c8db3ec6486.1493741168.git.sd@queasysnail.net>
On Wed, May 03, 2017 at 04:57:57PM +0200, Sabrina Dubroca wrote:
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> ---
> net/ipv4/ah4.c | 5 +++--
> net/ipv6/ah6.c | 5 +++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
Is this a fix for something? If so, please describe what it fixes.
If not, it can wait until after the merge window and merged into
ipsec-next then.
^ permalink raw reply
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