Replace -EBUSY with -ENOSPC 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 | 2
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 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
Tested-by: Christophe Leroy
---
drivers/crypto/talitos.c | 38 +-
1 file changed, 5 insertions(+)
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
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
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
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
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
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 ++---
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
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 8
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
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 ++-
Many users of kernel async. crypto services have a pattern of
starting an async. crypto op and than using a completion
to wait for it to end.
This patch set simplifies this common use case in two ways:
First, by separating the return codes of the case where a
request is queued to a backlog due to
Replace -EBUSY with -ENOSPC 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/crypto
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
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
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
Currently, squashfs fragments' cache size is only determined by
config option CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE. Users have
no way to change the value when they get the binary kernel.
Now make it be configured during booting or inserting module.
Signed-off-by: Qixuan Wu
Signed-off-by: Chen Jie
Currently, squashfs fragments' cache size is only determined by
config option CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE. Users have
no way to change the value when they get the binary kernel.
Now make it be configured during booting.
Signed-off-by: Qixuan Wu
---
Documentation/admin-guide/kernel-parame
Hi All,
Currently, squashfs fragments' cache size is only determined by
config option CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE. Users have
no way to change the value when they get the binary kernel.
Now make it be configured when booting or inserting module.
Actually, it's better that a config option i
On Tue, 17 Oct 2017 13:58:21 -0700
Guenter Roeck wrote:
> On Tue, Oct 17, 2017 at 03:36:31PM -0500, Rob Herring wrote:
> > On Thu, Oct 12, 2017 at 02:36:04PM +0200, Maciej Purski wrote:
> > > Add optional max expected current property which allows calibrating
> > > the ina sensor in order to ac
On Wednesday, October 18, 2017 2:39:24 AM CEST Rafael J. Wysocki wrote:
> On Tuesday, October 17, 2017 9:41:16 PM CEST Ulf Hansson wrote:
>
> [cut]
>
> > >
> > >> deploying this and from a middle layer point of view, all the trivial
> > >> cases supports this.
> > >
> > > These functions are wron
Hi Hocko,
On Tue, Oct 17, 2017 at 12:20:52PM +0200, Michal Hocko wrote:
> [CC Kirill]
>
> On Mon 16-10-17 17:19:16, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > This patch introduced 4 new interfaces to allocate a prepared
> > transparent huge page.
> > - alloc_transhuge_page_vm
On Tue, Oct 17, 2017 at 02:12:46PM +0300, Kirill A. Shutemov wrote:
> On Mon, Oct 16, 2017 at 05:19:16PM +0800, changbin...@intel.com wrote:
> > @@ -501,6 +501,45 @@ void prep_transhuge_page(struct page *page)
> > set_compound_page_dtor(page, TRANSHUGE_PAGE_DTOR);
> > }
> >
> > +struct page
Hi Morton,
On Tue, Oct 17, 2017 at 04:28:16PM -0700, Andrew Morton wrote:
> On Mon, 16 Oct 2017 17:19:15 +0800 changbin...@intel.com wrote:
>
> > The first one introduce new interfaces, the second one kills naming
> > confusion.
> > The aim is to remove duplicated code and simplify transparent hu
On 18 October 2017 at 02:39, Rafael J. Wysocki wrote:
> On Tuesday, October 17, 2017 9:41:16 PM CEST Ulf Hansson wrote:
>
> [cut]
>
>> >
>> >> deploying this and from a middle layer point of view, all the trivial
>> >> cases supports this.
>> >
>> > These functions are wrong, however, because they
[...]
>> Are there any major reasons why the appended patch (obviously untested) won't
>> work, then?
>
> OK, there is a reason, which is the optimizations bundled into
> pm_runtime_force_*, because (a) the device may be left in runtime suspend
> by them (in which case amba_pm_suspend_early() in m
On Wednesday, October 18, 2017 1:57:52 PM CEST Ulf Hansson wrote:
> On 18 October 2017 at 02:39, Rafael J. Wysocki wrote:
> > On Tuesday, October 17, 2017 9:41:16 PM CEST Ulf Hansson wrote:
> >
> > [cut]
> >
> >> >
> >> >> deploying this and from a middle layer point of view, all the trivial
> >>
Hi Mark,
Thanks for your comments.
On 2017/10/17 23:06, Mark Rutland wrote:
> Hi,
>
> Apologies for the delay for this review.
>
> Largely this seems to look OK, but there are a couple of things which
> stick out.
>
> On Tue, Aug 22, 2017 at 04:07:53PM +0800, Shaokun Zhang wrote:
>> +int hisi_
Hi Mark,
On 2017/10/17 23:16, Mark Rutland wrote:
> On Tue, Aug 22, 2017 at 04:07:54PM +0800, Shaokun Zhang wrote:
>> +static int hisi_l3c_pmu_init_irq(struct hisi_pmu *l3c_pmu,
>> + struct platform_device *pdev)
>> +{
>> +int irq, ret;
>> +
>> +/* Read and init
Hi Mark,
On 2017/10/17 23:18, Mark Rutland wrote:
> On Tue, Aug 22, 2017 at 04:07:55PM +0800, Shaokun Zhang wrote:
>> L3 cache coherence is maintained by Hydra Home Agent (HHA) in HiSilicon
>> SoC. This patch adds support for HHA PMU driver, Each HHA has own
>> control, counter and interrupt regis
Hi Mark,
On 2017/10/17 23:21, Mark Rutland wrote:
> On Tue, Aug 22, 2017 at 04:07:56PM +0800, Shaokun Zhang wrote:
>> This patch adds support for DDRC PMU driver in HiSilicon SoC chip, Each
>> DDRC has own control, counter and interrupt registers and is an separate
>> PMU. For each DDRC PMU, it ha
On Wed, Oct 18, 2017 at 09:33:30PM +0800, Zhangshaokun wrote:
> On 2017/10/17 23:16, Mark Rutland wrote:
> > On Tue, Aug 22, 2017 at 04:07:54PM +0800, Shaokun Zhang wrote:
> >> +static int hisi_l3c_pmu_init_data(struct platform_device *pdev,
> >> +struct hisi_pmu *l3c_pm
Hi Mark,
Thanks for your further explanation.
On 2017/10/18 21:55, Mark Rutland wrote:
> On Wed, Oct 18, 2017 at 09:33:30PM +0800, Zhangshaokun wrote:
>> On 2017/10/17 23:16, Mark Rutland wrote:
>>> On Tue, Aug 22, 2017 at 04:07:54PM +0800, Shaokun Zhang wrote:
+static int hisi_l3c_pmu_init_
[...]
>>
>> The reason why pm_runtime_force_* needs to respects the hierarchy of
>> the RPM callbacks, is because otherwise it can't safely update the
>> runtime PM status of the device.
>
> I'm not sure I follow this requirement. Why is that so?
If the PM domain controls some resources for the
-dedicated-transparent-huge-page-allocation-interfaces/20171018-230128
base: git://git.cmpxchg.org/linux-mmotm.git master
config: i386-randconfig-x003-201742 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
-dedicated-transparent-huge-page-allocation-interfaces/20171018-230128
base: git://git.cmpxchg.org/linux-mmotm.git master
config: i386-randconfig-x001-201742 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
On Mon, 16 Oct 2017 13:26:19 -0700
"Paul E. McKenney" wrote:
> OK, how about if I submit them to the 4.15 merge window, but add the
> appropriate -stable tags to get them backported? Yes, these are bugs,
> but I cannot in good conscience claim that they are v4.14 regressions.
>
> But if Jon agr
On Wed, Oct 18, 2017 at 10:03:40AM -0600, Jonathan Corbet wrote:
> On Mon, 16 Oct 2017 13:26:19 -0700
> "Paul E. McKenney" wrote:
>
> > OK, how about if I submit them to the 4.15 merge window, but add the
> > appropriate -stable tags to get them backported? Yes, these are bugs,
> > but I cannot
On Wed, 18 Oct 2017 09:27:01 -0700
"Paul E. McKenney" wrote:
> On a related topic... Is there anything that test-builds docbook prior
> to patches hitting mainline? My experience indicates that the answer is
> "no".
The zero-day robot is said to be testing for new doc-build errors, but I
haven
2017-10-14 3:02 GMT+09:00 Douglas Anderson :
> Right now there is a way to add some CFLAGS that affect target builds,
> but no way to add CFLAGS that affect host builds. Let's add a way.
> We'll document two environment variables: CFLAGS_HOST and
> CXXFLAGS_HOST.
>
> We'll document that these vari
On Tue, Oct 17, 2017 at 08:06:53AM -0700, Eduardo Valentin wrote:
> Adding myself to the list as I missed the window to be in the original patch.
>
> Cc: Jonathan Corbet
> Cc: Bart Van Assche
> Cc: Namhyung Kim
> Cc: Olof Johansson
> Cc: Juergen Gross
> Cc: Javier Martinez Canillas
> Signed-
On Sat, Sep 16, 2017 at 01:48:37PM +0200, Pavel Machek wrote:
> Fix little inconsistencies in Documentation: make case and spacing
> match surrounding text.
>
> Signed-off-by: Pavel Machek
> Reviewed-by: Darrick J. Wong
Applied, thanks.
- Ted
--
To unsub
Hi Dongjiu Geng,
On 17/10/17 15:14, Dongjiu Geng wrote:
> ARMv8.2 adds a new bit HCR_EL2.TEA which controls to
> route synchronous external aborts to EL2, and adds a
> trap control bit HCR_EL2.TERR which controls to
> trap all Non-secure EL1&0 error record accesses to EL2.
The bulk of this patch
On 10/18/2017 09:11 AM, Ulf Hansson wrote:
> [...]
>
>>>
>>> The reason why pm_runtime_force_* needs to respects the hierarchy of
>>> the RPM callbacks, is because otherwise it can't safely update the
>>> runtime PM status of the device.
>>
>> I'm not sure I follow this requirement. Why is that
On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
>
> On 10/18/2017 09:11 AM, Ulf Hansson wrote:
[...]
> >>> That's the point. We know pm_runtime_force_* works nicely for the
> >>> trivial middle-layer cases.
> >>
> >> In which cases the middle-layer callbacks don't exist,
On Wednesday, October 18, 2017 2:34:10 PM CEST Ulf Hansson wrote:
> [...]
>
> >> Are there any major reasons why the appended patch (obviously untested)
> >> won't
> >> work, then?
> >
> > OK, there is a reason, which is the optimizations bundled into
> > pm_runtime_force_*, because (a) the devic
On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote:
> [...]
>
> >>
> >> The reason why pm_runtime_force_* needs to respects the hierarchy of
> >> the RPM callbacks, is because otherwise it can't safely update the
> >> runtime PM status of the device.
> >
> > I'm not sure I follow thi
From: Rafael J. Wysocki
The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.
The problem is that some middle layer code (the PCI bus type and
the ACPI PM dom
From: Rafael J. Wysocki
There is one word too many under formatting markup in one place
in device.rst, so fix it.
Signed-off-by: Rafael J. Wysocki
---
Documentation/driver-api/pm/devices.rst |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-pm/Documentation/driver-api/pm/d
It does several fixes:
1. move the displaced ld example to its reasonale place.
2. add new example for command gzip.
3. fix 2 number errors.
4. fix format of chapter 7.x, make it looks the same as other chapters.
Signed-off-by: Cao jin
---
Documentation/kbuild/makefiles.txt | 31
55 matches
Mail list logo
