[BUG]kmemleak in cfq_get_queue+0x213

Hi, I notice following kmemleak warning on 4.14.65 when running blktests unreferenced object 0x88031d34f7c0 (size 240): comm "kworker/0:1", pid 18344, jiffies 4301519574 (age 3716.610s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 51 f9 bc 02 88 ff ff .Q.. d0

Re: [PATCH v2] block: ratelimite pr_err on IO path

On Fri, Apr 13, 2018 at 6:59 PM, Martin K. Petersen wrote: > > Jinpu, > > [CC:ed the mpt3sas maintainers] > > The ratelimit patch is just an attempt to treat the symptom, not the > cause. Agree. If we can fix the root cause, it will be great. > >> Thanks for asking, we

Re: [PATCH v2] block: ratelimite pr_err on IO path

On Thu, Apr 12, 2018 at 11:20 PM, Martin K. Petersen wrote: > > Jack, > >> + pr_err_ratelimited("%s: ref tag error at >> location %llu (rcvd %u)\n", > > I'm a bit concerned about dropping records of potential data loss. > > Also, what are

Re: [PATCH] block: ratelimite pr_err on IO path

On Wed, Apr 11, 2018 at 7:07 PM, Elliott, Robert (Persistent Memory) wrote: >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >> ow...@vger.kernel.org] On Behalf Of Jack Wang >> Sent: Wednesday, April 11, 2018 8:21 AM >> Subject:

Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

On Mon, Feb 5, 2018 at 5:16 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Mon, 2018-02-05 at 09:56 +0100, Jinpu Wang wrote: >> Hi Bart, >> >> My another 2 cents:) >> On Fri, Feb 2, 2018 at 6:05 PM, Bart Van Assche <bart.vanass...@wdc.com> >

Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

Hi Bart, My another 2 cents:) On Fri, Feb 2, 2018 at 6:05 PM, Bart Van Assche wrote: > On Fri, 2018-02-02 at 15:08 +0100, Roman Pen wrote: >> o Simple configuration of IBNBD: >>- Server side is completely passive: volumes do not need to be >> explicitly exported.

Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

On Fri, Feb 2, 2018 at 5:40 PM, Doug Ledford wrote: > On Fri, 2018-02-02 at 16:07 +, Bart Van Assche wrote: >> On Fri, 2018-02-02 at 15:08 +0100, Roman Pen wrote: >> > Since the first version the following was changed: >> > >> >- Load-balancing and IO fail-over using

Re: [RFC PATCH 00/28] INFINIBAND NETWORK BLOCK DEVICE (IBNBD)

Hi Sagi, On Mon, Mar 27, 2017 at 4:20 AM, Sagi Grimberg wrote: > >> This series introduces IBNBD/IBTRS kernel modules. >> >> IBNBD (InfiniBand network block device) allows for an RDMA transfer of >> block IO >> over InfiniBand network. The driver presents itself as a block

Re: [PATCH 01/28] ibtrs: add header shared between ibtrs_client and ibtrs_server

On Fri, Mar 24, 2017 at 3:31 PM, Johannes Thumshirn <jthumsh...@suse.de> wrote: > On Fri, Mar 24, 2017 at 01:54:04PM +0100, Jinpu Wang wrote: >> >> + >> >> +#define XX(a) case (a): return #a >> > >> > please no macros with retun in t

Re: [RFC PATCH 00/28] INFINIBAND NETWORK BLOCK DEVICE (IBNBD)

On Fri, Mar 24, 2017 at 2:31 PM, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On Fri, 2017-03-24 at 13:46 +0100, Jinpu Wang wrote: >> Our IBNBD project was started 3 years ago based on our need for Cloud >> Computing, NVMeOF is a bit younger. >> - IBNBD is

Re: [PATCH 01/28] ibtrs: add header shared between ibtrs_client and ibtrs_server

>> + >> +#define XX(a) case (a): return #a > > please no macros with retun in them and XX isn't quite too descriptive as > well. > > [...] > >> +static inline const char *ib_wc_opcode_str(enum ib_wc_opcode opcode) >> +{ >> + switch (opcode) { >> + XX(IB_WC_SEND); >> +

Re: [RFC PATCH 00/28] INFINIBAND NETWORK BLOCK DEVICE (IBNBD)

On Fri, Mar 24, 2017 at 1:15 PM, Johannes Thumshirn wrote: > On Fri, Mar 24, 2017 at 11:45:15AM +0100, Jack Wang wrote: >> From: Jack Wang >> >> This series introduces IBNBD/IBTRS kernel modules. >> >> IBNBD (InfiniBand network block device)

Re: [BUG] Deadlock in blk_mq_register_disk error path

On Mon, Aug 15, 2016 at 6:22 PM, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 08/15/2016 09:01 AM, Jinpu Wang wrote: >> >> It's more likely you hit another bug, my colleague Roman fix that: >> >> http://www.spinics.net/lists/linux-block/msg04552.html &

Re: Re: [BUG] Deadlock in blk_mq_register_disk error path

Hi Bart, >> >> Nope, your analysis looks correct. This should fix it: >> >> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus=6316338a94b2319abe9d3790eb9cdc56ef81ac1a > > Hi Jens, > > Will that patch be included in stable kernels? I just encountered a > deadlock with kernel v4.7 that

[BUG] Deadlock in blk_mq_register_disk error path

Hi Jens, I found in blk_mq_register_disk, we blk_mq_disable_hotplug which in turn mutex_lock(_q_mutex); queue_for_each_hw_ctx(q, hctx, i) { ret = blk_mq_register_hctx(hctx); if (ret) break; /// if about error out, we will call unregister