[PATCH resend 2/6] cdrom: factor out common open_for_* code

The open_for_audio and open_for_data copies are bitrotten in different ways already and will need to update the autoclose logic in both. Signed-off-by: Michal Suchanek --- drivers/cdrom/cdrom.c | 100 ++ 1 file changed, 36

Re: [patch -mm v2 2/3] mm, memcg: replace cgroup aware oom killer mount option with tunable

On Fri, 26 Jan 2018, Andrew Morton wrote: > > -ECONFUSED. We want to have a mount option that has the sole purpose of > > doing echo cgroup > /mnt/cgroup/memory.oom_policy? > > Approximately. Let me put it another way: can we modify your patchset > so that the mount option remains, and

Re: [patch -mm v2 2/3] mm, memcg: replace cgroup aware oom killer mount option with tunable

On Fri, 26 Jan 2018 14:20:24 -0800 (PST) David Rientjes wrote: > On Thu, 25 Jan 2018, Andrew Morton wrote: > > > > Now that each mem cgroup on the system has a memory.oom_policy tunable to > > > specify oom kill selection behavior, remove the needless "groupoom" mount > >

Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable

On Fri, 26 Jan 2018, Michal Hocko wrote: > > Could you elaborate on why specifying the oom policy for the entire > > hierarchy as part of the root mem cgroup and also for individual subtrees > > is incomplete? It allows admins to specify and delegate policy decisions > > to subtrees owners as

Re: [patch -mm v2 2/3] mm, memcg: replace cgroup aware oom killer mount option with tunable

On Thu, 25 Jan 2018, Andrew Morton wrote: > > Now that each mem cgroup on the system has a memory.oom_policy tunable to > > specify oom kill selection behavior, remove the needless "groupoom" mount > > option that requires (1) the entire system to be forced, perhaps > > unnecessarily, perhaps

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

Quoting Rob Landley (2018-01-25 18:40:54) > On 01/24/2018 09:27 PM, Taras Kondratiuk wrote: > > diff --git a/Documentation/early-userspace/buffer-format.txt > > b/Documentation/early-userspace/buffer-format.txt > > index e1fd7f9dad16..d818df4f72dc 100644 > > ---

Re: [PATCH v2 11/15] gen_init_cpio: add newcx format

Quoting Rob Landley (2018-01-25 18:40:25) > On 01/24/2018 09:27 PM, Taras Kondratiuk wrote: > > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c > > index 7a2a6d85345d..78a47a5bdcb1 100644 > > --- a/usr/gen_init_cpio.c > > +++ b/usr/gen_init_cpio.c > > @@ -10,6 +10,7 @@ > > #include > >

Re: [PATCH resend 0/6] Fix cdrom autoclose

On Fri, 2018-01-26 at 17:58 +0100, Michal Suchanek wrote: > First time I did not get any feedback for the patches. This is likely because no-one who might inspect the code saw the patches ... what list are they going to?  I'm on the block, scsi and ide mailing lists and I only saw a doc patch the

[PATCH resend 0/6] Fix cdrom autoclose

Hello, there is cdrom autoclose feature that is supposed to close the tray, wait for the disc to become ready, and then open the device. This used to work in ancient times. Then in old times there was a hack in util-linux which worked around the breakage which probably resulted from

[PATCH v2 1/6] Documentation: crypto: document crypto engine API

Signed-off-by: Corentin Labbe --- Documentation/crypto/crypto_engine.rst | 48 ++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/crypto/crypto_engine.rst diff --git a/Documentation/crypto/crypto_engine.rst

[PATCH v2 0/6] crypto: engine - Permit to enqueue all async requests

Hello The current crypto_engine support only ahash and ablkcipher request. My first patch which try to add skcipher was Nacked, it will add too many functions and adding other algs(aead, asymetric_key) will make the situation worst. This patchset remove all algs specific stuff and now only

[PATCH v2 3/6] crypto: omap: convert to new crypto engine API

This patch convert the driver to the new crypto engine API. Signed-off-by: Corentin Labbe --- drivers/crypto/omap-aes.c | 21 +++-- drivers/crypto/omap-aes.h | 3 +++ drivers/crypto/omap-des.c | 24 ++-- 3 files changed, 36

[PATCH v2 2/6] crypto: engine - Permit to enqueue all async requests

The crypto engine could actually only enqueue hash and ablkcipher request. This patch permit it to enqueue any type of crypto_async_request. Signed-off-by: Corentin Labbe Tested-by: Fabien Dessenne --- crypto/crypto_engine.c | 301

[PATCH v2 5/6] crypto: stm32-hash: convert to the new crypto engine API

This patch convert the stm32-hash driver to the new crypto engine API. Signed-off-by: Corentin Labbe Tested-by: Fabien Dessenne --- drivers/crypto/stm32/stm32-hash.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-)

[PATCH v2 6/6] crypto: stm32-cryp: convert to the new crypto engine API

This patch convert the stm32-cryp driver to the new crypto engine API. Signed-off-by: Corentin Labbe Tested-by: Fabien Dessenne --- drivers/crypto/stm32/stm32-cryp.c | 29 + 1 file changed, 21 insertions(+), 8

[PATCH v2 4/6] crypto: virtio: convert to new crypto engine API

This patch convert the driver to the new crypto engine API. Signed-off-by: Corentin Labbe --- drivers/crypto/virtio/virtio_crypto_algs.c | 16 ++-- drivers/crypto/virtio/virtio_crypto_common.h | 3 +-- drivers/crypto/virtio/virtio_crypto_core.c | 3

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On Fri, 26 Jan 2018, Victor Kamensky wrote: > On Fri, 26 Jan 2018, Henrique de Moraes Holschuh wrote: > > On Thu, 25 Jan 2018, Rob Landley wrote: > > > That said, I don't think -h newcx should emit (or recognize) the > > > "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018: > > >

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On Fri, 26 Jan 2018, Henrique de Moraes Holschuh wrote: On Thu, 25 Jan 2018, Rob Landley wrote: That said, I don't think -h newcx should emit (or recognize) the "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018: files have a length, pipes provide EOF, and each cpiox entry

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On Thu, 25 Jan 2018, Rob Landley wrote: > That said, I don't think -h newcx should emit (or recognize) the > "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018: > files have a length, pipes provide EOF, and each cpiox entry starts with > 6 bytes of c_magic anyway. (I stopped

Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable

On Thu 25-01-18 15:27:29, David Rientjes wrote: > On Thu, 25 Jan 2018, Michal Hocko wrote: > > > > As a result, this would remove patch 3/4 from the series. Do you have > > > any > > > other feedback regarding the remainder of this patch series before I > > > rebase it? > > > > Yes, and I

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On Fri, Jan 26, 2018 at 3:39 AM, Rob Landley wrote: > The problem with 1 second timestamps was you honestly could confuse > "make" about which file was newer once an exec() could complete in the > same second having done real work. That was the motivating issue causing > the