Did you get my message?

[JACK EDISON]

Do you received my previous email? about your late relative having the
same surname with you which i previously sent to you? please Let me
know.

Hello Beautiful

[Jack]

Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.

Hello Beautiful

[Jack]

Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.

Re: [PATCH linux-stable-4.14] tcp: reset sk_send_head in tcp_write_queue_purge

[Jack Wang]

2018-03-29 12:00 GMT+02:00 Timofey Titovets :
> Hi,
> any progress here?
>
> I didn't find that patch applied for any 4.14.27-4.14.31
>
> Patch rejected?
It's in queue for 4.14.32
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.14/tcp-reset-sk_send_head-in-tcp_write_queue_purge.patch?id=c78a2769647faebad83a2e35a14cde382be3ff7d
>
> 2018-03-20 19:13 GMT+03:00 Willy Tarreau :
>> Hi David,
>>
>> regarding the patch below, I'm not certain whether you planned to take
>> it since it's marked "not applicable" on patchwork, but I suspect it's
>> only because it doesn't apply to mainline.
>>
>> However, please note that there are two typos in commit IDs referenced in
>> the commit message that might be nice to fix before merging :
>>
>>> > For example, after 27fid7a8ed38 (tcp: purge write queue upon RST),
>>
>> - here it's "a27fd7a8ed38" (missing 'a' and extra 'i' in the middle)
>>
>> - and lower in the fixes tag there's the extra 'i' as well :
>>
>>> > Fixes: a27fid7a8ed38 (tcp: purge write queue upon RST)
>>
>> There was another report today on the stable list for a similar crash
>> on 4.14.28 and I suspect it's the one I saw this week-end on my firewall
>> after upgrading from 4.14.10 to 4.14.27 though I didn't have the symbols
>> to confirm.
>>
>> Thanks,
>> Willy
>
>
>
> --
> Have a nice day,
> Timofey.

Hello Beautiful

[Jack]

Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.

Hello Beautiful

[Jack]

Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.

Hello Beautiful

[Jack]

Cześć Drogi, nazywam się Jack i szukam związku, w którym będę czuć się kochany 
po serii nieudanych związków.

Mam nadzieję, że byłbyś zainteresowany i moglibyśmy się lepiej poznać, jeśli 
nie masz nic przeciwko. Jestem otwarty na udzielanie odpowiedzi na pytania od 
ciebie, ponieważ uważam, że moje podejście jest trochę niewłaściwe. Mam 
nadzieję, że odezwę się od ciebie.

Jacek.

Re: 4.14.2[6-7] tcp_push NULL pointer

[Jack Wang]

2018-03-19 12:51 GMT+01:00 Tomas Charvat <t...@excello.cz>:
> I have seen on multiple servers with kernel-4.14.26 and 4.14.27
> following errors in dmes. It seems that it also caused involved process
> to crash (apache and qmail-smtpd).
Hi,

upsteam has a fix for it:
https://www.mail-archive.com/netdev@vger.kernel.org/msg222545.html

Regards,
Jack
>
> [Fri Mar 16 00:00:11 2018] BUG: unable to handle kernel NULL pointer
> dereference at 0038
> [Fri Mar 16 00:00:11 2018] IP: tcp_push+0x3d/0x110
> [Fri Mar 16 00:00:11 2018] PGD 0 P4D 0
> [Fri Mar 16 00:00:11 2018] Oops: 0002 [#1] SMP NOPTI
> [Fri Mar 16 00:00:11 2018] CPU: 74 PID: 50845 Comm: parse_scanner.p Not
> tainted 4.14.27-gentoo #1
> [Fri Mar 16 00:00:11 2018] Hardware name: Supermicro AS
> -1123US-TR4/H11DSU-iN, BIOS 1.0a 09/14/2017
> [Fri Mar 16 00:00:11 2018] task: a33f855226c0 task.stack:
> bf3765394000
> [Fri Mar 16 00:00:11 2018] RIP: 0010:tcp_push+0x3d/0x110
> [Fri Mar 16 00:00:11 2018] RSP: 0018:bf3765397cd0 EFLAGS: 00010246
> [Fri Mar 16 00:00:11 2018] RAX:  RBX: a33b8664d000
> RCX: 
> [Fri Mar 16 00:00:11 2018] RDX: 0001 RSI: 
> RDI: a33b6338ac00
> [Fri Mar 16 00:00:11 2018] RBP: 1c20 R08: 0576
> R09: a33b6338ad58
> [Fri Mar 16 00:00:11 2018] R10: 0576 R11: 
> R12: ffe0
> [Fri Mar 16 00:00:11 2018] R13: 1c20 R14: a33b6338ac00
> R15: bf3765397dd0
> [Fri Mar 16 00:00:11 2018] FS:  7f64301f1700()
> GS:a33b9fc8() knlGS:
> [Fri Mar 16 00:00:11 2018] CS:  0010 DS:  ES:  CR0: 80050033
> [Fri Mar 16 00:00:11 2018] CR2: 0038 CR3: 800ff30bc000
> CR4: 001406e0
> [Fri Mar 16 00:00:11 2018] Call Trace:
> [Fri Mar 16 00:00:11 2018]  tcp_sendmsg_locked+0x65c/0xe40
> [Fri Mar 16 00:00:11 2018]  tcp_sendmsg+0x2e/0x50
> [Fri Mar 16 00:00:11 2018]  sock_sendmsg+0x3e/0x50
> [Fri Mar 16 00:00:11 2018]  SYSC_sendto+0x123/0x1c0
> [Fri Mar 16 00:00:11 2018]  do_syscall_64+0x80/0x340
> [Fri Mar 16 00:00:11 2018]  ? __do_page_fault+0x19c/0x3f0
> [Fri Mar 16 00:00:11 2018]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [Fri Mar 16 00:00:11 2018] RIP: 0033:0x7f642f9d0b01
> [Fri Mar 16 00:00:11 2018] RSP: 002b:7ffcfaa9c530 EFLAGS: 0246
> ORIG_RAX: 002c
> [Fri Mar 16 00:00:11 2018] RAX: ffda RBX: 562485e03c18
> RCX: 7f642f9d0b01
> [Fri Mar 16 00:00:11 2018] RDX: 2000 RSI: 562485e03c18
> RDI: 0004
> [Fri Mar 16 00:00:11 2018] RBP: 562485a6d2a8 R08: 
> R09: 
> [Fri Mar 16 00:00:11 2018] R10:  R11: 0246
> R12: 
> [Fri Mar 16 00:00:11 2018] R13: 562485e03c18 R14: 2000
> R15: 562485c18300
> [Fri Mar 16 00:00:11 2018] Code: 00 48 8b 87 60 01 00 00 4c 8d 8f 58 01
> 00 00 b9 00 00 00 00 41 89 f3 49 39 c1 48 0f 44 c1 41 81 e3 00 80 00 00
> 0f 85 a5 00 00 00 <80> 48 38 08 8b 8f 6c 06 00 00 89 8f 74 06 00 00 83
> e6 01 74 0c
> [Fri Mar 16 00:00:11 2018] RIP: tcp_push+0x3d/0x110 RSP: bf3765397cd0
> [Fri Mar 16 00:00:11 2018] CR2: 0038
> [Fri Mar 16 00:00:11 2018] ---[ end trace 4ed52c64cd15c543 ]---
>
> [Thu Mar 15 14:56:06 2018] BUG: unable to handle kernel NULL pointer
> dereference at 0038
> [Thu Mar 15 14:56:06 2018] IP: tcp_push+0x3d/0x110
> [Thu Mar 15 14:56:06 2018] PGD 0 P4D 0
> [Thu Mar 15 14:56:06 2018] Oops: 0002 [#1] SMP NOPTI
> [Thu Mar 15 14:56:06 2018] CPU: 2 PID: 17214 Comm: rsync Not tainted
> 4.14.26-gentoo #1
> [Thu Mar 15 14:56:06 2018] Hardware name: Xen HVM domU, BIOS 4.9.1
> 01/26/2018
> [Thu Mar 15 14:56:06 2018] task: 880164ca9a00 task.stack:
> c90002548000
> [Thu Mar 15 14:56:06 2018] RIP: 0010:tcp_push+0x3d/0x110
> [Thu Mar 15 14:56:06 2018] RSP: 0018:c9000254bc90 EFLAGS: 00010246
> [Thu Mar 15 14:56:06 2018] RAX:  RBX: 88006cf6a380
> RCX: 
> [Thu Mar 15 14:56:06 2018] RDX:  RSI: 0040
> RDI: 880100025d00
> [Thu Mar 15 14:56:06 2018] RBP: 65d0 R08: 43e0
> R09: 880100025e58
> [Thu Mar 15 14:56:06 2018] R10: 05a8 R11: 
> R12: 65d0
> [Thu Mar 15 14:56:06 2018] R13: ffe0 R14: c9000254bd80
> R15: 880100025d00
> [Thu Mar 15 14:56:06 2018] FS:  7f1ffba19e80()
> GS:88018f50() knlGS:
> [Thu Mar 15 14:56:06 2018] CS:  0010 DS:  ES:  CR0: 80050033
> [Thu Mar 15 14:56:06 2018] CR2: 0038 CR3: 9355
> CR4: 

Hello Beautiful

[jack]

Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.

Adding support for VRF traffic passed by mangle table

[Jack Ma]

Hi David,

I formatted a patch to support vrf flow passed by iptables(mangle table). And 
previously, we lost the flow.oif which would result in a routing look-up 
failure. This patch wraps vrf response flow with the correct master interface 
by using the skb->dev, which was set to the real ingress device.
Without this patch, VRF traffic permitted by firewall rules that changes 
nf_mark would be dropped while doing fib_lookup.
Kernel documentations suggested two way of fixing this:

 
<
[2] Iptables on ingress supports PREROUTING with skb->dev set to the 
real
ingress device and both INPUT and PREROUTING rules with skb->dev 
set to
the VRF device. For egress POSTROUTING and OUTPUT rules can be 
written
using either the VRF device or real egress device.
>


Could you please look at this patch and give me some feedback?
Thanks for your time and considerations.
​
Regards,
Jack




diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
index c0cc6aa..07168d4 100644
--- a/net/ipv4/netfilter.c
+++ b/net/ipv4/netfilter.c
@@ -46,6 +46,14 @@ int ip_route_me_harder(struct net *net, struct sk_buff *skb, 
unsigned int addr_t
fl4.flowi4_oif = l3mdev_master_ifindex(dev);
fl4.flowi4_mark = skb->mark;
fl4.flowi4_flags = flags;
+
+   /* Since we have already known this is vrf flow passed by
+* mangle table, we wrap the oif with the master interface.
+*/
+   if (fl4.flowi4_oif == 0 && fl4.daddr && skb->dev &&
+   netif_index_is_l3_master(net, skb->dev->ifindex))
+   fl4.flowi4_oif = skb->dev->ifindex;
+
rt = ip_route_output_key(net, );
if (IS_ERR(rt))
return PTR_ERR(rt);0001-Wrap-vrf-traffic-passed-by-mangle-table-with-correct.patch

Hello Beautiful,

[Jack]

Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.

hi beautiful

[Jack]

hi,

I am seriously looking for some love and affection, I'm an adventurous, 
hardworking, seriously committed and kind person. My current priority is my 
daughter, my work, my health and fitness. I'm a devoted father on the weekends, 
but missing someone special to share my life. I would like to find someone who 
shares my commitment to live, health and fitness, but also has unique interests 
and wants to try new things with me, for the rest of our lives.
I know it will be difficult for you to understand, but I will be glad if you to 
write me and tell me a little about yourself and if you will be interested in 
knowing more about me and I hope this will be the beginning of a very 
successful relationship for us.
Kind regards,

Jack.

Re: [PATCH 3/5] net/mlx4: fix some error handling in mlx4_multi_func_init()

[Jack Morgenstein]

On Wed, 10 Feb 2016 19:15:20 +0100
Rasmus Villemoes <li...@rasmusvillemoes.dk> wrote:

> On Wed, Feb 10 2016, Yishai Hadas <yish...@dev.mellanox.co.il> wrote:
> 
> >> @@ -2429,7 +2429,7 @@ err_thread:
> >>flush_workqueue(priv->mfunc.master.comm_wq);
> >>destroy_workqueue(priv->mfunc.master.comm_wq);
> >>   err_slaves:
> >> -  while (--i) {
> >> +  while (i--) {
> >
> > This fix is wrong as it hits the case that i arrived the last value
> > then below code will access to a non valid entry in the array.
> >
> > The expected fix should be:
> > while (--i >= 0)
> >
> 
> Huh? They're completely equivalent (given that i is necessarily
> non-negative before we evaluate the loop condition)

No, they are not equivalent.
if i == the max value (dev->num_slaves) when entering your proposed
while loop, the kfree call index (i) will be out of range!  This can
happen, for example, if the failure occurs downstream from the "i"
for-loop (e.g., if the call to mlx4_init_resource_tracker() fails).

Therefore, we DO require the pre-decrement format.  Therefore, the
one-line fix proposed by Yishai is the correct fix.
>. I don't really
> care either way, but git grep says that 'while (i--)' is 5 times more
> common than 'while (--i >= 0)'.
Not relevant, while (i--) is simply not correct, because of the case
where the for-loop involving i completes successfully and an error
occurs later.

FYI, you also had another bug in your solution -- a double-free when
kzalloc for port 2 fails.  For your code, you should also have reset
s_state->vlan_filter[port] to NULL as shown below:
for (port = 1; port <= MLX4_MAX_PORTS; port++) {
struct mlx4_vport_state *admin_vport;
struct mlx4_vport_state *oper_vport;

s_state->vlan_filter[port] =
kzalloc(sizeof(struct
mlx4_vlan_fltr), GFP_KERNEL);
if (!s_state->vlan_filter[port]) {
if (--port) {

kfree(s_state->vlan_filter[port]);
==> You should have added this  s_state->vlan_filter[port] = 
NULL;
}
goto err_slaves;
    }

However, again, the correct solution is to do what Yishai suggests:
while (--i >= 0)
so that if i is already zero the while-loop will not be entered.

-Jack
> 
> Rasmus
> --
> 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  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] net/mlx4: fix some error handling in mlx4_multi_func_init()

[Jack Morgenstein]

Ouch! Egg on my face!  Sorry about that.
You are correct!  while (--i >= 0) IS exactly equivalent to
while (i--). (the while condition is fully evaluated before the loop is
entered; pre or post increment only influences which value is tested
for true in the while condition -- the pre-value (with post-increment) 
or the post-value (with pre-increment)).

In that case, my comment below regarding the double-free is also not
correct.  Setting the freed pointer to NULL is not needed.

My bad. We should go with your format:  while (i--)

-Jack

On Thu, 11 Feb 2016 11:29:43 +0200
Jack Morgenstein <ja...@dev.mellanox.co.il> wrote:

> On Wed, 10 Feb 2016 19:15:20 +0100
> Rasmus Villemoes <li...@rasmusvillemoes.dk> wrote:
> 
> > On Wed, Feb 10 2016, Yishai Hadas <yish...@dev.mellanox.co.il>
> > wrote:
> > 
> > >> @@ -2429,7 +2429,7 @@ err_thread:
> > >>  flush_workqueue(priv->mfunc.master.comm_wq);
> > >>  destroy_workqueue(priv->mfunc.master.comm_wq);
> > >>   err_slaves:
> > >> -while (--i) {
> > >> +while (i--) {
> > >
> > > This fix is wrong as it hits the case that i arrived the last
> > > value then below code will access to a non valid entry in the
> > > array.
> > >
> > > The expected fix should be:
> > > while (--i >= 0)
> > >
> > 
> > Huh? They're completely equivalent (given that i is necessarily
> > non-negative before we evaluate the loop condition)
> 
> No, they are not equivalent.
> if i == the max value (dev->num_slaves) when entering your proposed
> while loop, the kfree call index (i) will be out of range!  This can
> happen, for example, if the failure occurs downstream from the "i"
> for-loop (e.g., if the call to mlx4_init_resource_tracker() fails).
> 
> Therefore, we DO require the pre-decrement format.  Therefore, the
> one-line fix proposed by Yishai is the correct fix.
> >. I don't really
> > care either way, but git grep says that 'while (i--)' is 5 times
> > more common than 'while (--i >= 0)'.
> Not relevant, while (i--) is simply not correct, because of the case
> where the for-loop involving i completes successfully and an error
> occurs later.
> 
> FYI, you also had another bug in your solution -- a double-free when
> kzalloc for port 2 fails.  For your code, you should also have reset
> s_state->vlan_filter[port] to NULL as shown below:
>   for (port = 1; port <= MLX4_MAX_PORTS;
> port++) { struct mlx4_vport_state *admin_vport;
>   struct mlx4_vport_state *oper_vport;
> 
>   s_state->vlan_filter[port] =
>   kzalloc(sizeof(struct
>   mlx4_vlan_fltr), GFP_KERNEL);
>   if (!s_state->vlan_filter[port]) {
>   if (--port) {
>   
> kfree(s_state->vlan_filter[port]);
>   ==> You should have added this
> s_state->vlan_filter[port] = NULL; }
>   goto err_slaves;
>   }
> 
> However, again, the correct solution is to do what Yishai suggests:
>   while (--i >= 0)
> so that if i is already zero the while-loop will not be entered.
> 
> -Jack
> > 
> > Rasmus
> > --
> > 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  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 02/25] IB/mthca, net/mlx4: remove counting semaphores

[Jack Morgenstein]

On Wed, 28 Oct 2015 03:45:50 +0100
Arnd Bergmann <a...@arndb.de> wrote:

> As far as I can tell, there is a preexisting race condition
> regarding the cmd->use_events flag, which is not protected
> by any lock. When this flag is toggled while another command
> is being started, that command gets stuck until the mode is
> toggled back.

We fixed this issue in mellanox ofed in a manner that allowed keeping
the same counting mechanism.  IMHO, this is preferable, rather than
totally changing the mechanism.

We will submit a similar patch to the upstream kernel shortly.

-Jack

net/mlx4: Switching between sending commands via polling and events may results 
in hung tasks

When switching between those methonds of sending commands, it's possbile that a
task will keep waiting for the polling sempahore, but may never be able to 
acquire it.
This is due to mlx4_cmd_use_events which "down"s the sempahore back to 0.

Reproducing it involves in sending commands while chaning between 
mlx4_cmd_use_polling
and mlx4_cmd_use_events.

Solving it by adding a read-write semaphore when switching between modes.

issue: 402565
Change-Id: I19f0d40dbb327c49b39a9abbcb2bb002b0279b0b
Signed-off-by: Matan Barak <mat...@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx4/cmd.c  | 23 +--
 drivers/net/ethernet/mellanox/mlx4/mlx4.h |  2 ++
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c 
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index def1338..f94a960 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -766,17 +766,23 @@ int __mlx4_cmd(struct mlx4_dev *dev, u64 in_param, u64 
*out_param,
return mlx4_cmd_reset_flow(dev, op, op_modifier, -EIO);
 
if (!mlx4_is_mfunc(dev) || (native && mlx4_is_master(dev))) {
+   int ret;
+
if (dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)
return mlx4_internal_err_ret_value(dev, op,
  op_modifier);
+   down_read(_priv(dev)->cmd.switch_sem);
if (mlx4_priv(dev)->cmd.use_events)
-   return mlx4_cmd_wait(dev, in_param, out_param,
-out_is_imm, in_modifier,
-op_modifier, op, timeout);
+   ret = mlx4_cmd_wait(dev, in_param, out_param,
+   out_is_imm, in_modifier,
+   op_modifier, op, timeout);
else
-   return mlx4_cmd_poll(dev, in_param, out_param,
-out_is_imm, in_modifier,
-op_modifier, op, timeout);
+   ret = mlx4_cmd_poll(dev, in_param, out_param,
+   out_is_imm, in_modifier,
+   op_modifier, op, timeout);
+
+   up_read(_priv(dev)->cmd.switch_sem);
+   return ret;
}
return mlx4_slave_cmd(dev, in_param, out_param, out_is_imm,
  in_modifier, op_modifier, op, timeout);
@@ -2437,6 +2443,7 @@ int mlx4_cmd_init(struct mlx4_dev *dev)
int flags = 0;
 
if (!priv->cmd.initialized) {
+   init_rwsem(>cmd.switch_sem);
mutex_init(>cmd.slave_cmd_mutex);
sema_init(>cmd.poll_sem, 1);
priv->cmd.use_events = 0;
@@ -2566,6 +2573,7 @@ int mlx4_cmd_use_events(struct mlx4_dev *dev)
if (!priv->cmd.context)
return -ENOMEM;
 
+   down_write(>cmd.switch_sem);
for (i = 0; i < priv->cmd.max_cmds; ++i) {
priv->cmd.context[i].token = i;
priv->cmd.context[i].next  = i + 1;
@@ -2590,6 +2598,7 @@ int mlx4_cmd_use_events(struct mlx4_dev *dev)
 
down(>cmd.poll_sem);
priv->cmd.use_events = 1;
+   up_write(>cmd.switch_sem);
 
return err;
 }
@@ -2602,6 +2611,7 @@ void mlx4_cmd_use_polling(struct mlx4_dev *dev)
struct mlx4_priv *priv = mlx4_priv(dev);
int i;
 
+   down_write(>cmd.switch_sem);
priv->cmd.use_events = 0;
 
for (i = 0; i < priv->cmd.max_cmds; ++i)
@@ -2610,6 +2620,7 @@ void mlx4_cmd_use_polling(struct mlx4_dev *dev)
kfree(priv->cmd.context);
 
up(>cmd.poll_sem);
+   up_write(>cmd.switch_sem);
 }
 
 struct mlx4_cmd_mailbox *mlx4_alloc_cmd_mailbox(struct mlx4_dev *dev)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h 
b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index 6c58021..2f03e6e 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
@@ -45,6

Re: [PATCH] net/mlx4: Memcpy at slave_event should copy sizeof mlx4_eqe

[Jack Morgenstein]

Hi Carol,

Good catch!

Need to add an additional chunk to your fix -- see below.

On Sun, 25 Oct 2015 10:26:07 +0200
Or Gerlitz  wrote:


> 
> > ---
> >  drivers/net/ethernet/mellanox/mlx4/eq.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c
> > b/drivers/net/ethernet/mellanox/mlx4/eq.c index c344884..603d1c3
> > 100644 --- a/drivers/net/ethernet/mellanox/mlx4/eq.c
> > +++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
> > @@ -196,7 +196,7 @@ static void slave_event(struct mlx4_dev *dev,
> > u8 slave, struct mlx4_eqe *eqe) return;
> > }
> >
> > -   memcpy(s_eqe, eqe, dev->caps.eqe_size - 1);
> > +   memcpy(s_eqe, eqe, sizeof(struct mlx4_eqe) - 1);
> > s_eqe->slave_id = slave;
> > /* ensure all information is written before setting the
> > ownersip bit */ dma_wmb();

diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c 
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 0a32020..2177e56 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -2398,7 +2398,7 @@ int mlx4_multi_func_init(struct mlx4_dev *dev)
}
}
 
-   memset(>mfunc.master.cmd_eqe, 0, dev->caps.eqe_size);
+   memset(>mfunc.master.cmd_eqe, 0, sizeof(struct mlx4_eqe));
priv->mfunc.master.cmd_eqe.type = MLX4_EVENT_TYPE_CMD;
INIT_WORK(>mfunc.master.comm_work,
  mlx4_master_comm_channel);


> > --
> > 1.8.3.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

[Jack Morgenstein]

On Thursday 13 September 2007 20:57, Roland Dreier wrote:
 HW specific:
 
  - I already merged patches to enable MSI-X by default for mthca and
    mlx4.  I hope there aren't too many systems that get hosed if a
    MSI-X interrupt is generated.
 
  - Jack and Michael's mlx4 FMR support.  Will merge I guess, although
    I do hope to have time to address the DMA API abuse that is being
    copied from mthca, so that mlx4 and mthca work in Xen domU.
 
  - ehca patch queue.  Will merge, pending fixes for the few minor
    issues I commented on.
 
  - Steve's mthca router mode support.  Would be nice to see a review
    from someone at Mellanox.
 
  - Arthur's mthca doorbell alignment fixes.  I will experiment with a
    few different approaches and post what I like (and fix mlx4 as
    well).  I hope Arthur can review.
 
  - Michael's mlx4 WQE shrinking patch.  Not sure yet; I'll reply to
    the latest patch directly.
 
Missing from this list (IMPORTANT patch!):
[ofa-general] [PATCH 2 of 2] IB/mlx4: Handle new FW requirement for send 
request prefetching, for WQE sg lists
(Posted by me to list on Sept 4)
{patch header: 
This is an addendum to Roland's commit 0e6e74162164d908edf7889ac66dca09e7505745
(June 18). This addendum adds prefetch headroom marking processing for s/g 
segments.

We write s/g segments in reverse order into the WQE, in order to guarantee
that the first dword of all cachelines containing s/g segments is written last
(overwriting the headroom invalidation pattern). The entire cacheline will thus
contain valid data when the invalidation pattern is overwritten.
}
This patch series (1 of 2 is for libmlx4, the same issue).


Also, I'm now posting (in a separate post) the following patch to mlx4, which 
is important:
  display the following device information via sysfs:
  board_id, fw_ver, hw_rev, hca_type.

  The info is displayed under directory /sys/class/infiniband/mlx4_x, where x is
  the pci bus sequence number (starting from zero).

  This patch makes information available to ibstat and ibv_devinfo under the
  same directory as is used for tavor/arbel/sinai -- thus requiring no userspace
  modifications.

- Jack


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: I/OAT: Call for discussion

[Jack Vogel]

On 4/19/06, Christoph Hellwig [EMAIL PROTECTED] wrote:
 On Wed, Apr 19, 2006 at 10:28:41AM -0700, John Ronciak wrote:
  The hardware is going to generally available in June.  There are also
  lots of OEMs, OSVs and hardware vendors that have the system to test
  on today.  The early rollout of hardware has been very large.

 As a start to get people actually interested you should stop talking
 like a jerk and kill all these silly three-letter acronyms from your language.


??? For a community absolutely FILLED with everyday use of acronyms
it boggles the mind why you would call someone names for using them.

So if they were 4 letter ones it would make him a savant instead??

Jack
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html