On Mon, Jan 20, 2025 at 04:16:49PM +, Cosmin Ratiu wrote:
> On Fri, 2025-01-17 at 08:54 +0100, Steffen Klassert wrote:
> > >
> > > Hi Jianbo,
> > >
> > > I talked with Sabrina and it looks we can't simply do this. Because
> > > both
> > > xfrm_add_sa_expire() and xfrm_timer_handler() calling
On Fri, 2025-01-17 at 08:54 +0100, Steffen Klassert wrote:
> >
> > Hi Jianbo,
> >
> > I talked with Sabrina and it looks we can't simply do this. Because
> > both
> > xfrm_add_sa_expire() and xfrm_timer_handler() calling
> > __xfrm_state_delete() under
> > spin lock. If we move the xfrm_dev_state
On Wed, Jan 15, 2025 at 09:19:33AM +, Hangbin Liu wrote:
> On Wed, Jan 08, 2025 at 07:15:00AM +, Hangbin Liu wrote:
> > > > > > > I don't know how to disable bonding sleeping since we use
> > > > > > > mutex_lock now.
> > > > > > > Hi Jianbo, do you have any idea?
> > > > > > >
> > > > >
On Wed, Jan 08, 2025 at 07:15:00AM +, Hangbin Liu wrote:
> > > > > > I don't know how to disable bonding sleeping since we use
> > > > > > mutex_lock now.
> > > > > > Hi Jianbo, do you have any idea?
> > > > > >
> > > > >
> > > > > I think we should allow drivers to sleep in the callbacks. S
On 1/9/2025 6:17 PM, Hangbin Liu wrote:
On Thu, Jan 09, 2025 at 05:51:07PM +0800, Jianbo Liu wrote:
No, we don't need. But I am trying to understand what you said in your last
email about adding a new lock, or unlocking spin lock in
I *thought* we need the spin lock in xfrm_state_delete().
On Thu, Jan 09, 2025 at 05:51:07PM +0800, Jianbo Liu wrote:
> > > No, we don't need. But I am trying to understand what you said in your
> > > last
> > > email about adding a new lock, or unlocking spin lock in
> >
> > I *thought* we need the spin lock in xfrm_state_delete(). So to protect
> > x
On 1/9/2025 4:37 PM, Hangbin Liu wrote:
On Thu, Jan 09, 2025 at 09:26:38AM +0800, Jianbo Liu wrote:
On 1/8/2025 3:14 PM, Hangbin Liu wrote:
On Wed, Jan 08, 2025 at 11:40:05AM +0800, Jianbo Liu wrote:
On 1/8/2025 10:46 AM, Hangbin Liu wrote:
On Mon, Jan 06, 2025 at 10:47:16AM +, Han
On Thu, Jan 09, 2025 at 09:26:38AM +0800, Jianbo Liu wrote:
>
>
> On 1/8/2025 3:14 PM, Hangbin Liu wrote:
> > On Wed, Jan 08, 2025 at 11:40:05AM +0800, Jianbo Liu wrote:
> > >
> > >
> > > On 1/8/2025 10:46 AM, Hangbin Liu wrote:
> > > > On Mon, Jan 06, 2025 at 10:47:16AM +, Hangbin Liu wrot
On 1/8/2025 3:14 PM, Hangbin Liu wrote:
On Wed, Jan 08, 2025 at 11:40:05AM +0800, Jianbo Liu wrote:
On 1/8/2025 10:46 AM, Hangbin Liu wrote:
On Mon, Jan 06, 2025 at 10:47:16AM +, Hangbin Liu wrote:
On Thu, Jan 02, 2025 at 11:33:34AM +0800, Jianbo Liu wrote:
Re-locking doesn't look gr
On Wed, Jan 08, 2025 at 11:40:05AM +0800, Jianbo Liu wrote:
>
>
> On 1/8/2025 10:46 AM, Hangbin Liu wrote:
> > On Mon, Jan 06, 2025 at 10:47:16AM +, Hangbin Liu wrote:
> > > On Thu, Jan 02, 2025 at 11:33:34AM +0800, Jianbo Liu wrote:
> > > > > > Re-locking doesn't look great, glancing at the
On 1/8/2025 10:46 AM, Hangbin Liu wrote:
On Mon, Jan 06, 2025 at 10:47:16AM +, Hangbin Liu wrote:
On Thu, Jan 02, 2025 at 11:33:34AM +0800, Jianbo Liu wrote:
Re-locking doesn't look great, glancing at the code I don't see any
obvious better workarounds. Easiest fix would be to don't let
On Mon, Jan 06, 2025 at 10:47:16AM +, Hangbin Liu wrote:
> On Thu, Jan 02, 2025 at 11:33:34AM +0800, Jianbo Liu wrote:
> > > > Re-locking doesn't look great, glancing at the code I don't see any
> > > > obvious better workarounds. Easiest fix would be to don't let the
> > > > drivers sleep in t
On Thu, Jan 02, 2025 at 11:33:34AM +0800, Jianbo Liu wrote:
> > > Re-locking doesn't look great, glancing at the code I don't see any
> > > obvious better workarounds. Easiest fix would be to don't let the
> > > drivers sleep in the callbacks and then we can go back to a spin lock.
> > > Maybe nvid
On Thu, Jan 02, 2025 at 11:33:34AM +0800, Jianbo Liu wrote:
> > > Re-locking doesn't look great, glancing at the code I don't see any
> > > obvious better workarounds. Easiest fix would be to don't let the
> > > drivers sleep in the callbacks and then we can go back to a spin lock.
> > > Maybe nvid
On 1/2/2025 10:44 AM, Hangbin Liu wrote:
On Fri, Dec 13, 2024 at 07:31:27PM -0800, Jakub Kicinski wrote:
On Fri, 13 Dec 2024 07:18:08 + Hangbin Liu wrote:
On Thu, Dec 12, 2024 at 06:27:34AM -0800, Jakub Kicinski wrote:
On Wed, 11 Dec 2024 07:11:25 + Hangbin Liu wrote:
The first pat
On Fri, Dec 13, 2024 at 07:31:27PM -0800, Jakub Kicinski wrote:
> On Fri, 13 Dec 2024 07:18:08 + Hangbin Liu wrote:
> > On Thu, Dec 12, 2024 at 06:27:34AM -0800, Jakub Kicinski wrote:
> > > On Wed, 11 Dec 2024 07:11:25 + Hangbin Liu wrote:
> > > > The first patch fixes the xfrm offload fe
On Fri, 13 Dec 2024 07:18:08 + Hangbin Liu wrote:
> On Thu, Dec 12, 2024 at 06:27:34AM -0800, Jakub Kicinski wrote:
> > On Wed, 11 Dec 2024 07:11:25 + Hangbin Liu wrote:
> > > The first patch fixes the xfrm offload feature during setup active-backup
> > > mode. The second patch add a ipse
On Thu, Dec 12, 2024 at 06:27:34AM -0800, Jakub Kicinski wrote:
> On Wed, 11 Dec 2024 07:11:25 + Hangbin Liu wrote:
> > The first patch fixes the xfrm offload feature during setup active-backup
> > mode. The second patch add a ipsec offload testing.
>
> Looks like the test is too good, is ther
On Wed, 11 Dec 2024 07:11:25 + Hangbin Liu wrote:
> The first patch fixes the xfrm offload feature during setup active-backup
> mode. The second patch add a ipsec offload testing.
Looks like the test is too good, is there a fix pending somewhere for
the BUG below? We can't merge the test befor
The first patch fixes the xfrm offload feature during setup active-backup
mode. The second patch add a ipsec offload testing.
Hangbin Liu (2):
bonding: fix xfrm offload feature setup on active-backup mode
selftests: bonding: add ipsec offload test
drivers/net/bonding/bond_main.c
20 matches
Mail list logo
