On Fri, 22 Jun 2018 13:18:38 +0200 osalva...@techadventures.net wrote:
> From: Oscar Salvador
>
> link_mem_sections() and walk_memory_range() share most of the code,
> so we can use convert link_mem_sections() into a dummy function that calls
> walk_memory_range() with a callback to
On Fri, 22 Jun 2018 13:18:38 +0200 osalva...@techadventures.net wrote:
> From: Oscar Salvador
>
> link_mem_sections() and walk_memory_range() share most of the code,
> so we can use convert link_mem_sections() into a dummy function that calls
> walk_memory_range() with a callback to
On Wed, 15 Aug 2018 13:18:17 +0800, Ryder Lee wrote:
> Update binding document for bananapi BPI-R64 board being supported.
>
> Signed-off-by: Ryder Lee
> ---
> Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
Reviewed-by: Rob Herring
On Wed, 15 Aug 2018 13:18:17 +0800, Ryder Lee wrote:
> Update binding document for bananapi BPI-R64 board being supported.
>
> Signed-off-by: Ryder Lee
> ---
> Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
Reviewed-by: Rob Herring
On Tue, 12 Jun 2018 14:26:24 +0200 Vlastimil Babka wrote:
> The __alloc_pages_slowpath() function has for a long time contained code to
> ignore node restrictions from memory policies for high priority allocations.
> The current code that resets the zonelist iterator however does effectively
>
On Tue, 12 Jun 2018 14:26:24 +0200 Vlastimil Babka wrote:
> The __alloc_pages_slowpath() function has for a long time contained code to
> ignore node restrictions from memory policies for high priority allocations.
> The current code that resets the zonelist iterator however does effectively
>
On 15.08.2018 23:57, Vivek Goyal wrote:
> Aha.., so that's your real problem. You are trying to load VirtualBox
> module and that will not load even if you take ownership of platform
> by adding your key and sign module with that key.
>
> So this patch still will not fix the problem you are
On 15.08.2018 23:57, Vivek Goyal wrote:
> Aha.., so that's your real problem. You are trying to load VirtualBox
> module and that will not load even if you take ownership of platform
> by adding your key and sign module with that key.
>
> So this patch still will not fix the problem you are
On Wed, Aug 15, 2018 at 01:11:21PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 15, 2018 at 11:58:46AM +0200, Takashi Iwai wrote:
> > The 4.4.y stable backport dc6ae4dffd65 for the upstream commit
> > 3d4bf93ac120 ("tcp: detect malicious patterns in
> > tcp_collapse_ofo_queue()") missed a line
On Wed, Aug 15, 2018 at 01:11:21PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 15, 2018 at 11:58:46AM +0200, Takashi Iwai wrote:
> > The 4.4.y stable backport dc6ae4dffd65 for the upstream commit
> > 3d4bf93ac120 ("tcp: detect malicious patterns in
> > tcp_collapse_ofo_queue()") missed a line
Signed-off-by: Yannik Sembritzki
---
arch/x86/kernel/kexec-bzimage64.c | 2 +-
certs/system_keyring.c | 3 ++-
crypto/asymmetric_keys/pkcs7_key_type.c | 2 +-
include/linux/verification.h | 3 +++
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git
Signed-off-by: Yannik Sembritzki
---
arch/x86/kernel/kexec-bzimage64.c | 2 +-
certs/system_keyring.c | 3 ++-
crypto/asymmetric_keys/pkcs7_key_type.c | 2 +-
include/linux/verification.h | 3 +++
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git
On Wed, Aug 15, 2018 at 2:19 PM Yannik Sembritzki wrote:
>
>
> +// Allow both builtin trusted keys and secondary trusted keys
> +#ifndef TRUST_SECONDARY_KEYRING
> +#define TRUST_SECONDARY_KEYRING ((struct key *)1UL)
> +#endif
>
> Sorry, I've fixed this now.
Actually, just remove the ifndef/endif
On Wed, Aug 15, 2018 at 2:19 PM Yannik Sembritzki wrote:
>
>
> +// Allow both builtin trusted keys and secondary trusted keys
> +#ifndef TRUST_SECONDARY_KEYRING
> +#define TRUST_SECONDARY_KEYRING ((struct key *)1UL)
> +#endif
>
> Sorry, I've fixed this now.
Actually, just remove the ifndef/endif
On Wed, 15 Aug 2018 16:42:18 +0200 Oscar Salvador
wrote:
> From: Oscar Salvador
>
> unregister_mem_sect_under_nodes() tries to allocate a nodemask_t
> in order to check whithin the loop which nodes have already been unlinked,
> so we do not repeat the operation on them.
>
> NODEMASK_ALLOC
On Wed, 15 Aug 2018 16:42:18 +0200 Oscar Salvador
wrote:
> From: Oscar Salvador
>
> unregister_mem_sect_under_nodes() tries to allocate a nodemask_t
> in order to check whithin the loop which nodes have already been unlinked,
> so we do not repeat the operation on them.
>
> NODEMASK_ALLOC
From: Andi Kleen
The stable backport of the
x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings
patch for 4.4 and 4.9 put new C code for !__HAVE_ARCH_PFN_MODIFY_ALLOWED
code outside the assembler ifdef. This breaks the xtensa and ia64
build as reported by 0day which
From: Andi Kleen
The stable backport of the
x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings
patch for 4.4 and 4.9 put new C code for !__HAVE_ARCH_PFN_MODIFY_ALLOWED
code outside the assembler ifdef. This breaks the xtensa and ia64
build as reported by 0day which
On Wed, Aug 15, 2018 at 11:31:27PM +0200, Yannik Sembritzki wrote:
> On 15.08.2018 23:13, James Bottomley wrote:
> > Consider a UEFI system for which a user has taken ownership, but which
> > has some signed ROMs which are UEFI secure boot verified. Simply to
> > get their system to boot the user
On Wed, Aug 15, 2018 at 11:31:27PM +0200, Yannik Sembritzki wrote:
> On 15.08.2018 23:13, James Bottomley wrote:
> > Consider a UEFI system for which a user has taken ownership, but which
> > has some signed ROMs which are UEFI secure boot verified. Simply to
> > get their system to boot the user
On Wed, 2018-08-15 at 17:52 -0400, Vivek Goyal wrote:
> On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote:
> > On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> > > On 15.08.2018 22:47, Linus Torvalds wrote:
> > > > It basically says: we don't allow modules that weren't
On Wed, 2018-08-15 at 17:52 -0400, Vivek Goyal wrote:
> On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote:
> > On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> > > On 15.08.2018 22:47, Linus Torvalds wrote:
> > > > It basically says: we don't allow modules that weren't
On 8/15/18 2:09 PM, Matthew Wilcox wrote:
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
(not even compiled, and I can see a good opportunity for combining the
VM_LOCKED loop with the has_uprobes loop)
I was rushing to get that sent earlier. Here it is tidied up to
On 8/15/18 2:09 PM, Matthew Wilcox wrote:
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
(not even compiled, and I can see a good opportunity for combining the
VM_LOCKED loop with the has_uprobes loop)
I was rushing to get that sent earlier. Here it is tidied up to
On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote:
> On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> > On 15.08.2018 22:47, Linus Torvalds wrote:
> > > It basically says: we don't allow modules that weren't built with
> > > the kernel. Adding a new key later and signing
On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote:
> On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> > On 15.08.2018 22:47, Linus Torvalds wrote:
> > > It basically says: we don't allow modules that weren't built with
> > > the kernel. Adding a new key later and signing
On 15.08.2018 23:40, James Bottomley wrote:
> What about the key linking patches:
>
> https://lkml.org/lkml/2018/5/2/989
>
> ? They allow you to insert your own binary key into bzimage and then
> resign the resulting blob for secure boot. It's a fairly painless
> process. The patches have been
On 15.08.2018 23:40, James Bottomley wrote:
> What about the key linking patches:
>
> https://lkml.org/lkml/2018/5/2/989
>
> ? They allow you to insert your own binary key into bzimage and then
> resign the resulting blob for secure boot. It's a fairly painless
> process. The patches have been
(Resent with lkml on copy)
[Note: This isn't meant to be merged, it need splitting at the very
least, see below]
This is something I cooked up quickly today to test if that would fix
my problems with large number of switch and NVME devices on POWER.
So far it does...
The issue (as discussed in
(Resent with lkml on copy)
[Note: This isn't meant to be merged, it need splitting at the very
least, see below]
This is something I cooked up quickly today to test if that would fix
my problems with large number of switch and NVME devices on POWER.
So far it does...
The issue (as discussed in
On Wed, 2018-08-15 at 23:31 +0200, Yannik Sembritzki wrote:
> On 15.08.2018 23:13, James Bottomley wrote:
> > Consider a UEFI system for which a user has taken ownership, but
> > which
> > has some signed ROMs which are UEFI secure boot verified. Simply
> > to
> > get their system to boot the
On Wed, 2018-08-15 at 23:31 +0200, Yannik Sembritzki wrote:
> On 15.08.2018 23:13, James Bottomley wrote:
> > Consider a UEFI system for which a user has taken ownership, but
> > which
> > has some signed ROMs which are UEFI secure boot verified. Simply
> > to
> > get their system to boot the
On 15.08.2018 23:13, James Bottomley wrote:
> Consider a UEFI system for which a user has taken ownership, but which
> has some signed ROMs which are UEFI secure boot verified. Simply to
> get their system to boot the user will be forced to add the ODM key to
> the UEFI db ... and I'm sure in
On 15.08.2018 23:13, James Bottomley wrote:
> Consider a UEFI system for which a user has taken ownership, but which
> has some signed ROMs which are UEFI secure boot verified. Simply to
> get their system to boot the user will be forced to add the ODM key to
> the UEFI db ... and I'm sure in
Hi Yannik,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180814]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Yannik,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180814]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Signed-off-by: Yannik Sembritzki
---
arch/x86/kernel/kexec-bzimage64.c | 2 +-
certs/system_keyring.c | 3 ++-
crypto/asymmetric_keys/pkcs7_key_type.c | 2 +-
include/linux/verification.h | 5 +
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git
Signed-off-by: Yannik Sembritzki
---
arch/x86/kernel/kexec-bzimage64.c | 2 +-
certs/system_keyring.c | 3 ++-
crypto/asymmetric_keys/pkcs7_key_type.c | 2 +-
include/linux/verification.h | 5 +
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git
Thanks for all the clean-up, looks great now!
For the whole series:
Reviewed-by: Julius Werner
Thanks for all the clean-up, looks great now!
For the whole series:
Reviewed-by: Julius Werner
On Wed, Aug 15, 2018 at 2:08 PM Yannik Sembritzki wrote:
>
> IMO, this is not okay. The layer of trust should extend from the bottom
> (user-provisioned platform key) up. Only trusting the kernel builtin key
> later on (wrt. kernel modules) contradicts this principal.
This module loading case is
On Wed, Aug 15, 2018 at 2:08 PM Yannik Sembritzki wrote:
>
> IMO, this is not okay. The layer of trust should extend from the bottom
> (user-provisioned platform key) up. Only trusting the kernel builtin key
> later on (wrt. kernel modules) contradicts this principal.
This module loading case is
On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> On 15.08.2018 22:47, Linus Torvalds wrote:
> > It basically says: we don't allow modules that weren't built with
> > the kernel. Adding a new key later and signing a module with it
> > violates that premise.
>
> Considering the
On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> On 15.08.2018 22:47, Linus Torvalds wrote:
> > It basically says: we don't allow modules that weren't built with
> > the kernel. Adding a new key later and signing a module with it
> > violates that premise.
>
> Considering the
On Fri, Aug 10, 2018 at 11:42:46AM -0700, Joe Perches wrote:
> Consistently use the "QPLIB: " prefix for dev_ logging.
>
> Miscellanea:
>
> o Add missing newlines to avoid possible message interleaving
> o Coalesce consecutive dev_ uses that emit a message header to
> avoid < 80 column lengths
On Fri, Aug 10, 2018 at 11:42:46AM -0700, Joe Perches wrote:
> Consistently use the "QPLIB: " prefix for dev_ logging.
>
> Miscellanea:
>
> o Add missing newlines to avoid possible message interleaving
> o Coalesce consecutive dev_ uses that emit a message header to
> avoid < 80 column lengths
On Wed, Aug 15, 2018 at 10:58 AM Masahiro Yamada
wrote:
>
> Masahiro Yamada (15):
> kconfig: make syncconfig update .config regardless of sym_change_count
This one is annoying me.
I don't care if it updates .config. But it does so *noisily*, so now
my build scripts en dup having extra
On Wed, Aug 15, 2018 at 10:58 AM Masahiro Yamada
wrote:
>
> Masahiro Yamada (15):
> kconfig: make syncconfig update .config regardless of sym_change_count
This one is annoying me.
I don't care if it updates .config. But it does so *noisily*, so now
my build scripts en dup having extra
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
> (not even compiled, and I can see a good opportunity for combining the
> VM_LOCKED loop with the has_uprobes loop)
I was rushing to get that sent earlier. Here it is tidied up to
actually compile.
Note the diffstat:
mmap.c |
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
> (not even compiled, and I can see a good opportunity for combining the
> VM_LOCKED loop with the has_uprobes loop)
I was rushing to get that sent earlier. Here it is tidied up to
actually compile.
Note the diffstat:
mmap.c |
On 15.08.2018 22:47, Linus Torvalds wrote:
> It basically says: we don't allow modules that weren't built with the
> kernel. Adding a new key later and signing a module with it violates
> that premise.
Considering the following scenario:
A user is running a distro kernel, which is built by the
On 15.08.2018 22:47, Linus Torvalds wrote:
> It basically says: we don't allow modules that weren't built with the
> kernel. Adding a new key later and signing a module with it violates
> that premise.
Considering the following scenario:
A user is running a distro kernel, which is built by the
On Mon, Aug 13, 2018 at 06:12:44PM -0700, Joe Perches wrote:
> There is an external use case for multiple private MAINTAINER
> style files in a separate directory. Allow it.
>
> --mpath has a default of "./MAINTAINERS".
>
> The value entered can be either a file or a directory.
>
> The
On Mon, Aug 13, 2018 at 06:12:44PM -0700, Joe Perches wrote:
> There is an external use case for multiple private MAINTAINER
> style files in a separate directory. Allow it.
>
> --mpath has a default of "./MAINTAINERS".
>
> The value entered can be either a file or a directory.
>
> The
On 08/15/2018 12:38 PM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:15 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Implements the VFIO_DEVICE_RESET ioctl. This ioctl zeroizes
all of the AP queues assigned to the guest.
Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
Tested-by:
On 08/15/2018 12:38 PM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:15 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Implements the VFIO_DEVICE_RESET ioctl. This ioctl zeroizes
all of the AP queues assigned to the guest.
Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
Tested-by:
On Wed, Jul 18, 2018 at 4:47 PM, Federico Vaga wrote:
> Hi Alan,
>
> Thanks for your time, comments below
>
> On Wednesday, July 18, 2018 9:47:24 PM CEST Alan Tull wrote:
>> On Thu, Jun 28, 2018 at 2:50 AM, Federico Vaga
> wrote:
>> > On Wednesday, 27 June 2018 23:23:07 CEST Alan Tull wrote:
>>
On Wed, Jul 18, 2018 at 4:47 PM, Federico Vaga wrote:
> Hi Alan,
>
> Thanks for your time, comments below
>
> On Wednesday, July 18, 2018 9:47:24 PM CEST Alan Tull wrote:
>> On Thu, Jun 28, 2018 at 2:50 AM, Federico Vaga
> wrote:
>> > On Wednesday, 27 June 2018 23:23:07 CEST Alan Tull wrote:
>>
On Wed, 2018-08-15 at 13:47 -0700, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 12:49 PM Vivek Goyal
> wrote:
> >
> > I see that module signing code trusts only builtin keys and
> > not the keys in secondary_trusted_keys keyring.
>
> This, I think, makes sense.
>
> It basically says: we
On Wed, 2018-08-15 at 13:47 -0700, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 12:49 PM Vivek Goyal
> wrote:
> >
> > I see that module signing code trusts only builtin keys and
> > not the keys in secondary_trusted_keys keyring.
>
> This, I think, makes sense.
>
> It basically says: we
m64-stable-rc.git
git branch: 4.4.148-rc2-hikey-20180815-258
git commit: f76c67628ea73cd7814850723fd3cf4ec681c404
git describe: 4.4.148-rc2-hikey-20180815-258
Test details:
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.148-rc2-hikey-20180815-258
No regressions (compared
m64-stable-rc.git
git branch: 4.4.148-rc2-hikey-20180815-258
git commit: f76c67628ea73cd7814850723fd3cf4ec681c404
git describe: 4.4.148-rc2-hikey-20180815-258
Test details:
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.148-rc2-hikey-20180815-258
No regressions (compared
On Wed, Aug 15, 2018 at 12:49 PM Vivek Goyal wrote:
>
> I see that module signing code trusts only builtin keys and
> not the keys in secondary_trusted_keys keyring.
This, I think, makes sense.
It basically says: we don't allow modules that weren't built with the
kernel. Adding a new key later
On Wed, Aug 15, 2018 at 12:49 PM Vivek Goyal wrote:
>
> I see that module signing code trusts only builtin keys and
> not the keys in secondary_trusted_keys keyring.
This, I think, makes sense.
It basically says: we don't allow modules that weren't built with the
kernel. Adding a new key later
On Wed, Aug 15, 2018 at 1:22 PM Guenter Roeck wrote:
>
> I have not seen a patch fly by, so here it is.
Applied.
Linus
On Wed, Aug 15, 2018 at 1:22 PM Guenter Roeck wrote:
>
> I have not seen a patch fly by, so here it is.
Applied.
Linus
On Tue, Aug 14, 2018 at 07:16:23PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.120 release.
> There are 107 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Tue, Aug 14, 2018 at 07:16:23PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.120 release.
> There are 107 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Wed, Aug 15, 2018 at 1:33 PM Sebastian Gottschall
wrote:
>
> if it would be helpfull i can do this quick here using the latest
> vanilla tree
It would definitely be helpful, since I'm already quite busy with the
normal merge window work. Having the embargo for L1TF end just as the
merge
On Wed, Aug 15, 2018 at 1:33 PM Sebastian Gottschall
wrote:
>
> if it would be helpfull i can do this quick here using the latest
> vanilla tree
It would definitely be helpful, since I'm already quite busy with the
normal merge window work. Having the embargo for L1TF end just as the
merge
On Wed, Aug 15, 2018 at 12:42:27PM -0700, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 12:26 PM Guenter Roeck wrote:
> >
> > Also seen in mainline. Meaning my non-SMP test builds are broken. Hmm.
>
> Grr. I think it's due mainly due to commit 447ae3166702 ("x86: Don't
Yes. It was a side
On Wed, Aug 15, 2018 at 12:42:27PM -0700, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 12:26 PM Guenter Roeck wrote:
> >
> > Also seen in mainline. Meaning my non-SMP test builds are broken. Hmm.
>
> Grr. I think it's due mainly due to commit 447ae3166702 ("x86: Don't
Yes. It was a side
On Tue, Aug 14, 2018 at 07:16:14PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.63 release.
> There are 104 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Tue, Aug 14, 2018 at 07:16:14PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.63 release.
> There are 104 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Both callers of coreboot_table_init() ioremap the pointer that comes in
but they don't unmap the memory on failure. Both of them also fail probe
immediately with the return value of coreboot_table_init(), leaking a
mapping when it fails. The mapping isn't necessary at all after devices
are
This function checks the header for sanity, registers a bus, and
populates devices for each coreboot table entry. Let's just populate
devices here and pull the other bits up into the caller so that this
function can be repurposed for pure device creation and registration.
Cc: Wei-Ning Huang
Cc:
Both callers of coreboot_table_init() ioremap the pointer that comes in
but they don't unmap the memory on failure. Both of them also fail probe
immediately with the return value of coreboot_table_init(), leaking a
mapping when it fails. The mapping isn't necessary at all after devices
are
This function checks the header for sanity, registers a bus, and
populates devices for each coreboot table entry. Let's just populate
devices here and pull the other bits up into the caller so that this
function can be repurposed for pure device creation and registration.
Cc: Wei-Ning Huang
Cc:
The bus is registered in module_init() but is unregistered when the
platform driver remove() function calls coreboot_table_exit(). That
isn't symmetric and it causes the bus to appear on systems that compile
this code in, even when there isn't any coreboot firmware on the device.
Let's move the
The bus is registered in module_init() but is unregistered when the
platform driver remove() function calls coreboot_table_exit(). That
isn't symmetric and it causes the bus to appear on systems that compile
this code in, even when there isn't any coreboot firmware on the device.
Let's move the
On 08/15/2018 12:24 PM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:14 -0400
Tony Krowiak wrote:
Nit: please drop the leading period in the subject.
I assume you mean the ending period?
From: Tony Krowiak
Let's call PAPQ(ZAPQ) to zeroize a queue:
* For each queue configured for a
This is all system memory, so we shouldn't be mapping this all with
ioremap() as these aren't I/O regions. Instead, they're memory regions
so we should use memremap(). Pick MEMREMAP_WB so we can map memory from
RAM directly if that's possible, otherwise it falls back to
ioremap_cache() like is
The DT based and ACPI based platform drivers here do the same thing; map
some memory and hand it over to the coreboot bus to populate devices.
The only major difference is that the DT based driver doesn't map the
coreboot table header to figure out how large of a region to map for the
whole
Now that the /firmware/coreboot node in DT is populated by the core DT
platform code with commit 3aa0582fdb82 ("of: platform: populate
/firmware/ node from of_platform_default_populate_init()") we should and
can remove the platform device creation here. Otherwise, the
of_platform_device_create()
This series reworks the coreboot firmware driver a bit to fix some bugs
and then simplify the code by changing the design to get rid of the
different platform drivers, remap memory with memremap() to fix sparse
__iomem issue, and finally simplify code. There's some risk in changing to
memremap()
The DT based and ACPI based platform drivers here do the same thing; map
some memory and hand it over to the coreboot bus to populate devices.
The only major difference is that the DT based driver doesn't map the
coreboot table header to figure out how large of a region to map for the
whole
Now that the /firmware/coreboot node in DT is populated by the core DT
platform code with commit 3aa0582fdb82 ("of: platform: populate
/firmware/ node from of_platform_default_populate_init()") we should and
can remove the platform device creation here. Otherwise, the
of_platform_device_create()
On 08/15/2018 12:24 PM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:14 -0400
Tony Krowiak wrote:
Nit: please drop the leading period in the subject.
I assume you mean the ending period?
From: Tony Krowiak
Let's call PAPQ(ZAPQ) to zeroize a queue:
* For each queue configured for a
This is all system memory, so we shouldn't be mapping this all with
ioremap() as these aren't I/O regions. Instead, they're memory regions
so we should use memremap(). Pick MEMREMAP_WB so we can map memory from
RAM directly if that's possible, otherwise it falls back to
ioremap_cache() like is
This series reworks the coreboot firmware driver a bit to fix some bugs
and then simplify the code by changing the design to get rid of the
different platform drivers, remap memory with memremap() to fix sparse
__iomem issue, and finally simplify code. There's some risk in changing to
memremap()
On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote:
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> wrote:
> > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> >> syzbot has found a reproducer for the following crash on:
> >>
> >> HEAD commit:5ed5da74de9e Add
On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote:
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> wrote:
> > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> >> syzbot has found a reproducer for the following crash on:
> >>
> >> HEAD commit:5ed5da74de9e Add
Create __vmalloc_node_try_addr function that tries to allocate at a specific
address and supports caller specified behavior for whether any lazy purging
happens if there is a collision.
Signed-off-by: Rick Edgecombe
---
include/linux/vmalloc.h | 3 +
mm/vmalloc.c| 177
Create __vmalloc_node_try_addr function that tries to allocate at a specific
address and supports caller specified behavior for whether any lazy purging
happens if there is a collision.
Signed-off-by: Rick Edgecombe
---
include/linux/vmalloc.h | 3 +
mm/vmalloc.c| 177
This changes the behavior of the KASLR logic for allocating memory for the text
sections of loadable modules. It randomizes the location of each module text
section with about 17 bits of entropy in typical use. This is enabled on X86_64
only. For 32 bit, the behavior is unchanged. It refactors
Add debugfs file "modfraginfo" for providing info on module space fragmentation.
This can be used for determining if loadable module randomization is causing any
problems for extreme module loading situations, like huge numbers of modules or
extremely large modules.
Sample output when KASLR is
Hi,
This is V3 of the "KASLR feature to randomize each loadable module" patchset.
The purpose is to increase the randomization and also to make the modules
randomized in relation to each other instead of just the base, so that if one
module leaks the location of the others can't be inferred.
V3
This changes the behavior of the KASLR logic for allocating memory for the text
sections of loadable modules. It randomizes the location of each module text
section with about 17 bits of entropy in typical use. This is enabled on X86_64
only. For 32 bit, the behavior is unchanged. It refactors
Add debugfs file "modfraginfo" for providing info on module space fragmentation.
This can be used for determining if loadable module randomization is causing any
problems for extreme module loading situations, like huge numbers of modules or
extremely large modules.
Sample output when KASLR is
Hi,
This is V3 of the "KASLR feature to randomize each loadable module" patchset.
The purpose is to increase the randomization and also to make the modules
randomized in relation to each other instead of just the base, so that if one
module leaks the location of the others can't be inferred.
V3
201 - 300 of 890 matches
Mail list logo
