| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A customer using nohz_full has experienced the following interruption:
oslat-1004510 [018] timer_cancel: timer=0xffff90a7ca663cf8
oslat-1004510 [018] timer_expire_entry: timer=0xffff90a7ca663cf8 function=delayed_work_timer_fn now=4709188240 baseclk=4709188240
oslat-1004510 [018] workqueue_queue_work: work struct=0xffff90a7ca663cd8 function=fb_flashcursor workqueue=events_power_efficient req_cpu=8192 cpu=18
oslat-1004510 [018] workqueue_activate_work: work struct 0xffff90a7ca663cd8
oslat-1004510 [018] sched_wakeup: kworker/18:1:326 [120] CPU:018
oslat-1004510 [018] timer_expire_exit: timer=0xffff90a7ca663cf8
oslat-1004510 [018] irq_work_entry: vector=246
oslat-1004510 [018] irq_work_exit: vector=246
oslat-1004510 [018] tick_stop: success=0 dependency=SCHED
oslat-1004510 [018] hrtimer_start: hrtimer=0xffff90a70009cb00 function=tick_sched_timer/0x0 ...
oslat-1004510 [018] softirq_exit: vec=1 [action=TIMER]
oslat-1004510 [018] softirq_entry: vec=7 [action=SCHED]
oslat-1004510 [018] softirq_exit: vec=7 [action=SCHED]
oslat-1004510 [018] tick_stop: success=0 dependency=SCHED
oslat-1004510 [018] sched_switch: oslat:1004510 [120] R ==> kworker/18:1:326 [120]
kworker/18:1-326 [018] workqueue_execute_start: work struct 0xffff90a7ca663cd8: function fb_flashcursor
kworker/18:1-326 [018] workqueue_queue_work: work struct=0xffff9078f119eed0 function=drm_fb_helper_damage_work workqueue=events req_cpu=8192 cpu=18
kworker/18:1-326 [018] workqueue_activate_work: work struct 0xffff9078f119eed0
kworker/18:1-326 [018] timer_start: timer=0xffff90a7ca663cf8 function=delayed_work_timer_fn ...
Set wq_power_efficient to true, in case nohz_full is enabled.
This makes the power efficient workqueue be unbounded, which allows
workqueue items there to be moved to HK CPUs.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Currently the workqueue just checks the atomic and locking states after work
execution ends. However, sometimes, a work item may not unlock rcu after
acquiring rcu_read_lock(). And as a result, it would cause rcu stall, but
the rcu stall warning can not dump the work func, because the work has
finished.
In order to quickly discover those works that do not call rcu_read_unlock()
after rcu_read_lock(), add the rcu lock check.
Use rcu_preempt_depth() to check the work's rcu status. Normally, this value
is 0. If this value is bigger than 0, it means the work are still holding
rcu lock. If so, print err info and the work func.
tj: Reworded the description for clarity. Minor formatting tweak.
Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com>
Reviewed-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
At the time they are created unbound workqueues rescuers currently use
cpu_possible_mask as their affinity, but this can be too wide in case a
workqueue unbound mask has been set as a subset of cpu_possible_mask.
Make new rescuers use their associated workqueue unbound cpumask from
the start.
Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Retrieving rescuers information (e.g., affinity and name) is quite
useful when debugging workqueues configurations.
Add printing of such information to the existing wq_dump.py script.
Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Currently we limit the size of the workqueue name to 24 characters due to
commit ecf6881ff349 ("workqueue: make workqueue->name[] fixed len")
Increase the size to 32 characters and print a warning in the event
the requested name is larger than the limit of 32 characters.
Signed-off-by: Audra Mitchell <audra@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
It's not easy to let go responsibility for a subsystem that one cared
for for a long time, but Thierry realized that his heart isn't in the
pwm framework any more.
Thierry cared for the pwm subsystem (commit 200efedd8766 ("pwm: Take
over maintainership of the PWM subsystem")) as a maintainer during
nearly 12 years. A big thanks for the time, effort and dedication spend
during that time.
Uwe takes over maintenance.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
From looking at the PCI IDs, every device supported by intelfb is
also supported by i915. Anyone still using intelfb should please
move on to i915, which does everything intelfb does but better.
Removing intelfb is motivated by the driver's excessive use of the
global screen_info state. The state belongs to architecture and
firmware code; device drivers should not attempt to access it. But
fixing intelfb would require a significant change in the driver's
probing logic. As intelfb has been obsolete for nearly 2 decades,
it is probably not worth the effort. Let's just remove it. Also
remove the related documentation.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maik Broemme <mbroemme@libmpq.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Do not clear the global instance of screen_info. If necessary, clearing
fields in screen_info should be done by architecture or firmware code
that maintains the firmware framebuffer.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
After consuming the global screen_info_state in sysfb_init(), the
created platform device maintains the firmware framebuffer. Clear
screen_info to avoid conflicting access. Subsequent kexec reboots
now ignore the firmware framebuffer.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Replace use of screen_info state with the correct interfaces from
the aperture helpers. The state is only for architecture and firmware
code. It is not guaranteed to contain valid data. Drivers are thus
not allowed to use it.
For removing conflicting firmware framebuffers, there are aperture
helpers. Hence replace screen_info with the correct functions that will
remove conflicting framebuffers for the hypervfb driver. For GEN1 PCI
devices, the driver reads the framebuffer base and size from the PCI
BAR, and uses the range for removing the firmware framebuffer. For
GEN2 VMBUS devices no range can be detected, so the driver clears all
firmware framebuffers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Replace use of screen_info state with the correct interface from
the aperture helpers. The state is only for architecture and firmware
code. It is not guaranteed to contain valid data. Drivers are thus
not allowed to use it.
For removing conflicting firmware framebuffers, there are aperture
helpers. Hence replace screen_info with the correct function that will
remove conflicting framebuffers for the hyperv-drm driver. Also
move the call to the correct place within the driver.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
When built-in, the sis driver tries to detect the current display mode
from the global screen_info state. That state is only for architecture
and firmware code. Drivers should not use it directly as it's not
guaranteed to contain valid information.
Remove the mode-detection code from sis. Drivers that want to detect a
pre-set mode on probe should read the hardware registers directly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Currently the %d format specifier is being used for unsigned int values.
Fix this by using the correct %u format specifier. Cleans up cppcheck
warnings:
warning: %d in format string (no. 1) requires 'int' but the argument
type is 'unsigned int'. [invalidPrintfArgType_sint]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The info field in struct sti_struct was used to detect the default
display device. That test is now done with the respective Linux device
and the info field is unused. Remove it.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Update fb_is_primary device() on parisc to detect the primary display
device from the Linux device instance. Aligns the code with the other
architectures. A later patch will remove the fbdev dependency from the
function's interface.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Allocate stifb's instance of fb_info with framebuffer_alloc(). This
is the preferred way of creating fb_info with associated driver data
stored in struct fb_info.par. Requires several, but minor, changes
through out the driver's code.
The intended side effect of this patch is that the new instance of
struct fb_info now has its device field correctly set to the parent
device of the STI ROM. A later patch can detect if the device is the
firmware's primary output. It is also now correctly located within
the Linux device hierarchy.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Helge Deller <deller@gmx.de>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Store the ROM's parent device in each STI struct, so we can associate
the STI framebuffer with a device.
The new field will eventually replace the fbdev subsystem's info field,
which the function fb_is_primary_device() currently requires to detect
the firmware's output. By using the device instead of the framebuffer
info, a later patch can generalize the helper for use in non-fbdev code.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
When framebuffer gets closed, the queued deferred IO gets cancelled. This
can cause some last display data to vanish. This is problematic for users
who send a still image to the framebuffer, then close the file: the image
may never appear.
To ensure none of display data get lost, flush the queued deferred IO
first before closing.
Another possible solution is to delete the cancel_delayed_work_sync()
instead. The difference is that the display may appear some time after
closing. However, the clearing of page mapping after this needs to be
removed too, because the page mapping is used by the deferred work. It is
not completely obvious whether it is okay to not clear the page mapping.
For a patch intended for stable trees, go with the simple and obvious
solution.
Fixes: 60b59beafba8 ("fbdev: mm: Deferred IO support")
Cc: stable@vger.kernel.org
Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The driver's fsync() is supposed to flush any pending operation to
hardware. It is implemented in this driver by cancelling the queued
deferred IO first, then schedule it for "immediate execution" by calling
schedule_delayed_work() again with delay=0. However, setting delay=0
only means the work is scheduled immediately, it does not mean the work
is executed immediately. There is no guarantee that the work is finished
after schedule_delayed_work() returns. After this driver's fsync()
returns, there can still be pending work. Furthermore, if close() is
called by users immediately after fsync(), the pending work gets
cancelled and fsync() may do nothing.
To ensure that the deferred IO completes, use flush_delayed_work()
instead. Write operations to this driver either write to the device
directly, or invoke schedule_delayed_work(); so by flushing the
workqueue, it can be guaranteed that all previous writes make it to the
device.
Fixes: 5e841b88d23d ("fb: fsync() method for deferred I/O flush.")
Cc: stable@vger.kernel.org
Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
We have managed to ascertain that all users of the old FBDEV
code that are out of tree are now gone.
The new DRM driver can be found in drivers/gpu/drm/pl111/.
The remaining out of tree user was the ARM FVP emulation
platform, running Android. Thanks to changes in Android
versions 13 and 14, Android can now use the DRM driver when
being emulated under FVP. Some final patches are being put
in place to make it fully featured.
This is essentially a revert of the partial revert in
commit 112c35237c72 ("Partially revert "video: fbdev: amba-clcd: Retire elder CLCD driver"")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
As far as anybody can tell, this product never shipped. If it did,
it shipped in 2007 and nobody has access to one any more. Remove the
fbdev driver and the backlight driver.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The expected result value for the call to of_count_phandle_with_args()
was updated from 7 to 8, but the accompanying error message was
forgotten.
Fixes: 4dde83569832f937 ("of: Fix double free in of_parse_phandle_with_args_map")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20240111085025.2073894-1-geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Convert Altera's bridges to yaml with using fpga-bridge.yaml.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Xu Yilun <yilun.xu@intel.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/07d646a6d82cc21b100e45ced7cae3ef05faa2cc.1704807147.git.michal.simek@amd.com
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Convert the generic fpga bridge DT binding to json-schema.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Xu Yilun <yilun.xu@intel.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/14558a4dcfab5255c1683015287e9c7f48b1afc2.1704807147.git.michal.simek@amd.com
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Add Silicon Mortion Technology Corporation
https://www.siliconmotion.com/
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/c8aaf67e3fcdb7e60632c53a784691aabfc7733e.1704788539.git.ysato@users.sourceforge.jp
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
The recently added driver uses the firmware loader mechanism but causes
a link failure when that is in a loadable module while thp7312 itself
is built-in:
arm-linux-gnueabi-ld: drivers/media/i2c/thp7312.o: in function `thp7312_probe':
thp7312.c:(.text+0x4164): undefined reference to `firmware_upload_register'
Select the required Kconfig symbol. Note that the driver specifically
needs the firmware upload interface that is controlled by CONFIG_FW_UPLOAD,
but there is no link failure when that is disabled because the interfaces
are stubbed out here.
Link: https://lore.kernel.org/linux-media/20240103155811.4092035-1-arnd@kernel.org
Fixes: 7a52ab415b43 ("media: i2c: Add driver for THine THP7312")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
Fix kernel-doc warnings found when using "W=1".
hgafb.c:370: warning: No description found for return value of 'hgafb_open'
hgafb.c:384: warning: No description found for return value of 'hgafb_release'
hgafb.c:406: warning: No description found for return value of 'hgafb_setcolreg'
hgafb.c:425: warning: No description found for return value of 'hgafb_pan_display'
hgafb.c:425: warning: expecting prototype for hga_pan_display(). Prototype was for hgafb_pan_display() instead
hgafb.c:455: warning: No description found for return value of 'hgafb_blank'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-nvidia@lists.surfsouth.com
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Fixes: 641b4b1b6a7c ("video: mmpdisp: add spi port in display controller")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Explicitly cast __iomem pointer to const void* with __force to fix the
following warning:
incorrect type in argument 1 (different address spaces)
expected void const volatile *address
got char [noderef] __iomem *screen_base
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202311161120.BgyxTBMQ-lkp@intel.com/
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Linux kernel coding style uses '*/' on a separate line at the end of
multi line comments.
Fix block comments by moving '*/' at the end of block comments on a
separate line as reported by checkpatch:
WARNING: Block comments use a trailing */ on a separate line
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Resolve the following warning reported by checkpatch:
WARNING: Prefer using '"%s...", __func__' to using 'imxfb_blank', this function's name, in a string
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Resolve the following warning reported by checkpatch:
WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
This made it necessary to move the 'fbi->pdev = pdev' setting to the
beginning of the driver's probing.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Fix the following checkpatch error:
ERROR: space required after that ',' (ctx:VxV)
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Resolve the following warning reported by checkpatch:
WARNING: Unnecessary ftrace-like logging - prefer using ftrace
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Resolve the following warning reported by checkpatch.pl:
WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
The patch also removes some license info made redundant by the addition
of the SPDX tag.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The patch gets rid of magic numbers replacing them with appropriate
macros.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Replace opencoded masking and shifting, with BIT(), GENMASK(),
FIELD_GET() and FIELD_PREP() macros.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The patch moves the bitfields of the PCR register near the macro that
defines its offset, just like for all the other registers.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The previous setting did not take into account the CSTN mode.
For the H_WAIT_2 bitfield (bits 0-7) of the LCDC Horizontal Configuration
Register (LCDCR), the IMX25RM manual states that:
In TFT mode, it specifies the number of SCLK periods between the end of
HSYNC and the beginning of OE signal, and the total delay time equals
(H_WAIT_2 + 3) of SCLK periods.
In CSTN mode, it specifies the number of SCLK periods between the end of
HSYNC and the first display data in each line, and the total delay time
equals (H_WAIT_2 + 2) of SCLK periods.
The patch handles both cases.
Fixes: 4e47382fbca9 ("fbdev: imxfb: warn about invalid left/right margin")
Fixes: 7e8549bcee00 ("imxfb: Fix margin settings")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The MV88E6060 switch has internal PHY registers at MDIO
addresses 0x00..0x04. Tie each port to the corresponding
PHY.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231020-ixp4xx-usr8200-dtsfix-v1-1-3a8591dea259@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
These are all options for boards that got removed in the past and
are not relevant here because the options no longer exist or
are implied by the platform.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
SLUB is now the only remaining allocator after the SLAB removal and it
was the default already before that, so no need to mention it in the
defconfig files.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
CONFIG_NET_ETHERNET was removed a long time ago in f860b0522f65 ("drivers/net:
Kconfig and Makefile cleanup"). Remove the last references to in in ARM
defconfig files.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
These were removed last year in commit 721da5cee9d4 ("driver core:
remove CONFIG_SYSFS_DEPRECATED and CONFIG_SYSFS_DEPRECATED_V2"),
so remove the last references to them in arm config files.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
As part of general housekeeping, change the defconfig files to
sort lines based on the 'make savedefconfig' output, to make
it easier to do additional changes on top.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
A number of options got reorganized over time wihtin Kconfig, so make sure
everything is where it belongs in order to simplify defconfig changes
again in the future.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The wording in the current documentation is a little strong. The
intention was not to fix any particular interrupt as wakeup capable but
leave those details to the device. It wasn't intended to enforce any
rules as what can be or can't be a wakeup interrupt.
Soften the wording to not mandate that the 'wakeup-source' property be
used, and clarify what it means when an interrupt is marked (or not
marked) for wakeup.
Link: https://lore.kernel.org/all/ZYAjxxHcCOgDVMTQ@bogus/
Link: https://lore.kernel.org/all/CAL_Jsq+MYwOG40X26cYmO9EkZ9xqWrXDi03MaRfxnV-+VGkXWQ@mail.gmail.com/
Signed-off-by: Mark Hasemeyer <markhas@chromium.org>
Link: https://lore.kernel.org/r/20240102140734.v4.4.I1016a45ac9e8daf8a9ebc9854ab90ec3542e7c30@changeid
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Fix the size check added to dns_resolver_preparse() for the V1 server-list
header so that it doesn't give EINVAL if the size supplied is the same as
the size of the header struct (which should be valid).
This can be tested with:
echo -n -e '\0\0\01\xff\0\0' | keyctl padd dns_resolver desc @p
which will give "add_key: Invalid argument" without this fix.
Fixes: 1997b3cb4217 ("keys, dns: Fix missing size check of V1 server-list header")
Reported-by: Pengfei Xu <pengfei.xu@intel.com>
Link: https://lore.kernel.org/r/ZZ4fyY4r3rqgZL+4@xpf.sh.intel.com/
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Suppose we issue two FITRIM ioctls for ranges [0,15] and [16,31] with
mininum length of trimmed range set to 8 blocks. If we have say a range of
blocks 10-22 free, this range will not be trimmed because it straddles the
boundary of the two FITRIM ranges and neither part is big enough. This is a
bit surprising to some users that call FITRIM on smaller ranges of blocks
to limit impact on the system. Also XFS trims all free space extents that
overlap with the specified range so we are inconsistent among filesystems.
Let's change ext4_try_to_trim_range() to consider for trimming the whole
free space extent that straddles the end of specified range, not just the
part of it within the range.
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20231216010919.1995851-1-yebin10@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
Currently in case the goal length is a multiple of stripe size we use
ext4_mb_scan_aligned() to find the stripe size aligned physical blocks.
In case we are not able to find any, we again go back to calling
ext4_mb_choose_next_group() to search for a different suitable block
group. However, since the linear search always begins from the start,
most of the times we end up with the same BG and the cycle continues.
With large fliesystems, the CPU can be stuck in this loop for hours
which can slow down the whole system. Hence, until we figure out a
better way to continue the search (rather than starting from beginning)
in ext4_mb_choose_next_group(), lets just fallback to
ext4_mb_complex_scan_group() in case aligned scan fails, as it is much
more likely to find the needed blocks.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/ee033f6dfa0a7f2934437008a909c3788233950f.1702455010.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
Marcelo Tosatti
Xuewen Yan
Juri Lelli
Audra Mitchell
Uwe Kleine-König
Thomas Zimmermann
Colin Ian King
Nam Cao
Linus Walleij
Matthew Wilcox (Oracle)
Geert Uytterhoeven
Michal Simek
Yoshinori Sato
Arnd Bergmann
Randy Dunlap
Dario Binacchi
Stanislav Kinsburskii
Mark Hasemeyer
David Howells
Ye Bin
Ojaswin Mujoo