Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753828AbcDJOE6 (ORCPT ); Sun, 10 Apr 2016 10:04:58 -0400 Received: from casper.infradead.org ([85.118.1.10]:60228 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753014AbcDJOE5 (ORCPT ); Sun, 10 Apr 2016 10:04:57 -0400 Date: Sun, 10 Apr 2016 15:04:51 +0100 (BST) From: James Simmons To: Jeff Mahoney cc: Greg Kroah-Hartman , devel@driverdev.osuosl.org, Andreas Dilger , Oleg Drokin , Linux Kernel Mailing List , Lustre Development List Subject: Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64 In-Reply-To: <63807394-FF62-4376-95FD-412309D47BF7@suse.com> Message-ID: References: <1460294020-2111-1-git-send-email-jsimmons@infradead.org> <1460294020-2111-14-git-send-email-jsimmons@infradead.org> <63807394-FF62-4376-95FD-412309D47BF7@suse.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160410_150451_464662_96338F56 X-CRM114-Status: GOOD ( 23.74 ) X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.4.0 on casper.infradead.org summary: Content analysis details: (-1.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 NO_RELAYS Informational: message was not relayed via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2392 Lines: 58 > This patch was shown not to work. I just haven't removed it from opensuse yet. Its been running in our production tree as well for some time. Guess that change is a noop. In any case we have been discussing redoing the lloop driver anyways. Just need to find the cycles. > -- > Jeff Mahoney > (apologies for the top post -- from my mobile) > > > On Apr 10, 2016, at 9:13 AM, James Simmons wrote: > > > > From: Jeff Mahoney > > > > On ppc64 with 64k pages, we get a build failure in lloop: > > > > drivers/staging/lustre/lustre/llite/lloop.c:527:2: > > note: in expansion of macro 'CLASSERT' > > CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > > > > There's no need to change the queue's logical block size. Even if it could > > accept a 64k value, that would result in any file system on top of it > > needing to also use 64k blocks. It'd be safe to set it to 4k, but there's > > no actual need for it. It's not used to split requests except for WRITE_SAME, > > which lloop doesn't implement anyway. > > > > Signed-off-by: Jeff Mahoney > > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000 > > Reviewed-on: http://review.whamcloud.com/7745 > > Reviewed-by: Jinshan Xiong > > Reviewed-by: Minh Diep > > Reviewed-by: Oleg Drokin > > Signed-off-by: James Simmons > > --- > > drivers/staging/lustre/lustre/llite/lloop.c | 3 --- > > 1 files changed, 0 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/staging/lustre/lustre/llite/lloop.c b/drivers/staging/lustre/lustre/llite/lloop.c > > index b725fc1..f396753 100644 > > --- a/drivers/staging/lustre/lustre/llite/lloop.c > > +++ b/drivers/staging/lustre/lustre/llite/lloop.c > > @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, > > lo->lo_queue->queuedata = lo; > > > > /* queue parameters */ > > - CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > > - blk_queue_logical_block_size(lo->lo_queue, > > - (unsigned short)PAGE_CACHE_SIZE); > > blk_queue_max_hw_sectors(lo->lo_queue, > > LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9)); > > blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS); > > -- > > 1.7.1 > > > > > >