If of_clk_add_provider() fails in ca8210_register_ext_clock(),
it calls clk_unregister() to release priv->clk and returns an
error. However, the caller ca8210_probe() then calls ca8210_remove(),
where priv->clk is freed again in ca8210_unregister_ext_clock(). In
this case, a use-after-free may
On Tue, 5 Sep 2023 09:52:53 +0800
"wuqiang.matt" wrote:
> kretprobe is using freelist to manage return-instances, but freelist,
> as LIFO queue based on singly linked list, scales badly and reduces
> the overall throughput of kretprobed routines, especially for high
> contention scenarios.
>
>
> Hello Dinghao,
>
>
> On 01.10.23 09:19, kernel test robot wrote:
> > Hi Dinghao,
> >
> > kernel test robot noticed the following build warnings:
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v6.6-rc3 next-20230929]
> > [If your patch is applied to the
On Fri, 2023-10-06 at 14:52 +0200, David Hildenbrand wrote:
> On 05.10.23 20:31, Vishal Verma wrote:
> >
<..>
> > @@ -2167,47 +2221,28 @@ static int __ref try_remove_memory(u64 start, u64
> > size)
> > if (rc)
> > return rc;
> >
> > + mem_hotplug_begin();
> > +
>
Setting WERROR for random subsystems make life really hard
for subsystems which want to build-test their stuff with W=1.
WERROR for the entire kernel now exists and can be used
instead. W=1 people probably know how to deal with the global
W=1 already, tracking all per-subsystem WERRORs is too
On Fri, Oct 6, 2023 at 8:33 PM Michal Wilczynski
wrote:
>
> AC driver uses struct acpi_driver incorrectly to register itself. This
> is wrong as the instances of the ACPI devices are not meant to
> be literal devices, they're supposed to describe ACPI entry of a
> particular device.
>
> Use
On Fri, Oct 06, 2023 at 08:30:52PM +0300, Michal Wilczynski wrote:
> AC driver uses struct acpi_driver incorrectly to register itself. This
> is wrong as the instances of the ACPI devices are not meant to
> be literal devices, they're supposed to describe ACPI entry of a
> particular device.
>
>
In acpi_nfit_ctl() ACPI handle is extracted using to_acpi_dev()
function and accessing handle field in ACPI device. After transformation
from ACPI driver to platform driver this is not optimal anymore. To get
a handle it's enough to just use ACPI_HANDLE() macro to extract the
handle.
Since transformation from ACPI driver to platform driver there are two
devices on which the driver operates - ACPI device and platform device.
For the sake of reader this calls for the distinction in their naming,
to avoid confusion. Rename device to adev, as corresponding
platform device is
NFIT driver uses struct acpi_driver incorrectly to register itself.
This is wrong as the instances of the ACPI devices are not meant
to be literal devices, they're supposed to describe ACPI entry of a
particular device.
Use platform_driver instead of acpi_driver. In relevant places call
platform
AC driver uses struct acpi_driver incorrectly to register itself. This
is wrong as the instances of the ACPI devices are not meant to
be literal devices, they're supposed to describe ACPI entry of a
particular device.
Use platform_driver instead of acpi_driver. In relevant places call
platform
Use modern string_choices API instead of manually determining the
output using ternary operator.
Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Signed-off-by: Michal Wilczynski
---
drivers/acpi/ac.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
Remove unnecessary checks for NULL for variables that can't be NULL at
the point they're checked for it. Defensive programming is discouraged
in the kernel.
Signed-off-by: Michal Wilczynski
---
drivers/acpi/ac.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
Currently there is a number of drivers that somewhat incorrectly
register themselves as acpi_driver, while they should be registering as
platform_drivers. acpi_device was never meant to represent actual
device, it only represents an entry in the ACPI table and ACPI driver
should be treated as a
On 10/6/2023 5:36 PM, Rafael J. Wysocki wrote:
> On Thu, Oct 5, 2023 at 10:39 PM Wilczynski, Michal
> wrote:
>>
>>
>> On 10/5/2023 8:28 PM, Wilczynski, Michal wrote:
>>> On 10/5/2023 7:57 PM, Rafael J. Wysocki wrote:
On Monday, September 25, 2023 4:48:35 PM CEST Michal Wilczynski wrote:
On Thu, Oct 05, 2023 at 05:07:28PM +0200, Michal Suchanek wrote:
> The default MODLIB value is composed of two variables and the hardcoded
> string '/lib/modules/'.
>
> MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
>
> Defining this middle part as a variable was rejected on the basis
On Thu, 2023-10-05 at 14:20 -0700, Dan Williams wrote:
> Vishal Verma wrote:
<..>
> >
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1380,6 +1380,44 @@ static bool mhp_supports_memmap_on_memory(unsigned
> > long size)
> > return
On Thu, Oct 5, 2023 at 10:39 PM Wilczynski, Michal
wrote:
>
>
>
> On 10/5/2023 8:28 PM, Wilczynski, Michal wrote:
> >
> > On 10/5/2023 7:57 PM, Rafael J. Wysocki wrote:
> >> On Monday, September 25, 2023 4:48:35 PM CEST Michal Wilczynski wrote:
> >>> Some devices implement ACPI driver as a way to
Now that the driver core allows for struct class to be in read-only
memory, we should make all 'class' structures declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at runtime.
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Hi Thomas,
On Tue, Sep 19, 2023 at 9:57 PM Thomas Gleixner wrote:
> Though it just occured to me that there are dragons lurking:
>
> arch/alpha/Kconfig: select ARCH_NO_PREEMPT
> arch/hexagon/Kconfig: select ARCH_NO_PREEMPT
> arch/m68k/Kconfig: select ARCH_NO_PREEMPT if !COLDFIRE
>
On 05.10.23 20:31, Vishal Verma wrote:
The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to
'memblock_size' chunks of memory being added. Adding a larger span of
memory precludes memmap_on_memory semantics.
For users of hotplug such as kmem, large amounts of memory might get
On 03.10.23 22:03, Verma, Vishal L wrote:
On Mon, 2023-10-02 at 11:28 +0200, David Hildenbrand wrote:
+
+static int __ref try_remove_memory(u64 start, u64 size)
+{
+ int rc, nid = NUMA_NO_NODE;
+
+ BUG_ON(check_hotplug_memory_range(start, size));
+
+ /*
+ * All memory
Thank you, Kai! I'm not familiar with any next steps to get this merged
upstream, but atm all commits in this series have been reviewed by at
least Jarkko. Let me know if anything further is needed from my side!
Best,
Jo
On 05.10.23 23:25, Huang, Kai wrote:
Hi Jo,
Just FYI I won't review
23 matches
Mail list logo
