Kirill A. Shutemov wrote:
> Something like this?
>
>
> From 251e124630da82482e8b320c73162ce89af04d5d Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov"
> Date: Thu, 18 Jan 2018 18:24:07 +0300
> Subject: [PATCH] mm, page_vma_mapped: Fix pointer arithmetics in
Kirill A. Shutemov wrote:
> Something like this?
>
>
> From 251e124630da82482e8b320c73162ce89af04d5d Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov"
> Date: Thu, 18 Jan 2018 18:24:07 +0300
> Subject: [PATCH] mm, page_vma_mapped: Fix pointer arithmetics in check_pte()
>
> Tetsuo reported
Store and restore the AMR, IAMR and UAMOR register state of the task
before scheduling out and after scheduling in, respectively.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu_context.h |3 ++
arch/powerpc/include/asm/pkeys.h |4 ++
Store and restore the AMR, IAMR and UAMOR register state of the task
before scheduling out and after scheduling in, respectively.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu_context.h |3 ++
arch/powerpc/include/asm/pkeys.h |4 ++
arch/powerpc/include/asm/processor.h
Don't let a lessee control what the current DRM master is set to;
that's the job of the "real" master. Otherwise, the lessee would
disable all access to master operations for the owner and all lessees
under it.
This matches the same check made in the SET_MASTER ioctl.
Signed-off-by: Keith
Don't let a lessee control what the current DRM master is set to;
that's the job of the "real" master. Otherwise, the lessee would
disable all access to master operations for the owner and all lessees
under it.
This matches the same check made in the SET_MASTER ioctl.
Signed-off-by: Keith
This patch provides the implementation of execute-only pkey.
The architecture-independent layer expects the arch-dependent
layer, to support the ability to create and enable a special
key which has execute-only permission.
Acked-by: Balbir Singh
Signed-off-by: Ram Pai
This patch provides the implementation of execute-only pkey.
The architecture-independent layer expects the arch-dependent
layer, to support the ability to create and enable a special
key which has execute-only permission.
Acked-by: Balbir Singh
Signed-off-by: Ram Pai
---
arch-independent code expects the arch to map
a pkey into the vma's protection bit setting.
The patch provides that ability.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mman.h |7 ++-
arch/powerpc/include/asm/pkeys.h | 11 +++
arch independent code calls arch_override_mprotect_pkey()
to return a pkey that best matches the requested protection.
This patch provides the implementation.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu_context.h |5
arch/powerpc/include/asm/pkeys.h
arch independent code calls arch_override_mprotect_pkey()
to return a pkey that best matches the requested protection.
This patch provides the implementation.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu_context.h |5
arch/powerpc/include/asm/pkeys.h | 21
arch-independent code expects the arch to map
a pkey into the vma's protection bit setting.
The patch provides that ability.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mman.h |7 ++-
arch/powerpc/include/asm/pkeys.h | 11 +++
arch/powerpc/mm/pkeys.c |
VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
is enabled. Powerpc also needs these bits. Hence lets define the
VM_PKEY_BITx bits for any architecture that enables
CONFIG_ARCH_HAS_PKEYS.
Signed-off-by: Ram Pai
---
fs/proc/task_mmu.c |4 ++--
VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
is enabled. Powerpc also needs these bits. Hence lets define the
VM_PKEY_BITx bits for any architecture that enables
CONFIG_ARCH_HAS_PKEYS.
Signed-off-by: Ram Pai
---
fs/proc/task_mmu.c |4 ++--
include/linux/mm.h |
Map the key protection bits of the vma to the pkey bits in
the PTE.
The PTE bits used for pkey are 3,4,5,6 and 57. The first
four bits are the same four bits that were freed up initially
in this patch series. remember? :-) Without those four bits
this patch wouldn't be possible.
BUT,
Map the PTE protection key bits to the HPTE key protection bits,
while creating HPTE entries.
Acked-by: Balbir Singh
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 +
arch/powerpc/include/asm/mmu_context.h
Map the key protection bits of the vma to the pkey bits in
the PTE.
The PTE bits used for pkey are 3,4,5,6 and 57. The first
four bits are the same four bits that were freed up initially
in this patch series. remember? :-) Without those four bits
this patch wouldn't be possible.
BUT,
Map the PTE protection key bits to the HPTE key protection bits,
while creating HPTE entries.
Acked-by: Balbir Singh
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 +
arch/powerpc/include/asm/mmu_context.h|6 ++
helper function that checks if the read/write/execute is allowed
on the pte.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/book3s/64/pgtable.h |4 +++
arch/powerpc/include/asm/pkeys.h |9
arch/powerpc/mm/pkeys.c | 28
helper function that checks if the read/write/execute is allowed
on the pte.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/book3s/64/pgtable.h |4 +++
arch/powerpc/include/asm/pkeys.h |9
arch/powerpc/mm/pkeys.c | 28
The value of the pkey, whose protection got violated,
is made available in si_pkey field of the siginfo structure.
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/bug.h |1 +
The value of the pkey, whose protection got violated,
is made available in si_pkey field of the siginfo structure.
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/bug.h |1 +
arch/powerpc/kernel/traps.c| 12 +++-
PAPR defines 'ibm,processor-storage-keys' property. It exports two
values. The first value holds the number of data-access keys and the
second holds the number of instruction-access keys. Due to a bug in
the firmware, instruction-access keys is always reported as zero.
However any key can be
PAPR defines 'ibm,processor-storage-keys' property. It exports two
values. The first value holds the number of data-access keys and the
second holds the number of instruction-access keys. Due to a bug in
the firmware, instruction-access keys is always reported as zero.
However any key can be
From: Thiago Jung Bauermann
The AMR/IAMR/UAMOR are part of the program context.
Allow it to be accessed via ptrace and through core files.
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
Make sure that the kernel does not access user pages without
checking their key-protection.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git
Make sure that the kernel does not access user pages without
checking their key-protection.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git
From: Thiago Jung Bauermann
The AMR/IAMR/UAMOR are part of the program context.
Allow it to be accessed via ptrace and through core files.
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/pkeys.h|5 +++
arch/powerpc/include/uapi/asm/elf.h |
Arch neutral code needs to know if the architecture supports
protection keys to display protection key in smaps. Hence
introducing arch_pkeys_enabled().
This patch also provides x86 implementation for
arch_pkeys_enabled().
Signed-off-by: Ram Pai
---
Arch neutral code needs to know if the architecture supports
protection keys to display protection key in smaps. Hence
introducing arch_pkeys_enabled().
This patch also provides x86 implementation for
arch_pkeys_enabled().
Signed-off-by: Ram Pai
---
arch/x86/include/asm/pkeys.h |1 +
Patch provides the ability for a process to
associate a pkey with a address range.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/systbl.h |1 +
arch/powerpc/include/asm/unistd.h |4 +---
arch/powerpc/include/uapi/asm/unistd.h |1 +
3 files
Patch provides the ability for a process to
associate a pkey with a address range.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/systbl.h |1 +
arch/powerpc/include/asm/unistd.h |4 +---
arch/powerpc/include/uapi/asm/unistd.h |1 +
3 files changed, 3 insertions(+), 3
Finally this patch provides the ability for a process to
allocate and free a protection key.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/systbl.h |2 ++
arch/powerpc/include/asm/unistd.h |4 +---
arch/powerpc/include/uapi/asm/unistd.h |2 ++
3
Finally this patch provides the ability for a process to
allocate and free a protection key.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/systbl.h |2 ++
arch/powerpc/include/asm/unistd.h |4 +---
arch/powerpc/include/uapi/asm/unistd.h |2 ++
3 files changed, 5
Currently the architecture specific code is expected to
display the protection keys in smap for a given vma.
This can lead to redundant code and possibly to divergent
formats in which the key gets displayed.
This patch changes the implementation. It displays the
pkey only if the
Currently the architecture specific code is expected to
display the protection keys in smap for a given vma.
This can lead to redundant code and possibly to divergent
formats in which the key gets displayed.
This patch changes the implementation. It displays the
pkey only if the
Introduce helper functions that can initialize the bits in the AMR,
IAMR and UAMOR register; the bits that correspond to the given pkey.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Ram Pai
---
arch/powerpc/mm/pkeys.c | 47
Handle Data and Instruction exceptions caused by memory
protection-key.
The CPU will detect the key fault if the HPTE is already
programmed with the key.
However if the HPTE is not hashed, a key fault will not
be detected by the hardware. The software will detect
pkey violation in such a case.
get_mm_addr_key() helper returns the pkey associated with
an address corresponding to a given mm_struct.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu.h |9 +
arch/powerpc/mm/hash_utils_64.c | 24
2 files changed, 33
Introduce helper functions that can initialize the bits in the AMR,
IAMR and UAMOR register; the bits that correspond to the given pkey.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Ram Pai
---
arch/powerpc/mm/pkeys.c | 47 +++
1 files
Handle Data and Instruction exceptions caused by memory
protection-key.
The CPU will detect the key fault if the HPTE is already
programmed with the key.
However if the HPTE is not hashed, a key fault will not
be detected by the hardware. The software will detect
pkey violation in such a case.
get_mm_addr_key() helper returns the pkey associated with
an address corresponding to a given mm_struct.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu.h |9 +
arch/powerpc/mm/hash_utils_64.c | 24
2 files changed, 33 insertions(+), 0
powerpc has hardware support to disable execute on a pkey.
This patch enables the ability to create execute-disabled
keys.
Signed-off-by: Ram Pai
---
arch/powerpc/include/uapi/asm/mman.h |6 ++
arch/powerpc/mm/pkeys.c | 16
2 files
This patch provides the implementation for
arch_vma_access_permitted(). Returns true if the
requested access is allowed by pkey associated with the
vma.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu_context.h |5 +++-
arch/powerpc/mm/pkeys.c|
powerpc has hardware support to disable execute on a pkey.
This patch enables the ability to create execute-disabled
keys.
Signed-off-by: Ram Pai
---
arch/powerpc/include/uapi/asm/mman.h |6 ++
arch/powerpc/mm/pkeys.c | 16
2 files changed, 22
This patch provides the implementation for
arch_vma_access_permitted(). Returns true if the
requested access is allowed by pkey associated with the
vma.
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu_context.h |5 +++-
arch/powerpc/mm/pkeys.c| 34
Implements helper functions to read and write the key related
registers; AMR, IAMR, UAMOR.
AMR register tracks the read,write permission of a key
IAMR register tracks the execute permission of a key
UAMOR register enables and disables a key
Acked-by: Balbir Singh
Implements helper functions to read and write the key related
registers; AMR, IAMR, UAMOR.
AMR register tracks the read,write permission of a key
IAMR register tracks the execute permission of a key
UAMOR register enables and disables a key
Acked-by: Balbir Singh
Reviewed-by: Thiago Jung
This patch provides the detailed implementation for
a user to allocate a key and enable it in the hardware.
It provides the plumbing, but it cannot be used till
the system call is implemented. The next patch will
do so.
Reviewed-by: Thiago Jung Bauermann
This patch provides the detailed implementation for
a user to allocate a key and enable it in the hardware.
It provides the plumbing, but it cannot be used till
the system call is implemented. The next patch will
do so.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Ram Pai
---
Cleanup the bits corresponding to a key in the AMR, and IAMR
register, when the key is newly allocated/activated or is freed.
We dont want some residual bits cause the hardware enforce
unintended behavior when the key is activated or freed.
Reviewed-by: Thiago Jung Bauermann
Basic plumbing to initialize the pkey system.
Nothing is enabled yet. A later patch will enable it
once all the infrastructure is in place.
Signed-off-by: Ram Pai
---
arch/powerpc/Kconfig | 15 +
arch/powerpc/include/asm/mmu_context.h |
Total 32 keys are available on power7 and above. However
pkey 0,1 are reserved. So effectively we have 30 pkeys.
On 4K kernels, we do not have 5 bits in the PTE to
represent all the keys; we only have 3bits.Two of those
keys are reserved; pkey 0 and pkey 1. So effectively we
have 6
Basic plumbing to initialize the pkey system.
Nothing is enabled yet. A later patch will enable it
once all the infrastructure is in place.
Signed-off-by: Ram Pai
---
arch/powerpc/Kconfig | 15 +
arch/powerpc/include/asm/mmu_context.h |1 +
Total 32 keys are available on power7 and above. However
pkey 0,1 are reserved. So effectively we have 30 pkeys.
On 4K kernels, we do not have 5 bits in the PTE to
represent all the keys; we only have 3bits.Two of those
keys are reserved; pkey 0 and pkey 1. So effectively we
have 6
Cleanup the bits corresponding to a key in the AMR, and IAMR
register, when the key is newly allocated/activated or is freed.
We dont want some residual bits cause the hardware enforce
unintended behavior when the key is activated or freed.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Ram
Memory protection keys enable applications to protect its
address space from inadvertent access from or corruption
by itself.
These patches along with the pte-bit freeing patch series
enables the protection key feature on powerpc; 4k and 64k
hashpage kernels.
Will send the documentation and
Memory protection keys enable applications to protect its
address space from inadvertent access from or corruption
by itself.
These patches along with the pte-bit freeing patch series
enables the protection key feature on powerpc; 4k and 64k
hashpage kernels.
Will send the documentation and
Currently only 4bits are allocated in the vma flags to hold 16
keys. This is sufficient for x86. PowerPC supports 32 keys,
which needs 5bits. This patch allocates an additional bit.
Acked-by: Balbir Singh
Signed-off-by: Ram Pai
---
Currently only 4bits are allocated in the vma flags to hold 16
keys. This is sufficient for x86. PowerPC supports 32 keys,
which needs 5bits. This patch allocates an additional bit.
Acked-by: Balbir Singh
Signed-off-by: Ram Pai
---
fs/proc/task_mmu.c |1 +
include/linux/mm.h |3 ++-
Hi Herbert,
After merging the crypto tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/crypto/chelsio/chcr_algo.c: In function 'create_authenc_wr':
drivers/crypto/chelsio/chcr_algo.c:2113:2: warning: this 'if' clause does not
guard... [-Wmisleading-indentation]
Hi Herbert,
After merging the crypto tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/crypto/chelsio/chcr_algo.c: In function 'create_authenc_wr':
drivers/crypto/chelsio/chcr_algo.c:2113:2: warning: this 'if' clause does not
guard... [-Wmisleading-indentation]
Hi Dmitry,
On Tue, Jan 16, 2018 at 10:58:51AM +0100, Dmitry Vyukov wrote:
On Tue, Jan 16, 2018 at 10:45 AM, Guenter Roeck wrote:
On Mon, Jan 15, 2018 at 11:51 PM, Dmitry Vyukov wrote:
Hello,
Several people proposed that linux-next should not be tested
Hi Dmitry,
On Tue, Jan 16, 2018 at 10:58:51AM +0100, Dmitry Vyukov wrote:
On Tue, Jan 16, 2018 at 10:45 AM, Guenter Roeck wrote:
On Mon, Jan 15, 2018 at 11:51 PM, Dmitry Vyukov wrote:
Hello,
Several people proposed that linux-next should not be tested on
syzbot. While some people suggested
Hello,
On Thu, Jan 18, 2018 at 03:25:25PM -0800, Andy Lutomirski wrote:
> I read the whitepaper that documented the new MSRs a couple days ago
> and I'm now completely unable to find it. If anyone could send the
> link, that would be great.
I see Andrew posted a link.
> From memory, however,
Hello,
On Thu, Jan 18, 2018 at 03:25:25PM -0800, Andy Lutomirski wrote:
> I read the whitepaper that documented the new MSRs a couple days ago
> and I'm now completely unable to find it. If anyone could send the
> link, that would be great.
I see Andrew posted a link.
> From memory, however,
On Thu, Jan 18, 2018 at 11:35:59AM -0500, Sinan Kaya wrote:
> On 1/18/2018 12:32 AM, p...@codeaurora.org wrote:
> > On 2018-01-18 08:26, Keith Busch wrote:
> >> On Wed, Jan 17, 2018 at 08:27:39AM -0800, Sinan Kaya wrote:
> >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote:
> >>> > +static bool
On Thu, Jan 18, 2018 at 11:35:59AM -0500, Sinan Kaya wrote:
> On 1/18/2018 12:32 AM, p...@codeaurora.org wrote:
> > On 2018-01-18 08:26, Keith Busch wrote:
> >> On Wed, Jan 17, 2018 at 08:27:39AM -0800, Sinan Kaya wrote:
> >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote:
> >>> > +static bool
On 2018/1/19 9:11, Francois Romieu wrote:
Jia-Ju Bai :
[...]
The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
netif_err(tp, drv, dev, "BUG! Tx Ring full when
On 2018/1/19 9:11, Francois Romieu wrote:
Jia-Ju Bai :
[...]
The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
Hi Paul,
This patch is optional.
1. It's true that the added #ifdef in rcu_read_unlock_special is a
bad breaker. The patch follows the current code e.g.
CONFIG_PROVE_RCU
2. Haven't evaluated the performance in system.
Studying RCU and found that boost
Hi Paul,
This patch is optional.
1. It's true that the added #ifdef in rcu_read_unlock_special is a
bad breaker. The patch follows the current code e.g.
CONFIG_PROVE_RCU
2. Haven't evaluated the performance in system.
Studying RCU and found that boost
Jia-Ju Bai :
[...]
> The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
> if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
> netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
> goto err_stop_0;
>
Jia-Ju Bai :
[...]
> The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
> if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
> netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
> goto err_stop_0;
> }
> But there is no
Peter Zijlstra :
[...]
> There is only 1 variable afaict. Memory barriers need at least 2 in
> order to be able to do _anything_.
I don't get your point: why don't {cur_tx, dirty_tx} qualify as said
two variables ?
--
Ueimor
Peter Zijlstra :
[...]
> There is only 1 variable afaict. Memory barriers need at least 2 in
> order to be able to do _anything_.
I don't get your point: why don't {cur_tx, dirty_tx} qualify as said
two variables ?
--
Ueimor
Hi JC, Will,
On 01/18/2018 06:28 PM, Jayachandran C wrote:
> On Thu, Jan 18, 2018 at 01:27:15PM -0500, Jon Masters wrote:
>> On 01/18/2018 12:56 PM, Jayachandran C wrote:
>>> On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote:
>>> I think in this case we have to choose between crashing
Hi JC, Will,
On 01/18/2018 06:28 PM, Jayachandran C wrote:
> On Thu, Jan 18, 2018 at 01:27:15PM -0500, Jon Masters wrote:
>> On 01/18/2018 12:56 PM, Jayachandran C wrote:
>>> On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote:
>>> I think in this case we have to choose between crashing
Quoting Stephen Hemminger :
On Thu, 18 Jan 2018 17:37:45 -0600
"Gustavo A. R. Silva" wrote:
Return statements in functions returning bool should use
true/false instead of 1/0.
This issue was detected with the help of Coccinelle.
Quoting Stephen Hemminger :
On Thu, 18 Jan 2018 17:37:45 -0600
"Gustavo A. R. Silva" wrote:
Return statements in functions returning bool should use
true/false instead of 1/0.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
LGTM
Fixes:
> On Jan 17, 2018, at 10:23 AM, Christopher Lameter wrote:
>
> On Tue, 16 Jan 2018, Mel Gorman wrote:
>
>> My main source of discomfort is the fact that this is permanent as two
>> processes perfectly isolated but with a suitably shared COW mapping
>> will never migrate the
> On Jan 17, 2018, at 10:23 AM, Christopher Lameter wrote:
>
> On Tue, 16 Jan 2018, Mel Gorman wrote:
>
>> My main source of discomfort is the fact that this is permanent as two
>> processes perfectly isolated but with a suitably shared COW mapping
>> will never migrate the data. A potential
Reviewed-by: Lyude Paul
(hope you don't mind that I'm using my gmail address for this ;)
On Thu, 2018-01-18 at 16:49 -0800, Dmitry Torokhov wrote:
> We want to free memory reserved for interrupt mask handling only after we
> free functions, as function drivers might want to
Reviewed-by: Lyude Paul
(hope you don't mind that I'm using my gmail address for this ;)
On Thu, 2018-01-18 at 16:49 -0800, Dmitry Torokhov wrote:
> We want to free memory reserved for interrupt mask handling only after we
> free functions, as function drivers might want to mask interrupts. This
if (c->x86 == 6 &&
c->x86_model == INTEL_FAM6_BROADWELL_X &&
c->x86_mask == 0x01 &&
+ llc_size_per_core > 2621440 &&
c->microcode < 0x0b21) {
pr_err_once("Erratum BDF90: late loading with revision <
0x0b21 (0x%x)
if (c->x86 == 6 &&
c->x86_model == INTEL_FAM6_BROADWELL_X &&
c->x86_mask == 0x01 &&
+ llc_size_per_core > 2621440 &&
c->microcode < 0x0b21) {
pr_err_once("Erratum BDF90: late loading with revision <
0x0b21 (0x%x)
Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 01/09/2018 05:00 AM, Will Deacon wrote:
> On Mon, Jan 08, 2018 at 08:06:27PM -0800, Jayachandran C wrote:
>> On Mon, Jan 08, 2018 at 05:51:00PM +, Will Deacon wrote:
>>> On Mon, Jan 08, 2018 at 09:40:17AM -0800, Jayachandran C wrote:
On Mon, Jan 08, 2018 at 09:20:09AM +, Marc
On 01/09/2018 05:00 AM, Will Deacon wrote:
> On Mon, Jan 08, 2018 at 08:06:27PM -0800, Jayachandran C wrote:
>> On Mon, Jan 08, 2018 at 05:51:00PM +, Will Deacon wrote:
>>> On Mon, Jan 08, 2018 at 09:40:17AM -0800, Jayachandran C wrote:
On Mon, Jan 08, 2018 at 09:20:09AM +, Marc
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
kernel/bpf/verifier.c
between commit:
6f16101e6a8b ("bpf: mark dst unknown on inconsistent {s, u}bounds
adjustments")
from the net tree and commit:
f4d7e40a5b71 ("bpf: introduce function calls (verification)")
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
kernel/bpf/verifier.c
between commit:
6f16101e6a8b ("bpf: mark dst unknown on inconsistent {s, u}bounds
adjustments")
from the net tree and commit:
f4d7e40a5b71 ("bpf: introduce function calls (verification)")
On Mon, 2017-12-18 at 16:48 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Daniel Bristot de Oliveira
>
>
> [ Upstream commit df8eac8cafce7d086be3bd5cf5a838fa37594dfb ]
[...]
On Mon, 2017-12-18 at 16:48 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Daniel Bristot de Oliveira
>
>
> [ Upstream commit df8eac8cafce7d086be3bd5cf5a838fa37594dfb ]
[...]
I think this needs
On Thu, 2018-01-18 at 15:58 -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on linux-next commit
> 0e08c463db387a2adcb0243b15ab868a73f87807
>
> So far this crash happened 6 times on linux-next, mmots, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
>
On Thu, 2018-01-18 at 15:58 -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on linux-next commit
> 0e08c463db387a2adcb0243b15ab868a73f87807
>
> So far this crash happened 6 times on linux-next, mmots, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
>
We want to free memory reserved for interrupt mask handling only after we
free functions, as function drivers might want to mask interrupts. This is
needed for the followup patch to the F03 that would implement unmasking and
masking interrupts from the serio pass-through port open() and close()
We want to free memory reserved for interrupt mask handling only after we
free functions, as function drivers might want to mask interrupts. This is
needed for the followup patch to the F03 that would implement unmasking and
masking interrupts from the serio pass-through port open() and close()
Hi,
The following patch series is hopefully improves trackpint detection
on systems using RMI4 and PS/2 guest modules. The issue was that we
were registering port too early, before RMI driver was ready to service
interrupts properly, so psmouse would try to get ID from the device and RMI
driver
Hi,
The following patch series is hopefully improves trackpint detection
on systems using RMI4 and PS/2 guest modules. The issue was that we
were registering port too early, before RMI driver was ready to service
interrupts properly, so psmouse would try to get ID from the device and RMI
driver
201 - 300 of 1962 matches
Mail list logo