Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

On Tue, 2017-09-05 at 10:00 -0700, Guenter Roeck wrote: > On Tue, Sep 05, 2017 at 05:01:32PM +1000, Andrew Jeffery wrote: > > Some functions exposed by pmbus core conflated errors that occurred when > > setting the page to access with errors that occurred when accessing > > registers in a page. In

Re: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

On Tue, Sep 05, 2017 at 03:44:12PM +0200, Michal Hocko wrote: > Why is this an opt out rather than opt-in? IMHO the original oom logic > should be preserved by default and specific workloads should opt in for > the cgroup aware logic. Changing the global behavior depending on > whether cgroup v2

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

From: Pavel Machek Date: Mon, 4 Sep 2017 18:25:30 +0200 > Will gcc be able to compile code that uses these automatically? That > does not sound easy to me. Can libc automatically use this in malloc() > to prevent accessing freed data when buffers are overrun? > > Is this for

Re: [v7 2/5] mm, oom: cgroup-aware OOM killer

On Tue, Sep 05, 2017 at 04:57:00PM +0200, Michal Hocko wrote: > On Mon 04-09-17 15:21:05, Roman Gushchin wrote: > [...] > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index a69d23082abf..97813c56163b 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -2649,6 +2649,213 @@

Re: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

On Tue, Sep 05, 2017 at 05:12:51PM +0200, Michal Hocko wrote: > On Tue 05-09-17 15:30:21, Roman Gushchin wrote: > > On Tue, Sep 05, 2017 at 03:44:12PM +0200, Michal Hocko wrote: > [...] > > > Why is this an opt out rather than opt-in? IMHO the original oom logic > > > should be preserved by

Re: [PATCH v2] fscrypt: add a documentation file for filesystem-level encryption

On Thu, Aug 31, 2017 at 5:02 PM, Eric Biggers wrote: > From: Eric Biggers > > Perhaps long overdue, add a documentation file for filesystem-level > encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation > directory. The new file is based loosely

[PATCH] device: Fix link to device power management documentation

Correct location as of commit 2728b2d2e5be4b82 ("PM / core / docs: Convert sleep states API document to reST"). Signed-off-by: Geert Uytterhoeven --- Note that the link was already broken before... --- include/linux/device.h | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v2] fscrypt: add a documentation file for filesystem-level encryption

Hi Michael, On Fri, Sep 01, 2017 at 05:12:28PM -0700, Michael Halcrow wrote: > > +fscrypt is only resistant to side-channel attacks, such as timing or > > +electromagnetic attacks, to the extent that the underlying Linux > > +Cryptographic API algorithms are. If a vulnerable algorithm is used, >

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

On Tue, Sep 05, 2017 at 05:01:32PM +1000, Andrew Jeffery wrote: > Some functions exposed by pmbus core conflated errors that occurred when > setting the page to access with errors that occurred when accessing > registers in a page. In some cases, this caused legitimate errors to be > hidden under

Re: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

On Tue 05-09-17 15:30:21, Roman Gushchin wrote: > On Tue, Sep 05, 2017 at 03:44:12PM +0200, Michal Hocko wrote: [...] > > Why is this an opt out rather than opt-in? IMHO the original oom logic > > should be preserved by default and specific workloads should opt in for > > the cgroup aware logic.

Re: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

On Tue, Sep 05, 2017 at 03:44:12PM +0200, Michal Hocko wrote: > I will go and check patch 2 more deeply but this is something that I > wanted to sort out first. > > On Mon 04-09-17 15:21:08, Roman Gushchin wrote: > > Introducing of cgroup-aware OOM killer changes the victim selection > >

Re: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

I will go and check patch 2 more deeply but this is something that I wanted to sort out first. On Mon 04-09-17 15:21:08, Roman Gushchin wrote: > Introducing of cgroup-aware OOM killer changes the victim selection > algorithm used by default: instead of picking the largest process, > it will pick

Re: [v7 1/5] mm, oom: refactor the oom_kill_process() function

On Mon 04-09-17 15:21:04, Roman Gushchin wrote: > The oom_kill_process() function consists of two logical parts: > the first one is responsible for considering task's children as > a potential victim and printing the debug information. > The second half is responsible for sending SIGKILL to all >

[PATCH v8 04/20] crypto: remove redundant backlog checks on EBUSY

Now that -EBUSY return code only indicates backlog queueing we can safely remove the now redundant check for the CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned. Signed-off-by: Gilad Ben-Yossef --- crypto/ahash.c| 12 +++- crypto/cts.c | 6

[PATCH v8 10/20] crypto: move gcm to generic async completion

gcm is starting an async. crypto op and waiting for it complete. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- crypto/gcm.c | 32 ++-- 1 file changed, 6 insertions(+), 26 deletions(-) diff --git a/crypto/gcm.c

[PATCH v8 09/20] crypto: move drbg to generic async completion

DRBG is starting an async. crypto op and waiting for it complete. Move it over to generic code doing the same. The code now also passes CRYPTO_TFM_REQ_MAY_SLEEP flag indicating crypto request memory allocation may use GFP_KERNEL which should be perfectly fine as the code is obviously sleeping for

[PATCH v8 14/20] cifs: move to generic async completion

cifs starts an async. crypto op and waits for their completion. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef Acked-by: Pavel Shilovsky --- fs/cifs/smb2ops.c | 30 -- 1 file changed, 4

[PATCH v8 15/20] ima: move to generic async completion

ima starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef Acked-by: Mimi Zohar --- security/integrity/ima/ima_crypto.c | 56

[PATCH v8 18/20] crypto: qce: move to generic async completion

The qce driver starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- drivers/crypto/qce/sha.c | 30 -- 1 file changed, 4 insertions(+), 26 deletions(-)

[PATCH v8 19/20] crypto: mediatek: move to generic async completion

The mediatek driver starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef Acked-by: Ryder Lee --- drivers/crypto/mediatek/mtk-aes.c | 31

[PATCH v8 17/20] crypto: talitos: move to generic async completion

The talitos driver starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- drivers/crypto/talitos.c | 38 +- 1 file changed, 5 insertions(+), 33

[PATCH v8 16/20] crypto: tcrypt: move to generic async completion

tcrypt starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- crypto/tcrypt.c | 84 + 1 file changed, 25 insertions(+), 59

[PATCH v8 13/20] dm: move dm-verity to generic async completion

dm-verity is starting async. crypto ops and waiting for them to complete. Move it over to generic code doing the same. This also avoids a future potential data coruption bug created by the use of wait_for_completion_interruptible() without dealing correctly with an interrupt aborting the wait

[PATCH v8 12/20] fscrypt: move to generic async completion

fscrypt starts several async. crypto ops and waiting for them to complete. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- fs/crypto/crypto.c | 28 fs/crypto/fname.c | 36

[PATCH v8 07/20] crypto: move algif to generic async completion

algif starts several async crypto ops and waits for their completion. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- crypto/af_alg.c | 27 --- crypto/algif_aead.c | 8 crypto/algif_hash.c |

[PATCH v8 08/20] crypto: move pub key to generic async completion

public_key_verify_signature() is starting an async crypto op and waiting for it to complete. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- crypto/asymmetric_keys/public_key.c | 28 1 file changed, 4

[PATCH v8 06/20] crypto: introduce crypto wait for async op

Invoking a possibly async. crypto op and waiting for completion while correctly handling backlog processing is a common task in the crypto API implementation and outside users of it. This patch adds a generic implementation for doing so in preparation for using it across the board instead of hand

[PATCH v8 05/20] crypto: marvell/cesa: remove redundant backlog checks on EBUSY

Now that -EBUSY return code only indicates backlog queueing we can safely remove the now redundant check for the CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned. Signed-off-by: Gilad Ben-Yossef Acked-by: Boris Brezillon ---

[PATCH v8 03/20] net: use -EAGAIN for transient busy indication

Replace -EBUSY with -EAGAIN when handling transient busy indication in the absence of backlog. Signed-off-by: Gilad Ben-Yossef --- Please squash this patch with the previous one when merging upstream. --- net/ipv4/ah4.c | 2 +- net/ipv4/esp4.c | 2 +- net/ipv6/ah6.c | 2

[PATCH v8 01/20] crypto: change transient busy return code to -EAGAIN

The crypto API was using the -EBUSY return value to indicate both a hard failure to submit a crypto operation into a transformation provider when the latter was busy and the backlog mechanism was not enabled as well as a notification that the operation was queued into the backlog when the backlog

[PATCH v8 00/20] simplify crypto wait for async op

all of the corner cases. The patch set is based upon linux-next release tagged next-20170905. Changes from v7: - Turn -EBUSY to -EAGAIN also in crypto using net code which I missed before, as has been pointed out by Harsh Jain. Changes from v6: - Fix brown paper bag compile error on marvell

[PATCH v8 02/20] crypto: ccp: use -EAGAIN for transient busy indication

Replace -EBUSY with -EAGAIN when reporting transient busy indication in the absence of backlog. Signed-off-by: Gilad Ben-Yossef Reviewed-by: Gary R Hook --- Please squash this patch with the previous one when merging upstream. ---

Re: [PATCH v7 00/19] simplify crypto wait for async op

On Tue, Sep 5, 2017 at 2:23 PM, Harsh Jain wrote: > On Sun, Sep 3, 2017 at 11:47 AM, Gilad Ben-Yossef wrote: >> On Thu, Aug 31, 2017 at 3:31 PM, Harsh Jain wrote: >>> HI Gilad, >>> >>> I think we need an update in ESP

[PATCH 0/3 v11] printk: Add new timestamps

printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock timestamp to printk messages. The local hardware clock loses time each day making it difficult to determine exactly when an issue has occurred in the kernel log, and making it difficult to determine how kernel and hardware

[PATCH 3/3 v11] printk: Add monotonic, boottime, and realtime timestamps

printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock timestamp to printk messages. The local hardware clock loses time each day making it difficult to determine exactly when an issue has occurred in the kernel log, and making it difficult to determine how kernel and hardware

Re: [PATCH v7 00/19] simplify crypto wait for async op

On Sun, Sep 3, 2017 at 11:47 AM, Gilad Ben-Yossef wrote: > On Thu, Aug 31, 2017 at 3:31 PM, Harsh Jain wrote: >> HI Gilad, >> >> I think we need an update in ESP also. Now EBUSY return means driver >> has accepted, Packet should not be dropped in >>

[PATCH] media: add qcom_camss.rst to v4l-drivers rst file

Avoid this warning: /devel/v4l/docs/Documentation/media/v4l-drivers/qcom_camss.rst:: WARNING: document isn't included in any toctree Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/v4l-drivers/index.rst | 1 + 1 file changed, 1 insertion(+) diff

[PATCH 2/2] media: dvb headers: make checkpatch happier

Adjust dvb ca.h, dmx.h and frontend.h in order to make checkpatch happier. Now, it only complains about the typedefs, and those are there just to provide backward userspace compatibility. Signed-off-by: Mauro Carvalho Chehab --- include/uapi/linux/dvb/ca.h | 2 +-

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On 05/09/17 11:03, Peter Zijlstra wrote: > On Tue, Sep 05, 2017 at 10:52:06AM +0200, Juergen Gross wrote: >>> Hmm, that might work. Could we somehow nop that call when >>> !X86_FEATURE_HYPERVISOR?, that saves native from having to do the call >>> and would be a win for everyone. >> >> So in fact

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 10:52:06AM +0200, Juergen Gross wrote: > > Hmm, that might work. Could we somehow nop that call when > > !X86_FEATURE_HYPERVISOR?, that saves native from having to do the call > > and would be a win for everyone. > > So in fact we want a "always false" shortcut for bare

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On 05/09/17 10:28, Peter Zijlstra wrote: > On Tue, Sep 05, 2017 at 10:14:21AM +0200, Juergen Gross wrote: >> On 05/09/17 10:10, Peter Zijlstra wrote: >>> On Tue, Sep 05, 2017 at 09:35:40AM +0200, Juergen Gross wrote: > So the problem with qspinlock is that it will revert to a classic >

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 10:14:21AM +0200, Juergen Gross wrote: > On 05/09/17 10:10, Peter Zijlstra wrote: > > On Tue, Sep 05, 2017 at 09:35:40AM +0200, Juergen Gross wrote: > >>> So the problem with qspinlock is that it will revert to a classic > >>> test-and-set spinlock if you don't do paravirt

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On 05/09/17 10:10, Peter Zijlstra wrote: > On Tue, Sep 05, 2017 at 09:35:40AM +0200, Juergen Gross wrote: >>> So the problem with qspinlock is that it will revert to a classic >>> test-and-set spinlock if you don't do paravirt but are running a HV. >> >> In the Xen case we just use the bare metal

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 09:35:40AM +0200, Juergen Gross wrote: > > So the problem with qspinlock is that it will revert to a classic > > test-and-set spinlock if you don't do paravirt but are running a HV. > > In the Xen case we just use the bare metal settings when xen_nopvspin > has been

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 08:57:16AM +0200, Oscar Salvador wrote: > It may be that the original patch was just to keep consistency between Xen > and KVM, and also only for testing purposes. > But we find a case when a customer of ours is running some workloads with > 1<->1 mapping between physical

[PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

Some functions exposed by pmbus core conflated errors that occurred when setting the page to access with errors that occurred when accessing registers in a page. In some cases, this caused legitimate errors to be hidden under the guise of the register not being supported. Signed-off-by: Andrew

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 08:28:10AM +0200, Juergen Gross wrote: > On 05/09/17 00:21, Davidlohr Bueso wrote: > > On Mon, 04 Sep 2017, Peter Zijlstra wrote: > > > >> For testing its trivial to hack your kernel and I don't feel this is > >> something an Admin can make reasonable decisions about. > >>

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On 05/09/17 00:21, Davidlohr Bueso wrote: > On Mon, 04 Sep 2017, Peter Zijlstra wrote: > >> For testing its trivial to hack your kernel and I don't feel this is >> something an Admin can make reasonable decisions about. >> >> So why? In general less knobs is better. > > +1. > > Also, note how