On 11/07/2013 11:49 PM, H. Peter Anvin wrote:
On 11/07/2013 02:15 PM, Ard Biesheuvel wrote:
That would involve repurposing/generalizing a bit more of the existing
x86-only code than I did the first time around, but if you (as x86
maintainers) are happy with that, I'm all for it.
I do h
s this. Our particular
>> implementation of the loader (on an embedded system) tries to set it
>> on the first mmap invocation, and stops trying if it fails. Not the
>> most elegant approach, I know ...
>
> Actually, that seems easiest.
>
> Has there been any more
mainly intended for the dynamic linker,
which sets up the address space on behalf of
dynamic binaries. By using this flag, it can
prevent exploited code from remapping read-only
executable code or data sections read-write.
Signed-off-by: Ard Biesheuvel
---
arch/alpha/include/asm/mman.h |1
2012/10/4 Kees Cook :
> On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton
> wrote:
>> Again: has this proposal been reviewed by the glibc maintainers? If
>> so, what was their position on it?
>
> Ard have you talked with them? I would expect it would be welcomed.
> Rolan
own code and constant data, as
understanding those would greatly help in designing the ways userland
should be able to have control over this.
Regards,
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
the implementation of the policy potentially
much simpler than that of PaX MPROTECT (but not necessarily as
secure).
However, let's decide first whether there is a point to having some
control over the VM_MAY* flags directly. If yes, then the patch makes
sense, otherwise it doesn't. How p
d Command Shared Object Symbol
> # . ...
> #
> 0.00% unwindme unwindme [.] bar
> |
> --- bar
>
I get exactly the same results, just bar and nothing below.
--
Ard.
--
To unsubscribe from this
argc=2) at
perf.c:376
#21 run_argv (argv=0xbefff4a8, argcp=0xbefff4ac) at perf.c:420
#22 main (argc=2, argv=0xbefff6c8) at perf.c:521
--
Ard.
>>
>> E.g. the following stupid program (built with -O0 -g):
>>
>> --->8
>>
>> void bar(void)
&
On 4 September 2013 20:04, Jean Pihet wrote:
> From: Will Deacon
>
> This patch implements the functions required for the perf refs API,
'regs API' not 'refs API'
Regards,
Ard.
> allowing the perf tool to interface kernel register dumps with libunwind
to Ubuntu Saucy's libunwind8
on a Ubuntu Raring system (Calxeda Highbank)
FWIW, for the series
Tested-by: Ard Biesheuvel # on
ARM/Highbank/UbuntuSaucy
--
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
is further, I'm curious if anyone else has run into
> this.
>
Cheers,
Ard.
> josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2012/10/6 PaX Team :
> sadly, this is not true at all, for multiple reasons:
>
.. snip ...
>
> cheers,
> PaX Team
>
So can I summarize your position as that there is no merit at all in
the ability to inhibit future permissions of existing mappings?
--
Ard.
--
To unsubscr
corruption is
high while the likelihood of immediate detection is low, e.g., when
using the NEON unit in kernel mode on arm64.
Signed-off-by: Ard Biesheuvel
---
include/linux/preempt.h | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/linux
mainly intended for the dynamic linker,
which sets up the address space on behalf of
dynamic binaries. By using this flag, it can
prevent exploited code from remapping read-only
executable code or data sections read-write.
Signed-off-by: Ard Biesheuvel
---
arch/powerpc/include/asm/mman.h |3
flag is
> available, though.
>
I am open for suggestions to address this. Our particular
implementation of the loader (on an embedded system) tries to set it
on the first mmap invocation, and stops trying if it fails. Not the
most elegant approach, I know ...
--
Ard.
> -K
On 22 July 2016 at 13:38, Robert Richter wrote:
> On 29.06.16 15:56:50, Ard Biesheuvel wrote:
>> On 29 June 2016 at 15:34, Christopher Covington wrote:
>> > Hi Tomasz,
>> >
>> > On 06/29/2016 06:48 AM, Tomasz Nowicki wrote:
>> >> On 28.06.2016 18
contained the bridge
> resources? Then you'd have some driver ugliness to find that device,
> but at least the ACPI core could tell what resources were in use.
>
> Maybe Rafael has a better idea?
>
In the discussions leading up to this, we tried very hard to make this
arm64/acpi quirks mechanism just as flexible as we need it to be to
cover the current crop of incompatible hardware, but not more so.
Going forward, we intend to require all arm64/acpi hardware to be spec
compliant, and so any parametrization beyond what is required for the
currently known broken hardware is only going to make it easier for
others to ship with tweaked ACPI descriptions so that an existing
quirk is triggered for hardware that it was not intended for. It also
implies that we have to deal with the ACPI descriptions as they were
shipped with the current hardware.
That does not mean, of course, that we should use bare constants
rather than symbolic ones, but anything beyond that exceeds the
desired scope of quirks handling.
--
Ard.
On 20 September 2016 at 15:05, Bjorn Helgaas wrote:
> Hi Ard,
>
> On Tue, Sep 20, 2016 at 02:40:13PM +0100, Ard Biesheuvel wrote:
>> On 20 September 2016 at 14:33, Bjorn Helgaas wrote:
>> > [+cc Rafael (maybe already cc'd; I didn't recognize raf...@kernel.org, D
At the request of Matt, I am taking up co-maintainership of the EFI
subsystem. So add my name to the EFI section in MAINTAINERS, and
change the SCM tree reference to point to the new shared Git repo.
Cc: Matt Fleming
Signed-off-by: Ard Biesheuvel
---
MAINTAINERS | 3 ++-
1 file changed, 2
Since I will be co-maintaining the EFI subsystem, it makes sense to
mention the ARM and arm64 EFI bits in the EFI section in MAINTAINERS
so that Matt, the list and I get cc'ed on proposed changes.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Russell King
Signed-off-by: Ard Biesh
great to have testing as early as possible.
>
> Yes, the existing one is also part of linux-next once it gets merged
> into tip. The issue has been that I didn't send pull requests to tip
> frequently enough for that to happen on a regular basis.
>
> Ard has already mention
dma_map_page() to the .init hook, and set the streaming DMA
mask based on the MMU subdev parameters before performing the call.
Signed-off-by: Ard Biesheuvel
---
I am sure there is a much better way to address this, but this fixes the
problem I get on AMD Seattle with a GeForce 210 PCIe card
On 20 June 2016 at 19:16, Lorenzo Pieralisi wrote:
> [+ Ard, Arnd]
>
> On Wed, Jun 15, 2016 at 11:34:10AM -0400, Christopher Covington wrote:
>> From: Tomasz Nowicki
>>
>> Some platforms may not be fully compliant with the generic PCI config
>> operations. For
dma_map_page() to the .init hook, and set the streaming DMA
mask based on the MMU subdev parameters before performing the call.
Signed-off-by: Ard Biesheuvel
---
I am sure there is a much better way to address this, but this fixes the
problem I get on AMD Seattle with a GeForce 210 PCIe card
dma_map_page() to the .init hook, which executes after the
DMA mask has been set.
Signed-off-by: Ard Biesheuvel
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 30 +---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
b
incorrect comparison of dma_addr_t type var against NULL
Ard Biesheuvel (3):
drm/nouveau: set streaming DMA mask early
drm/nouveau/fb/gf100: defer DMA mapping of scratch page to init() hook
drm/nouveau/fb/nv50: defer DMA mapping of scratch page to init() hook
drivers/gpu/drm/nouveau/nouv
RAM is above 4 GB).
So set a preliminary DMA mask right after constructing the PCI device, and
base it on the .dma_bits member of the MMU subdevice, which is what the TTM
layer will base the DMA mask on as well.
Signed-off-by: Ard Biesheuvel
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 11
dma_map_page() to the .init hook, which executes after the
DMA mask has been set.
Signed-off-by: Ard Biesheuvel
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 26 ++--
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c
dt_virt_base, SWAPPER_BLOCK_SIZE, prot);
- if (fdt_check_header(dt_virt) != 0)
+ if (fdt_magic(dt_virt) != FDT_MAGIC)
return NULL;
*size = fdt_totalsize(dt_virt);
We are simply looking for a size field. The OF code will call
fdt_check_header() again, so anything that is checked there in
addition to the magic field will still be checked.
--
Ard.
anic...
>
> I have also researched the similar function in other architectures, and
> there if(walk.nbytes) is used, not this if(nbytes) statement in the armv8.
> so I think this armv8 function ctr_encrypt() should deal with the page
> allocation failed situation.
>
OK, thanks for the report, and for the analysis. I will investigate,
and propose a fix
Thanks,
Ard.
On 13 September 2016 at 07:43, Herbert Xu wrote:
> On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote:
>>
>> So to me, it seems like we should be taking the blkcipher_next_slow()
>> path, which does a kmalloc() and bails with -ENOMEM if that fails.
>
> Inde
t for developer discipline anyway (although I should have
spoken up when that was first introduced) Or am I missing something
here?
--
Ard.
> Cc: Mark Rutland
> Cc: Andre Przywara
> Cc: Will Deacon
> Cc: Catalin Marinas
> Signed-off-by: Suzuki K Poulose
> ---
> arch/arm
On 26 August 2016 at 17:16, Will Deacon wrote:
> On Fri, Aug 26, 2016 at 02:08:01PM +0100, Suzuki K Poulose wrote:
>> On 26/08/16 14:04, Suzuki K Poulose wrote:
>> >On 26/08/16 12:03, Ard Biesheuvel wrote:
>> >>IMO, this is a pattern that we should avoid: you are int
(+ Mark, Will)
On 15 August 2017 at 22:46, Andy Lutomirski wrote:
> On Tue, Aug 15, 2017 at 12:18 PM, Sai Praneeth Prakhya
> wrote:
>> +/*
>> + * Makes the calling kernel thread switch to/from efi_mm context
>> + * Can be used from SetVirtualAddressMap() or during efi runtime calls
>> + * (Note:
Hi Sergey,
Thanks for taking a look
On 18 August 2017 at 06:56, Sergey Senozhatsky
wrote:
> On (08/14/17 11:52), Ard Biesheuvel wrote:
>> This adds support for emitting special sections such as initcall arrays,
>> PCI fixups and tracepoints as relative references rathe
On 18 August 2017 at 07:29, Sergey Senozhatsky
wrote:
> Hi Ard,
>
> On (08/18/17 07:12), Ard Biesheuvel wrote:
>> Hi Sergey,
>>
>> Thanks for taking a look
>>
>> On 18 August 2017 at 06:56, Sergey Senozhatsky
>> wrote:
>> > On (08/14/17 11:
On 18 August 2017 at 09:26, Ingo Molnar wrote:
>
> * Ard Biesheuvel wrote:
>
>> -static void for_each_tracepoint_range(struct tracepoint * const *begin,
>> - struct tracepoint * const *end,
>> +static void for_each_tracepoint_range(const v
On 18 August 2017 at 09:36, Ard Biesheuvel wrote:
> On 18 August 2017 at 09:26, Ingo Molnar wrote:
>>
>> * Ard Biesheuvel wrote:
>>
>>> -static void for_each_tracepoint_range(struct tracepoint * const *begin,
>>> - struct tr
be able to support and benefit
from it.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Signed-o
Signed-off-by: Ard Biesheuvel
---
include/linux/init.h | 64
init/main.c| 22 ++-
kernel/printk/printk.c | 4 +-
security/security.c| 6 +-
4 files changed, 62 insertions(+), 34 deletions(-)
diff --git a/include/linux/init.h b/include/linux/init.h
ind
: Kees Cook
Cc: Thomas Garnier
Cc: Nicolas Pitre
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/Kbuild | 1 +
arch/x86/include/asm/export.h | 4 --
include/asm-generic/export.h | 12 +++-
include/linux/compiler.h | 11
include/linux/export.h| 68
Allow the PCI quirk tables to be emitted in a way that avoids absolute
references to the hook functions. This reduces the size of the entries,
and, more importantly, makes them invariant under runtime relocation
(e.g., for KASLR)
Cc: Bjorn Helgaas
Signed-off-by: Ard Biesheuvel
---
drivers/pci
: Ard Biesheuvel
---
include/linux/tracepoint.h | 42 ++--
kernel/tracepoint.c| 7 +---
2 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index a26ffbe09e71..68701821933a 100644
--- a/include/linux
Before modifying the initcall() code to add support for relative
references in the initcall sections, fix the existing code that
lacks the required trailing semicolon so we can remove it from the
macros.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/kernel/perf_event.c | 2 +-
arch
dt
Cc: Martin Schwidefsky
Cc: Sergey Senozhatsky
Cc: Linus Torvalds
Cc: Andy Whitcroft
Cc: Jessica Yu
Ard Biesheuvel (6):
arch: enable relative relocations for arm64, power, x86, s390 and x86
module: use relative references for __ksymtab entries
treewide: add missing trailing semicolon
On 19 June 2017 at 17:03, Will Deacon wrote:
> On Mon, Jun 19, 2017 at 04:37:24PM +0200, Ard Biesheuvel wrote:
>> On arm64, the /dev/kmem driver barely works, given that it assumes that
>> VMALLOC_START > PAGE_OFFSET, which is not the case on arm64. Due to the
>
> Proba
erface entirely for arm64.
Signed-off-by: Ard Biesheuvel
---
v3: improve commit log
v2: disable /dev/kmem entirely rather than bandaiding it
drivers/char/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 31adbebf812e..8102ee7b3247 1
> - use proper markups for titles;
> - identify literal blocks.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Ard Biesheuvel
> ---
> Documentation/efi-stub.txt | 25 +++--
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --gi
On 20 June 2017 at 08:59, Ard Biesheuvel wrote:
> As it turns out, arm64 deviates from other architectures in the way it
> maps the VMALLOC region: on most (all?) other architectures, it resides
> strictly above the kernel's direct mapping of DRAM, but on arm64, this
> is the
On 20 June 2017 at 22:14, Daniel Kiper wrote:
> Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.
>
> In theory we can check EFI_PARAVIRT too, however,
> EFI_MEMMAP looks more generic and covers more cases.
>
> Signed-off-by: Daniel Kiper
Reviewed-by: Ard Biesheuvel
a few times until now. So, let's initialize only efi struct members used by
> Xen to avoid such issues in the future.
>
> Signed-off-by: Daniel Kiper
Acked-by: Ard Biesheuvel
> ---
> arch/x86/xen/efi.c | 45 -
> 1 file chan
is_hash_blacklisted(). This would typically be the case for a signed
> X.509 message.
>
This last part seems a premature optimization to me. Is there a
performance concern preventing us from using (4) only?
In any case, the approach and the code look sound to me, althoug
On 21 June 2017 at 14:49, David Howells wrote:
> Ard Biesheuvel wrote:
>
>> > This can be told to skip a particular algorithm for when the caller
>> > has one precalculated. The precalculated hash can be passed to
>> > is_hash_blacklisted(). Thi
On 16 October 2017 at 12:42, Liuwenliang (Lamb) wrote:
> On 10/16/2017 07:03 PM, Abbott Liu wrote:
>>arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support
>>`movw r1,
>
> #:lower16:0xC000-0x0100)>>3)+((0xC000-0x0100)-(1<<29'
> in ARM mode
>>arch/
On 17 October 2017 at 08:27, Jean Delvare wrote:
> Hi Ard,
>
> On Thu, 12 Oct 2017 20:59:37 +0100, Ard Biesheuvel wrote:
>> Currently, when booting a kernel with DMI support on a platform that has
>> no DMI tables, the following output is emitted into the kernel log:
>&
On 17 October 2017 at 10:29, Mark Rutland wrote:
> On Tue, Oct 17, 2017 at 08:30:54AM +0800, Leo Yan wrote:
>> On Mon, Oct 16, 2017 at 03:35:46PM +0100, Robin Murphy wrote:
>> > On 16/10/17 15:26, Mark Rutland wrote:
>> > > On Mon, Oct 16, 2017 at 03:12:45PM +0100, Robin Murphy wrote:
>> > >> On 1
On 17 October 2017 at 10:36, Leo Yan wrote:
> On Tue, Oct 17, 2017 at 10:32:21AM +0100, Ard Biesheuvel wrote:
>
> [...]
>
>> > AFAICT, erratum 836870 results in livelock rather than memory
>> > corruption, so I think we can ignore that.
>> >
>>
On 17 October 2017 at 12:27, Liuwenliang (Lamb) wrote:
> On 10/17/2017 12:40 AM, Abbott Liu wrote:
>> Ard Biesheuvel [ard.biesheu...@linaro.org] wrote
>>This is unnecessary:
>>
>>ldr r1, =TASK_SIZE
>>
>>will be converted to a mov instruction by the assemble
.
The first one is a pr_info(), but the subsequent ones are pr_err()s that
complain about a condition that is not really an error to begin with.
So let's clean this up, and give up silently if dma_available is not set.
Signed-off-by: Ard Biesheuvel
---
v2: - don't use dmi_available in
emap() being used on normal memory.
>
> Signed-off-by: Roy Franz
Acked-by: Ard Biesheuvel
> ---
> Tested on arm64 simulation, using simulator to preload filesystem image into
> RAM,
> and also tested on x86_64 using video card memory. This is useful for
> speeding
>
On 30 May 2017 at 07:10, AKASHI Takahiro wrote:
> Hi David,
>
> Struct mz_hdr in include/linux/pe.h contains a message[] field.
> Should it be part of this structure?
> (I googled "MZ format," but didn't find out the exact definition.)
>
MZ format does not exist. It is the magic number of the DOS
s for highlighting this. I agree that this should be addressed
asap, given that this code has not appeared in a release yet (it was
added this cycle)
Perhaps redundantly, I'd like to emphasize that this is really not a
UEFI specific issue, it applies to any application of X.509 that does
not restrict the set of permitted hash algorithms to a single one.
Regards,
Ard.
reaks the build on non-x86. Please build test EFI-related
patches on arm64 and/or ARM before submitting patches. And if
possible, could we find a magic SysRq key that works on all
architectures? I know we discussed this at some point (I think?) but I
don't remember the conclusion.
Regard
On 31 October 2017 at 12:47, Russell King - ARM Linux
wrote:
> On Mon, Oct 30, 2017 at 04:38:17PM +, Russell King - ARM Linux wrote:
>> On Mon, Oct 30, 2017 at 05:24:34PM +0100, Gregory CLEMENT wrote:
>> > Hi Russell King,
>> >
>> > Here you will find all the objects included the vmlinux:
>> >
On 31 October 2017 at 13:22, Gregory CLEMENT
wrote:
> Hi Ard,
>
> On mar., oct. 31 2017, Ard Biesheuvel wrote:
>
>> On 31 October 2017 at 12:47, Russell King - ARM Linux
>> wrote:
>>> On Mon, Oct 30, 2017 at 04:38:17PM +, Russell King - ARM Linux wrote:
&
On 1 November 2017 at 18:00, Russell King - ARM Linux
wrote:
> On Wed, Nov 01, 2017 at 03:57:36PM +0000, Ard Biesheuvel wrote:
>> On 31 October 2017 at 13:22, Gregory CLEMENT
>> wrote:
>> > Hi Ard,
>> >
>> > On mar., oct. 31 2017, Ard Biesheuvel wro
On 1 November 2017 at 18:11, Russell King - ARM Linux
wrote:
> On Wed, Nov 01, 2017 at 06:02:24PM +0000, Ard Biesheuvel wrote:
>> On 1 November 2017 at 18:00, Russell King - ARM Linux
>> wrote:
>> > On Wed, Nov 01, 2017 at 03:57:36PM +, Ard Biesheuvel wrote:
>>
On 24 October 2017 at 10:09, Russell King - ARM Linux
wrote:
> On Tue, Oct 24, 2017 at 09:09:52AM +0100, Ard Biesheuvel wrote:
>> The following patch appears to fix the issue as well:
>>
>> diff --git a/arch/arm/boot/compressed/vmlinux.lds.S
>> b/arch/arm/boot/compre
On 24 October 2017 at 10:22, Russell King - ARM Linux
wrote:
> On Tue, Oct 24, 2017 at 10:13:09AM +0100, Ard Biesheuvel wrote:
>> On 24 October 2017 at 10:09, Russell King - ARM Linux
>> wrote:
>> > The question is: do we want to know when additional sections get
>
On 24 October 2017 at 10:26, Ard Biesheuvel wrote:
> On 24 October 2017 at 10:22, Russell King - ARM Linux
> wrote:
>> On Tue, Oct 24, 2017 at 10:13:09AM +0100, Ard Biesheuvel wrote:
>>> On 24 October 2017 at 10:09, Russell King - ARM Linux
>>> wrote:
>>>
On 24 October 2017 at 10:38, Russell King - ARM Linux
wrote:
> On Tue, Oct 24, 2017 at 10:30:41AM +0100, Ard Biesheuvel wrote:
>> On 24 October 2017 at 10:26, Ard Biesheuvel
>> wrote:
>> > On 24 October 2017 at 10:22, Russell King - ARM Linux
>> > wrote:
&g
On 24 October 2017 at 10:54, Russell King - ARM Linux
wrote:
> On Tue, Oct 24, 2017 at 10:44:00AM +0100, Ard Biesheuvel wrote:
>> On 24 October 2017 at 10:38, Russell King - ARM Linux
>> wrote:
>> > Do you have any preference - I'd prefer one that I can merge along
ION=y.
Cc: James Morse
Cc: Matt Fleming
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/libstub/arm-stub.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/arm-stub.c
b/drivers/firmware/efi/libstub/arm-stub.c
index 1cb2d1c070c3..a94601d
avoid crashing on UEFI runtime services invocations after resume from
hibernation on ARM
----
Ard Biesheuvel (1):
efi/libstub: arm: don't randomize runtime regions when
CONFIG_HIBERNATION=y
Dan Carpenter (1):
ef
ing UEFI runtime
service interfaces")
Signed-off-by: Dan Carpenter
Acked-by: Ivan Hu
Cc: Ard Biesheuvel
Signed-off-by: Matt Fleming
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/test/efi_test.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/efi/test/efi_
string fix
Ard Biesheuvel (1):
arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set
Arvind Yadav (1):
efi/capsule-loader: pr_err() strings should end with newlines
arch/arm64/kernel/efi.c | 4
pt to execute)
Reported-by: Stephen Boyd
Tested-by: Stephen Boyd
Cc: Matt Fleming
Signed-off-by: Ard Biesheuvel
---
arch/arm64/kernel/efi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 82cd07592519..f85ac58d08a3 100644
From: Arvind Yadav
pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.
Signed-off-by: Arvind Yadav
Cc: Ard Biesheuvel
Cc: Jan Kiszka
Cc: Kweh Hock Leong
Signed-off-by: Matt Fleming
Signed-off-by: Ard Biesheuvel
---
drivers/firmware
On 26 October 2017 at 21:29, Nick Desaulniers wrote:
> Upon upgrading to binutils 2.27, we found that our lz4 compressed kernel
> images were significantly larger, resulting is 10ms boot time regressions.
>
> As noted by Rahul:
> "aarch64 binaries uses RELA relocations, where each relocation entry
On 13 November 2017 at 15:40, Andreas Färber wrote:
> Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
>> On 6 November 2017 at 06:58, Andreas Färber wrote:
>>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>> [...]
>>>>
>>>> Again, I am not
err = PTR_ERR(data->base);
> + if (!data->base) {
> + err = -ENODEV;
> goto out_free;
> }
>
I was going to blame Marc's Tegra code for this, because that is where
I copied most of the code from, but the bug doesn't exist there, and
so it appears to be an original work. Oops.
Acked-by: Ard Biesheuvel
> On 3 Nov 2017, at 13:42, Will Deacon wrote:
>
> Hi Jason,
>
> [+Ard]
>
>> On Thu, Nov 02, 2017 at 06:43:22PM +0100, Jason A. Donenfeld wrote:
>> Versions of gcc prior to gcc 5 emitted a __multi3 function call when
>> dealing with TI types, resultin
On 3 November 2017 at 17:12, Sami Tolvanen wrote:
> CONFIG_CLANG_LTO depends on GNU gold and due to a known bug, the
> linker crashes when ARM64_MODULE_PLTS is enabled:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=14592
>
> To work around the problem, this change:
>
> 1) Enables ARM64_M
On 3 November 2017 at 17:11, Sami Tolvanen wrote:
> With CONFIG_CLANG_LTO, we produce LLVM IR instead of object files. Since LTO
> is not really needed here and the Makefile assumes we produce an object file,
> disable LTO for libstub.
>
> Signed-off-by: Sami Tolvanen
Acked-by:
On 3 November 2017 at 17:12, Sami Tolvanen wrote:
> CONFIG_CLANG_LTO requires the use of clang's integrated assembler, which
> doesn't understand the inline assembly in aes-ce-cipher.c. Disable LTO for
> the file to work around the issue.
>
> Signed-off-by: Sami
On 3 November 2017 at 17:11, Sami Tolvanen wrote:
> CONFIG_CLANG_LTO depends on GNU gold, which can generate ADR_PREL_PG_HI21
> relocations even with --fix-cortex-a53-843419.
>
> Since ARM64_ERRATUM_843419 disables kernel support for these relocations,
> disable the erratum when LTO is used.
>
I
On 3 November 2017 at 19:26, Mark Rutland wrote:
> On Fri, Nov 03, 2017 at 11:11:45AM -0700, Nick Desaulniers wrote:
>> On Fri, Nov 3, 2017 at 11:09 AM, Mark Rutland wrote:
>> ently compile
>> > What's the minimum set of patches necessary to work with clang (ignoring
>> > LTO)?
>>
>> If you have
On 4 November 2017 at 13:44, Andreas Färber wrote:
> Hi everyone,
>
> The non-building clk driver has been removed for 4.14, but this patchset
> seems stuck on matters of naming and maintenance...
>
> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>> Hi Andreas,
>>
>> 2017-06-29 21:53 GMT+09:00 A
On 4 November 2017 at 15:30, Andreas Färber wrote:
> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>> On 4 November 2017 at 13:44, Andreas Färber wrote:
>>> Hi everyone,
>>>
>>> The non-building clk driver has been removed for 4.14, but this patchset
>
On 4 November 2017 at 20:06, Andreas Färber wrote:
> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>> On 4 November 2017 at 15:30, Andreas Färber wrote:
>>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel:
>>>> On 4 November 2017 at 13:44, Andreas Färber wrote:
>
On 6 November 2017 at 06:58, Andreas Färber wrote:
> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
[...]
>>
>> Again, I am not the one who is ranting here. You hit a nerve by
>> accusing me of 'rebelling against linux.git' while this is quite the
>> opposite
On 6 November 2017 at 16:51, Jason A. Donenfeld wrote:
> Wait, please don't jump to that decision so quickly.
>
> Are you sure the fail is for v4? Will mentioned this with v1, which is whay
> this current v4 is supposed to fix up.
>
It appears your v4 adds __ashlti3() and __ashrti3, whereas the e
Even though calling dql_completed() with a count that exceeds the
queued count is a serious error, it still does not justify bringing
down the entire kernel with a BUG_ON(). So relax it to a WARN_ON()
instead.
Signed-off-by: Ard Biesheuvel
---
lib/dynamic_queue_limits.c | 2 +-
1 file changed
On 18 October 2017 at 17:29, Eric Dumazet wrote:
> On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote:
>> Even though calling dql_completed() with a count that exceeds the
>> queued count is a serious error, it still does not justify bringing
>> down the entire kerne
On 18 October 2017 at 19:45, Eric Dumazet wrote:
> On Wed, 2017-10-18 at 18:57 +0100, Ard Biesheuvel wrote:
>> On 18 October 2017 at 17:29, Eric Dumazet wrote:
>> > On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote:
>> >> Even though calling dql_completed()
On 19 October 2017 at 11:57, David Miller wrote:
> From: Ard Biesheuvel
> Date: Wed, 18 Oct 2017 16:45:15 +0100
>
>> Even though calling dql_completed() with a count that exceeds the
>> queued count is a serious error, it still does not justify bringing
>> down the
On 19 October 2017 at 20:40, Sam Protsenko wrote:
> HugePages support is enabled on ARM64 and x86. On ARM32 we have support
> for HugePages since kernel 3.11 [1]. Let's enable it on ARM32 too, as
> it's needed for some projects like DPDK [2], LTP [3], etc. The similar
> change was done in commit 7
be able to get better results from the
> longer runs of zeros, not just GZIP and LZ4.
>
> 10ms boot time savings isn't anything to get excited about, but users of
> arm64+compression+bfd-2.27 should not have to pay a boot time penalty for no
> runtime improvement.
>
> Reported
On 30 October 2017 at 13:08, Will Deacon wrote:
> On Fri, Oct 27, 2017 at 09:33:41AM -0700, Nick Desaulniers wrote:
>> Upon upgrading to binutils 2.27, we found that our lz4 and gzip
>> compressed kernel images were significantly larger, resulting is 10ms
>> boot time regressions.
>>
>> As noted b
On 30 October 2017 at 13:12, Will Deacon wrote:
> On Mon, Oct 30, 2017 at 01:11:23PM +0000, Ard Biesheuvel wrote:
>> On 30 October 2017 at 13:08, Will Deacon wrote:
>> > On Fri, Oct 27, 2017 at 09:33:41AM -0700, Nick Desaulniers wrote:
>> >> Upon upgrading to binuti
1 - 100 of 2935 matches
Mail list logo
