diff for duplicates of <554B6F2A.6000608@dev.mellanox.co.il> diff --git a/a/1.txt b/N1/1.txt index c9dd7ef..614c5be 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,6 +1,6 @@ On 5/7/2015 4:39 PM, Chuck Lever wrote: > -> On May 7, 2015, at 6:00 AM, Sagi Grimberg <sagig@dev.mellanox.co.il> wrote: +> On May 7, 2015, at 6:00 AM, Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote: > >> On 5/4/2015 8:57 PM, Chuck Lever wrote: >>> The connect worker can replace ri_id, but prevents ri_id->device @@ -13,7 +13,7 @@ On 5/7/2015 4:39 PM, Chuck Lever wrote: >>> Other code can use it to save an extra address generation (one >>> pointer dereference instead of two). >>> ->>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> +>>> Signed-off-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> >>> --- >>> net/sunrpc/xprtrdma/fmr_ops.c | 8 +---- >>> net/sunrpc/xprtrdma/frwr_ops.c | 12 +++---- @@ -88,3 +88,7 @@ wandering about ia->ri_device, which might not have been updated yet. Just asking, assuming your transport device can change between consecutive reconnects (the new cm_id will contain another device), is it safe to rely on ri_device being updated? +-- +To unsubscribe from this list: send the line "unsubscribe linux-rdma" in +the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 22cf0ca..ab8956e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,17 +2,18 @@ "ref\020150504175720.3483.80356.stgit@manet.1015granger.net\0" "ref\0554B37CF.2070206@dev.mellanox.co.il\0" "ref\0E1ADA91B-45DA-46B6-A114-E2600613969A@oracle.com\0" - "From\0Sagi Grimberg <sagig@dev.mellanox.co.il>\0" + "ref\0E1ADA91B-45DA-46B6-A114-E2600613969A-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org\0" + "From\0Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>\0" "Subject\0Re: [PATCH v1 04/14] xprtrdma: Use ib_device pointer safely\0" "Date\0Thu, 07 May 2015 16:56:58 +0300\0" - "To\0Chuck Lever <chuck.lever@oracle.com>\0" - "Cc\0linux-rdma@vger.kernel.org" - " Linux NFS Mailing List <linux-nfs@vger.kernel.org>\0" + "To\0Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\0" + "Cc\0linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" + " Linux NFS Mailing List <linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>\0" "\00:1\0" "b\0" "On 5/7/2015 4:39 PM, Chuck Lever wrote:\n" ">\n" - "> On May 7, 2015, at 6:00 AM, Sagi Grimberg <sagig@dev.mellanox.co.il> wrote:\n" + "> On May 7, 2015, at 6:00 AM, Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:\n" ">\n" ">> On 5/4/2015 8:57 PM, Chuck Lever wrote:\n" ">>> The connect worker can replace ri_id, but prevents ri_id->device\n" @@ -25,7 +26,7 @@ ">>> Other code can use it to save an extra address generation (one\n" ">>> pointer dereference instead of two).\n" ">>>\n" - ">>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>\n" + ">>> Signed-off-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\n" ">>> ---\n" ">>> net/sunrpc/xprtrdma/fmr_ops.c | 8 +----\n" ">>> net/sunrpc/xprtrdma/frwr_ops.c | 12 +++----\n" @@ -99,6 +100,10 @@ "\n" "Just asking, assuming your transport device can change between \n" "consecutive reconnects (the new cm_id will contain another device), is\n" - it safe to rely on ri_device being updated? + "it safe to rely on ri_device being updated?\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-rdma\" in\n" + "the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -16d38944d71899ca34b25a273efe620d51d7afea2daca19aedf801cb7110dc23 +190f82079b7b816ac48b090308176a718605acc1e1fa017337df882e0cd7ff00
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.