Re: [PATCH 00/11] staging: gasket: fixes

On Sun, Oct 14, 2018 at 09:59:16PM -0700, Todd Poynor wrote: > From: Todd Poynor > > Various fixes for gasket/apex drivers. I still can't find any explanation in the staging tree or in your comments what gasket even is. ___ devel mailing list de...@lin

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

FYI, I've moved it off for-next and into its own dma-ranges branch for now until we sort out the regressions. I still hope to bring it back soon. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

On Mon, Sep 07, 2020 at 05:18:59PM +0200, Nicolas Saenz Julienne wrote: > Hi Christoph, a small fix to your fixes: Thanks, folded into the patch on the dma-ranges branch. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverpr

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

On Mon, Sep 07, 2020 at 01:40:46PM -0400, Jim Quinlan wrote: > Thanks for looking into this. The concern I have with your solution > is that returning an arbitrarily large offset might overlap with an > improbable but valid usage. AFAIK there is nothing that disallows > mapping a device to anywhe

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

On Mon, Sep 07, 2020 at 08:19:43PM +0200, Nicolas Saenz Julienne wrote: > Indeed, that's why I wasn't all that happy with my solution. > > As an alternative, how about returning '-dev->bus_dma_limit' instead of 0? > It's > always 0 for the devices without bus_dma_regions, and, I think, an always

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

FYI, this is what I'd do relative to the patch on the dma-ranges branch. In fact realizing this makes me want to refactor things a bit so that the new code can entirely live in the dma-direct code, but please test this first: diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/as

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

On Tue, Sep 08, 2020 at 09:29:35AM +0200, Christoph Hellwig wrote: > FYI, this is what I'd do relative to the patch on the dma-ranges > branch. In fact realizing this makes me want to refactor things a bit > so that the new code can entirely live in the dma-direct code, but plea

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

And because I like replying to myself so much, here is a link to the version with the arm cleanup patch applied. Unlike the previous two attempts this has at least survived very basic sanity testing: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-ranges.2 Note that we'll sti

Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips

On Tue, Sep 08, 2020 at 11:42:26AM +0100, Lorenzo Pieralisi wrote: > > Maybe we can parallelize the PCIe driver review while the DMA changes > > are being worked on in Christoph's branch. Lorenzo, are you fine with > > the PCIe changes proper? > > I will have a look - the main contentious point wa

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

On Tue, Sep 08, 2020 at 01:20:56PM +0200, Nicolas Saenz Julienne wrote: > On Tue, 2020-09-08 at 11:43 +0200, Christoph Hellwig wrote: > > And because I like replying to myself so much, here is a link to the > > version with the arm cleanup patch applied. Unlike the previous two &g

Re: [PATCH RFT/RFC 06/49] staging: media: zoran: unsplit lines

On Mon, Sep 21, 2020 at 10:19:41AM +, Corentin Labbe wrote: > This patch un-split some lines. > Signed-off-by: Corentin Labbe Just don't do this. This is a purious change going over 80 chars for absolutely no reason, and you'd still need a very good reason for that. _

Re: [PATCH RFT/RFC 24/49] staging: media: zoran: Use DMA coherent for stat_com

On Mon, Sep 21, 2020 at 10:19:59AM +, Corentin Labbe wrote: > Instead of using a fragile virt_to_bus, let's use proper DMA coherent > for the stat_com entry. > > Signed-off-by: Corentin Labbe > --- > drivers/staging/media/zoran/zoran.h| 2 ++ > drivers/staging/media/zoran/zoran_card

Re: [PATCH RFT/RFC 01/49] staging: media: Revert "media: zoran: remove deprecated driver"

> + fh->buffers.buffer[i].v4l.fbuffer = mem; > + fh->buffers.buffer[i].v4l.fbuffer_phys = virt_to_phys(mem); > + fh->buffers.buffer[i].v4l.fbuffer_bus = virt_to_bus(mem); > + for (off = 0; off < fh->buffers.buffer_size; > + off += PAG

Re: [PATCH] media: atomisp: stop compiling compat_ioctl32 code

On Wed, Oct 07, 2020 at 04:16:39PM +0200, Arnd Bergmann wrote: > Alternatively, the entire file could just be removed, since anyone > willing to restore the functionality can equally well just look up > the contents in the git history if needed. I suspect that is the right thing. Note that given

Re: [PATCH RFC PKS/PMEM 24/58] fs/freevxfs: Utilize new kmap_thread()

> - kaddr = kmap(pp); > + kaddr = kmap_thread(pp); > memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE); > - kunmap(pp); > + kunmap_thread(pp); You only Cced me on this particular patch, which means I have absolutely no idea what kmap_thread and kunmap_thread actually

use of dma_direct_set_offset in (allwinner) drivers

Hi all, Linux 5.10-rc1 switched from having a single dma offset in struct device to a set of DMA ranges, and introduced a new helper to set them, dma_direct_set_offset. This in fact surfaced that a bunch of drivers that violate our layering and set the offset from drivers, which meant we had to r

Re: use of dma_direct_set_offset in (allwinner) drivers

On Wed, Nov 04, 2020 at 10:15:49AM +, Robin Murphy wrote: > How about having something in the platform code that keys off the top-level > SoC compatible and uses a bus notifier to create offsets for the relevant > devices if an MBUS description is missing? At least that way the workaround >

Re: [PATCH 0/7] sunxi: Remove the calls to dma_direct_set_offset

Thanks, this looks good to me: Reviewed-by: Christoph Hellwig Can you include this patch at the end of your series to that it gets picked up with the other patches? --- >From 5963f88d365367fe74d477b8420d34562d684406 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Fri, 6 Nov 2020 17

Re: [PATCH 0/7] sunxi: Remove the calls to dma_direct_set_offset

On Mon, Nov 09, 2020 at 10:43:03AM +0100, Maxime Ripard wrote: > Hi Christoph, Chen-Yu, Hans, > > On Fri, Nov 06, 2020 at 05:07:37PM +0100, Christoph Hellwig wrote: > > Thanks, > > > > this looks good to me: > > > > Reviewed-by: Christoph Hellwig > &g

Re: [PATCH 0/7] sunxi: Remove the calls to dma_direct_set_offset

On Mon, Nov 09, 2020 at 10:43:03AM +0100, Maxime Ripard wrote: > Hi Christoph, Chen-Yu, Hans, > > On Fri, Nov 06, 2020 at 05:07:37PM +0100, Christoph Hellwig wrote: > > Thanks, > > > > this looks good to me: > > > > Reviewed-by: Christoph Hellwig > &g

Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap

On Wed, Jan 16, 2019 at 10:17:23AM -0600, Andrew F. Davis wrote: > I wouldn't go as far as to remove them just yet.. Liam seems pretty > adamant that they have valid uses. I'm just not sure performance is one > of them, maybe in the case of software locks between devices or > something where there

Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap

On Fri, Jan 18, 2019 at 12:31:34PM -0800, Laura Abbott wrote: > I thought about doing that, the problem is it becomes an ABI break for > existing users which I really didn't want to do again. If it > ends up being the last thing we do before moving out of staging, > I'd consider doing it. This is

Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes

On Fri, Jan 18, 2019 at 10:37:46AM -0800, Liam Mark wrote: > Add support for configuring dma mapping attributes when mapping > and unmapping memory through dma_buf_map_attachment and > dma_buf_unmap_attachment. > > Signed-off-by: Liam Mark And who is going to decide which ones to pass? And who

Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes

On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote: > > And who is going to decide which ones to pass? And who documents > > which ones are safe? > > > > I'd much rather have explicit, well documented dma-buf flags that > > might get translated to the DMA API flags, which are not error

Re: [PATCH v2] vmbus: Switch to use new generic UUID API

Looks good, Reviewed-by: Christoph Hellwig ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes

On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote: > The main use case is for allowing clients to pass in > DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance > which happens in dma_buf_map_attachment and dma_buf_unmap_attachment. In > ION the buffers aren't usually ac

Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes

On Mon, Jan 21, 2019 at 12:20:42PM -0800, Liam Mark wrote: > I have left this to clients, but if they own the buffer they can have the > knowledge as to whether CPU access is needed in that use case (example for > post-processing). That is an API design which the user is more likely to get wrong

Re: [Linaro-mm-sig] [PATCH 2/4] staging: android: ion: Restrict cache maintenance to dma mapped memory

The CPU may only access DMA mapped memory if ownership has been transferred back to the CPU using dma_sync_{single,sg}_to_cpu, and then before the device can access it again ownership needs to be transferred back to the device using dma_sync_{single,sg}_to_device. > I've run some testing, and this

Re: [PATCH v3 0/7] binder: eliminate use of vmalloc space for binder buffers

On Fri, Feb 08, 2019 at 10:35:13AM -0800, Todd Kjos wrote: > Binder buffers have always been mapped into kernel space > via map_kernel_range_noflush() to allow the binder driver > to modify the buffer before posting to userspace for > processing. > > In recent Android releases, the number of long-

Re: [RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it

On Tue, Feb 19, 2019 at 09:30:33PM -0800, ira.we...@intel.com wrote: > From: Ira Weiny > > Resending these as I had only 1 minor comment which I believe we have covered > in this series. I was anticipating these going through the mm tree as they > depend on a cleanup patch there and the IB chang

Re: [PATCH] erofs: move erofs out of staging

On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote: > Note that of the mainstream file systems, ext4 and xfs don't guarantee > that it's safe to blindly take maliciously provided file systems, such > as those provided by a untrusted container, and mount it on a file > system without p

Re: [PATCH] erofs: move erofs out of staging

On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote: > Ted's observation was about maliciously-crafted filesystems, though, so > integrity-only features such as metadata checksums are irrelevant. Also the > filesystem version is irrelevant; anything accepted by the kernel code (even > if

Re: [PATCH] erofs: move erofs out of staging

On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote: > Not sure what you're even disagreeing with, as I *do* expect new filesystems > to > be held to a high standard, and to be written with the assumption that the > on-disk data may be corrupted or malicious. We just can't expect the bar

Re: [PATCH] staging: exfat: add exfat filesystem code to staging

Can we please just review the damn thing and get it into the proper tree? That whole concept of staging file systems just has been one fricking disaster, including Greg just moving not fully reviewed ones over like erofs just because he feels like it. I'm getting sick and tired of this scheme. __

Re: [PATCH] staging: exfat: add exfat filesystem code to staging

On Thu, Aug 29, 2019 at 08:39:55AM +0200, Greg Kroah-Hartman wrote: > On Wed, Aug 28, 2019 at 11:23:40PM -0700, Christoph Hellwig wrote: > > Can we please just review the damn thing and get it into the proper > > tree? That whole concept of staging file systems just has been o

Re: [PATCH] staging: exfat: add exfat filesystem code to staging

On Thu, Aug 29, 2019 at 04:24:09PM +0800, Gao Xiang wrote: > It seems I misunderstood your idea, sorry about that... EROFS > properly uses vfs interfaces (e.g. we also considered RCU symlink > lookup path at the very beginning of our design as Al said [1], > except for mount interface as Al mention

Re: [PATCH v6 01/24] erofs: add on-disk layout

> --- /dev/null > +++ b/fs/erofs/erofs_fs.h > @@ -0,0 +1,316 @@ > +/* SPDX-License-Identifier: GPL-2.0-only OR Apache-2.0 */ > +/* > + * linux/fs/erofs/erofs_fs.h Please remove the pointless file names in the comment headers. > +struct erofs_super_block { > +/* 0 */__le32 magic; /* in

Re: [PATCH v6 03/24] erofs: add super block operations

On Fri, Aug 02, 2019 at 08:53:26PM +0800, Gao Xiang wrote: > +static int __init erofs_init_inode_cache(void) > +{ > + erofs_inode_cachep = kmem_cache_create("erofs_inode", > +sizeof(struct erofs_vnode), 0, > +

Re: [PATCH v6 04/24] erofs: add raw address_space operations

The actual address_space operations seem to largely duplicate the iomap versions. Please use those instead. Also I don't think any new file system should write up ->bmap these days. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.li

Re: [PATCH v6 05/24] erofs: add inode operations

On Fri, Aug 02, 2019 at 08:53:28PM +0800, Gao Xiang wrote: > This adds core functions to get, read an inode. > It adds statx support as well. > > Signed-off-by: Gao Xiang > --- > fs/erofs/inode.c | 291 +++ > 1 file changed, 291 insertions(+) > create

Re: [PATCH v6 06/24] erofs: support special inode

On Fri, Aug 02, 2019 at 08:53:29PM +0800, Gao Xiang wrote: > This patch adds to support special inode, such as > block dev, char, socket, pipe inode. > > Signed-off-by: Gao Xiang > --- > fs/erofs/inode.c | 27 +-- > 1 file changed, 25 insertions(+), 2 deletions(-) > > di

Re: [PATCH v6 08/24] erofs: add namei functions

On Fri, Aug 02, 2019 at 08:53:31PM +0800, Gao Xiang wrote: > +struct erofs_qstr { > + const unsigned char *name; > + const unsigned char *end; > +}; Maybe erofs_name? The q in qstr stands for quick, because of the existing hash and len, which this doesn't really provide. Also I don't rea

Re: [PATCH v6 01/24] erofs: add on-disk layout

On Thu, Aug 29, 2019 at 06:32:53PM +0800, Gao Xiang wrote: > I can fix it up as you like but I still cannot get > what is critical issues here. The problem is that the whole codebase is way substandard quality, looking a lot like Linux code from 20 years ago. Yes, we already have plenty of code o

Re: [PATCH] staging: exfat: add exfat filesystem code to staging

On Thu, Aug 29, 2019 at 11:50:19AM +0200, Greg Kroah-Hartman wrote: > I did try just that, a few years ago, and gave up on it. I don't think > it can be added to the existing vfat code base but I am willing to be > proven wrong. And what exactly was the problem? > > Now that we have the specs,

Re: [PATCH] staging: exfat: add exfat filesystem code to staging

On Thu, Aug 29, 2019 at 01:18:10PM +0200, Greg Kroah-Hartman wrote: > Hey, that's not nice, erofs isn't a POS. It could always use more > review, which the developers asked for numerous times. > > There's nothing different from a filesystem compared to a driver. If > its stand-alone, and touches

Re: [PATCH] staging: exfat: add exfat filesystem code to staging

On Thu, Aug 29, 2019 at 10:56:31PM +0200, Pali Rohár wrote: > In my opinion, proper way should be to implement exFAT support into > existing fs/fat/ code instead of replacing whole vfat/msdosfs by this > new (now staging) fat implementation. > > In linux kernel we really do not need two different

Re: [PATCH v2 2/7] erofs: some marcos are much more readable as a function

On Thu, Aug 29, 2019 at 08:16:27PM -0700, Joe Perches wrote: > > - sizeof(__u32) * ((__count) - 1); }) > > +static inline unsigned int erofs_xattr_ibody_size(__le16 d_icount) > > +{ > > + unsigned int icount = le16_to_cpu(d_icount); > > + > > + if (!icount) > > + return 0; >

Re: [PATCH v3 6/7] erofs: remove all likely/unlikely annotations

On Fri, Aug 30, 2019 at 11:36:42AM +0800, Gao Xiang wrote: > As Dan Carpenter suggested [1], I have to remove > all erofs likely/unlikely annotations. Do you have to remove all of them, or just those where you don't have a particularly good reason why you think in this particular case they might a

Re: [PATCH v3 7/7] erofs: redundant assignment in __erofs_get_meta_page()

> - err = bio_add_page(bio, page, PAGE_SIZE, 0); > - if (err != PAGE_SIZE) { > + if (bio_add_page(bio, page, PAGE_SIZE, 0) != PAGE_SIZE) { > err = -EFAULT; > goto err_out; > } This patch looks like an imp

Re: [PATCH v8 20/24] erofs: introduce generic decompression backend

On Thu, Aug 15, 2019 at 12:41:51PM +0800, Gao Xiang wrote: > +static bool use_vmap; > +module_param(use_vmap, bool, 0444); > +MODULE_PARM_DESC(use_vmap, "Use vmap() instead of vm_map_ram() (default 0)"); And how would anyone know which to pick? ___ deve

Re: [PATCH v6 03/24] erofs: add super block operations

On Thu, Aug 29, 2019 at 06:50:48PM +0800, Gao Xiang wrote: > > Please use an erofs_ prefix for all your functions. > > It is already a static function, I have no idea what is wrong here. Which part of all wasn't clear? Have you looked at the prefixes for most functions in the various other big f

Re: [PATCH v6 04/24] erofs: add raw address_space operations

On Thu, Aug 29, 2019 at 07:46:11PM +0800, Gao Xiang wrote: > Hi Christoph, > > On Thu, Aug 29, 2019 at 03:17:21AM -0700, Christoph Hellwig wrote: > > The actual address_space operations seem to largely duplicate > > the iomap versions. Please use those instead. Also I do

Re: [PATCH v6 05/24] erofs: add inode operations

On Thu, Aug 29, 2019 at 07:59:22PM +0800, Gao Xiang wrote: > On Thu, Aug 29, 2019 at 03:24:26AM -0700, Christoph Hellwig wrote: > > [] > > > > > > + > > > + /* fill last page if inline data is available */ > > > + err = fill_inline_d

Re: [PATCH v8 20/24] erofs: introduce generic decompression backend

On Sat, Aug 31, 2019 at 12:52:17AM +0800, Gao Xiang wrote: > Hi Christoph, > > On Fri, Aug 30, 2019 at 09:35:34AM -0700, Christoph Hellwig wrote: > > On Thu, Aug 15, 2019 at 12:41:51PM +0800, Gao Xiang wrote: > > > +static bool use_vmap; > > > +

Re: [PATCH 01/21] erofs: remove all the byte offset comments

On Sun, Sep 01, 2019 at 01:51:10PM +0800, Gao Xiang wrote: > From: Gao Xiang > > As Christoph suggested [1], "Please remove all the byte offset comments. > that is something that can easily be checked with gdb or pahole." Looks good. If you want to keep them after the field names as someone poi

Re: [PATCH 02/21] erofs: on-disk format should have explicitly assigned numbers

On Sun, Sep 01, 2019 at 01:51:11PM +0800, Gao Xiang wrote: > enum { > - EROFS_INODE_FLAT_PLAIN, > - EROFS_INODE_FLAT_COMPRESSION_LEGACY, > - EROFS_INODE_FLAT_INLINE, > - EROFS_INODE_FLAT_COMPRESSION, > + EROFS_INODE_FLAT_PLAIN = 0, > + EROFS_INODE_FLAT_COMP

Re: [PATCH 03/21] erofs: some macros are much more readable as a function

This looks much better now. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 04/21] erofs: kill __packed for on-disk structures

On Sun, Sep 01, 2019 at 01:51:13PM +0800, Gao Xiang wrote: > From: Gao Xiang > > As Christoph suggested "Please don't add __packed" [1], > remove all __packed except struct erofs_dirent here. > > Note that all on-disk fields except struct erofs_dirent > (12 bytes with a 8-byte nid) in EROFS are

Re: [PATCH 05/21] erofs: update erofs_inode_is_data_compressed helper

On Sun, Sep 01, 2019 at 01:51:14PM +0800, Gao Xiang wrote: > From: Gao Xiang > > As Christoph said, "This looks like a really obsfucated > way to write: > return datamode == EROFS_INODE_FLAT_COMPRESSION || > datamode == EROFS_INODE_FLAT_COMPRESSION_LEGACY; " > > Although I ha

Re: [PATCH 06/21] erofs: kill erofs_{init,exit}_inode_cache

On Sun, Sep 01, 2019 at 01:51:15PM +0800, Gao Xiang wrote: > From: Gao Xiang > > As Christoph said [1] "having this function seems > entirely pointless", let's kill those. Looks much better. ___ devel mailing list de...@linuxdriverproject.org http://dr

Re: [PATCH 07/21] erofs: use erofs_inode naming

> { > - struct erofs_vnode *vi = ptr; > - > - inode_init_once(&vi->vfs_inode); > + inode_init_once(&((struct erofs_inode *)ptr)->vfs_inode); Why doesn't this use EROFS_I? This looks a little odd. ___ devel mailing list de...@linuxdriverproj

Re: [PATCH 09/21] erofs: update erofs symlink stuffs

Thanks, this looks much better. > fs/erofs/inode.c| 35 ++- > fs/erofs/internal.h | 10 -- > fs/erofs/super.c| 5 ++--- > 3 files changed, 12 insertions(+), 38 deletions(-) And that diffstat ain't bad either. __

Re: [PATCH 10/21] erofs: kill is_inode_layout_compression()

Thanks, this looks much better. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 11/21] erofs: use dsb instead of layout for ondisk super_block

> + dsb = (struct erofs_super_block *)((u8 *)bh->b_data + > +EROFS_SUPER_OFFSET); Not new in this patch, but that u8 cast shouldn't be needed. ___ devel mailing list de...@linuxdriverproject.org http://driverde

Re: [PATCH 12/21] erofs: kill verbose debug info in erofs_fill_super

On Sun, Sep 01, 2019 at 01:51:21PM +0800, Gao Xiang wrote: > From: Gao Xiang > > As Christoph said [1], "That is some very verbose > debug info. We usually don't add that and let > people trace the function instead. " Note that this applies to most of the infoln users as far as I can tell. And

Re: [PATCH 13/21] erofs: simplify erofs_grab_bio() since bio_alloc() never fail

On Sun, Sep 01, 2019 at 01:51:22PM +0800, Gao Xiang wrote: > From: Gao Xiang > > As Christoph pointed out [1], "erofs_grab_bio tries to > handle a bio_alloc failure, except that the function will > not actually fail due the mempool backing it." > > Sorry about useless code, fix it now. A lot of

Re: [PATCH 14/21] erofs: kill prio and nofail of erofs_get_meta_page()

Thanks, much better. I'm still hoping REQ_PRIO in this current form will go entirely away soon as well. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 16/21] erofs: kill magic underscores

> > - vi->datamode = __inode_data_mapping(advise); > + vi->datamode = erofs_inode_data_mapping(advise); > > if (vi->datamode >= EROFS_INODE_LAYOUT_MAX) { While you are at it can we aim for some naming consistency here? The inode member is called is called datamode, the helper is

Re: [PATCH 17/21] erofs: use a switch statement when dealing with the file modes

Thanks, this looks much nicer. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 18/21] erofs: add "erofs_" prefix for common and short functions

Thanks. I don't have a tree with all these applies, but please make sure this covers at least all inlines in headers and all methods wired up to operation structures. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject

Re: [PATCH 19/21] erofs: kill all erofs specific fault injection

On Sun, Sep 01, 2019 at 01:51:28PM +0800, Gao Xiang wrote: > From: Gao Xiang > > As Christoph suggested [1], "Please just use plain kmalloc > everywhere and let the normal kernel error injection code > take care of injeting any errors." Thanks. ___ dev

Re: [PATCH 21/21] erofs: save one level of indentation

On Sun, Sep 01, 2019 at 01:51:30PM +0800, Gao Xiang wrote: > From: Gao Xiang > > As Christoph said [1], ".. and save one > level of indentation." Thanks. Just a little cleanup, but cumulated things like this really help readability. ___ devel mailing

Re: [PATCH 20/21] erofs: kill use_vmap module parameter

> @@ -224,9 +220,6 @@ static void *erofs_vmap(struct page **pages, unsigned int > count) > { > int i = 0; > > - if (use_vmap) > - return vmap(pages, count, VM_MAP, PAGE_KERNEL); > - > while (1) { > void *addr = vm_map_ram(pages, count, -1, PAGE_KERNEL);

Re: [PATCH v6 01/24] erofs: add on-disk layout

On Sun, Sep 01, 2019 at 03:54:11PM +0800, Gao Xiang wrote: > It could be better has a name though, because 1) erofs.mkfs uses this > definition explicitly, and we keep this on-disk definition erofs_fs.h > file up with erofs-utils. > > 2) For kernel use, first we have, >datamode < EROFS_INODE_L

Re: [PATCH 00/21] erofs: patchset addressing Christoph's comments

On Sun, Sep 01, 2019 at 01:51:09PM +0800, Gao Xiang wrote: > Hi, > > This patchset is based on the following patch by Pratik Shinde, > https://lore.kernel.org/linux-erofs/20190830095615.10995-1-pratikshinde...@gmail.com/ > > All patches addressing Christoph's comments on v6, which are trivial, >

Re: [PATCH 07/21] erofs: use erofs_inode naming

On Mon, Sep 02, 2019 at 08:13:06PM +0800, Gao Xiang wrote: > Hi Christoph, > > On Mon, Sep 02, 2019 at 05:10:21AM -0700, Christoph Hellwig wrote: > > > { > > > - struct erofs_vnode *vi = ptr; > > > - > > > - inode_init_once(&vi->vfs_inode);

Re: [PATCH v6 03/24] erofs: add super block operations

On Sun, Sep 01, 2019 at 04:54:55PM +0800, Gao Xiang wrote: > No modification at this... (some comments already right here...) > 20 /* 128-byte erofs on-disk super block */ > 21 struct erofs_super_block { > ... > 24 __le32 features;/* (aka. feature_compat) */ > ... > 38

Re: [PATCH v6 05/24] erofs: add inode operations

On Sun, Sep 01, 2019 at 05:34:00PM +0800, Gao Xiang wrote: > > > + return iget5_locked(sb, hashval, erofs_ilookup_test_actor, > > > + erofs_iget_set_actor, &nid); > > > +#endif > > > > Just use the slightly more complicated 32-bit version everywhere so that > > you have a single actually t

Re: [PATCH 16/21] erofs: kill magic underscores

On Mon, Sep 02, 2019 at 08:39:37PM +0800, Gao Xiang wrote: > > > > > + if (erofs_inode_version(advise) == EROFS_INODE_LAYOUT_V2) { > > > > I still need to wade through the old thread - but didn't you say this > > wasn't really a new vs old version but a compat vs full inode? Maybe > > the names

Re: [PATCH v8 11/24] erofs: introduce xattr & posixacl support

> +config EROFS_FS_XATTR > + bool "EROFS extended attributes" > + depends on EROFS_FS > + default y > + help > + Extended attributes are name:value pairs associated with inodes by > + the kernel or by users (see the attr(5) manual page, or visit > +

Re: [PATCH v8 11/24] erofs: introduce xattr & posixacl support

On Mon, Sep 02, 2019 at 04:20:37PM +0200, David Sterba wrote: > Oh right, I think the reasons are historical and that we can remove the > options nowadays. From the compatibility POV this should be safe, with > ACLs compiled out, no tool would use them, and no harm done when the > code is present b

Re: [PATCH v6 03/24] erofs: add super block operations

On Mon, Sep 02, 2019 at 10:43:04PM +0800, Gao Xiang wrote: > Hi Christoph, > > > ... > > > 24 __le32 features;/* (aka. feature_compat) */ > > > ... > > > 38 __le32 requirements;/* (aka. feature_incompat) */ > > > ... > > > 41 }; > > > > This is only cosmetic, why not

Re: [PATCH 00/21] erofs: patchset addressing Christoph's comments

On Mon, Sep 02, 2019 at 10:24:52PM +0800, Gao Xiang wrote: > > code quality stuff. We're not addressing the issues with large amounts > > of functionality duplicating VFS helpers. > > You means killing erofs_get_meta_page or avoid erofs_read_raw_page? > > - For killing erofs_get_meta_page, here

Re: [PATCH 00/21] erofs: patchset addressing Christoph's comments

On Mon, Sep 02, 2019 at 11:50:38PM +0800, Gao Xiang wrote: > > > You means killing erofs_get_meta_page or avoid erofs_read_raw_page? > > > > > > - For killing erofs_get_meta_page, here is the current > > > erofs_get_meta_page: > > > > > I think it is simple enough. read_cache_page need write a

Re: [PATCH 00/21] erofs: patchset addressing Christoph's comments

On Tue, Sep 03, 2019 at 04:17:49PM +0800, Gao Xiang wrote: > I implement a prelimitary version, but I have no idea it is a really > cleanup for now. The fact that this has to guess the block device address_space implementation is indeed pretty ugly. I'd much prefer to just use read_cache_page_gfp

Re: [PATCH v2 00/25] erofs: patchset addressing Christoph's comments

On Wed, Sep 04, 2019 at 10:08:47AM +0800, Gao Xiang wrote: > Hi, > > This patchset is based on the following patch by Pratik Shinde, > https://lore.kernel.org/linux-erofs/20190830095615.10995-1-pratikshinde...@gmail.com/ > > All patches addressing Christoph's comments on v6, which are trivial, >

Re: [PATCH v2 00/25] erofs: patchset addressing Christoph's comments

On Thu, Sep 05, 2019 at 09:03:54AM +0800, Gao Xiang wrote: > Could we submit these patches if these patches look good... > Since I'd like to work based on these patches, it makes a difference > to the current code though... Yes, I'm fine with these patches.

Re: [GIT PULL] Staging/IIO driver patches for 5.4-rc1

Just as a note of record: I don't think either file system move is a good idea. erofs still needs a lot of work, especially in interacting with the mm code like abusing page->mapping. exfat is just a random old code drop from Samsung hastily picked up, and also duplicating the fat16/32 functiona

Re: [GIT PULL] Staging/IIO driver patches for 5.4-rc1

On Wed, Sep 18, 2019 at 08:50:10PM +0200, Greg KH wrote: > > exfat is just a random old code drop from Samsung hastily picked up, > > and also duplicating the fat16/32 functionality, and without > > consultation of the developes of that who are trying to work through > > their process of contributi

Re: [PATCH v17 0/1] staging: Add VirtualBox guest shared folder (vboxsf) support

it up. > > Previous versions of this patch have been reviewed by Al Viro, David Howells > and Christoph Hellwig (all in the Cc) and I believe that the current > version addresses all their review remarks. Please just send it to Linus directly. This is the equivalent of consumer h

Re: [PATCH 10/10] errno.h: Provide EFSCORRUPTED for everybody

On Sun, Nov 03, 2019 at 08:45:06PM -0500, Valdis Kletnieks wrote: > There's currently 6 filesystems that have the same #define. Move it > into errno.h so it's defined in just one place. And 4 out of 6 also define EFSBADCRC, so please lift that as well. _

Re: [GIT PULL] IIO fixes / Staging driver for 5.4-rc7

On Sun, Nov 10, 2019 at 04:43:03PM +0100, Greg KH wrote: > The staging driver addition is the vboxsf filesystem, which is the > VirtualBox guest shared folder code. Hans has been trying to get > filesystem reviewers to review the code for many months now, and > Christoph finally said to just merge

Re: [GIT PULL] Staging driver patches for 3.19-rc1

On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote: > I don't understand this kind of logic. > a) Binder is considered a piece of shite. > b) Google is working on a (hopefully sane) replacement. > > Why moving it out of staging then? What is the benefit? There is none, and Greg di

Re: [GIT PULL] Staging driver patches for 3.19-rc1

On Mon, Dec 15, 2014 at 10:56:38AM -0800, Greg KH wrote: > Ok, that was a bit snotty on my part, I apologize. > > But really, this is self-contained, doesn't touch any core > infrastructure, and is really just like any other driver for hardware > that people don't use. It shouldn't affect anythin

[PATCH] SCSI:STORVSC Use SCSI layer to allocate memory for per-command device request data

data. Reviewed-by: Long Li Signed-off-by: Christoph Hellwig --- drivers/scsi/storvsc_drv.c | 119 +++-- 1 file changed, 8 insertions(+), 111 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 4cff0dd..14ee98e 100644

Re: [PATCH 0/4] Drivers: scsi: storvsc: Fix miscellaneous issues

Thanks, applied to scsi-for-3.20. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: fix unexpected out-of-bound data access

> +++ b/drivers/staging/erofs/data.c > @@ -304,7 +304,7 @@ static inline struct bio *erofs_read_raw_page(struct bio > *bio, > *last_block = current_block; > > /* shift in advance in case of it followed by too many gaps */ > - if (unlikely(bio->bi_vcnt >= bio->bi_max_vecs)) { > +

Re: [PATCH] staging: erofs: fix unexpected out-of-bound data access

On Fri, Apr 12, 2019 at 08:06:33AM -0700, Christoph Hellwig wrote: > > +++ b/drivers/staging/erofs/data.c > > @@ -304,7 +304,7 @@ static inline struct bio *erofs_read_raw_page(struct > > bio *bio, > > *last_block = current_block; > > > > /* shift in a

[PATCH 01/16] media: videobuf-dma-contig: use dma_mmap_coherent

management inside the DMA allocator is hidden from the callers. Fixes: a8f3c203e19b ("[media] videobuf-dma-contig: add cache support") Signed-off-by: Christoph Hellwig --- drivers/media/v4l2-core/videobuf-dma-contig.c | 23 +++ 1 file changed, 8 insertions(+), 15

[PATCH 02/16] drm/ati_pcigart: stop using drm_pci_alloc

Remove usage of the legacy drm PCI DMA wrappers, and with that the incorrect usage cocktail of __GFP_COMP, virt_to_page on DMA allocation and SetPageReserved. Signed-off-by: Christoph Hellwig --- drivers/gpu/drm/ati_pcigart.c | 27 +++ include/drm/ati_pcigart.h | 5

  1   2   3   4   5   >