Hi,
Le 21.05.2013 02:26, Weiny, Ira a écrit :
[PATCH 0/2] update to autotools How are these different (if at all)
from the patches submitted by Jeff previously?
Patches from Jeff are already applied on libibverbs.
My patches apply on top to improve a bit the way autotools are used for
libibv
On Wed, Apr 24, 2013 at 04:58:43PM +0300, Or Gerlitz wrote:
> Hi Roland, all
>
> The first five patches in the series are mlx4 DMFS (Device Managed Flow
> Steering) pre-patches needed for flow steering access from the mlx4 IB driver.
>
> net/mlx4_core: Move DMFS HW structs to common header fil
File opened by libibverbs are not supposed to be inherited
across exec*(), most of the files are of no use for another program,
and others cannot be used without the associated memory mapping.
This patch changes open() and fopen() to always set close on exec flag.
This patch also add checks to co
'autoupdate' is a tool to help developer to update configure.ac.
This patch apply a few fixes as suggested by autoupdate.
It was tested on Debian 6.0.7 (Squeeze) and Fedora 17 (Beefy Miracle).
Signed-off-by: Yann Droneaud
---
configure.ac | 17 -
1 file changed, 8 insertions(+)
As part of update to configure.ac, please find two quite simple patches.
It should be applied to bring the build system a bit up to date
regarding autotools.
It works on Debian 6.0 (Squeeze) and Fedora 17 (Beefy Miracle),
but you might want to test on older systems ... I'm looking at you
Red Hat
Following advice in "Autotool Mythbuster" [1],
option subdir-objects can be used to have Makefiles
create object files in the same directory than
theirs source files.
It reduces clobbering in the build directory.
[1] "Autotool Mythbuster", by Diego Elio "Flameeyes" Petten`o
http://www.flameeyes.e
On Tue, Jan 17, 2012 at 10:21:28AM -0600, Steve Wise wrote:
> On 01/17/2012 09:59 AM, Or Gerlitz wrote:
> >On 1/17/2012 5:08 PM, Steve Wise wrote:
> >>I think this series should add some new send flags for HW that
> >>does checksum offload [...] also, on ingress, most hardware can
> >>do INET check
libibverbs must refuse to load arbitrary shared objects.
This patch check the configuration directory and files for
- being owned by root;
- not being writable by others.
Signed-off-by: Yann Droneaud
---
src/init.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
Files beginning with a dot are mostly current and parent directories or,
by convention, hidden files.
Those path are skipped in find_sysfs_dev().
Signed-off-by: Yann Droneaud
---
src/init.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/init.c b/src/init.c
index 96ecf04..c880b68 100
Try to protect libibverbs from hand modified configuration files.
Signed-off-by: Yann Droneaud
---
src/init.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/init.c b/src/init.c
index c880b68..1981da7 100644
--- a/src/init.c
+++ b/src/init.c
@@ -311,6 +311,9 @@ static void read_config
Hi,
Please find three patches to protect libibverbs from using invalid,
unsecure configuration files.
Thoses configurations files are usually located in
/etc/libibverbs.d/ and contains the name of a shared library
to dlopen().
Only legitimate shared libraries should be loaded by libibverbs,
so i
> So if you were pushing these private conversations to linux-rdma, more
> have been known on rsockets for the benefit of all... oh well. I think
> you mentioned something re Intel HPC group, or I am wrong?
rsockets will continue to be supported by myself and Intel going forward. The
rsocket wor
On Mon, May 20, 2013 at 10:52 PM, Hefty, Sean wrote:
>> Do we have some public quoted usages/feedback for rsockets? I think
>> you've mentioned something during the panel at the Linux EU summit
>> last week but I am not sure...
>
> Most feedback I can think of has come via private emails or person
On Mon, May 20, 2013 at 10:58 PM, Hefty, Sean wrote:
> I believe this is true wrt the IB spec.
indeed, don't go anywhere else on that corner.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at htt
On 5/20/13 2:58 PM, Hefty, Sean wrote:
My reading of the code (i.e. hw/mlx4/cq.c) is that the hardware cqe
owner_sr_opcode field contains MLX4_CQE_OPCODE_ERROR when there is an
error and therefore, the only way to recover what the opcode was is
through the wr_id you used when submitting the WR.
> My reading of the code (i.e. hw/mlx4/cq.c) is that the hardware cqe
> owner_sr_opcode field contains MLX4_CQE_OPCODE_ERROR when there is an
> error and therefore, the only way to recover what the opcode was is
> through the wr_id you used when submitting the WR.
>
> Is my reading of the code cor
On 2013年05月20日 21:50, Or Gerlitz wrote:
> On Mon, May 20, 2013 at 10:38 PM, Jack Wang
> wrote:
>>
>> The bug in our production environment is introduced in our backport
>> about ipoib fixes from mainline, and when we hit that bug we reverted
>> back to old kernel without the backport patch, and t
> Do we have some public quoted usages/feedback for rsockets? I think
> you've mentioned something during the panel at the Linux EU summit
> last week but I am not sure...
Most feedback I can think of has come via private emails or personal
interactions, especially specific details of various usa
Hi Guys,
One other quick one. I've received conflicting claims on the validity of
the wc.opcode when wc.status != 0 for mlx4 hardware.
My reading of the code (i.e. hw/mlx4/cq.c) is that the hardware cqe
owner_sr_opcode field contains MLX4_CQE_OPCODE_ERROR when there is an
error and therefore
On Mon, May 20, 2013 at 10:38 PM, Jack Wang wrote:
>
> The bug in our production environment is introduced in our backport
> about ipoib fixes from mainline, and when we hit that bug we reverted
> back to old kernel without the backport patch, and the bug didn't happen for
> now.
>
> This list_de
On 2013年05月20日 21:00, Or Gerlitz wrote:
> On Mon, May 20, 2013 at 5:36 PM, Jack Wang
> wrote:
>> Sorry for confusion. Current list corruption is gone in my preliminary test,
>> after I changed
>> list_del to list_del_init as Or suggested.
>> As Or asked for the original bug, so I just want to sh
Hi Sean,
Do we have some public quoted usages/feedback for rsockets? I think
you've mentioned something during the panel at the Linux EU summit
last week but I am not sure...
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.ke
On Mon, May 20, 2013 at 5:36 PM, Jack Wang wrote:
> Sorry for confusion. Current list corruption is gone in my preliminary test,
> after I changed
> list_del to list_del_init as Or suggested.
> As Or asked for the original bug, so I just want to show him the whole story.
I am still not clear if
On 05/20/2013 12:49 PM, Roland Dreier wrote:
> On Mon, May 20, 2013 at 5:37 AM, Or Gerlitz wrote:
>> Following what we discussed last week during the Linux Foundation EU summit,
>> I think it would be good to follow what you said and have a point release
>> for libibverbs and libmlx4 before we p
> So is it intended that cooperating processes sharing an xrc domain will
> "choose" one process to create the xrc qp, and the rest will open it?
yes - The QPN of the shared QP must be known between the cooperating processes.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma"
On 3/26/2013 4:14 PM, sean.he...@intel.com wrote:
From: Sean Hefty
XRC receive QPs are shareable across multiple processes. Allow
any process with access to the xrc domain to open an existing
QP. After opening the QP, the process will receive events
related to the QP and be able to modify the
On Mon, May 20, 2013 at 5:37 AM, Or Gerlitz wrote:
> Following what we discussed last week during the Linux Foundation EU summit,
> I think it would be good to follow what you said and have a point release for
> libibverbs and libmlx4 before we pull in the verbs extensions framework and
> featu
On Mon, May 20, 2013 at 7:53 AM, Jack Morgenstein
wrote:
> This is racy and can cause use-after-free, null pointer dereference, etc,
> which
> result in kernel crashes.
Sounds fine and I'd be happy to apply your final patch, but I'd be
curious to know what the race is in more detail.
--
To unsub
On Saturday 18 May 2013 00:37, Roland Dreier wrote:
> On Fri, May 17, 2013 at 12:25 PM, Tom Tucker
> wrote:
> > I'm looking at the Linux MLX4 net driver and found something that confuses
> > me mightily. In particular in the file net/ethernet/mellanox/mlx4/cq.c, the
> > mlx4_ib_completion funct
>
> Hi Jack,
>
> I don't understand what is the current status, that is what do you see
> now after applying the patches.
> If you don't get the original bug why did you gave the trace of it? Or
> is it a new trace? It is not clear from your mail.
> Please add only the trace of the current issue.
On 5/20/2013 3:58 PM, Jack Wang wrote:
I haven't reproduced the original bug we saw in our production
environment
BUG: unable to handle kernel
at 0008
IP: [] ipoib_cm_tx_reap+0xe0/0x5a0 [ib_ipoib]
...
RIP: 0010:[] []
ipoib_cm_tx_reap+0xe0/0x5a0 [ib_ipoib]
RSP: 0018:8825fdcbd
On 20/05/2013 15:46, Jinpu Wang wrote:
A quick test show the list_corruption warning is gone, after I convert
all list_del(&neigh->list) to list_del_list(&neigh->list).
yes, but this wasn't your original problem or was it?
--
To unsubscribe from this list: send the line "unsubscribe linux-r
A quick test show the list_corruption warning is gone, after I convert
all list_del(&neigh->list) to list_del_list(&neigh->list).
Test is still running, will update status if anything wrong.
Thanks Or.
On Mon, May 20, 2013 at 12:58 PM, Or Gerlitz wrote:
> On 20/05/2013 12:10, Jinpu Wang wro
Hi Roland,
Following what we discussed last week during the Linux Foundation EU
summit, I think it would be good to follow what you said and have a
point release for libibverbs and libmlx4 before we pull in the verbs
extensions framework and features that use it (XRC, Flow-Steering, etc
more
On 20/05/2013 12:10, Jinpu Wang wrote:
which list_del do you mean? in ipoib_cm_tx_start?
yes, but not only, you can start with 5KG hammer and convert all
thesehits to list_del_init
linux-2.6]# grep list_del drivers/infiniband/ulp/ipoib/*.c | grep neigh
drivers/infiniband/ulp/ipoib/ipoib_cm.c:
which list_del do you mean? in ipoib_cm_tx_start?
On Mon, May 20, 2013 at 11:05 AM, Or Gerlitz wrote:
> On 19/05/2013 12:17, Jack Wang wrote:
>>
>> we added inject_bug sysfs node to make function run into error case, like
>> something below. Yes, you are right, we want to speedup the bug reproduc
On 19/05/2013 12:17, Jack Wang wrote:
we added inject_bug sysfs node to make function run into error case, like
something below. Yes, you are right, we want to speedup the bug reproduce process,
and we saw the warning and come to conclusion the neigh->list corrupted some
where. What's your opi
37 matches
Mail list logo
