Since snprintf() returns the possible output size instead of the
actual output size, the available flash_msg length returned by
get_validate_flash_msg may exceed the given buffer limit when
simple_read_from_buffer calls copy_to_user
Signed-off-by: Yi Zhuang
---
arch/powerpc/kernel/rtas_flash.c |
Hi Yi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on v5.14-rc1 next-20210713]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as
..snip..
> > > I think the main question I have is how would you like to see patches for
> > > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
> >
> > Yes that would be perfect. If there are any dependencies on the rc1, I
> > can rebase it on top of that.
>
> Yes, please,
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were
Hello,
this is v4 of the final patch set for my effort to make struct
bus_type::remove return void.
The first four patches contain cleanups that make some of these
callbacks (more obviously) always return 0. They are acked by the
respective maintainers. Bjorn Helgaas explicitly asked to include t
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were
Hello,
this is the final patch set for my effort to make struct
bus_type::remove return void.
The first four patches contain cleanups that make some of these
callbacks (more obviously) always return 0. They are acked by the
respective maintainers. Bjorn Helgaas explicitly asked to include the
pci
On 12/07/21 18:18, Srikar Dronamraju wrote:
> Hi Valentin,
>
>> On 01/07/21 09:45, Srikar Dronamraju wrote:
>> > @@ -1891,12 +1894,30 @@ void sched_init_numa(void)
>> > void sched_domains_numa_masks_set(unsigned int cpu)
>> > {
>>
>> Hmph, so we're playing games with masks of offline nodes - is t
On 7/13/21 7:57 PM, Daniel Henrique Barboza wrote:
Aneesh,
This series compiles with a configuration made with "pseries_le_defconfig"
but fails with a config based on an existing RHEL8 config.
The reason, which is hinted in the robot replies in patch 4, is that you
defined
a "__vphn_get_associ
Aneesh,
This series compiles with a configuration made with "pseries_le_defconfig"
but fails with a config based on an existing RHEL8 config.
The reason, which is hinted in the robot replies in patch 4, is that you defined
a "__vphn_get_associativity" inside a #ifdef CONFIG_PPC_SPLPAR guard but
The performance reporting driver added cpu hotplug
feature but it didn't add pmu migration call in cpu
offline function.
This can create an issue incase the current designated
cpu being used to collect fme pmu data got offline,
as based on current code we are not migrating fme pmu to
new target cpu
On 7/12/21 7:57 AM, Wu, Hao wrote:
>> Subject: [PATCH v2] fpga: dfl: fme: Fix cpu hotplug issue in performance
>> reporting
>>
>> The performance reporting driver added cpu hotplug
>> feature but it didn't add pmu migration call in cpu
>> offline function.
>> This can create an issue incase the
12 matches
Mail list logo
