Tejun Heo
Reviewed-by: Tejun Heo
Acked-by: Michal Hocko
Cc: KAMEZAWA Hiroyuki
Cc: Glauber Costa
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
[wt: Backported to linux-3.10.y: adjusted context]
Signed-off-by: Wenwei Tao
---
mm/memcontrol.c
2017-07-26 21:44 GMT+08:00 Michal Hocko :
> On Wed 26-07-17 21:07:42, Wenwei Tao wrote:
>> From: Wenwei Tao
>>
>> By removing the child cgroup while the parent cgroup is
>> under reclaim, we could trigger the following ker
From: Wenwei Tao
By removing the child cgroup while the parent cgroup is
under reclaim, we could trigger the following kernel panic
on kernel 3.10:
kernel BUG at kernel/cgroup.c:893!
invalid opcode: [#1] SMP
CPU: 1
Hi,
I open the Transparent huge page and run the system and hit the bug
in huge_memory.c:
static void __split_huge_page_refcount(struct page *page)
.
.
.
/* tail_page->_mapcount cannot change */
Hi,
The original message is somehow determined to be junk mail and
rejected by the system.
Forward this message.
-- Forwarded message --
From: Wenwei Tao
Date: 2016-06-19 10:40 GMT+08:00
Subject: Re: [RFC PATCH 1/3] mm, page_alloc: free HIGHATOMIC page
directly to the allocator
From: Wenwei Tao
We might not want other migrate types pin highatomic pageblock
away since it's reserved for high order use. And also we might
not want reserve high atomic pages out of limit, we can add
check in __free_one_page but this might be costly, so just stop
the merging.
Signed-o
From: Wenwei Tao
The migratetype might get staled, pages might have become highatomic when
we try to free them to the allocator, we might not want to put highatomic
pages into other buddy lists, since they are reserved only for atomic high
order use. And also highatomic pages could have been
From: Wenwei Tao
The migratetype might get staled, pages might have become highatomic when
we try to free them to the allocator, we might not want to put highatomic
pages into other buddy lists, since they are reserved only for atomic high
order use. And also highatomic pages could have been
Hi
Something is wrong with my email, I cannot send the patch out, and
this patch commit title is not complete.
Apologize for the noise.
2016-06-18 19:45 GMT+08:00 Wenwei Tao :
> From: Wenwei Tao
>
> The migratetype might get staled, pages might have become highatomic when
> we try
From: Wenwei Tao
Some pages might have already been allocated before reserve
the pageblock as HIGHATOMIC. When free these pages, put them
directly to the allocator instead of the pcp lists since they
might have the chance to be merged to high order pages.
Signed-off-by: Wenwei Tao
---
mm
I think explicit BUG_ON may make the debug easier, since it can point
out the wrong line.
2016-05-30 16:53 GMT+08:00 Michal Hocko :
> On Mon 30-05-16 16:45:51, Wenwei Tao wrote:
>> From: Wenwei Tao
>>
>> The mem_cgroup_tree_per_node allocation might fail,
>> check tha
From: Wenwei Tao
The mem_cgroup_tree_per_node allocation might fail,
check that before continue the memcg init. Since it
is in the init phase, trigger the panic if that failure
happens.
Signed-off-by: Wenwei Tao
---
mm/memcontrol.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm
It's fine to allow the user to define a device name as long as hold
the global lock and link the targets into a global list but that may
against the idea to move the target management into media mgr.
2016-05-24 22:17 GMT+08:00 Matias Bjørling :
> On 05/23/2016 03:31 PM, Wenwei Tao wrote:
0:24 GMT+08:00 Matias Bjørling :
> On 05/23/2016 01:05 PM, Wenwei Tao wrote:
>>
>> 2016-05-23 17:16 GMT+08:00 Matias Bjørling :
>>>
>>> On 05/23/2016 11:13 AM, Wenwei Tao wrote:
>>>>
>>>>
>>>> From: Wenwei Tao
>>>>
>
2016-05-23 17:16 GMT+08:00 Matias Bjørling :
> On 05/23/2016 11:13 AM, Wenwei Tao wrote:
>>
>> From: Wenwei Tao
>>
>> We may create targets with same name on different
>> backend devices, this is not what we want, so append
>> the device name to target nam
From: Wenwei Tao
When create a target, we check whether the target is
already exist first. If the answer is no, we release
the lock and continue the creation. This cannot prevent
concurrent creation of the same target, so hold the lock
until finish the target creation.
Signed-off-by: Wenwei Tao
From: Wenwei Tao
We may create targets with same name on different
backend devices, this is not what we want, so append
the device name to target name to make the new target
name unique in the system.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/gennvm.c | 13 +++--
1 file changed
Okay, I will rebase it on for-4.8/core.
2016-05-19 20:42 GMT+08:00 Matias Bjørling :
> On 05/19/2016 08:38 AM, Wenwei Tao wrote:
>>
>> From: Wenwei Tao
>>
>> When create a target, we check whether the target is
>> already exist first. If the answer is no, we rel
That is okay with me.
2016-05-19 20:40 GMT+08:00 Matias Bjørling :
> On 05/19/2016 08:38 AM, Wenwei Tao wrote:
>>
>> From: Wenwei Tao
>>
>> Break the loop when rqd is not null to reduce
>> unnecessary schedule.
>>
>> Signed-off-by: Wenwei Tao
>&
From: Wenwei Tao
When create a target, we check whether the target is
already exist first. If the answer is no, we release
the lock and continue the creation. This cannot prevent
concurrent creation of the same target, so hold the lock
until finish the target creation.
Signed-off-by: Wenwei Tao
From: Wenwei Tao
Break the loop when rqd is not null to reduce
unnecessary schedule.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 2103e97..2915e39 100644
--- a/drivers
From: Wenwei Tao
When create css failed, before call css_free_rcu_fn,
we remove the css id and exit the percpu_ref, but we
will do these again in css_free_work_fn, so they are redundant.
Especially the css id, that would cause problem if we
remove it twice, since it may be assigned to another
bound of target's own intead of global device's.
In rrpc_block_map_update, we should use the global
physcical address to compare with the one in trans_map,
since we store the global value in it.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 39 ++--
Since we mainly use soffset in device sector size, we store
that value in rrpc->soffset to reduce doing "(ilog2(dev->sec_size) - 9)".
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/
Calculate rrpc total blocks and sectors up front, make sense
to use them. For example, we use rrpc->nr_sects to calculate rrpc
area size, but it makes no sense if we don't initialize it up front,
since it would be zero until we finish rrpc luns init.
Signed-off-by: Wenwei Tao
---
Okay, I'll send a patch to cover that change.
2016-03-31 17:11 GMT+08:00 Matias Bjørling :
> On 03/30/2016 04:28 PM, Wenwei Tao wrote:
>>
>> Since every target now has their own logical address area,
>> we should deal trans_map and rev_trans_map with relative
>>
This is okay with me.
By the way, why don't you like (sector_t)dev->sec_size *
dev->sec_per_lun * rrpc->nr_luns, the change seems smaller?
2016-03-31 18:07 GMT+08:00 Matias Bjørling :
> On 03/31/2016 11:51 AM, Wenwei Tao wrote:
>>
>> This could be work,
ero by mistake. If we move rrpc_area_init
call under the rrpc_luns_init call instead, we need a way to avoid it.
2016-03-31 16:57 GMT+08:00 Matias Bjørling :
>
>
> On 03/31/2016 10:31 AM, Wenwei Tao wrote:
>>
>> 2016-03-30 22:28 GMT+08:00 Wenwei Tao :
>>>
>>&g
2016-03-30 22:28 GMT+08:00 Wenwei Tao :
> rrpc->nr_sects is calculated after rrpc init luns succeeds,
> before that the value of rrpc->nr_sects is zero, so we cannot
> use it to calcuate rrpc area size, we use rrpc->nr_luns instead.
>
> Signed-off-by: Wenwei Tao
> ---
rrpc->nr_sects is calculated after rrpc init luns succeeds,
before that the value of rrpc->nr_sects is zero, so we cannot
use it to calcuate rrpc area size, we use rrpc->nr_luns instead.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 2 +-
1 file changed, 1 insertion(+), 1
Since every target now has their own logical address area,
we should deal trans_map and rev_trans_map with relative
logical address instead of the global one.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a
I notice that sysfs already have lun information exposed, we only need
to add some more,
2016-03-21 18:27 GMT+08:00 Matias Bjørling :
> On 03/19/2016 05:58 PM, Wenwei Tao wrote:
>>
>> Export per lun information to user, let the user
>> know more detail information ab
passed to test_and_set_bit instead of 0.
2016-03-21 18:25 GMT+08:00 Matias Bjørling :
> On 03/20/2016 06:51 AM, Wenwei Tao wrote:
>>
>> Divide the target's global reverse translation map into per lun,
>> to prepare support for the non-continuous lun target creation.
>>
>>
Divide the target's global reverse translation map into per lun,
to prepare support for the non-continuous lun target creation.
Signed-off-by: Wenwei Tao
---
Changes since v1
-fix merge/rebase mistake in rrpc_block_map_update().
-remove variables poffset and lun_offset in rrpc structure
pport,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao
---
Changes since v4
-fix target creation fail.
-move code concerning the per-lun reverse translation
map to a new patch.
Changes since v3
-limit list luns to 768, thus we don't go
above a single mem
Export per lun information to user, let the user
know more detail information about underlying device.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 59 ++-
drivers/lightnvm/gennvm.c | 34 +
include/linux
Divide the target's global reverse translation map into per lun,
to prepare support for the non-continuous lun target creation.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 183 +++
drivers/lightnvm/rrpc.h | 7 +-
include/
be zero, thus creation fails in rrpc_map_init().
goto err;
- }
I will include the changes you mentioned in the next version.
Thanks.
2016-02-18 20:35 GMT+08:00 Javier González :
>> On 16 Feb 2016, at 12:28, Wenwei Tao wrote:
>>
>> When create a target, we specify
After register null_blk devices into lightnvm, we forget
to add these devices to the the nullb_list, makes them
invisible to the null_blk driver.
Signed-off-by: Wenwei Tao
---
drivers/block/null_blk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/block/null_blk.c
Export per lun information to user, let the user
know more detail information about underlying device.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 59 ++-
drivers/lightnvm/gennvm.c | 34 +
include/linux
pport,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao
---
Changes since v3
-limit list luns to 768, thus we don't go
above a single memory page.
-move NVM_DEV_FREE_LUNS to its own patch and
rename it to NVM_DEV_LUNS_STATUS.
-insert and delete some li
okay, I agree it's good to export these information to user. Will
include these changes in the next version.
2016-02-05 20:55 GMT+08:00 Matias Bjørling :
> On 02/05/2016 03:42 AM, Wenwei Tao wrote:
>> When create a target, we specify the begin lunid and
>> the end lunid, and g
Forgot to do that.
Thanks for fixing my mistake.
2016-02-05 19:59 GMT+08:00 Matias Bjørling :
> On 02/04/2016 12:34 PM, Wenwei Tao wrote:
>> Add a bitmap of luns to indicate the status
>> of luns: inuse/available. When create targets
>> do the necessary check to avoid alloca
pport,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao
---
Changes since v2
-rebase on for-next branch
-move luns bitmap to PATCH 2
-remove the logic to dynamically select another lun than
the one requested
-implement lunid list in the lnvm ioctl interfac
rwise the targets on the device might use
the same logical addresses cause incorrect
information in the device's l2p table.
Signed-off-by: Wenwei Tao
---
Changes since v2:
-rebase on for-next branch
-make the list increase by area->begin
Changes since v1:
-rename some variables
-add pa
Add a bitmap of luns to indicate the status
of luns: inuse/available. When create targets
do the necessary check to avoid allocating luns
that are already allocated.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 5
drivers/lightnvm/gennvm.c | 18 +++
drivers
OK, I see. Will include these changes in next version.
2016-01-28 17:09 GMT+08:00 Matias Bjørling :
> On 01/28/2016 09:50 AM, Wenwei Tao wrote:
>> 2016-01-27 17:44 GMT+08:00 Matias Bjørling :
>>> On 01/26/2016 01:33 PM, Wenwei Tao wrote:
>>>> When create a target,
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index d8c7595..307db1e 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -300,8 +300,10 @@ static int
2016-01-27 17:44 GMT+08:00 Matias Bjørling :
> On 01/26/2016 01:33 PM, Wenwei Tao wrote:
>> When create a target, we specify the begin lunid and
>> the end lunid, and get the corresponding continuous
>> luns from media manager, if one of the luns is not free,
>> we
to rrpc,
but the code above indeed make me confuse about the sec and page
thing.
Hope I'm not misunderstand the code.
ps: I'm not an expert on flash, if the confusion is caused by lack of
knowledge about flash, pleas let me know.
2016-01-27 21:26 GMT+08:00 Matias Bjørling :
> On 01/2
2016-01-27 17:36 GMT+08:00 Matias Bjørling :
> On 01/27/2016 07:06 AM, Wenwei Tao wrote:
>> Thanks.
>>
>> 2016-01-27 13:52 GMT+08:00 Matias Bjørling :
>>> On 01/27/2016 03:21 AM, Wenwei Tao wrote:
>>>>
>>>> Yes, It's a spelling mistake, w
Thanks.
2016-01-27 13:52 GMT+08:00 Matias Bjørling :
> On 01/27/2016 03:21 AM, Wenwei Tao wrote:
>>
>> Yes, It's a spelling mistake, will correct it in next version.
>
>
> I can fix it in the version I apply. No problem.
Yes, It's a spelling mistake, will correct it in next version.
2016-01-26 22:52 GMT+08:00 Matias Bjørling :
> On 01/26/2016 01:33 PM, Wenwei Tao wrote:
>> We can create more than one target on a lightnvm
>> device by specifying its begin lun and end lun.
>>
>&g
pport,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao
---
Changes since v1:
-use NVM_FIXED instead NVM_C_FIXED in gennvm_get_lun
-add target creation flags check
-rebase to v4.5-rc1
drivers/lightnvm/core.c | 36 ---
drivers/lightnvm/gennvm.c
rwise the targets on the device might use
the same logical addresses cause incorrect
information in the device's l2p table.
Signed-off-by: Wenwei Tao
---
Changes since v1:
- rename some variables
- add parentheses for clarity
- make gennvm_get_area return int, and add one more sector_t* paramet
2016-01-21 17:49 GMT+08:00 Matias Bjørling :
> On 01/21/2016 10:47 AM, Wenwei Tao wrote:
>
>>
>> Currently a bitmap of luns already added into nvm_dev, every time we
>> map the luns we check the bitmap.
>> I don't quite understand why we need to add anothe
2016-01-21 15:53 GMT+08:00 Matias Bjørling :
> On 01/21/2016 08:44 AM, Wenwei Tao wrote:
>> 2016-01-20 21:19 GMT+08:00 Matias Bjørling :
>>> On 01/15/2016 12:44 PM, Wenwei Tao wrote:
>>>> When create a target, we specify the begin lunid and
>>>> the end l
2016-01-20 21:19 GMT+08:00 Matias Bjørling :
> On 01/15/2016 12:44 PM, Wenwei Tao wrote:
>> When create a target, we specify the begin lunid and
>> the end lunid, and get the corresponding continuous
>> luns from media manager, if one of the luns is not free,
>> we
2016-01-20 21:03 GMT+08:00 Matias Bjørling :
> On 01/15/2016 12:44 PM, Wenwei Tao wrote:
>> We can create more than one target on a lightnvm
>> device by specifying its begin lun and end lun.
>>
>> But only specify the physical address area is not
>> enough, we
There is no need to check whether dev's pages per block is
beyond rrpc support everytime we init a lun, we only need
to check it once before enter the lun init loop.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
d now, and will not get reclaimed
for further use.
I think we may need to put the page back when the page is not actually
used/programmed.
2016-01-04 19:24 GMT+08:00 Matias Bjørling :
> On 01/04/2016 10:54 AM, Wenwei Tao wrote:
>>
>> We allocate gcb to queue full block to the gc list,
&
We allocate gcb to queue full block to the gc list,
but gcb allocation may fail, if that happens, the
block will not get reclaimed. So add the full block
direct to the gc list, omit the queuing step.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 47
tting it back to the list,
this makes the block won't get reclaimed in the future. To solve
this issue, delete block after gcb allocation.
Signed-off-by: Wenwei Tao
---
Changed in v2:
-Advance the gcb allocation, make the debug log deliver
the correct message.
drivers/lightnvm/rrpc.c
tting it back to the list,
this makes the block won't get reclaimed in the future. To solve
this issue, delete block after gcb allocation.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/lightnvm/rrpc.c
We delete a block from the gc list before reclaim it, so
put it back to the list on its reclaim fail, otherwize
this block will not get reclaimed and be programable
in the future.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 18 ++
1 file changed, 14 insertions(+), 4
We should check last io compeltion status before
start another one.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index c0886a8..d40c140 100644
--- a/drivers/lightnvm/rrpc.c
+++ b
08:32 AM, Wenwei Tao wrote:
>>
>> after io submission failed, before free rq, delete rq from
>> rrpc's inflight list, leave no bad item in the list. And
>> free rq's ppa_list to avoid memory leak.
>>
>> Signed-off-by: Wenwei Tao
>> ---
>>
This patch is based on [PATCH] lightnvm: fix bio submission issue
https://lkml.org/lkml/2015/12/9/394
2015-12-21 15:32 GMT+08:00 Wenwei Tao :
> after io submission failed, before free rq, delete rq from
> rrpc's inflight list, leave no bad item in the list. And
> free rq'
after io submission failed, before free rq, delete rq from
rrpc's inflight list, leave no bad item in the list. And
free rq's ppa_list to avoid memory leak.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/lightnv
put bio when submission fails, since we get it
before submission. And return error when backend
device driver doesn't provide a submit_io method,
thus we can end IO properly.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/gennvm.c | 2 +-
drivers/lightnvm/rrpc.c | 4 +++-
2 files chang
when ashmem init fails, destroy the slabs, leave
no garbage.
Signed-off-by: Wenwei Tao
---
drivers/staging/android/ashmem.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 3f2a3d6
rrpc_core_init，or you have any other concerns ?
2015-12-08 3:45 GMT+08:00 Matias Bjørling :
> On Mon, Dec 7, 2015 at 1:16 PM, Wenwei Tao wrote:
>>
>> create rrpc slabs during rrpc module init,
>> thus eliminate the lock contention and slab
>> status check in rrpc_core_ini
create rrpc slabs during rrpc module init,
thus eliminate the lock contention and slab
status check in rrpc_core_init. And destroy
them when rrpc exit.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 54 ++---
1 file changed, 33 insertions
move spin_unlock(&vlun->lock) to common path to make
the code more clean.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/gennvm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/lightnvm/gennvm.c b/drivers/lightnvm/gennvm.c
index 35dde84..ce60254 10064
er can be registered later, that
> can manage a device. Only warn if a media manager fails initialization.
>
> Additionally, protect against the media managed being registered or
> deregistered while looping through available media managers. This was
> reported by Wenwei Tao.
2015-12-02 20:16 GMT+08:00 Matias Bjørling :
> The core can initialize I/Os before a media manager is registered with
> the lightnvm subsystem. Make sure that we don't call the media manager
> prematurely.
>
> Signed-off-by: Matias Bjørling
> ---
> drivers/nvme/host/lightnvm.c | 2 +-
> 1 file ch
put the allocated blks back to the free list
when the luns configure failed, to make these
blks useable to others.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/lightnvm/rrpc.c b/drivers
rrpc_get_blk use constant 0 as the input parameter
of nvm_get_blk, this may result in getting gc block
failed unexpectedly.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
Hi Matiasl
Just to let you know this patch and previous version both cannot
address 'register device with supported manager may blocked while
holding the lock' issue.
2015-11-28 3:41 GMT+08:00 Matias Bjørling :
> On 11/27/2015 01:04 PM, Wenwei Tao wrote:
>>
>> Hi Matias
lock, this is
not good.
2015-11-27 16:31 GMT+08:00 Matias Bjørling :
> On 11/27/2015 05:09 AM, Wenwei Tao wrote:
>>
>> To avoid race conditions, traverse dev, media manager,
>> and targeet lists and also register, unregister entries
>> to/from them, should be always
nvme_ns->type set to zero
Wenwei Tao (3):
lightnvm: missing nvm_lock acquire
lightnvm: handle targets when corresponding nvm device exit
nvme: change the interface between nvme and lightnvm
drivers/lightnvm/core.c | 197 ++-
drivers/nvm
block creations of new targets, remove exiting targets when
underlying device was gone.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 128 +++
include/linux/lightnvm.h | 3 ++
2 files changed, 87 insertions(+), 44 deletions(-)
diff --git
To avoid race conditions, traverse dev, media manager,
and targeet lists and also register, unregister entries
to/from them, should be always under the nvm_lock control.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 73 +
1 file changed
When nvme devices were removed, we need to handle the targets
build upon them properly: remove the existing targets, block
creations of new ones. To do this clean up job well, we
need to change the interface between nvme and lightnvm.
Signed-off-by: Wenwei Tao
---
drivers/nvme/host/lightnvm.c
/25/2015 01:42 PM, Wenwei Tao wrote:
>>
>> block creations of new targets, remove exiting targets when
>> underlying device was gone.
>>
>> Signed-off-by: Wenwei Tao
>> ---
>> drivers/lightnvm/core.c | 127
>> ++---
You are right. Reset it to zero is not necessary.
2015-11-25 23:13 GMT+08:00 Matias Bjørling :
> On 11/25/2015 01:42 PM, Wenwei Tao wrote:
>>
>> When nvme devices were removed, we need to handle the targets
>> build upon them properly: remove the existing targets, block
>
return dev;
+ up_write(&nvm_lock);
return NULL;
}
use nvm_find_nvm_dev_locked() and nvm_find_nvm_dev() properly.
2015-11-25 21:11 GMT+08:00 Wenwei Tao :
> Hi Matias
>
> Place the lock inside nvm_find_nvm_dev can make code cleaner, but
> sometime may lack of flexibilit
lot 'return'.
I just submit a patch set covering the lock issue and the target issue
mentioned before, you can have a look before you apply this patch.
Thanks.
2015-11-25 19:37 GMT+08:00 Matias Bjørling :
> On 11/25/2015 09:57 AM, Wenwei Tao wrote:
>>
>> Hi Matias
>&g
When nvme devices were removed, we need to handle the targets
build upon them properly: remove the existing targets, block
creations of new ones. To do this clean up job well, we
need to change the interface between nvme and lightnvm.
Signed-off-by: Wenwei Tao
---
drivers/nvme/host/lightnvm.c
To avoid race conditions, traverse dev, media manager,
and targeet lists and also register, unregister entries
to/from them, should be always under the nvm_lock control.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions
Hi
A couple of fixes.
Patch 1 add the missing lock aquire
Patch 2-3 handle the targets when corresponding underlying devices were removed
Wenwei Tao (3):
lightnvm: missing nvm_lock acquire
lightnvm: handle targets when corresponding nvm device exit
nvme: change the interface between nvme
block creations of new targets, remove exiting targets when
underlying device was gone.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 127 ++-
include/linux/lightnvm.h | 3 ++
2 files changed, 85 insertions(+), 45 deletions(-)
diff --git
I will send a patch for that.
2015-11-25 2:51 GMT+08:00 Matias :
> On 11/24/2015 05:03 PM, Wenwei Tao wrote:
>>
>> the target should be unreachable when underlying device was gone.
>>
>> Signed-off-by: Wenwei Tao
>> ---
>> drivers/lightnvm/core.c |
Hi Matias
I think list_for_each_entry_safe(pos, n, head, member) cannot avoid
race condition
the item point by ‘n’ can be deleted and freed in the same time we
operate on 'pos'
so lock is still necessary.
2015-11-25 2:36 GMT+08:00 Matias :
> On 11/24/2015 04:24 PM, Wenwei Tao wr
the target should be unreachable when underlying device was gone.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index f659e60..b95c6c4 100644
--- a/drivers
To avoid race conditions, traverse dev, media manager,
and targeet lists and also register, unregister entries
to/from them, should be always under the nvm_lock control.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions
This is okay with me.
2015-11-23 16:47 GMT+08:00 Matias Bjørling :
> On 11/23/2015 09:29 AM, Wenwei Tao wrote:
>>
>> free allocated nvm block and gennvm lun structures when
>> gennvm register fails, otherwise it will cause memory leak.
>>
>> Signed-off-by: Wenwei
free allocated nvm block and gennvm lun structures when
gennvm register fails, otherwise it will cause memory leak.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/gennvm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/lightnvm/gennvm.c b/drivers/lightnvm/gennvm.c
index ae1fb2b
OK, I see. Thanks for the explanation.
2015-11-23 2:34 GMT+08:00 Matias :
> On 11/22/2015 02:51 PM, Wenwei Tao wrote:
>>
>> In the original calculation, the relationships among
>> block, plane and lun was confusing, refine it on the
>> basis of Open-channelSSDInterface
I'm a new guy to flash, if I'm wrong about this patch, please correct me.
Thanks.
2015-11-22 21:51 GMT+08:00 Wenwei Tao :
> In the original calculation, the relationships among
> block, plane and lun was confusing, refine it on the
> basis of Open-channelSSDInterfaceSpecificat
1 - 100 of 113 matches
Mail list logo
