On 13/08/2017 21:51, Peng Hao wrote:
> some versions of windows guest access rtc frequently because of
> rtc as system tick.guest access rtc like this: write register index
> to 0x70, then write or read data from 0x71. writing 0x70 port is
> just as index and do nothing else. So we can use coalesce
On Mon, 14 Aug 2017, Markus Heiser wrote:
> see "Sphinx Install" Documentation/doc-guide/sphinx.rst (ATM in Jon's
> docs-next)
>
> The ReST markups currently used by the Documentation/ files are meant to be
> built with ``Sphinx`` version 1.3 or upper. If you're desiring to build
> PDF outputs
Hi Steve, Mauro,
when I generate documentation from Jon's docs-next,
I get this warning:
checking consistency... Documentation/media/v4l-drivers/imx.rst: WARNING:
document isn't included in any toctree
Is there already something on its way upstream or did you
missed adding imx.rst to Document
> Am 14.08.2017 um 09:45 schrieb Jani Nikula :
>
> On Mon, 14 Aug 2017, Markus Heiser wrote:
>> see "Sphinx Install" Documentation/doc-guide/sphinx.rst (ATM in Jon's
>> docs-next)
>>
>> The ReST markups currently used by the Documentation/ files are meant to be
>> built with ``Sphinx`` version
With Sphinx 1.6 nested numbering is reported as warning::
./input/joydev/index.rst:13: WARNING: input/joydev/joystick-api is already
assigned section numbers (nested numbered toctree?)
./media/uapi/cec/cec-funcs.rst:8: WARNING: media/uapi/cec/cec-func-open is
already assigned section numbers
according to what Documentation/doc-guide/sphinx.rst says::
The ReST markups currently used by the Documentation/ files
are meant to be built with ``Sphinx`` version 1.3 or upper.
Signed-off-by: Markus Heiser
---
Documentation/conf.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
> Am 14.08.2017 um 09:45 schrieb Jani Nikula :
>
> On Mon, 14 Aug 2017, Markus Heiser wrote:
>> see "Sphinx Install" Documentation/doc-guide/sphinx.rst (ATM in Jon's
>> docs-next)
>>
>> The ReST markups currently used by the Documentation/ files are meant to be
>> built with ``Sphinx`` version
2017-08-12 13:43 GMT+02:00 Jonathan Cameron :
> On Tue, 1 Aug 2017 16:50:26 +0200
> Bartosz Golaszewski wrote:
>
>> Implement a simple, irq_work-based framework for simulating
>> interrupts. Currently the API exposes routines for initializing and
>> deinitializing the simulator object, enqueueing
On 14 August 2017 17:54:22 GMT+08:00, Bartosz Golaszewski wrote:
>2017-08-12 13:43 GMT+02:00 Jonathan Cameron :
>> On Tue, 1 Aug 2017 16:50:26 +0200
>> Bartosz Golaszewski wrote:
>>
>>> Implement a simple, irq_work-based framework for simulating
>>> interrupts. Currently the API exposes routin
Add a resource managed version of irq_sim_init(). This can be
conveniently used in device drivers.
Signed-off-by: Bartosz Golaszewski
Acked-by: Jonathan Cameron
---
Documentation/driver-model/devres.txt | 1 +
include/linux/irq_sim.h | 4
kernel/irq_sim.c
Shrink the driver by removing the code dealing with dummy interrupts
and replacing it with calls to the irq_sim API.
Signed-off-by: Bartosz Golaszewski
Acked-by: Jonathan Cameron
Reviewed-by: Linus Walleij
---
drivers/gpio/Kconfig | 2 +-
drivers/gpio/gpio-mockup.c | 77 +---
Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated
interrupts that can be 'fired' from process context when needed and
requested just like normal interrupts. This is useful for testing and
development purposes.
Currently this code is reimplemented by every user. This series
pr
Implement a simple, irq_work-based framework for simulating
interrupts. Currently the API exposes routines for initializing and
deinitializing the simulator object, enqueueing the interrupts and
retrieving the allocated interrupt numbers based on the offset of the
dummy interrupt in the simulator s
On Tue, Aug 08, 2017 at 04:06:38PM -0700, David Rientjes wrote:
> On Tue, 1 Aug 2017, Roman Gushchin wrote:
>
> > > To the rest of the patch. I have to say I do not quite like how it is
> > > implemented. I was hoping for something much simpler which would hook
> > > into oom_evaluate_task. If a t
On Tue, Aug 08, 2017 at 04:24:32PM -0700, David Rientjes wrote:
> On Wed, 26 Jul 2017, Roman Gushchin wrote:
>
> > +Cgroup-aware OOM Killer
> > +~~~
> > +
> > +Cgroup v2 memory controller implements a cgroup-aware OOM killer.
> > +It means that it treats memory cgroups as first
On Tue, Aug 08, 2017 at 04:14:50PM -0700, David Rientjes wrote:
> On Wed, 26 Jul 2017, Roman Gushchin wrote:
>
> > Introduce a per-memory-cgroup oom_priority setting: an integer number
> > within the [-1, 1] range, which defines the order in which
> > the OOM killer selects victim memory c
On Mon, 14 Aug 2017, Bartosz Golaszewski wrote:
> Implement a simple, irq_work-based framework for simulating
> interrupts. Currently the API exposes routines for initializing and
> deinitializing the simulator object, enqueueing the interrupts and
> retrieving the allocated interrupt numbers base
2017-08-14 15:06 GMT+02:00 Thomas Gleixner :
> On Mon, 14 Aug 2017, Bartosz Golaszewski wrote:
>
>> Implement a simple, irq_work-based framework for simulating
>> interrupts. Currently the API exposes routines for initializing and
>> deinitializing the simulator object, enqueueing the interrupts an
On Mon, 14 Aug 2017, Bartosz Golaszewski wrote:
> 2017-08-14 15:06 GMT+02:00 Thomas Gleixner :
> > On Mon, 14 Aug 2017, Bartosz Golaszewski wrote:
> >
> >> Implement a simple, irq_work-based framework for simulating
> >> interrupts. Currently the API exposes routines for initializing and
> >> deini
2017-08-14 16:48 GMT+02:00 Thomas Gleixner :
> On Mon, 14 Aug 2017, Bartosz Golaszewski wrote:
>> 2017-08-14 15:06 GMT+02:00 Thomas Gleixner :
>> > On Mon, 14 Aug 2017, Bartosz Golaszewski wrote:
>> >
>> >> Implement a simple, irq_work-based framework for simulating
>> >> interrupts. Currently the
Shrink the driver by removing the code dealing with dummy interrupts
and replacing it with calls to the irq_sim API.
Signed-off-by: Bartosz Golaszewski
Acked-by: Jonathan Cameron
Reviewed-by: Linus Walleij
---
drivers/gpio/Kconfig | 2 +-
drivers/gpio/gpio-mockup.c | 77 +---
Add a resource managed version of irq_sim_init(). This can be
conveniently used in device drivers.
Signed-off-by: Bartosz Golaszewski
Acked-by: Jonathan Cameron
---
Documentation/driver-model/devres.txt | 1 +
include/linux/irq_sim.h | 4
kernel/irq/irq_sim.c
Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated
interrupts that can be 'fired' from process context when needed and
requested just like normal interrupts. This is useful for testing and
development purposes.
Currently this code is reimplemented by every user. This series
pr
Implement a simple, irq_work-based framework for simulating
interrupts. Currently the API exposes routines for initializing and
deinitializing the simulator object, enqueueing the interrupts and
retrieving the allocated interrupt numbers based on the offset of the
dummy interrupt in the simulator s
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
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
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
---
drivers/crypto/mediatek/mtk-aes.c | 31 +--
1 file changed, 5 insertions(+), 26 deletions(-)
diff --g
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 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
From: "Edward A. James"
Add the driver to monitor IBM CFF power supplies with hwmon over
pmbus.
Signed-off-by: Edward A. James
---
drivers/hwmon/pmbus/Kconfig | 10 +++
drivers/hwmon/pmbus/Makefile| 1 +
drivers/hwmon/pmbus/ibm-cffps.c | 151
From: "Edward A. James"
Signed-off-by: Edward A. James
---
Documentation/hwmon/ibm-cffps | 54 +++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/hwmon/ibm-cffps
diff --git a/Documentation/hwmon/ibm-cffps b/Documentation/hwmon/ibm-cff
From: "Edward A. James"
This series adds a hwmon pmbus driver for a POWER System power supply. The
core monitoring functionality is provided by pmbus.
Changes since v2:
* Renamed the driver again...
* Remove debugfs bool from pmbus_driver_info.
* Add comment for returning rc when reading STAT
From: "Edward A. James"
Signed-off-by: Edward A. James
---
.../devicetree/bindings/i2c/ibm,cffps1.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/ibm,cffps1.txt
diff --git a/Documentation/devicetree/bindings/i2
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
On 08/13/2017 11:46 PM, Markus Heiser wrote:
> Hi Randy,
>
>> Am 13.08.2017 um 19:29 schrieb Randy Dunlap :
>>
>> Hi,
>>
>> [on linux v4.13-rc4]
>>
>>> sphinx-build --version
>> Sphinx (sphinx-build) 1.2.3
>
> see "Sphinx Install" Documentation/doc-guide/sphinx.rst (ATM in Jon's
> docs-next)
>
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 fixes a possible data coruption bug created by the
use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait prior to the
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
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
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 ++-
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
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
---
drivers/crypto/marvell/cesa.c | 3 +--
drivers/crypto/marvell/cesa.h | 2 +-
2 files chang
Replace -EBUSY with -EAGAIN when reporting transient busy
indication in the absence of backlog.
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/ccp/ccp-crypto-main.c | 8 +++-
drivers/crypto/ccp/ccp-dev.c | 7 +--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/
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
On Mon, 14 Aug 2017, Randy Dunlap wrote:
> On 08/13/2017 11:46 PM, Markus Heiser wrote:
>> Hi Randy,
>>
>>> Am 13.08.2017 um 19:29 schrieb Randy Dunlap :
>>> Lots of ERRORs where a doc comment is of the form GPP_ (ending with a '_'):
>>>
>>> ../block/bio.c:404: ERROR: Unknown target name: "gfp".
On 08/13/2017 11:46 PM, Markus Heiser wrote:
> Hi Randy,
>
>> Am 13.08.2017 um 19:29 schrieb Randy Dunlap :
>>
>> Hi,
>>
>> [on linux v4.13-rc4]
>>
>>> sphinx-build --version
>> Sphinx (sphinx-build) 1.2.3
>
> see "Sphinx Install" Documentation/doc-guide/sphinx.rst (ATM in Jon's
> docs-next)
>
On 08/14/2017 09:15 AM, Jani Nikula wrote:
> On Mon, 14 Aug 2017, Randy Dunlap wrote:
>> On 08/13/2017 11:46 PM, Markus Heiser wrote:
>>> Hi Randy,
>>>
Am 13.08.2017 um 19:29 schrieb Randy Dunlap :
Lots of ERRORs where a doc comment is of the form GPP_ (ending with a '_'):
../b
On 08/14/2017 10:21 AM, Gilad Ben-Yossef wrote:
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
---
drivers/crypto/ccp/ccp-crypto-main.c | 8 +++-
drivers/crypto/ccp/ccp-dev.c
This patchset makes the OOM killer cgroup-aware.
v5:
- Rebased on top of Michal Hocko's patches, which have changed the
way how OOM victims becoming an access to the memory
reserves. Dropped corresponding part of this patchset
- Separated the oom_kill_process() splitting into a standal
Update cgroups v2 docs.
Signed-off-by: Roman Gushchin
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Johannes Weiner
Cc: Tetsuo Handa
Cc: David Rientjes
Cc: Tejun Heo
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kv
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
tasks sharing the mm struct with the given victim.
This co
Traditionally, the OOM killer is operating on a process level.
Under oom conditions, it finds a process with the highest oom score
and kills it.
This behavior doesn't suit well the system with many running
containers:
1) There is no fairness between containers. A small container with
few large pr
Introduce a per-memory-cgroup oom_priority setting: an integer number
within the [-1, 1] range, which defines the order in which
the OOM killer selects victim memory cgroups.
OOM killer prefers memory cgroups with larger priority if they are
populated with elegible tasks.
The oom_priority
On Mon, Aug 14, 2017 at 10:26:30AM -0500, Eddie James wrote:
> From: "Edward A. James"
>
> Signed-off-by: Edward A. James
> ---
> Documentation/hwmon/ibm-cffps | 54
> +++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/hwmon/ibm-c
On 08/14/2017 01:53 PM, Guenter Roeck wrote:
On Mon, Aug 14, 2017 at 10:26:30AM -0500, Eddie James wrote:
From: "Edward A. James"
Signed-off-by: Edward A. James
---
Documentation/hwmon/ibm-cffps | 54 +++
1 file changed, 54 insertions(+)
create m
On Fri, Aug 11, 2017 at 6:05 PM, Kees Cook wrote:
> This series is the result of Fabricio, Tyler, Will and I going around a
> few times on possible solutions for finding a way to enhance RET_KILL
> to kill the process group. There's a lot of ways this could be done,
> but I wanted something that f
On Mon, Aug 14, 2017 at 1:46 PM, Paul Moore wrote:
> On Fri, Aug 11, 2017 at 6:05 PM, Kees Cook wrote:
>> This series is the result of Fabricio, Tyler, Will and I going around a
>> few times on possible solutions for finding a way to enhance RET_KILL
>> to kill the process group. There's a lot of
On Mon, 14 Aug 2017, 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
> tasks
On Mon, Aug 14, 2017 at 02:26:20PM -0500, Eddie James wrote:
>
>
> On 08/14/2017 01:53 PM, Guenter Roeck wrote:
> >On Mon, Aug 14, 2017 at 10:26:30AM -0500, Eddie James wrote:
> >>From: "Edward A. James"
> >>
> >>Signed-off-by: Edward A. James
> >>---
> >> Documentation/hwmon/ibm-cffps | 54
>
On Mon, 14 Aug 2017, Roman Gushchin wrote:
> diff --git a/include/linux/oom.h b/include/linux/oom.h
> index 8a266e2be5a6..b7ec3bd441be 100644
> --- a/include/linux/oom.h
> +++ b/include/linux/oom.h
> @@ -39,6 +39,7 @@ struct oom_control {
> unsigned long totalpages;
> struct task_struc
On Mon, 14 Aug 2017, Roman Gushchin wrote:
> Introduce a per-memory-cgroup oom_priority setting: an integer number
> within the [-1, 1] range, which defines the order in which
> the OOM killer selects victim memory cgroups.
>
> OOM killer prefers memory cgroups with larger priority if the
On Mon, 14 Aug 2017, Roman Gushchin wrote:
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index dec5afdaa36d..22108f31e09d 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -48,6 +48,7 @@ v1 is available under Documentation/cgroup-v1/.
On Mon, 14 Aug 2017 18:21:15 +0300
Gilad Ben-Yossef wrote:
> 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
On Mon, 2017-08-14 at 18:21 +0300, Gilad Ben-Yossef wrote:
> 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 |
69 matches
Mail list logo
