Sergey Senozhatsky writes:
> 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
Otherwise, the following warning is encountered:
WARNING: vmlinux.o(.text+0x3dc6): Section mismatch in reference from the
variable start_here_multiplatform to the function .init.text:.early_setup()
The function start_here_multiplatform() references
the function __init .early_setup().
This is ofte
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 chan
[ 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 ha
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 dereference_function_descrip
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 probe_kernel_read().
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" defi
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 sh
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 qual
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 fe
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 LPAR
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 unchanged
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 da
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()
> and
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 we
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 abo
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 memor
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 a
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: [bbfcac5ff
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 caus
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(),
>> check_poi
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
>arch
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 comm
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 instances
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 probe_kernel_read(
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 memor
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
>arch
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:
> >>>
> >>> arch/
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 v4.4.y
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 ac
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
---
arch/power
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
>arch
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 memor
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 Hildenbran
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. Let'
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
arch/powerpc/mm/hash_low_32.S,
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 in
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 _mcoun
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
--- a/arch/powerpc/mm/book3s32/
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||christophe.le
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 (v4.4.179-143-gc4
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 probe_kerne
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 c1fe1
* 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: linux-ker...@
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
>> someth
58 matches
Mail list logo