* Re: [PATCH] fbdev: mb862xxfbdrv: Make CONFIG_FB_DEVICE optional
From: Uwe Kleine-König @ 2025-10-06 8:07 UTC (permalink / raw)
To: Javier Garcia
Cc: deller, tzimmermann, linux-fbdev, dri-devel, linux-kernel, shuah
In-Reply-To: <20251005173812.1169436-1-rampxxxx@gmail.com>
Hello,
On Sun, Oct 05, 2025 at 07:38:12PM +0200, Javier Garcia wrote:
> This patch wraps the relevant code blocks with #ifdef CONFIG_FB_DEVICE,
> allowing the driver to be built and used even if CONFIG_FB_DEVICE is not selected.
>
> The sysfs only give access to show some controller and cursor registers so
> it's not needed to allow driver works correctly.
>
> Signed-off-by: Javier Garcia <rampxxxx@gmail.com>
I don't understand this patch. CONFIG_FB_DEVICE is about legacy /dev/fb*
stuff, and this patch make the creation of a sysfs file dependent on
that.
> diff --git a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
> index ade88e7bc760..a691a5fefb25 100644
> --- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
> +++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
> @@ -530,6 +530,7 @@ static int mb862xxfb_init_fbinfo(struct fb_info *fbi)
> return 0;
> }
>
> +#ifdef CONFIG_FB_DEVICE
> /*
> * show some display controller and cursor registers
> */
> @@ -569,6 +570,7 @@ static ssize_t dispregs_show(struct device *dev,
> }
>
> static DEVICE_ATTR_RO(dispregs);
> +#endif
>
> static irqreturn_t mb862xx_intr(int irq, void *dev_id)
> {
> @@ -759,9 +761,11 @@ static int of_platform_mb862xx_probe(struct platform_device *ofdev)
>
> dev_set_drvdata(dev, info);
>
> +#ifdef CONFIG_FB_DEVICE
> if (device_create_file(dev, &dev_attr_dispregs))
> dev_err(dev, "Can't create sysfs regdump file\n");
> return 0;
> +#endif
That looks wrong. Without CONFIG_FB_DEVICE set the success return is
removed and all resources are freed essentially making the
CONFIG_FB_MB862XX_LIME part of the driver unusable.
> rel_cmap:
> fb_dealloc_cmap(&info->cmap);
> @@ -801,7 +805,9 @@ static void of_platform_mb862xx_remove(struct platform_device *ofdev)
> free_irq(par->irq, (void *)par);
> irq_dispose_mapping(par->irq);
>
> +#ifdef CONFIG_FB_DEVICE
> device_remove_file(&ofdev->dev, &dev_attr_dispregs);
> +#endif
>
> unregister_framebuffer(fbi);
> fb_dealloc_cmap(&fbi->cmap);
> @@ -1101,8 +1107,10 @@ static int mb862xx_pci_probe(struct pci_dev *pdev,
>
> pci_set_drvdata(pdev, info);
>
> +#ifdef CONFIG_FB_DEVICE
> if (device_create_file(dev, &dev_attr_dispregs))
> dev_err(dev, "Can't create sysfs regdump file\n");
> +#endif
>
> if (par->type == BT_CARMINE)
> outreg(ctrl, GC_CTRL_INT_MASK, GC_CARMINE_INT_EN);
> @@ -1151,7 +1159,9 @@ static void mb862xx_pci_remove(struct pci_dev *pdev)
>
> mb862xx_i2c_exit(par);
>
> +#ifdef CONFIG_FB_DEVICE
> device_remove_file(&pdev->dev, &dev_attr_dispregs);
> +#endif
>
> unregister_framebuffer(fbi);
> fb_dealloc_cmap(&fbi->cmap);
The amount of ifdefs could be greatly reduced using the following patch:
diff --git a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
index a691a5fefb25..3f79dfc27a53 100644
--- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
@@ -530,7 +530,6 @@ static int mb862xxfb_init_fbinfo(struct fb_info *fbi)
return 0;
}
-#ifdef CONFIG_FB_DEVICE
/*
* show some display controller and cursor registers
*/
@@ -570,7 +569,6 @@ static ssize_t dispregs_show(struct device *dev,
}
static DEVICE_ATTR_RO(dispregs);
-#endif
static irqreturn_t mb862xx_intr(int irq, void *dev_id)
{
@@ -761,11 +759,9 @@ static int of_platform_mb862xx_probe(struct platform_device *ofdev)
dev_set_drvdata(dev, info);
-#ifdef CONFIG_FB_DEVICE
- if (device_create_file(dev, &dev_attr_dispregs))
+ if (IS_ENABLED(CONFIG_FB_DEVICE) && device_create_file(dev, &dev_attr_dispregs))
dev_err(dev, "Can't create sysfs regdump file\n");
return 0;
-#endif
rel_cmap:
fb_dealloc_cmap(&info->cmap);
@@ -805,9 +801,8 @@ static void of_platform_mb862xx_remove(struct platform_device *ofdev)
free_irq(par->irq, (void *)par);
irq_dispose_mapping(par->irq);
-#ifdef CONFIG_FB_DEVICE
- device_remove_file(&ofdev->dev, &dev_attr_dispregs);
-#endif
+ if (IS_ENABLED(CONFIG_FB_DEVICE))
+ device_remove_file(&ofdev->dev, &dev_attr_dispregs);
unregister_framebuffer(fbi);
fb_dealloc_cmap(&fbi->cmap);
@@ -1107,10 +1102,8 @@ static int mb862xx_pci_probe(struct pci_dev *pdev,
pci_set_drvdata(pdev, info);
-#ifdef CONFIG_FB_DEVICE
- if (device_create_file(dev, &dev_attr_dispregs))
+ if (IS_ENABLED(CONFIG_FB_DEVICE) && device_create_file(dev, &dev_attr_dispregs))
dev_err(dev, "Can't create sysfs regdump file\n");
-#endif
if (par->type == BT_CARMINE)
outreg(ctrl, GC_CTRL_INT_MASK, GC_CARMINE_INT_EN);
@@ -1159,9 +1152,8 @@ static void mb862xx_pci_remove(struct pci_dev *pdev)
mb862xx_i2c_exit(par);
-#ifdef CONFIG_FB_DEVICE
- device_remove_file(&pdev->dev, &dev_attr_dispregs);
-#endif
+ if (IS_ENABLED(CONFIG_FB_DEVICE))
+ device_remove_file(&pdev->dev, &dev_attr_dispregs);
unregister_framebuffer(fbi);
fb_dealloc_cmap(&fbi->cmap);
(It would still be questionable however to make the device file creation
dependent on FB_DEVICE.)
Best regards
Uwe
^ permalink raw reply related
* Re: [PATCH] fbdev: mb862xxfbdrv: Make CONFIG_FB_DEVICE optional
From: Helge Deller @ 2025-10-05 19:51 UTC (permalink / raw)
To: Javier Garcia, u.kleine-koenig, tzimmermann
Cc: linux-fbdev, dri-devel, linux-kernel, shuah
In-Reply-To: <20251005173812.1169436-1-rampxxxx@gmail.com>
On 10/5/25 19:38, Javier Garcia wrote:
> This patch wraps the relevant code blocks with #ifdef CONFIG_FB_DEVICE,
> allowing the driver to be built and used even if CONFIG_FB_DEVICE is not selected.
>
> The sysfs only give access to show some controller and cursor registers so
> it's not needed to allow driver works correctly.
>
> Signed-off-by: Javier Garcia <rampxxxx@gmail.com>
> ---
> drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
applied.
Thanks!
Helge
^ permalink raw reply
* [PATCH] fbdev: mb862xxfbdrv: Make CONFIG_FB_DEVICE optional
From: Javier Garcia @ 2025-10-05 17:38 UTC (permalink / raw)
To: deller, u.kleine-koenig, tzimmermann
Cc: linux-fbdev, dri-devel, linux-kernel, shuah, Javier Garcia
This patch wraps the relevant code blocks with #ifdef CONFIG_FB_DEVICE,
allowing the driver to be built and used even if CONFIG_FB_DEVICE is not selected.
The sysfs only give access to show some controller and cursor registers so
it's not needed to allow driver works correctly.
Signed-off-by: Javier Garcia <rampxxxx@gmail.com>
---
drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
index ade88e7bc760..a691a5fefb25 100644
--- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
@@ -530,6 +530,7 @@ static int mb862xxfb_init_fbinfo(struct fb_info *fbi)
return 0;
}
+#ifdef CONFIG_FB_DEVICE
/*
* show some display controller and cursor registers
*/
@@ -569,6 +570,7 @@ static ssize_t dispregs_show(struct device *dev,
}
static DEVICE_ATTR_RO(dispregs);
+#endif
static irqreturn_t mb862xx_intr(int irq, void *dev_id)
{
@@ -759,9 +761,11 @@ static int of_platform_mb862xx_probe(struct platform_device *ofdev)
dev_set_drvdata(dev, info);
+#ifdef CONFIG_FB_DEVICE
if (device_create_file(dev, &dev_attr_dispregs))
dev_err(dev, "Can't create sysfs regdump file\n");
return 0;
+#endif
rel_cmap:
fb_dealloc_cmap(&info->cmap);
@@ -801,7 +805,9 @@ static void of_platform_mb862xx_remove(struct platform_device *ofdev)
free_irq(par->irq, (void *)par);
irq_dispose_mapping(par->irq);
+#ifdef CONFIG_FB_DEVICE
device_remove_file(&ofdev->dev, &dev_attr_dispregs);
+#endif
unregister_framebuffer(fbi);
fb_dealloc_cmap(&fbi->cmap);
@@ -1101,8 +1107,10 @@ static int mb862xx_pci_probe(struct pci_dev *pdev,
pci_set_drvdata(pdev, info);
+#ifdef CONFIG_FB_DEVICE
if (device_create_file(dev, &dev_attr_dispregs))
dev_err(dev, "Can't create sysfs regdump file\n");
+#endif
if (par->type == BT_CARMINE)
outreg(ctrl, GC_CTRL_INT_MASK, GC_CARMINE_INT_EN);
@@ -1151,7 +1159,9 @@ static void mb862xx_pci_remove(struct pci_dev *pdev)
mb862xx_i2c_exit(par);
+#ifdef CONFIG_FB_DEVICE
device_remove_file(&pdev->dev, &dev_attr_dispregs);
+#endif
unregister_framebuffer(fbi);
fb_dealloc_cmap(&fbi->cmap);
--
2.50.1
^ permalink raw reply related
* [PATCH RESEND] staging: sm750fb: rename camel case identifiers
From: Ahmet Sezgin Duran @ 2025-10-04 20:48 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Ahmet Sezgin Duran
Rename two identifiers from camel case to snake case, in order to follow
kernel coding style.
Changes:
- Local variable `deCtrl` to `de_ctrl`
- Function `deGetTransparency` to `de_get_transparency`
Signed-off-by: Ahmet Sezgin Duran <ahmet@sezginduran.net>
---
drivers/staging/sm750fb/sm750_accel.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index b07c1aa68621..046b9282b24a 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -89,7 +89,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop)
{
- u32 deCtrl;
+ u32 de_ctrl;
if (accel->de_wait() != 0) {
/*
@@ -121,11 +121,11 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
((width << DE_DIMENSION_X_SHIFT) & DE_DIMENSION_X_MASK) |
(height & DE_DIMENSION_Y_ET_MASK)); /* dpr8 */
- deCtrl = DE_CONTROL_STATUS | DE_CONTROL_LAST_PIXEL |
+ de_ctrl = DE_CONTROL_STATUS | DE_CONTROL_LAST_PIXEL |
DE_CONTROL_COMMAND_RECTANGLE_FILL | DE_CONTROL_ROP_SELECT |
(rop & DE_CONTROL_ROP_MASK); /* dpr0xc */
- write_dpr(accel, DE_CONTROL, deCtrl);
+ write_dpr(accel, DE_CONTROL, de_ctrl);
return 0;
}
@@ -284,7 +284,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
return 0;
}
-static unsigned int deGetTransparency(struct lynx_accel *accel)
+static unsigned int de_get_transparency(struct lynx_accel *accel)
{
unsigned int de_ctrl;
@@ -391,7 +391,7 @@ int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
DE_CONTROL_ROP_SELECT | DE_CONTROL_COMMAND_HOST_WRITE |
DE_CONTROL_HOST | DE_CONTROL_STATUS;
- write_dpr(accel, DE_CONTROL, de_ctrl | deGetTransparency(accel));
+ write_dpr(accel, DE_CONTROL, de_ctrl | de_get_transparency(accel));
/* Write MONO data (line by line) to 2D Engine data port */
for (i = 0; i < height; i++) {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2] fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
From: Helge Deller @ 2025-10-04 0:43 UTC (permalink / raw)
To: Albin Babu Varghese, Simona Vetter
Cc: syzbot+48b0652a95834717f190, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20251003073210.48501-1-albinbabuvarghese20@gmail.com>
On 10/3/25 09:32, Albin Babu Varghese wrote:
> Add bounds checking to prevent writes past framebuffer boundaries when
> rendering text near screen edges. Return early if the Y position is off-screen
> and clip image height to screen boundary. Break from the rendering loop if the
> X position is off-screen. When clipping image width to fit the screen, update
> the character count to match the clipped width to prevent buffer size
> mismatches.
>
> Without the character count update, bit_putcs_aligned and bit_putcs_unaligned
> receive mismatched parameters where the buffer is allocated for the clipped
> width but cnt reflects the original larger count, causing out-of-bounds writes.
>
> Reported-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190
> Suggested-by: Helge Deller <deller@gmx.de>
> Tested-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com
> Signed-off-by: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
> ---
> Changes in v2:
> - Partially render when height exceeding screen boundaries instead of skipping
> - Update character count when width is clipped to prevent buffer mismatch
>
> Link to v1:
> https://lore.kernel.org/all/20250927075010.119671-1-albinbabuvarghese20@gmail.com/
> ---
> drivers/video/fbdev/core/bitblit.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] fbdev: udlfb: make CONFIG_FB_DEVICE optional
From: Helge Deller @ 2025-10-03 19:50 UTC (permalink / raw)
To: sukrut heroorkar, Thomas Zimmermann, Mikulas Patocka
Cc: David Hunter, kernel test robot, Bernie Thompson, Arnd Bergmann,
Randy Dunlap, Bartosz Golaszewski, Zsolt Kajtar,
Gonzalo Silvalde Blanco, linux-fbdev, dri-devel, linux-kernel,
llvm, oe-kbuild-all, skhan
In-Reply-To: <CAHCkknrAKGxzAYE-R3QX20W4faR9Wfjgn37peyHRJcZ6PRLENA@mail.gmail.com>
On 10/3/25 20:43, sukrut heroorkar wrote:
> On Thu, Oct 2, 2025 at 8:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Am 02.10.25 um 08:41 schrieb Helge Deller:
>>>>>> kernel test robot noticed the following build errors:
>>>>>
>>>>> Did you compile and test this code before submitting this patch?
>>>>
>>>> Yes, I had compiled & loaded the udlfb module with no errors. Please
>>>> let me know how to proceed in this case.
>>>
>>> Look at the reported build error, which seems to happen in dev_dbg().
>>> So, maybe in your testing you did not have debugging enabled?
>>> The report contains the .config file with which you can test.
>>
>> Can we rather make an effort to remove the udlfb driver entirely? A few
>> years back, there was one user who was still using it because of some
>> problems with the DRM udl driver. But I think we've addressed them. The
>> discussion is at [1].
Would be good to know if they issues/crashes really have been solved.
In [1] it seems the crashes still happened with DRM.
> Should I send a patch series to completely remove udlfb,
No. (at least not yet)
> since [1] echoed that DRM udl driver is good enough?
>> [1] https://lore.kernel.org/dri-devel/20201130125200.10416-1-tzimmermann@suse.de/
Well, some people who do *NOT* actively use fbdev with the old
cards say the DRM replacements are "good enough".
For tThose people who really depend on fbdev and the speed it has
over DRM, the DRM "basic-drivers" are simply a nice-to-have-but-not-really-useable
type of drivers.
So, unless the really affected people say the DRM replacement
is fully usable, we need to keep the fbdev driver.
Helge
^ permalink raw reply
* Re: [PATCH] fbdev: udlfb: make CONFIG_FB_DEVICE optional
From: sukrut heroorkar @ 2025-10-03 18:43 UTC (permalink / raw)
To: Thomas Zimmermann, Helge Deller
Cc: David Hunter, kernel test robot, Bernie Thompson, Arnd Bergmann,
Randy Dunlap, Bartosz Golaszewski, Zsolt Kajtar,
Gonzalo Silvalde Blanco, linux-fbdev, dri-devel, linux-kernel,
llvm, oe-kbuild-all, skhan
In-Reply-To: <41ef536d-2399-43f8-8041-c6b0e642aba2@suse.de>
Hi
On Thu, Oct 2, 2025 at 8:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 02.10.25 um 08:41 schrieb Helge Deller:
> >>>> kernel test robot noticed the following build errors:
> >>>
> >>> Did you compile and test this code before submitting this patch?
> >>
> >> Yes, I had compiled & loaded the udlfb module with no errors. Please
> >> let me know how to proceed in this case.
> >
> > Look at the reported build error, which seems to happen in dev_dbg().
> > So, maybe in your testing you did not have debugging enabled?
> > The report contains the .config file with which you can test.
>
> Can we rather make an effort to remove the udlfb driver entirely? A few
> years back, there was one user who was still using it because of some
> problems with the DRM udl driver. But I think we've addressed them. The
> discussion is at [1].
Should I send a patch series to completely remove udlfb, since [1] echoed that
DRM udl driver is good enough?
>
> [1]
> https://lore.kernel.org/dri-devel/20201130125200.10416-1-tzimmermann@suse.de/
>
> Best regards
> Thomas
>
> >
> > Helge
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
>
>
^ permalink raw reply
* [PATCH v2] fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
From: Albin Babu Varghese @ 2025-10-03 7:32 UTC (permalink / raw)
To: Simona Vetter, Helge Deller
Cc: Albin Babu Varghese, syzbot+48b0652a95834717f190, linux-fbdev,
dri-devel, linux-kernel
Add bounds checking to prevent writes past framebuffer boundaries when
rendering text near screen edges. Return early if the Y position is off-screen
and clip image height to screen boundary. Break from the rendering loop if the
X position is off-screen. When clipping image width to fit the screen, update
the character count to match the clipped width to prevent buffer size
mismatches.
Without the character count update, bit_putcs_aligned and bit_putcs_unaligned
receive mismatched parameters where the buffer is allocated for the clipped
width but cnt reflects the original larger count, causing out-of-bounds writes.
Reported-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190
Suggested-by: Helge Deller <deller@gmx.de>
Tested-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com
Signed-off-by: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
---
Changes in v2:
- Partially render when height exceeding screen boundaries instead of skipping
- Update character count when width is clipped to prevent buffer mismatch
Link to v1:
https://lore.kernel.org/all/20250927075010.119671-1-albinbabuvarghese20@gmail.com/
---
drivers/video/fbdev/core/bitblit.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c
index f9475c14f733..116b4bf5e94c 100644
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -160,6 +160,11 @@ static void bit_putcs(struct vc_data *vc, struct fb_info *info,
image.height = vc->vc_font.height;
image.depth = 1;
+ if (image.dy >= info->var.yres)
+ return;
+
+ image.height = min(image.height, info->var.yres - image.dy);
+
if (attribute) {
buf = kmalloc(cellsize, GFP_ATOMIC);
if (!buf)
@@ -173,6 +178,21 @@ static void bit_putcs(struct vc_data *vc, struct fb_info *info,
cnt = count;
image.width = vc->vc_font.width * cnt;
+
+ if (image.dx >= info->var.xres)
+ break;
+
+ if (image.dx + image.width > info->var.xres) {
+ image.width = info->var.xres - image.dx;
+
+ cnt = image.width / vc->vc_font.width;
+
+ if (cnt == 0)
+ break;
+
+ image.width = cnt * vc->vc_font.width;
+ }
+
pitch = DIV_ROUND_UP(image.width, 8) + scan_align;
pitch &= ~scan_align;
size = pitch * image.height + buf_align;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
From: Helge Deller @ 2025-10-02 10:11 UTC (permalink / raw)
To: Albin Babu Varghese
Cc: Simona Vetter, syzbot+48b0652a95834717f190, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <aN49Qt4dezOqAmoo@arch-box>
On 10/2/25 10:52, Albin Babu Varghese wrote:
> Hi Helge, I tested your suggestions and they seem to work well.
>
>> Do you know if this affects the selection?
>> If so, would modifying (reducing/shortening) the selection maybe fix it?
>
> The syzkaller reproducer uses really weird values where xs > xe and ys > ye
> (xs=0xa00, xe=0x101, ys=0xc7e, ye=0x100) and set_selection() already swaps them
> if needed and clamps the values.
Ok.
> I added debug prints to check what's happening and the clamping in
> set_selection() is working and the values coming through are within bounds. But
> the crash still happens when you remap the framebuffer because of a slight
> overflow.
>
> I also discovered that when image.width is clipped on the X-axis, the character
> count (cnt) must also be updated to match, otherwise bit_putcs_aligned()
> receives mismatched buffer size and character count parameters, causing
> out-of-bounds writes.
>
> So I changed it to something like this:
>
> + if (image.dx >= info->var.xres)
> + break;
> + if (image.dx + image.width > info->var.xres) {
> + image.width = info->var.xres - image.dx;
> + cnt = image.width / vc->vc_font.width;
> + if (cnt == 0)
> + break;
> + image.width = cnt * vc->vc_font.width;
> + }
Looks good.
> I tested it in syzbot, with the syzkaller reproducer, and also manually in QEMU
> and verified that the buffer switches from tty1 to tty2 work correctly.
>
> I couldn’t find a dedicated fbdev/fbcon test suite. Beyond kselftests, do you
> recommend anything specific before sending v2?
There is Geert's fbdev test tool (https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git/),
but it does not involve testing of fbcon.
Helge
^ permalink raw reply
* Re: [PATCH] fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
From: Albin Babu Varghese @ 2025-10-02 8:52 UTC (permalink / raw)
To: Helge Deller
Cc: Simona Vetter, syzbot+48b0652a95834717f190, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <5ab00319-e43e-4000-8814-c7d67f384c53@gmx.de>
Hi Helge, I tested your suggestions and they seem to work well.
> Do you know if this affects the selection?
> If so, would modifying (reducing/shortening) the selection maybe fix it?
The syzkaller reproducer uses really weird values where xs > xe and ys > ye
(xs=0xa00, xe=0x101, ys=0xc7e, ye=0x100) and set_selection() already swaps them
if needed and clamps the values.
I added debug prints to check what's happening and the clamping in
set_selection() is working and the values coming through are within bounds. But
the crash still happens when you remap the framebuffer because of a slight
overflow.
I also discovered that when image.width is clipped on the X-axis, the character
count (cnt) must also be updated to match, otherwise bit_putcs_aligned()
receives mismatched buffer size and character count parameters, causing
out-of-bounds writes.
So I changed it to something like this:
+ if (image.dx >= info->var.xres)
+ break;
+ if (image.dx + image.width > info->var.xres) {
+ image.width = info->var.xres - image.dx;
+ cnt = image.width / vc->vc_font.width;
+ if (cnt == 0)
+ break;
+ image.width = cnt * vc->vc_font.width;
+ }
I tested it in syzbot, with the syzkaller reproducer, and also manually in QEMU
and verified that the buffer switches from tty1 to tty2 work correctly.
I couldn’t find a dedicated fbdev/fbcon test suite. Beyond kselftests, do you
recommend anything specific before sending v2?
Thanks,
Albin
^ permalink raw reply
* Re: [PATCH] fbdev: udlfb: make CONFIG_FB_DEVICE optional
From: Thomas Zimmermann @ 2025-10-02 6:52 UTC (permalink / raw)
To: Helge Deller, sukrut heroorkar, David Hunter
Cc: kernel test robot, Bernie Thompson, Arnd Bergmann, Randy Dunlap,
Bartosz Golaszewski, Zsolt Kajtar, Gonzalo Silvalde Blanco,
linux-fbdev, dri-devel, linux-kernel, llvm, oe-kbuild-all, skhan
In-Reply-To: <edccab86-321b-4e6e-998f-3ce320ee0193@gmx.de>
Hi
Am 02.10.25 um 08:41 schrieb Helge Deller:
>>>> kernel test robot noticed the following build errors:
>>>
>>> Did you compile and test this code before submitting this patch?
>>
>> Yes, I had compiled & loaded the udlfb module with no errors. Please
>> let me know how to proceed in this case.
>
> Look at the reported build error, which seems to happen in dev_dbg().
> So, maybe in your testing you did not have debugging enabled?
> The report contains the .config file with which you can test.
Can we rather make an effort to remove the udlfb driver entirely? A few
years back, there was one user who was still using it because of some
problems with the DRM udl driver. But I think we've addressed them. The
discussion is at [1].
[1]
https://lore.kernel.org/dri-devel/20201130125200.10416-1-tzimmermann@suse.de/
Best regards
Thomas
>
> Helge
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
^ permalink raw reply
* Re: [PATCH] fbdev: udlfb: make CONFIG_FB_DEVICE optional
From: Helge Deller @ 2025-10-02 6:41 UTC (permalink / raw)
To: sukrut heroorkar, David Hunter
Cc: kernel test robot, Bernie Thompson, Thomas Zimmermann,
Arnd Bergmann, Randy Dunlap, Bartosz Golaszewski, Zsolt Kajtar,
Gonzalo Silvalde Blanco, linux-fbdev, dri-devel, linux-kernel,
llvm, oe-kbuild-all, skhan
In-Reply-To: <CAHCkknrZ-ieNKeg-aj3-NVqgGSk770jJpUpCvn_SuffkPu+ZrQ@mail.gmail.com>
>>> kernel test robot noticed the following build errors:
>>
>> Did you compile and test this code before submitting this patch?
>
> Yes, I had compiled & loaded the udlfb module with no errors. Please
> let me know how to proceed in this case.
Look at the reported build error, which seems to happen in dev_dbg().
So, maybe in your testing you did not have debugging enabled?
The report contains the .config file with which you can test.
Helge
^ permalink raw reply
* Re: [PATCH] fbdev: udlfb: make CONFIG_FB_DEVICE optional
From: sukrut heroorkar @ 2025-10-02 6:35 UTC (permalink / raw)
To: David Hunter
Cc: kernel test robot, Helge Deller, Bernie Thompson,
Thomas Zimmermann, Arnd Bergmann, Randy Dunlap,
Bartosz Golaszewski, Zsolt Kajtar, Gonzalo Silvalde Blanco,
linux-fbdev, dri-devel, linux-kernel, llvm, oe-kbuild-all, skhan
In-Reply-To: <bb9d90ca-aa4d-4168-bdc5-543109c74493@gmail.com>
Hi David,
Apologies for the late reply,
On Mon, Sep 29, 2025 at 1:29 AM David Hunter
<david.hunter.linux@gmail.com> wrote:
>
> On 9/27/25 12:12, kernel test robot wrote:
> > Hi Sukrut,
> >
> > kernel test robot noticed the following build errors:
> >
>
> Did you compile and test this code before submitting this patch?
>
>
Yes, I had compiled & loaded the udlfb module with no errors. Please
let me know how to proceed
in this case.
^ permalink raw reply
* Re: [PATCH] fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
From: Helge Deller @ 2025-10-01 18:36 UTC (permalink / raw)
To: Albin Babu Varghese
Cc: Simona Vetter, syzbot+48b0652a95834717f190, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <aN1ihRfB-GHTEt_4@arch-box>
On 10/1/25 19:19, Albin Babu Varghese wrote:
> Hi Helge, Thanks for the review.
>
>> I wonder if the image.height value should be capped in this case,
>> instead of not rendering any chars at all?
>> Something like (untested!):
>>
>> + if (image.dy >= info->var.yres)
>> + return;
>> + image.height = min(image.height, info->var.yres - image.dy);
>
> This looks like a better implementation than what I had.
I just added comments - not sure if mine was better.,
> I thought it might be better to skip the entire row instead of
> rendering partially.
Do you know if this affects the selection?
If so, would modifying (reducing/shortening) the selection maybe fix it?
> I’m still new to this subsystem, so thanks for pointing this out.
> I’ll test the suggested changes and send a v2.
Thanks for testing and checking!
Helge
^ permalink raw reply
* Re: [PATCH] fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
From: Albin Babu Varghese @ 2025-10-01 17:19 UTC (permalink / raw)
To: Helge Deller
Cc: Simona Vetter, syzbot+48b0652a95834717f190, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <cb00a5e2-6e50-4b01-bcd7-33eeae57ed63@gmx.de>
Hi Helge, Thanks for the review.
> I wonder if the image.height value should be capped in this case,
> instead of not rendering any chars at all?
> Something like (untested!):
>
> + if (image.dy >= info->var.yres)
> + return;
> + image.height = min(image.height, info->var.yres - image.dy);
This looks like a better implementation than what I had. I thought it might be
better to skip the entire row instead of rendering partially. I’m still new to
this subsystem, so thanks for pointing this out. I’ll test the suggested
changes and send a v2.
^ permalink raw reply
* Re: (subset) [PATCH v2 00/15] backlight: Do not include <linux/fb.h> in header file
From: Lee Jones @ 2025-10-01 13:43 UTC (permalink / raw)
To: danielt, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
ilpo.jarvinen, sven, alyssa, neal, support.opensource,
Hans de Goede, duje, Thomas Zimmermann
Cc: dri-devel, asahi, platform-driver-x86, linux-arm-kernel,
linux-fbdev
In-Reply-To: <175803873238.3892705.12154571803108246655.b4-ty@kernel.org>
On Tue, 16 Sep 2025, Lee Jones wrote:
> On Tue, 15 Jul 2025 14:24:37 +0200, Thomas Zimmermann wrote:
> > Remove the final dependencies on fbdev from the backlight subsystem.
> > This is really just the include of <linux/fb.h> in backlight, but it
> > has some fallout in other code.
> >
> > Patches 1 to 14 fix all the implicit includes that come from fb.h
> > throughout the kernel. It's all trivial, but touches various drivers.
> > Maintainers are in CC. Patch 15 fixes the backlight header.
> >
> > [...]
>
> Applied, thanks!
>
> [06/15] backlight: Include <linux/of.h>
> commit: b12224c28d84d054dfb680c05cda61d1e2584bf5
> [07/15] backlight: apple_dwi_bl: Include <linux/mod_devicetable.h>
> commit: 945e411acde3800234d506f4304203a9b11890f8
> [08/15] backlight: as3711_bl: Include <linux/of.h>
> commit: 6789cd935a57464deaacdd14c84bc026aa228e72
> [09/15] backlight: da9052_bl: Include <linux/mod_devicetable.h>
> commit: e2e76f67bdbbc7b8df608e3dd1028059d838871e
> [10/15] backlight: jornada720: Include <linux/io.h>
> commit: ce4bb1a2f1cbcd5f6471f74ee5c7e1443a4cfd84
> [11/15] backlight: ktd2801: Include <linux/mod_devicetable.h>
> commit: 5f60004f152b432c6ae5dbacc172adc1fa215825
> [12/15] backlight: led_bl: Include <linux/of.h>
> commit: b38ed7c05a35f3a029c2fc5e43a94aa81e2ac843
> [13/15] backlight: rave-sp: Include <linux/of.h> and <linux/mod_devicetable.h>
> commit: 246da2b48e2ce973db255fc4b6faf42f73c03114
> [14/15] backlight: rt4831: Include <linux/mod_devicetable.h>
> commit: ba3b29a639fe5173033914db6ee58d8d9bb86aba
> [15/15] backlight: Do not include <linux/fb.h> in header file
> commit: 9f218f9bb9d274b9d5d48a4c95e1b199141fc1f2
I have removed this commit from Backlight, since it was causing too many
issues. Please resubmit it once the merge-window is closed.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3] fbdev/simplefb: Fix use after free in simplefb_detach_genpds()
From: Janne Grunau @ 2025-10-01 6:11 UTC (permalink / raw)
To: Helge Deller
Cc: Hans de Goede, Thierry Reding, linux-fbdev, dri-devel,
linux-kernel, Daniel Huhardeaux, stable
In-Reply-To: <e0b113e6-8b3d-4d2d-b1b8-cd6609b8bca7@gmx.de>
On Tue, Sep 30, 2025 at 09:12:21PM +0200, Helge Deller wrote:
> On 9/15/25 08:36, Janne Grunau wrote:
> > The pm_domain cleanup can not be devres managed as it uses struct
> > simplefb_par which is allocated within struct fb_info by
> > framebuffer_alloc(). This allocation is explicitly freed by
> > unregister_framebuffer() in simplefb_remove().
> > Devres managed cleanup runs after the device remove call and thus can no
> > longer access struct simplefb_par.
> > Call simplefb_detach_genpds() explicitly from simplefb_destroy() like
> > the cleanup functions for clocks and regulators.
> >
> > Fixes an use after free on M2 Mac mini during
> > aperture_remove_conflicting_devices() using the downstream asahi kernel
> > with Debian's kernel config. For unknown reasons this started to
> > consistently dereference an invalid pointer in v6.16.3 based kernels.
> >
> > [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220
> > [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227
> > [ 6.750697]
> > [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY
> > [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC
> > [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT)
> > [ 6.752189] Call trace:
> > [ 6.752190] show_stack+0x34/0x98 (C)
> > [ 6.752194] dump_stack_lvl+0x60/0x80
> > [ 6.752197] print_report+0x17c/0x4d8
> > [ 6.752201] kasan_report+0xb4/0x100
> > [ 6.752206] __asan_report_load4_noabort+0x20/0x30
> > [ 6.752209] simplefb_detach_genpds+0x58/0x220
> > [ 6.752213] devm_action_release+0x50/0x98
> > [ 6.752216] release_nodes+0xd0/0x2c8
> > [ 6.752219] devres_release_all+0xfc/0x178
> > [ 6.752221] device_unbind_cleanup+0x28/0x168
> > [ 6.752224] device_release_driver_internal+0x34c/0x470
> > [ 6.752228] device_release_driver+0x20/0x38
> > [ 6.752231] bus_remove_device+0x1b0/0x380
> > [ 6.752234] device_del+0x314/0x820
> > [ 6.752238] platform_device_del+0x3c/0x1e8
> > [ 6.752242] platform_device_unregister+0x20/0x50
> > [ 6.752246] aperture_detach_platform_device+0x1c/0x30
> > [ 6.752250] aperture_detach_devices+0x16c/0x290
> > [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50
> > ...
> > [ 6.752343]
> > [ 6.967409] Allocated by task 62:
> > [ 6.970724] kasan_save_stack+0x3c/0x70
> > [ 6.974560] kasan_save_track+0x20/0x40
> > [ 6.978397] kasan_save_alloc_info+0x40/0x58
> > [ 6.982670] __kasan_kmalloc+0xd4/0xd8
> > [ 6.986420] __kmalloc_noprof+0x194/0x540
> > [ 6.990432] framebuffer_alloc+0xc8/0x130
> > [ 6.994444] simplefb_probe+0x258/0x2378
> > ...
> > [ 7.054356]
> > [ 7.055838] Freed by task 227:
> > [ 7.058891] kasan_save_stack+0x3c/0x70
> > [ 7.062727] kasan_save_track+0x20/0x40
> > [ 7.066565] kasan_save_free_info+0x4c/0x80
> > [ 7.070751] __kasan_slab_free+0x6c/0xa0
> > [ 7.074675] kfree+0x10c/0x380
> > [ 7.077727] framebuffer_release+0x5c/0x90
> > [ 7.081826] simplefb_destroy+0x1b4/0x2c0
> > [ 7.085837] put_fb_info+0x98/0x100
> > [ 7.089326] unregister_framebuffer+0x178/0x320
> > [ 7.093861] simplefb_remove+0x3c/0x60
> > [ 7.097611] platform_remove+0x60/0x98
> > [ 7.101361] device_remove+0xb8/0x160
> > [ 7.105024] device_release_driver_internal+0x2fc/0x470
> > [ 7.110256] device_release_driver+0x20/0x38
> > [ 7.114529] bus_remove_device+0x1b0/0x380
> > [ 7.118628] device_del+0x314/0x820
> > [ 7.122116] platform_device_del+0x3c/0x1e8
> > [ 7.126302] platform_device_unregister+0x20/0x50
> > [ 7.131012] aperture_detach_platform_device+0x1c/0x30
> > [ 7.136157] aperture_detach_devices+0x16c/0x290
> > [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50
> > ...
> >
> > Reported-by: Daniel Huhardeaux <tech@tootai.net>
> > Cc: stable@vger.kernel.org
> > Fixes: 92a511a568e44 ("fbdev/simplefb: Add support for generic power-domains")
> > Signed-off-by: Janne Grunau <j@jannau.net>
> > ---
> > Changes in v3:
> > - release power-domains on probe errors
> > - set par->num_genpds when it's <= 1
> > - set par->num_genpds to 0 after detaching
> > - Link to v2: https://lore.kernel.org/r/20250908-simplefb-genpd-uaf-v2-1-f88a0d9d880f@jannau.net
> >
> > Changes in v2:
> > - reworked change due to missed use of `par->num_genpds` before setting
> > it. Missed in testing due to mixing up FB_SIMPLE and SYSFB_SIMPLEFB.
> > - Link to v1: https://lore.kernel.org/r/20250901-simplefb-genpd-uaf-v1-1-0d9f3a34c4dc@jannau.net
> > ---
> > drivers/video/fbdev/simplefb.c | 31 +++++++++++++++++++++++--------
> > 1 file changed, 23 insertions(+), 8 deletions(-)
>
> applied to fbdev git tree.
Thanks.
>
> PS: Janne, if you want to push yourself via drm-misc, just let me know and I drop it...
I won't. My request for commit access is still pending. I should fine
someone at xdc to ask about that.
Janne
^ permalink raw reply
* Re: [PATCH v2 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Wei Liu @ 2025-10-01 0:01 UTC (permalink / raw)
To: Mukesh Rathor
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250915234604.3256611-1-mrathor@linux.microsoft.com>
On Mon, Sep 15, 2025 at 04:46:02PM -0700, Mukesh Rathor wrote:
> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV
> for hv subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
> built if CONFIG_HYPER is set, either loadable or builtin.
>
> This is not a good approach. CONFIG_HYPERV is really an umbrella
> config that encompasses builtin code and various other things and not
> a dedicated config option for VMBus. VMBus should really have a config
> option just like CONFIG_HYPERV_BALLOON etc. This small series introduces
> CONFIG_HYPERV_VMBUS to build VMBus driver and make that distinction
> explicit. With that CONFIG_HYPERV could be changed to bool.
>
> For now, hv_common.c is left as is to reduce conflicts for upcoming
> patches, but once merges are mostly done, that and some others should
> be moved to virt/hyperv directory.
>
> V2:
> o rebased on hyper-next: commit 553d825fb2f0
> ("x86/hyperv: Switch to msi_create_parent_irq_domain()")
>
> V1:
> o Change subject from hyper-v to "Drivers: hv:"
> o Rewrite commit messages paying attention to VMBus and not vmbus
> o Change some wordings in Kconfig
> o Make new VMBUS config option default to HYPERV option for a smoother
> transition
>
> Mukesh Rathor (2):
> Driver: hv: Add CONFIG_HYPERV_VMBUS option
I changed Driver to Drivers and applied both patches. Thanks.
^ permalink raw reply
* Re: [PATCH v1 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Wei Liu @ 2025-09-30 23:59 UTC (permalink / raw)
To: Mukesh Rathor
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <aNxuU6VI3dQVPYF7@liuwe-devbox-ubuntu-v2.lamzopl0uupeniq2etz1fddiyg.xx.internal.cloudapp.net>
On Tue, Sep 30, 2025 at 11:57:07PM +0000, Wei Liu wrote:
> On Fri, Sep 05, 2025 at 06:09:50PM -0700, Mukesh Rathor wrote:
> > At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV
> > for hv subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
> > hv_common.c that is needed for the drivers. Moreover, vmbus driver is
> > built if CONFIG_HYPER is set, either loadable or builtin.
> >
> > This is not a good approach. CONFIG_HYPERV is really an umbrella
> > config that encompasses builtin code and various other things and not
> > a dedicated config option for VMBus. VMBus should really have a config
> > option just like CONFIG_HYPERV_BALLOON etc. This small series introduces
> > CONFIG_HYPERV_VMBUS to build VMBus driver and make that distinction
> > explicit. With that CONFIG_HYPERV could be changed to bool.
> >
> > For now, hv_common.c is left as is to reduce conflicts for upcoming
> > patches, but once merges are mostly done, that and some others should
> > be moved to virt/hyperv directory.
> >
> > V1:
> > o Change subject from hyper-v to "Drivers: hv:"
> > o Rewrite commit messages paying attention to VMBus and not vmbus
> > o Change some wordings in Kconfig
> > o Make new VMBUS config option default to HYPERV option for a smoother
> > transition
> >
> > Mukesh Rathor (2):
> > Driver: hv: Add CONFIG_HYPERV_VMBUS option
> > Drivers: hv: Make CONFIG_HYPERV bool
> >
>
> Applied. Thanks.
I meant to apply v2 of this series. This is sent to the wrong version.
Please ignore.
^ permalink raw reply
* Re: [PATCH v1 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Wei Liu @ 2025-09-30 23:57 UTC (permalink / raw)
To: Mukesh Rathor
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250906010952.2145389-1-mrathor@linux.microsoft.com>
On Fri, Sep 05, 2025 at 06:09:50PM -0700, Mukesh Rathor wrote:
> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV
> for hv subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
> built if CONFIG_HYPER is set, either loadable or builtin.
>
> This is not a good approach. CONFIG_HYPERV is really an umbrella
> config that encompasses builtin code and various other things and not
> a dedicated config option for VMBus. VMBus should really have a config
> option just like CONFIG_HYPERV_BALLOON etc. This small series introduces
> CONFIG_HYPERV_VMBUS to build VMBus driver and make that distinction
> explicit. With that CONFIG_HYPERV could be changed to bool.
>
> For now, hv_common.c is left as is to reduce conflicts for upcoming
> patches, but once merges are mostly done, that and some others should
> be moved to virt/hyperv directory.
>
> V1:
> o Change subject from hyper-v to "Drivers: hv:"
> o Rewrite commit messages paying attention to VMBus and not vmbus
> o Change some wordings in Kconfig
> o Make new VMBUS config option default to HYPERV option for a smoother
> transition
>
> Mukesh Rathor (2):
> Driver: hv: Add CONFIG_HYPERV_VMBUS option
> Drivers: hv: Make CONFIG_HYPERV bool
>
Applied. Thanks.
^ permalink raw reply
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Wei Liu @ 2025-09-30 22:05 UTC (permalink / raw)
To: Mukesh R
Cc: Greg KH, dri-devel, linux-kernel, linux-input, linux-hyperv,
netdev, linux-pci, linux-scsi, linux-fbdev, linux-arch,
virtualization, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, jikos, bentiss, kys, haiyangz, wei.liu, decui,
dmitry.torokhov, andrew+netdev, davem, edumazet, kuba, pabeni,
bhelgaas, James.Bottomley, martin.petersen, deller, arnd,
sgarzare, horms
In-Reply-To: <a8c8305c-b518-c840-fc64-50bcba302725@linux.microsoft.com>
On Fri, Sep 12, 2025 at 11:10:00AM -0700, Mukesh R wrote:
[...]
> > What was it made against?
> >
>
> Sorry to hear that. It was built against hyper-next, but perhaps I
> accidentally used our internal mirror. Let me rebase and send V2
> right away.
Sorry for the late reply -- I was away for two weeks. I can pick this
series up.
Greg, feel free to ignore this series.
Wei
>
> Thanks,
> -Mukesh
>
>
>
^ permalink raw reply
* Re: [PATCH] fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
From: Helge Deller @ 2025-09-30 20:46 UTC (permalink / raw)
To: Albin Babu Varghese, Simona Vetter
Cc: syzbot+48b0652a95834717f190, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20250927075010.119671-1-albinbabuvarghese20@gmail.com>
On 9/27/25 09:50, Albin Babu Varghese wrote:
> KASAN reports vmalloc-out-of-bounds writes in sys_imageblit during console
> resize operations. The crash happens when bit_putcs renders characters
> outside the allocated framebuffer region.
>
> Call trace: vc_do_resize -> clear_selection -> invert_screen ->
> do_update_region -> fbcon_putcs -> bit_putcs -> sys_imageblit
>
> The console resize changes dimensions but bit_putcs doesn't validate that
> the character positions fit within the framebuffer before rendering.
> This causes writes past the allocated buffer in fb_imageblit functions.
>
> Fix by checking bounds before rendering:
> - Return if dy + height > yres (would write past bottom)
> - Break if dx + width > xres (would write past right edge)
>
> Reported-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190
> Tested-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com
> Signed-off-by: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
> ---
> drivers/video/fbdev/core/bitblit.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c
> index f9475c14f733..4c732284384a 100644
> --- a/drivers/video/fbdev/core/bitblit.c
> +++ b/drivers/video/fbdev/core/bitblit.c
> @@ -160,6 +160,9 @@ static void bit_putcs(struct vc_data *vc, struct fb_info *info,
> image.height = vc->vc_font.height;
> image.depth = 1;
>
> + if (image.dy + image.height > info->var.yres)
> + return;
> +
I wonder if the image.height value should be capped in this case,
instead of not rendering any chars at all?
Something like (untested!):
+ if (image.dy >= info->var.yres)
+ return;
+ image.height = min(image.height, info->var.yres - image.dy);
> if (attribute) {
> buf = kmalloc(cellsize, GFP_ATOMIC);
> if (!buf)
> @@ -173,6 +176,10 @@ static void bit_putcs(struct vc_data *vc, struct fb_info *info,
> cnt = count;
>
> image.width = vc->vc_font.width * cnt;
> +
> + if (image.dx + image.width > info->var.xres)
> + break;
> +
same here.
> pitch = DIV_ROUND_UP(image.width, 8) + scan_align;
> pitch &= ~scan_align;
> size = pitch * image.height + buf_align;
^ permalink raw reply
* Re: [PATCH] fbdev: Make drivers depend on LCD_CLASS_DEVICE
From: Helge Deller @ 2025-09-30 20:35 UTC (permalink / raw)
To: Thomas Zimmermann, arnd; +Cc: linux-fbdev, dri-devel
In-Reply-To: <20250924083411.165979-1-tzimmermann@suse.de>
On 9/24/25 10:33, Thomas Zimmermann wrote:
> LCD_CLASS_DEVICE is the user-controlled option that enables the LCD
> display subsystem. Do not select it from fbdev drivers. Selecting it
> from drivers can lead to cyclic dependencies within the config.
>
> Some guidelines for using select can be found in the kernel docs at [1].
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Link: https://elixir.bootlin.com/linux/v6.16/source/Documentation/kbuild/kconfig-language.rst#L147 # [1]
> ---
> drivers/video/fbdev/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied to fbdev.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] ARM: spitz: Do not include <linux/fb.h>
From: Dmitry Baryshkov @ 2025-09-30 20:06 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, haojian.zhuang, robert.jarzmik, linux, linux-arm-kernel,
linux-kernel, linux-fbdev, dri-devel
In-Reply-To: <20250930112651.87159-1-tzimmermann@suse.de>
On Tue, Sep 30, 2025 at 01:26:46PM +0200, Thomas Zimmermann wrote:
> This ARM architecture's source file does not require <linux/fb.h>.
> Remove the include statement.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> arch/arm/mach-pxa/spitz.h | 1 -
> 1 file changed, 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2] fbdev/radeon: Remove stale product link in Kconfig/FB_RADEON
From: Helge Deller @ 2025-09-30 19:51 UTC (permalink / raw)
To: Sukrut Heroorkar, open list:FRAMEBUFFER LAYER,
open list:FRAMEBUFFER LAYER
In-Reply-To: <20250923171409.25927-1-hsukrut3@gmail.com>
On 9/23/25 19:14, Sukrut Heroorkar wrote:
> The product page referenced in the FB_RADEON is no longer valid.
> Remove it to avoid pointing to an invalid link.
>
> Signed-off-by: Sukrut Heroorkar <hsukrut3@gmail.com>
> ---
> Changes since v1:
> - Dropped the link entirely as suggested
> (See: https://lore.kernel.org/all/CADnq5_NHu5=esJZrgy_S80jF68ZapRRYX4_L70DwDDSN3VXitQ@mail.gmail.com/)
>
> drivers/video/fbdev/Kconfig | 3 ---
> 1 file changed, 3 deletions(-)
applied.
Thanks!
Helge
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox