Re: [PATCH] bcache: dont reset bio opf in bch_data_insert_start

Hi Christoph, 在 2021/1/28 星期四 下午 5:10, Dongsheng Yang 写道: Hi Christop: 在 2021/1/28 星期四 上午 1:37, Christoph Hellwig 写道: But the old code is also completely broken.  We can't just OR in the op, as that implicitly assumes the old op was 0 (REQ_OP_READ). Yes, indeed, there is an assume

Re: [PATCH] bcache: dont reset bio opf in bch_data_insert_start

Hi Christop: 在 2021/1/28 星期四 上午 1:37, Christoph Hellwig 写道: But the old code is also completely broken. We can't just OR in the op, as that implicitly assumes the old op was 0 (REQ_OP_READ). Yes, indeed, there is an assume that the op is just possible to be 0 (REQ_OP_READ) or 1

Re: [PATCH] bcache: dont reset bio opf in bch_data_insert_start

在 2021/1/26 星期二 下午 12:34, Coly Li 写道: On 1/26/21 12:32 PM, Dongsheng Yang wrote: 在 2021/1/25 星期一 下午 12:53, Coly Li 写道: On 1/25/21 12:29 PM, Dongsheng Yang wrote: commit ad0d9e76(bcache: use bio op accessors) makes the bi_opf modified by bio_set_op_attrs(). But there is a logical problem

[PATCH V2] bcache: dont reset bio opf in bch_data_insert_start

this fix, bio to nvme will flaged as (REQ_SYNC | REQ_IDLE), then fio for writing will get about 1000M/s bandwidth. Fixes: ad0d9e76a412 ("bcache: use bio op accessors") Close: EAS-60259 CC: Mike Christie Signed-off-by: Dongsheng Yang --- drivers/md/bcache/request.c | 2 +- 1 file changed, 1 i

[PATCH V3] bcache: dont reset bio opf in bch_data_insert_start

this fix, bio to nvme will flaged as (REQ_SYNC | REQ_IDLE), then fio for writing will get about 1000M/s bandwidth. Fixes: ad0d9e76a412 ("bcache: use bio op accessors") CC: Mike Christie Signed-off-by: Dongsheng Yang --- V3-V2: remove an unused close-line in commit message. drivers/md

Re: [PATCH] bcache: dont reset bio opf in bch_data_insert_start

在 2021/1/25 星期一 下午 12:53, Coly Li 写道: On 1/25/21 12:29 PM, Dongsheng Yang wrote: commit ad0d9e76(bcache: use bio op accessors) makes the bi_opf modified by bio_set_op_attrs(). But there is a logical problem in this commit: trace_bcache_cache_insert(k

[PATCH] bcache: dont reset bio opf in bch_data_insert_start

this fix, bio to nvme will flaged as (REQ_SYNC | REQ_IDLE), then fio for writing will get about 1000M/s bandwidth. Fixes: ad0d9e76a412470800c04fc4b56fc86c02d6 Signed-off-by: Dongsheng Yang --- drivers/md/bcache/request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers

Re: [PATCH] bcache: consider the fragmentation when update the writeback rate

take effect after dirty buckets percent is above that Agree with that's too aggressive to reuse writeback_percent, and that's less flexable. Okey, let's wait for your testing result. Thanx Thanks, Dongdong On Wed, Dec 9, 2020 at 10:27 AM Dongsheng Yang wrote: 在 2020/11/3 星期二 下午 8

Re: [PATCH] bcache: consider the fragmentation when update the writeback rate

在 2020/11/3 星期二 下午 8:42, Dongdong Tao 写道: From: dongdong tao Current way to calculate the writeback rate only considered the dirty sectors, this usually works fine when the fragmentation is not high, but it will give us unreasonable small rate when we are under a situation that very few

Re: [PATCH] rbd: fix spelling mistake: "reregisteration" -> "re-registration"

Hi Colin, On 03/19/2018 09:33 PM, Colin King wrote: From: Colin Ian King Trivial fix to spelling mistake in rdb_warn message text Signed-off-by: Colin Ian King --- drivers/block/rbd.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH] rbd: fix spelling mistake: "reregisteration" -> "re-registration"

Hi Colin, On 03/19/2018 09:33 PM, Colin King wrote: From: Colin Ian King Trivial fix to spelling mistake in rdb_warn message text Signed-off-by: Colin Ian King --- drivers/block/rbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/rbd.c

[tip:sched/core] sched/cpuacct: Split usage accounting into user_usage and sys_usage

Commit-ID: d740037fac7052e49450f6fa1454f1144a103b55 Gitweb: http://git.kernel.org/tip/d740037fac7052e49450f6fa1454f1144a103b55 Author: Dongsheng Yang <yangds.f...@cn.fujitsu.com> AuthorDate: Tue, 22 Mar 2016 16:37:08 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/cpuacct: Split usage accounting into user_usage and sys_usage

Commit-ID: d740037fac7052e49450f6fa1454f1144a103b55 Gitweb: http://git.kernel.org/tip/d740037fac7052e49450f6fa1454f1144a103b55 Author: Dongsheng Yang AuthorDate: Tue, 22 Mar 2016 16:37:08 +0800 Committer: Ingo Molnar CommitDate: Thu, 31 Mar 2016 10:48:54 +0200 sched/cpuacct: Split

Re: [PATCH 0/5] drivers/mtd: make several functions return bool

ccing: Brian and Richard Hi Yao, Is that really necessary? I am not sure how much benefit we can achieve from this change. Could you explain more? Yang On 03/25/2016 10:41 AM, Yaowei Bai wrote: This series only make several funcitons return bool to improve readability, no other

Re: [PATCH 0/5] drivers/mtd: make several functions return bool

ccing: Brian and Richard Hi Yao, Is that really necessary? I am not sure how much benefit we can achieve from this change. Could you explain more? Yang On 03/25/2016 10:41 AM, Yaowei Bai wrote: This series only make several funcitons return bool to improve readability, no other

[tip:sched/urgent] sched/cpuacct: Rename parameter in cpuusage_write() for readability

Commit-ID: 1a736b77a3f50910843d076623204ba6e5057dc1 Gitweb: http://git.kernel.org/tip/1a736b77a3f50910843d076623204ba6e5057dc1 Author: Dongsheng Yang <yangds.f...@cn.fujitsu.com> AuthorDate: Mon, 21 Dec 2015 19:14:42 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/urgent] sched/cpuacct: Rename parameter in cpuusage_write() for readability

Commit-ID: 1a736b77a3f50910843d076623204ba6e5057dc1 Gitweb: http://git.kernel.org/tip/1a736b77a3f50910843d076623204ba6e5057dc1 Author: Dongsheng Yang AuthorDate: Mon, 21 Dec 2015 19:14:42 +0800 Committer: Ingo Molnar CommitDate: Mon, 21 Mar 2016 10:59:29 +0100 sched/cpuacct: Rename

[tip:sched/core] sched/core: Remove duplicated sched_group_set_shares() prototype

Commit-ID: 41d93397334f3c3374810f45e7bcce9007d1a7bb Gitweb: http://git.kernel.org/tip/41d93397334f3c3374810f45e7bcce9007d1a7bb Author: Dongsheng Yang <yangds.f...@cn.fujitsu.com> AuthorDate: Wed, 13 Jan 2016 16:42:38 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/core: Remove duplicated sched_group_set_shares() prototype

Commit-ID: 41d93397334f3c3374810f45e7bcce9007d1a7bb Gitweb: http://git.kernel.org/tip/41d93397334f3c3374810f45e7bcce9007d1a7bb Author: Dongsheng Yang AuthorDate: Wed, 13 Jan 2016 16:42:38 +0800 Committer: Ingo Molnar CommitDate: Mon, 29 Feb 2016 09:53:05 +0100 sched/core: Remove

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/24/2015 12:36 AM, Eric W. Biederman wrote: Dongsheng Yang writes: [...] Hi Eric, Happy new year and sorry for the late reply. Given the other constraints on an implementation the pid namespace looks by far the one best suited to host such a sysctl if it is possible

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/24/2015 12:36 AM, Eric W. Biederman wrote: Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: [...] Hi Eric, Happy new year and sorry for the late reply. Given the other constraints on an implementation the pid namespace looks by far the one best suited to host such a

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/22/2015 05:52 AM, Eric W. Biederman wrote: Dongsheng Yang writes: On 12/20/2015 05:47 PM, Eric W. Biederman wrote: Dongsheng Yang writes: On 12/20/2015 10:37 AM, Al Viro wrote: On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: On 12/17/2015 07:23 PM, Dongsheng Yang

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/22/2015 11:12 AM, Kamezawa Hiroyuki wrote: > On 2015/12/22 6:52, Eric W. Biederman wrote: >> Dongsheng Yang writes: >> >>> On 12/20/2015 05:47 PM, Eric W. Biederman wrote: >>>> Dongsheng Yang writes: >>>> >>>>> On 12/20/201

Re: [RESEND PATCH 2/2] cpuacct: split usage into user_usage and sys_usage.

On 12/22/2015 05:33 AM, Tejun Heo wrote: On Mon, Dec 21, 2015 at 07:14:43PM +0800, Dongsheng Yang wrote: Sometimes, cpuacct.usage is not detialed enough to user to see how much usage a group used. We want to know how much time it used in user mode and how much in kernel mode. cpuusage

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/22/2015 11:12 AM, Kamezawa Hiroyuki wrote: > On 2015/12/22 6:52, Eric W. Biederman wrote: >> Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: >> >>> On 12/20/2015 05:47 PM, Eric W. Biederman wrote: >>>> Dongsheng Yang <yangds.f...@cn.fujitsu.c

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/22/2015 05:52 AM, Eric W. Biederman wrote: Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: On 12/20/2015 05:47 PM, Eric W. Biederman wrote: Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: On 12/20/2015 10:37 AM, Al Viro wrote: On Sun, Dec 20, 2015 at 10:1

Re: [RESEND PATCH 2/2] cpuacct: split usage into user_usage and sys_usage.

On 12/22/2015 05:33 AM, Tejun Heo wrote: On Mon, Dec 21, 2015 at 07:14:43PM +0800, Dongsheng Yang wrote: Sometimes, cpuacct.usage is not detialed enough to user to see how much usage a group used. We want to know how much time it used in user mode and how much in kernel mode. cpuusage

[RESEND PATCH 1/2] cpuacct: rename parameter in cpuusage_write for readability

-by: Dongsheng Yang --- kernel/sched/cpuacct.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c index dd7cbb5..9c2bbf7 100644 --- a/kernel/sched/cpuacct.c +++ b/kernel/sched/cpuacct.c @@ -145,13 +145,16 @@ static u64 cpuusage_read

[RESEND PATCH 2/2] cpuacct: split usage into user_usage and sys_usage.

/cgroup/cpuacct/cpuacct.usage /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_user /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu /sys/fs/cgroup/cpuacct/cpuacct.usage_sys /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_sys /sys/fs/cgroup/cpuacct/cpuacct.usage_user Signed-off-by: Dongsheng

[RESEND PATCH 1/2] cpuacct: rename parameter in cpuusage_write for readability

-by: Dongsheng Yang <yangds.f...@cn.fujitsu.com> --- kernel/sched/cpuacct.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c index dd7cbb5..9c2bbf7 100644 --- a/kernel/sched/cpuacct.c +++ b/kernel/sched/cpuacct.c @@ -145,13 +

[RESEND PATCH 2/2] cpuacct: split usage into user_usage and sys_usage.

/cgroup/cpuacct/cpuacct.usage /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_user /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu /sys/fs/cgroup/cpuacct/cpuacct.usage_sys /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_sys /sys/fs/cgroup/cpuacct/cpuacct.usage_user Signed-off-by: Dongsheng

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/20/2015 05:47 PM, Eric W. Biederman wrote: Dongsheng Yang writes: On 12/20/2015 10:37 AM, Al Viro wrote: On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on making core dump behaviour isolated

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/20/2015 05:47 PM, Eric W. Biederman wrote: Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: On 12/20/2015 10:37 AM, Al Viro wrote: On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/20/2015 10:37 AM, Al Viro wrote: On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern is a kernel wide setting, not belongs to a container. So we want to add core_pattern into mnt namespace

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern is a kernel wide setting, not belongs to a container. So we want to add core_pattern into mnt namespace

Re: [Propose] Isolate core_pattern in mnt namespace.

On 12/20/2015 10:37 AM, Al Viro wrote: On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern

[Propose] Isolate core_pattern in mnt namespace.

Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern is a kernel wide setting, not belongs to a container. So we want to add core_pattern into mnt namespace. What do you think about it? Yang

[Propose] Isolate core_pattern in mnt namespace.

Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern is a kernel wide setting, not belongs to a container. So we want to add core_pattern into mnt namespace. What do you think about it? Yang

[PATCH 1/2] cpuacct: rename parameter in cpuusage_write for readability

-by: Dongsheng Yang --- kernel/sched/cpuacct.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c index dd7cbb5..9c2bbf7 100644 --- a/kernel/sched/cpuacct.c +++ b/kernel/sched/cpuacct.c @@ -145,13 +145,16 @@ static u64 cpuusage_read

[PATCH 2/2] cpuacct: split usage into user_usage and sys_usage.

/cgroup/cpuacct/cpuacct.usage /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_user /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu /sys/fs/cgroup/cpuacct/cpuacct.usage_sys /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_sys /sys/fs/cgroup/cpuacct/cpuacct.usage_user Signed-off-by: Dongsheng

[PATCH 1/2] cpuacct: rename parameter in cpuusage_write for readability

-by: Dongsheng Yang <yangds.f...@cn.fujitsu.com> --- kernel/sched/cpuacct.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c index dd7cbb5..9c2bbf7 100644 --- a/kernel/sched/cpuacct.c +++ b/kernel/sched/cpuacct.c @@ -145,13 +

[PATCH 2/2] cpuacct: split usage into user_usage and sys_usage.

/cgroup/cpuacct/cpuacct.usage /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_user /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu /sys/fs/cgroup/cpuacct/cpuacct.usage_sys /sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_sys /sys/fs/cgroup/cpuacct/cpuacct.usage_user Signed-off-by: Dongsheng

Re: piping core dump to a program escapes container

On 12/09/2015 11:29 AM, Eric W. Biederman wrote: Dongsheng Yang writes: On 12/09/2015 10:26 AM, Dongsheng Yang wrote: On 10/25/2015 05:54 AM, Shayan Pooya wrote: I noticed the following core_pattern behavior in my linux box while running docker containers. I am not sure if it is bug

Re: piping core dump to a program escapes container

On 12/09/2015 04:34 PM, Bruno Prémont wrote: On Tue, 08 Dec 2015 21:29:13 -0600 Eric W. Biederman wrote: Dongsheng Yang writes: On 12/09/2015 10:26 AM, Dongsheng Yang wrote: On 10/25/2015 05:54 AM, Shayan Pooya wrote: I noticed the following core_pattern behavior in my linux box while

Re: piping core dump to a program escapes container

On 12/09/2015 02:32 PM, Eric W. Biederman wrote: Dongsheng Yang writes: On 12/09/2015 11:29 AM, Eric W. Biederman wrote: Dongsheng Yang writes: [...] There has not yet been an obvious namespace in which to stick core_pattern, and even worse exactly how to appropriate launch a process

Re: piping core dump to a program escapes container

On 12/09/2015 02:32 PM, Eric W. Biederman wrote: Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: On 12/09/2015 11:29 AM, Eric W. Biederman wrote: Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: [...] There has not yet been an obvious namespace in which to stick

Re: piping core dump to a program escapes container

On 12/09/2015 04:34 PM, Bruno Prémont wrote: On Tue, 08 Dec 2015 21:29:13 -0600 Eric W. Biederman wrote: Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: On 12/09/2015 10:26 AM, Dongsheng Yang wrote: On 10/25/2015 05:54 AM, Shayan Pooya wrote: I noticed the following core_p

Re: piping core dump to a program escapes container

On 12/09/2015 11:29 AM, Eric W. Biederman wrote: Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: On 12/09/2015 10:26 AM, Dongsheng Yang wrote: On 10/25/2015 05:54 AM, Shayan Pooya wrote: I noticed the following core_pattern behavior in my linux box while running docker containers

Re: piping core dump to a program escapes container

On 12/09/2015 11:29 AM, Eric W. Biederman wrote: Dongsheng Yang writes: [...] There has not yet been an obvious namespace in which to stick core_pattern, and even worse exactly how to appropriate launch a process in a container has not been figured out. If those tricky problems can

Re: piping core dump to a program escapes container

On 12/09/2015 10:26 AM, Dongsheng Yang wrote: On 10/25/2015 05:54 AM, Shayan Pooya wrote: I noticed the following core_pattern behavior in my linux box while running docker containers. I am not sure if it is bug, but it is inconsistent and not documented. If the core_pattern is set on the host

Re: piping core dump to a program escapes container

On 10/25/2015 05:54 AM, Shayan Pooya wrote: I noticed the following core_pattern behavior in my linux box while running docker containers. I am not sure if it is bug, but it is inconsistent and not documented. If the core_pattern is set on the host, the containers will observe and use the

Re: piping core dump to a program escapes container

On 10/25/2015 05:54 AM, Shayan Pooya wrote: I noticed the following core_pattern behavior in my linux box while running docker containers. I am not sure if it is bug, but it is inconsistent and not documented. If the core_pattern is set on the host, the containers will observe and use the

Re: piping core dump to a program escapes container

On 12/09/2015 11:29 AM, Eric W. Biederman wrote: Dongsheng Yang <yangds.f...@cn.fujitsu.com> writes: [...] There has not yet been an obvious namespace in which to stick core_pattern, and even worse exactly how to appropriate launch a process in a container has not been figured out. If

Re: piping core dump to a program escapes container

On 12/09/2015 10:26 AM, Dongsheng Yang wrote: On 10/25/2015 05:54 AM, Shayan Pooya wrote: I noticed the following core_pattern behavior in my linux box while running docker containers. I am not sure if it is bug, but it is inconsistent and not documented. If the core_pattern is set on the host

Re: [PATCH v13 2/5] gennvm: Generic NVM manager

On 10/28/2015 08:30 AM, Matias Bjørling wrote: The implementation for Open-Channel SSDs is divided into media [...] + lun->reserved_blocks = 2; /* for GC only */ + lun->vlun.id = i; + lun->vlun.lun_id = i % dev->luns_per_chnl; +

Re: [PATCH v13 2/5] gennvm: Generic NVM manager

On 10/28/2015 08:30 AM, Matias Bjørling wrote: The implementation for Open-Channel SSDs is divided into media [...] + lun->reserved_blocks = 2; /* for GC only */ + lun->vlun.id = i; + lun->vlun.lun_id = i % dev->luns_per_chnl; +

Re: [PATCH] mtd: mtdram: check offs and len in mtdram->erase

On 10/03/2015 01:38 AM, Brian Norris wrote: On Fri, Oct 02, 2015 at 03:31:33PM +0530, Sudip Mukherjee wrote: On Fri, Oct 02, 2015 at 05:39:02PM +0800, Dongsheng Yang wrote: On 10/01/2015 12:41 AM, Sudip Mukherjee wrote: We should prevent user to erasing mtd device with an unaligned offset

Re: [PATCH] mtd: mtdram: check offs and len in mtdram->erase

On 10/01/2015 12:41 AM, Sudip Mukherjee wrote: We should prevent user to erasing mtd device with an unaligned offset or length. Signed-off-by: Sudip Mukherjee --- I am not sure if I should add the Signed-off-by of Dongsheng Yang . He is the original author and he should get the credit

Re: [PATCH] mtd: mtdram: check offs and len in mtdram->erase

On 10/01/2015 12:41 AM, Sudip Mukherjee wrote: We should prevent user to erasing mtd device with an unaligned offset or length. Signed-off-by: Sudip Mukherjee <su...@vectorindia.org> --- I am not sure if I should add the Signed-off-by of Dongsheng Yang <yangds.f...@cn.fujitsu.

Re: [PATCH] mtd: mtdram: check offs and len in mtdram->erase

On 10/03/2015 01:38 AM, Brian Norris wrote: On Fri, Oct 02, 2015 at 03:31:33PM +0530, Sudip Mukherjee wrote: On Fri, Oct 02, 2015 at 05:39:02PM +0800, Dongsheng Yang wrote: On 10/01/2015 12:41 AM, Sudip Mukherjee wrote: We should prevent user to erasing mtd device with an unaligned offset

Re: Linux 4.3-rc1 build error on CentOS 5.11 "scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or directory"

On 09/12/2015 07:22 AM, Davidlohr Bueso wrote: On Fri, 11 Sep 2015, Vinson Lee wrote: Hi. With the latest Linux 4.3-rc1, I am hitting this build error on CentOS 5.11. HOSTCC scripts/sign-file scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or directory #include

Re: Linux 4.3-rc1 build error on CentOS 5.11 "scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or directory"

On 09/12/2015 07:22 AM, Davidlohr Bueso wrote: On Fri, 11 Sep 2015, Vinson Lee wrote: Hi. With the latest Linux 4.3-rc1, I am hitting this build error on CentOS 5.11. HOSTCC scripts/sign-file scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or directory #include

Re: [PATCH v7 1/5] lightnvm: Support for Open-Channel SSDs

ks: %lu sector size: %d\n", . >From 2060232d379328679b22753587d16249f01fa219 Mon Sep 17 00:00:00 2001 From: Dongsheng Yang Date: Fri, 4 Sep 2015 08:10:13 +0900 Subject: [PATCH 2/2] lightNVM: register bm in nvm_create_target if dev->bm is NULL When we create target, we need to make sure dev->bm is

Re: [PATCH v7 1/5] lightnvm: Support for Open-Channel SSDs

On 09/02/2015 06:48 PM, Matias Bjørling wrote: + +/* register with device with a supported BM */ +list_for_each_entry(bt, _bms, list) { +ret = bt->register_bm(dev); +if (ret < 0) +goto err; /* initialization failed */ +if (ret > 0) { +

Re: [PATCH v7 1/5] lightnvm: Support for Open-Channel SSDs

On 09/02/2015 06:48 PM, Matias Bjørling wrote: + +/* register with device with a supported BM */ +list_for_each_entry(bt, _bms, list) { +ret = bt->register_bm(dev); +if (ret < 0) +goto err; /* initialization failed */ +if (ret > 0) { +

Re: [PATCH v7 1/5] lightnvm: Support for Open-Channel SSDs

ks: %lu sector size: %d\n", . >From 2060232d379328679b22753587d16249f01fa219 Mon Sep 17 00:00:00 2001 From: Dongsheng Yang <yangds.f...@cn.fujitsu.com> Date: Fri, 4 Sep 2015 08:10:13 +0900 Subject: [PATCH 2/2] lightNVM: register bm in nvm_create_target if dev->bm is NULL When we create target,

Re: [PATCH v7 0/5] Support for Open-Channel SSDs

On 08/07/2015 10:29 PM, Matias Bjørling wrote: These patches implement support for Open-Channel SSDs. Applies against axboe's linux-block/for-4.3/drivers and can be found in the lkml_v7 branch at https://github.com/OpenChannelSSD/linux Any feedback is greatly appreciated. Hi Matias,

Re: [PATCH v7 1/5] lightnvm: Support for Open-Channel SSDs

On 08/07/2015 10:29 PM, Matias Bjørling wrote: Open-channel SSDs are devices that share responsibilities with the host in order to implement and maintain features that typical SSDs keep strictly in firmware. These include (i) the Flash Translation Layer (FTL), (ii) bad block management, and

Re: [PATCH v7 1/5] lightnvm: Support for Open-Channel SSDs

On 08/07/2015 10:29 PM, Matias Bjørling wrote: Open-channel SSDs are devices that share responsibilities with the host in order to implement and maintain features that typical SSDs keep strictly in firmware. These include (i) the Flash Translation Layer (FTL), (ii) bad block management, and

Re: [PATCH v7 0/5] Support for Open-Channel SSDs

On 08/07/2015 10:29 PM, Matias Bjørling wrote: These patches implement support for Open-Channel SSDs. Applies against axboe's linux-block/for-4.3/drivers and can be found in the lkml_v7 branch at https://github.com/OpenChannelSSD/linux Any feedback is greatly appreciated. Hi Matias,

Re: [PATCH 1/2] ubifs: Remove dead xattr code

On 08/26/2015 10:15 PM, Josh Cartwright wrote: On Thu, Aug 20, 2015 at 10:48:38AM +0800, Dongsheng Yang wrote: On 08/20/2015 04:35 AM, Richard Weinberger wrote: This is a partial revert of commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53 ("UBIFS: Add security.* XATTR support for the

Re: [PATCH 1/2] ubifs: Remove dead xattr code

On 08/26/2015 10:15 PM, Josh Cartwright wrote: On Thu, Aug 20, 2015 at 10:48:38AM +0800, Dongsheng Yang wrote: On 08/20/2015 04:35 AM, Richard Weinberger wrote: This is a partial revert of commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53 (UBIFS: Add security.* XATTR support for the UBIFS). Hi

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

On 08/24/2015 04:03 PM, Christoph Hellwig wrote: On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote: Back when we were writing UBIFS, we did not need direct IO, so we did not implement it. But yes, probably someone who cares could just try implementing this feature. So I think

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

On 08/24/2015 03:17 PM, Dongsheng Yang wrote: On 08/24/2015 03:18 PM, Artem Bityutskiy wrote: On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote: On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote: Basically, we need to see what is the "common practice" here,

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

On 08/24/2015 03:18 PM, Artem Bityutskiy wrote: On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote: On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote: Basically, we need to see what is the "common practice" here, and follow it. This requires a small research. What would be the

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

On 08/24/2015 04:03 PM, Christoph Hellwig wrote: On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote: Back when we were writing UBIFS, we did not need direct IO, so we did not implement it. But yes, probably someone who cares could just try implementing this feature. So I think

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

On 08/24/2015 03:18 PM, Artem Bityutskiy wrote: On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote: On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote: Basically, we need to see what is the common practice here, and follow it. This requires a small research. What would be the

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

On 08/24/2015 03:17 PM, Dongsheng Yang wrote: On 08/24/2015 03:18 PM, Artem Bityutskiy wrote: On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote: On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote: Basically, we need to see what is the common practice here, and follow

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

On 08/20/2015 02:42 PM, Richard Weinberger wrote: Yang, (Sorry if I've used your last name lately) Haha, that's fine. My friends in China all call me Dongsheng. :) Am 20.08.2015 um 05:00 schrieb Dongsheng Yang: On 08/20/2015 04:35 AM, Richard Weinberger wrote: Currently UBIFS does

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

On 08/20/2015 02:42 PM, Richard Weinberger wrote: Yang, (Sorry if I've used your last name lately) Haha, that's fine. My friends in China all call me Dongsheng. :) Am 20.08.2015 um 05:00 schrieb Dongsheng Yang: On 08/20/2015 04:35 AM, Richard Weinberger wrote: Currently UBIFS does

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

have not listed the all cons and pros of it so far. Artem, what's your opinion? Yang Cc: Dongsheng Yang Cc: dedeki...@gmail.com Suggested-by: Dave Chinner Signed-off-by: Richard Weinberger --- fs/ubifs/file.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/fs/ubifs/file.c b/fs

Re: [PATCH 1/2] ubifs: Remove dead xattr code

On 08/20/2015 04:35 AM, Richard Weinberger wrote: This is a partial revert of commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53 ("UBIFS: Add security.* XATTR support for the UBIFS"). Hi Richard, What about a full reverting of this commit. In ubifs, we *can* support any namespace of xattr

Re: [PATCH 1/2] ubifs: Remove dead xattr code

On 08/20/2015 04:35 AM, Richard Weinberger wrote: This is a partial revert of commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53 (UBIFS: Add security.* XATTR support for the UBIFS). Hi Richard, What about a full reverting of this commit. In ubifs, we *can* support any namespace of xattr

Re: [PATCH 2/2] ubifs: Allow O_DIRECT

have not listed the all cons and pros of it so far. Artem, what's your opinion? Yang Cc: Dongsheng Yang yangds.f...@cn.fujitsu.com Cc: dedeki...@gmail.com Suggested-by: Dave Chinner da...@fromorbit.com Signed-off-by: Richard Weinberger rich...@nod.at --- fs/ubifs/file.c | 10 ++ 1

Re: [PATCH] ubifs: Kill unneeded locking in ubifs_init_security

On 07/08/2015 05:46 PM, Richard Weinberger wrote: Fixes the following lockdep splat: [1.244527] = [1.245193] [ INFO: possible recursive locking detected ] [1.245193] 4.2.0-rc1+ #37 Not tainted [1.245193]

Re: [PATCH] ubifs: Kill unneeded locking in ubifs_init_security

On 07/08/2015 05:46 PM, Richard Weinberger wrote: Fixes the following lockdep splat: [1.244527] = [1.245193] [ INFO: possible recursive locking detected ] [1.245193] 4.2.0-rc1+ #37 Not tainted [1.245193]

Re: [PATCH V2] cgroup: Introduce cgroup_detach_task().

On Tue, Aug 26, 2014 at 9:35 AM, Li Zefan wrote: > On 2014/8/25 23:00, Dongsheng Yang wrote: >> On Mon, Aug 25, 2014 at 10:47 PM, Tejun Heo wrote: >>> On Mon, Aug 25, 2014 at 10:46:03PM +0800, Dongsheng Yang wrote: >>>> My point here is that attaching and deta

Re: [PATCH V2] cgroup: Introduce cgroup_detach_task().

On Mon, Aug 25, 2014 at 10:47 PM, Tejun Heo wrote: > On Mon, Aug 25, 2014 at 10:46:03PM +0800, Dongsheng Yang wrote: >> My point here is that attaching and detaching are a pair of operations. > > There is no detaching from a cgroup. A task is always attached to a > cgroup whe

Re: [PATCH] cgroup: Enable controllers for default hierarchy by default.

Hi tj, On Mon, Aug 25, 2014 at 10:40 PM, Tejun Heo wrote: > Hello, Dongsheng. > > On Mon, Aug 25, 2014 at 07:27:32PM +0800, Dongsheng Yang wrote: >> When we create a cgroup in unified hierarchy, we have to enable >> controllers in cgrp_dfl_root.subtree_control manually. F

Re: [PATCH V2] cgroup: Introduce cgroup_detach_task().

Hi tj. On Mon, Aug 25, 2014 at 10:12 PM, Tejun Heo wrote: > On Mon, Aug 25, 2014 at 07:32:10PM +0800, Dongsheng Yang wrote: >> Currently, the only method to detach a task from a cgroup is moving >> it to others. It looks not natrual to me. > > Ummm... how is this

Re: [PATCH] cgroup: Introduce cgroup_detach_task().

Sorry for the noise, :(. This patch is not a correct version. Please ignore it and I have sent a v2 for it. Thanx On 08/25/2014 07:28 PM, Dongsheng Yang wrote: Currently, the only method to detach a task from a cgroup is moving it to others. It looks not natrual to me. Inspired

[PATCH V2] cgroup: Introduce cgroup_detach_task().

old method to allow user echo "pid" without "+/-" to cgroup.procs as a attaching behavior. Signed-off-by: Dongsheng Yang --- >From v1: *Sorry for a incorrect comment in v1. kernel/cgroup.c | 61 +++-- 1 file chang

[PATCH] cgroup: Introduce cgroup_detach_task().

old method to allow user echo "pid" without "+/-" to cgroup.procs as a attaching behavior. Signed-off-by: Dongsheng Yang --- kernel/cgroup.c | 62 +++-- 1 file changed, 60 insertions(+), 2 deletions(-) diff --git a/kernel/cg

[PATCH] cgroup: Enable controllers for default hierarchy by default.

-by: Dongsheng Yang --- kernel/cgroup.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 7dc8788..70996ee 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -1267,12 +1267,9 @@ static int rebind_subsystems(struct cgroup_root

[PATCH] cgroup: fix a typo in comment.

There is no function named cgroup_enable_task_cg_links(). Instead, the correct function name in this comment should be cgroup_enabled_task_cg_lists(). Signed-off-by: Dongsheng Yang --- kernel/cgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/cgroup.c b

[PATCH] cgroup: Enable controllers for default hierarchy by default.

-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- kernel/cgroup.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 7dc8788..70996ee 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -1267,12 +1267,9 @@ static int

[PATCH] cgroup: fix a typo in comment.

There is no function named cgroup_enable_task_cg_links(). Instead, the correct function name in this comment should be cgroup_enabled_task_cg_lists(). Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- kernel/cgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH] cgroup: Introduce cgroup_detach_task().

to allow user echo pid without +/- to cgroup.procs as a attaching behavior. Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- kernel/cgroup.c | 62 +++-- 1 file changed, 60 insertions(+), 2 deletions(-) diff --git a/kernel/cgroup.c b

[PATCH V2] cgroup: Introduce cgroup_detach_task().

to allow user echo pid without +/- to cgroup.procs as a attaching behavior. Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- From v1: *Sorry for a incorrect comment in v1. kernel/cgroup.c | 61 +++-- 1 file changed, 59

  1   2   3   4   5   6   7   8   >