Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752306AbbKKQ4z (ORCPT ); Wed, 11 Nov 2015 11:56:55 -0500 Received: from mail-lb0-f177.google.com ([209.85.217.177]:34945 "EHLO mail-lb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751861AbbKKQ4x (ORCPT ); Wed, 11 Nov 2015 11:56:53 -0500 MIME-Version: 1.0 In-Reply-To: <20151111163630.GN22011@ZenIV.linux.org.uk> References: <20151111025647.GG22011@ZenIV.linux.org.uk> <20151111033007.GI22011@ZenIV.linux.org.uk> <20151111074330.GK22011@ZenIV.linux.org.uk> <20151111191636.17e4ac62@canb.auug.org.au> <20151111101948.GL22011@ZenIV.linux.org.uk> <20151111212850.63fcb152@canb.auug.org.au> <20151111163630.GN22011@ZenIV.linux.org.uk> Date: Wed, 11 Nov 2015 11:56:51 -0500 Message-ID: Subject: Re: fs: out of bounds on stack in iov_iter_advance From: Mike Marshall To: Al Viro Cc: Stephen Rothwell , Linus Torvalds , Sasha Levin , Andrey Ryabinin , Matthew Wilcox , Chuck Ebbert , linux-fsdevel , LKML , Jens Axboe , Dan Williams Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4594 Lines: 95 > BTW, could you put the current state of the docs someplace public? The documentation will eventually end up in Documentation/filesystems/orangefs.txt. This part about the creation of the shared memory between userspace and the kernel module seems complete and accurate to me so far. This "bufmap" data structure is central to the protocol between userspace and the kernel module. This describes the creation of the bufmap, details on how it is used in exchanges is what I am working on now... ----------------------------------------------------------------------------------------------------------- Orangefs is a user space filesystem and an associated kernel module. We'll just refer to the user space part of Orangefs as "userspace" from here on out... The kernel module implements a pseudo device that userspace can read from and write to. Userspace can also manipulate the kernel module through the pseudo device with ioctl. At startup userspace allocates two page-size-aligned (posix_memalign) mlocked memory blocks, one is used for IO and one is used for readdir operations. The IO block is 41943040 bytes and the readdir block is 4194304 bytes. Each block contains logical chunks, and a pointer to each block is added to its own PVFS_dev_map_desc structure which also describes its total size, as well as the size and number of the logical chunks. A pointer to the IO block's PVFS_dev_map_desc structure is sent to a mapping routine in the kernel module with an ioctl. The structure is copied from user space to kernel space with copy_from_user and is used to initialize the kernel module's "bufmap" (struct pvfs2_bufmap), which then contains: * refcnt - a reference counter * desc_size - PVFS2_BUFMAP_DEFAULT_DESC_SIZE (4194304) the IO block's logical chunk size, which represents the filesystem's block size and is used for s_blocksize in super blocks. * desc_count - PVFS2_BUFMAP_DEFAULT_DESC_COUNT (10) the number of logical chunks in the IO block. * desc_shift - log2(desc_size), used for s_blocksize_bits in super blocks. * total_size - the total size of the IO block. * page_count - the number of 4096 byte pages in the IO block. * page_array - a pointer to page_count * (sizeof(struct page*)) bytes of kcalloced memory. This memory is used as an array of pointers to each of the pages in the IO block through a call to get_user_pages. * desc_array - a pointer to desc_count * (sizeof(struct pvfs_bufmap_desc)) bytes of kcalloced memory. This memory is further intialized: user_desc is the kernel's copy of the IO block's PVFS_dev_map_desc structure. user_desc->ptr points to the IO block. pages_per_desc = bufmap->desc_size / PAGE_SIZE offset = 0 bufmap->desc_array[0].page_array = &bufmap->page_array[offset] bufmap->desc_array[0].array_count = pages_per_desc = 1024 bufmap->desc_array[0].uaddr = (user_desc->ptr) + (0 * 1024 * 4096) offset += 1024 . . . bufmap->desc_array[9].page_array = &bufmap->page_array[offset] bufmap->desc_array[9].array_count = pages_per_desc = 1024 bufmap->desc_array[9].uaddr = (user_desc->ptr) + (9 * 1024 * 4096) offset += 1024 * buffer_index_array - a desc_count sized array of ints, used to indicate which of the IO block's chunks are available to use. * buffer_index_lock - a spinlock to protect buffer_index_array during update. * readdir_index_array - a five (PVFS2_READDIR_DEFAULT_DESC_COUNT) element int array used to indicate which of the readdir block's chunks are available to use. * readdir_index_lock - a spinlock to protect readdir_index_array during update. On Wed, Nov 11, 2015 at 11:36 AM, Al Viro wrote: > On Wed, Nov 11, 2015 at 11:25:17AM -0500, Mike Marshall wrote: >> I'm the Orangefs guy... >> >> If the orangefs warnings that people see because of what's in >> linux-next is annoying, I could focus on quieting them down... > > See the fixup just posted in this thread. > >> We've been focusing on code review and documentation ever >> since our last big exchange with Al and Linus... > > BTW, could you put the current state of the docs someplace public? -- 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/