On Fri, Aug 30, 2019 at 07:46:44PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently there are error return paths in ffsReadFile that
> exit via lable err_out that return and uninitialized error
> return in variable ret. Fix this by initializing ret to zero.
>
> Addresses-Coverity:
You can drop the if on line 3490.
julia
-- Forwarded message --
Date: Tue, 3 Sep 2019 04:28:35 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [staging:staging-testing 268/273]
drivers/staging/exfat/exfat_super.c:3491:2-7: WARNING: NULL check
On Mon, Sep 02, 2019 at 10:08:54AM -0400, Valdis Klētnieks wrote:
> On Mon, 02 Sep 2019 15:42:19 +0300, Anatoly Pugachev said:
>
> > is it intentionally that you use
> >
> > yes "" | make oldconfig
> >
> > instead of
> >
> > make olddefconfig
>
> They do something different. 'olddefconfig' just
> From: Dexuan Cui
> Sent: Tuesday, August 13, 2019 6:07 PM
> To: lorenzo.pieral...@arm.com; bhelg...@google.com;
> linux-...@vger.kernel.org
> Cc: Michael Kelley ; linux-hyp...@vger.kernel.org;
> linux-ker...@vger.kernel.org; driverdev-devel@linuxdriverproject.org; Sasha
> Levin ; Haiyang Zhang
Hi Rui,
On 9/2/19 2:38 AM, Rui Miguel Silva wrote:
Hi Steve,
On Tue 06 Aug 2019 at 00:34, Steve Longerbeam wrote:
Implement a notifier bound op to register media links from the remote
sub-device's source pad(s) to the CSI sink pad.
Signed-off-by: Steve Longerbeam
---
Fixes checkpatch.pl warnings:
CHECK: Please don't use multiple blank lines
CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Please use a blank line after function/struct/union/enum
declarations
Signed-off-by: Valentin Vidic
---
drivers/staging/exfat/exfat.h
Fixes checkpatch.pl warning:
CHECK: Prefer using the BIT macro
Signed-off-by: Valentin Vidic
---
drivers/staging/exfat/exfat.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index
On Mon, 2019-09-02 at 11:07 -0700, Randy Dunlap wrote:
> On 9/2/19 10:46 AM, Greg KH wrote:
> > On Mon, Sep 02, 2019 at 10:39:39AM -0700, Randy Dunlap wrote:
> > > On 9/2/19 5:43 AM, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > News: I will only be doing 2 more releases before I leave
On Mon, Sep 02, 2019 at 11:11:45AM -0700, Joe Perches wrote:
> On Mon, 2019-09-02 at 11:07 -0700, Randy Dunlap wrote:
> > On 9/2/19 10:46 AM, Greg KH wrote:
> > > On Mon, Sep 02, 2019 at 10:39:39AM -0700, Randy Dunlap wrote:
> > > > On 9/2/19 5:43 AM, Stephen Rothwell wrote:
> > > > > Hi all,
> >
On 9/2/19 10:46 AM, Greg KH wrote:
> On Mon, Sep 02, 2019 at 10:39:39AM -0700, Randy Dunlap wrote:
>> On 9/2/19 5:43 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> News: I will only be doing 2 more releases before I leave for Kernel
>>> Summit (there may be some reports on Thursday, but I doubt I
On Mon, Sep 02, 2019 at 10:39:39AM -0700, Randy Dunlap wrote:
> On 9/2/19 5:43 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > News: I will only be doing 2 more releases before I leave for Kernel
> > Summit (there may be some reports on Thursday, but I doubt I will have
> > time to finish the
On Mon, Sep 02, 2019 at 10:39:39AM -0700, Randy Dunlap wrote:
> On 9/2/19 5:43 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > News: I will only be doing 2 more releases before I leave for Kernel
> > Summit (there may be some reports on Thursday, but I doubt I will have
> > time to finish the
On 9/2/19 5:43 AM, Stephen Rothwell wrote:
> Hi all,
>
> News: I will only be doing 2 more releases before I leave for Kernel
> Summit (there may be some reports on Thursday, but I doubt I will have
> time to finish the full release) and then no more until Sept 30.
>
> Changes since 20190830:
>
On Fri, Aug 30, 2019 at 02:30:19AM -0500, Tyler Hicks wrote:
> On 2019-08-30 08:29:10, Greg Kroah-Hartman wrote:
> > On Thu, Aug 29, 2019 at 10:13:20AM -0500, Tyler Hicks wrote:
> > > Hello, Sasha!
> > >
> > > On 2019-08-29 06:49:51, Sasha Levin wrote:
> > > > From: Tyler Hicks
> > > >
> > > >
Hi Christoph,
On Mon, Sep 02, 2019 at 08:23:23AM -0700, Christoph Hellwig wrote:
> 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
Hi Christoph,
On Mon, Sep 02, 2019 at 08:19:10AM -0700, Christoph Hellwig wrote:
> On Mon, Sep 02, 2019 at 10:43:04PM +0800, Gao Xiang wrote:
> > Hi Christoph,
> > > > ...
> > > > 24 __le32 features;/* (aka. feature_compat) */
> > > > ...
> > > > 38 __le32 requirements;
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,
Hi Christoph,
On Mon, Sep 02, 2019 at 08:06:40AM -0700, Christoph Hellwig wrote:
> 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
>
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
Hi Christoph,
On Mon, Sep 02, 2019 at 08:06:40AM -0700, Christoph Hellwig wrote:
> 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
>
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
Hi Christoph,
On Mon, Sep 02, 2019 at 05:51:09AM -0700, Christoph Hellwig wrote:
> 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 {
Hi Christoph,
On Mon, Sep 02, 2019 at 05:46:45AM -0700, Christoph Hellwig wrote:
> 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,
> >
On Mon, Sep 02, 2019 at 09:51:59PM +0800, Chao Yu wrote:
> On 2019-9-2 21:06, David Sterba wrote:
> > On Mon, Sep 02, 2019 at 05:57:11AM -0700, Christoph Hellwig wrote:
> >>> +config EROFS_FS_XATTR
> >>> + bool "EROFS extended attributes"
> >>> + depends on EROFS_FS
> >>> + default y
> >>> + help
On Fri, Aug 30, 2019 at 08:39:43AM +0200, Greg KH wrote:
> On Fri, Aug 30, 2019 at 02:59:01AM +0800, Peikan Tsai wrote:
> > On Thu, Aug 29, 2019 at 05:27:22PM +0200, Christian Brauner wrote:
> > > On Thu, Aug 29, 2019 at 09:53:59AM -0400, Joel Fernandes wrote:
> > > > On Thu, Aug 29, 2019 at
On Mon, 02 Sep 2019 15:42:19 +0300, Anatoly Pugachev said:
> is it intentionally that you use
>
> yes "" | make oldconfig
>
> instead of
>
> make olddefconfig
They do something different. 'olddefconfig' just takes the platform or
architecture defconfig and updates it for any new CONFIG_*
On Mon, Sep 02, 2019 at 10:43:03AM +0200, Pavel Machek wrote:
> > > > Rather than they didn't run "gdb" or "pahole" and change it by mistake.
> > >
> > > I think Christoph is not right here.
> > >
> > > Using external tools for validation is extra work
> > > when necessary for understanding the
Hi David,
On Mon, Sep 02, 2019 at 03:43:29PM +0200, David Sterba wrote:
> On Sun, Sep 01, 2019 at 05:34:00PM +0800, Gao Xiang wrote:
> > > > +static int read_inode(struct inode *inode, void *data)
> > > > +{
> > > > + struct erofs_vnode *vi = EROFS_V(inode);
> > > > + struct
On 2019-9-2 21:06, David Sterba wrote:
> On Mon, Sep 02, 2019 at 05:57:11AM -0700, Christoph Hellwig wrote:
>>> +config EROFS_FS_XATTR
>>> + bool "EROFS extended attributes"
>>> + depends on EROFS_FS
>>> + default y
>>> + help
>>> + Extended attributes are name:value pairs associated
On Sun, Sep 01, 2019 at 05:34:00PM +0800, Gao Xiang wrote:
> > > +static int read_inode(struct inode *inode, void *data)
> > > +{
> > > + struct erofs_vnode *vi = EROFS_V(inode);
> > > + struct erofs_inode_v1 *v1 = data;
> > > + const unsigned int advise = le16_to_cpu(v1->i_advise);
> > > +
Hi Christoph,
On Mon, Sep 02, 2019 at 05:54:38AM -0700, Christoph Hellwig wrote:
> 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
Hi Christoph,
On Mon, Sep 02, 2019 at 05:47:37AM -0700, Christoph Hellwig wrote:
> 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;
> >
On Mon, Sep 02, 2019 at 05:57:11AM -0700, Christoph Hellwig wrote:
> > +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
Hi Christoph,
On Mon, Sep 02, 2019 at 05:57:11AM -0700, Christoph Hellwig wrote:
> > +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
> > +
Hi Christoph,
On Mon, Sep 02, 2019 at 05:45:21AM -0700, Christoph Hellwig wrote:
> 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
> >
> +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);
> > > + inode_init_once(&((struct erofs_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 <
Hi Christoph,
On Mon, Sep 02, 2019 at 05:31:24AM -0700, Christoph Hellwig wrote:
> > @@ -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);
> >
On Mon, Sep 2, 2019 at 4:52 AM Tobin C. Harding wrote:
>
> On Sun, Sep 01, 2019 at 05:30:23AM +0530, Amit Kumar wrote:
> > Hi,
> > I think now your tutorial should be ready.
>
> I do not understand what this means sorry. Is it a request for action?
> The tutorial was a couple of weeks ago now,
Hi Christoph,
On Mon, Sep 02, 2019 at 05:26:27AM -0700, Christoph Hellwig wrote:
> >
> > - 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
> @@ -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
Hi Christoph,
On Mon, Sep 02, 2019 at 05:14:24AM -0700, Christoph Hellwig wrote:
> 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
Hi Christoph,
On Mon, Sep 02, 2019 at 05:12:34AM -0700, Christoph Hellwig wrote:
> > + 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.
Yes, thanks and will
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.
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);
> > + inode_init_once(&((struct erofs_inode *)ptr)->vfs_inode);
>
> Why doesn't this use EROFS_I? This looks a little odd.
> + 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
Hi Pavel,
(Thanks...)
On Mon, Sep 02, 2019 at 10:40:20AM +0200, Pavel Machek wrote:
>
> So __packed is right thing to do. If architecture accesses that
> slowly, that's ungood, but different structures between architectures
> would be really bad.
(...a little word, it seems that Christoph was
From: Colin Ian King
The return statement is incorrect, the error exit should be by
assigning ret with the error code and exiting via label out.
Thanks to Valdis Klētnieks for correcting my original fix.
Addresses-Coverity: ("Structurally dead code")
Signed-off-by: Colin Ian King
---
V2: exit
Hi Steve,
On Tue 06 Aug 2019 at 00:34, Steve Longerbeam wrote:
> Implement a notifier bound op to register media links from the remote
> sub-device's source pad(s) to the CSI sink pad.
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/staging/media/imx/imx7-media-csi.c | 24
Hi Steve,
Just to let you know that this series no longer apply clean after
your other series:
media: imx: Fix subdev unregister/register issues
And since you will need to send a new one, some notes...
On Tue 06 Aug 2019 at 00:34, Steve Longerbeam wrote:
> Implement a notifier bound op to
Hi!
> > > Rather than they didn't run "gdb" or "pahole" and change it by mistake.
> >
> > I think Christoph is not right here.
> >
> > Using external tools for validation is extra work
> > when necessary for understanding the code.
>
> The advantage of using the external tools that the
Hi!
> > +struct erofs_super_block {
> > +/* 0 */__le32 magic; /* in the little endian */
> > +/* 4 */__le32 checksum;/* crc32c(super_block) */
> > +/* 8 */__le32 features;/* (aka. feature_compat) */
> > +/* 12 */__u8 blkszbits; /* support block_size ==
On Sun, Sep 01, 2019 at 07:23:03PM +0200, Pavel Machek wrote:
> Hi!
>
> > The Greybus code has long been "stable" but was living in the
> > drivers/staging/ directory to see if there really was going to be
> > devices using this protocol over the long-term. With the success of
> > millions of
74 matches
Mail list logo
