Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-12-14 Thread Jakub Kicinski
On Fri, 09 Dec 2022 13:37:08 +0100 Paolo Abeni wrote: > I think this is the most feasible way out of the existing issue, and I > think this patchset should go via the networking tree, targeting the > Linux 6.2. FWIW some fields had been moved so this will not longer apply cleanly, see

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-12-14 Thread Paolo Abeni
On Fri, 2022-12-09 at 08:11 -0800, Jakub Kicinski wrote: > On Fri, 09 Dec 2022 13:37:08 +0100 Paolo Abeni wrote: > > I think this is the most feasible way out of the existing issue, and I > > think this patchset should go via the networking tree, targeting the > > Linux 6.2. > > FWIW some fields

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-12-14 Thread Paolo Abeni
On Mon, 2022-11-21 at 08:35 -0500, Benjamin Coddington wrote: > Since moving to memalloc_nofs_save/restore, SUNRPC has stopped setting the > GFP_NOIO flag on sk_allocation which the networking system uses to decide > when it is safe to use current->task_frag. The results of this are > unexpected

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-12-05 Thread Guillaume Nault
On Tue, Nov 29, 2022 at 11:47:47AM -0500, Benjamin Coddington wrote: > On 29 Nov 2022, at 9:02, Christoph Hellwig wrote: > > > Hmm. Having to set a flag to not accidentally corrupt per-task > > state seems a bit fragile. Wouldn't it make sense to find a way to opt > > into the feature only for

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-12-05 Thread Guillaume Nault
On Tue, Nov 29, 2022 at 03:02:42PM +0100, Christoph Hellwig wrote: > Hmm. Having to set a flag to not accidentally corrupt per-task > state seems a bit fragile. Wouldn't it make sense to find a way to opt > into the feature only for sockets created from the syscall layer? That's something I

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-12-05 Thread Jeff Layton
On Tue, 2022-11-29 at 15:02 +0100, Christoph Hellwig wrote: > Hmm. Having to set a flag to not accidentally corrupt per-task > state seems a bit fragile. Wouldn't it make sense to find a way to opt > into the feature only for sockets created from the syscall layer? I agree that that would be

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-29 Thread Benjamin Coddington
On 29 Nov 2022, at 9:02, Christoph Hellwig wrote: > Hmm. Having to set a flag to not accidentally corrupt per-task > state seems a bit fragile. Wouldn't it make sense to find a way to opt > into the feature only for sockets created from the syscall layer? It's totally fragile, and that's why

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-29 Thread Christoph Hellwig
Hmm. Having to set a flag to not accidentally corrupt per-task state seems a bit fragile. Wouldn't it make sense to find a way to opt into the feature only for sockets created from the syscall layer? -- You received this message because you are subscribed to the Google Groups "open-iscsi"

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-23 Thread Benjamin Coddington
On 21 Nov 2022, at 16:43, Shuah Khan wrote: > On 11/21/22 14:40, Shuah Khan wrote: >> On 11/21/22 07:34, Benjamin Coddington wrote: >>> On 21 Nov 2022, at 8:56, David Howells wrote: >>> Benjamin Coddington wrote: > Since moving to memalloc_nofs_save/restore, SUNRPC has stopped

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-23 Thread Shuah Khan
On 11/21/22 14:40, Shuah Khan wrote: On 11/21/22 07:34, Benjamin Coddington wrote: On 21 Nov 2022, at 8:56, David Howells wrote: Benjamin Coddington wrote: Since moving to memalloc_nofs_save/restore, SUNRPC has stopped setting the GFP_NOIO flag on sk_allocation which the networking system

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-23 Thread Shuah Khan
On 11/21/22 15:01, Benjamin Coddington wrote: On 21 Nov 2022, at 16:43, Shuah Khan wrote: On 11/21/22 14:40, Shuah Khan wrote: On 11/21/22 07:34, Benjamin Coddington wrote: On 21 Nov 2022, at 8:56, David Howells wrote: Benjamin Coddington wrote: Since moving to

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-23 Thread Benjamin Coddington
On 21 Nov 2022, at 17:32, Shuah Khan wrote: > On 11/21/22 15:01, Benjamin Coddington wrote: >> On 21 Nov 2022, at 16:43, Shuah Khan wrote: >> >>> On 11/21/22 14:40, Shuah Khan wrote: On 11/21/22 07:34, Benjamin Coddington wrote: > On 21 Nov 2022, at 8:56, David Howells wrote: >

[PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-23 Thread Benjamin Coddington
Since moving to memalloc_nofs_save/restore, SUNRPC has stopped setting the GFP_NOIO flag on sk_allocation which the networking system uses to decide when it is safe to use current->task_frag. The results of this are unexpected corruption in task_frag when SUNRPC is involved in memory reclaim.

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-23 Thread Shuah Khan
On 11/21/22 07:34, Benjamin Coddington wrote: On 21 Nov 2022, at 8:56, David Howells wrote: Benjamin Coddington wrote: Since moving to memalloc_nofs_save/restore, SUNRPC has stopped setting the GFP_NOIO flag on sk_allocation which the networking system uses to decide when it is safe to use

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-23 Thread David Howells
Benjamin Coddington wrote: > Since moving to memalloc_nofs_save/restore, SUNRPC has stopped setting the > GFP_NOIO flag on sk_allocation which the networking system uses to decide > when it is safe to use current->task_frag. Um, what's task_frag? David -- You received this message because

Re: [PATCH v1 2/3] Treewide: Stop corrupting socket's task_frag

2022-11-23 Thread Benjamin Coddington
On 21 Nov 2022, at 8:56, David Howells wrote: > Benjamin Coddington wrote: > >> Since moving to memalloc_nofs_save/restore, SUNRPC has stopped setting the >> GFP_NOIO flag on sk_allocation which the networking system uses to decide >> when it is safe to use current->task_frag. > > Um, what's