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
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
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
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
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
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
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
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"
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
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
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
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:
>
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.
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
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
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
16 matches
Mail list logo