Hi, Joel
On 07/29/2017 10:13 AM, Joel Fernandes wrote:
> +Michael Wang on his current email address (old one bounced). (my
> reply was to Mike Galbraith but I also meant to CC Michael Wang for
> the discussion). Thanks
Just back from vacation and saw this long long discussion...
I t
Hi, Joel
On 07/29/2017 10:13 AM, Joel Fernandes wrote:
> +Michael Wang on his current email address (old one bounced). (my
> reply was to Mike Galbraith but I also meant to CC Michael Wang for
> the discussion). Thanks
Just back from vacation and saw this long long discussion...
I t
, is there any plan on backport it in future?
Regards,
Michael Wang
, is there any plan on backport it in future?
Regards,
Michael Wang
We found the upstream fix, sorry for the noise...
Regards,
Michael Wang
On 04/11/2017 12:14 PM, Michael Wang wrote:
>
> sysfs_kf_read() expect the show() callback return the dumped
> length, while rdev_attr_show() can return the error which lead
> into overflow:
>
> BUG
We found the upstream fix, sorry for the noise...
Regards,
Michael Wang
On 04/11/2017 12:14 PM, Michael Wang wrote:
>
> sysfs_kf_read() expect the show() callback return the dumped
> length, while rdev_attr_show() can return the error which lead
> into overflow:
>
> BUG
Oops: 0003 [#1] SMP
[snip]
Call Trace:
[] ? sysfs_kf_read+0x80/0xb0
[] kernfs_fop_read+0xab/0x160
[] __vfs_read+0x28/0xd0
[] vfs_read+0x86/0x130
[] SyS_read+0x46/0xa0
[] entry_SYSCALL_64_fastpath+0x12/0x6a
Simply return 0 in case of error solved the problem.
Signed-off-by: Michael
Oops: 0003 [#1] SMP
[snip]
Call Trace:
[] ? sysfs_kf_read+0x80/0xb0
[] kernfs_fop_read+0xab/0x160
[] __vfs_read+0x28/0xd0
[] vfs_read+0x86/0x130
[] SyS_read+0x46/0xa0
[] entry_SYSCALL_64_fastpath+0x12/0x6a
Simply return 0 in case of error solved the problem.
Signed-off-by: Michael
Make sense, while still have concerns regarding the design:
* in this case since the read_disk already abandoned, is it fine to
keep r1_bio->read_disk recording the faulty device index?
* we assign the 'end_sync_write' to the original read bio in this
case, but when is this supposed to
Make sense, while still have concerns regarding the design:
* in this case since the read_disk already abandoned, is it fine to
keep r1_bio->read_disk recording the faulty device index?
* we assign the 'end_sync_write' to the original read bio in this
case, but when is this supposed to
eset the 'bi_next' after bio
is done inside request, we hit the BUG like that.
This patch simply reset the bi_next before we reuse it.
Signed-off-by: Michael Wang <yun.w...@profitbricks.com>
---
drivers/md/raid1.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drive
eset the 'bi_next' after bio
is done inside request, we hit the BUG like that.
This patch simply reset the bi_next before we reuse it.
Signed-off-by: Michael Wang
---
drivers/md/raid1.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid
On 04/04/2017 02:24 PM, Michael Wang wrote:
> On 04/04/2017 12:23 PM, Michael Wang wrote:
> [snip]
>>> add something like
>>> if (wbio->bi_next)
>>> printk("bi_next!= NULL i=%d read_disk=%d bi_end_io=%pf\n",
>>> i, r1_bi
On 04/04/2017 02:24 PM, Michael Wang wrote:
> On 04/04/2017 12:23 PM, Michael Wang wrote:
> [snip]
>>> add something like
>>> if (wbio->bi_next)
>>> printk("bi_next!= NULL i=%d read_disk=%d bi_end_io=%pf\n",
>>> i, r1_bi
On 04/04/2017 12:23 PM, Michael Wang wrote:
[snip]
>> add something like
>> if (wbio->bi_next)
>> printk("bi_next!= NULL i=%d read_disk=%d bi_end_io=%pf\n",
>> i, r1_bio->read_disk, wbio->bi_end_io);
>>
>> that might help n
On 04/04/2017 12:23 PM, Michael Wang wrote:
[snip]
>> add something like
>> if (wbio->bi_next)
>> printk("bi_next!= NULL i=%d read_disk=%d bi_end_io=%pf\n",
>> i, r1_bio->read_disk, wbio->bi_end_io);
>>
>> that might help n
On 04/04/2017 11:37 AM, NeilBrown wrote:
> On Tue, Apr 04 2017, Michael Wang wrote:
[snip]
>>>
>>> If sync_request_write() is using a bio that has already been used, it
>>> should call bio_reset() and fill in the details again.
>>> However I don't see
On 04/04/2017 11:37 AM, NeilBrown wrote:
> On Tue, Apr 04 2017, Michael Wang wrote:
[snip]
>>>
>>> If sync_request_write() is using a bio that has already been used, it
>>> should call bio_reset() and fill in the details again.
>>> However I don't see
Hi, Neil
On 04/03/2017 11:25 PM, NeilBrown wrote:
> On Mon, Apr 03 2017, Michael Wang wrote:
>
>> blk_attempt_plug_merge() try to merge bio into request and chain them
>> by 'bi_next', while after the bio is done inside request, we forgot to
>> reset the 'bi_next'.
>&g
Hi, Neil
On 04/03/2017 11:25 PM, NeilBrown wrote:
> On Mon, Apr 03 2017, Michael Wang wrote:
>
>> blk_attempt_plug_merge() try to merge bio into request and chain them
>> by 'bi_next', while after the bio is done inside request, we forgot to
>> reset the 'bi_next'.
>&g
pen.
Signed-off-by: Michael Wang <yun.w...@profitbricks.com>
---
block/blk-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 43b7d06..91223b2 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2619,8 +2619,1
pen.
Signed-off-by: Michael Wang
---
block/blk-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 43b7d06..91223b2 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2619,8 +2619,10 @@ bool blk_update_request(struct request *
are we still planning to have this fix
in upstream?
Regards,
Michael Wang
On 07/11/2016 04:10 PM, Lars Ellenberg wrote:
> For a long time, generic_make_request() converts recursion into
> iteration by queuing recursive arguments on current->bio_list.
>
> This is convenient for s
are we still planning to have this fix
in upstream?
Regards,
Michael Wang
On 07/11/2016 04:10 PM, Lars Ellenberg wrote:
> For a long time, generic_make_request() converts recursion into
> iteration by queuing recursive arguments on current->bio_list.
>
> This is convenient for s
k->minors, NULL,
exact_match, exact_lock, disk);
to prevent the following NULL pointer dereference and hard lockup?
Regards,
Michael Wang
Sep 29 09:53:28 st401b-3 systemd[1]: Starting Update UTMP about System Runlevel
Changes...
Sep 29 09:53:28 st401b-3 ntpd[4970]: Listen and drop on 1 v6wildcard :: UDP 1
k->minors, NULL,
exact_match, exact_lock, disk);
to prevent the following NULL pointer dereference and hard lockup?
Regards,
Michael Wang
Sep 29 09:53:28 st401b-3 systemd[1]: Starting Update UTMP about System Runlevel
Changes...
Sep 29 09:53:28 st401b-3 ntpd[4970]: Listen and drop on 1 v6wildcard :: UDP 1
On 12/16/2015 07:16 PM, Jason Gunthorpe wrote:
> On Wed, Dec 16, 2015 at 11:26:39AM +0100, Michael Wang wrote:
[snip]
>>
>> I've rechecked the ib_init_ah_from_path() again, and found it
>> still set IB_AH_GRH when the GID cache missing, but with:
On 12/16/2015 07:16 PM, Jason Gunthorpe wrote:
> On Wed, Dec 16, 2015 at 11:26:39AM +0100, Michael Wang wrote:
[snip]
>>
>> I've rechecked the ib_init_ah_from_path() again, and found it
>> still set IB_AH_GRH when the GID cache missing, but with:
On 12/15/2015 06:30 PM, Jason Gunthorpe wrote:
> On Tue, Dec 15, 2015 at 05:38:34PM +0100, Michael Wang wrote:
>> The hop_limit is only suggest that the package allowed to be
>> routed, not have to, correct?
>
> If the hop limit is >= 2 (?) then the GRH is mandato
On 12/15/2015 06:30 PM, Jason Gunthorpe wrote:
> On Tue, Dec 15, 2015 at 05:38:34PM +0100, Michael Wang wrote:
>> The hop_limit is only suggest that the package allowed to be
>> routed, not have to, correct?
>
> If the hop limit is >= 2 (?) then the GRH is mandato
if the transport don't require GRH?
eg inside the same subnet?
The hop_limit is only suggest that the package allowed to be
routed, not have to, correct?
Regards,
Michael Wang
> + if (ret)
> + return ret;
> +
> av->timeout = path->packet_life_time + 1;
>
>
ondering what if the transport don't require GRH?
eg inside the same subnet?
The hop_limit is only suggest that the package allowed to be
routed, not have to, correct?
Regards,
Michael Wang
> + if (ret)
> + return ret;
> +
> av->timeout = path->pac
n the GID table, but such connections
> would fail later on when creating a QP, right?
Me too think this need a reconsider, to me the current logical don't
really care the missing gid in cache when initializing AV, I'm not
sure if it's necessary to fail all the following path for such cache
missing..
erstand correctly, this will
> fail only when the SGID isn't found in the GID table, but such connections
> would fail later on when creating a QP, right?
Me too think this need a reconsider, to me the current logical don't
really care the missing gid in cache when initiali
dditional annotations or specific page
> alloc API. However, this has its own drawbacks in terms of code
> complexity (potentially outside mm/kmemleak.c) and overhead.
Thanks for the very nice explain :-) I used to thought overhead is
the only concern, missing the point regarding al
n of page flags, additional annotations or specific page
> alloc API. However, this has its own drawbacks in terms of code
> complexity (potentially outside mm/kmemleak.c) and overhead.
Thanks for the very nice explain :-) I used to thought overhead is
the only concern, missing the point r
On 12/02/2015 03:13 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 03:09:18PM +0100, Michael Wang wrote:
>> This tool will help improve the kernel, AFAIK it's already made it's
>> best, if you got any idea on how to make it even better that would be
>> great, but at
On 12/02/2015 02:59 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:48:47PM +0100, Michael Wang wrote:
>> I'm not sure why amd-iommu use get_page not kmalloc to initialize the
>> pointer table, but if it's necessary then the conflict will be there,
>> it's no
On 12/02/2015 02:40 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:18:44PM +0100, Michael Wang wrote:
[snip]
>
>> Yeah, but it would be better to solve it, otherwise whoever saw this
>> report will need to go into the amd-iommu, make sure it's not a real
&g
Hi, Borislav
On 12/02/2015 02:13 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:01:55PM +0100, Michael Wang wrote:
>> Yeah.. it's a little complicated since we have our own kernel tree and this
>> won't be a problem for us, but we really prefer to help fix it in mainline
On 12/02/2015 01:56 PM, Joerg Roedel wrote:
> On Wed, Dec 02, 2015 at 01:31:38PM +0100, Michael Wang wrote:
>> It's not my work or your work... it's a defect in the module and maintainer
>> should take responsibility on fixing it, correct?
>
> No, its a false positive from
On 12/02/2015 01:53 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 01:31:38PM +0100, Michael Wang wrote:
>> It's not my work or your work... it's a defect in the module and maintainer
>> should take responsibility on fixing it, correct?
>
> Well, you said "actual
On 12/02/2015 12:51 PM, Joerg Roedel wrote:
> On Wed, Dec 02, 2015 at 12:38:03PM +0100, Michael Wang wrote:
>> Joerg, this is really a tiny fix, would you mind to merge it into some
>> of your cleanup patch and testing them together? we are not in hurry,
>> just want t
On 12/02/2015 12:31 PM, Catalin Marinas wrote:
> On 2 December 2015 at 10:56, Michael Wang wrote:
[snip]
>
> I could copy your description but I don't currently have a way (nor
> time) to test the patch. If you plan to test it anyway, please feel
> free to include my diff
atch?
>
> My preference (from a kmemleak perspective) is to tell kmemleak about
> the irq_lookup_table. Untested:
I'm fine with both solution, will leave the decision to maintainer :-)
BTW, could you please send a formal patch with descriptions?
Regards,
Michael Wang
>
> diff -
Hi, Joerg
On 11/25/2015 04:14 PM, Michael Wang wrote:
> On 11/25/2015 04:08 PM, Joerg Roedel wrote:
[snip]
>>> This is caused by the 'irq_lookup_table' was allocated with
>>> __get_free_pages() which won't create kmemleak object, thus it's
>>> pointers
On 12/02/2015 03:13 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 03:09:18PM +0100, Michael Wang wrote:
>> This tool will help improve the kernel, AFAIK it's already made it's
>> best, if you got any idea on how to make it even better that would be
>> great, but at
Hi, Joerg
On 11/25/2015 04:14 PM, Michael Wang wrote:
> On 11/25/2015 04:08 PM, Joerg Roedel wrote:
[snip]
>>> This is caused by the 'irq_lookup_table' was allocated with
>>> __get_free_pages() which won't create kmemleak object, thus it's
>>> pointers
atch?
>
> My preference (from a kmemleak perspective) is to tell kmemleak about
> the irq_lookup_table. Untested:
I'm fine with both solution, will leave the decision to maintainer :-)
BTW, could you please send a formal patch with descriptions?
Regards,
Michael Wang
>
> diff -
On 12/02/2015 12:31 PM, Catalin Marinas wrote:
> On 2 December 2015 at 10:56, Michael Wang <yun.w...@profitbricks.com> wrote:
[snip]
>
> I could copy your description but I don't currently have a way (nor
> time) to test the patch. If you plan to test it anyway, please feel
&g
On 12/02/2015 12:51 PM, Joerg Roedel wrote:
> On Wed, Dec 02, 2015 at 12:38:03PM +0100, Michael Wang wrote:
>> Joerg, this is really a tiny fix, would you mind to merge it into some
>> of your cleanup patch and testing them together? we are not in hurry,
>> just want t
On 12/02/2015 01:53 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 01:31:38PM +0100, Michael Wang wrote:
>> It's not my work or your work... it's a defect in the module and maintainer
>> should take responsibility on fixing it, correct?
>
> Well, you said "actual
On 12/02/2015 01:56 PM, Joerg Roedel wrote:
> On Wed, Dec 02, 2015 at 01:31:38PM +0100, Michael Wang wrote:
>> It's not my work or your work... it's a defect in the module and maintainer
>> should take responsibility on fixing it, correct?
>
> No, its a false positive from
Hi, Borislav
On 12/02/2015 02:13 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:01:55PM +0100, Michael Wang wrote:
>> Yeah.. it's a little complicated since we have our own kernel tree and this
>> won't be a problem for us, but we really prefer to help fix it in mainline
On 12/02/2015 02:40 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:18:44PM +0100, Michael Wang wrote:
[snip]
>
>> Yeah, but it would be better to solve it, otherwise whoever saw this
>> report will need to go into the amd-iommu, make sure it's not a real
&g
On 12/02/2015 02:59 PM, Borislav Petkov wrote:
> On Wed, Dec 02, 2015 at 02:48:47PM +0100, Michael Wang wrote:
>> I'm not sure why amd-iommu use get_page not kmalloc to initialize the
>> pointer table, but if it's necessary then the conflict will be there,
>> it's no
On 11/25/2015 04:08 PM, Joerg Roedel wrote:
> On Fri, Nov 20, 2015 at 12:33:50PM +0100, Michael Wang wrote:
>> The kmemleak testing on 3.18.24 show:
>>
>> unreferenced object 0x880233ff9010 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294937440 (a
Hi, Joery
On 11/20/2015 12:33 PM, Michael Wang wrote:
> The kmemleak testing on 3.18.24 show:
>
> unreferenced object 0x880233ff9010 (size 16):
> comm "swapper/0", pid 1, jiffies 4294937440 (age 2010.490s)
> hex dump (first 16 bytes):
> 0a 0a 00 00 20 00 0
On 11/25/2015 04:08 PM, Joerg Roedel wrote:
> On Fri, Nov 20, 2015 at 12:33:50PM +0100, Michael Wang wrote:
>> The kmemleak testing on 3.18.24 show:
>>
>> unreferenced object 0x880233ff9010 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294937440 (a
Hi, Joery
On 11/20/2015 12:33 PM, Michael Wang wrote:
> The kmemleak testing on 3.18.24 show:
>
> unreferenced object 0x880233ff9010 (size 16):
> comm "swapper/0", pid 1, jiffies 4294937440 (age 2010.490s)
> hex dump (first 16 bytes):
> 0a 0a 00 00 20 00 0
On 11/23/2015 11:32 AM, Borislav Petkov wrote:
> On Mon, Nov 23, 2015 at 11:20:18AM +0100, Michael Wang wrote:
>> Who want to do that would take responsibility to make an else branch at
>> that time, but reserve the branch at this moment sounds unnecessary, and
>> no
On 11/23/2015 10:54 AM, Borislav Petkov wrote:
> Hi Michael,
>
> On Mon, Nov 23, 2015 at 10:49:34AM +0100, Michael Wang wrote:
>> Why not just initialized it as NULL, or mark it as uninitialized_var()?
>
> because I'd like us to save us the redundant NULL initialization in
Hi, Borislav
Why not just initialized it as NULL, or mark it as uninitialized_var()?
Regards,
Michael Wang
On 11/23/2015 10:36 AM, Borislav Petkov wrote:
> Hey,
>
> so I keep getting those since recently:
>
> net/netfilter/nfnetlink_queue.c:519:19: warning: ‘nfnl_
On 11/23/2015 11:32 AM, Borislav Petkov wrote:
> On Mon, Nov 23, 2015 at 11:20:18AM +0100, Michael Wang wrote:
>> Who want to do that would take responsibility to make an else branch at
>> that time, but reserve the branch at this moment sounds unnecessary, and
>> no
On 11/23/2015 10:54 AM, Borislav Petkov wrote:
> Hi Michael,
>
> On Mon, Nov 23, 2015 at 10:49:34AM +0100, Michael Wang wrote:
>> Why not just initialized it as NULL, or mark it as uninitialized_var()?
>
> because I'd like us to save us the redundant NULL initialization in
Hi, Borislav
Why not just initialized it as NULL, or mark it as uninitialized_var()?
Regards,
Michael Wang
On 11/23/2015 10:36 AM, Borislav Petkov wrote:
> Hey,
>
> so I keep getting those since recently:
>
> net/netfilter/nfnetlink_queue.c:519:19: warning: ‘nfnl_
On 11/20/2015 12:33 PM, Michael Wang wrote:
> The kmemleak testing on 3.18.24 show:
>
> unreferenced object 0x880233ff9010 (size 16):
> comm "swapper/0", pid 1, jiffies 4294937440 (age 2010.490s)
> hex dump (first 16 bytes):
> 0a 0a 00 00 20 00 0
n
kmemleak scan.
The 'irq_remap_table' won't be freed after initialized, doesn't
make sense to check it's leaking.
This patch mark the 'irq_remap_table' object as 'gray' to stop
the 'false positives' report.
Signed-off-by: Michael Wang
---
v2:
Use kmemleak_not_leak() instead of kmemleak_igno
k scanning.
The 'irq_remap_table' allocated won't be freed after initialized,
doesn't make sense to let kmemleak scan it.
This patch mark the 'irq_remap_table' object as 'ignored' to
stop the 'false positives' report.
Signed-off-by: Michael Wang
---
drivers/iommu/amd_iommu.c | 1 +
1 file changed, 1
On 11/20/2015 12:33 PM, Michael Wang wrote:
> The kmemleak testing on 3.18.24 show:
>
> unreferenced object 0x880233ff9010 (size 16):
> comm "swapper/0", pid 1, jiffies 4294937440 (age 2010.490s)
> hex dump (first 16 bytes):
> 0a 0a 00 00 20 00 0
k scanning.
The 'irq_remap_table' allocated won't be freed after initialized,
doesn't make sense to let kmemleak scan it.
This patch mark the 'irq_remap_table' object as 'ignored' to
stop the 'false positives' report.
Signed-off-by: Michael Wang <yun.w...@profitbricks.com>
---
drivers/iommu/amd_iommu
n
kmemleak scan.
The 'irq_remap_table' won't be freed after initialized, doesn't
make sense to check it's leaking.
This patch mark the 'irq_remap_table' object as 'gray' to stop
the 'false positives' report.
Signed-off-by: Michael Wang <yun.w...@profitbricks.com>
---
v2:
Use kmemleak_no
finition is far more detailed and accurate, it's already good enough
according to my understanding, should benefit the developer a lot ;-)
Regards,
Michael Wang
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
the developer a lot ;-)
Regards,
Michael Wang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
e the header of inline func for kdoc?
>
> Just because I want to move this along versus waiting for another
> respin, I'm going to copy and paste these into those locations and clean
> up the changelog when I integrate this patch.
Got it, if there is anything I could help, please let me k
I'll put the highlights and changelog under '---' in next version, is it
looks like this?
Subject: [PATCH RFC v3] Documentation/infiniband: Add docs for rdma-helpers
This is the following patch for:
https://lkml.org/lkml/2015/5/5/417
which try to document the settled rdma_cap_XX().
Sign
, please don't
be hesitate to point out the issues, any suggestions to improve or
complete the description are very welcomed ;-)
Signed-off-by: Michael Wang
---
Documentation/infiniband/rdma_helpers.txt | 79 +++
1 file changed, 79 insertions(+)
create mode 100644
to move this along versus waiting for another
respin, I'm going to copy and paste these into those locations and clean
up the changelog when I integrate this patch.
Got it, if there is anything I could help, please let me know ;-)
Regards,
Michael Wang
Subject: [PATCH RFC v3] Documentation
, please don't
be hesitate to point out the issues, any suggestions to improve or
complete the description are very welcomed ;-)
Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
Documentation/infiniband/rdma_helpers.txt | 79 +++
1 file changed, 79 insertions
'---' in next version, is it
looks like this?
Subject: [PATCH RFC v3] Documentation/infiniband: Add docs for rdma-helpers
This is the following patch for:
https://lkml.org/lkml/2015/5/5/417
which try to document the settled rdma_cap_XX().
Signed-off-by: Michael Wang yun.w...@profitbricks.com
t I can understand the concept.
>
> This helper is true when the address family of this queue pair is of the
> Ethernet (RoCE) variety.
Sounds good, will be merged in next version :-)
Regards,
Michael Wang
>
>
--
To unsubscribe from this list: send the line "unsubscrib
the long description.
>
[snip]
>> Shall we put this long description into USAGE? Here maybe list
>> all the helpers to give some quick overview with a brief
>> description, what's your opinion?
>
> Given how we have a more complete description of this below, it need not
n ethernet fabric,
>> use
>>> +the helper to verify whether the port is using ethernet format or
>> not.
>>
>> This helper is true when the address of the specific connection is of
>> the Ethernet (RoCE) variety.
>
> This is used for connectionless co
(MAD) are a required part of the InfiniBand
> specification and are supported on all InfiniBand devices. A slightly
> extended version are also supported on OPA interfaces.
>
> I would drop all instances of "use the helper to verify..." as that's
> redundant. This whole d
On 05/13/2015 05:59 PM, Jason Gunthorpe wrote:
> On Wed, May 13, 2015 at 03:24:32PM +0200, Michael Wang wrote:
>> This is the following patch for:
>> https://lkml.org/lkml/2015/5/5/417
>> which try to document the settled rdma_cap_XX().
>>
>> Highlights:
or
not.
This helper is true when the address of the specific connection is of
the Ethernet (RoCE) variety.
This is used for connectionless communication.
Could you please give more details on this?
Regards,
Michael Wang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 05/13/2015 05:59 PM, Jason Gunthorpe wrote:
On Wed, May 13, 2015 at 03:24:32PM +0200, Michael Wang wrote:
This is the following patch for:
https://lkml.org/lkml/2015/5/5/417
which try to document the settled rdma_cap_XX().
Highlights:
There could be many missing/mistakes
the helpers to verify things.
Agree, will be dropped in next version.
And all the comments below make sense, will be merged ;-)
Regards,
Michael Wang
+
+ rdma_cap_ib_smi
+ ---
+Subnet Management Interface (SMI) will handle SMP packet from SM
+in an infiniband fabric, use
into USAGE? Here maybe list
all the helpers to give some quick overview with a brief
description, what's your opinion?
Given how we have a more complete description of this below, it need not
have such a lengthy description here.
Got it :-)
Regards,
Michael Wang
+
+USAGE
is true when the address family of this queue pair is of the
Ethernet (RoCE) variety.
Sounds good, will be merged in next version :-)
Regards,
Michael Wang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
are very welcomed ;-)
Signed-off-by: Michael Wang
---
Documentation/infiniband/rdma_helpers.txt | 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/infiniband/rdma_helpers.txt
diff --git a/Documentation/infiniband/rdma_helpers.txt
b
k up an incremental patch to address the kdocs issue.
> I've picked up the v8 patchset, and there is no need to respin it, but I
> would like to have that kdoc patch before the 4.2 merge window opens.
Sure, now these helpers are settled down, it's time for document,
I'll send o
are very welcomed ;-)
Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
Documentation/infiniband/rdma_helpers.txt | 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/infiniband/rdma_helpers.txt
diff --git a/Documentation/infiniband
issue.
I've picked up the v8 patchset, and there is no need to respin it, but I
would like to have that kdoc patch before the 4.2 merge window opens.
Sure, now these helpers are settled down, it's time for document,
I'll send out the RFC ASAP :-)
Regards,
Michael Wang
--
To unsubscribe from
ed up to my github repo sometime today.
Got it :-)
Regards,
Michael Wang
>
>> About the Bug, if it was not introduced in this series, maybe including the
>> fix in next series would be better?
>>
>> Regards,
>> Michael Wang
>>
>>>
>>>> Fra
, it sounds more reasonable to include the fix in the series introduced
it :-P
>
>
> For the rest of the series.
>
> Reviewed-by: Ira Weiny
> Tested-by: Ira Weiny
> -- Limited to mlx4, qib, and OPA (with additional patches.)
Thanks for the review and testing :-)
Rega
as asking to merge the #15~23, and want to reserve the changelog
meanwhile reply the cover of prev version (I'm still confused on that...),
I've replied but get no respond yet.
I can make a v9 to merge the #15~#23 if that could benefit the maintainability,
please let me know your opinion :-)
About th
make a v9 to merge the #15~#23 if that could benefit the maintainability,
please let me know your opinion :-)
About the Bug, if it was not introduced in this series, maybe including the
fix in next series would be better?
Regards,
Michael Wang
Frankly
I vote for the former because
For the rest of the series.
Reviewed-by: Ira Weiny ira.we...@intel.com
Tested-by: Ira Weiny ira.we...@intel.com
-- Limited to mlx4, qib, and OPA (with additional patches.)
Thanks for the review and testing :-)
Regards,
Michael Wang
On Tue, May 05, 2015 at 02:50:17PM +0200
benefit the
maintainability,
please let me know your opinion :-)
I don't think it would make a significant difference. I've pulled the
v8 patchset out of patchworks and I'll throw a new branch with it
included up to my github repo sometime today.
Got it :-)
Regards,
Michael Wang
About
1 - 100 of 1619 matches
Mail list logo
