[PATCH PING] drm/arc: disambiguate Synopsys ARC in Kconfig labels
There's Intel Arc now which is what most folks will be looking for. Signed-off-by: Adam Borowski Acked-by: Alexey Brodkin --- drivers/gpu/drm/tiny/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) v2: added Alexey's ACK. diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig index f6889f649bc1..efeead65030a 100644 --- a/drivers/gpu/drm/tiny/Kconfig +++ b/drivers/gpu/drm/tiny/Kconfig @@ -1,12 +1,12 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_ARCPGU - tristate "ARC PGU" + tristate "Synopsys ARC PGU" depends on DRM && OF select DRM_GEM_DMA_HELPER select DRM_KMS_HELPER help - Choose this option if you have an ARC PGU controller. + Choose this option if you have a Synopsys ARC PGU controller. If M is selected the module will be called arcpgu. -- 2.40.0
[PATCH] drm/arc: disambiguate Synopsys ARC in Kconfig labels
There's Intel Arc now which is what most folks will be looking for. Signed-off-by: Adam Borowski --- drivers/gpu/drm/tiny/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig index 565957264875..51b60c1a2bea 100644 --- a/drivers/gpu/drm/tiny/Kconfig +++ b/drivers/gpu/drm/tiny/Kconfig @@ -1,12 +1,12 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_ARCPGU - tristate "ARC PGU" + tristate "Synopsys ARC PGU" depends on DRM && OF select DRM_GEM_DMA_HELPER select DRM_KMS_HELPER help - Choose this option if you have an ARC PGU controller. + Choose this option if you have a Synopsys ARC PGU controller. If M is selected the module will be called arcpgu. -- 2.37.2.609.g9ff673ca1a
Re: [PATCH] tty: vt: selection: Add check for valid tiocl_selection values
On Thu, Aug 04, 2022 at 11:22:26AM +0200, Jiri Slaby wrote: > On 04. 08. 22, 10:44, Helge Deller wrote: > > On 8/4/22 09:15, Helge Deller wrote: > > > On 8/4/22 07:47, Jiri Slaby wrote: > > > > On 30. 07. 22, 20:49, Helge Deller wrote: > > > > > The line and column numbers for the selection need to start at 1. > > > > > Add the checks to prevent invalid input. > > > > > --- a/drivers/tty/vt/selection.c > > > > > +++ b/drivers/tty/vt/selection.c > > > > > @@ -326,6 +326,9 @@ static int vc_selection(struct vc_data *vc, > > > > > struct tiocl_selection *v, > > > > > + if (!v->xs || !v->ys || !v->xe || !v->ye) > > > > > + return -EINVAL; > > > > > > > > Hmm, I'm not sure about this. It potentially breaks userspace (by > > > > returning EINVAL now). > We can still do a trial and revert it if something breaks... It's just that > _noone_ knows with all this undocumented stuff ;). > > But in fact, 0 currently means full row/column. Isn't it on purpose? > > Today, we are out of luck, codesearch.debian.net gives no clue about users: > https://codesearch.debian.net/search?q=%5CbTIOCL_SETSEL%5Cb=0 That's because the macro is undocumented. "man ioctl_console" says: TIOCLINUX, subcode=2 Set selection. argp points to a [...] thus everyone writes it as a number. You'd need to grep for TIOCLINUX; there's not that many references to check... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Say what you want about Adolf, at least he was the man who ⢿⡄⠘⠷⠚⠋⠀ killed Hitler. Your turn, Vlad! ⠈⠳⣄
[PATCH] drm/rockchip: fix a -Werror fail on !CONFIG_PM_SLEEP
Signed-off-by: Adam Borowski
---
With Linus suddenly loving -Werror, let's get clean.
drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 8ab3247dbc4a..bee0f2d2a9be 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1123,6 +1123,7 @@ static int cdn_dp_suspend(struct device *dev)
return ret;
}
+#ifdef CONFIG_PM_SLEEP
static int cdn_dp_resume(struct device *dev)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
@@ -1135,6 +1136,7 @@ static int cdn_dp_resume(struct device *dev)
return 0;
}
+#endif
static int cdn_dp_probe(struct platform_device *pdev)
{
--
2.33.0
[PATCH] drm/fb-helper: disallow if DRM=y and FB=m
A subfeature of a built-in can't depend on a module. Signed-off-by: Adam Borowski --- drivers/gpu/drm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index cea777ae7fb9..75a5a9359d4b 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -103,7 +103,7 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS config DRM_FBDEV_EMULATION bool "Enable legacy fbdev support for your modesetting driver" depends on DRM - depends on FB + depends on FB >= DRM select DRM_KMS_HELPER select FB_CFB_FILLRECT select FB_CFB_COPYAREA -- 2.33.0
Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
On Mon, May 10, 2021 at 12:26:12PM +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
[...]
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
>
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset
I'm not aware of a distribution that still allows selecting a non-UTF-8
charset in a normal flow in their installer. And if they haven't purged
support for ancient encodings, that support is thoroughly bitrotten.
Thus, I disagree that this is a legitimate concern.
What _could_ be a legitimate reason is that someone is on a _terminal_
that can't display a wide enough set of glyphs. Such terminals are:
• Linux console (because of vgacon limitations; patchsets to improve
other cons haven't been mainlined)
• some Windows terminals (putty, old Windows console) that can't borrow
glyphs from other fonts like fontconfig can
For the former, it's whatever your distribution ships in
/usr/share/consolefonts/ or an equivalent, which is based on historic
ISO-8859 and VT100 traditions.
For the latter, the near-guaranteed character set is WGL4.
Thus, at least two of your choices seem to disagree with the above:
[dropped]
> 0xd7 => 'x', # MULTIPLICATION SIGN
[retained]
> - U+2b0d ('⬍'): UP DOWN BLACK ARROW
× is present in ISO-8859, V100, WGL4; I've found no font in
/usr/share/consolefonts/ on my Debian unstable box that lacks this
character.
⬍ is not found in any of the above. You might want to at least
convert it to ↕ which is at least present in WGL4, and thus likely
to be supported in fonts heeding Windows/Mac/OpenType recommendations.
That still won't make it work on VT.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `
Re: no mouse cursor on nv50
On Mon, Jun 18, 2018 at 06:18:34PM +1000, Ben Skeggs wrote: > On Mon, Jun 18, 2018 at 7:46 AM, Adam Borowski wrote: > > On v4.18-rc1, the mouse cursor is missing on my right monitor. > > Card is G98 [GeForce 8400 GS Rev. 2]. > > > > I have two monitors: one small landscape 1280x1024 on DVI-I-1 left, and one > > big 1600x1200 (1200x1600 portrait) on HDMI-1 right. Curiously, the cursor > > is missing not only with proper xrandr setup after logging in but even in > > mirrored mode at the lightdm greeter[1]. How is this even possible if both > > screens are supposed to be identical? > > > > # first bad commit: [5bca1621c07c3ad37b5a4943450a892e18984df0] > > drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows > > > > Alas, the bad commit can't be easily reverted as there's a lot of further > > work on the file on question. > > Thanks for the report! Can you give > https://github.com/skeggsb/linux/commit/fffdc521f313031b1745a264ec0d5c848c2475d1 > a try and see if it helps the issue you're seeing? Yay, it works! Both for mirrored and extended w/ different orientation. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
no mouse cursor on nv50
Hi! On v4.18-rc1, the mouse cursor is missing on my right monitor. Card is G98 [GeForce 8400 GS Rev. 2]. I have two monitors: one small landscape 1280x1024 on DVI-I-1 left, and one big 1600x1200 (1200x1600 portrait) on HDMI-1 right. Curiously, the cursor is missing not only with proper xrandr setup after logging in but even in mirrored mode at the lightdm greeter[1]. How is this even possible if both screens are supposed to be identical? Bisected: # bad: [ce397d215ccd07b8ae3f71db689aedb85d56ab40] Linux 4.18-rc1 # good: [29dcea88779c856c7dc92040a0c01233263101d4] Linux 4.17 git bisect start 'v4.18-rc1' 'v4.17' # bad: [1c8c5a9d38f607c0b6fd12c91cbe1a4418762a21] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect bad 1c8c5a9d38f607c0b6fd12c91cbe1a4418762a21 # bad: [135c5504a600ff9b06e321694fbcac78a9530cd4] Merge tag 'drm-next-2018-06-06-1' of git://anongit.freedesktop.org/drm/drm git bisect bad 135c5504a600ff9b06e321694fbcac78a9530cd4 # good: [5231804cf9e584f3e7e763a0d6d2fffe011c1bce] Merge tag 'leds_for_4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds git bisect good 5231804cf9e584f3e7e763a0d6d2fffe011c1bce # good: [315852b422972e6ebb1dfddaadada09e46a2681a] drm: rcar-du: Fix build failure git bisect good 315852b422972e6ebb1dfddaadada09e46a2681a # good: [ec064d3c6b40697fd72f4b1eeabbf293b7947a04] Merge tag 'driver-core-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core git bisect good ec064d3c6b40697fd72f4b1eeabbf293b7947a04 # bad: [ce234ccc03cfee004e168a1ae4b9d0cfb1974a32] Merge tag 'drm/tegra/for-4.18-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next git bisect bad ce234ccc03cfee004e168a1ae4b9d0cfb1974a32 # bad: [d7c6e97a32329032ba7af1f53cab2767832fed77] drm/nouveau/kms/nv50-: modify base allocation so the code can be split git bisect bad d7c6e97a32329032ba7af1f53cab2767832fed77 # good: [0a5b97304b9e2cd07c78a399c5395d5fb0118341] drm/nouveau/gr/gf100-: virtualise init_sked_hww_esr git bisect good 0a5b97304b9e2cd07c78a399c5395d5fb0118341 # good: [18d17221dd58741a8590ba0a40a9ded82aa5d619] drm/nouveau/gr/gf100-: virtualise r419e00 git bisect good 18d17221dd58741a8590ba0a40a9ded82aa5d619 # good: [e9d03335f604a1123b8de3103ce8e06db4ad777a] drm/nouveau/gr/gp100-: use correct registers for zbc colour/depth setup git bisect good e9d03335f604a1123b8de3103ce8e06db4ad777a # good: [512fa0b8a398539c3c2db251f6c40da4ef065d09] drm/nouveau/drm/nv50-: remove allocation of sw class git bisect good 512fa0b8a398539c3c2db251f6c40da4ef065d09 # good: [62b290fc7b36e8fec2a370b946d7117c1899b6c1] drm/nouveau/kms/nv50-: fix i2c-over-aux on anx9805 git bisect good 62b290fc7b36e8fec2a370b946d7117c1899b6c1 # bad: [a97c530eb968bad8d945d4f64fb550fa37a9d362] drm/nouveau/kms/nv50-: modify overlay allocation so the code can be split git bisect bad a97c530eb968bad8d945d4f64fb550fa37a9d362 # bad: [5bca1621c07c3ad37b5a4943450a892e18984df0] drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows git bisect bad 5bca1621c07c3ad37b5a4943450a892e18984df0 # first bad commit: [5bca1621c07c3ad37b5a4943450a892e18984df0] drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows Alas, the bad commit can't be easily reverted as there's a lot of further work on the file on question. Meow! [1]. It's possible to setup lightdm for proper layout even on the login screen, but that gives only aesthetic bonus while possibly causing problems when the layout changes. -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/nouveau: Move irq setup/teardown to pci ctor/dtor
On Thu, Jan 25, 2018 at 06:29:53PM -0500, Lyude Paul wrote: > This was made apparent by what appeared to be a regression in the > mainline kernel that started introducing suspend/resume issues for > nouveau: > > a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation) I'm just a dumb user here, but I confirm: CPU: AMD Phenom II X6 1055T, GPU: GTX 560 Ti 100% fail to resume GPU on 4.15-rc*, 100% ok with your patch. And that spinning rust hates being repeatedly powered off and on... :/ > --- > Changes since v2: > - Remove teardown, just reuse pci->irq to indicate when we're tearing >down the driver > > drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 44 > +- > 1 file changed, 29 insertions(+), 15 deletions(-) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious... ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API
On Fri, Dec 08, 2017 at 06:30:34PM +, Ard Biesheuvel wrote:
> Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly
> into nv04_instobj") introduced some new calls to the refcount api to
> the nv50 mapping code. In one particular instance, it does the
> following:
>
> if (!refcount_inc_not_zero(>maps)) {
> ...
> refcount_inc(>maps);
> }
>
> i.e., it calls refcount_inc() to increment the refcount when it is known
> to be zero, which is explicitly forbidden by the API. Instead, use
> refcount_set() to set it to 1.
>
> Signed-off-by: Ard Biesheuvel
> ---
Awesome! Works for me.
> Apologies if this was already found and fixed. I don't usually follow
> the DRM or nouveau mailing lists.
I see nothing relevant in dri-devel and nouveau archives, except my
complaint (GTX 560 Ti (GF114)):
https://lists.freedesktop.org/archives/nouveau/2017-December/029264.html
and Richard Narron seconding it (MSI GeForce 210):
https://lists.freedesktop.org/archives/nouveau/2017-December/029276.html
> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> index 1ba7289684aa..db48a1daca0c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> @@ -249,7 +249,7 @@ nv50_instobj_acquire(struct nvkm_memory *memory)
> iobj->base.memory.ptrs = _instobj_fast;
> else
> iobj->base.memory.ptrs = _instobj_slow;
> - refcount_inc(>maps);
> + refcount_set(>maps, 1);
> }
>
> mutex_unlock(>subdev.mutex);
> --
I'm just a dumb user here, my tags don't carry a weight, but Tested-by:.
Meow!
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau: refcount_t splat on 4.15-rc1 on nv50
Hi guys! I'm getting the following warn on 4.15-rc1, on GTX 560 Ti: [9.430433] nouveau :01:00.0: NVIDIA GF114 (0ce000a1) ... [9.585172] nouveau :01:00.0: bios: version 70.24.2e.00.02 ... [9.772204] nouveau :01:00.0: fb: 1024 MiB GDDR5 [9.777342] [ cut here ] [9.782106] refcount_t: increment on 0; use-after-free. [9.787522] WARNING: CPU: 0 PID: 3 at lib/refcount.c:153 refcount_inc+0x30/0x50 [9.795060] Modules linked in: sha256_generic cfg80211(+) rfkill snd_usb_audio snd_usbmidi_lib nouveau(+) video ttm [9.805756] CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.15.0-rc1-debug-ubsan-00020-gf4707a916107 #1 [9.815215] Hardware name: System manufacturer System Product Name/M4A77T, BIOS 240105/18/2011 [9.824420] Workqueue: events work_for_cpu_fn [9.828915] task: 880226110c80 task.stack: c9c8 [9.830647] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [9.841681] RIP: 0010:refcount_inc+0x30/0x50 [9.846093] RSP: 0018:c9c83808 EFLAGS: 00010296 [9.851458] RAX: 002b RBX: RCX: [9.858763] RDX: 0001 RSI: 0082 RDI: 8378eb8c [9.866051] RBP: 88021f103fd0 R08: 0199 R09: 880bd500 [9.873330] R10: R11: 82289a80 R12: [9.880621] R13: 8802103a69e0 R14: 88021f103fe0 R15: 88021f103fe0 [9.887909] FS: () GS:88022fc0() knlGS: [9.896230] CS: 0010 DS: ES: CR0: 80050033 [9.902117] CR2: 560476ba CR3: 000225232000 CR4: 06f0 [9.909417] Call Trace: [9.912106] nv50_instobj_acquire+0x123/0x1c0 [nouveau] [9.917565] ? nvbios_rd08+0x1b/0x70 [nouveau] [9.922239] nvkm_instobj_new+0x1e3/0x520 [nouveau] [9.927353] ? nvbios_rd08+0x1b/0x70 [nouveau] [9.932017] ? nvbios_pll_parse+0x8d7/0xcf0 [nouveau] [9.937218] ? kmem_cache_alloc+0x1f0/0x2d0 [9.941624] nvkm_memory_new+0x4b/0xc0 [nouveau] [9.946461] ? nvkm_longopt+0x17/0x60 [nouveau] [9.951208] gf100_fb_oneinit+0x7b/0x1c0 [nouveau] [9.956218] nvkm_fb_oneinit+0x89/0x2e0 [nouveau] [9.961144] nvkm_subdev_init+0x92/0x600 [nouveau] [9.966085] ? ktime_get+0x64/0x110 [9.969815] nvkm_device_init+0x169/0x2a0 [nouveau] [9.974922] nvkm_udevice_init+0x7e/0xf0 [nouveau] [9.979924] nvkm_object_init+0x6a/0x2e0 [nouveau] [9.984932] nvkm_ioctl_new+0x198/0x430 [nouveau] [9.989846] ? nvif_vmm_init+0x340/0x340 [nouveau] [9.994864] ? nvkm_udevice_rd08+0x90/0x90 [nouveau] [ 10.56] nvkm_ioctl+0x21e/0x5a0 [nouveau] [ 10.004548] ? yield_to+0x2b2/0x370 [ 10.008257] nvif_object_init+0xef/0x1b0 [nouveau] [ 10.013281] nvif_device_init+0x9/0x40 [nouveau] [ 10.018136] nouveau_cli_init+0x234/0x12f0 [nouveau] [ 10.023253] ? idr_alloc_cyclic+0x6c/0x110 [ 10.027487] ? _cond_resched+0x1d/0x80 [ 10.031366] ? kmem_cache_alloc+0x1f0/0x2d0 [ 10.035790] nouveau_drm_load+0x71/0xec0 [nouveau] [ 10.040735] drm_dev_register+0x1b4/0x330 [ 10.044872] ? pci_enable_device_flags+0x155/0x200 [ 10.049806] drm_get_pci_dev+0xde/0x2c0 [ 10.053874] nouveau_drm_probe+0x1b9/0x240 [nouveau] [ 10.058986] ? __pm_runtime_resume+0x68/0xb0 [ 10.063409] local_pci_probe+0x5e/0xf0 [ 10.067300] work_for_cpu_fn+0x10/0x30 [ 10.071183] process_one_work+0x21a/0x670 [ 10.075325] worker_thread+0x256/0x500 [ 10.079208] ? manage_workers+0x1e0/0x1e0 [ 10.083362] kthread+0x169/0x220 [ 10.086730] ? kthread_create_worker_on_cpu+0x40/0x40 [ 10.091933] ret_from_fork+0x1f/0x30 [ 10.095655] Code: ff 84 c0 74 02 5b c3 0f b6 1d 59 b2 a6 01 80 fb 01 77 1c 83 e3 01 75 ed 48 c7 c7 c8 f1 3f 82 c6 05 41 b2 a6 01 01 e8 50 02 8d ff <0f> ff 5b c3 0f b6 f3 48 c7 c7 00 16 c7 82 e8 dd 81 0d 00 eb d3 [ 10.114909] ---[ end trace 08f29138ff4259e6 ]--- [ 10.119703] hpet1: lost 21 rtc interrupts [ 10.125534] [ cut here ] [ 10.130326] refcount_t: underflow; use-after-free. [ 10.135292] WARNING: CPU: 0 PID: 3 at lib/refcount.c:281 refcount_dec_not_one+0x68/0x90 [ 10.143540] Modules linked in: sha256_generic cfg80211 rfkill snd_usb_audio snd_usbmidi_lib nouveau(+) video ttm [ 10.153956] CPU: 0 PID: 3 Comm: kworker/0:0 Tainted: GW 4.15.0-rc1-debug-ubsan-00020-gf4707a916107 #1 [ 10.164719] Hardware name: System manufacturer System Product Name/M4A77T, BIOS 240105/18/2011 [ 10.173929] Workqueue: events work_for_cpu_fn [ 10.178423] task: 880226110c80 task.stack: c9c8 [ 10.184488] RIP: 0010:refcount_dec_not_one+0x68/0x90 [ 10.189580] RSP: 0018:c9c837f0 EFLAGS: 00010286 [ 10.194946] RAX: 0026 RBX: RCX: [ 10.202232] RDX: 0001 RSI: 0092 RDI: 8378eb8c [ 10.209512]
Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback
On Tue, Aug 29, 2017 at 08:56:15PM -0400, Jerome Glisse wrote: > I will wait for people to test and for result of my own test before > reposting if need be, otherwise i will post as separate patch. > > > But from a _very_ quick read-through this looks fine. But it obviously > > needs testing. > > > > People - *especially* the people who saw issues under KVM - can you > > try out Jérôme's patch-series? I aded some people to the cc, the full > > series is on lkml. Jérôme - do you have a git branch for people to > > test that they could easily pull and try out? > > https://cgit.freedesktop.org/~glisse/linux mmu-notifier branch > git://people.freedesktop.org/~glisse/linux Tested your branch as of 10f07641, on a long list of guest VMs. No earth-shattering kaboom. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: enable interrupts on cards with 32 intr lines
The code attempts to enable them, but hits an undefined behaviour by
shifting by the entire register's width:
int lines = 32;
u32 mask = (1 << lines) - 1;// on x86
u32 mask = (1 << lines) - 1;// on arm (32)
u32 mask = (1 << lines) - 1;// on arm64
u32 mask = (1ULL << lines) - 1; // everywhere
Signed-off-by: Adam Borowski <kilob...@angband.pl>
---
To be honest, I can't tell the difference other than UBSAN stopping its
complaints, but the current code is obviously wrong.
drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c
index 77c649723ad7..4a57defc99b3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c
@@ -164,7 +164,7 @@ static int
nvkm_gpio_fini(struct nvkm_subdev *subdev, bool suspend)
{
struct nvkm_gpio *gpio = nvkm_gpio(subdev);
- u32 mask = (1 << gpio->func->lines) - 1;
+ u32 mask = (1ULL << gpio->func->lines) - 1;
gpio->func->intr_mask(gpio, NVKM_GPIO_TOGGLED, mask, 0);
gpio->func->intr_stat(gpio, , );
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
