Use memdup_user_nul() helper instead of open-coding to simplify the code.
Signed-off-by: Geliang Tang
---
arch/powerpc/platforms/pseries/reconfig.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/reconfig.c
b/arch/powerpc/platfor
Use memdup_user() helper instead of open-coding to simplify the code.
Signed-off-by: Geliang Tang
---
arch/powerpc/platforms/powernv/opal-prd.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-prd.c
b/arch/powerpc/platforms/p
Use memdup_user() helper instead of open-coding to simplify the code.
Signed-off-by: Geliang Tang
---
arch/powerpc/kernel/nvram_64.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index eae61b0..4
The bnx2x driver is not providing proper alignment on the receive buffers it
passes to build_skb(), causing skb_shared_info to be misaligned.
skb_shared_info contains an atomic, and while PPC normally supports
unaligned accesses, it does not support unaligned atomics.
Aligning the size of rx buffe
On Fri, 28 Apr 2017 15:58:10 +0200
Peter Zijlstra wrote:
> On Fri, Apr 28, 2017 at 03:44:23PM +0200, Petr Mladek wrote:
> > On Fri 2017-04-28 11:02:26, Peter Zijlstra wrote:
> > > On Thu, Apr 27, 2017 at 03:38:19PM +0200, Petr Mladek wrote:
> > > > Also we need to look for alternatives. There
This is a trivial fix patch regarding mapped ranges in radix MMU
environment during boot. No functional change.
Before the patch:
$dmesg | grep Mapped
[0.00] Mapped range 0x0 - 0x20 with 0x4000
[0.00] Mapped range 0x2000 - 0x2020 with 0x4000
After
On Fri, 28 Apr 2017 14:57:25 +0200
Petr Mladek wrote:
> Of course, if the problem is reproducible, the easiest solution
> is to use bigger main log buffer, for example boot with
> log_buf_len=32M.
Of course that may not be enough. Especially when I have a machine with
240 CPUs. But it also has
On Fri, Apr 28, 2017 at 03:44:23PM +0200, Petr Mladek wrote:
> On Fri 2017-04-28 11:02:26, Peter Zijlstra wrote:
> > On Thu, Apr 27, 2017 at 03:38:19PM +0200, Petr Mladek wrote:
> > > Also we need to look for alternatives. There is a chance
> > > to create crashdump and get the ftrace messages from
On Fri 2017-04-28 11:02:26, Peter Zijlstra wrote:
> On Thu, Apr 27, 2017 at 03:38:19PM +0200, Petr Mladek wrote:
> > Also we need to look for alternatives. There is a chance
> > to create crashdump and get the ftrace messages from it.
> > Also this might be scenario when we might need to suggest
>
On 04/27/2017 10:59 PM, Shilpasri G Bhat wrote:
Add support for adding min/max values for the inband sensors copied by
OCC to main memory. And also add current(mA) sensors to the list.
Signed-off-by: Shilpasri G Bhat
---
Changes from V1:
- Add functions to get min and max attribute strings
- Ad
On Fri 2017-04-28 10:35:32, Sergey Senozhatsky wrote:
> On (04/27/17 12:14), Steven Rostedt wrote:
> [..]
> > I tried this patch. It's better because I get the end of the trace, but
> > I do lose the beginning of it:
> >
> > ** 196358 printk messages dropped ** [ 102.321182] perf-59810...
On Fri 2017-04-28 10:25:30, Sergey Senozhatsky wrote:
>
> On (04/20/17 15:11), Petr Mladek wrote:
> [..]
> > void printk_nmi_enter(void)
> > {
> > - this_cpu_or(printk_context, PRINTK_NMI_CONTEXT_MASK);
> > + /*
> > +* The size of the extra per-CPU buffer is limited. Use it
> > +* on
Michal Suchánek writes:
> Hello,
>
> just a nit:
>
> On Thu, 30 Mar 2017 23:03:58 +1100
> Michael Ellerman wrote:
>> + * For kernel space, we use context ids 1-5 to map address as below:
>
> This appears wrong.
>> /*
>> - * kernel take the top 4 context from the available range
>> +
Michal Suchánek noticed a comment in book3s/64/mmu-hash.h about the context ids
we use for the kernel was inconsistent with the code and other comments in the
same file.
It should read 1-4 not 1-5.
While we're touching it, update "address" to "addresses" which makes more sense
as it's referring t
On 4/27/2017 6:46 PM, Martin Hicks wrote:
>
> The max keysize for both of these is 128, not 96. Before, with keysizes
> over 96, the memcpy in ahash_setkey() would overwrite memory beyond the
> key field.
>
While here, what about aead_setkey()?
AFAICT, TALITOS_MAX_KEY_SIZE value has been incorre
From: Nicholas Piggin
An externally triggered system reset (e.g., via QEMU nmi command, or pseries
reset button) can cause system reset interrupts on all CPUs. In case this causes
xmon to be entered, it is undesirable for the primary (first) CPU into xmon to
trigger an NMI IPI to others, because
Hello,
just a nit:
On Thu, 30 Mar 2017 23:03:58 +1100
Michael Ellerman wrote:
> From: "Aneesh Kumar K.V"
>
> Currently we use the top 4 context ids (0x7fffc-0x7) for the
> kernel. Kernel VSIDs are built using these top context values and
> effective the segement ID. In subsequent patches
From: Michael Ellerman
> Sent: 28 April 2017 07:34
...
> Not sure what you mean. You can enable pr_debug()s individually, by
> function, by module, by file, or for the whole kernel.
It is sort of a shame that you can't turn pr_info() off in the same way.
David
Hi Pingfan,
[auto build test WARNING on powerpc/next]
[also build test WARNING on v4.11-rc8 next-20170428]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Pingfan-Liu/powerpc-pseries-hotplug
On 04/28/2017 11:12 AM, Rashmica Gupta wrote:
> Some powerpc hardware features may want to gain access to a chunk of
What kind of features ? Please add specifics.
> undisturbed real memory. This update provides a means to unplug said memory
Undisturbed ? Meaning part of memblock and currently i
On 04/28/2017 11:12 AM, Rashmica Gupta wrote:
> Signed-off-by: Rashmica Gupta
Please describe a bit about the function/feature you are trying
to add with this new config option. The subject says " Add config
option for removal of memory" but I guess its not related to
memory hotplug but about har
Hi Alastair,
Le 28/04/2017 à 05:20, Alastair D'Silva a écrit :
From: Alastair D'Silva
In some situations, a faulty AFU slice may create an interrupt storm,
rendering the machine unusable. Since these interrupts are informational
only, present the interrupt once, then mask it off to prevent it
On Thu, Apr 27, 2017 at 03:38:19PM +0200, Petr Mladek wrote:
> Also we need to look for alternatives. There is a chance
> to create crashdump and get the ftrace messages from it.
> Also this might be scenario when we might need to suggest
> the early_printk() patchset from Peter Zijlstra.
I'd be h
23 matches
Mail list logo
