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
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 in
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 benefit of JITs?
An
On Tue, Sep 5, 2017 at 8:16 PM, Geert Uytterhoeven
wrote:
> 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...
Yup, thanks, I'll queue this
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 @@ stat
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 default
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 on the latest version of the
> "EXT4 Encry
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 deletion(-)
diff --git a/inc
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,
>
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 t
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. Ch
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 @@ static inline bool memcg_has_children(struct
> mem_cgroup *memcg)
> retur
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
> > algorithm
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 t
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
> t
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 ++
crypto/lrw.c
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 b/crypto/gcm.c
index 3
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
testmgr is starting async. crypto ops and waiting for them to complete.
Move it over to generic code doing the same.
This also provides a test of the generic crypto async. wait code.
Signed-off-by: Gilad Ben-Yossef
---
crypto/testmgr.c | 204 ++---
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 insertions(+), 26 deletions(-)
diff --git a/fs/cif
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 +++--
1 file changed, 17 insertions(+), 39 deleti
The code sample is waiting for an async. crypto op completion.
Adapt sample to use the new generic infrastructure to do the same.
This also fixes a possible data coruption bug created by the
use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait pr
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(-)
diff --git a/drivers/c
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 +--
1 file changed, 5 insertions(+), 26 d
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 deletions(-)
diff --git
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 deletions(-)
diff --git
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 prio
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 ++--
fs/cry
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 | 30 ++-
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 insertions(+), 24 deletions(-)
d
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
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
---
drivers/crypto/marvell/cesa.c | 3 +--
drivers/crypto/marvell/c
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 +-
net/ipv6/esp6.c |
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 m
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
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.
---
drivers/crypto/ccp/ccp-crypto-main.c | 8 +++-
drivers/cry
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 also. Now EBUSY return means driver
>>> has accepted, Packet should not be dro
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 i
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 i
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
>>
>> esp_output_tail() function.
>
> Good catch.
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 --git a/Documentation/media
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 +-
include/uapi/linux/dvb/dm
There's a chapter for the legacy APIs. Move the frontend DVBv3
API to it, and update the chapter's introduction accordingly.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/dvb/frontend.rst| 1 -
Documentation/media/uapi/dvb/legacy_dvb_apis.rst | 21 ++-
Hi Mauro,
On Mon, Sep 04, 2017 at 05:41:27PM -0300, Mauro Carvalho Chehab wrote:
> From: Sakari Ailus
>
> There appears to be an issue in using \small in certain cases on Sphinx
> 1.4 and 1.5. Other format documents don't use \small either, remove it
> from here as well.
>
> [mche...@s-opensour
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 we
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 met
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
> test
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 b
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 s
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 specifi
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 co
On 05/09/17 08:58, Peter Zijlstra wrote:
> 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
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 Jef
53 matches
Mail list logo
