* Re: [bug] GNOME loses all settings following failure to resume from suspend
From: Filipe Manana @ 2022-01-05 18:04 UTC (permalink / raw)
To: Chris Murphy; +Cc: Btrfs BTRFS, Josef Bacik
In-Reply-To: <CAJCQCtRnyUHEwV1o9k565B_u_RwQ2OQqdXHtcfa-LWAbUSB7Gg@mail.gmail.com>
On Wed, Jan 05, 2022 at 10:34:10AM -0700, Chris Murphy wrote:
> https://gitlab.gnome.org/GNOME/dconf/-/issues/73
>
> Following a crash, instead of either the old or new dconf database
> file being present, a corrupt one is present.
>
> dconf uses g_file_set_contents() to atomically update the database
> file, which effectively inhibits (one or more?) fsync's, yet somehow
> in the crash/powerfail case this is resulting in a corrupt dconf
> database. I don't know if by "corrupt" this is a 0 length file or some
> other effect.
Looking at the issue, Sebastian Keller posted a patch to disable one
optimization in glib, that should fix it.
Looking at the code before that patch, it explicitly skips fsync after
a rename pointing out to:
https://btrfs.wiki.kernel.org/index.php/FAQ#What_are_the_crash_guarantees_of_overwrite-by-rename.3F
I'm afraid that information is wrong, perhaps it might have been true in
some very distant past, but certainly not for many years.
The wiki says, doing something like this:
echo "oldcontent" > file
# make sure oldcontent is on disk
sync
echo "newcontent" > file.tmp
mv -f file.tmp file
# *crash*
Will give either:
file contains "newcontent"; file.tmp does not exist
file contains "oldcontent"; file.tmp may contain "newcontent", be zero-length or not exists at all.
However that's not true, there's a chance 'file' will be empty.
During a rename with overwrite we trigger writeback (via filemap_flush())
of the file being renamed but never wait for it to complete before
returning to user space. So what can happen is:
1) We trigger writeback;
2) We join the current transaction and do the rename;
3) We return from rename to user space with success (0);
4) Writeback didn't finish yet, or it has finished but the
ordered extent is not yet complete - i.e. btrfs_finish_ordered_io()
did not complete yet;
5) The transaction used by the rename is committed;
A transaction commit does not wait for any writeback or in flight
ordered extents to complete - except if the fs is mounted with
"-o flushoncommit";
6) Crash
After mounting the fs again 'file' is empty and 'file.tmp' does not exists.
The only for that to guarantee 'file' is not empty and has the expected
data ("newcontent"), would be to mount with -o flushoncommit.
I don't think I have a wiki account enabled, but I'll see if I get that
updated soon.
Thanks.
>
> Thanks,
>
> --
> Chris Murphy
^ permalink raw reply
* Re: [RFC PATCH 2/8] media: i2c: ov6650: Drop implementation of .set_mbus_config()
From: Sakari Ailus @ 2022-01-05 18:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-media, linux-renesas-soc, Hans Verkuil, Kieran Bingham,
Jacopo Mondi, Niklas Söderlund, Tomi Valkeinen,
Janusz Krzysztofik
In-Reply-To: <20220103162414.27723-3-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent,
Thanks for the set.
On Mon, Jan 03, 2022 at 06:24:08PM +0200, Laurent Pinchart wrote:
> The subdev .set_mbus_config() operation is deprecated. No code in the
> kernel calls it, so drop its implementation from the ov6650 driver.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/media/i2c/ov6650.c | 37 -------------------------------------
> 1 file changed, 37 deletions(-)
>
> diff --git a/drivers/media/i2c/ov6650.c b/drivers/media/i2c/ov6650.c
> index f67412150b16..455a627e35a0 100644
> --- a/drivers/media/i2c/ov6650.c
> +++ b/drivers/media/i2c/ov6650.c
> @@ -944,42 +944,6 @@ static int ov6650_get_mbus_config(struct v4l2_subdev *sd,
> return 0;
> }
>
> -/* Alter bus settings on camera side */
> -static int ov6650_set_mbus_config(struct v4l2_subdev *sd,
> - unsigned int pad,
> - struct v4l2_mbus_config *cfg)
> -{
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> - int ret = 0;
> -
> - if (cfg->flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
> - ret = ov6650_reg_rmw(client, REG_COMJ, COMJ_PCLK_RISING, 0);
> - else if (cfg->flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
> - ret = ov6650_reg_rmw(client, REG_COMJ, 0, COMJ_PCLK_RISING);
I think this configuration should come from the endpoint which the driver
currently does not parse. In fact, there are no even DT bindings for the
device.
I wonder what kind of environment it is used in --- assuming it works
somewhere.
> - if (ret)
> - return ret;
> -
> - if (cfg->flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
> - ret = ov6650_reg_rmw(client, REG_COMF, COMF_HREF_LOW, 0);
> - else if (cfg->flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> - ret = ov6650_reg_rmw(client, REG_COMF, 0, COMF_HREF_LOW);
> - if (ret)
> - return ret;
> -
> - if (cfg->flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
> - ret = ov6650_reg_rmw(client, REG_COMJ, COMJ_VSYNC_HIGH, 0);
> - else if (cfg->flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> - ret = ov6650_reg_rmw(client, REG_COMJ, 0, COMJ_VSYNC_HIGH);
> - if (ret)
> - return ret;
> -
> - /*
> - * Update the configuration to report what is actually applied to
> - * the hardware.
> - */
> - return ov6650_get_mbus_config(sd, pad, cfg);
> -}
> -
> static const struct v4l2_subdev_video_ops ov6650_video_ops = {
> .s_stream = ov6650_s_stream,
> .g_frame_interval = ov6650_g_frame_interval,
> @@ -993,7 +957,6 @@ static const struct v4l2_subdev_pad_ops ov6650_pad_ops = {
> .get_fmt = ov6650_get_fmt,
> .set_fmt = ov6650_set_fmt,
> .get_mbus_config = ov6650_get_mbus_config,
> - .set_mbus_config = ov6650_set_mbus_config,
> };
>
> static const struct v4l2_subdev_ops ov6650_subdev_ops = {
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v2] KVM: Move VM's worker kthreads back to the original cgroups before exiting.
From: Michal Koutný @ 2022-01-05 18:04 UTC (permalink / raw)
To: Vipin Sharma
Cc: pbonzini, seanjc, tj, lizefan.x, hannes, dmatlack, jiangshanlai,
kvm, cgroups, linux-kernel
In-Reply-To: <20211222225350.1912249-1-vipinsh@google.com>
Hi Vipin.
On Wed, Dec 22, 2021 at 10:53:50PM +0000, Vipin Sharma <vipinsh@google.com> wrote:
> VM worker kthreads can linger in the VM process's cgroup for sometime
> after KVM terminates the VM process.
Why is it a problem? And how long are we talking about?
> A VM process can terminate between the time window of exit_mm() to
> cgroup_exit(), leaving only worker kthreads in the cgroup.
Even kthreads should eventually have PF_EXITING set, they shouldd be
treated as "user-space" zombies by cgroups, i.e. mostly invisible (e.g.
it doesn't prevent rmdir'ing the cgroup).
(And after the last task_struct reference is gone, the cgroup structs
can be released too. Maybe the cause is holding the reference to the KVM
worker thread somewhere for too long.)
> Moving worker kthreads back to the original cgroup (kthreadd_task's
> cgroup) makes sure that cgroup is empty as soon as the main VM process
> is terminated.
BTW this used to be done for "user-space" tasks too (migrate to root
cgroup) but it was replaced with the less transactional "ignore zombies"
approach. So this change seems inconsistent.
Regards,
Michal
^ permalink raw reply
* [PATCH v6] soc: ti: smartreflex: Use platform_get_irq_optional() to get the interrupt
From: Lad Prabhakar @ 2022-01-05 18:03 UTC (permalink / raw)
To: Nishanth Menon, Santosh Shilimkar
Cc: Rob Herring, Andy Shevchenko, Prabhakar, Lad Prabhakar, linux-pm,
linux-kernel, linux-arm-kernel
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq_optional().
While at it return 0 instead of returning ret in the probe success path.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v5->v6:
* Dropped printing function name in error message.
v4->v5:
* Fixed missing return while using dev_err_probe().
v3->v4:
* Used dev_err_probe() to print error message
* Returning 0 in probe success path.
v2->v3
* Switch back to platform_get_irq_optional()
* Only print error in case of error, and not when interrupt is missing.
v1->v2
* Updated commit message
* Drop check for IRQ0
* Switched to using platform_get_irq() so that the probe won't
fail silently as requested by Nishanth.
v1:
* https://www.spinics.net/lists/arm-kernel/msg942549.html
---
drivers/soc/ti/smartreflex.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c
index b5b2fa538d5c..ad2bb72e640c 100644
--- a/drivers/soc/ti/smartreflex.c
+++ b/drivers/soc/ti/smartreflex.c
@@ -819,7 +819,7 @@ static int omap_sr_probe(struct platform_device *pdev)
{
struct omap_sr *sr_info;
struct omap_sr_data *pdata = pdev->dev.platform_data;
- struct resource *mem, *irq;
+ struct resource *mem;
struct dentry *nvalue_dir;
int i, ret = 0;
@@ -844,7 +844,11 @@ static int omap_sr_probe(struct platform_device *pdev)
if (IS_ERR(sr_info->base))
return PTR_ERR(sr_info->base);
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ ret = platform_get_irq_optional(pdev, 0);
+ if (ret < 0 && ret != -ENXIO)
+ return dev_err_probe(&pdev->dev, ret, "failed to get IRQ resource\n");
+ if (ret > 0)
+ sr_info->irq = ret;
sr_info->fck = devm_clk_get(pdev->dev.parent, "fck");
if (IS_ERR(sr_info->fck))
@@ -870,9 +874,6 @@ static int omap_sr_probe(struct platform_device *pdev)
sr_info->autocomp_active = false;
sr_info->ip_type = pdata->ip_type;
- if (irq)
- sr_info->irq = irq->start;
-
sr_set_clk_length(sr_info);
list_add(&sr_info->node, &sr_list);
@@ -926,7 +927,7 @@ static int omap_sr_probe(struct platform_device *pdev)
}
- return ret;
+ return 0;
err_debugfs:
debugfs_remove_recursive(sr_info->dbg_dir);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] KVM: Move VM's worker kthreads back to the original cgroups before exiting.
From: Michal Koutný @ 2022-01-05 18:04 UTC (permalink / raw)
To: Vipin Sharma
Cc: pbonzini-H+wXaHxf7aLQT0dZR+AlfA, seanjc-hpIqsD4AKlfQT0dZR+AlfA,
tj-DgEjT+Ai2ygdnm+yROfE0A, lizefan.x-EC8Uxl6Npydl57MIdRCFDg,
hannes-druUgvl0LCNAfugRpC6u6w, dmatlack-hpIqsD4AKlfQT0dZR+AlfA,
jiangshanlai-Re5JQEeQqe8AvxtiuMwx3w, kvm-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20211222225350.1912249-1-vipinsh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Hi Vipin.
On Wed, Dec 22, 2021 at 10:53:50PM +0000, Vipin Sharma <vipinsh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> VM worker kthreads can linger in the VM process's cgroup for sometime
> after KVM terminates the VM process.
Why is it a problem? And how long are we talking about?
> A VM process can terminate between the time window of exit_mm() to
> cgroup_exit(), leaving only worker kthreads in the cgroup.
Even kthreads should eventually have PF_EXITING set, they shouldd be
treated as "user-space" zombies by cgroups, i.e. mostly invisible (e.g.
it doesn't prevent rmdir'ing the cgroup).
(And after the last task_struct reference is gone, the cgroup structs
can be released too. Maybe the cause is holding the reference to the KVM
worker thread somewhere for too long.)
> Moving worker kthreads back to the original cgroup (kthreadd_task's
> cgroup) makes sure that cgroup is empty as soon as the main VM process
> is terminated.
BTW this used to be done for "user-space" tasks too (migrate to root
cgroup) but it was replaced with the less transactional "ignore zombies"
approach. So this change seems inconsistent.
Regards,
Michal
^ permalink raw reply
* Re: [PATCH v3] arm64/mm: avoid fixmap race condition when create pud mapping
From: Catalin Marinas @ 2022-01-05 18:03 UTC (permalink / raw)
To: Jianyong Wu
Cc: will, anshuman.khandual, akpm, david, quic_qiancai, ardb,
linux-kernel, linux-arm-kernel, gshan, justin.he, nd
In-Reply-To: <20211216082812.165387-1-jianyong.wu@arm.com>
On Thu, Dec 16, 2021 at 04:28:12PM +0800, Jianyong Wu wrote:
> The 'fixmap' is a global resource and is used recursively by
> create pud mapping(), leading to a potential race condition in the
> presence of a concurrent call to alloc_init_pud():
>
> kernel_init thread virtio-mem workqueue thread
> ================== ===========================
>
> alloc_init_pud(...) alloc_init_pud(...)
> pudp = pud_set_fixmap_offset(...) pudp = pud_set_fixmap_offset(...)
> READ_ONCE(*pudp)
> pud_clear_fixmap(...)
> READ_ONCE(*pudp) // CRASH!
>
> As kernel may sleep during creating pud mapping, introduce a mutex lock to
> serialise use of the fixmap entries by alloc_init_pud().
>
> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
I tried to queue this patch but with certain configurations it doesn't
boot under Qemu. Starting from defconfig, update .config with (I had
this in one of my build scripts):
$ ./scripts/config \
-e DEBUG_KERNEL \
-e DEBUG_PAGEALLOC \
-e DEBUG_PAGEALLOC_ENABLE_DEFAULT \
-e DEBUG_WX \
-e DEBUG_SET_MODULE_RONX \
-e DEBUG_ALIGN_RODATA \
-e ARM64_PTDUMP_DEBUGFS \
-e DEBUG_OBJECTS \
-e DEBUG_OBJECTS_FREE \
-e DEBUG_OBJECTS_TIMERS \
-e DEBUG_KOBJECT_RELEASE \
-e DEBUG_LOCKING_API_SELFTESTS \
-e DEBUG_PREEMPT \
-e DEBUG_TIMEKEEPING \
-e DEBUG_VM \
-e DEBUG_VM_VMACACHE \
-e DEBUG_VM_RB \
-e DEBUG_VM_PGFLAGS \
-e DEBUG_VIRTUAL \
-e DEBUG_LIST \
-e DEBUG_PI_LIST \
-e DEBUG_SG \
-e PROVE_LOCKING \
-e DEBUG_RT_MUTEXES \
-e DEBUG_ATOMIC_SLEEP \
-e ATOMIC64_SELFTEST
It stop after exiting the EFI boot services. I did not have time to
debug.
--
Catalin
^ permalink raw reply
* [PATCH v6] soc: ti: smartreflex: Use platform_get_irq_optional() to get the interrupt
From: Lad Prabhakar @ 2022-01-05 18:03 UTC (permalink / raw)
To: Nishanth Menon, Santosh Shilimkar
Cc: Rob Herring, Andy Shevchenko, Prabhakar, Lad Prabhakar, linux-pm,
linux-kernel, linux-arm-kernel
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq_optional().
While at it return 0 instead of returning ret in the probe success path.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v5->v6:
* Dropped printing function name in error message.
v4->v5:
* Fixed missing return while using dev_err_probe().
v3->v4:
* Used dev_err_probe() to print error message
* Returning 0 in probe success path.
v2->v3
* Switch back to platform_get_irq_optional()
* Only print error in case of error, and not when interrupt is missing.
v1->v2
* Updated commit message
* Drop check for IRQ0
* Switched to using platform_get_irq() so that the probe won't
fail silently as requested by Nishanth.
v1:
* https://www.spinics.net/lists/arm-kernel/msg942549.html
---
drivers/soc/ti/smartreflex.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c
index b5b2fa538d5c..ad2bb72e640c 100644
--- a/drivers/soc/ti/smartreflex.c
+++ b/drivers/soc/ti/smartreflex.c
@@ -819,7 +819,7 @@ static int omap_sr_probe(struct platform_device *pdev)
{
struct omap_sr *sr_info;
struct omap_sr_data *pdata = pdev->dev.platform_data;
- struct resource *mem, *irq;
+ struct resource *mem;
struct dentry *nvalue_dir;
int i, ret = 0;
@@ -844,7 +844,11 @@ static int omap_sr_probe(struct platform_device *pdev)
if (IS_ERR(sr_info->base))
return PTR_ERR(sr_info->base);
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ ret = platform_get_irq_optional(pdev, 0);
+ if (ret < 0 && ret != -ENXIO)
+ return dev_err_probe(&pdev->dev, ret, "failed to get IRQ resource\n");
+ if (ret > 0)
+ sr_info->irq = ret;
sr_info->fck = devm_clk_get(pdev->dev.parent, "fck");
if (IS_ERR(sr_info->fck))
@@ -870,9 +874,6 @@ static int omap_sr_probe(struct platform_device *pdev)
sr_info->autocomp_active = false;
sr_info->ip_type = pdata->ip_type;
- if (irq)
- sr_info->irq = irq->start;
-
sr_set_clk_length(sr_info);
list_add(&sr_info->node, &sr_list);
@@ -926,7 +927,7 @@ static int omap_sr_probe(struct platform_device *pdev)
}
- return ret;
+ return 0;
err_debugfs:
debugfs_remove_recursive(sr_info->dbg_dir);
--
2.17.1
^ permalink raw reply related
* [PATCH] namei: clear nd->root.mnt before O_CREAT unlazy
From: Brian Foster @ 2022-01-05 18:02 UTC (permalink / raw)
To: linux-fsdevel
The unlazy sequence of an rcuwalk lookup occurs a bit earlier than
normal for O_CREAT lookups (i.e. in open_last_lookups()). The create
logic here historically invoked complete_walk(), which clears the
nd->root.mnt pointer when appropriate before the unlazy. This
changed in commit 72287417abd1 ("open_last_lookups(): don't abuse
complete_walk() when all we want is unlazy"), which refactored the
create path to invoke unlazy_walk() and not consider nd->root.mnt.
This tweak negatively impacts performance on a concurrent
open(O_CREAT) workload to multiple independent mounts beneath the
root directory. This attributes to increased spinlock contention on
the root dentry via legitimize_root(), to the point where the
spinlock becomes the primary bottleneck over the directory inode
rwsem of the individual submounts. For example, the completion rate
of a 32k thread aim7 create/close benchmark that repeatedly passes
O_CREAT to open preexisting files drops from over 700k "jobs per
minute" to 30, increasing the overall test time from a few minutes
to over an hour.
A similar, more simplified test to create a set of opener tasks
across a set of submounts can demonstrate the problem more quickly.
For example, consider sets of 100 open/close tasks each running
against 64 independent filesystem mounts (i.e. 6400 tasks total),
with each task completing 10k iterations before it exits. On an
80xcpu box running v5.16.0-rc2, this test completes in 50-55s. With
this patch applied, the same test completes in 10-15s.
This is not the most realistic workload in the world as it factors
out inode allocation in the filesystem. The contention can also be
avoided by more selective use of O_CREAT or via use of relative
pathnames. That said, this regression appears to be an unintentional
side effect of code cleanup and might be unexpected for users.
Restore original behavior prior to commit 72287417abd1 by factoring
the rcu logic from complete_walk() into a new helper and invoke that
from both places.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/namei.c | 37 +++++++++++++++++++++----------------
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 1f9d2187c765..b32fcbc99929 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -856,6 +856,22 @@ static inline int d_revalidate(struct dentry *dentry, unsigned int flags)
return 1;
}
+static inline bool complete_walk_rcu(struct nameidata *nd)
+{
+ if (nd->flags & LOOKUP_RCU) {
+ /*
+ * We don't want to zero nd->root for scoped-lookups or
+ * externally-managed nd->root.
+ */
+ if (!(nd->state & ND_ROOT_PRESET))
+ if (!(nd->flags & LOOKUP_IS_SCOPED))
+ nd->root.mnt = NULL;
+ nd->flags &= ~LOOKUP_CACHED;
+ return try_to_unlazy(nd);
+ }
+ return true;
+}
+
/**
* complete_walk - successful completion of path walk
* @nd: pointer nameidata
@@ -871,18 +887,8 @@ static int complete_walk(struct nameidata *nd)
struct dentry *dentry = nd->path.dentry;
int status;
- if (nd->flags & LOOKUP_RCU) {
- /*
- * We don't want to zero nd->root for scoped-lookups or
- * externally-managed nd->root.
- */
- if (!(nd->state & ND_ROOT_PRESET))
- if (!(nd->flags & LOOKUP_IS_SCOPED))
- nd->root.mnt = NULL;
- nd->flags &= ~LOOKUP_CACHED;
- if (!try_to_unlazy(nd))
- return -ECHILD;
- }
+ if (!complete_walk_rcu(nd))
+ return -ECHILD;
if (unlikely(nd->flags & LOOKUP_IS_SCOPED)) {
/*
@@ -3325,10 +3331,9 @@ static const char *open_last_lookups(struct nameidata *nd,
BUG_ON(nd->flags & LOOKUP_RCU);
} else {
/* create side of things */
- if (nd->flags & LOOKUP_RCU) {
- if (!try_to_unlazy(nd))
- return ERR_PTR(-ECHILD);
- }
+ if (!complete_walk_rcu(nd))
+ return ERR_PTR(-ECHILD);
+
audit_inode(nd->name, dir, AUDIT_INODE_PARENT);
/* trailing slashes? */
if (unlikely(nd->last.name[nd->last.len]))
--
2.31.1
^ permalink raw reply related
* [PATCH v2] iio: addac: Do not reference negative array offsets
From: Kees Cook @ 2022-01-05 18:02 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Kees Cook, Michael Hennerich, Cosmin Tanislav, Jonathan Cameron,
linux-iio, Linus Walleij, linux-kernel, linux-hardening
Instead of aiming rx_buf at an invalid array-boundary-crossing location,
just skip the first increment. Fixes this warning seen when building
with -Warray-bounds:
drivers/iio/addac/ad74413r.c: In function 'ad74413r_update_scan_mode':
drivers/iio/addac/ad74413r.c:843:22: warning: array subscript -4 is below array bounds of 'u8[16]' { aka 'unsigned char[16]'} [-Warray-bounds]
843 | u8 *rx_buf = &st->adc_samples_buf.rx_buf[-1 * AD74413R_FRAME_SIZE];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/iio/addac/ad74413r.c:84:20: note: while referencing 'rx_buf'
84 | u8 rx_buf[AD74413R_FRAME_SIZE * AD74413R_CHANNEL_MAX];
| ^~~~~~
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Cosmin Tanislav <cosmin.tanislav@analog.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
Signed-off-by: Kees Cook <keescook@chromium.org>
---
v1: https://lore.kernel.org/lkml/20211215232321.2069314-1-keescook@chromium.org/
v2:
- use "xfer" for checking "first through the loop"
---
drivers/iio/addac/ad74413r.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/addac/ad74413r.c b/drivers/iio/addac/ad74413r.c
index 5271073bb74e..aba9a643a4ca 100644
--- a/drivers/iio/addac/ad74413r.c
+++ b/drivers/iio/addac/ad74413r.c
@@ -840,7 +840,7 @@ static int ad74413r_update_scan_mode(struct iio_dev *indio_dev,
{
struct ad74413r_state *st = iio_priv(indio_dev);
struct spi_transfer *xfer = st->adc_samples_xfer;
- u8 *rx_buf = &st->adc_samples_buf.rx_buf[-1 * AD74413R_FRAME_SIZE];
+ u8 *rx_buf = st->adc_samples_buf.rx_buf;
u8 *tx_buf = st->adc_samples_tx_buf;
unsigned int channel;
int ret = -EINVAL;
@@ -894,9 +894,10 @@ static int ad74413r_update_scan_mode(struct iio_dev *indio_dev,
spi_message_add_tail(xfer, &st->adc_samples_msg);
- xfer++;
tx_buf += AD74413R_FRAME_SIZE;
- rx_buf += AD74413R_FRAME_SIZE;
+ if (xfer != st->adc_samples_xfer)
+ rx_buf += AD74413R_FRAME_SIZE;
+ xfer++;
}
xfer->rx_buf = rx_buf;
--
2.30.2
^ permalink raw reply related
* stable-rc/queue/4.9 build: 188 builds: 3 failed, 185 passed, 2 errors, 34 warnings (v4.9.295-13-g1d9484cc9e1a)
From: kernelci.org bot @ 2022-01-05 18:02 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable-rc/queue/4.9 build: 188 builds: 3 failed, 185 passed, 2 errors, 34 warnings (v4.9.295-13-g1d9484cc9e1a)
Full Build Summary: https://kernelci.org/build/stable-rc/branch/queue%2F4.9/kernel/v4.9.295-13-g1d9484cc9e1a/
Tree: stable-rc
Branch: queue/4.9
Git Describe: v4.9.295-13-g1d9484cc9e1a
Git Commit: 1d9484cc9e1a4df669a3985ac43ca6818c88cfc7
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 6 unique architectures
Build Failures Detected:
arm:
rpc_defconfig: (gcc-10) FAIL
mips:
ip27_defconfig: (gcc-10) FAIL
ip28_defconfig: (gcc-10) FAIL
Errors and Warnings Detected:
arc:
arm64:
arm:
mini2440_defconfig (gcc-10): 1 warning
omap1_defconfig (gcc-10): 1 warning
rpc_defconfig (gcc-10): 2 errors
s3c2410_defconfig (gcc-10): 1 warning
i386:
allnoconfig (gcc-10): 3 warnings
i386_defconfig (gcc-10): 3 warnings
tinyconfig (gcc-10): 3 warnings
mips:
mtx1_defconfig (gcc-10): 3 warnings
x86_64:
allnoconfig (gcc-10): 5 warnings
tinyconfig (gcc-10): 4 warnings
x86_64_defconfig (gcc-10): 5 warnings
x86_64_defconfig+x86-chromebook (gcc-10): 5 warnings
Errors summary:
1 arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
1 arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
Warnings summary:
7 ld: warning: creating DT_TEXTREL in a PIE
7 arch/x86/kernel/process.c:460: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
4 ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
4 arch/x86/entry/entry_64.S:1565: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
3 ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
3 arch/x86/entry/entry_32.S:452: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
2 sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
2 drivers/tty/serial/samsung.c:1786:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
1 sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
1 drivers/gpio/gpio-omap.c:1135:34: warning: array ‘omap_gpio_match’ assumed to have one element
Section mismatches summary:
2 WARNING: modpost: Found 1 section mismatch(es).
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
acs5k_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:452: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
allnoconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (x86_64, gcc-10) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1565: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
arch/x86/kernel/process.c:460: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
arch/x86/kernel/process.c:460: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ar7_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
assabet_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
at91_dt_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath25_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath79_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
badge4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm2835_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bigsur_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_be_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
Section mismatches:
WARNING: modpost: Found 1 section mismatch(es).
--------------------------------------------------------------------------------
bmips_stb_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
Section mismatches:
WARNING: modpost: Found 1 section mismatch(es).
--------------------------------------------------------------------------------
capcella_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ci20_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cobalt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
collie_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
corgi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
davinci_all_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
db1xxx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
dove_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
e55_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
efm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
em_x270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ep93xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
exynos_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ezx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
footbridge_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h5000_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hackkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hisi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
i386_defconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:452: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
imote2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
integrator_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop32x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop33x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip22_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jazz_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
keystone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ks8695_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lasat_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1b_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1c_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc18xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpd270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
magician_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mainstone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_qemu_32r6_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_xpa_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mini2440_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/tty/serial/samsung.c:1786:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mpc30x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mps2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msp71xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
--------------------------------------------------------------------------------
multi_v4t_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mxs_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
neponset_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netwinder_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nhk8815_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc950_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc960_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omap1_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/gpio/gpio-omap.c:1135:34: warning: array ‘omap_gpio_match’ assumed to have one element
--------------------------------------------------------------------------------
omap2plus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
orion5x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
palmz72_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pcm027_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pic32mzda_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pleb_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa168_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qcom_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rb532_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rm200_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm, gcc-10) — FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
--------------------------------------------------------------------------------
rt305x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/tty/serial/samsung.c:1786:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
--------------------------------------------------------------------------------
s3c6400_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s5pv210_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sama5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shmobile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
simpad_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
socfpga_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear6xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spitz_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
stm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sunxi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0219_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tegra_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:452: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
tinyconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1565: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
arch/x86/kernel/process.c:460: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
trizeps4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u8500_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
versatile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vexpress_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vf610m4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
viper_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
workpad_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-10) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1565: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
arch/x86/kernel/process.c:460: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
arch/x86/kernel/process.c:460: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
x86_64_defconfig+x86-chromebook (x86_64, gcc-10) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1565: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
arch/x86/kernel/process.c:460: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
arch/x86/kernel/process.c:460: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
xcep_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
xilfpga_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zebu_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zebu_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* [RFC] eal: remove size for eal_set_runtime_dir
From: Stephen Hemminger @ 2022-01-05 18:01 UTC (permalink / raw)
To: Morten Brørup; +Cc: dev, Stephen Hemminger
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86DB1@smartserver.smartshare.dk>
The size argument to eal_set_runtime_dir is useless and was
being used incorrectly in strlcpy. It worked only because
all callers passed PATH_MAX which is same as sizeof the destination
runtime_dir.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
---
lib/eal/common/eal_common_config.c | 7 ++-----
lib/eal/common/eal_private.h | 4 +---
lib/eal/freebsd/eal.c | 2 +-
lib/eal/linux/eal.c | 2 +-
4 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/lib/eal/common/eal_common_config.c b/lib/eal/common/eal_common_config.c
index 1c4c4dd585d0..62a9d7a198db 100644
--- a/lib/eal/common/eal_common_config.c
+++ b/lib/eal/common/eal_common_config.c
@@ -29,12 +29,9 @@ rte_eal_get_runtime_dir(void)
}
int
-eal_set_runtime_dir(char *run_dir, size_t size)
+eal_set_runtime_dir(const char *run_dir)
{
- size_t str_size;
-
- str_size = strlcpy(runtime_dir, run_dir, size);
- if (str_size >= size) {
+ if (strlcpy(runtime_dir, run_dir, PATH_MAX) >= PATH_MAX) {
RTE_LOG(ERR, EAL, "Runtime directory string too long\n");
return -1;
}
diff --git a/lib/eal/common/eal_private.h b/lib/eal/common/eal_private.h
index 36bcc0b5a492..734f1f334b69 100644
--- a/lib/eal/common/eal_private.h
+++ b/lib/eal/common/eal_private.h
@@ -681,13 +681,11 @@ eal_mem_set_dump(void *virt, size_t size, bool dump);
*
* @param run_dir
* The new runtime directory path of DPDK
- * @param size
- * The size of the new runtime directory path in bytes.
* @return
* 0 on success, (-1) on failure.
*/
int
-eal_set_runtime_dir(char *run_dir, size_t size);
+eal_set_runtime_dir(const char *run_dir);
/**
* Get the internal configuration structure.
diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
index a1cd2462db1b..503e276dc27f 100644
--- a/lib/eal/freebsd/eal.c
+++ b/lib/eal/freebsd/eal.c
@@ -123,7 +123,7 @@ eal_create_runtime_dir(void)
return -1;
}
- if (eal_set_runtime_dir(run_dir, sizeof(run_dir)))
+ if (eal_set_runtime_dir(run_dir))
return -1;
return 0;
diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
index 80ffe1c7f9d8..a73ff75f65c9 100644
--- a/lib/eal/linux/eal.c
+++ b/lib/eal/linux/eal.c
@@ -135,7 +135,7 @@ eal_create_runtime_dir(void)
return -1;
}
- if (eal_set_runtime_dir(run_dir, sizeof(run_dir)))
+ if (eal_set_runtime_dir(run_dir))
return -1;
return 0;
--
2.30.2
^ permalink raw reply related
* Re: [PATCH] drm/dp: Remove common Post Cursor2 register handling
From: Jani Nikula @ 2022-01-05 18:00 UTC (permalink / raw)
To: Kees Cook, Maarten Lankhorst
Cc: Kees Cook, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, dri-devel, Thierry Reding, Jonathan Hunter,
Philipp Zabel, Lyude Paul, linux-kernel, linux-tegra,
linux-hardening
In-Reply-To: <20220105173507.2420910-1-keescook@chromium.org>
On Wed, 05 Jan 2022, Kees Cook <keescook@chromium.org> wrote:
> The link_status array was not large enough to read the Adjust Request
> Post Cursor2 register, so remove the common helper function to avoid
> an OOB read, found with a -Warray-bounds build:
>
> drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor':
> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds]
> 59 | return link_status[r - DP_LANE0_1_STATUS];
> | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'
> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
> | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Replace the only user of the helper with an open-coded fetch and decode,
> similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
>
> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> This is the alternative to:
> https://lore.kernel.org/lkml/20211203084354.3105253-1-keescook@chromium.org/
> ---
> drivers/gpu/drm/drm_dp_helper.c | 10 ----------
> drivers/gpu/drm/tegra/dp.c | 11 ++++++++++-
> include/drm/drm_dp_helper.h | 2 --
> 3 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 23f9073bc473..c9528aa62c9c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -144,16 +144,6 @@ u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
>
> -u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane)
> -{
> - unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
> - u8 value = dp_link_status(link_status, offset);
> -
> - return (value >> (lane << 1)) & 0x3;
> -}
> -EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
> -
> static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8 rd_interval)
> {
> if (rd_interval > 4)
> diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
> index 70dfb7d1dec5..f5535eb04c6b 100644
> --- a/drivers/gpu/drm/tegra/dp.c
> +++ b/drivers/gpu/drm/tegra/dp.c
> @@ -549,6 +549,15 @@ static void drm_dp_link_get_adjustments(struct drm_dp_link *link,
> {
> struct drm_dp_link_train_set *adjust = &link->train.adjust;
> unsigned int i;
> + u8 post_cursor;
> + int err;
> +
> + err = drm_dp_dpcd_read(link->aux, DP_ADJUST_REQUEST_POST_CURSOR2,
> + &post_cursor, sizeof(post_cursor));
There's a drm_dp_dpcd_readb() for the common 1-byte reads. Other than
that,
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Though obviously that's not enough to actually merge to tegra.
> + if (err < 0) {
> + DRM_ERROR("failed to read post_cursor2: %d\n", err);
> + post_cursor = 0;
> + }
>
> for (i = 0; i < link->lanes; i++) {
> adjust->voltage_swing[i] =
> @@ -560,7 +569,7 @@ static void drm_dp_link_get_adjustments(struct drm_dp_link *link,
> DP_TRAIN_PRE_EMPHASIS_SHIFT;
>
> adjust->post_cursor[i] =
> - drm_dp_get_adjust_request_post_cursor(status, i);
> + (post_cursor >> (i << 1)) & 0x3;
> }
> }
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 472dac376284..fdf3cf6ccc02 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1528,8 +1528,6 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 link_status[DP_LINK_STATUS_SI
> int lane);
> u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane);
> -u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane);
>
> #define DP_BRANCH_OUI_HEADER_SIZE 0xc
> #define DP_RECEIVER_CAP_SIZE 0xf
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH] drm/dp: Remove common Post Cursor2 register handling
From: Jani Nikula @ 2022-01-05 18:00 UTC (permalink / raw)
To: Kees Cook, Maarten Lankhorst
Cc: David Airlie, linux-kernel, dri-devel, Jonathan Hunter,
Thierry Reding, linux-hardening, Thomas Zimmermann, linux-tegra,
Kees Cook
In-Reply-To: <20220105173507.2420910-1-keescook@chromium.org>
On Wed, 05 Jan 2022, Kees Cook <keescook@chromium.org> wrote:
> The link_status array was not large enough to read the Adjust Request
> Post Cursor2 register, so remove the common helper function to avoid
> an OOB read, found with a -Warray-bounds build:
>
> drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor':
> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds]
> 59 | return link_status[r - DP_LANE0_1_STATUS];
> | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'
> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
> | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Replace the only user of the helper with an open-coded fetch and decode,
> similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
>
> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> This is the alternative to:
> https://lore.kernel.org/lkml/20211203084354.3105253-1-keescook@chromium.org/
> ---
> drivers/gpu/drm/drm_dp_helper.c | 10 ----------
> drivers/gpu/drm/tegra/dp.c | 11 ++++++++++-
> include/drm/drm_dp_helper.h | 2 --
> 3 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 23f9073bc473..c9528aa62c9c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -144,16 +144,6 @@ u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
>
> -u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane)
> -{
> - unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
> - u8 value = dp_link_status(link_status, offset);
> -
> - return (value >> (lane << 1)) & 0x3;
> -}
> -EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
> -
> static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8 rd_interval)
> {
> if (rd_interval > 4)
> diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
> index 70dfb7d1dec5..f5535eb04c6b 100644
> --- a/drivers/gpu/drm/tegra/dp.c
> +++ b/drivers/gpu/drm/tegra/dp.c
> @@ -549,6 +549,15 @@ static void drm_dp_link_get_adjustments(struct drm_dp_link *link,
> {
> struct drm_dp_link_train_set *adjust = &link->train.adjust;
> unsigned int i;
> + u8 post_cursor;
> + int err;
> +
> + err = drm_dp_dpcd_read(link->aux, DP_ADJUST_REQUEST_POST_CURSOR2,
> + &post_cursor, sizeof(post_cursor));
There's a drm_dp_dpcd_readb() for the common 1-byte reads. Other than
that,
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Though obviously that's not enough to actually merge to tegra.
> + if (err < 0) {
> + DRM_ERROR("failed to read post_cursor2: %d\n", err);
> + post_cursor = 0;
> + }
>
> for (i = 0; i < link->lanes; i++) {
> adjust->voltage_swing[i] =
> @@ -560,7 +569,7 @@ static void drm_dp_link_get_adjustments(struct drm_dp_link *link,
> DP_TRAIN_PRE_EMPHASIS_SHIFT;
>
> adjust->post_cursor[i] =
> - drm_dp_get_adjust_request_post_cursor(status, i);
> + (post_cursor >> (i << 1)) & 0x3;
> }
> }
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 472dac376284..fdf3cf6ccc02 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1528,8 +1528,6 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 link_status[DP_LINK_STATUS_SI
> int lane);
> u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane);
> -u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane);
>
> #define DP_BRANCH_OUI_HEADER_SIZE 0xc
> #define DP_RECEIVER_CAP_SIZE 0xf
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* mpt3sas fails to allocate budget_map and detects no devices
From: Martin Wilck @ 2022-01-05 18:00 UTC (permalink / raw)
To: sreekanth.reddy@broadcom.com, ming.lei@redhat.com
Cc: linux-scsi@vger.kernel.org, suganath-prabu.subramani@broadcom.com,
MPT-FusionLinux.pdl@broadcom.com, hare@suse.de, Martin Wilck
Hello Ming, Sreekanth,
I'm observing a problem where mpt3sas fails to allocate the budget_map
for any SCSI device, because attempted allocation is larger than the
maximum possible. The issue is caused by the logic used in 020b0f0a3192
("scsi: core: Replace sdev->device_busy with sbitmap")
to calculate the bitmap size. This is observed with 5.16-rc8.
The controller at hand has properties can_queue=29865 and
cmd_per_lun=7. The way these parameters are used in scsi_alloc_sdev()->
sbitmap_init_node(), this results in an sbitmap with 29865 maps, where
only a single bit is used per map. On x86_64, this results in an
attempt to allocate 29865 * 192 = 5734080 bytes for the sbitmap, which
is larger than PAGE_SIZE * (1 << (MAX_ORDER - 1)), and fails.
cmd_per_lun=7 is an extreme case, because sbitmap_calculate_shift()
returns 0 (i.e. 1 bit per word) for this case. The problem for this
controller is the very large difference between the actual
cmd_per_lun=7 and the theoretical maximum
scsi_device_max_queue_depth(sdev) = host->can_queue = 29865. The
generic sbitmap logic assumes that the initial size is at least rougly
similar to the maximum.
I believe it would make sense to limit scsi_device_max_queue_depth(),
and thus the bitmap size, to BLK_MQ_MAX_DEPTH = 10240. But even then,
we would allocate a huge bitmap for this controller - 2MiB, of which no
more than 10kiB would ever be used (and only 7 bytes (!) in the default
case).
I'm unsure how to fix this correctly. To my understanding, the reason
that the sbitmap is split over multiple cache lines is to avoid ping-
pong between CPUs accessing the bitmap simultaneously. 29865 maps is
quite obviously too much. AFAICS it makes no sense to use more than
nr_cpu_ids separate bitmap chunks, and for a single SCSI device
probably much less (like 8 or 16 chunks) would be sufficient.
That means that we'd have to calculate the "shift" argument to
sbitmap_init_node() differently.
Here's a tentative patch that would do this, please have a look.
With this patch, the driver would use a bitmap with shift 6 for my
problem case./bitma
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 23e1c0acdeae..3e51f8183b42 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -231,7 +231,8 @@ static void scsi_unlock_floptical(struct scsi_device *sdev,
static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
u64 lun, void *hostdata)
{
- unsigned int depth;
+ static const unsigned int BITMAP_CHUNKS = 16;
+ unsigned int depth, sb_map_chunks, sb_depth;
struct scsi_device *sdev;
struct request_queue *q;
int display_failure_msg = 1, ret;
@@ -298,17 +299,26 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
__scsi_init_queue(sdev->host, q);
WARN_ON_ONCE(!blk_get_queue(q));
- depth = sdev->host->cmd_per_lun ?: 1;
-
/*
* Use .can_queue as budget map's depth because we have to
* support adjusting queue depth from sysfs. Meantime use
* default device queue depth to figure out sbitmap shift
* since we use this queue depth most of times.
+ * Avoid extremely small shift if cmd_per_lun is small but
+ * greater than 3 (see sbitmap_calculate_shift()).
+ * Assume that usually no more than BITMAP_CHUNKS
+ * CPUs will access this bitmap simultaneously.
*/
+ depth = sdev->host->cmd_per_lun ?: 1;
+ sb_map_chunks = max_t(unsigned int, 1U,
+ min_t(unsigned int, nr_cpu_ids, BITMAP_CHUNKS));
+ sb_depth = max_t(unsigned int,
+ scsi_device_max_queue_depth(sdev) / sb_map_chunks,
+ depth);
+
if (sbitmap_init_node(&sdev->budget_map,
scsi_device_max_queue_depth(sdev),
- sbitmap_calculate_shift(depth),
+ sbitmap_calculate_shift(sb_depth),
GFP_KERNEL, sdev->request_queue->node,
false, true)) {
put_device(&starget->dev);
Regards,
Martin
Below is a dmesg snippet illustrating the problem.
See "Current Controller Queue Depth" (=can_queue).
[ 2760.377997] mpt2sas_cm0: scatter gather: sge_in_main_msg(1), sge_per_chain(9), sge_per_io(128), chains_per_io(15)
[ 2760.475225] mpt2sas_cm0: request pool(0x000000004d742465) - dma(0x447800000): depth(30127), frame_size(128), pool_size(3765 kB)
[ 2761.787680] mpt2sas_cm0: sense pool(0x0000000069af807c) - dma(0x447400000): depth(29868), element_size(96), pool_size (2800 kB)
[ 2761.898550] mpt2sas_cm0: sense pool(0x0000000069af807c)- dma(0x447400000): depth(29868),element_size(96), pool_size(0 kB)
[ 2762.002396] mpt2sas_cm0: reply pool(0x000000005def89ce) - dma(0x44b400000): depth(30191), frame_size(128), pool_size(3773 kB)
[ 2762.107551] mpt2sas_cm0: config page(0x00000000dc01e404) - dma(0x44d69f000): size(512)
[ 2762.183235] mpt2sas_cm0: Allocated physical memory: size(66932 kB)
[ 2762.242790] mpt2sas_cm0: Current Controller Queue Depth(29865),Max Controller Queue Depth(32455)
[ 2762.326393] mpt2sas_cm0: Scatter Gather Elements per IO(128)
[ 2762.426639] mpt2sas_cm0: LSISAS2116: FWVersion(15.00.00.00), ChipRevision(0x02), BiosVersion(07.29.00.00)
[ 2762.517588] mpt2sas_cm0: Protocol=(Initiator,Target), Capabilities=(TLR,EEDP,Snapshot Buffer,Diag Trace Buffer,Task Set Full,NCQ)
[ 2762.626129] scsi host1: Fusion MPT SAS Host
[ 2762.669095] blk-mq: reduced tag depth to 10240
[ 2762.721135] mpt2sas_cm0: sending port enable !!
[ 2762.768419] mpt2sas_cm0: hba_port entry: 00000000c01410d1, port: 255 is added to hba_port list
[ 2762.858130] mpt2sas_cm0: host_add: handle(0x0001), sas_addr(0x500605b002d80ae0), phys(16)
[ 2762.937991] mpt2sas_cm0: handle(0x11) sas_address(0x500a0b838933700c) port_type(0x4)
[ 2763.012583] mpt2sas_cm0: handle(0x14) sas_address(0x50080e51beede010) port_type(0x4)
[ 2763.086293] mpt2sas_cm0: handle(0x12) sas_address(0x500a0b83763eb00c) port_type(0x4)
[ 2763.161090] mpt2sas_cm0: handle(0x13) sas_address(0x50080e51bf1f0010) port_type(0x4)
[ 2763.243850] mpt2sas_cm0: port enable: SUCCESS
[ 2763.290141] ------------[ cut here ]------------
[ 2763.336935] WARNING: CPU: 15 PID: 9641 at mm/page_alloc.c:5344 __alloc_pages+0x2a1/0x340
[ 2764.707134] CPU: 15 PID: 9641 Comm: kworker/u258:2 Tainted: G I E 5.16.0-rc8-mw #1 openSUSE Tumbleweed (unreleased) d2750100410fdc3981005f9733dae65153e2c621
[ 2764.707140] Hardware name: HP ProLiant DL560 Gen8, BIOS P77
05/24/2019
[ 2764.707144] Workqueue: events_unbound async_run_entry_fn
[ 2764.707153] RIP: 0010:__alloc_pages+0x2a1/0x340
[ 2764.707155] Code: 3d fb f6 a6 01 01 76 0e 48 83 b8 d0 f9 ff ff 00 0f 84 e2 fe ff ff 80 ce 01 e9 da fe ff ff 81 e7 00 20 00 00 0f 85 79 ff ff ff <0f> 0b e9 72 ff ff ff 48 89 c7 e8 30 c8 fb ff e9 91 fe ff ff 31 c0
[ 2764.707158] RSP: 0018:ffffb5dfc688fa80 EFLAGS: 00010246
[ 2764.707160] RAX: 0000000000000000 RBX: 00000000000074a9 RCX: 0000000000000000
[ 2764.707161] RDX: 0000000000000001 RSI: 000000000000000b RDI: 0000000000000000
[ 2764.707163] RBP: 000000000000000b R08: 0000000000000000 R09: 0000000000000000
[ 2764.707164] R10: 000000000000007f R11: 000000000000000f R12: 0000000000577ec0
[ 2764.707166] R13: 0000000000000cc0 R14: 00000000ffffffff R15: 0000000000000080
[ 2764.707167] FS: 0000000000000000(0000) GS:ffff8954ef7c0000(0000) knlGS:0000000000000000
[ 2764.707169] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2764.707170] CR2: 00007fdb29c3ffa0 CR3: 00000002c6a10006 CR4: 00000000000606e0
[ 2764.707172] Call Trace:
[ 2764.707178] <TASK>
[ 2764.707185] kmalloc_large_node+0x3a/0xa0
[ 2764.707192] __kmalloc_node+0x2b7/0x330
[ 2764.707195] sbitmap_init_node+0x7d/0x1a0
[ 2764.707204] scsi_alloc_sdev+0x25e/0x330
[ 2764.707210] scsi_probe_and_add_lun+0x43d/0xdf0
[ 2764.707214] __scsi_scan_target+0xf9/0x610
...
[ 2766.769381] </TASK>
[ 2766.769382] ---[ end trace ac1aec9da4689c68 ]---
[ 2766.769387] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
^ permalink raw reply related
* Re: [PATCH net-next] net/sched: add missing tracker information in qdisc_create()
From: patchwork-bot+netdevbpf @ 2022-01-05 18:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, netdev, edumazet
In-Reply-To: <20220104170439.3790052-1-eric.dumazet@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 4 Jan 2022 09:04:39 -0800 you wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> qdisc_create() error path needs to use dev_put_track()
> because qdisc_alloc() allocated the tracker.
>
> Fixes: 606509f27f67 ("net/sched: add net device refcount tracker to struct Qdisc")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> [...]
Here is the summary with links:
- [net-next] net/sched: add missing tracker information in qdisc_create()
https://git.kernel.org/netdev/net-next/c/88248c357c2a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] netlink: do not allocate a device refcount tracker in ethnl_default_notify()
From: patchwork-bot+netdevbpf @ 2022-01-05 18:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, netdev, edumazet, johannes
In-Reply-To: <20220105170849.2610470-1-eric.dumazet@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 5 Jan 2022 09:08:49 -0800 you wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> As reported by Johannes, the tracker allocated in
> ethnl_default_notify() is not really needed, as this
> function is not expected to change a device reference count.
>
> Fixes: e4b8954074f6 ("netlink: add net device refcount tracker to struct ethnl_req_info")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Tested-by: Johannes Berg <johannes@sipsolutions.net>
>
> [...]
Here is the summary with links:
- [net-next] netlink: do not allocate a device refcount tracker in ethnl_default_notify()
https://git.kernel.org/netdev/net-next/c/2d6ec25539b0
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
From: Zeng, Oak @ 2022-01-05 17:59 UTC (permalink / raw)
To: Thomas Hellström, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Bloomfield, Jon, Vetter, Daniel,
Wilson, Chris P
Cc: Auld, Matthew
In-Reply-To: <8ea33d30-7765-4c2a-8e19-a99e993d8b33@linux.intel.com>
Regards,
Oak
> -----Original Message-----
> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Sent: January 5, 2022 8:44 AM
> To: Zeng, Oak <oak.zeng@intel.com>; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Bloomfield, Jon
> <jon.bloomfield@intel.com>; Vetter, Daniel <daniel.vetter@intel.com>; Wilson, Chris P <chris.p.wilson@intel.com>
> Cc: Auld, Matthew <matthew.auld@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
>
>
> On 1/4/22 17:07, Thomas Hellström wrote:
> > Hi, Oak,
> >
> > On 1/4/22 16:35, Zeng, Oak wrote:
> >>
> >> Regards,
> >> Oak
> >>
> >>> -----Original Message-----
> >>> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> >>> Sent: January 4, 2022 3:29 AM
> >>> To: Zeng, Oak <oak.zeng@intel.com>; intel-gfx@lists.freedesktop.org;
> >>> dri-devel@lists.freedesktop.org
> >>> Cc: Auld, Matthew <matthew.auld@intel.com>
> >>> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma
> >>> resource as argument for gtt binding / unbinding
> >>>
> >>> Hi, Oak.
> >>>
> >>> On 1/4/22 00:08, Zeng, Oak wrote:
> >>>> Regards,
> >>>> Oak
> >>> Looks like your emails always start with "Regards, Oak". a
> >>> misconfiguration?
> >> My mail client (outlook) is set to automatically add a regards, when
> >> I compose new mail or reply email. Not a big problem 😊
> >>
> >>>
> >>>>> -----Original Message-----
> >>>>> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> >>>>> Sent: January 3, 2022 1:58 PM
> >>>>> To: Zeng, Oak <oak.zeng@intel.com>;
> >>>>> intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> >>>>> Cc: Auld, Matthew <matthew.auld@intel.com>
> >>>>> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma
> >>>>> resource as argument for gtt binding / unbinding
> >>>>>
> >>>>> Hi, Oak.
> >>>>>
> >>>>> On 1/3/22 19:17, Zeng, Oak wrote:
> >>>>>> Regards,
> >>>>>> Oak
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On
> >>>>>>> Behalf Of Thomas Hellström
> >>>>>>> Sent: January 3, 2022 7:00 AM
> >>>>>>> To: intel-gfx@lists.freedesktop.org;
> >>>>>>> dri-devel@lists.freedesktop.org
> >>>>>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>; Auld,
> >>>>>>> Matthew <matthew.auld@intel.com>
> >>>>>>> Subject: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma
> >>>>>>> resource as argument for gtt binding / unbinding
> >>>>>>>
> >>>>>>> When introducing asynchronous unbinding, the vma itself may no
> >>>>>>> longer
> >>>>>>> be alive when the actual binding or unbinding takes place.
> >>>>>> Can we take an extra reference counter of the vma to keep the vma
> >>>>>> alive, until the actual binding/unbinding takes place?
> >>>>> The point here is that that's not needed, and should be avoided.
> >>>> Can you explain more why "keeping vma alive until unbinding takes
> >>>> place" should be avoided?
> >>>>
> >>>> As I understand it, your series introduce asynchronized unbinding.
> >>>> But since vma might be no longer alive at the time of unbinding.
> >>> To overcome this difficulty, you introduce a vma resource structure
> >>> and you guarantee vma resource is alive at bind/unbind time. So
> >>> you can use vma resource for the bind/unbind operation. My question
> >>> is, can we achieve the asynchronized unbinding still using vma
> >>> structure by keeping vma structure alive ( by ref count it). This
> >>> way the change should be much smaller (compared to this series). Why
> >>> it is harmful to keep the vma alive? Maybe you have other reasons to
> >>> introduce vma resource that I don't see.
> >>>
> >>> When we allow asynchronous unbinding, it's allowed to immediately
> >>> rebind
> >>> the vma, possibly into the same gpu virtual address, but with different
> >>> pages. And when doing that we don't want to block waiting for the
> >>> unbind
> >>> to execute.
> >> Imagine this sequence:
> >>
> >> 1. Virtual address a1 is bound to physical page p1
> >> 2. Unbind a1 from p1, asynchronous so actual unbind not happen yet
> >> 3. bind a1 to physical page p2, page table is changed, now a1
> >> pointing to p2 in page table.
> >> 4. #2 now take place now - since in page table, a1 points to p2 now,
> >> does a1 point to scratch page after #4?
> >
> > Here, 3) will also become async, awaiting any pending unbinds in the
> > address range provided to 3), in particular, the bind in 3) will await
> > 4). See i915_vma_resource_bind_dep_await(), and the discussion on
> > whether or not to use an interval tree for this at the start of
> > i915_vma_resource.c
> >
> >> In fact, we could allow a large number of outstanding binds
> >>> and unbinds for a vma, which makes the vma structure unsuitable to
> >>> track
> >>> this, since there will no longer be a single mapping between a set of
> >>> active pages and a vma, or a virtual gpu range and a vma.
> >> I agree that if pages - vma - virtual gpu range is not 1:1:1 mapping,
> >> we need introduce a finer-grained vma resource to for the non-1:1
> >> mapping. I also understand the asynchronous unbinding utilize the
> >> virtual address space more effectively. But my feeling is that this
> >> non-1:1 mapping makes our program hard to understand and maintain.
> >> Since this non- 1:1 mapping is introduced by asynchronous
> >> binding/unbinding, maybe the real question here is, is it really
> >> benefit to introduce asynchronous unbinding?
> >
> > That's a relevant question, which I've asked myself a couple of times.
> > Async unbinding has complicated things like error capture and indeed
> > complicates the understanding of the binding process as well.
> >
> > The main gain is that we avoid a sync point at LMEM eviction, enabling
> > us to pipeline eviction, moving forward it may also find use in the
> > shrinker and for user-space prematurely wanting to re-use softpin
> > addresses.
> >
> > /Thomas
> >
> >>
> >> I am still not familiar enough to the codes. I suggest other experts
> >> to take a look also. @Bloomfield, Jon @Vetter, Daniel @Wilson, Chris P.
>
> It might make sense here to point out as well that the direction from
> the arch team is towards moving towards gpu-writes of page-table entries
> for binding and unbinding, also keeping small PCI bars in mind, which
> will more or less force us to allow async unbinding for maintained
> performance.
I agree we need to support asynchronous bind/unbind. My main argue
Here was, should we introduce a vma resource structure to enable async bind/unbind, versus,
Change the life time of vma structure to achieve async bind/unbind - ie, still introduce a interval
tree for vma (not vma resource in your patch) that is to be unbind but still not unbound. When I
looked more into your patches, I realized if we reuse vma structure, we will need to add a lot of
members to the vma structure. maybe your method of introducing vma resource is cleaner.
Regards,
Oak
>
> /Thomas
>
>
> >>
> >> Regards,
> >> Oak
> >>> Thanks,
> >>>
> >>> /Thomas
> >>>
> >>>> Regards,
> >>>> Oak
> >>>>
> >>>> If the
> >>>>> vma is no longer alive, that means nobody uses it anymore, but the
> >>>>> GPU
> >>>>> may still have work in the pipe that references the GPU virtual
> >>>>> address.
> >>>>>
> >>>>> /Thomas.
> >>>>>
^ permalink raw reply
* RE: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
From: Zeng, Oak @ 2022-01-05 17:59 UTC (permalink / raw)
To: Thomas Hellström, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Bloomfield, Jon, Vetter, Daniel,
Wilson, Chris P
Cc: Auld, Matthew
In-Reply-To: <8ea33d30-7765-4c2a-8e19-a99e993d8b33@linux.intel.com>
Regards,
Oak
> -----Original Message-----
> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Sent: January 5, 2022 8:44 AM
> To: Zeng, Oak <oak.zeng@intel.com>; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Bloomfield, Jon
> <jon.bloomfield@intel.com>; Vetter, Daniel <daniel.vetter@intel.com>; Wilson, Chris P <chris.p.wilson@intel.com>
> Cc: Auld, Matthew <matthew.auld@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
>
>
> On 1/4/22 17:07, Thomas Hellström wrote:
> > Hi, Oak,
> >
> > On 1/4/22 16:35, Zeng, Oak wrote:
> >>
> >> Regards,
> >> Oak
> >>
> >>> -----Original Message-----
> >>> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> >>> Sent: January 4, 2022 3:29 AM
> >>> To: Zeng, Oak <oak.zeng@intel.com>; intel-gfx@lists.freedesktop.org;
> >>> dri-devel@lists.freedesktop.org
> >>> Cc: Auld, Matthew <matthew.auld@intel.com>
> >>> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma
> >>> resource as argument for gtt binding / unbinding
> >>>
> >>> Hi, Oak.
> >>>
> >>> On 1/4/22 00:08, Zeng, Oak wrote:
> >>>> Regards,
> >>>> Oak
> >>> Looks like your emails always start with "Regards, Oak". a
> >>> misconfiguration?
> >> My mail client (outlook) is set to automatically add a regards, when
> >> I compose new mail or reply email. Not a big problem 😊
> >>
> >>>
> >>>>> -----Original Message-----
> >>>>> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> >>>>> Sent: January 3, 2022 1:58 PM
> >>>>> To: Zeng, Oak <oak.zeng@intel.com>;
> >>>>> intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> >>>>> Cc: Auld, Matthew <matthew.auld@intel.com>
> >>>>> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma
> >>>>> resource as argument for gtt binding / unbinding
> >>>>>
> >>>>> Hi, Oak.
> >>>>>
> >>>>> On 1/3/22 19:17, Zeng, Oak wrote:
> >>>>>> Regards,
> >>>>>> Oak
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On
> >>>>>>> Behalf Of Thomas Hellström
> >>>>>>> Sent: January 3, 2022 7:00 AM
> >>>>>>> To: intel-gfx@lists.freedesktop.org;
> >>>>>>> dri-devel@lists.freedesktop.org
> >>>>>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>; Auld,
> >>>>>>> Matthew <matthew.auld@intel.com>
> >>>>>>> Subject: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma
> >>>>>>> resource as argument for gtt binding / unbinding
> >>>>>>>
> >>>>>>> When introducing asynchronous unbinding, the vma itself may no
> >>>>>>> longer
> >>>>>>> be alive when the actual binding or unbinding takes place.
> >>>>>> Can we take an extra reference counter of the vma to keep the vma
> >>>>>> alive, until the actual binding/unbinding takes place?
> >>>>> The point here is that that's not needed, and should be avoided.
> >>>> Can you explain more why "keeping vma alive until unbinding takes
> >>>> place" should be avoided?
> >>>>
> >>>> As I understand it, your series introduce asynchronized unbinding.
> >>>> But since vma might be no longer alive at the time of unbinding.
> >>> To overcome this difficulty, you introduce a vma resource structure
> >>> and you guarantee vma resource is alive at bind/unbind time. So
> >>> you can use vma resource for the bind/unbind operation. My question
> >>> is, can we achieve the asynchronized unbinding still using vma
> >>> structure by keeping vma structure alive ( by ref count it). This
> >>> way the change should be much smaller (compared to this series). Why
> >>> it is harmful to keep the vma alive? Maybe you have other reasons to
> >>> introduce vma resource that I don't see.
> >>>
> >>> When we allow asynchronous unbinding, it's allowed to immediately
> >>> rebind
> >>> the vma, possibly into the same gpu virtual address, but with different
> >>> pages. And when doing that we don't want to block waiting for the
> >>> unbind
> >>> to execute.
> >> Imagine this sequence:
> >>
> >> 1. Virtual address a1 is bound to physical page p1
> >> 2. Unbind a1 from p1, asynchronous so actual unbind not happen yet
> >> 3. bind a1 to physical page p2, page table is changed, now a1
> >> pointing to p2 in page table.
> >> 4. #2 now take place now - since in page table, a1 points to p2 now,
> >> does a1 point to scratch page after #4?
> >
> > Here, 3) will also become async, awaiting any pending unbinds in the
> > address range provided to 3), in particular, the bind in 3) will await
> > 4). See i915_vma_resource_bind_dep_await(), and the discussion on
> > whether or not to use an interval tree for this at the start of
> > i915_vma_resource.c
> >
> >> In fact, we could allow a large number of outstanding binds
> >>> and unbinds for a vma, which makes the vma structure unsuitable to
> >>> track
> >>> this, since there will no longer be a single mapping between a set of
> >>> active pages and a vma, or a virtual gpu range and a vma.
> >> I agree that if pages - vma - virtual gpu range is not 1:1:1 mapping,
> >> we need introduce a finer-grained vma resource to for the non-1:1
> >> mapping. I also understand the asynchronous unbinding utilize the
> >> virtual address space more effectively. But my feeling is that this
> >> non-1:1 mapping makes our program hard to understand and maintain.
> >> Since this non- 1:1 mapping is introduced by asynchronous
> >> binding/unbinding, maybe the real question here is, is it really
> >> benefit to introduce asynchronous unbinding?
> >
> > That's a relevant question, which I've asked myself a couple of times.
> > Async unbinding has complicated things like error capture and indeed
> > complicates the understanding of the binding process as well.
> >
> > The main gain is that we avoid a sync point at LMEM eviction, enabling
> > us to pipeline eviction, moving forward it may also find use in the
> > shrinker and for user-space prematurely wanting to re-use softpin
> > addresses.
> >
> > /Thomas
> >
> >>
> >> I am still not familiar enough to the codes. I suggest other experts
> >> to take a look also. @Bloomfield, Jon @Vetter, Daniel @Wilson, Chris P.
>
> It might make sense here to point out as well that the direction from
> the arch team is towards moving towards gpu-writes of page-table entries
> for binding and unbinding, also keeping small PCI bars in mind, which
> will more or less force us to allow async unbinding for maintained
> performance.
I agree we need to support asynchronous bind/unbind. My main argue
Here was, should we introduce a vma resource structure to enable async bind/unbind, versus,
Change the life time of vma structure to achieve async bind/unbind - ie, still introduce a interval
tree for vma (not vma resource in your patch) that is to be unbind but still not unbound. When I
looked more into your patches, I realized if we reuse vma structure, we will need to add a lot of
members to the vma structure. maybe your method of introducing vma resource is cleaner.
Regards,
Oak
>
> /Thomas
>
>
> >>
> >> Regards,
> >> Oak
> >>> Thanks,
> >>>
> >>> /Thomas
> >>>
> >>>> Regards,
> >>>> Oak
> >>>>
> >>>> If the
> >>>>> vma is no longer alive, that means nobody uses it anymore, but the
> >>>>> GPU
> >>>>> may still have work in the pipe that references the GPU virtual
> >>>>> address.
> >>>>>
> >>>>> /Thomas.
> >>>>>
^ permalink raw reply
* Re: [PATCH v6 0/6] x86/xen: Add in-kernel Xen event channel delivery
From: David Woodhouse @ 2022-01-05 17:58 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, Boris Ostrovsky, Joao Martins, jmattson @ google . com,
wanpengli @ tencent . com, vkuznets @ redhat . com,
mtosatti @ redhat . com, joro @ 8bytes . org, karahmed,
butt3rflyh4ck
In-Reply-To: <YcTpJ369cRBN4W93@google.com>
On Thu, 2021-12-23 at 21:24 +0000, Sean Christopherson wrote:
> Commit e880c6ea55b9 ("KVM: x86: hyper-v: Prevent using not-yet-updated TSC page
> by secondary CPUs") is squarely to blame as it was added after dirty ring, though
> in Vitaly's defense, David put it best: "That's a fairly awful bear trap".
Even with the WARN to keep us honest, this is still awful.
We have kvm_vcpu_write_guest()... but the vcpu we pass it is ignored
and only vcpu->kvm is used. But you have to be running on a physical
CPU which currently owns *a* vCPU of that KVM, or you might crash.
There is also kvm_write_guest() which doesn't take a vCPU as an
argument, and looks for all the world like it was designed for you not
to need one... but which still needs there to be a vCPU or it might
crash.
I think I want to kill the latter, make the former use the vCPU it's
given, add a spinlock to the dirty ring which will be uncontended
anyway in the common case so it shouldn't hurt (?), and then let people
use kvm->vcpu[0] when they really need to, with a documented caveat
that when there are *no* vCPUs in a KVM, dirty tracking might not work.
Which is fine, as migration of a KVM that hasn't been fully set up yet
is silly.
^ permalink raw reply
* CI for qemu-hexagon
From: Alessandro Di Federico via @ 2022-01-05 17:57 UTC (permalink / raw)
To: Alex Bennée; +Cc: tsimpson, Anton Johansson via, Brian Cain
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
Hi Alex, I hope you enjoyed the holidays!
We're trying to upstream idef-parser (the automatic generator of the
Hexagon frontend). This introduces new dependencies, specifically flex
and bison.
Attached you can find our patch for that.
However the CI fails:
https://gitlab.com/carl.cudig/qemu/-/jobs/1939950230
AFAIU the Hexagon docker image is "special" since it's the only one
that needs the cross-compiler to be built from source and, therefore,
it's a process that needs to be triggered manually.
Is this correct?
If so, what should we do? Make a pull request despite the failure and
then it will be taken care of, or should I make a separate (preliminary)
pull request just for that patch?
--
Alessandro Di Federico
rev.ng
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: import-flex-bison.patch --]
[-- Type: text/x-patch, Size: 9951 bytes --]
commit 14e90d55b368b4a56fde668b66311bab6e1a4518
Author: Paolo Montesel <babush@rev.ng>
Date: Thu Dec 9 13:23:06 2021 +0100
target/hexagon: import flex/bison to docker files
Signed-off-by: Alessandro Di Federico <ale@rev.ng>
Signed-off-by: Paolo Montesel <babush@rev.ng>
Signed-off-by: Anton Johansson <anjo@rev.ng>
diff --git a/.gitlab-ci.d/windows.yml b/.gitlab-ci.d/windows.yml
index 309f7e7fb86..2abfe4e91aa 100644
--- a/.gitlab-ci.d/windows.yml
+++ b/.gitlab-ci.d/windows.yml
@@ -33,6 +33,7 @@ msys2-64bit:
script:
- .\msys64\usr\bin\bash -lc "pacman -Sy --noconfirm --needed
diffutils git grep make sed
+ flex bison
mingw-w64-x86_64-capstone
mingw-w64-x86_64-curl
mingw-w64-x86_64-cyrus-sasl
@@ -68,6 +69,7 @@ msys2-32bit:
script:
- .\msys64\usr\bin\bash -lc "pacman -Sy --noconfirm --needed
diffutils git grep make sed
+ flex bison
mingw-w64-i686-capstone
mingw-w64-i686-curl
mingw-w64-i686-cyrus-sasl
diff --git a/tests/docker/dockerfiles/alpine.docker b/tests/docker/dockerfiles/alpine.docker
index 7e6997e3015..45db55ba55a 100644
--- a/tests/docker/dockerfiles/alpine.docker
+++ b/tests/docker/dockerfiles/alpine.docker
@@ -9,9 +9,11 @@ ENV PACKAGES \
alsa-lib-dev \
bash \
binutils \
+ bison \
ccache \
coreutils \
curl-dev \
+ flex \
g++ \
gcc \
git \
diff --git a/tests/docker/dockerfiles/centos8.docker b/tests/docker/dockerfiles/centos8.docker
index 7f135f8e8c0..d93bbe30026 100644
--- a/tests/docker/dockerfiles/centos8.docker
+++ b/tests/docker/dockerfiles/centos8.docker
@@ -5,6 +5,7 @@ ENV PACKAGES \
SDL2-devel \
alsa-lib-devel \
bc \
+ bison \
brlapi-devel \
bzip2 \
bzip2-devel \
@@ -19,6 +20,7 @@ ENV PACKAGES \
device-mapper-multipath-devel \
diffutils \
findutils \
+ flex \
gcc \
gcc-c++ \
genisoimage \
diff --git a/tests/docker/dockerfiles/debian-amd64.docker b/tests/docker/dockerfiles/debian-amd64.docker
index ed546edcd65..805fd6f981d 100644
--- a/tests/docker/dockerfiles/debian-amd64.docker
+++ b/tests/docker/dockerfiles/debian-amd64.docker
@@ -14,9 +14,11 @@ RUN apt update && \
RUN apt update && \
DEBIAN_FRONTEND=noninteractive eatmydata \
apt install -y --no-install-recommends \
+ bison \
cscope \
genisoimage \
exuberant-ctags \
+ flex \
global \
libbz2-dev \
liblzo2-dev \
diff --git a/tests/docker/dockerfiles/debian-native.docker b/tests/docker/dockerfiles/debian-native.docker
index efd55cb6e0e..02ccaf98fd1 100644
--- a/tests/docker/dockerfiles/debian-native.docker
+++ b/tests/docker/dockerfiles/debian-native.docker
@@ -26,13 +26,16 @@ RUN apt update && \
RUN apt update && \
DEBIAN_FRONTEND=noninteractive eatmydata \
apt install -y --no-install-recommends \
+ bison \
cscope \
genisoimage \
exuberant-ctags \
+ flex \
global \
libbz2-dev \
liblzo2-dev \
libgcrypt20-dev \
+ libglib2.0-dev \
libfdt-dev \
librdmacm-dev \
libsasl2-dev \
diff --git a/tests/docker/dockerfiles/debian-riscv64-cross.docker b/tests/docker/dockerfiles/debian-riscv64-cross.docker
index 594d97982c1..f5553afc2e1 100644
--- a/tests/docker/dockerfiles/debian-riscv64-cross.docker
+++ b/tests/docker/dockerfiles/debian-riscv64-cross.docker
@@ -17,12 +17,15 @@ RUN apt update && \
# Install common build utilities
RUN DEBIAN_FRONTEND=noninteractive eatmydata apt install -yy \
bc \
+ bison \
build-essential \
ca-certificates \
debian-ports-archive-keyring \
dpkg-dev \
+ flex \
gettext \
git \
+ libglib2.0-dev \
ninja-build \
pkg-config \
python3
diff --git a/tests/docker/dockerfiles/debian-tricore-cross.docker b/tests/docker/dockerfiles/debian-tricore-cross.docker
index d8df2c61170..9191aafc7f3 100644
--- a/tests/docker/dockerfiles/debian-tricore-cross.docker
+++ b/tests/docker/dockerfiles/debian-tricore-cross.docker
@@ -16,9 +16,11 @@ MAINTAINER Philippe Mathieu-Daudé <f4bug@amsat.org>
RUN apt update && \
DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata && \
DEBIAN_FRONTEND=noninteractive eatmydata apt install -yy \
+ bison \
bzip2 \
ca-certificates \
ccache \
+ flex \
g++ \
gcc \
git \
diff --git a/tests/docker/dockerfiles/debian10.docker b/tests/docker/dockerfiles/debian10.docker
index b414af1b9f7..06b8d9d6b0f 100644
--- a/tests/docker/dockerfiles/debian10.docker
+++ b/tests/docker/dockerfiles/debian10.docker
@@ -17,16 +17,19 @@ RUN apt update && \
DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata && \
DEBIAN_FRONTEND=noninteractive eatmydata \
apt install -y --no-install-recommends \
+ bison \
bc \
build-essential \
ca-certificates \
ccache \
clang \
dbus \
+ flex \
gdb-multiarch \
gettext \
git \
libffi-dev \
+ libglib2.0-dev \
libncurses5-dev \
ninja-build \
pkg-config \
diff --git a/tests/docker/dockerfiles/fedora-i386-cross.docker b/tests/docker/dockerfiles/fedora-i386-cross.docker
index 13328e6081f..ae009a203f5 100644
--- a/tests/docker/dockerfiles/fedora-i386-cross.docker
+++ b/tests/docker/dockerfiles/fedora-i386-cross.docker
@@ -1,12 +1,15 @@
FROM registry.fedoraproject.org/fedora:34
ENV PACKAGES \
+ bison \
bzip2 \
ccache \
diffutils \
findutils \
+ flex \
gcc \
git \
+ glib2-devel \
libffi-devel.i686 \
libselinux-devel.i686 \
libtasn1-devel.i686 \
diff --git a/tests/docker/dockerfiles/fedora-win32-cross.docker b/tests/docker/dockerfiles/fedora-win32-cross.docker
index aad39dd97ff..9ae8eda39f7 100644
--- a/tests/docker/dockerfiles/fedora-win32-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win32-cross.docker
@@ -2,14 +2,17 @@ FROM registry.fedoraproject.org/fedora:33
# Please keep this list sorted alphabetically
ENV PACKAGES \
+ bison \
bc \
bzip2 \
ccache \
diffutils \
findutils \
+ flex \
gcc \
gettext \
git \
+ glib2-devel \
hostname \
make \
meson \
diff --git a/tests/docker/dockerfiles/fedora-win64-cross.docker b/tests/docker/dockerfiles/fedora-win64-cross.docker
index 9a224a619bd..c59a130d001 100644
--- a/tests/docker/dockerfiles/fedora-win64-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win64-cross.docker
@@ -2,13 +2,16 @@ FROM registry.fedoraproject.org/fedora:33
# Please keep this list sorted alphabetically
ENV PACKAGES \
+ bison \
bc \
bzip2 \
ccache \
diffutils \
findutils \
+ flex \
gcc \
gettext \
+ glib2-devel \
git \
hostname \
make \
diff --git a/tests/docker/dockerfiles/fedora.docker b/tests/docker/dockerfiles/fedora.docker
index c6fd7e1113d..b19ef01bf7d 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -2,6 +2,7 @@ FROM registry.fedoraproject.org/fedora:33
# Please keep this list sorted alphabetically
ENV PACKAGES \
+ bison \
SDL2-devel \
SDL2_image-devel \
alsa-lib-devel \
@@ -20,6 +21,7 @@ ENV PACKAGES \
device-mapper-multipath-devel \
diffutils \
findutils \
+ flex \
gcc \
gcc-c++ \
gcovr \
diff --git a/tests/docker/dockerfiles/opensuse-leap.docker b/tests/docker/dockerfiles/opensuse-leap.docker
index 3bbdb67f4fa..b868ca71982 100644
--- a/tests/docker/dockerfiles/opensuse-leap.docker
+++ b/tests/docker/dockerfiles/opensuse-leap.docker
@@ -5,6 +5,7 @@ ENV PACKAGES \
Mesa-devel \
alsa-lib-devel \
bc \
+ bison \
brlapi-devel \
bzip2 \
ca-certificates \
@@ -15,6 +16,7 @@ ENV PACKAGES \
dbus-1 \
diffutils \
findutils \
+ flex \
gcc \
gcc-c++ \
gcovr \
diff --git a/tests/docker/dockerfiles/ubuntu.docker b/tests/docker/dockerfiles/ubuntu.docker
index f0e0180d215..5667ef592cf 100644
--- a/tests/docker/dockerfiles/ubuntu.docker
+++ b/tests/docker/dockerfiles/ubuntu.docker
@@ -11,9 +11,11 @@
FROM docker.io/library/ubuntu:20.04
ENV PACKAGES \
+ bison \
ccache \
clang \
dbus \
+ flex \
gcc \
gettext \
git \
@@ -30,6 +32,7 @@ ENV PACKAGES \
libfdt-dev \
libffi-dev \
libgbm-dev \
+ libglib2.0-dev \
libgnutls28-dev \
libgtk-3-dev \
libibverbs-dev \
diff --git a/tests/docker/dockerfiles/ubuntu1804.docker b/tests/docker/dockerfiles/ubuntu1804.docker
index 450fd06d0d5..ce7d15c03e2 100644
--- a/tests/docker/dockerfiles/ubuntu1804.docker
+++ b/tests/docker/dockerfiles/ubuntu1804.docker
@@ -1,6 +1,7 @@
FROM docker.io/library/ubuntu:18.04
ENV PACKAGES \
bc \
+ bison \
bsdmainutils \
bzip2 \
ca-certificates \
@@ -11,6 +12,7 @@ ENV PACKAGES \
diffutils \
exuberant-ctags \
findutils \
+ flex \
g++ \
gcc \
gcovr \
diff --git a/tests/docker/dockerfiles/ubuntu2004.docker b/tests/docker/dockerfiles/ubuntu2004.docker
index 15a026be091..d39d4ea07f2 100644
--- a/tests/docker/dockerfiles/ubuntu2004.docker
+++ b/tests/docker/dockerfiles/ubuntu2004.docker
@@ -1,5 +1,6 @@
FROM docker.io/library/ubuntu:20.04
ENV PACKAGES \
+ bison \
bc \
bsdmainutils \
bzip2 \
@@ -11,6 +12,7 @@ ENV PACKAGES \
diffutils \
exuberant-ctags \
findutils \
+ flex \
g++ \
gcc \
gcovr \
^ permalink raw reply related
* Re: Add timestamp to dpdk.log
From: Stephen Hemminger @ 2022-01-05 17:58 UTC (permalink / raw)
To: Soumya Muralidhar; +Cc: dev@dpdk.org
In-Reply-To: <892917C6-9F3F-4AF0-9429-A4AC19DC47BC@gigamon.com>
On Wed, 5 Jan 2022 17:42:49 +0000
Soumya Muralidhar <soumya.muralidhar@gigamon.com> wrote:
> Hi Stephen,
>
> Thanks for getting back. But I am looking at storing logs with timestamps in a file, basically something similar to syslog. Could you help me with that ?
>
> Regards,
> Soumya
>
> On 1/5/22, 8:17 AM, "Stephen Hemminger" <stephen@networkplumber.org> wrote:
>
> WARNING: This email originated from outside of Gigamon. Use caution with any links or attachments.
>
>
> Your message is garbaled with lots of bogus URL's. Please avoid HTML mail
> or weird links.
>
> I use this. There was a more general version submitted as a patch to
> DPDK but no one seemed interested. The reason for redirecting stdout
> is that are libraries we use that print to stdout and want to get timestamps
> from them if debugging startup issues.
>
>
> /*
> * Sample of redirecting DPDK log stream.
> *
> * If program is run for debugging then stdout will be a console and
> * put messages onto console stream with timestamps. Otherwise, just
> * put message onto stderr which systemd journal handles. No need for
> * syslog because that causes duplicate messages.
> */
>
> static struct timespec log_t0; /* Start program in monotonic time */
>
> /*
> * Write message to standard output with timestamp.
> * Use writev() so that timestamp and message do not get interleaved.
> */
> static ssize_t
> dpdk_log_tty_write(__rte_unused void *ctx, const char *buf, size_t size)
> {
> struct timespec ts;
> struct iovec iov[2];
> char tbuf[64];
>
> /* format up monotonic timestamp */
> clock_gettime(CLOCK_MONOTONIC, &ts);
>
> ts.tv_sec -= log_t0.tv_sec;
> ts.tv_nsec -= log_t0.tv_nsec;
> if (ts.tv_nsec < 0) {
> --ts.tv_sec;
> ts.tv_nsec += NS_PER_S;
> }
>
> iov[0].iov_base = tbuf;
> iov[0].iov_len = snprintf(tbuf, sizeof(tbuf), "[%8lu.%06lu] ",
> ts.tv_sec, ts.tv_nsec / 1000u);
>
> /* extra cast is workaround to remove const qualifier */
> iov[1].iov_base = (void *)(uintptr_t)buf;
> iov[1].iov_len = size;
>
> return writev(STDOUT_FILENO, iov, 2);
> }
>
> static cookie_io_functions_t dpdk_log_tty_func = {
> .write = dpdk_log_tty_write,
> };
>
> /*
> * Print message to stderr with priority format so that
> * Systemd journal can handle it. Alternative would be
> * to use syslog or use sd_journal; but less is more.
> */
> static ssize_t
> dpdk_log_write(__rte_unused void *ctx, const char *buf, size_t size)
> {
> /* Syslog error levels are from 0 to 7, DPDK uses 1 to 8 */
> int priority = rte_log_cur_msg_loglevel() - 1;
>
> fprintf(stderr, "<%i>%.*s\n", priority, (int)size, buf);
> return size;
> }
>
> static cookie_io_functions_t dpdk_log_func = {
> .write = dpdk_log_write,
> };
>
> /*
> * Override default DPDK logging which duplicates messages
> * to both stderr and syslog.
> */
> static void log_init(void)
> {
> backplane_logtype = rte_log_register("backplane");
> if (backplane_logtype >= 0)
> rte_log_set_level(backplane_logtype, RTE_LOG_INFO);
>
> if (isatty(STDOUT_FILENO)) {
> clock_gettime(CLOCK_MONOTONIC, &log_t0);
>
> stdout = fopencookie(NULL, "w+", dpdk_log_tty_func);
> setlinebuf(stdout);
> rte_openlog_stream(stdout);
> } else {
> FILE *jf;
>
> jf = fopencookie(NULL, "w+", dpdk_log_func);
> rte_openlog_stream(jf);
> }
> }
>
> /* Put DPDK log back onto stderr */
> static void log_uninit(void)
> {
> FILE *logf;
>
> logf = rte_log_get_stream();
> if (logf != stderr) {
> rte_openlog_stream(stderr);
> fclose(logf);
> }
> }
>
> This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Gigamon email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails (“spam”).
Just use my example and make code like dpdk_tty_log_write that does writev to your file.
^ permalink raw reply
* Re: [PATCH v1 11/13] KVM: x86/mmu: Split huge pages during CLEAR_DIRTY_LOG
From: David Matlack @ 2022-01-05 17:57 UTC (permalink / raw)
To: Peter Xu
Cc: Paolo Bonzini, kvm list, Ben Gardon, Joerg Roedel, Jim Mattson,
Wanpeng Li, Vitaly Kuznetsov, Sean Christopherson,
Janis Schoetterl-Glausch, Junaid Shahid, Oliver Upton,
Harish Barathvajasankar, Peter Shier, Nikunj A . Dadhania
In-Reply-To: <CALzav=fqg3AzrJkWR3StKLG38vzwcycSu19M=TFfCWg+wG8q9Q@mail.gmail.com>
On Wed, Jan 5, 2022 at 9:55 AM David Matlack <dmatlack@google.com> wrote:
>
> On Wed, Jan 5, 2022 at 1:02 AM Peter Xu <peterx@redhat.com> wrote:
> >
> > On Mon, Dec 13, 2021 at 10:59:16PM +0000, David Matlack wrote:
> > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > > index c9e5fe290714..55640d73df5a 100644
> > > --- a/arch/x86/kvm/mmu/mmu.c
> > > +++ b/arch/x86/kvm/mmu/mmu.c
> > > @@ -1362,6 +1362,20 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
> > > gfn_t start = slot->base_gfn + gfn_offset + __ffs(mask);
> > > gfn_t end = slot->base_gfn + gfn_offset + __fls(mask);
> > >
> > > + /*
> > > + * Try to proactively split any huge pages down to 4KB so that
> > > + * vCPUs don't have to take write-protection faults.
> > > + *
> > > + * Drop the MMU lock since huge page splitting uses its own
> > > + * locking scheme and does not require the write lock in all
> > > + * cases.
> > > + */
> > > + if (READ_ONCE(eagerly_split_huge_pages_for_dirty_logging)) {
> > > + write_unlock(&kvm->mmu_lock);
> > > + kvm_mmu_try_split_huge_pages(kvm, slot, start, end, PG_LEVEL_4K);
> > > + write_lock(&kvm->mmu_lock);
> > > + }
> > > +
> > > kvm_mmu_slot_gfn_write_protect(kvm, slot, start, PG_LEVEL_2M);
> >
> > Would it be easier to just allow passing in shared=true/false for the new
> > kvm_mmu_try_split_huge_pages(), then previous patch will not be needed? Or is
> > it intended to do it for performance reasons?
> >
> > IOW, I think this patch does two things: (1) support clear-log on eager split,
> > and (2) allow lock degrade during eager split.
> >
> > It's just that imho (2) may still need some justification on necessity since
> > this function only operates on a very small range of guest mem (at most
> > 4K*64KB=256KB range), so it's not clear to me whether the extra lock operations
> > are needed at all; after all it'll make the code slightly harder to follow.
> > Not to mention the previous patch is preparing for this, and both patches will
> > add lock operations.
> >
> > I think dirty_log_perf_test didn't cover lock contention case, because clear
> > log was run after vcpu threads stopped, so lock access should be mostly hitting
> > the cachelines there, afaict. While in real life, clear log is run with vcpus
> > running. Not sure whether that'll be a problem, so raising this question up.
>
> Good point. Dropping the write lock to acquire the read lock is
> probably not necessary since we're splitting a small region of memory
> here. Plus the splitting code detects contention and will drop the
> lock if necessary. And the value of dropping the lock is dubious since
> it adds a lot more lock operations.
I wasn't very clear here. I meant the value of "dropping the write
lock to switch the read lock every time we split" is dubious since it
adds more lock operations. Dropping the lock and yielding when there's
contention detected is not dubious :).
>
> I'll try your suggestion in v3.
>
> >
> > Thanks,
>
>
> >
> > --
> > Peter Xu
> >
^ permalink raw reply
* Re: Wrong piix4_smbus address / slow trackpoint on Thinkpad P14s gen 2 (AMD)
From: Miroslav Bendík @ 2022-01-05 17:57 UTC (permalink / raw)
To: linux-i2c, linux-input
In-Reply-To: <CAPoEpV0ZSidL6aMXvB6LN1uS-3CUHS4ggT8RwFgmkzzCiYJ-XQ@mail.gmail.com>
Address detection does not work because cd6h/cd7h port io can be
disabled, but
it's accessible using mmio. This patch:
https://lore.kernel.org/all/20210715221828.244536-1-Terry.Bowman@amd.com/
with
modified AMD_PCI_SMBUS_REVISION_MMIO fixed base address detection.
Problem with RMI4 touchpad / trackpoint remains, because rmi4-smbus
needs host
notify feature. I have tried implement this feature, without success.
Interrupts
on IRQ 7 (SMBus) are generated only for block data transfers, but not for
trackpoint / touchpad move actions. I have looked at pinctrl_amd and it
looks,
that activity is signaled using GPIO. This looks promising:
cat /sys/kernel/debug/pinctrl/AMDI0030:00/pingroups:
group: i2c0
pin 145 (GPIO_145)
pin 146 (GPIO_146)
group: i2c1
pin 147 (GPIO_147)
pin 148 (GPIO_148)
group: i2c2
pin 113 (GPIO_113)
pin 114 (GPIO_114)
group: i2c3
pin 19 (GPIO_19)
pin 20 (GPIO_20)
After loading psmouse with forced enabled intertouch pin 19/20 started
generating events.
^ permalink raw reply
* [PATCH] firmware: memmap: use default_groups in kobj_type
From: Greg Kroah-Hartman @ 2022-01-05 17:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the firmware memmap sysfs code to use default_groups field
which has been the preferred way since aa30f47cf666 ("kobject: Add
support for default attribute groups to kobj_type") so that we can soon
get rid of the obsolete default_attrs field.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/memmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 24945e2da77b..8e59be3782cb 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -69,6 +69,7 @@ static struct attribute *def_attrs[] = {
&memmap_type_attr.attr,
NULL
};
+ATTRIBUTE_GROUPS(def);
static const struct sysfs_ops memmap_attr_ops = {
.show = memmap_attr_show,
@@ -118,7 +119,7 @@ static void __meminit release_firmware_map_entry(struct kobject *kobj)
static struct kobj_type __refdata memmap_ktype = {
.release = release_firmware_map_entry,
.sysfs_ops = &memmap_attr_ops,
- .default_attrs = def_attrs,
+ .default_groups = def_groups,
};
/*
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v5] soc: ti: smartreflex: Use platform_get_irq_optional() to get the interrupt
From: Lad, Prabhakar @ 2022-01-05 17:55 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lad Prabhakar, Nishanth Menon, Santosh Shilimkar, Rob Herring,
Linux Kernel Mailing List, linux-arm Mailing List, Linux PM
In-Reply-To: <CAHp75Ve+0VmfU7GhC=AjZ3J1J6KtGko2YAenA9mXCSCVrcuX5w@mail.gmail.com>
Hi Andy,
Thank you for the review.
On Wed, Jan 5, 2022 at 9:47 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Jan 4, 2022 at 6:45 PM Lad Prabhakar
> <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> >
> > platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> > allocation of IRQ resources in DT core code, this causes an issue
> > when using hierarchical interrupt domains using "interrupts" property
> > in the node as this bypasses the hierarchical setup and messes up the
> > irq chaining.
> >
> > In preparation for removal of static setup of IRQ resource from DT core
> > code use platform_get_irq_optional().
> >
> > While at it return 0 instead of returning ret in the probe success path.
>
> ...
>
> > + ret = platform_get_irq_optional(pdev, 0);
> > + if (ret < 0 && ret != -ENXIO)
> > + return dev_err_probe(&pdev->dev, ret, "%s: failed to get IRQ resource\n", __func__);
>
> Sorry, I haven't noticed that you are using __func__ in the message.
> Please don't. It shows either that the message is not unique (so make
> the message unique enough in this driver) or the redundancy of the
> __func__ (it doesn't add any value, but noise).
>
Thanks for the pointer, I was just keeping the messages in-sync with the driver.
Cheers,
Prabhakar
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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.