Fix lack of multiple KNI requests handling support by introducing a
rotating ring mechanism for the sync buffer.
Prevent kni_net_change_rx_flags() from calling kni_net_process_request()
with a malformed request.
Bugzilla ID: 809
Signed-off-by: Elad Nachman
---
kernel/linux/kni/kni_dev.h
Fix lack of multiple KNI requests handling support by introducing a
request in progress flag which will fail additional requests with
EAGAIN return code if the original request has not been processed
by user-space.
Bugzilla ID: 809
Signed-off-by: Elad Nachman
---
kernel/linux/kni/kni_net.c
Hi,
EAGAIN is propogated back to the kernel and to the caller.
We cannot retry from the kni kernel module since we hold the rtnl lock.
FYI,
Elad
בתאריך יום ב׳, 4 באוק׳ 2021, 16:05, מאת Ferruh Yigit <
ferruh.yi...@intel.com>:
> On 9/24/2021 11:54 AM, Elad Nachman wrote:
> &
<
ferruh.yi...@intel.com>:
> On 10/4/2021 2:09 PM, Elad Nachman wrote:
> > Hi,
> >
> > EAGAIN is propogated back to the kernel and to the caller.
> >
>
> So will the user get an error, or it will be handled by the kernel and
> retried?
>
> > We cannot
בתאריך יום ב׳, 4 באוק׳ 2021, 17:51, מאת Ferruh Yigit <
ferruh.yi...@intel.com>:
> On 10/4/2021 3:25 PM, Elad Nachman wrote:
>
> Can you please try to not top post, it will make impossible to follow this
> discussion later from the mail archives.
>
> > 1. Userspace wil
On Mon, Oct 4, 2021 at 7:05 PM Ferruh Yigit wrote:
> On 10/4/2021 3:58 PM, Elad Nachman wrote:
> > בתאריך יום ב׳, 4 באוק׳ 2021, 17:51, מאת Ferruh Yigit <
> > ferruh.yi...@intel.com>:
> >
> >> On 10/4/2021 3:25 PM, Elad Nachman wrote:
> >>
> >
reate it IMHO is to either:
run the ioctl from two parallel threads or perhaps assign RT fifo priority
to the application calling ioctl in a row.
Elad
>
> On Mon, Oct 4, 2021 at 12:19 PM Elad Nachman wrote:
>
>>
>>
>> On Mon, Oct 4, 2021 at 7:05 PM Ferruh Yigit
>>
rface down : unlock rtnl, send request to user-space,
> > wait for response, send the response error code to caller in user-space.
> >
> > request == interface down: send request to user-space, return immediately
> > with error code of 0 (success) to user-space.
> >
> > Fixes: 3fc5ca2f6352 ("kni: initial import")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Elad Nachman
> > ---
> > Cc: Stephen Hemminger
> > Cc: Igor Ryzhov
> > Cc: Dan Gora
> >
>
> Hi Elad, Igor,
>
> Can you please review/test this set when you have time?
>
> Thanks,
> ferruh
>
>
down since this is the path called
from __dev_close_many() , causing the corruption of the close_list.
Signed-off-by: Elad Nachman
---
kernel/linux/kni/kni_net.c | 47 +-
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/kernel/linux/kni/kni_ne
Hi,
Owing to my current development schedule and obligations, I see no
opportunity to make this set of changes in the near future.
Sorry,
Elad.
בתאריך יום ב׳, 15 במרץ 2021, 19:17, מאת Ferruh Yigit <
ferruh.yi...@intel.com>:
> On 2/25/2021 2:32 PM, Elad Nachman wrote:
> > T
change , without the empty
line, and with the comment moved to the proper place in the code.
Waiting for your decision,
Elad.
On Fri, Feb 19, 2021 at 8:42 PM Ferruh Yigit wrote:
>
> On 11/26/2020 2:46 PM, Elad Nachman wrote:
> > This patch leverages on Stephen Hemminger's 641
nging the device down since this is the path called
from __dev_close_many() , causing the corruption of the close_list.
Depends-on: patch-64106 ("kni: fix kernel deadlock when using mlx devices")
Signed-off-by: Elad Nachman
---
V2:
* rebuild the patch as increment from patch 64106
*
This first part of v3 of the patch re-introduces Stephen Hemminger's
patch 64106 . This part changes the parameter kni_net_process_request()
gets and introduces the initial rtnl unlocking mechanism.
Signed-off-by: Elad Nachman
---
v3:
* Include original patch and new patch as a series of
since this is the path called
from __dev_close_many() , causing the corruption of the close_list.
Signed-off-by: Elad Nachman
---
v3:
* Include original patch and new patch as a series of patch, added a
comment to the new patch
v2:
* rebuild the patch as increment from patch 64106
* fix comment
If it is not a problem, then I don't see any point in merging this.
>
> On Tue, Feb 23, 2021 at 4:45 PM Elad Nachman wrote:
>>
>> This part of the series includes my fixes for the issues reported
>> by Ferruh and Igor on top of part 1 of the patch series:
>&g
er fix.
> It may work for you because you don't disable interfaces, but it will fail
> for users who do.
>
> On Wed, Feb 24, 2021 at 4:33 PM Elad Nachman wrote:
>>
>> Currently KNI has a lot of issues with deadlocks locking the code,
>> after this commit, they
this fix works for you doesn't mean that it will work
>> > for all DPDK users.
>> >
>> > For example, I provided two simple commands: "ip link set up" and "ip link
>> > set down".
>> > Your fix works for only one of them. For me,
This first part of v4 of the patch re-introduces Stephen Hemminger's
patch 64106 . This part changes the parameter kni_net_process_request()
gets and introduces the initial rtnl unlocking mechanism.
Signed-off-by: Elad Nachman
---
v4:
* for if down case, send asynchronously with rtnl locke
down: send request to user-space, return immediately
with error code of 0 (success) to user-space.
Signed-off-by: Elad Nachman
---
v4:
* for if down case, send asynchronously with rtnl locked and without
wait, returning immediately to avoid both kernel race conditions
and deadlock in user
The way the kernel handles its locks and lists for the dev close many
path, there is no way you can go around this with rtnl unlocked :
"
There is a race condition in __dev_close_many() processing the
close_list while the application terminates.
It looks like if two vEth devices are terminating,
a
don't have a better proposal, but I think it is not correct to
> change
> > > the behavior of KNI (making link down without a real response).
> > > Even though we know that communicating with userspace under rtnl_lock
> is a
> > > bad idea, it works as it is for
21 matches
Mail list logo
