Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752376AbaAPCai (ORCPT ); Wed, 15 Jan 2014 21:30:38 -0500 Received: from mail.linux-iscsi.org ([67.23.28.174]:43894 "EHLO linux-iscsi.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752163AbaAPCaf (ORCPT ); Wed, 15 Jan 2014 21:30:35 -0500 Message-ID: <1389839550.5567.643.camel@haakon3.risingtidesystems.com> Subject: Re: [PATCH 00/14] target: Initial support for DIF Type1+Type3 emulation From: "Nicholas A. Bellinger" To: "Martin K. Petersen" Cc: sagi grimberg , "Nicholas A. Bellinger" , target-devel , linux-scsi , linux-kernel , Christoph Hellwig , Hannes Reinecke , Or Gerlitz Date: Wed, 15 Jan 2014 18:32:30 -0800 In-Reply-To: References: <1389212157-14540-1-git-send-email-nab@daterainc.com> <52D6CD70.20706@mellanox.com> <1389822920.5567.560.camel@haakon3.risingtidesystems.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2014-01-15 at 20:42 -0500, Martin K. Petersen wrote: > >>>>> "nab" == Nicholas A Bellinger writes: > > nab> The issue is that existing fs/bio-integrity.c code always assumes > nab> client/initiator mode, in that it will attempt to > nab> bio_integrity_generate() protection information in the submit_bio > nab> WRITE path, and bio_integrity_verify() of protection information in > nab> the bio_endio READ completion path. > > Only if the submit_bio() caller hasn't attached protection information > already. If you submit a bio with a bip already attached the block layer > will not generate/verify. > Mmm, missed that detail. So that would take care of the passthrough for the WRITE case then.. How about a passthrough on the READ completion side for target fabrics doing a hardware VERIFY..? Any preferences how this should work..? Also, for IBLOCK responses to properly generate GUARD + REFERENCE tag CHECK_CONDITION sense failures from an underlying device VERIFY failure, there will also need to be a way to propagate up the failure status through bio_endio(). I assume bio_integrity_payload is the proper place for adding something like this..? One other item from my TODO list for IBLOCK protection support is how to go about determining which DIF type to expose in the target, based upon what is currently enabled on the underlying struct block_device. I'm currently trying to deduce the protection type by looking at struct blk_integrity, but it would be helpful to make this explicit with bi->prot_type. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/