* [PATCH] tpm: add support for partial reads
From: James Bottomley @ 2018-07-23 21:13 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <fb053916-f6e8-3266-14d7-128e062b6a92@intel.com>
On Mon, 2018-07-23 at 13:53 -0700, Tadeusz Struk wrote:
> On 07/23/2018 01:19 PM, Jarkko Sakkinen wrote:
> > In this case I do not have any major evidence of any major benefit
> > *and* the change breaks the ABI.
>
> As I said before - this does not break the ABI.
The current patch does, you even provided a use case in your last email
(it's do command to get sizing followed by do command with correctly
sized buffer).?
However, if you tie it to O_NONBLOCK, it won't because no-one currently
opens the TPM device non blocking so it's an ABI conformant
discriminator of the uses. Tying to O_NONBLOCK should be simple
because it's in file->f_flags.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/7] libsdl2: Find wayland-protocol files in proper location during cross compile
From: Khem Raj @ 2018-07-23 21:11 UTC (permalink / raw)
To: Burton, Ross; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAJTo0LaofRc4ifkmj84YBk0iQZ6K=YSX1+QPSYAcwZJFh1aKxA@mail.gmail.com>
On Mon, Jul 23, 2018 at 3:31 AM Burton, Ross <ross.burton@intel.com> wrote:
>
> On 21 July 2018 at 17:27, Khem Raj <raj.khem@gmail.com> wrote:
> > @@ -29,6 +30,7 @@ EXTRA_OECONF = "--disable-oss --disable-esd --disable-arts \
> > --enable-pthreads \
> > --enable-sdl-dlopen \
> > --disable-rpath \
> > + --disable-wayland-shared \
>
> This isn't explained in the commit log.
disable dynamic loading support for Wayland as it seems to not load
the dependencies correctly.
do you want me to send v2 ?
>
> Ross
^ permalink raw reply
* [PATCH v5] PCI: Check for PCIe downtraining conditions
From: Alexandru Gagniuc @ 2018-07-23 20:03 UTC (permalink / raw)
To: linux-pci, bhelgaas
Cc: keith.busch, alex_gagniuc, austin_bolen, shyam_iyer,
jeffrey.t.kirsher, ariel.elior, michael.chan, ganeshgr, tariqt,
jakub.kicinski, airlied, alexander.deucher, mike.marciniszyn,
Alexandru Gagniuc, linux-kernel
In-Reply-To: <20180718215359.GG128988@bhelgaas-glaptop.roam.corp.google.com>
PCIe downtraining happens when both the device and PCIe port are
capable of a larger bus width or higher speed than negotiated.
Downtraining might be indicative of other problems in the system, and
identifying this from userspace is neither intuitive, nor
straightforward.
The easiest way to detect this is with pcie_print_link_status(),
since the bottleneck is usually the link that is downtrained. It's not
a perfect solution, but it works extremely well in most cases.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
---
For the sake of review, I've created a __pcie_print_link_status() which
takes a 'verbose' argument. If we agree want to go this route, and update
the users of pcie_print_link_status(), I can split this up in two patches.
I prefer just printing this information in the core functions, and letting
drivers not have to worry about this. Though there seems to be strong for
not going that route, so here it goes:
Changes since v4:
- Use 'verbose' argumnet to print bandwidth under normal conditions
- Without verbose, only downtraining conditions are reported
Changes since v3:
- Remove extra newline and parentheses.
Changes since v2:
- Check dev->is_virtfn flag
Changes since v1:
- Use pcie_print_link_status() instead of reimplementing logic
drivers/pci/pci.c | 22 ++++++++++++++++++----
drivers/pci/probe.c | 21 +++++++++++++++++++++
include/linux/pci.h | 1 +
3 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 316496e99da9..414ad7b3abdb 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5302,14 +5302,15 @@ u32 pcie_bandwidth_capable(struct pci_dev *dev, enum pci_bus_speed *speed,
}
/**
- * pcie_print_link_status - Report the PCI device's link speed and width
+ * __pcie_print_link_status - Report the PCI device's link speed and width
* @dev: PCI device to query
+ * @verbose: Be verbose -- print info even when enough bandwidth is available.
*
* Report the available bandwidth at the device. If this is less than the
* device is capable of, report the device's maximum possible bandwidth and
* the upstream link that limits its performance to less than that.
*/
-void pcie_print_link_status(struct pci_dev *dev)
+void __pcie_print_link_status(struct pci_dev *dev, bool verbose)
{
enum pcie_link_width width, width_cap;
enum pci_bus_speed speed, speed_cap;
@@ -5319,11 +5320,11 @@ void pcie_print_link_status(struct pci_dev *dev)
bw_cap = pcie_bandwidth_capable(dev, &speed_cap, &width_cap);
bw_avail = pcie_bandwidth_available(dev, &limiting_dev, &speed, &width);
- if (bw_avail >= bw_cap)
+ if (bw_avail >= bw_cap && verbose)
pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth (%s x%d link)\n",
bw_cap / 1000, bw_cap % 1000,
PCIE_SPEED2STR(speed_cap), width_cap);
- else
+ else if (bw_avail < bw_cap)
pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
bw_avail / 1000, bw_avail % 1000,
PCIE_SPEED2STR(speed), width,
@@ -5331,6 +5332,19 @@ void pcie_print_link_status(struct pci_dev *dev)
bw_cap / 1000, bw_cap % 1000,
PCIE_SPEED2STR(speed_cap), width_cap);
}
+
+/**
+ * pcie_print_link_status - Report the PCI device's link speed and width
+ * @dev: PCI device to query
+ *
+ * Report the available bandwidth at the device. If this is less than the
+ * device is capable of, report the device's maximum possible bandwidth and
+ * the upstream link that limits its performance to less than that.
+ */
+void pcie_print_link_status(struct pci_dev *dev)
+{
+ __pcie_print_link_status(dev, true);
+}
EXPORT_SYMBOL(pcie_print_link_status);
/**
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac876e32de4b..1f7336377c3b 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2205,6 +2205,24 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn)
return dev;
}
+static void pcie_check_upstream_link(struct pci_dev *dev)
+{
+ if (!pci_is_pcie(dev))
+ return;
+
+ /* Look from the device up to avoid downstream ports with no devices. */
+ if ((pci_pcie_type(dev) != PCI_EXP_TYPE_ENDPOINT) &&
+ (pci_pcie_type(dev) != PCI_EXP_TYPE_LEG_END) &&
+ (pci_pcie_type(dev) != PCI_EXP_TYPE_UPSTREAM))
+ return;
+
+ /* Multi-function PCIe share the same link/status. */
+ if (PCI_FUNC(dev->devfn) != 0 || dev->is_virtfn)
+ return;
+
+ __pcie_print_link_status(dev, false);
+}
+
static void pci_init_capabilities(struct pci_dev *dev)
{
/* Enhanced Allocation */
@@ -2240,6 +2258,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
/* Advanced Error Reporting */
pci_aer_init(dev);
+ /* Check link and detect downtrain errors */
+ pcie_check_upstream_link(dev);
+
if (pci_probe_reset_function(dev) == 0)
dev->reset_fn = 1;
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index abd5d5e17aee..15bfab8f7a1b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1088,6 +1088,7 @@ int pcie_set_mps(struct pci_dev *dev, int mps);
u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev **limiting_dev,
enum pci_bus_speed *speed,
enum pcie_link_width *width);
+void __pcie_print_link_status(struct pci_dev *dev, bool verbose);
void pcie_print_link_status(struct pci_dev *dev);
int pcie_flr(struct pci_dev *dev);
int __pci_reset_function_locked(struct pci_dev *dev);
--
2.17.1
^ permalink raw reply related
* Re: Linux 4.18-rc6
From: David Miller @ 2018-07-23 21:06 UTC (permalink / raw)
To: torvalds; +Cc: linux, schwidefsky, linux-kernel
In-Reply-To: <CA+55aFyuaEGGksOxv3aAp0THYkAapap-JY65A0A81S0qUE0S+g@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 23 Jul 2018 13:56:15 -0700
> Hmm. I assume it's
>
> arch/sparc/include/asm/cacheflush_32.h
>
> that wants a forward-declaration of 'struct page', and doesn't include
> any header files.
>
> The fix is presumably to move the
>
> #include <asm/cacheflush.h>
>
> in drivers/staging/media/omap4iss/iss_video.c down to below the
> <linux/*> includes?
>
> The old patchwork link you had for a fix no longer works, I think
> because the patchwork database got re-generated during the upgrade
> (and the patchwork numbering isn't stable).
I think modifying the include order in that driver is the best fix.
BTW, here is a proper patchwork link in the SPARC project on ozlabs:
http://patchwork.ozlabs.org/patch/947434/
^ permalink raw reply
* Re: [PATCH mlx5-next v2 2/8] net/mlx5: Add support for flow table destination number
From: Saeed Mahameed @ 2018-07-23 21:05 UTC (permalink / raw)
To: Jason Gunthorpe, leon@kernel.org, dledford@redhat.com
Cc: netdev@vger.kernel.org, Leon Romanovsky,
linux-rdma@vger.kernel.org, Yishai Hadas
In-Reply-To: <20180723122512.20967-3-leon@kernel.org>
On Mon, 2018-07-23 at 15:25 +0300, Leon Romanovsky wrote:
> From: Yishai Hadas <yishaih@mellanox.com>
>
> Add support to set a destination from a flow table number.
> This functionality will be used in downstream patches from this
> series by the DEVX stuff.
>
> Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> .../mellanox/mlx5/core/diag/fs_tracepoint.c | 3 +++
> drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c | 24
> ++++++++++++++--------
> drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 4 +++-
> include/linux/mlx5/fs.h | 1 +
> include/linux/mlx5/mlx5_ifc.h | 1 +
> 5 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git
> a/drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.c
> b/drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.c
> index b3820a34e773..0f11fff32a9b 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.c
> @@ -240,6 +240,9 @@ const char *parse_fs_dst(struct trace_seq *p,
> case MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE:
> trace_seq_printf(p, "ft=%p\n", dst->ft);
> break;
> + case MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE_NUM:
> + trace_seq_printf(p, "ft_num=%u\n", dst->ft_num);
> + break;
> case MLX5_FLOW_DESTINATION_TYPE_TIR:
> trace_seq_printf(p, "tir=%u\n", dst->tir_num);
> break;
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
> b/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
> index 5a00deff5457..910d25f84f2f 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
> @@ -362,18 +362,20 @@ static int mlx5_cmd_set_fte(struct
> mlx5_core_dev *dev,
> int list_size = 0;
>
> list_for_each_entry(dst, &fte->node.children,
> node.list) {
> - unsigned int id;
> + unsigned int id, type = dst->dest_attr.type;
>
> - if (dst->dest_attr.type ==
> MLX5_FLOW_DESTINATION_TYPE_COUNTER)
> + if (type ==
> MLX5_FLOW_DESTINATION_TYPE_COUNTER)
> continue;
>
> - MLX5_SET(dest_format_struct, in_dests,
> destination_type,
> - dst->dest_attr.type);
> - if (dst->dest_attr.type ==
> - MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE) {
> + switch (type) {
> + case
> MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE_NUM:
> + id = dst->dest_attr.ft_num;
> + type =
> MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE;
> + break;
> + case MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE:
> id = dst->dest_attr.ft->id;
> - } else if (dst->dest_attr.type ==
> - MLX5_FLOW_DESTINATION_TYPE_VPORT)
> {
> + break;
> + case MLX5_FLOW_DESTINATION_TYPE_VPORT:
> id = dst->dest_attr.vport.num;
> MLX5_SET(dest_format_struct,
> in_dests,
> destination_eswitch_owner_v
> hca_id_valid,
> @@ -381,9 +383,13 @@ static int mlx5_cmd_set_fte(struct mlx5_core_dev
> *dev,
> MLX5_SET(dest_format_struct,
> in_dests,
> destination_eswitch_owner_v
> hca_id,
> dst-
> >dest_attr.vport.vhca_id);
> - } else {
> + break;
> + default:
> id = dst->dest_attr.tir_num;
> }
> +
> + MLX5_SET(dest_format_struct, in_dests,
> destination_type,
> + type);
> MLX5_SET(dest_format_struct, in_dests,
> destination_id, id);
> in_dests +=
> MLX5_ST_SZ_BYTES(dest_format_struct);
> list_size++;
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> index eba113cf1117..69aa298a0b1c 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> @@ -1356,7 +1356,9 @@ static bool mlx5_flow_dests_cmp(struct
> mlx5_flow_destination *d1,
> (d1->type ==
> MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE &&
> d1->ft == d2->ft) ||
> (d1->type == MLX5_FLOW_DESTINATION_TYPE_TIR &&
> - d1->tir_num == d2->tir_num))
> + d1->tir_num == d2->tir_num) ||
> + (d1->type ==
> MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE_NUM &&
> + d1->ft_num == d2->ft_num))
> return true;
> }
>
> diff --git a/include/linux/mlx5/fs.h b/include/linux/mlx5/fs.h
> index 757b4a30281e..a45febcf6b51 100644
> --- a/include/linux/mlx5/fs.h
> +++ b/include/linux/mlx5/fs.h
> @@ -89,6 +89,7 @@ struct mlx5_flow_destination {
> enum mlx5_flow_destination_type type;
> union {
> u32 tir_num;
> + u32 ft_num;
> struct mlx5_flow_table *ft;
> struct mlx5_fc *counter;
> struct {
> diff --git a/include/linux/mlx5/mlx5_ifc.h
> b/include/linux/mlx5/mlx5_ifc.h
> index 44a6ce01c3bb..fb89cc519703 100644
> --- a/include/linux/mlx5/mlx5_ifc.h
> +++ b/include/linux/mlx5/mlx5_ifc.h
> @@ -1181,6 +1181,7 @@ enum mlx5_flow_destination_type {
>
> MLX5_FLOW_DESTINATION_TYPE_PORT = 0x99,
> MLX5_FLOW_DESTINATION_TYPE_COUNTER = 0x100,
> + MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE_NUM = 0x101,
> };
>
> struct mlx5_ifc_dest_format_struct_bits {
^ permalink raw reply
* Re: [PATCH 01/12] i2c: quirks: add zero length checks
From: Wolfram Sang @ 2018-07-23 21:05 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Wolfram Sang, linux-i2c, linux-renesas-soc, linux-kernel
In-Reply-To: <20180723204418.GG1432@bigcity.dyn.berto.se>
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
> > Only build tested.
>
> Was this not tested when you also tested i2c-rcar and i2c-sh_mobile
> drivers? In any case I think this change make much sens.
>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
You are right, of course. This text was added by a script and I forgot to
remove it :( This code was tested!
Thanks for the review!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH mlx5-next v2 1/8] net/mlx5: Add forward compatible support for the FTE match data
From: Saeed Mahameed @ 2018-07-23 21:05 UTC (permalink / raw)
To: Jason Gunthorpe, leon@kernel.org, dledford@redhat.com
Cc: netdev@vger.kernel.org, Leon Romanovsky,
linux-rdma@vger.kernel.org, Yishai Hadas
In-Reply-To: <20180723122512.20967-2-leon@kernel.org>
On Mon, 2018-07-23 at 15:25 +0300, Leon Romanovsky wrote:
> From: Yishai Hadas <yishaih@mellanox.com>
>
> Use the PRM size including the reserved when working with the FTE
> match data.
>
> This comes to support forward compatibility for cases that current
> reserved data will be exposed by the firmware by an application that
> uses the DEVX API without changing the kernel.
>
> Also drop some driver checks around the match criteria leaving the
> work
> for firmware to enable forward compatibility for future bits there.
>
> Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 77 +----------
> ------------
> 1 file changed, 1 insertion(+), 76 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> index 49a75d31185e..eba113cf1117 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> @@ -309,89 +309,17 @@ static struct fs_prio *find_prio(struct
> mlx5_flow_namespace *ns,
> return NULL;
> }
>
> -static bool check_last_reserved(const u32 *match_criteria)
> -{
> - char *match_criteria_reserved =
> - MLX5_ADDR_OF(fte_match_param, match_criteria,
> MLX5_FTE_MATCH_PARAM_RESERVED);
> -
> - return !match_criteria_reserved[0] &&
> - !memcmp(match_criteria_reserved,
> match_criteria_reserved + 1,
> - MLX5_FLD_SZ_BYTES(fte_match_param,
> - MLX5_FTE_MATCH_PARAM_RESER
> VED) - 1);
> -}
> -
> -static bool check_valid_mask(u8 match_criteria_enable, const u32
> *match_criteria)
> -{
> - if (match_criteria_enable & ~(
> - (1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_OUTER_HEADERS) |
> - (1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_MISC_PARAMETERS) |
> - (1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_INNER_HEADERS) |
> - (1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_MISC_PARAMETERS_2)))
> - return false;
> -
> - if (!(match_criteria_enable &
> - 1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_OUTER_HEADERS)) {
> - char *fg_type_mask = MLX5_ADDR_OF(fte_match_param,
> - match_criteria,
> outer_headers);
> -
> - if (fg_type_mask[0] ||
> - memcmp(fg_type_mask, fg_type_mask + 1,
> - MLX5_ST_SZ_BYTES(fte_match_set_lyr_2_4) -
> 1))
> - return false;
> - }
> -
> - if (!(match_criteria_enable &
> - 1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_MISC_PARAMETERS)) {
> - char *fg_type_mask = MLX5_ADDR_OF(fte_match_param,
> - match_criteria,
> misc_parameters);
> -
> - if (fg_type_mask[0] ||
> - memcmp(fg_type_mask, fg_type_mask + 1,
> - MLX5_ST_SZ_BYTES(fte_match_set_misc) -
> 1))
> - return false;
> - }
> -
> - if (!(match_criteria_enable &
> - 1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_INNER_HEADERS)) {
> - char *fg_type_mask = MLX5_ADDR_OF(fte_match_param,
> - match_criteria,
> inner_headers);
> -
> - if (fg_type_mask[0] ||
> - memcmp(fg_type_mask, fg_type_mask + 1,
> - MLX5_ST_SZ_BYTES(fte_match_set_lyr_2_4) -
> 1))
> - return false;
> - }
> -
> - if (!(match_criteria_enable &
> - 1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_MISC_PARAMETERS_2)) {
> - char *fg_type_mask = MLX5_ADDR_OF(fte_match_param,
> - match_criteria,
> misc_parameters_2);
> -
> - if (fg_type_mask[0] ||
> - memcmp(fg_type_mask, fg_type_mask + 1,
> - MLX5_ST_SZ_BYTES(fte_match_set_misc2) -
> 1))
> - return false;
> - }
> -
> - return check_last_reserved(match_criteria);
> -}
> -
> static bool check_valid_spec(const struct mlx5_flow_spec *spec)
> {
> int i;
>
> - if (!check_valid_mask(spec->match_criteria_enable, spec-
> >match_criteria)) {
> - pr_warn("mlx5_core: Match criteria given mismatches
> match_criteria_enable\n");
> - return false;
> - }
> -
> for (i = 0; i < MLX5_ST_SZ_DW_MATCH_PARAM; i++)
> if (spec->match_value[i] & ~spec->match_criteria[i])
> {
> pr_warn("mlx5_core: match_value differs from
> match_criteria\n");
> return false;
> }
>
> - return check_last_reserved(spec->match_value);
> + return true;
> }
>
> static struct mlx5_flow_root_namespace *find_root(struct fs_node
> *node)
> @@ -1158,9 +1086,6 @@ struct mlx5_flow_group
> *mlx5_create_flow_group(struct mlx5_flow_table *ft,
> struct mlx5_flow_group *fg;
> int err;
>
> - if (!check_valid_mask(match_criteria_enable,
> match_criteria))
> - return ERR_PTR(-EINVAL);
> -
> if (ft->autogroup.active)
> return ERR_PTR(-EPERM);
>
^ permalink raw reply
* [PATCH v2] PCI/AER: Do not clear AER bits if we don't own AER
From: Alexandru Gagniuc @ 2018-07-23 20:01 UTC (permalink / raw)
To: linux-pci, bhelgaas
Cc: keith.busch, alex_gagniuc, austin_bolen, shyam_iyer,
jeffrey.t.kirsher, ariel.elior, michael.chan, ganeshgr, tariqt,
jakub.kicinski, airlied, alexander.deucher, mike.marciniszyn,
Alexandru Gagniuc, Frederick Lawler, Oza Pawandeep,
Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20180718215359.GG128988@bhelgaas-glaptop.roam.corp.google.com>
When we don't own AER, we shouldn't touch the AER error bits. Clearing
error bits willy-nilly might cause firmware to miss some errors. In
theory, these bits get cleared by FFS, or via ACPI _HPX method. These
mechanisms are not subject to the problem.
This race is mostly of theoretical significance, since I can't
reasonably demonstrate this race in the lab.
On a side-note, pcie_aer_is_kernel_first() is created to alleviate the
need for two checks: aer_cap and get_firmware_first().
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
---
drivers/pci/pcie/aer.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index a2e88386af28..85c3e173c025 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -307,6 +307,12 @@ int pcie_aer_get_firmware_first(struct pci_dev *dev)
aer_set_firmware_first(dev);
return dev->__aer_firmware_first;
}
+
+static bool pcie_aer_is_kernel_first(struct pci_dev *dev)
+{
+ return !!dev->aer_cap && !pcie_aer_get_firmware_first(dev);
+}
+
#define PCI_EXP_AER_FLAGS (PCI_EXP_DEVCTL_CERE | PCI_EXP_DEVCTL_NFERE | \
PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
@@ -337,10 +343,7 @@ bool aer_acpi_firmware_first(void)
int pci_enable_pcie_error_reporting(struct pci_dev *dev)
{
- if (pcie_aer_get_firmware_first(dev))
- return -EIO;
-
- if (!dev->aer_cap)
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_AER_FLAGS);
@@ -349,7 +352,7 @@ EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting);
int pci_disable_pcie_error_reporting(struct pci_dev *dev)
{
- if (pcie_aer_get_firmware_first(dev))
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
@@ -383,10 +386,10 @@ int pci_cleanup_aer_error_status_regs(struct pci_dev *dev)
if (!pci_is_pcie(dev))
return -ENODEV;
- pos = dev->aer_cap;
- if (!pos)
+ if (pcie_aer_is_kernel_first(dev))
return -EIO;
+ pos = dev->aer_cap;
port_type = pci_pcie_type(dev);
if (port_type == PCI_EXP_TYPE_ROOT_PORT) {
pci_read_config_dword(dev, pos + PCI_ERR_ROOT_STATUS, &status);
--
2.17.1
^ permalink raw reply related
* [Intel-wired-lan] [RFC PATCH jkirsher-next-queue] i40e: len_ethhdr can be static
From: kbuild test robot @ 2018-07-23 21:04 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <201807240548.0XzJcSzH%fengguang.wu@intel.com>
Fixes: 58e0270bb7ac ("i40e: Initial support to add hw hints for xdp")
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
i40e_txrx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 09536d7e7..ab8b97f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2296,9 +2296,9 @@ static inline void i40e_xdp_ring_update_tail(struct i40e_ring *xdp_ring)
writel_relaxed(xdp_ring->next_to_use, xdp_ring->tail);
};
-const size_t len_ethhdr = sizeof(struct ethhdr);
-const size_t len_ipv4hdr = sizeof(struct iphdr);
-const size_t len_ipv6hdr = sizeof(struct ipv6hdr);
+static const size_t len_ethhdr = sizeof(struct ethhdr);
+static const size_t len_ipv4hdr = sizeof(struct iphdr);
+static const size_t len_ipv6hdr = sizeof(struct ipv6hdr);
enum XDP_META_PTYPE
{
^ permalink raw reply related
* [Intel-wired-lan] [jkirsher-next-queue:XDP-hints-EXPERIMENTAL 1/1] drivers/net/ethernet/intel/i40e/i40e_txrx.c:2299:14: sparse: symbol 'len_ethhdr' was not declared. Should it be static?
From: kbuild test robot @ 2018-07-23 21:04 UTC (permalink / raw)
To: intel-wired-lan
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git XDP-hints-EXPERIMENTAL
head: 58e0270bb7ac94a31ff0fe372385cfce4198b56c
commit: 58e0270bb7ac94a31ff0fe372385cfce4198b56c [1/1] i40e: Initial support to add hw hints for xdp
reproduce:
# apt-get install sparse
git checkout 58e0270bb7ac94a31ff0fe372385cfce4198b56c
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/intel/i40e/i40e_txrx.c:1118:23: sparse: expression using sizeof(void)
drivers/net/ethernet/intel/i40e/i40e_txrx.c:1118:23: sparse: expression using sizeof(void)
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2299:14: sparse: symbol 'len_ethhdr' was not declared. Should it be static?
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2300:14: sparse: symbol 'len_ipv4hdr' was not declared. Should it be static?
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2301:14: sparse: symbol 'len_ipv6hdr' was not declared. Should it be static?
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2346:38: sparse: missing braces around initializer
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2350:47: sparse: incorrect type in initializer (different base types) @@ expected unsigned long long [unsigned] [usertype] stserr @@ got g long [unsigned] [usertype] stserr @@
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2350:47: expected unsigned long long [unsigned] [usertype] stserr
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2350:47: got restricted __le64 [usertype] status_error_len
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2438:36: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [unsigned] [assigned] [usertype] hash @@ got igned] [assigned] [usertype] hash @@
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2438:36: expected unsigned int [unsigned] [assigned] [usertype] hash
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2438:36: got restricted __le32 [usertype] rss
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2761:27: sparse: expression using sizeof(void)
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2809:16: sparse: expression using sizeof(void)
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2809:16: sparse: expression using sizeof(void)
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH v4 00/21] Add `range-diff`, a `tbdiff` lookalike
From: Stefan Beller @ 2018-07-23 21:03 UTC (permalink / raw)
To: gitgitgadget; +Cc: git, Junio C Hamano
In-Reply-To: <pull.1.v4.git.gitgitgadget@gmail.com>
On Sat, Jul 21, 2018 at 3:04 PM Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> Side note: I work on implementing range-diff not only to make life easier for reviewers who have to suffer through v2, v3, ... of my patch series, but also to verify my changes before submitting a new iteration. And also, maybe even more importantly, I plan to use it to verify my merging-rebases of Git for
> Windows (for which I previously used to redirect the pre-rebase/post-rebase diffs vs upstream and then compare them using `git diff --no-index`). And of course any interested person can see what changes were necessary e.g. in the merging-rebase of Git for Windows onto v2.17.0 by running a command like:
Thanks for making tools that makes the life of a Git developer easier!
(Just filed https://github.com/gitgitgadget/gitgitgadget/issues/26
which asks to break lines for this cover letter)
> base-commit: b7bd9486b055c3f967a870311e704e3bb0654e4f
> Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-1%2Fdscho%2Fbranch-diff-v4
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1/dscho/branch-diff-v4
> Pull-Request: https://github.com/gitgitgadget/git/pull/1
I just realized that if I had ideal memory of the previous review,
I could contain my whole review answer to this email only.
>
> Range-diff vs v3:
>
> 1: 39272eefc ! 1: f7e70689e linear-assignment: a function to solve least-cost assignment problems
> @@ -223,9 +223,7 @@
> + BUG("negative j: %d", j);
> + i = pred[j];
> + column2row[j] = i;
> -+ k = j;
> -+ j = row2column[i];
> -+ row2column[i] = k;
> ++ SWAP(j, row2column[i]);
The dual color option (as a default) really helps here. Thanks for that!
Does it have to be renamed though? (It's more than two colors; originally
it was inverting the beginning signs)
Maybe --color=emphasize-later
assuming there will be other modes for coloring, such as "diff-only",
which would correspond with --no-dual-color, or "none" that will correspond
would be --no-color. I imagine there could be more fancy things, hence I would
propose a mode rather than a switch.
(Feel free to push back if discussing naming here feels like bike shedding)
2: 7f15b26d4ea ! 82: 88134121d2a Introduce `range-diff` to compare
iterations of a topic branch
[...]
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
The line starting with --- is red (default removed color) and the line
with +++ is green (default add color).
Ideally these two lines and the third line above starting with "diff --git"
would render in GIT_COLOR_BOLD ("METAINFO").
> 3: 076e1192d ! 3: 4e3fb47a1 range-diff: first rudimentary implementation
> @@ -4,7 +4,7 @@
>
> At this stage, `git range-diff` can determine corresponding commits
> of two related commit ranges. This makes use of the recently introduced
> - implementation of the Hungarian algorithm.
> + implementation of the linear assignment algorithm.
>
> The core of this patch is a straight port of the ideas of tbdiff, the
> apparently dormant project at https://github.com/trast/tbdiff.
> @@ -51,19 +51,17 @@
> + int res = 0;
> + struct strbuf range1 = STRBUF_INIT, range2 = STRBUF_INIT;
>
> -- argc = parse_options(argc, argv, NULL, options,
> -- builtin_range_diff_usage, 0);
> -+ argc = parse_options(argc, argv, NULL, options, builtin_range_diff_usage,
> -+ 0);
> + argc = parse_options(argc, argv, NULL, options,
> + builtin_range_diff_usage, 0);
This is really nice in colors when viewed locally.
> 16: dfa7b1e71 < -: --------- range-diff --dual-color: work around bogus white-space warning
> -: --------- > 16: f4252f2b2 range-diff --dual-color: fix bogus white-space warning
Ah; here my initial assumption of only reviewing the range-diff breaks down now.
I'll dig into patch 16 separately.
Maybe it is worth having an option to expand all "new" patches.
(Given that the range-diff pr-1/dscho/branch-diff-v3...pr-1/dscho/branch-diff-v4
told me you used a different base, this is a hard problem, as I certainly
would want to skip over all new base commits, but this one is interesting
to look at. An easy way out: Maybe an option to expand any new
commits/patches after the first expansion? Asking for opinions rather
than implementing it)
> 19: 144363006 < -: --------- range-diff: left-pad patch numbers
> -: --------- > 19: 07ec215e8 range-diff: left-pad patch numbers
> -: --------- > 21: d8498fb32 range-diff: use dim/bold cues to improve dual color mode
Those are interesting, I'll look at them separately, too.
Thanks,
Stefan
^ permalink raw reply
* Re: linux-next: Tree for Jul 23
From: Stephen Rothwell @ 2018-07-23 21:03 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <877elmhvf9.fsf@concordia.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
Hi Michael,
On Tue, 24 Jul 2018 00:35:22 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Would you mind adding my "topic/hvc" branch to linux-next.
>
> We (ppc) are notionally the maintainers for that code but it's used by
> some other folks, so I'd like it to get some wider testing before I
> commit it.
>
> You should get:
>
> 9f65b81f36e3 ("tty: hvc: introduce the hv_ops.flush operation for hvc drivers")
Added from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgement of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5] PCI: Check for PCIe downtraining conditions
From: Jakub Kicinski @ 2018-07-23 21:01 UTC (permalink / raw)
To: Alexandru Gagniuc
Cc: linux-pci, bhelgaas, keith.busch, alex_gagniuc, austin_bolen,
shyam_iyer, jeffrey.t.kirsher, ariel.elior, michael.chan,
ganeshgr, tariqt, airlied, alexander.deucher, mike.marciniszyn,
linux-kernel
In-Reply-To: <20180723200339.23943-1-mr.nuke.me@gmail.com>
On Mon, 23 Jul 2018 15:03:38 -0500, Alexandru Gagniuc wrote:
> PCIe downtraining happens when both the device and PCIe port are
> capable of a larger bus width or higher speed than negotiated.
> Downtraining might be indicative of other problems in the system, and
> identifying this from userspace is neither intuitive, nor
> straightforward.
>
> The easiest way to detect this is with pcie_print_link_status(),
> since the bottleneck is usually the link that is downtrained. It's not
> a perfect solution, but it works extremely well in most cases.
>
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>
> For the sake of review, I've created a __pcie_print_link_status() which
> takes a 'verbose' argument. If we agree want to go this route, and update
> the users of pcie_print_link_status(), I can split this up in two patches.
> I prefer just printing this information in the core functions, and letting
> drivers not have to worry about this. Though there seems to be strong for
> not going that route, so here it goes:
FWIW the networking drivers print PCIe BW because sometimes the network
bandwidth is simply over-provisioned on multi port cards, e.g. 80Gbps
card on a x8 link.
Sorry to bike shed, but currently the networking cards print the info
during probe. Would it make sense to move your message closer to probe
time? Rather than when device is added. If driver structure is
available, we could also consider adding a boolean to struct pci_driver
to indicate if driver wants the verbose message? This way we avoid
duplicated prints.
I have no objection to current patch, it LGTM. Just a thought.
> drivers/pci/pci.c | 22 ++++++++++++++++++----
> drivers/pci/probe.c | 21 +++++++++++++++++++++
> include/linux/pci.h | 1 +
> 3 files changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 316496e99da9..414ad7b3abdb 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5302,14 +5302,15 @@ u32 pcie_bandwidth_capable(struct pci_dev *dev, enum pci_bus_speed *speed,
> }
>
> /**
> - * pcie_print_link_status - Report the PCI device's link speed and width
> + * __pcie_print_link_status - Report the PCI device's link speed and width
> * @dev: PCI device to query
> + * @verbose: Be verbose -- print info even when enough bandwidth is available.
> *
> * Report the available bandwidth at the device. If this is less than the
> * device is capable of, report the device's maximum possible bandwidth and
> * the upstream link that limits its performance to less than that.
> */
> -void pcie_print_link_status(struct pci_dev *dev)
> +void __pcie_print_link_status(struct pci_dev *dev, bool verbose)
> {
> enum pcie_link_width width, width_cap;
> enum pci_bus_speed speed, speed_cap;
> @@ -5319,11 +5320,11 @@ void pcie_print_link_status(struct pci_dev *dev)
> bw_cap = pcie_bandwidth_capable(dev, &speed_cap, &width_cap);
> bw_avail = pcie_bandwidth_available(dev, &limiting_dev, &speed, &width);
>
> - if (bw_avail >= bw_cap)
> + if (bw_avail >= bw_cap && verbose)
> pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth (%s x%d link)\n",
> bw_cap / 1000, bw_cap % 1000,
> PCIE_SPEED2STR(speed_cap), width_cap);
> - else
> + else if (bw_avail < bw_cap)
> pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
> bw_avail / 1000, bw_avail % 1000,
> PCIE_SPEED2STR(speed), width,
> @@ -5331,6 +5332,19 @@ void pcie_print_link_status(struct pci_dev *dev)
> bw_cap / 1000, bw_cap % 1000,
> PCIE_SPEED2STR(speed_cap), width_cap);
> }
> +
> +/**
> + * pcie_print_link_status - Report the PCI device's link speed and width
> + * @dev: PCI device to query
> + *
> + * Report the available bandwidth at the device. If this is less than the
> + * device is capable of, report the device's maximum possible bandwidth and
> + * the upstream link that limits its performance to less than that.
> + */
> +void pcie_print_link_status(struct pci_dev *dev)
> +{
> + __pcie_print_link_status(dev, true);
> +}
> EXPORT_SYMBOL(pcie_print_link_status);
>
> /**
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ac876e32de4b..1f7336377c3b 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2205,6 +2205,24 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn)
> return dev;
> }
>
> +static void pcie_check_upstream_link(struct pci_dev *dev)
> +{
> + if (!pci_is_pcie(dev))
> + return;
> +
> + /* Look from the device up to avoid downstream ports with no devices. */
> + if ((pci_pcie_type(dev) != PCI_EXP_TYPE_ENDPOINT) &&
> + (pci_pcie_type(dev) != PCI_EXP_TYPE_LEG_END) &&
> + (pci_pcie_type(dev) != PCI_EXP_TYPE_UPSTREAM))
> + return;
> +
> + /* Multi-function PCIe share the same link/status. */
> + if (PCI_FUNC(dev->devfn) != 0 || dev->is_virtfn)
> + return;
> +
> + __pcie_print_link_status(dev, false);
> +}
> +
> static void pci_init_capabilities(struct pci_dev *dev)
> {
> /* Enhanced Allocation */
> @@ -2240,6 +2258,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
> /* Advanced Error Reporting */
> pci_aer_init(dev);
>
> + /* Check link and detect downtrain errors */
> + pcie_check_upstream_link(dev);
> +
> if (pci_probe_reset_function(dev) == 0)
> dev->reset_fn = 1;
> }
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index abd5d5e17aee..15bfab8f7a1b 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1088,6 +1088,7 @@ int pcie_set_mps(struct pci_dev *dev, int mps);
> u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev **limiting_dev,
> enum pci_bus_speed *speed,
> enum pcie_link_width *width);
> +void __pcie_print_link_status(struct pci_dev *dev, bool verbose);
> void pcie_print_link_status(struct pci_dev *dev);
> int pcie_flr(struct pci_dev *dev);
> int __pci_reset_function_locked(struct pci_dev *dev);
^ permalink raw reply
* Re: [PATCH bpf] xdp: add NULL pointer check in __xdp_return()
From: Jakub Kicinski @ 2018-07-23 19:58 UTC (permalink / raw)
To: Björn Töpel
Cc: Daniel Borkmann, Björn Töpel, Jesper Dangaard Brouer,
kafai, ap420073, ast, Netdev, Karlsson, Magnus
In-Reply-To: <CAJ+HfNh5BLoqhJWkiDf7-mVxuPrOgAyGp6=8e5jOOOvVkb9+HA@mail.gmail.com>
On Mon, 23 Jul 2018 11:39:36 +0200, Björn Töpel wrote:
> Den fre 20 juli 2018 kl 22:08 skrev Jakub Kicinski:
> > On Fri, 20 Jul 2018 10:18:21 -0700, Martin KaFai Lau wrote:
> > > On Sat, Jul 21, 2018 at 01:04:45AM +0900, Taehee Yoo wrote:
> > > > rhashtable_lookup() can return NULL. so that NULL pointer
> > > > check routine should be added.
> > > >
> > > > Fixes: 02b55e5657c3 ("xdp: add MEM_TYPE_ZERO_COPY")
> > > > Signed-off-by: Taehee Yoo <ap420073@gmail.com>
> > > > ---
> > > > net/core/xdp.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/core/xdp.c b/net/core/xdp.c
> > > > index 9d1f220..1c12bc7 100644
> > > > --- a/net/core/xdp.c
> > > > +++ b/net/core/xdp.c
> > > > @@ -345,7 +345,8 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> > > > rcu_read_lock();
> > > > /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
> > > > xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
> > > > - xa->zc_alloc->free(xa->zc_alloc, handle);
> > > > + if (xa)
> > > > + xa->zc_alloc->free(xa->zc_alloc, handle);
> > > hmm...It is not clear to me the "!xa" case don't have to be handled?
> >
> > Actually I have a more fundamental question about this interface I've
> > been meaning to ask.
> >
> > IIUC free() can happen on any CPU at any time, when whatever device,
> > socket or CPU this got redirected to completed the TX. IOW there may
> > be multiple producers. Drivers would need to create spin lock a'la the
> > a9744f7ca200 ("xsk: fix potential race in SKB TX completion code") fix?
> >
>
> Jakub, apologies for the slow response. I'm still in
> "holiday/hammock&beer mode", but will be back in a week. :-P
Ah, sorry to interrupt! :)
> The idea with the xdp_return_* functions are that an xdp_buff and
> xdp_frame can have custom allocations schemes. The difference beween
> struct xdp_buff and struct xdp_frame is lifetime. The xdp_buff
> lifetime is within the napi context, whereas xdp_frame can have a
> lifetime longer/outside the napi context. E.g. for a XDP_REDIRECT
> scenario an xdp_buff is converted to a xdp_frame. The conversion is
> done in include/net/xdp.h:convert_to_xdp_frame.
>
> Currently, the zero-copy MEM_TYPE_ZERO_COPY memtype can *only* be used
> for xdp_buff, meaning that the lifetime is constrained to a napi
> context. Further, given an xdp_buff with memtype MEM_TYPE_ZERO_COPY,
> doing XDP_REDIRECT to a target that is *not* an AF_XDP socket would
> mean converting the xdp_buff to an xdp_frame. The xdp_frame can then
> be free'd on any CPU.
>
> Note that the xsk_rcv* functions is always called from an napi
> context, and therefore is using the xdp_return_buff calls.
>
> To answer your question -- no, this fix is *not* needed, because the
> xdp_buff napi constrained, and the xdp_buff will only be free'd on one
> CPU.
Oh, thanks, I missed the check in convert_to_xdp_frame(), so the only
frames which can come back via the free path are out of the error path
in __xsk_rcv_zc()?
That path looks a little surprising too, isn't the expectation that if
xdp_do_redirect() returns an error the driver retains the ownership of
the buffer?
static int __xsk_rcv_zc(struct xdp_sock *xs, struct xdp_buff *xdp, u32 len)
{
int err = xskq_produce_batch_desc(xs->rx, (u64)xdp->handle, len);
if (err) {
xdp_return_buff(xdp);
xs->rx_dropped++;
}
return err;
}
This seems to call xdp_return_buff() *and* return an error.
> > We need some form of internal kernel circulation which would be MPSC.
> > I'm currently hacking up the XSK code to tell me whether the frame was
> > consumed by the correct XSK, and always clone the frame otherwise
> > (claiming to be the "traditional" MEM_TYPE_PAGE_ORDER0).
> >
> > I feel like I'm missing something about the code. Is redirect of
> > ZC/UMEM frame outside the xsk not possible and the only returns we will
> > see are from net/xdp/xsk.c? That would work, but I don't see such a
> > check. Help would be appreciated.
> >
>
> Right now, this is the case (refer to the TODO in
> convert_to_xdp_frame), i.e. you cannot redirect an ZC/UMEM allocated
> xdp_buff to a target that is not an xsk. This must, obviously, change
> so that an xdp_buff (of MEM_TYPE_ZERO_COPY) can be converted to an
> xdp_frame. The xdp_frame must be able to be free'd from multiple CPUs,
> so here the a more sophisticated allocation scheme is required.
>
> > Also the fact that XSK bufs can't be freed, only completed, adds to the
> > pain of implementing AF_XDP, we'd certainly need some form of "give
> > back the frame, but I may need it later" SPSC mechanism, otherwise
> > driver writers will have tough time. Unless, again, I'm missing
> > something about the code :)
> >
>
> Yup, moving the recycling scheme from driver to "generic" is a good
> idea! I need to finish up those i40e zerocopy patches first though...
Interesting, FWIW I wasn't necessarily thinking about full recycling,
although that would be the holy grail. Just a generic way of giving up
buffers for example when user changes ring sizes or brings the device
down.
> (...and I'm very excited that you're doing nfp support for AF_XDP!!!)
Thanks, I'm still way out in the weeds but it's interesting work :)
^ permalink raw reply
* [PATCH] net: sort Kconfig menu items alphabetically
From: Bjorn Helgaas @ 2018-07-23 21:01 UTC (permalink / raw)
To: David S. Miller
Cc: Florian Fainelli, Rasesh Mody, Sudarsana Kalluru, Jon Mason,
Dept-GELinuxNICDev, netdev, linux-kernel
From: Bjorn Helgaas <bhelgaas@google.com>
6c541b4595a2 ("net: ethernet: Sort Kconfig sourcing alphabetically")
sorted Kconfig sourcing based on directory names, but in a couple cases,
the menu item text is quite different from the directory name and is not
sorted correctly:
drivers/net/ethernet/neterion/Kconfig => "Exar devices"
drivers/net/ethernet/brocade/Kconfig => "QLogic BR-series devices"
Move these entries so the Kconfig menu items are sorted.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/net/ethernet/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index af766fd61151..b21febba458e 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -34,7 +34,6 @@ source "drivers/net/ethernet/arc/Kconfig"
source "drivers/net/ethernet/atheros/Kconfig"
source "drivers/net/ethernet/aurora/Kconfig"
source "drivers/net/ethernet/broadcom/Kconfig"
-source "drivers/net/ethernet/brocade/Kconfig"
source "drivers/net/ethernet/cadence/Kconfig"
source "drivers/net/ethernet/calxeda/Kconfig"
source "drivers/net/ethernet/cavium/Kconfig"
@@ -71,6 +70,7 @@ config DNET
source "drivers/net/ethernet/dec/Kconfig"
source "drivers/net/ethernet/dlink/Kconfig"
source "drivers/net/ethernet/emulex/Kconfig"
+source "drivers/net/ethernet/neterion/Kconfig"
source "drivers/net/ethernet/ezchip/Kconfig"
source "drivers/net/ethernet/faraday/Kconfig"
source "drivers/net/ethernet/freescale/Kconfig"
@@ -81,7 +81,6 @@ source "drivers/net/ethernet/huawei/Kconfig"
source "drivers/net/ethernet/i825xx/Kconfig"
source "drivers/net/ethernet/ibm/Kconfig"
source "drivers/net/ethernet/intel/Kconfig"
-source "drivers/net/ethernet/neterion/Kconfig"
source "drivers/net/ethernet/xscale/Kconfig"
config JME
@@ -160,6 +159,7 @@ config ETHOC
source "drivers/net/ethernet/packetengines/Kconfig"
source "drivers/net/ethernet/pasemi/Kconfig"
source "drivers/net/ethernet/qlogic/Kconfig"
+source "drivers/net/ethernet/brocade/Kconfig"
source "drivers/net/ethernet/qualcomm/Kconfig"
source "drivers/net/ethernet/rdc/Kconfig"
source "drivers/net/ethernet/realtek/Kconfig"
^ permalink raw reply related
* Re: [RFC PATCH ghak59 V1 3/6] audit: exclude user records from syscall context
From: Paul Moore @ 2018-07-23 21:00 UTC (permalink / raw)
To: rgb; +Cc: Eric Paris, linux-audit, linux-kernel
In-Reply-To: <20180723164035.wkazolpmpf3mvdxw@madcap2.tricolour.ca>
On Mon, Jul 23, 2018 at 12:43 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2018-07-12 17:46, Richard Guy Briggs wrote:
> > On 2018-06-28 18:11, Paul Moore wrote:
> > > On Thu, Jun 14, 2018 at 4:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > > > Since the function audit_log_common_recv_msg() is shared by a number of
> > > > AUDIT_CONFIG_CHANGE and the entire range of AUDIT_USER_* record types,
> > > > and since the AUDIT_CONFIG_CHANGE message type has been converted to a
> > > > syscall accompanied record type, special-case the AUDIT_USER_* range of
> > > > messages so they remain standalone records.
> > > >
> > > > See: https://github.com/linux-audit/audit-kernel/issues/59
> > > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > > ---
> > > > kernel/audit.c | 12 +++++++++---
> > > > 1 file changed, 9 insertions(+), 3 deletions(-)
> > >
> > > I think this is fine, but see my previous comment about combining 2/6
> > > and 3/6 as a safety measure.
> >
> > This one I left as a seperate patch for discussion. We'd previously
> > talked about connecting all possible records with syscall records if
> > they exist, but this one I'm unsure about, since we don't really care
> > what userspace process is issuing this message. It is just the message
> > content itself that is important. Or is it? Are we concerned about
> > CAP_AUDIT_WRITE holders/abusers and want as much info about them as we
> > can get in case they go rogue or pear-shaped?
>
> I'm waiting on re-spinning this patchset because of this open question.
>
> Is connecting AUDIT_USER* records desirable or a liability?
Like I said, I think special casing the AUDIT_USER* records so they
are *not* associated with other records is okay, and perhaps even the
right thing to do. The problem is that we don't have the necessary
context (har har) to match any kernel events (and there is the
possibility that there are none) to the userspace generated
AUDIT_USER* event. Further, I don't think this is something we would
ever be able to solve in a reasonable manner.
> > > > diff --git a/kernel/audit.c b/kernel/audit.c
> > > > index e469234..c8c2efc 100644
> > > > --- a/kernel/audit.c
> > > > +++ b/kernel/audit.c
> > > > @@ -1057,7 +1057,8 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 msg_type)
> > > > return err;
> > > > }
> > > >
> > > > -static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > +static void __audit_log_common_recv_msg(struct audit_context *context,
> > > > + struct audit_buffer **ab, u16 msg_type)
> > > > {
> > > > uid_t uid = from_kuid(&init_user_ns, current_uid());
> > > > pid_t pid = task_tgid_nr(current);
> > > > @@ -1067,7 +1068,7 @@ static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > return;
> > > > }
> > > >
> > > > - *ab = audit_log_start(audit_context(), GFP_KERNEL, msg_type);
> > > > + *ab = audit_log_start(context, GFP_KERNEL, msg_type);
> > > > if (unlikely(!*ab))
> > > > return;
> > > > audit_log_format(*ab, "pid=%d uid=%u", pid, uid);
> > > > @@ -1075,6 +1076,11 @@ static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > audit_log_task_context(*ab);
> > > > }
> > > >
> > > > +static inline void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > +{
> > > > + __audit_log_common_recv_msg(audit_context(), ab, msg_type);
> > > > +}
> > > > +
> > > > int is_audit_feature_set(int i)
> > > > {
> > > > return af.features & AUDIT_FEATURE_TO_MASK(i);
> > > > @@ -1341,7 +1347,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> > > > if (err)
> > > > break;
> > > > }
> > > > - audit_log_common_recv_msg(&ab, msg_type);
> > > > + __audit_log_common_recv_msg(NULL, &ab, msg_type);
> > > > if (msg_type != AUDIT_USER_TTY)
> > > > audit_log_format(ab, " msg='%.*s'",
> > > > AUDIT_MESSAGE_TEXT_MAX,
> > > > --
> > > > 1.8.3.1
> > > >
> > >
> > >
> > > --
> > > paul moore
> > > www.paul-moore.com
> > >
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rgb@redhat.com>
> > Sr. S/W Engineer, Kernel Security, Base Operating Systems
> > Remote, Ottawa, Red Hat Canada
> > IRC: rgb, SunRaycer
> > Voice: +1.647.777.2635, Internal: (81) 32635
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 0/4] ia64: switch to NO_BOOTMEM
From: Luck, Tony @ 2018-07-23 21:00 UTC (permalink / raw)
To: Mike Rapoport
Cc: Fenghua Yu, Michal Hocko, linux-ia64, linux-mm, linux-kernel
In-Reply-To: <1532325418-22617-1-git-send-email-rppt@linux.vnet.ibm.com>
On Mon, Jul 23, 2018 at 08:56:54AM +0300, Mike Rapoport wrote:
> Hi,
>
> These patches convert ia64 to use NO_BOOTMEM.
>
> The first two patches are cleanups, the third patches reduces usage of
> 'struct bootmem_data' for easier transition and the forth patch actually
> replaces bootmem with memblock + nobootmem.
>
> I've tested the sim_defconfig with the ski simulator and build tested other
> defconfigs.
Boots OK on my real ia64 system.
Unless somebody else sees an issue I'll push to Linus nest merge window.
-Tony
^ permalink raw reply
* Re: [PATCH 0/4] ia64: switch to NO_BOOTMEM
From: Luck, Tony @ 2018-07-23 21:00 UTC (permalink / raw)
To: Mike Rapoport
Cc: Fenghua Yu, Michal Hocko, linux-ia64, linux-mm, linux-kernel
In-Reply-To: <1532325418-22617-1-git-send-email-rppt@linux.vnet.ibm.com>
On Mon, Jul 23, 2018 at 08:56:54AM +0300, Mike Rapoport wrote:
> Hi,
>
> These patches convert ia64 to use NO_BOOTMEM.
>
> The first two patches are cleanups, the third patches reduces usage of
> 'struct bootmem_data' for easier transition and the forth patch actually
> replaces bootmem with memblock + nobootmem.
>
> I've tested the sim_defconfig with the ski simulator and build tested other
> defconfigs.
Boots OK on my real ia64 system.
Unless somebody else sees an issue I'll push to Linus nest merge window.
-Tony
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/4] lib: Don't assert all KMS drivers support edid_override
From: Patchwork @ 2018-07-23 20:59 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20180723200736.29508-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with [i-g-t,1/4] lib: Don't assert all KMS drivers support edid_override
URL : https://patchwork.freedesktop.org/series/47084/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> IGTPW_1633 =
== Summary - SUCCESS ==
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47084/revisions/1/mbox/
== Known issues ==
Here are the changes found in IGTPW_1633 that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@drv_module_reload@basic-reload-inject:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106725, fdo#106248) +1
igt@gem_ringfill@basic-default-fd:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719)
igt@kms_flip@basic-flip-vs-wf_vblank:
fi-glk-j4005: PASS -> FAIL (fdo#100368)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: NOTRUN -> INCOMPLETE (fdo#103713)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000)
==== Possible fixes ====
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: FAIL (fdo#104008) -> PASS
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248
fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725
== Participating hosts (47 -> 43) ==
Additional (1): fi-bsw-kefka
Missing (5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u
== Build changes ==
* IGT: IGT_4570 -> IGTPW_1633
CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_1633: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1633/
IGT_4570: 65cdccdc7bcbb791d791aeeeecb784a382110a3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Testlist changes ==
+igt@gem_exec_capture@many-random
+igt@gem_exec_capture@many-zero
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1633/issues.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* request for 4.17-stable: 7ec916f82c48 ("Revert "iommu/intel-iommu: Enable CONFIG_DMA_DIRECT_OPS=y and clean up intel_{alloc,free}_coherent()"")
From: Jeremy Cline @ 2018-07-23 19:56 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Christoph Hellwig, Fabio Coatti, stable
Hi Greg,
Please consider backporting commit 7ec916f82c48, which fixes an issue
with iwlwifi module loading in some cases. Fabio initially reported the
issue and confirmed reverting fixed the problem, and it has also been
reported by at least one Fedora user[0] as fixing the problem.
Thanks!
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1607092
^ permalink raw reply
* [PATCH] net/mlx5: fix queue rollback when starting device
From: Yongseok Koh @ 2018-07-23 20:57 UTC (permalink / raw)
To: shahafs; +Cc: dev, Yongseok Koh, stable
mlx5_rxq_start() and mlx5_rxq_stop() must be strictly paired because
internal reference counter is increased or decreased inside. Also,
mlx5_rxq_get() must be paired with mlx5_rxq_release().
Fixes: 7d6bf6b866b8 ("net/mlx5: add Multi-Packet Rx support")
Fixes: a1366b1a2be3 ("net/mlx5: add reference counter on DPDK Rx queues")
Fixes: 6e78005a9b30 ("net/mlx5: add reference counter on DPDK Tx queues")
Cc: stable@dpdk.org
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
---
drivers/net/mlx5/mlx5_trigger.c | 33 ++++++++++++++++++++-------------
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_trigger.c b/drivers/net/mlx5/mlx5_trigger.c
index 4d2078bbd..ef499d898 100644
--- a/drivers/net/mlx5/mlx5_trigger.c
+++ b/drivers/net/mlx5/mlx5_trigger.c
@@ -46,7 +46,6 @@ mlx5_txq_start(struct rte_eth_dev *dev)
unsigned int i;
int ret;
- /* Add memory regions to Tx queues. */
for (i = 0; i != priv->txqs_n; ++i) {
struct mlx5_txq_ctrl *txq_ctrl = mlx5_txq_get(dev, i);
@@ -60,12 +59,17 @@ mlx5_txq_start(struct rte_eth_dev *dev)
}
}
ret = mlx5_tx_uar_remap(dev, priv->ctx->cmd_fd);
- if (ret)
+ if (ret) {
+ /* Adjust index for rollback. */
+ i = priv->txqs_n - 1;
goto error;
+ }
return 0;
error:
ret = rte_errno; /* Save rte_errno before cleanup. */
- mlx5_txq_stop(dev);
+ do {
+ mlx5_txq_release(dev, i);
+ } while (i-- != 0);
rte_errno = ret; /* Restore rte_errno. */
return -rte_errno;
}
@@ -103,8 +107,10 @@ mlx5_rxq_start(struct rte_eth_dev *dev)
int ret = 0;
/* Allocate/reuse/resize mempool for Multi-Packet RQ. */
- if (mlx5_mprq_alloc_mp(dev))
- goto error;
+ if (mlx5_mprq_alloc_mp(dev)) {
+ /* Should not release Rx queues but return immediately. */
+ return -rte_errno;
+ }
for (i = 0; i != priv->rxqs_n; ++i) {
struct mlx5_rxq_ctrl *rxq_ctrl = mlx5_rxq_get(dev, i);
struct rte_mempool *mp;
@@ -130,7 +136,9 @@ mlx5_rxq_start(struct rte_eth_dev *dev)
return 0;
error:
ret = rte_errno; /* Save rte_errno before cleanup. */
- mlx5_rxq_stop(dev);
+ do {
+ mlx5_rxq_release(dev, i);
+ } while (i-- != 0);
rte_errno = ret; /* Restore rte_errno. */
return -rte_errno;
}
@@ -152,21 +160,21 @@ mlx5_dev_start(struct rte_eth_dev *dev)
struct priv *priv = dev->data->dev_private;
int ret;
- dev->data->dev_started = 1;
- DRV_LOG(DEBUG, "port %u allocating and configuring hash Rx queues",
- dev->data->port_id);
+ DRV_LOG(DEBUG, "port %u starting device", dev->data->port_id);
ret = mlx5_txq_start(dev);
if (ret) {
DRV_LOG(ERR, "port %u Tx queue allocation failed: %s",
dev->data->port_id, strerror(rte_errno));
- goto error;
+ return -rte_errno;
}
ret = mlx5_rxq_start(dev);
if (ret) {
DRV_LOG(ERR, "port %u Rx queue allocation failed: %s",
dev->data->port_id, strerror(rte_errno));
- goto error;
+ mlx5_txq_stop(dev);
+ return -rte_errno;
}
+ dev->data->dev_started = 1;
ret = mlx5_rx_intr_vec_enable(dev);
if (ret) {
DRV_LOG(ERR, "port %u Rx interrupt vector creation failed",
@@ -221,8 +229,7 @@ mlx5_dev_stop(struct rte_eth_dev *dev)
dev->tx_pkt_burst = removed_tx_burst;
rte_wmb();
usleep(1000 * priv->rxqs_n);
- DRV_LOG(DEBUG, "port %u cleaning up and destroying hash Rx queues",
- dev->data->port_id);
+ DRV_LOG(DEBUG, "port %u stopping device", dev->data->port_id);
mlx5_flow_stop(dev, &priv->flows);
mlx5_traffic_disable(dev);
mlx5_rx_intr_vec_disable(dev);
--
2.11.0
^ permalink raw reply related
* Re: Linux 4.18-rc6
From: Linus Torvalds @ 2018-07-23 20:56 UTC (permalink / raw)
To: Guenter Roeck, David Miller, Martin Schwidefsky; +Cc: Linux Kernel Mailing List
In-Reply-To: <20180723204617.GA14487@roeck-us.net>
Adding davem for the sparc issue, Martin for the s390 one.
On Mon, Jul 23, 2018 at 1:46 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> The s390 gcc plugins related build error reported previously has not really
> been fixed; after feedback from the s390 maintainers, suggesting that it
> won't get fixed in 4.18, I disabled GCC_PLUGINS for s390 builds. This is
> not my preferred solution, but it beats not testing s390:allmodconfig
> builds at all.
Martin - can we just remove the
select HAVE_GCC_PLUGINS
from the s390 Kconfig file (or perhaps add "if BROKEN" or something to
disable it).
Because if it's not getting fixed, it shouldn't be exposed.
> The sparc32 build error is still:
>
> In file included from
> ...
> from drivers/staging/media/omap4iss/iss_video.c:15:
> include/linux/highmem.h: In function 'clear_user_highpage':
> include/linux/highmem.h:137:31: error:
> passing argument 1 of 'sparc_flush_page_to_ram' from incompatible pointer type
>
> due to a missing declaration of 'struct page', as previously reported.
Hmm. I assume it's
arch/sparc/include/asm/cacheflush_32.h
that wants a forward-declaration of 'struct page', and doesn't include
any header files.
The fix is presumably to move the
#include <asm/cacheflush.h>
in drivers/staging/media/omap4iss/iss_video.c down to below the
<linux/*> includes?
The old patchwork link you had for a fix no longer works, I think
because the patchwork database got re-generated during the upgrade
(and the patchwork numbering isn't stable).
Davem?
Linus
^ permalink raw reply
* Re: [PATCH 2/5] rhashtable: don't hold lock on first table throughout insertion.
From: Paul E. McKenney @ 2018-07-23 20:56 UTC (permalink / raw)
To: NeilBrown; +Cc: Herbert Xu, Thomas Graf, netdev, linux-kernel
In-Reply-To: <87h8kqrhi0.fsf@notabene.neil.brown.name>
On Mon, Jul 23, 2018 at 09:13:43AM +1000, NeilBrown wrote:
> On Sun, Jul 22 2018, Paul E. McKenney wrote:
> >
> > One issue is that the ->func pointer can legitimately be NULL while on
> > RCU's callback lists. This happens when someone invokes kfree_rcu()
> > with the rcu_head structure at the beginning of the enclosing structure.
> > I could add an offset to avoid this, or perhaps the kmalloc() folks
> > could be persuaded Rao Shoaib's patch moving kfree_rcu() handling to
> > the slab allocators, so that RCU only ever sees function pointers in
> > the ->func field.
> >
> > Either way, this should be hidden behind an API to allow adjustments
> > to be made if needed. Maybe something like is_after_call_rcu()?
> > This would (for example) allow debug-object checks to be used to catch
> > check-after-free bugs.
> >
> > Would something of that sort work for you?
>
> Yes, if you could provide an is_after_call_rcu() API, that would
> perfectly suit my use-case.
After beating my head against the object-debug code a bit, I have to ask
if it would be OK for you if the is_after_call_rcu() API also takes the
function that was passed to RCU.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH v6] pidns: introduce syscall translate_pid
From: Michael Tirado @ 2018-07-23 20:55 UTC (permalink / raw)
To: Nagarathnam Muthusamy
Cc: Konstantin Khlebnikov, linux-api, LKML, Jann Horn, Serge Hallyn,
Prakash Sangappa, Oleg Nesterov, Eric W. Biederman, Andrew Morton,
Andy Lutomirski, Michael Kerrisk (man-pages)
In-Reply-To: <db8d560e-47d1-c32f-e4a2-407110f2b5b6@oracle.com>
Hey, I'm not seeing much activity on this so here's my $0.02
> Unix socket automatically translates pid attached to SCM_CREDENTIALS.
> This requires CAP_SYS_ADMIN for sending arbitrary pids and entering
> into pid namespace, this expose process and could be insecure.
Perhaps it would be a good idea to add a sysctl switch that prevents
credential spoofing over AF_UNIX \by default\ if that is the main
concern, or is there another concern and I have read this wrong? I'm
having trouble thinking of a legitimate use of SCM_CREDENTIALS
spoofing that isn't in a debugging or troubleshooting context and
would be more comfortable if it were not possible at all... Anyone
know of a program that relies on this spoofing functionality?
If you look at socket(7) under SO_PEERCRED there is a way to get
credentials at time of connect() for an AF_UNIX SOCK_STREAM, or at
time of socketpair() for a SOCK_DGRAM. I would like to think these
credentials are reliable, but will probably require some extra daemon
to proxy a dgram syslog socket.
^ permalink raw reply
* Re: [PATCH 12/12] i2c: sh_mobile: use core to detect 'no zero length read' quirk
From: Niklas Söderlund @ 2018-07-23 20:54 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-i2c, linux-renesas-soc, linux-kernel
In-Reply-To: <20180723202617.15230-13-wsa+renesas@sang-engineering.com>
Hi Wolfram,
Thanks for your work.
On 2018-07-23 22:26:16 +0200, Wolfram Sang wrote:
> And don't reimplement in the driver.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
>
> drivers/i2c/busses/i2c-sh_mobile.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
> index 5fda4188a9e5..9c7f6f8ceb22 100644
> --- a/drivers/i2c/busses/i2c-sh_mobile.c
> +++ b/drivers/i2c/busses/i2c-sh_mobile.c
> @@ -613,11 +613,6 @@ static void sh_mobile_i2c_xfer_dma(struct sh_mobile_i2c_data *pd)
> static int start_ch(struct sh_mobile_i2c_data *pd, struct i2c_msg *usr_msg,
> bool do_init)
> {
> - if (usr_msg->len == 0 && (usr_msg->flags & I2C_M_RD)) {
> - dev_err(pd->dev, "Unsupported zero length i2c read\n");
> - return -EOPNOTSUPP;
> - }
> -
> if (do_init) {
> /* Initialize channel registers */
> iic_wr(pd, ICCR, ICCR_SCP);
> @@ -758,6 +753,10 @@ static const struct i2c_algorithm sh_mobile_i2c_algorithm = {
> .master_xfer = sh_mobile_i2c_xfer,
> };
>
> +static const struct i2c_adapter_quirks sh_mobile_i2c_quirks = {
> + .flags = I2C_AQ_NO_ZERO_LEN_READ,
> +};
> +
> /*
> * r8a7740 chip has lasting errata on I2C I/O pad reset.
> * this is work-around for it.
> @@ -925,6 +924,7 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
>
> adap->owner = THIS_MODULE;
> adap->algo = &sh_mobile_i2c_algorithm;
> + adap->quirks = &sh_mobile_i2c_quirks;
> adap->dev.parent = &dev->dev;
> adap->retries = 5;
> adap->nr = dev->id;
> --
> 2.11.0
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.