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
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
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
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
>
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
> - 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
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
> + 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 +=
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 ++
>
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.
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 t
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
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
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
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
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
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
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
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
I've applied this to the dma-mapping tree.
I had to resolve a conflict in drivers/of/address.c with a recent
mainline commit. I also applied the minor tweaks Andy pointed out
plus a few more style changes. A real change is that I changed the
prototype for dma_copy_dma_range_map to require less
On Tue, Aug 25, 2020 at 08:52:29AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 25, 2020 at 07:47:29AM +0100, Christoph Hellwig wrote:
> > On Fri, Aug 21, 2020 at 06:27:04PM +0300, Tomer Samara wrote:
> > > Remove BUG/BUG_ON from androind/ion
> >
> > Please
On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
> Hi,
>
> On 8/24/2020 12:30 PM, Jim Quinlan wrote:
>>
>> Patchset Summary:
>>Enhance a PCIe host controller driver. Because of its unusual design
>>we are foced to change dev->dma_pfn_offset into a more general role
>>
On Fri, Aug 21, 2020 at 06:27:04PM +0300, Tomer Samara wrote:
> Remove BUG/BUG_ON from androind/ion
Please just remove ion. It has been rejected and we have developed
proper kernel subsystens to replace it. Don't waste your time on it.
___
devel
On Mon, Aug 17, 2020 at 11:27:25AM +0200, Mauro Carvalho Chehab wrote:
> I need to start from the original patch in order to preserve its
> authorship.
Nom you don't. We have plenty of example where people submit code
written by other, especially when it is significantly reworked,
> My plan is
On Mon, Aug 17, 2020 at 09:49:59AM +0200, Mauro Carvalho Chehab wrote:
> Add a driver for the Kirin 960/970 iommu.
>
> As on the past series, this starts from the original 4.9 driver from
> the 96boards tree:
>
> https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
>
> The remaining
You can't modify non-staging core code just for staging code.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> I started using devm_kcalloc() but at least two reviewers convinced me
> to just use kcalloc(). In addition, when I was using devm_kcalloc()
> it was awkward because 'dev' is not available to this function.
>
> It comes down to
A few tiny nitpicks:
The subject should have the dma-mapping prefix, this doesn't
really touch the device core.
> - rc = of_dma_get_range(np, _addr, , );
> + rc = of_dma_get_range(np, );
> + rc = PTR_ERR_OR_ZERO(map);
I don't think you need the PTR_ERR_OR_ZERO line here,
On Wed, Jul 15, 2020 at 10:35:11AM -0400, Jim Quinlan wrote:
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable
On Thu, Jul 09, 2020 at 09:27:06AM -0400, Jim Quinlan wrote:
> Hi Christoph,
>
> I'm sending all commits to since most of
> them are PCI related. I don't send all patches to
> linux-ker...@vger.kernel.org since I've read it is overused. The --cc
> list is generated by get_maintainer.pl.
>
>
I someone seem to get just this patch instead of the full series for
review again..
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
eting ion and watching if anyone notices. In case you're
> typing that patch, here's my:
>
> Acked-by: Daniel Vetter
As ion ha sbeen a major pain for various tree wide changes also from me:
Acked-by: Christoph Hellwig
___
dev
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
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.
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 equivalen
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
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
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.
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
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
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,
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
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
> +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
> +
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
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, );
> > > +#endif
> >
> > Just use the slightly more complicated 32-bit version everywhere so that
> > you have a single actually
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
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(>vfs_inode);
>
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,
>
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 <
> @@ -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,
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
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.
___
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
Thanks,
this looks much nicer.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>
> - 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
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
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
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.
> + 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
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.
Thanks,
this looks much better.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
> {
> - struct erofs_vnode *vi = ptr;
> -
> - inode_init_once(>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
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
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
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
This looks much better now.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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,
> +
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
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;
> > > +
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
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
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
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?
___
> - 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
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
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;
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
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
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,
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
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
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(-)
>
>
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(+)
>
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
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,
> +
> --- /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
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
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
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.
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
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
>
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
On Tue, Jul 02, 2019 at 11:48:44AM +0200, Arend Van Spriel wrote:
> You made me look ;-) Actually not touching my drivers so I'm off the hook.
> However, I was wondering if drivers could know so I decided to look into
> the DMA-API.txt documentation which currently states:
>
> """
> The flag
On Fri, Jun 14, 2019 at 03:47:10PM +0200, Christoph Hellwig wrote:
> Switching to a slightly cleaned up alloc_pages_exact is pretty easy,
> but it turns out that because we didn't filter valid gfp_t flags
> on the DMA allocator, a bunch of drivers were passing __GFP_COMP
> to it, whi
>From the DMA point of view this looks good:
Reviewed-by: Christoph Hellwig
I still think that doing that SetPageReserved + remap_pfn_range
dance for the normal memory allocations is a bad idea. Just use
vm_insert_page on the page, in which case it doesn't need to be
marked as Reser
On Wed, Jun 19, 2019 at 01:29:03PM -0300, Jason Gunthorpe wrote:
> > Yes. This will blow up badly on many platforms, as sq->queue
> > might be vmapped, ioremapped, come from a pool without page backing.
>
> Gah, this addr gets fed into io_remap_pfn_range/remap_pfn_range too..
>
> Potnuri, you
> + struct scatterlist *sg = *cur_sg ?:
> + (struct scatterlist *)scsi_sglist(srb);
> +
No need for the cast here. And I have to say I hate that GNU C
non-standard shortshut in ? :.
Why not simply:
struct scatterlist *sg = *cur_sg;
> drivers/infiniband/hw/cxgb4/qp.c
>129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
>130 {
>131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev),
> sq->memsize,
>132 &(sq->dma_addr), GFP_KERNEL);
>
; This way allows us to pre-allocate one small scatterlist, which can be
> chained with one runtime allocated scatterlist if the pre-allocated one
> isn't enough for the whole request.
Looks good,
Reviewed-by: Christoph Hellwig
___
devel mailing
1 - 100 of 389 matches
Mail list logo
