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 corruption in task_frag when SUNRPC is involved in memory
> reclaim.
> 
> The corruption can be seen in crashes, but the root cause is often
> difficult to ascertain as a crashing machine's stack trace will have no
> evidence of being near NFS or SUNRPC code.  I believe this problem to
> be much more pervasive than reports to the community may indicate.
> 
> Fix this by having kernel users of sockets that may corrupt task_frag due
> to reclaim set sk_use_task_frag = false.  Preemptively correcting this
> situation for users that still set sk_allocation allows them to convert to
> memalloc_nofs_save/restore without the same unexpected corruptions that are
> sure to follow, unlikely to show up in testing, and difficult to bisect.
> 
> CC: Philipp Reisner 
> CC: Lars Ellenberg 
> CC: "Christoph Böhmwalder" 
> CC: Jens Axboe 
> CC: Josef Bacik 
> CC: Keith Busch 
> CC: Christoph Hellwig 
> CC: Sagi Grimberg 
> CC: Lee Duncan 
> CC: Chris Leech 
> CC: Mike Christie 
> CC: "James E.J. Bottomley" 
> CC: "Martin K. Petersen" 
> CC: Valentina Manea 
> CC: Shuah Khan 
> CC: Greg Kroah-Hartman 
> CC: David Howells 
> CC: Marc Dionne 
> CC: Steve French 
> CC: Christine Caulfield 
> CC: David Teigland 
> CC: Mark Fasheh 
> CC: Joel Becker 
> CC: Joseph Qi 
> CC: Eric Van Hensbergen 
> CC: Latchesar Ionkov 
> CC: Dominique Martinet 
> CC: "David S. Miller" 
> CC: Eric Dumazet 
> CC: Jakub Kicinski 
> CC: Paolo Abeni 
> CC: Ilya Dryomov 
> CC: Xiubo Li 
> CC: Chuck Lever 
> CC: Jeff Layton 
> CC: Trond Myklebust 
> CC: Anna Schumaker 
> CC: drbd-...@lists.linbit.com
> CC: linux-bl...@vger.kernel.org
> CC: linux-ker...@vger.kernel.org
> CC: n...@other.debian.org
> CC: linux-n...@lists.infradead.org
> CC: open-iscsi@googlegroups.com
> CC: linux-s...@vger.kernel.org
> CC: linux-...@vger.kernel.org
> CC: linux-...@lists.infradead.org
> CC: linux-c...@vger.kernel.org
> CC: samba-techni...@lists.samba.org
> CC: cluster-de...@redhat.com
> CC: ocfs2-de...@oss.oracle.com
> CC: v9fs-develo...@lists.sourceforge.net
> CC: net...@vger.kernel.org
> CC: ceph-de...@vger.kernel.org
> CC: linux-...@vger.kernel.org
> 
> Suggested-by: Guillaume Nault 
> Signed-off-by: Benjamin Coddington 

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.

If someone has disagreement with the above, please speak! 

Thanks,

Paolo

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/d220402a232e204676d9100d6fe4c2ae08f753ee.camel%40redhat.com.


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 b534dc46c8ae016. But I think we can apply it to net since the merge
window is upon us? Just a heads up.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/20221209081101.7500478c%40kernel.org.


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 had been moved so this will not longer apply cleanly,
> see b534dc46c8ae016. But I think we can apply it to net since the merge
> window is upon us? Just a heads up.

We will need an additional revision, see my reply to patch 3/3. I think
the -net tree should be the appropriate target.

Thanks,

Paolo

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/73186bd6e1ad62da16726b95b1a266c0aeb39719.camel%40redhat.com.


Re: [PATCH 0/2] scsi:donot skip lun if inquiry returns PQ=1 for all hosts

2022-12-14 Thread Christoph Hellwig
On Wed, Dec 14, 2022 at 03:08:44PM +0800, Wenchao Hao wrote:
> When iSCSI initiator logged in target, the target attached none valid
> lun but lun0. lun0 is not an valid disk, while it would response
> inquiry command with PQ=1 and other general scsi commands like probe lun.
> The others luns of target is added/removed dynamicly.

I can't find any special casing of LUN0 in RFC7144, can you clarify
where you think that treats LUN0 any differently than other transports?

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/Y5rHX95Vvl1aLhbp%40infradead.org.