Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758682Ab1BPEgV (ORCPT ); Tue, 15 Feb 2011 23:36:21 -0500 Received: from mail-iy0-f174.google.com ([209.85.210.174]:33822 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756576Ab1BPEgT convert rfc822-to-8bit (ORCPT ); Tue, 15 Feb 2011 23:36:19 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=szKc5bK8kNm6W/oyPX+QsX5ZNV0iurVlyipM/VucvPkGVus82D/NyyQGGvvMQwuDZh PqdOjgQ8iwBp7AHWpvHCRZcNzznkfUELpwCzvL9uNBYIHv0xmNm4pLRSHfCSX8Sq80nJ u/Vi/P4hGUXCebnzouT4FP9EXz5NDMweKkYvI= MIME-Version: 1.0 In-Reply-To: References: <20110207032407.GA27404@ca-server1.us.oracle.com> <1ddd01a8-591a-42bc-8bb3-561843b31acb@default> Date: Wed, 16 Feb 2011 13:36:18 +0900 Message-ID: Subject: Re: [PATCH V2 0/3] drivers/staging: zcache: dynamic page cache/swap compression From: Minchan Kim To: Dan Magenheimer Cc: Matt , gregkh@suse.de, Chris Mason , linux-kernel@vger.kernel.org, linux-mm@kvack.org, ngupta@vflare.org, linux-btrfs@vger.kernel.org, Josef Bacik , Dan Rosenberg , Yan Zheng , miaox@cn.fujitsu.com, Li Zefan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2827 Lines: 80 On Wed, Feb 16, 2011 at 10:27 AM, Dan Magenheimer wrote: >> -----Original Message----- >> From: Matt [mailto:jackdachef@gmail.com] >> Sent: Tuesday, February 15, 2011 5:12 PM >> To: Minchan Kim >> Cc: Dan Magenheimer; gregkh@suse.de; Chris Mason; linux- >> kernel@vger.kernel.org; linux-mm@kvack.org; ngupta@vflare.org; linux- >> btrfs@vger.kernel.org; Josef Bacik; Dan Rosenberg; Yan Zheng; >> miaox@cn.fujitsu.com; Li Zefan >> Subject: Re: [PATCH V2 0/3] drivers/staging: zcache: dynamic page >> cache/swap compression >> >> On Mon, Feb 14, 2011 at 4:35 AM, Minchan Kim >> > Just my guessing. I might be wrong. >> > >> > __cleancache_flush_inode calls cleancache_get_key with >> cleancache_filekey. >> > cleancache_file_key's size is just 6 * u32. >> > cleancache_get_key calls btrfs_encode_fh with the key. >> > but btrfs_encode_fh does typecasting the key to btrfs_fid which is >> > bigger size than cleancache_filekey's one so it should not access >> > fields beyond cleancache_get_key. >> > >> > I think some file systems use extend fid so in there, this problem >> can >> > happen. I don't know why we can't find it earlier. Maybe Dan and >> > others test it for a long time. >> > >> > Am I missing something? >> > >> > >> > >> > -- >> > Kind regards, >> > Minchan Kim >> > >> >> reposting Minchan's message for reference to the btrfs mailing list >> while also adding >> >> Li Zefan, Miao Xie, Yan Zheng, Dan Rosenberg and Josef Bacik to CC >> >> Regards >> >> Matt > > Hi Matt and Minchan -- > > (BTRFS EXPERTS SEE *** BELOW) > > I definitely see a bug in cleancache_get_key in the monolithic > zcache+cleancache+frontswap patch I posted on oss.oracle.com > that is corrected in linux-next but I don't see how it could > get provoked by btrfs. > > The bug is that, in cleancache_get_key, the return value of fhfn should > be checked against 255.  If the return value is 255, cleancache_get_key > should return -1.  This should disable cleancache for any filesystem > where KEY_MAX is too large. > > But cleancache_get_key always calls fhfn with connectable == 0 and > CLEANCACHE_KEY_MAX==6 should be greater than BTRFS_FID_SIZE_CONNECTABLE > (which I think should be 5?).  And the elements written into the > typecast btrfs_fid should be only writing the first 5 32-bit words. BTRFS_FID_SIZE_NON_CONNECTALBE is 5, not BTRFS_FID_SIZE_CONNECTABLE. Anyway, you passed connectable with 0 so it should be only writing the first 5 32-bit words as you said. That's one I missed. ;-) Thanks. -- Kind regards, Minchan Kim -- 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/