https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #10 from Christophe Leroy (christophe.le...@c-s.fr) ---
Thanks for testing.
Proposed patch at https://patchwork.ozlabs.org/patch/1097492/
Note that the backport to stable should be straight forward as the directory
and file name
[ Sorry about html and mobile crud, I'm not at the computer right now ]
How about we just undo the whole misguided probe_kernel_address() thing?
The excuse for is was that it would avoid crashes.
It turns out that was wrong, and that it just made things much worse.
Honestly, we haven't really
On (05/09/19 21:47), Linus Torvalds wrote:
>[ Sorry about html and mobile crud, I'm not at the computer right now ]
>How about we just undo the whole misguided probe_kernel_address() thing?
But the problem will remain - %pS/%pF on PPC (and some other arch-s)
do
On (05/09/19 14:19), Petr Mladek wrote:
> 1. Report on Power:
>
> Kernel crashes very early during boot with with CONFIG_PPC_KUAP and
> CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
>
> The problem is the combination of some new code called via printk(),
> check_pointer() which calls
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> Define new "d-modsig" template field which holds the digest that is
> expected to match the one contained in the modsig, and also new "modsig"
> template field which holds the appended file signature.
>
> Add a new "ima-modsig"
Hi Thiago,
> diff --git a/security/integrity/ima/ima_policy.c
> b/security/integrity/ima/ima_policy.c
> index fca7a3f23321..a7a20a8c15c1 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -1144,6 +1144,12 @@ void ima_delete_rules(void)
> }
>
> Looks good to me.
>
>>
>> (I would actually even prefer "memory_block_devices", because memory
>> blocks have different meanins)
>>
>
> Agree with you, this comes to my mind sometime ago :-)
We have memblocks, memory_blocks ... I guess memory_block_device is
unique :)
>
>>>
>>> [...]
>>>
On Thu, May 09, 2019 at 04:58:56PM +0200, David Hildenbrand wrote:
>On 09.05.19 16:31, Wei Yang wrote:
>> On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>>> Only memory to be added to the buddy and to be onlined/offlined by
>>> user space using memory block devices needs (and
On Thu, May 09, 2019 at 04:55:34PM +0200, Borislav Petkov wrote:
> On Fri, May 10, 2019 at 12:52:05AM +1000, Michael Ellerman wrote:
> > Thanks. It would be nice if you could send it as a fix for 5.2, it's the
> > last thing blocking one of my allmodconfig builds. But if you don't
> > think it
From: Michal Suchánek
> Sent: 09 May 2019 14:38
...
> > The problem is the combination of some new code called via printk(),
> > check_pointer() which calls probe_kernel_read(). That then calls
> > allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early
> > (before we've patched
On Thu, May 09, 2019 at 11:35:36AM +0530, Sachin Sant wrote:
>
>
> > On 09-May-2019, at 4:53 AM, Roman Gushchin wrote:
> >
> > On Wed, May 08, 2019 at 03:06:30PM +0530, Sachin Sant wrote:
> >> While running LTP tests(specifically ptrace01) following WARNING is
> >> observed
> >> on POWER8
On Fri, May 10, 2019 at 12:31:05AM +1000, Michael Ellerman wrote:
> Greg Kroah-Hartman writes:
> > On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> >> I see multiple instances of:
> >>
> >> arch/powerpc/kernel/exceptions-64s.S:839: Error:
> >>attempt to move .org backwards
>
On 04/16, Dmitry V. Levin wrote:
>
> [Andrew, could you take this patchset into your tree, please?]
Just in case...
I have already acked 6/7.
Other patches look good to me too, just I don't think I can actually review
these non-x86 changes.
Oleg.
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> Verify xattr signature in a separate function so that the logic in
> ima_appraise_measurement() remains clear when it gains the ability to also
> verify an appended module signature.
>
> The code in the switch statement is
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> IMA will need to verify a PKCS#7 signature which has already been parsed.
> For this reason, factor out the code which does that from
> verify_pkcs7_signature() into a new function which takes a struct
> pkcs7_message instead of a
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> IMA will use the module_signature format for append signatures, so export
> the relevant definitions and factor out the code which verifies that the
> appended signature trailer is valid.
>
> Also, create a CONFIG_MODULE_SIG_FORMAT
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> Designated initializers allow specifying only the members of the struct
> that need initialization. Non-mentioned members are initialized to zero.
>
> This makes the code a bit clearer (particularly in ima_add_boot_aggregate()
>
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
> IMA will need to access the digest of the PKCS7 message (as calculated by
> the kernel) before the signature is verified, so introduce
> pkcs7_get_digest() for that purpose.
>
> Also, modify pkcs7_digest() to detect when the digest
On Wed, 2019-05-08 at 12:30:47 UTC, Michael Ellerman wrote:
> When implementing the KUAP support on Radix we fixed one case where
> mmu_has_feature() was being called too early in boot via
> __put_user_size().
>
> However since then some new code in linux-next has created a new path
> via which
On Mon, 2019-05-06 at 00:20:43 UTC, Rick Lindsley wrote:
> When the memset code was added to pgd_alloc(), it failed to consider that
> kmem_cache_alloc() can return NULL. It's uncommon, but not impossible under
> heavy memory contention.
>
> Signed-off-by: Rick Lindsley
> Fixes: cf266dbcd2a7
On 29/04/2019 03:05, Paul Mackerras wrote:
> On Wed, Apr 03, 2019 at 03:16:12PM +0100, Steven Price wrote:
>> Since pmd_large() is now always available, pmd_is_leaf() is redundant.
>> Replace all uses with calls to pmd_large().
>
> NAK. I don't want to do this, because pmd_is_leaf() is purely
On 09.05.19 16:31, Wei Yang wrote:
> On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>> Only memory to be added to the buddy and to be onlined/offlined by
>> user space using memory block devices needs (and should have!) memory
>> block devices.
>>
>> Factor out creation of
On Fri, May 10, 2019 at 12:52:05AM +1000, Michael Ellerman wrote:
> Thanks. It would be nice if you could send it as a fix for 5.2, it's the
> last thing blocking one of my allmodconfig builds. But if you don't
> think it qualifies as a fix that's fine too, it can wait.
Sure, no problem. Will do
Borislav Petkov writes:
> On Mon, May 06, 2019 at 08:50:45AM +0200, Johannes Thumshirn wrote:
>> Acked-by: Johannes Thumshirn
>
> Queued, thanks.
Thanks. It would be nice if you could send it as a fix for 5.2, it's the
last thing blocking one of my allmodconfig builds. But if you don't
think it
Herbert Xu writes:
> On Thu, May 02, 2019 at 11:08:55AM +, Horia Geanta wrote:
>> >> +
>> >> static inline void wr_reg32(void __iomem *reg, u32 data)
>> >> {
>> >> if (caam_little_end)
>> >
>> > This crashes on my p5020ds. Did you test on powerpc?
>> >
>> > # first bad commit:
Christophe Leroy writes:
> Le 08/05/2019 à 03:30, Michael Neuling a écrit :
>> If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
>> at linking with:
>>arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined
>> reference to `dawr_force_enable'
>>
>> This was
Petr Mladek writes:
> On Wed 2019-05-08 00:54:51, Michael Ellerman wrote:
>> Hi folks,
>>
>> Just an FYI in case anyone else is seeing crashes very early in boot in
>> linux-next with the above config options.
>>
>> The problem is the combination of some new code called via printk(),
>>
On Thu, 9 May 2019 07:06:32 -0700
Guenter Roeck wrote:
> On 5/9/19 6:26 AM, Michal Suchánek wrote:
> > On Thu, 9 May 2019 06:07:31 -0700
> > Guenter Roeck wrote:
> >
> >> On 5/9/19 2:49 AM, Michal Suchánek wrote:
> >>> On Thu, 9 May 2019 08:53:24 +0200
> >>> Greg Kroah-Hartman wrote:
>
On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>Only memory to be added to the buddy and to be onlined/offlined by
>user space using memory block devices needs (and should have!) memory
>block devices.
>
>Factor out creation of memory block devices Create all devices after
Greg Kroah-Hartman writes:
> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
>> I see multiple instances of:
>>
>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
>> attempt to move .org backwards
>>
>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>>
>> This is due to
On 5/9/19 6:26 AM, Michal Suchánek wrote:
On Thu, 9 May 2019 06:07:31 -0700
Guenter Roeck wrote:
On 5/9/19 2:49 AM, Michal Suchánek wrote:
On Thu, 9 May 2019 08:53:24 +0200
Greg Kroah-Hartman wrote:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple
On Thu 2019-05-09 09:13:57, Steven Rostedt wrote:
> On Thu, 9 May 2019 14:19:23 +0200
> Petr Mladek wrote:
>
> > The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
> > invalid pointers") broke boot on several architectures. The common
> > pattern is that
On 09.05.19 15:55, Wei Yang wrote:
> On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>> Only memory to be added to the buddy and to be onlined/offlined by
>> user space using memory block devices needs (and should have!) memory
>> block devices.
>>
>> Factor out creation of
On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>Only memory to be added to the buddy and to be onlined/offlined by
>user space using memory block devices needs (and should have!) memory
>block devices.
>
>Factor out creation of memory block devices Create all devices after
On Thu, 9 May 2019 14:19:23 +0200
Petr Mladek wrote:
> The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
> invalid pointers") broke boot on several architectures. The common
> pattern is that probe_kernel_read() is not working during early
> boot because userspace access
On Thu, 9 May 2019 06:07:31 -0700
Guenter Roeck wrote:
> On 5/9/19 2:49 AM, Michal Suchánek wrote:
> > On Thu, 9 May 2019 08:53:24 +0200
> > Greg Kroah-Hartman wrote:
> >
> >> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> >>> I see multiple instances of:
> >>>
> >>>
On Thu, 9 May 2019 14:19:23 +0200
Petr Mladek wrote:
> The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
> invalid pointers") broke boot on several architectures. The common
> pattern is that probe_kernel_read() is not working during early
> boot because userspace access
On 5/9/19 2:49 AM, Michal Suchánek wrote:
On Thu, 9 May 2019 08:53:24 +0200
Greg Kroah-Hartman wrote:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error:
attempt to move .org backwards
in
On Thu, May 09, 2019 at 02:19:23PM +0200, Petr Mladek wrote:
> The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
> invalid pointers") broke boot on several architectures. The common
> pattern is that probe_kernel_read() is not working during early
> boot because userspace
flush_hash_pages() runs with data translation off, so current
task_struct has to be accesssed using physical address.
Reported-by: Erhard F.
Fixes: f7354ccac844 ("powerpc/32: Remove CURRENT_THREAD_INFO and rename TI_CPU")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>Only memory to be added to the buddy and to be onlined/offlined by
>user space using memory block devices needs (and should have!) memory
>block devices.
>
>Factor out creation of memory block devices Create all devices after
On 09.05.19 14:43, Wei Yang wrote:
> On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>> Only memory to be added to the buddy and to be onlined/offlined by
>> user space using memory block devices needs (and should have!) memory
>> block devices.
>>
>> Factor out creation of
On Tue, May 07, 2019 at 08:37:57PM +0200, David Hildenbrand wrote:
>By converting start and size to page granularity, we actually ignore
>unaligned parts within a page instead of properly bailing out with an
>error.
>
>Cc: Andrew Morton
>Cc: Oscar Salvador
>Cc: Michal Hocko
>Cc: David
The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
invalid pointers") broke boot on several architectures. The common
pattern is that probe_kernel_read() is not working during early
boot because userspace access framework is not ready.
The check is only the best effort.
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
I tried to apply the patch on top of 5.1.0 but it did not work out 'cause there
is no arch/powerpc/mm/book3s32/hash_low.S. The correct file on my system seemed
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #9 from Erhard F. (erhar...@mailbox.org) ---
@Christophe: Oops, accidentally I trashed your last comment. Sorry! This patch
didn't apply either. There is no book3s32 directory in my linux-stable tree,
the hash_*.S files are directly
Le 08/05/2019 à 02:45, Michael Ellerman a écrit :
Christophe Leroy writes:
Selects HAVE_C_RECORDMCOUNT to use the C version of the recordmcount
intead of the old Perl Version of recordmcount.
This should improve build time. It also seems like the old Perl Version
misses some calls to
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #7 from Christophe Leroy (christophe.le...@c-s.fr) ---
On 05/09/2019 10:05 AM, bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=203125
>
> Christophe Leroy (christophe.le...@c-s.fr) changed:
>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #6 from Christophe Leroy (christophe.le...@c-s.fr) ---
Try followin change:
diff --git a/arch/powerpc/mm/book3s32/hash_low.S
b/arch/powerpc/mm/book3s32/hash_low.S
index e27792d0b744..8366c2abeafc 100644
---
On 05/09/2019 10:05 AM, bugzilla-dae...@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=203125
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
https://bugzilla.kernel.org/show_bug.cgi?id=203125
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
CC|
On Thu, 9 May 2019 08:53:24 +0200
Greg Kroah-Hartman wrote:
> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> > I see multiple instances of:
> >
> > arch/powerpc/kernel/exceptions-64s.S:839: Error:
> > attempt to move .org backwards
> >
> > in v4.4.y.queue
On Wed 2019-05-08 00:54:51, Michael Ellerman wrote:
> Hi folks,
>
> Just an FYI in case anyone else is seeing crashes very early in boot in
> linux-next with the above config options.
>
> The problem is the combination of some new code called via printk(),
> check_pointer() which calls
Le 08/05/2019 à 03:30, Michael Neuling a écrit :
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined reference
to `dawr_force_enable'
This was caused by this recent patch:
commit
* Dave Hansen wrote:
> Reported-by: Richard Biener
> Reported-by: H.J. Lu
> Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
> Cc: Yang Shi
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Cc: Andy Lutomirski
> Cc: x...@kernel.org
> Cc: Andrew Morton
> Cc:
On 09.05.19 01:08, osalvador wrote:
> On Wed, 2019-05-08 at 09:39 +0200, David Hildenbrand wrote:
>> However I haven't really thought it through yet, smalles like that
>> could
>> as well just be handled by the caller of
>> arch_add_memory()/arch_remove_memory() eventually, passing it via
>>
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> I see multiple instances of:
>
> arch/powerpc/kernel/exceptions-64s.S:839: Error:
> attempt to move .org backwards
>
> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>
> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add
Satheesh,
>> Xive(both ic-mode=dual and ic-mode=xive) guest fails to boot with
>> guest memory > 64G, till 64G it boots fine.
>>
>> Note: xics(ic-mode=xics) guest with the same configuration boots fine
>
> Indeed. The guest hangs because IPIs are not correctly received. The guest
> sees the
> On 09-May-2019, at 4:53 AM, Roman Gushchin wrote:
>
> On Wed, May 08, 2019 at 03:06:30PM +0530, Sachin Sant wrote:
>> While running LTP tests(specifically ptrace01) following WARNING is observed
>> on POWER8 LPAR running next-20190507 built using 4K page size.
>>
>> [ 3969.979492] msgrcv04
59 matches
Mail list logo
