On Tue, Dec 12, 2023 at 10:47 PM Kees Cook wrote:
>
> Since "dev_search_path" can technically be as large as PATH_MAX,
> there was a risk of truncation when copying it and a second string
> into "full_path" since it was also PATH_MAX sized. The W=1 builds were
> reporting this warning:
>
> drivers
On Wed, Oct 2, 2019 at 5:42 PM Leon Romanovsky wrote:
>
> On Wed, Oct 02, 2019 at 05:15:10PM +0200, Jinpu Wang wrote:
> > On Tue, Sep 24, 2019 at 1:56 AM Bart Van Assche wrote:
> > >
> > > On 6/20/19 8:03 AM, Jack Wang wrote:
> > > > +ssize_t ibtrs_sr
On Tue, Sep 24, 2019 at 1:56 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +ssize_t ibtrs_srv_stats_rdma_to_str(struct ibtrs_srv_stats *stats,
> > + char *page, size_t len)
> > +{
> > + struct ibtrs_srv_stats_rdma_stats *r = &stats->rdma
On Tue, Sep 24, 2019 at 2:00 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +static void ibtrs_srv_dev_release(struct device *dev)
> > +{
> > + /* Nobody plays with device references, so nop */
> > +}
>
> I doubt that the above comment is correct.
>
> Thanks,
>
> Bart.
On Fri, Sep 27, 2019 at 5:11 PM Bart Van Assche wrote:
>
> On 9/27/19 8:03 AM, Jinpu Wang wrote:
> > On Tue, Sep 24, 2019 at 1:49 AM Bart Van Assche wrote:
> >> On 6/20/19 8:03 AM, Jack Wang wrote:
> >>> +static char cq_affinity_list[256] = "";
>
On Tue, Sep 24, 2019 at 1:49 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +module_param_named(max_chunk_size, max_chunk_size, int, 0444);
> > +MODULE_PARM_DESC(max_chunk_size,
> > + "Max size for each IO request, when change the unit is in
> > byte"
> > +
On Tue, Sep 24, 2019 at 1:21 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +static inline const char *ibtrs_srv_state_str(enum ibtrs_srv_state state)
> > +{
> > + switch (state) {
> > + case IBTRS_SRV_CONNECTING:
> > + return "IBTRS_SRV_CONNECTING";
> >
On Tue, Sep 24, 2019 at 1:15 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +void ibtrs_clt_update_rdma_lat(struct ibtrs_clt_stats *stats, bool read,
> > +unsigned long ms)
> > +{
> > + struct ibtrs_clt_stats_pcpu *s;
> > + int id;
> > +
t; > +static inline struct ibtrs_clt_con *to_clt_con(struct ibtrs_con *c)
> > +{
> > + return container_of(c, struct ibtrs_clt_con, c);
> > +}
> > +
> > +static inline struct ibtrs_clt_sess *to_clt_sess(struct ibtrs_sess *s)
> > +{
> > + return container_of(s, struct ibtrs_clt_sess, s);
> > +}
>
> Is it really useful to define functions for these conversions? Has it
> been considered to inline these functions?
We use them quite some places, it does make the code shorter.
Thanks
Jinpu Wang
On Tue, Sep 24, 2019 at 1:03 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +static int ibtrs_str_gid_to_sockaddr(const char *addr, size_t len,
> > + short port, struct sockaddr_storage *dst)
> > +{
> > + struct sockaddr_ib *dst_ib = (st
On Tue, Sep 24, 2019 at 12:50 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +#define P1 )
> > +#define P2 ))
> > +#define P3 )))
> > +#define P4
> > +#define P(N) P ## N
> > +
> > +#define CAT(a, ...) PRIMITIVE_CAT(a, __VA_ARGS__)
> > +#define PRIMITIVE_CAT(a, ...) a
On Thu, Sep 26, 2019 at 5:38 PM Danil Kipnis
wrote:
>
> > > Bart, would it in your opinion be OK to drop the file_io support in
> > > IBNBD entirely? We implemented this feature in the beginning of the
> > > project to see whether it could be beneficial in some use cases, but
> > > never actually
Sorry for the slow reply.
On Wed, Sep 18, 2019 at 11:46 PM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +#undef pr_fmt
> > +#define pr_fmt(fmt) KBUILD_MODNAME " L" __stringify(__LINE__) ": " fmt
>
> Same comment as for a previous patch: please do not include line number
> i
On Thu, Sep 26, 2019 at 1:43 AM Danil Kipnis
wrote:
>
> On Tue, Sep 17, 2019 at 6:36 PM Jinpu Wang wrote:
> >
> > On Sat, Sep 14, 2019 at 12:25 AM Bart Van Assche wrote:
> > >
> > > On 6/20/19 8:03 AM, Jack Wang wrote:
> > > >
On Wed, Sep 18, 2019 at 6:28 PM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +#undef pr_fmt
> > +#define pr_fmt(fmt) KBUILD_MODNAME " L" __stringify(__LINE__) ": " fmt
>
> Including the line number in all messages is too much information.
> Please don't do this. Additionally
On Sat, Sep 14, 2019 at 1:56 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > From: Roman Pen
> >
> > Signed-off-by: Danil Kipnis
> > Signed-off-by: Jack Wang
> > ---
> > MAINTAINERS | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/MAINTAIN
On Wed, Sep 18, 2019 at 5:26 PM Bart Van Assche wrote:
>
> On 9/16/19 8:39 AM, Jinpu Wang wrote:
> > - Roman's pb emal address, it's no longer valid, will fix next round.
> >
> >
> >>>
> >>>> +static inline const char *ibnbd_io_mode_str
> > +static void destroy_gen_disk(struct ibnbd_clt_dev *dev)
> > +{
> > + del_gendisk(dev->gd);
>
> > + /*
> > + * Before marking queue as dying (blk_cleanup_queue() does that)
> > + * we have to be sure that everything in-flight has gone.
> > + * Blink with freeze/unfreeze.
On Sat, Sep 14, 2019 at 1:58 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > From: Roman Pen
> >
> > README with description of major sysfs entries.
>
> Please have a look at Documentation/ABI/README and follow the
> instructions from that document.
>
> Thanks,
>
> Bart.
T
On Tue, Sep 17, 2019 at 6:46 PM Bart Van Assche wrote:
>
> On 9/17/19 6:09 AM, Jinpu Wang wrote:
> >>> +static void ibnbd_softirq_done_fn(struct request *rq)
> >>> +{
> >>> + struct ibnbd_clt_dev *dev = rq->rq_disk->private_data;
> &g
On Sat, Sep 14, 2019 at 12:25 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > + charpathname[NAME_MAX];
> [ ... ]
> > +charblk_symlink_name[NAME_MAX];
>
> Please allocate path names dynamically instead of hard-coding the upper
On Tue, Sep 17, 2019 at 5:42 PM Leon Romanovsky wrote:
>
> On Mon, Sep 16, 2019 at 06:45:17AM -0700, Bart Van Assche wrote:
> > On 9/15/19 10:27 PM, Leon Romanovsky wrote:
> > > On Sun, Sep 15, 2019 at 04:30:04PM +0200, Jinpu Wang wrote:
> > > > On Sat, Sep 14,
> > +static void ibnbd_softirq_done_fn(struct request *rq)
> > +{
> > + struct ibnbd_clt_dev *dev = rq->rq_disk->private_data;
> > + struct ibnbd_clt_session *sess = dev->sess;
> > + struct ibnbd_iu *iu;
> > +
> > + iu = blk_mq_rq_to_pdu(rq);
> > + ibnbd_put_tag(sess, iu-
On Mon, Sep 16, 2019 at 7:25 PM Bart Van Assche wrote:
>
> On 9/16/19 7:57 AM, Jinpu Wang wrote:
> >>>> +#define _IBNBD_FILEIO 0
> >>>> +#define _IBNBD_BLOCKIO 1
> >>>> +#define _IBNBD_AUTOIO 2
> >>>>
>
- Roman's pb emal address, it's no longer valid, will fix next round.
> >
> > > +static inline const char *ibnbd_io_mode_str(enum ibnbd_io_mode mode)
> > > +{
> > > + switch (mode) {
> > > + case IBNBD_FILEIO:
> > > + return "fileio";
> > > + case IBNBD_BLOCKIO:
> > > +
> > > +#define _IBNBD_FILEIO 0
> > > +#define _IBNBD_BLOCKIO 1
> > > +#define _IBNBD_AUTOIO 2
> > >
> > > +enum ibnbd_io_mode {
> > > + IBNBD_FILEIO = _IBNBD_FILEIO,
> > > + IBNBD_BLOCKIO = _IBNBD_BLOCKIO,
> > > + IBNBD_AUTOIO = _IBNBD_AUTOIO,
> > > +};
> >
> > Since the IBNBD_* and
Thanks Bart for detailed review, reply inline.
On Sat, Sep 14, 2019 at 12:10 AM Bart Van Assche wrote:
>
> On 6/20/19 8:03 AM, Jack Wang wrote:
> > +#define ibnbd_log(fn, dev, fmt, ...) ({ \
> > + __builtin_choose_expr( \
>
Sagi Grimberg 于2019年7月12日周五 下午9:40写道：
>
>
> > Hi Sagi,
> >
> Another question, from what I understand from the code, the client
> always rdma_writes data on writes (with imm) from a remote pool of
> server buffers dedicated to it. Essentially all writes are immediate (no
> rdma
Hi Sagi,
> >> Another question, from what I understand from the code, the client
> >> always rdma_writes data on writes (with imm) from a remote pool of
> >> server buffers dedicated to it. Essentially all writes are immediate (no
> >> rdma reads ever). How is that different than using send wrs to
On Tue, Jul 9, 2019 at 5:10 PM Leon Romanovsky wrote:
>
> On Thu, Jun 20, 2019 at 05:03:37PM +0200, Jack Wang wrote:
> > From: Roman Pen
> >
> > Signed-off-by: Danil Kipnis
> > Signed-off-by: Jack Wang
> > ---
> > MAINTAINERS | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > di
On Tue, Jul 9, 2019 at 3:19 PM Jason Gunthorpe wrote:
>
> On Tue, Jul 09, 2019 at 03:15:46PM +0200, Jinpu Wang wrote:
> > On Tue, Jul 9, 2019 at 2:06 PM Jason Gunthorpe wrote:
> > >
> > > On Tue, Jul 09, 2019 at 01:37:39PM +0200, Jinpu Wang wrote:
> > > &
On Tue, Jul 9, 2019 at 2:06 PM Jason Gunthorpe wrote:
>
> On Tue, Jul 09, 2019 at 01:37:39PM +0200, Jinpu Wang wrote:
> > Leon Romanovsky 于2019年7月9日周二 下午1:00写道：
> > >
> > > On Tue, Jul 09, 2019 at 11:55:03AM +0200, Danil Kipnis wrote:
> > > > Hallo
Greg KH 于2019年7月9日周二 下午1:17写道：
>
> On Tue, Jul 09, 2019 at 02:00:36PM +0300, Leon Romanovsky wrote:
> > On Tue, Jul 09, 2019 at 11:55:03AM +0200, Danil Kipnis wrote:
> > > Hallo Doug, Hallo Jason, Hallo Jens, Hallo Greg,
> > >
> > > Could you please provide some feedback to the IBNBD driver and th
Leon Romanovsky 于2019年7月9日周二 下午1:00写道：
>
> On Tue, Jul 09, 2019 at 11:55:03AM +0200, Danil Kipnis wrote:
> > Hallo Doug, Hallo Jason, Hallo Jens, Hallo Greg,
> >
> > Could you please provide some feedback to the IBNBD driver and the
> > IBTRS library?
> > So far we addressed all the requests provi
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
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 updated mpt3sas driver which
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 you doing that compels all the
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: [PATCH] block: ratelim
On Mon, Feb 5, 2018 at 5:16 PM, Bart Van Assche 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
>> wrote:
>> > On Fri, 2018-02-02 at 15:
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.
>
> That sounds like a s
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 multipath features wer
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 device on
>> client
>>
On Fri, Mar 24, 2017 at 3:20 PM, Steve Wise wrote:
>>
>> From: Jack Wang
>>
>> 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 device on
> c
On Fri, Mar 24, 2017 at 3:31 PM, Johannes Thumshirn 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 them an
On Fri, Mar 24, 2017 at 2:31 PM, Bart Van Assche
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 one of our components, part of our sof
>> +
>> +#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);
>> + XX(IB_WC_RDMA_WRIT
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) allows for an RDMA transfer of block
>> IO
>> over Inf
On Mon, Aug 15, 2016 at 6:22 PM, Bart Van Assche
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
>
>
> Hello Jinpu,
&
Hi Bart,
>>
>> Nope, your analysis looks correct. This should fix it:
>>
>> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=6316338a94b2319abe9d3790eb9cdc56ef81ac1a
>
> Hi Jens,
>
> Will that patch be included in stable kernels? I just encountered a
> deadlock with kernel v4.7 that lo
On Tue, Aug 2, 2016 at 7:21 PM, Jens Axboe wrote:
> On 08/02/2016 06:58 AM, Jinpu Wang wrote:
>>
>> Hi Jens,
>>
>> I found in blk_mq_register_disk, we blk_mq_disable_hotplug which in
>> turn mutex_lock(&all_q_mutex);
>> queue_for_each_
Hi Jens,
I found in blk_mq_register_disk, we blk_mq_disable_hotplug which in
turn mutex_lock(&all_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
unregiste
51 matches
Mail list logo
