Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation

On 10/26/2017 10:36 AM, Linus Torvalds wrote: > On Tue, Oct 24, 2017 at 1:57 PM, John Johansen > wrote: >> >> actually a lot of work and testing has been done. A regression was >> found, the fix is in testing and it should land soon, but its not the >> regression you

Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation

On 10/26/2017 10:36 AM, Linus Torvalds wrote: > On Tue, Oct 24, 2017 at 1:57 PM, John Johansen > wrote: >> >> actually a lot of work and testing has been done. A regression was >> found, the fix is in testing and it should land soon, but its not the >> regression you are having issues with. > >

POSIX Message Queue Priority Scheduling

Can someone explain to me how message queues handle waking multiple threads blocked on a single message queue? My situation is I have multiple writers blocking on a full message queue, each posting messages with priority equal to the thread priority. I want to make sure they wake and post in

POSIX Message Queue Priority Scheduling

Can someone explain to me how message queues handle waking multiple threads blocked on a single message queue? My situation is I have multiple writers blocking on a full message queue, each posting messages with priority equal to the thread priority. I want to make sure they wake and post in

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > Greg Thelen wrote: > > So a force charge fallback might be a needed even with oom killer successful > > invocations. Or we'll need to teach out_of_memory() to return three values > > (e.g. NO_VICTIM, NEW_VICTIM, PENDING_VICTIM) and try_charge() can loop on > > NEW_VICTIM. >

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > Greg Thelen wrote: > > So a force charge fallback might be a needed even with oom killer successful > > invocations. Or we'll need to teach out_of_memory() to return three values > > (e.g. NO_VICTIM, NEW_VICTIM, PENDING_VICTIM) and try_charge() can loop on > > NEW_VICTIM. >

Re: [PATCH] pids: introduce find_get_task_by_vpid helper

On Thu, Oct 26, 2017 at 03:58:25PM +0200, Oleg Nesterov wrote: > On 10/26, Mike Rapoport wrote: > > > > There are several functions that do find_task_by_vpid() followed by > > get_task_struct(). We can use a helper function instead. > > Yes, agreed, I was going to do this many times. > > > ---

Re: [PATCH] pids: introduce find_get_task_by_vpid helper

On Thu, Oct 26, 2017 at 03:58:25PM +0200, Oleg Nesterov wrote: > On 10/26, Mike Rapoport wrote: > > > > There are several functions that do find_task_by_vpid() followed by > > get_task_struct(). We can use a helper function instead. > > Yes, agreed, I was going to do this many times. > > > ---

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Also add pvcalls-front to the Makefile. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrov...@oracle.com > CC: jgr...@suse.com Reviewed-by: Boris Ostrovsky

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Also add pvcalls-front to the Makefile. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrov...@oracle.com > CC: jgr...@suse.com Reviewed-by: Boris Ostrovsky

[PATCH] Input-max8925_onkey: Use common error handling code in max8925_onkey_probe()

From: Markus Elfring Date: Thu, 26 Oct 2017 21:40:51 +0200 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] Input-max8925_onkey: Use common error handling code in max8925_onkey_probe()

From: Markus Elfring Date: Thu, 26 Oct 2017 21:40:51 +0200 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/input/misc/max8925_onkey.c |

Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

Reverting seems like the right approach at the moment. My apologies for the breakage so late the in the cycle. Post-revert, there remains a bug here wherein you can make the system OOPS if you mmap memory above the 48 bit bus width. Linus/Ingo, is there something in particular that you'd like

Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

Reverting seems like the right approach at the moment. My apologies for the breakage so late the in the cycle. Post-revert, there remains a bug here wherein you can make the system OOPS if you mmap memory above the 48 bit bus width. Linus/Ingo, is there something in particular that you'd like

Re: [PATCH v7 12/13] xen/pvcalls: implement release command

On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Send PVCALLS_RELEASE to the backend and wait for a reply. Take both > in_mutex and out_mutex to avoid concurrent accesses. Then, free the > socket. > > For passive sockets, check whether we have already pre-allocated an > active socket for the

Re: [PATCH v7 12/13] xen/pvcalls: implement release command

On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Send PVCALLS_RELEASE to the backend and wait for a reply. Take both > in_mutex and out_mutex to avoid concurrent accesses. Then, free the > socket. > > For passive sockets, check whether we have already pre-allocated an > active socket for the

Re: [PATCH v7 02/13] xen/pvcalls: implement frontend disconnect

On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Introduce a data structure named pvcalls_bedata. It contains pointers to > the command ring, the event channel, a list of active sockets and a list > of passive sockets. Lists accesses are protected by a spin_lock. > > Introduce a waitqueue to

Re: [PATCH v7 02/13] xen/pvcalls: implement frontend disconnect

On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Introduce a data structure named pvcalls_bedata. It contains pointers to > the command ring, the event channel, a list of active sockets and a list > of passive sockets. Lists accesses are protected by a spin_lock. > > Introduce a waitqueue to

Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

On 26/10/17 19:49, Craig Bergstrom wrote: > Sander, thanks for the details, they've been very useful. > > I suspect that your host system's mem=2048M parameter is causing the > problem. Any chance you can confirm by removing the parameter and > running the guest code path? I removed it, but

Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

On Thu, Oct 26, 2017 at 9:02 PM, Ingo Molnar wrote: > > Well, 'mem=2048M' shouldn't really limit device memory, it's supposed to limit > (trim) 'RAM' and not much else. Agreed. You should very much be able to map in IO memory or whatever above the 2G address even if the

Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

On Thu, Oct 26, 2017 at 9:02 PM, Ingo Molnar wrote: > > Well, 'mem=2048M' shouldn't really limit device memory, it's supposed to limit > (trim) 'RAM' and not much else. Agreed. You should very much be able to map in IO memory or whatever above the 2G address even if the high_memory itself might

Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

On 26/10/17 19:49, Craig Bergstrom wrote: > Sander, thanks for the details, they've been very useful. > > I suspect that your host system's mem=2048M parameter is causing the > problem. Any chance you can confirm by removing the parameter and > running the guest code path? I removed it, but

Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

On 10/26/2017 12:44 PM, Borislav Petkov wrote: On Thu, Oct 26, 2017 at 11:56:57AM -0500, Brijesh Singh wrote: The variable is used as ref counter. ... and it can't be converted to a boolean because...? SHUTDOWN command unconditionally transitions a platform to uninitialized state. The

Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

On 10/26/2017 12:44 PM, Borislav Petkov wrote: On Thu, Oct 26, 2017 at 11:56:57AM -0500, Brijesh Singh wrote: The variable is used as ref counter. ... and it can't be converted to a boolean because...? SHUTDOWN command unconditionally transitions a platform to uninitialized state. The

[PATCH] Input-mpr121: Use common error handling code in mpr_touchkey_interrupt()

From: Markus Elfring Date: Thu, 26 Oct 2017 21:16:53 +0200 Add a jump target so that an error message can be better reused in an if branch of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] Input-mpr121: Use common error handling code in mpr_touchkey_interrupt()

From: Markus Elfring Date: Thu, 26 Oct 2017 21:16:53 +0200 Add a jump target so that an error message can be better reused in an if branch of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/input/keyboard/mpr121_touchkey.c |

Re: [GIT PULL] Kernel lockdown for secure boot

On Thu, 26 Oct 2017, David Howells wrote: > Hi James, > > Can you pull this patchset into security/next please? > > It adds kernel lockdown support for EFI secure boot. Note that it doesn't yet > cover: > > bpf - No agreement as to how > ftrace - Recently suggested, query

Re: [GIT PULL] Kernel lockdown for secure boot

On Thu, 26 Oct 2017, David Howells wrote: > Hi James, > > Can you pull this patchset into security/next please? > > It adds kernel lockdown support for EFI secure boot. Note that it doesn't yet > cover: > > bpf - No agreement as to how > ftrace - Recently suggested, query

[PATCH v7 02/13] xen/pvcalls: implement frontend disconnect

Introduce a data structure named pvcalls_bedata. It contains pointers to the command ring, the event channel, a list of active sockets and a list of passive sockets. Lists accesses are protected by a spin_lock. Introduce a waitqueue to allow waiting for a response on commands sent to the backend.

[PATCH v7 02/13] xen/pvcalls: implement frontend disconnect

Introduce a data structure named pvcalls_bedata. It contains pointers to the command ring, the event channel, a list of active sockets and a list of passive sockets. Lists accesses are protected by a spin_lock. Introduce a waitqueue to allow waiting for a response on commands sent to the backend.

RE:

I have a business proposal 15,500,000 GBP.

RE:

I have a business proposal 15,500,000 GBP.

[PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

Also add pvcalls-front to the Makefile. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/Kconfig | 11 +++ drivers/xen/Makefile | 1 + 2 files changed, 12 insertions(+) diff --git a/drivers/xen/Kconfig

[PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

Also add pvcalls-front to the Makefile. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/Kconfig | 11 +++ drivers/xen/Makefile | 1 + 2 files changed, 12 insertions(+) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index

[PATCH v7 11/13] xen/pvcalls: implement poll command

For active sockets, check the indexes and use the inflight_conn_req waitqueue to wait. For passive sockets if an accept is outstanding (PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking at bedata->rsp[req_id]. If so, return POLLIN. Otherwise use the inflight_accept_req

[PATCH v7 11/13] xen/pvcalls: implement poll command

For active sockets, check the indexes and use the inflight_conn_req waitqueue to wait. For passive sockets if an accept is outstanding (PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking at bedata->rsp[req_id]. If so, return POLLIN. Otherwise use the inflight_accept_req

[PATCH v7 07/13] xen/pvcalls: implement listen command

Send PVCALLS_LISTEN to the backend. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-front.c | 57 +

[PATCH v7 07/13] xen/pvcalls: implement listen command

Send PVCALLS_LISTEN to the backend. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-front.c | 57 + drivers/xen/pvcalls-front.h | 1 + 2 files changed, 58

[PATCH v7 09/13] xen/pvcalls: implement sendmsg

Send data to an active socket by copying data to the "out" ring. Take the active socket out_mutex so that only one function can access the ring at any given time. If not enough room is available on the ring, rather than returning immediately or sleep-waiting, spin for up to 5000 cycles. This

[PATCH v7 09/13] xen/pvcalls: implement sendmsg

Send data to an active socket by copying data to the "out" ring. Take the active socket out_mutex so that only one function can access the ring at any given time. If not enough room is available on the ring, rather than returning immediately or sleep-waiting, spin for up to 5000 cycles. This

[PATCH v7 06/13] xen/pvcalls: implement bind command

Send PVCALLS_BIND to the backend. Introduce a new structure, part of struct sock_mapping, to store information specific to passive sockets. Introduce a status field to keep track of the status of the passive socket. Signed-off-by: Stefano Stabellini Reviewed-by: Boris

[PATCH v7 06/13] xen/pvcalls: implement bind command

Send PVCALLS_BIND to the backend. Introduce a new structure, part of struct sock_mapping, to store information specific to passive sockets. Introduce a status field to keep track of the status of the passive socket. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky CC:

[PATCH v7 04/13] xen/pvcalls: implement socket command and handle events

Send a PVCALLS_SOCKET command to the backend, use the masked req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0 and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array ready for the response, and there cannot be two outstanding responses with the same req_id. Wait

[PATCH v7 04/13] xen/pvcalls: implement socket command and handle events

Send a PVCALLS_SOCKET command to the backend, use the masked req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0 and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array ready for the response, and there cannot be two outstanding responses with the same req_id. Wait

[PATCH v7 05/13] xen/pvcalls: implement connect command

Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for the active socket. Introduce fields in struct sock_mapping to keep track of active sockets. Introduce a waitqueue to allow the frontend to wait on data coming from the backend on the active socket (recvmsg command). Two

[PATCH v7 05/13] xen/pvcalls: implement connect command

Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for the active socket. Introduce fields in struct sock_mapping to keep track of active sockets. Introduce a waitqueue to allow the frontend to wait on data coming from the backend on the active socket (recvmsg command). Two

[PATCH v7 12/13] xen/pvcalls: implement release command

Send PVCALLS_RELEASE to the backend and wait for a reply. Take both in_mutex and out_mutex to avoid concurrent accesses. Then, free the socket. For passive sockets, check whether we have already pre-allocated an active socket for the purpose of being accepted. If so, free that as well.

[PATCH v7 12/13] xen/pvcalls: implement release command

Send PVCALLS_RELEASE to the backend and wait for a reply. Take both in_mutex and out_mutex to avoid concurrent accesses. Then, free the socket. For passive sockets, check whether we have already pre-allocated an active socket for the purpose of being accepted. If so, free that as well.

[PATCH v7 10/13] xen/pvcalls: implement recvmsg

Implement recvmsg by copying data from the "in" ring. If not enough data is available and the recvmsg call is blocking, then wait on the inflight_conn_req waitqueue. Take the active socket in_mutex so that only one function can access the ring at any given time. Signed-off-by: Stefano Stabellini

[PATCH v7 10/13] xen/pvcalls: implement recvmsg

Implement recvmsg by copying data from the "in" ring. If not enough data is available and the recvmsg call is blocking, then wait on the inflight_conn_req waitqueue. Take the active socket in_mutex so that only one function can access the ring at any given time. Signed-off-by: Stefano Stabellini

[PATCH v7 08/13] xen/pvcalls: implement accept command

Introduce a waitqueue to allow only one outstanding accept command at any given time and to implement polling on the passive socket. Introduce a flags field to keep track of in-flight accept and poll commands. Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make sure that only

[PATCH v7 08/13] xen/pvcalls: implement accept command

Introduce a waitqueue to allow only one outstanding accept command at any given time and to implement polling on the passive socket. Introduce a flags field to keep track of in-flight accept and poll commands. Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make sure that only

[PATCH v7 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend

Introduce a xenbus frontend for the pvcalls protocol, as defined by https://xenbits.xen.org/docs/unstable/misc/pvcalls.html. This patch only adds the stubs, the code will be added by the following patches. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky

[PATCH v7 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend

Introduce a xenbus frontend for the pvcalls protocol, as defined by https://xenbits.xen.org/docs/unstable/misc/pvcalls.html. This patch only adds the stubs, the code will be added by the following patches. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky CC:

[PATCH v7 03/13] xen/pvcalls: connect to the backend

Implement the probe function for the pvcalls frontend. Read the supported versions, max-page-order and function-calls nodes from xenstore. Only one frontend<->backend connection is supported at any given time for a guest. Store the active frontend device to a static pointer. Introduce a stub

[PATCH v7 03/13] xen/pvcalls: connect to the backend

Implement the probe function for the pvcalls frontend. Read the supported versions, max-page-order and function-calls nodes from xenstore. Only one frontend<->backend connection is supported at any given time for a guest. Store the active frontend device to a static pointer. Introduce a stub

[PATCH v7 00/13] introduce the Xen PV Calls frontend

Hi all, this series introduces the frontend for the newly introduced PV Calls procotol. PV Calls is a paravirtualized protocol that allows the implementation of a set of POSIX functions in a different domain. The PV Calls frontend sends POSIX function calls to the backend, which implements them

[PATCH v7 00/13] introduce the Xen PV Calls frontend

Hi all, this series introduces the frontend for the newly introduced PV Calls procotol. PV Calls is a paravirtualized protocol that allows the implementation of a set of POSIX functions in a different domain. The PV Calls frontend sends POSIX function calls to the backend, which implements them

Re: Fixing CVE-2017-15361

On Thu, Oct 26, 2017 at 03:51:27PM +, alexander.stef...@infineon.com wrote: > > > On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: > > > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen > > > > wrote: > > > > > I'm implementing a fix for

Re: Fixing CVE-2017-15361

On Thu, Oct 26, 2017 at 03:51:27PM +, alexander.stef...@infineon.com wrote: > > > On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote: > > > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen > > > > wrote: > > > > > I'm implementing a fix for CVE-2017-15361 that simply blacklists

Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation

On Thu, 26 Oct 2017, Linus Torvalds wrote: > On Thu, Oct 26, 2017 at 8:54 PM, James Morris > wrote: > > On Thu, 26 Oct 2017, Linus Torvalds wrote: > > > >> I'm *very* unhappy with the security layer as is > > > > What are you unhappy with? > > We had two big

Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation

On Thu, 26 Oct 2017, Linus Torvalds wrote: > On Thu, Oct 26, 2017 at 8:54 PM, James Morris > wrote: > > On Thu, 26 Oct 2017, Linus Torvalds wrote: > > > >> I'm *very* unhappy with the security layer as is > > > > What are you unhappy with? > > We had two big _fundamental_ problems this merge

Re: [PATCH v2] iio : Add cm3218 smbus ara and acpi support

> On asus T100, Capella cm3218 chip is implemented as ambiant light > sensor. This chip expose an smbus ARA protocol device on standard > address 0x0c. The chip is not functional before all alerts are > acknowledged. > On asus T100, this device is enumerated on ACPI bus and the description > give

Re: [PATCH v2] iio : Add cm3218 smbus ara and acpi support

> On asus T100, Capella cm3218 chip is implemented as ambiant light > sensor. This chip expose an smbus ARA protocol device on standard > address 0x0c. The chip is not functional before all alerts are > acknowledged. > On asus T100, this device is enumerated on ACPI bus and the description > give

Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation

On Thu, Oct 26, 2017 at 8:54 PM, James Morris wrote: > On Thu, 26 Oct 2017, Linus Torvalds wrote: > >> I'm *very* unhappy with the security layer as is > > What are you unhappy with? We had two big _fundamental_ problems this merge window: - untested code that

Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation

On Thu, Oct 26, 2017 at 8:54 PM, James Morris wrote: > On Thu, 26 Oct 2017, Linus Torvalds wrote: > >> I'm *very* unhappy with the security layer as is > > What are you unhappy with? We had two big _fundamental_ problems this merge window: - untested code that clearly didn't do what it claimed

Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

* Craig Bergstrom wrote: > Sander, thanks for the details, they've been very useful. > > I suspect that your host system's mem=2048M parameter is causing the > problem. Any chance you can confirm by removing the parameter and > running the guest code path? > > More

Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

* Craig Bergstrom wrote: > Sander, thanks for the details, they've been very useful. > > I suspect that your host system's mem=2048M parameter is causing the > problem. Any chance you can confirm by removing the parameter and > running the guest code path? > > More specifically, since you're

Re: [PATCH 05/14] VFS: Implement fsopen() to prepare for a mount [ver #6]

On Fri, 2017-10-06 at 16:49 +0100, David Howells wrote: > Provide an fsopen() system call that starts the process of preparing to > mount, using an fd as a context handle. fsopen() is given the name of the > filesystem that will be used: > > int mfd = fsopen(const char *fsname, int

Re: [PATCH 05/14] VFS: Implement fsopen() to prepare for a mount [ver #6]

On Fri, 2017-10-06 at 16:49 +0100, David Howells wrote: > Provide an fsopen() system call that starts the process of preparing to > mount, using an fd as a context handle. fsopen() is given the name of the > filesystem that will be used: > > int mfd = fsopen(const char *fsname, int

Re: [PATCH v3 4/5] efi: call get_event_log before ExitBootServices

On Tue, Oct 17, 2017 at 10:00:15AM +0200, Thiebaud Weksteen wrote: > This patch was mainly developed and tested on Kabylake with PTT as well. > > It could be a few things. Are you booting with the EFI stub? Is the > TPM enabled within the BIOS? Does tpm_tis get loaded? Does it produce > any log?

Re: [PATCH v3 4/5] efi: call get_event_log before ExitBootServices

On Tue, Oct 17, 2017 at 10:00:15AM +0200, Thiebaud Weksteen wrote: > This patch was mainly developed and tested on Kabylake with PTT as well. > > It could be a few things. Are you booting with the EFI stub? Is the > TPM enabled within the BIOS? Does tpm_tis get loaded? Does it produce > any log?

[PATCH] Input-as5011: Use common error handling code in as5011_configure_chip()

From: Markus Elfring Date: Thu, 26 Oct 2017 20:48:49 +0200 Add a jump target so that a specific error message is stored only once at the end of this function implementation. Replace four calls of the function "dev_err" by goto statements. This issue was detected

[PATCH] Input-as5011: Use common error handling code in as5011_configure_chip()

From: Markus Elfring Date: Thu, 26 Oct 2017 20:48:49 +0200 Add a jump target so that a specific error message is stored only once at the end of this function implementation. Replace four calls of the function "dev_err" by goto statements. This issue was detected by using the Coccinelle

Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation

On Thu, 26 Oct 2017, Linus Torvalds wrote: > I'm *very* unhappy with the security layer as is What are you unhappy with? -- James Morris

Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation

On Thu, 26 Oct 2017, Linus Torvalds wrote: > I'm *very* unhappy with the security layer as is What are you unhappy with? -- James Morris

Re: [PATCH] leds: Convert timers to use timer_setup()

Hi Kees, Thanks for the patch. On 10/25/2017 12:30 PM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Richard Purdie

Re: [PATCH] leds: Convert timers to use timer_setup()

Hi Kees, Thanks for the patch. On 10/25/2017 12:30 PM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Richard Purdie >

Re: WARNING in refcount_sub_and_test

On Fri, Oct 27, 2017 at 12:56 AM, Xin Long wrote: > On Fri, Oct 27, 2017 at 12:13 AM, Dmitry Vyukov wrote: >> On Thu, Oct 26, 2017 at 5:49 PM, Xin Long wrote: >>> On Thu, Oct 26, 2017 at 10:49 PM, Dmitry Vyukov

Re: WARNING in refcount_sub_and_test

On Fri, Oct 27, 2017 at 12:56 AM, Xin Long wrote: > On Fri, Oct 27, 2017 at 12:13 AM, Dmitry Vyukov wrote: >> On Thu, Oct 26, 2017 at 5:49 PM, Xin Long wrote: >>> On Thu, Oct 26, 2017 at 10:49 PM, Dmitry Vyukov wrote: On Thu, Oct 26, 2017 at 10:53 AM, ChunYu Wang wrote: > Hi all,

Re: [PATCH v5 0/2] thermal: add brcmstb AVS TMON driver

On Thu, Oct 26, 2017 at 11:24:33AM -0700, Eduardo Valentin wrote: > On Thu, Oct 26, 2017 at 09:55:50AM -0700, Florian Fainelli wrote: > > On 09/26/2017 02:27 PM, Markus Mayer wrote: > > > From: Markus Mayer > > > > > > This series adds the brcmstb AVS TMON driver. > > > > >

Re: [PATCH v5 0/2] thermal: add brcmstb AVS TMON driver

On Thu, Oct 26, 2017 at 11:24:33AM -0700, Eduardo Valentin wrote: > On Thu, Oct 26, 2017 at 09:55:50AM -0700, Florian Fainelli wrote: > > On 09/26/2017 02:27 PM, Markus Mayer wrote: > > > From: Markus Mayer > > > > > > This series adds the brcmstb AVS TMON driver. > > > > > > The driver was

[PATCH] clockevents: Update clockevents device next_event

Usually clockevent device's next_event is updated in clockevents_program_event() and next_event indicates the next timer event on that cpu. Whenever there are no timers on a CPU, corresponding clockevent device is going into ONESHOT_STOPPED state but clockevent device next_event is not updated,

[PATCH] clockevents: Update clockevents device next_event

Usually clockevent device's next_event is updated in clockevents_program_event() and next_event indicates the next timer event on that cpu. Whenever there are no timers on a CPU, corresponding clockevent device is going into ONESHOT_STOPPED state but clockevent device next_event is not updated,

Re: KASAN: slab-out-of-bounds Read in tipc_nametbl_lookup_dst_nodes

#syz fix: tipc: eliminate KASAN warning

Re: KASAN: slab-out-of-bounds Read in tipc_nametbl_lookup_dst_nodes

#syz fix: tipc: eliminate KASAN warning

Re: general protection fault in __list_del_entry_valid

#syz fix: ipsec: Fix aborted xfrm policy dump crash

Re: general protection fault in __list_del_entry_valid

#syz fix: ipsec: Fix aborted xfrm policy dump crash

Re: KASAN: use-after-free Read in tipc_group_self

#syz fix: tipc: fix a dangling pointer

Re: KASAN: use-after-free Read in tipc_group_self

#syz fix: tipc: fix a dangling pointer

Re: [PATCH v7 0/6] vfs: Use dlock list for SB's s_inodes list

On 10/05/2017 02:43 PM, Waiman Long wrote: > > This is a follow up of the following patchset: > > [PATCH v7 0/4] vfs: Use per-cpu list for SB's s_inodes list > https://lkml.org/lkml/2016/4/12/1009 > > This patchset provides new APIs for a set of distributed locked lists > (one/CPU core) to

Re: [PATCH v7 0/6] vfs: Use dlock list for SB's s_inodes list

On 10/05/2017 02:43 PM, Waiman Long wrote: > > This is a follow up of the following patchset: > > [PATCH v7 0/4] vfs: Use per-cpu list for SB's s_inodes list > https://lkml.org/lkml/2016/4/12/1009 > > This patchset provides new APIs for a set of distributed locked lists > (one/CPU core) to

Re: [PATCH] media: av7110: switch to useing timer_setup()

Hi Dmitry, Thank you for the patch! Yet we hit a small issue. [auto build test ERROR on linuxtv-media/master] [also build test ERROR on v4.14-rc6 next-20171018] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: BUG: unable to handle kernel paging request in vsock_diag_dump

#syz fix: vsock: always call vsock_init_tables()

Re: [PATCH] media: av7110: switch to useing timer_setup()

Hi Dmitry, Thank you for the patch! Yet we hit a small issue. [auto build test ERROR on linuxtv-media/master] [also build test ERROR on v4.14-rc6 next-20171018] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: BUG: unable to handle kernel paging request in vsock_diag_dump

#syz fix: vsock: always call vsock_init_tables()

Re: [PATCH] CLK: ARC: Set initial pll output frequency specified in device tree

Hi folks, On 09/29/2017 06:13 AM, Eugeniy Paltsev wrote: Add option to set initial output frequency of plls via "clock-frequency" property in pll's device tree node. This frequency will be set while pll driver probed. The usage example is setting CPU clock frequency on boot See discussion:

Re: [PATCH] CLK: ARC: Set initial pll output frequency specified in device tree

Hi folks, On 09/29/2017 06:13 AM, Eugeniy Paltsev wrote: Add option to set initial output frequency of plls via "clock-frequency" property in pll's device tree node. This frequency will be set while pll driver probed. The usage example is setting CPU clock frequency on boot See discussion:

Re: [PATCH v5 0/2] thermal: add brcmstb AVS TMON driver

On Thu, Oct 26, 2017 at 09:55:50AM -0700, Florian Fainelli wrote: > On 09/26/2017 02:27 PM, Markus Mayer wrote: > > From: Markus Mayer > > > > This series adds the brcmstb AVS TMON driver. > > > > The driver was originally written by Brian Norris. > > Rui, Eduardo, what's

Re: [PATCH v5 0/2] thermal: add brcmstb AVS TMON driver

On Thu, Oct 26, 2017 at 09:55:50AM -0700, Florian Fainelli wrote: > On 09/26/2017 02:27 PM, Markus Mayer wrote: > > From: Markus Mayer > > > > This series adds the brcmstb AVS TMON driver. > > > > The driver was originally written by Brian Norris. > > Rui, Eduardo, what's going on here? Can

<    1   2   3   4   5   6   7   8   9   10   >