On Tue, Jan 23, 2018 at 06:53:18PM -0800, Joe Perches wrote:
> On Tue, 2018-01-23 at 23:12 +, Bart Van Assche wrote:
> > On Tue, 2018-01-23 at 04:45 -0800, Joe Perches wrote:
> > > Perhaps the email subject could be improved to describe
> > > the new macro and as well, this macro, without a pr_
On 24/01/2018 2:54 PM, tang.jun...@zte.com.cn wrote:
> From: Tang Junhui
>
> In btree_flush_write(), two places need to take a locker to
> avoid races:
>
> Firstly, we need take rcu read locker to protect the bucket_hash
> traverse, since hlist_for_each_entry_rcu() must be called under
> the pro
From: Tang Junhui
> On 24/01/2018 10:34 AM, Pony Cheng wrote:
> > Hi all,
> >
> > I'm beginner of kernel module, and I'm reading bcache codebase now.
> > But I'm very confused about many details, such as b+tree and io path.
> >
> > So, what should I do now, do you have some advices?
>
> Hi Pon
From: Tang Junhui
>On 24/01/2018 2:54 PM, tang.jun...@zte.com.cn wrote:
>> From: Tang Junhui
>>
>> In btree_flush_write(), two places need to take a locker to
>> avoid races:
>>
>> Firstly, we need take rcu read locker to protect the bucket_hash
>> traverse, since hlist_for_each_entry_rcu() mu
On 24/01/2018 5:45 PM, tang.jun...@zte.com.cn wrote:
> From: Tang Junhui
>
>> On 24/01/2018 2:54 PM, tang.jun...@zte.com.cn wrote:
>>> From: Tang Junhui
>>>
>>> In btree_flush_write(), two places need to take a locker to
>>> avoid races:
>>>
>>> Firstly, we need take rcu read locker to protect t
On 24.01.2018 08:54, tang.jun...@zte.com.cn wrote:
> From: Tang Junhui
>
> In btree_flush_write(), two places need to take a locker to
> avoid races:
>
> Firstly, we need take rcu read locker to protect the bucket_hash
> traverse, since hlist_for_each_entry_rcu() must be called under
> the pro
On Wed, 2018-01-24 at 09:03 +0100, Johannes Thumshirn wrote:
> On Tue, Jan 23, 2018 at 06:53:18PM -0800, Joe Perches wrote:
> > On Tue, 2018-01-23 at 23:12 +, Bart Van Assche wrote:
> > > On Tue, 2018-01-23 at 04:45 -0800, Joe Perches wrote:
> > > > Perhaps the email subject could be improved t
On 22/01/18 21:19, Christoph Hellwig wrote:
On Wed, Jan 17, 2018 at 08:33:59PM +0100, Heinz Mauelshagen wrote:
Enhancing IO performance compared to the kernels existing
loop driver thus better suiting respective requirements in
test setups, this patch series adds new "loop" and "ram" targets.
With the introduction of byte addressable storage devices that have low
latencies, it becomes difficult to decide how to expose these devices to
user space applications. Do we treat them as traditional block devices
or expose them as a DAX capable device? A traditional block device
allows us to
On Tue, 2018-01-23 at 11:55 +0100, Johannes Thumshirn wrote:
> Use pr_debug instead of hand craftet macros. This way it is not needed to
> re-compile the kernel to enable bsg debug outputs and it's possible to
> selectively enable specific prints.
Reviewed-by: Bart Van Assche
On 1/23/18 8:49 PM, Ming Lei wrote:
> On Tue, Jan 23, 2018 at 02:32:06PM -0700, Jens Axboe wrote:
>> On 1/23/18 10:20 AM, Eryu Guan wrote:
>>> Attributes that only implement .seq_ops are read-only, any write to
>>> them should be rejected. But currently kernel would crash when
>>> writing to such d
On 1/24/18 9:24 AM, Bart Van Assche wrote:
> On Tue, 2018-01-23 at 11:55 +0100, Johannes Thumshirn wrote:
>> Use pr_debug instead of hand craftet macros. This way it is not needed to
>> re-compile the kernel to enable bsg debug outputs and it's possible to
>> selectively enable specific prints.
>
The classic error injection mechanism, should_fail_request() does not
support use cases where more information is required (from the entire
struct bio, for example).
To that end, this patch introduces should_fail_bio(), which calls
should_fail_request() under the hood but provides a convenient
pla
On 14 Jan 2018, Coly Li said:
> Hi maintainers and folks,
>
> This patch set tries to improve bcache device failure handling, includes
> cache device and backing device failures.
>
> The basic idea to handle failed cache device is,
> - Unregister cache set
> - Detach all backing devices which are
From: Tang Junhui
Hello Kent && Nix
>
>neither of those locks are needed - rcu_read_lock() isn't needed because we
>never
>free struct btree (except at shutdown), and we're not derefing journal there
__bch_btree_node_write() is called in many places, in __bch_btree_node_write(),
before node w
OK, Thank you very much.
2018-01-24 17:34 GMT+08:00 :
> From: Tang Junhui
>
>> On 24/01/2018 10:34 AM, Pony Cheng wrote:
>> > Hi all,
>> >
>> > I'm beginner of kernel module, and I'm reading bcache codebase now.
>> > But I'm very confused about many details, such as b+tree and io path.
>> >
>> >
The only purpose of rcu_read_lock() would be to ensure the object
isn't freed out from under you. That's not an issue here.
Racing with other writers isn't a correctness issue here, and if it
was - just throwing write_lock around where you have it wouldn't be
sufficient, you'd need something much
From: Tang Junhui
Hello Kent
>The only purpose of rcu_read_lock() would be to ensure the object
>isn't freed out from under you. That's not an issue here.
>
I do not think so. In for_each_cached_btree(), we traverse all
btrees by hlist_for_each_entry_rcu(), and the hlist_for_each_entry_rcu()
sh
The function ioc_create_icq here is not called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
block/blk-mq-sched.c |2 +-
1 file changed, 1 inser
On Thu, Jan 25, 2018 at 10:46:26AM +0800, Jia-Ju Bai wrote:
> The function ioc_create_icq here is not called in atomic context.
> Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
>
> This is found by a static analysis tool named DCNS written by myself.
Umm... Some human-
On 2018/1/25 10:58, Al Viro wrote:
On Thu, Jan 25, 2018 at 10:46:26AM +0800, Jia-Ju Bai wrote:
The function ioc_create_icq here is not called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written
After checking all possible call chains to kmalloc here,
my tool finds that kmalloc is never called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
bl
On 1/24/18 7:46 PM, Jia-Ju Bai wrote:
> The function ioc_create_icq here is not called in atomic context.
> Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
>
> This is found by a static analysis tool named DCNS written by myself.
But it's running off the IO submission pa
Hello Nix,
Thursday, January 25, 2018, 1:23:19 AM, you wrote:
> On 14 Jan 2018, Coly Li said:
>> Hi maintainers and folks,
>>
>> This patch set tries to improve bcache device failure handling, includes
>> cache device and backing device failures.
>>
>> The basic idea to handle failed cache devic
On 2018/1/25 11:34, Jens Axboe wrote:
On 1/24/18 7:46 PM, Jia-Ju Bai wrote:
The function ioc_create_icq here is not called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
But it
After checking all possible call chains to init_tag_map here,
my tool finds that init_tag_map is never called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Ba
On 1/24/18 8:38 PM, Jia-Ju Bai wrote:
> After checking all possible call chains to kmalloc here,
> my tool finds that kmalloc is never called in atomic context.
> Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
>
> This is found by a static analysis tool named DCNS writte
On Thu, Jan 25, 2018 at 11:13:56AM +0800, Jia-Ju Bai wrote:
> I have checked the given call chain, and find that nvme_dev_disable in
> nvme_timeout calls mutex_lock that can sleep.
> Thus, I suppose this call chain is not in atomic context.
... or it is broken.
> Besides, how do you find that "f
On Wed, Jan 24, 2018 at 08:34:14PM -0700, Jens Axboe wrote:
> On 1/24/18 7:46 PM, Jia-Ju Bai wrote:
> > The function ioc_create_icq here is not called in atomic context.
> > Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
> >
> > This is found by a static analysis tool na
On 2018/1/25 12:16, Al Viro wrote:
On Thu, Jan 25, 2018 at 11:13:56AM +0800, Jia-Ju Bai wrote:
I have checked the given call chain, and find that nvme_dev_disable in
nvme_timeout calls mutex_lock that can sleep.
Thus, I suppose this call chain is not in atomic context.
... or it is broken.
30 matches
Mail list logo
