linux-kernel - Re: [PATCH 2/2] xfs: stop using kmalloc in xfs_buf_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070307123824.GA3996@lst.de>
Date:	Wed, 7 Mar 2007 13:38:24 +0100
From:	Christoph Hellwig <hch@....de>
To:	Shailendra Tripathi <stripathi@...mi.com>
Cc:	Christoph Hellwig <hch@....de>, xfs@....sgi.com,
	ecashin@...aid.com, akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] xfs: stop using kmalloc in xfs_buf_get_noaddr

On Wed, Mar 07, 2007 at 05:44:24PM +0530, Shailendra Tripathi wrote:
> Hi Christoph,
> 	     Did you do some testing for recovery when end of the physical 
> 	     log is seen ?

I ran xfsqa over it, which should catch this case.

> 	     When you will be dealing with striped ICLOG buffers or big 
> 	     sized ICLOGs, header size might range from 512 to 2k. Also, this header 
> might be split into 2 parts at the end of physical log. Then, you don't 
> have page size buffer. Please verify that XFS_BUF_SETP_PTRs work correctly 
> for those cases.
> 	 Same thing is true when data section is split around physical log. 
> 	 You can get one part which is not PAGE sized. 	

I should have made my wording more clear, we always do PAGE_SIZE +
buffer allocations.  After XFS_BUF_SETP_PTR the actually used buffer
might be smaller.  I tested XFS_BUF_SETP_PTR manually with
artifical test code aswell, and made sure it still works.
Long term I have a plan to replace XFS_BUF_SETP_PTR with better
schemes, but that's irrelevant for this patch.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/