From: "Su, Xuemin" <s...@chinanetcenter.com>
There is a corner case in which udp packets belonging to a same
flow are hashed to different socket when hslot->count changes from 10
to 11:
1) When hslot->count <= 10, __udp_lib_lookup() searches udp_table->ha
From: "Su, Xuemin"
There is a corner case in which udp packets belonging to a same
flow are hashed to different socket when hslot->count changes from 10
to 11:
1) When hslot->count <= 10, __udp_lib_lookup() searches udp_table->hash,
and always passes 'daddr' to udp_eha
From: "Su, Xuemin" <s...@chinanetcenter.com>
There is a corner case in which udp packets belonging to a same
flow are hashed to different socket when hslot->count changes from 10
to 11:
1) When hslot->count <= 10, __udp_lib_lookup() searches udp_table->ha
From: "Su, Xuemin"
There is a corner case in which udp packets belonging to a same
flow are hashed to different socket when hslot->count changes from 10
to 11:
1) When hslot->count <= 10, __udp_lib_lookup() searches udp_table->hash,
and always passes 'daddr' to udp_eha
On Wed 2016-06-08 at 08:43 -0700, Eric Dumazet wrote:
> I am not convinced this is the right way to fix the issue.
>
> Fact that you did not change udp4_lib_lookup2() is telling me something.
>
>
> 1) If host has 100 different IP, and 10 sockets bound to 0.0.0.0:53
> 2) If we receive datagrams
On Wed 2016-06-08 at 08:43 -0700, Eric Dumazet wrote:
> I am not convinced this is the right way to fix the issue.
>
> Fact that you did not change udp4_lib_lookup2() is telling me something.
>
>
> 1) If host has 100 different IP, and 10 sockets bound to 0.0.0.0:53
> 2) If we receive datagrams
From: "Su, Xuemin" <s...@chinanetcenter.com>
There is a corner case in which udp packets belonging to a same
flow are hashed to different socket when hslot->count changes from 10
to 11:
1) When hslot->count <= 10, __udp_lib_lookup() searches udp_table->ha
From: "Su, Xuemin"
There is a corner case in which udp packets belonging to a same
flow are hashed to different socket when hslot->count changes from 10
to 11:
1) When hslot->count <= 10, __udp_lib_lookup() searches udp_table->hash,
and always passes 'daddr' to udp_eha
From: "Su, Xuemin" <s...@chinanetcenter.com>
There is a corner case in which udp packets belonging to a same
flow are hashed to different socket when hslot->count changes from 10
to 11:
1) When hslot->count <= 10, __udp_lib_lookup() searches udp_table->ha
From: "Su, Xuemin"
There is a corner case in which udp packets belonging to a same
flow are hashed to different socket when hslot->count changes from 10
to 11:
1) When hslot->count <= 10, __udp_lib_lookup() searches udp_table->hash,
and always passes 'daddr' to udp_eha
From: liu chuansheng
Date: Thu, 31 Jan 2013 22:13:00 +0800
Subject: [PATCH] drm/radeon: Calling object_unrefer() when creating fb
failure
When kzalloc() failed in radeon_user_framebuffer_create(), need to
call object_unreference() to match the object_reference().
Signed-off-by: liu chuansheng
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Thursday, January 24, 2013 5:05 PM
To: Su, Xuemin
Cc: airl...@linux.ie; dri-de...@lists.freedesktop.org;
linux-kernel@vger.kernel.org; yanmin_zh...@linux.intel.com; He, Bo
Subject: Re: [PATCH V3] drm_crtc
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Thursday, January 24, 2013 5:05 PM
To: Su, Xuemin
Cc: airl...@linux.ie; dri-de...@lists.freedesktop.org;
linux-kernel@vger.kernel.org; yanmin_zh...@linux.intel.com; He, Bo
Subject: Re: [PATCH V3] drm_crtc
From: liu chuansheng chuansheng@intel.com
Date: Thu, 31 Jan 2013 22:13:00 +0800
Subject: [PATCH] drm/radeon: Calling object_unrefer() when creating fb
failure
When kzalloc() failed in radeon_user_framebuffer_create(), need to
call object_unreference() to match the object_reference().
On Thu, 2013-01-24 at 10:31 +0200, Jani Nikula wrote:
> > }
> > + /* some buggy driver may return NULL here, which may cause panic */
> > + BUG_ON(!fb);
>
> I fail to see the benefit of this compared to just letting it oops...
>
> > or->fb_id = fb->base.id;
>
> ...right here.
>
>
On Thu, 2013-01-24 at 10:31 +0200, Jani Nikula wrote:
}
+ /* some buggy driver may return NULL here, which may cause panic */
+ BUG_ON(!fb);
I fail to see the benefit of this compared to just letting it oops...
or-fb_id = fb-base.id;
...right here.
For PATCH V3, I
From: xueminsu
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL
Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.
Signed-off-by: xueminsu
---
drivers/gpu/drm/drm_crtc.c |2 ++
1 files changed, 2 insertions(+),
-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Wednesday, January 23, 2013 5:54 PM
>To: Su, Xuemin
>Cc: airl...@linux.ie; dri-de...@lists.freedesktop.org;
>linux-kernel@vger.kernel.org; yanmin_zh...@linux.in
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, January 23, 2013 5:54 PM
To: Su, Xuemin
Cc: airl...@linux.ie; dri-de...@lists.freedesktop.org;
linux-kernel@vger.kernel.org; yanmin_zh...@linux.intel.com; He, Bo
Subject: Re
From: xueminsu xuemin...@intel.com
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL
Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.
Signed-off-by: xueminsu xuemin...@intel.com
---
drivers/gpu/drm/drm_crtc.c |2
From: xueminsu
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL
Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.
Signed-off-by: xueminsu
---
drivers/gpu/drm/drm_crtc.c |7 +++
1 files changed, 7
From: xueminsu
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL
Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.
Signed-off-by: xueminsu
---
drivers/gpu/drm/drm_crtc.c |6 ++
1 files changed, 6
From: xueminsu
Date: Tue, 22 Jan 2013 22:16:53 +0800
Subject: [PATCH] radeon_display: Use pointer return error codes
drm_mode_addfb() expects fb_create return error code
instead of NULL.
Signed-off-by: xueminsu
---
drivers/gpu/drm/radeon/radeon_display.c |2 +-
1 files changed, 1
From: xueminsu xuemin...@intel.com
Date: Tue, 22 Jan 2013 22:16:53 +0800
Subject: [PATCH] radeon_display: Use pointer return error codes
drm_mode_addfb() expects fb_create return error code
instead of NULL.
Signed-off-by: xueminsu xuemin...@intel.com
---
drivers/gpu/drm/radeon/radeon_display.c
From: xueminsu xuemin...@intel.com
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL
Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.
Signed-off-by: xueminsu xuemin...@intel.com
---
drivers/gpu/drm/drm_crtc.c |6
From: xueminsu xuemin...@intel.com
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL
Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.
Signed-off-by: xueminsu xuemin...@intel.com
---
drivers/gpu/drm/drm_crtc.c |7
26 matches
Mail list logo
