Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 24 Jun 2021 03:04:15 -0700
From:   Satya Tangirala <satyaprateek2357@gmail.com>
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     Satya Tangirala <satyat@google.com>, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH v3 07/10] mmc: handle error from blk_ksm_register()
Message-ID: <20210624100415.GA4845@fractal>
References: <20210604195900.2096121-1-satyat@google.com>
 <20210604195900.2096121-8-satyat@google.com>
 <YMrAn7EkKkNVEjUW@sol.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YMrAn7EkKkNVEjUW@sol.localdomain>
Precedence: bulk

On Wed, Jun 16, 2021 at 08:25:19PM -0700, Eric Biggers wrote:
> On Fri, Jun 04, 2021 at 07:58:57PM +0000, Satya Tangirala wrote:
> > +		/*
> > +		 * This WARN_ON should never trigger since &host->ksm won't be
> > +		 * "empty" (i.e. will support at least 1 crypto capability), an
> > +		 * MMC device's request queue doesn't support integrity, and
> > +		 * it also satisfies all the block layer constraints (i.e.
> > +		 * supports SG gaps, doesn't have chunk sectors, has a
> > +		 * sufficiently large supported max_segments per bio)
> > +		 */
> > +		WARN_ON(!blk_ksm_register(&host->ksm, q));
> > +	}
> >  }
> 
> There appear to be some MMC host drivers that set max_segments to 1, so this
> explanation may not hold.  It may hold for every driver that actually supports
> crypto, though.
Yeah, I think it does hold for every driver that actually supports
crypto. I'll check this more carefully before sending out the next
version.
> 
> - Eric