Hi Christoph,
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 one
> fricking disaster, including Greg just moving not fully reviewed ones
> ove
Hi Christoph,
On Thu, Aug 29, 2019 at 03:01:49PM +0800, Gao Xiang wrote:
> Hi Christoph,
>
> 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 be
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 one
> > fricking disas
On Thu, Aug 29, 2019 at 02:41:36AM -0700, Christoph Hellwig wrote:
> 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
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
> --- /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 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,
> +
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
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
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
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
Hi Christoph,
On Thu, Aug 29, 2019 at 02:59:54AM -0700, Christoph Hellwig wrote:
> > --- /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 name
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
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,
From: Tyler Hicks
[ Upstream commit 60d4885710836595192c42d3e04b27551d30ec91 ]
Restore the behavior of locking mmap_sem for reading in
binder_alloc_free_page(), as was first done in commit 3013bf62b67a
("binder: reduce mmap_sem write-side lock"). That change was
inadvertently reverted by commit
From: Tyler Hicks
[ Upstream commit 60d4885710836595192c42d3e04b27551d30ec91 ]
Restore the behavior of locking mmap_sem for reading in
binder_alloc_free_page(), as was first done in commit 3013bf62b67a
("binder: reduce mmap_sem write-side lock"). That change was
inadvertently reverted by commit
Hi Christoph,
On Thu, Aug 29, 2019 at 03:15:45AM -0700, Christoph Hellwig wrote:
> 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",
> > +
Hi Christoph,
On Thu, Aug 29, 2019 at 03:36:04AM -0700, Christoph Hellwig wrote:
> 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 qual
On Thu, Aug 29, 2019 at 03:37:49AM -0700, Christoph Hellwig wrote:
> 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 w
On 8/22/19 9:45 PM, Jernej Skrabec wrote:
> This command is useful for explicitly flushing last decoded frame.
>
> Signed-off-by: Jernej Skrabec
> ---
> .../staging/media/sunxi/cedrus/cedrus_video.c | 34 +++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/staging/me
On Thu, Aug 29, 2019 at 03:37:49AM -0700, Christoph Hellwig wrote:
> 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 w
On Thu, Aug 29, 2019 at 07:04:43PM +0800, Gao Xiang wrote:
> On Thu, Aug 29, 2019 at 03:37:49AM -0700, Christoph Hellwig wrote:
> > 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
On 8/22/19 9:44 PM, Jernej Skrabec wrote:
> When frame contains multiple slices and driver works in slice mode, it's
> more efficient to hold capture buffer in queue until all slices of a
> same frame are decoded.
>
> Add support for that to Cedrus driver by exposing and implementing
> V4L2_BUF_CA
On Thu, Aug 29, 2019 at 03:28:38AM -0700, Christoph Hellwig wrote:
> 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 th
On 8/26/19 3:31 PM, YueHaibing wrote:
> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> to m will set IOMMU_IOVA to m, this fails the building of
> TEGRA_HOST1X and DRM_TEGRA which is y like this:
>
> drivers/gpu/host1x/cdma.o: In function `host1x_cdma_init':
> cdma.c:(.text+0x6
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 don't think
> any new file system should write up ->bmap these days.
iomap doesn't support tail
On Thu, Aug 29, 2019 at 03:24:26AM -0700, Christoph Hellwig wrote:
[]
>
> > +
> > + /* fill last page if inline data is available */
> > + err = fill_inline_data(inode, data, ofs);
>
> Well, I think you should move the is_inode_flat_inline and
> (S_ISLNK(inode->i_mode) && in
On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> The full specification of the filesystem can be found at:
> https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification
This is not truth. This specification is not "full". There are missing
important details, like ho
The problem is in gb_lights_request_handler(). If we get a request to
change the config then we release the light with gb_lights_light_release()
and re-allocated it. However, if the allocation fails part way through
then we call gb_lights_light_release() again. This can lead to a couple
differen
On Thu, 29 Aug 2019 14:14:35 +0200, Pali Roh�r said:
> On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> > The full specification of the filesystem can be found at:
> > https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification
>
> This is not truth. This specificati
On Thu, Aug 29, 2019 at 01:39:32PM +0200, Hans Verkuil wrote:
> On 8/26/19 3:31 PM, YueHaibing wrote:
> > If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> > to m will set IOMMU_IOVA to m, this fails the building of
> > TEGRA_HOST1X and DRM_TEGRA which is y like this:
> >
> > driv
On Thursday 29 August 2019 08:34:04 Valdis Klētnieks wrote:
> On Thu, 29 Aug 2019 14:14:35 +0200, Pali Roh?r said:
> > On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> > > The full specification of the filesystem can be found at:
> > >
> > > https://docs.microsoft.com/en-us/windo
while filling the linux inode, using switch-case statement to check
the type of inode.
switch-case statement looks more clean.
Signed-off-by: Pratik Shinde
---
drivers/staging/erofs/inode.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/er
On Thu, Aug 29, 2019 at 01:49:53PM +0800, Peikan Tsai wrote:
> Hi,
>
> The allocated size for each binder_thread is 512 bytes by kzalloc.
> Because the size of binder_thread is fixed and it's only 304 bytes.
> It will save 208 bytes per binder_thread when use create a kmem_cache
> for the binder_t
On Thu, Aug 29, 2019 at 08:42:29AM +0200, Greg KH wrote:
> On Thu, Aug 29, 2019 at 01:49:53PM +0800, Peikan Tsai wrote:
[snip]
> > The allocated size for each binder_thread is 512 bytes by kzalloc.
> > Because the size of binder_thread is fixed and it's only 304 bytes.
> > It will save 208 bytes p
Hi Pratik,
On Thu, Aug 29, 2019 at 06:38:13PM +0530, Pratik Shinde wrote:
> while filling the linux inode, using switch-case statement to check
> the type of inode.
> switch-case statement looks more clean.
>
> Signed-off-by: Pratik Shinde
No, that is not the case, see __ext4_iget() in fs/ext4/
29.08.2019 15:40, Thierry Reding пишет:
> On Thu, Aug 29, 2019 at 01:39:32PM +0200, Hans Verkuil wrote:
>> On 8/26/19 3:31 PM, YueHaibing wrote:
>>> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
>>> to m will set IOMMU_IOVA to m, this fails the building of
>>> TEGRA_HOST1X and DR
> +++ b/drivers/staging/exfat/exfat.h
> @@ -0,0 +1,973 @@
…
> +/* file types */
> +#define TYPE_UNUSED 0x
> +#define TYPE_DELETED 0x0001
…
> +/* time modes */
> +#define TM_CREATE0
> +#define TM_MODIFY1
Will it be helpful to work with enumerations at su
On Thu, Aug 29, 2019 at 07:35:01PM +0530, Pratik Shinde wrote:
> Hi Gao,
>
> Sorry I didn't pull the latest tree. I will do the necessary.
> Anyways, don't you think it will be cleaner to have a switch case statement
> rather than if-else statement.
I think so, but that's another personal choise
Hi Dan,
On Thu 29 Aug 2019 at 13:28, Dan Carpenter wrote:
> The problem is in gb_lights_request_handler(). If we get a request to
> change the config then we release the light with gb_lights_light_release()
> and re-allocated it. However, if the allocation fails part way through
> then we call gb
On Thu, Aug 29, 2019 at 09:56:07PM +0800, Gao Xiang wrote:
> Hi Pratik,
>
> On Thu, Aug 29, 2019 at 06:38:13PM +0530, Pratik Shinde wrote:
> > while filling the linux inode, using switch-case statement to check
> > the type of inode.
> > switch-case statement looks more clean.
> >
> > Signed-off-
On Thu, Aug 29, 2019 at 10:15:22PM +0800, Gao Xiang wrote:
> I am very happy that you send a patch about this, but we have
> to take care of handling "fall through" properly at least,
> and I don't want to introduce some extra compile warnings
> instead at this time.
I can't apply the patch so I m
Hello, Sasha!
On 2019-08-29 06:50:34, Sasha Levin wrote:
> From: Tyler Hicks
>
> [ Upstream commit 60d4885710836595192c42d3e04b27551d30ec91 ]
>
> Restore the behavior of locking mmap_sem for reading in
> binder_alloc_free_page(), as was first done in commit 3013bf62b67a
> ("binder: reduce mmap_
On Thu, Aug 29, 2019 at 01:18:10PM +0200, Greg Kroah-Hartman wrote:
> It could always use more review, which the developers asked for
> numerous times.
I stopped commenting on erofs style because all the likely/unlikely()
nonsense is a pet peeve.
regards,
dan carpenter
__
Hello, Sasha!
On 2019-08-29 06:49:51, Sasha Levin wrote:
> From: Tyler Hicks
>
> [ Upstream commit 60d4885710836595192c42d3e04b27551d30ec91 ]
>
> Restore the behavior of locking mmap_sem for reading in
> binder_alloc_free_page(), as was first done in commit 3013bf62b67a
> ("binder: reduce mmap_
Hi Dan,
On Thu, Aug 29, 2019 at 06:04:36PM +0300, Dan Carpenter wrote:
> On Thu, Aug 29, 2019 at 10:15:22PM +0800, Gao Xiang wrote:
> > I am very happy that you send a patch about this, but we have
> > to take care of handling "fall through" properly at least,
> > and I don't want to introduce som
As Christoph suggested [1], these marcos are much
more readable as a function.
[1] https://lore.kernel.org/r/20190829095954.gb20...@infradead.org/
Reported-by: Christoph Hellwig
Signed-off-by: Gao Xiang
---
fs/erofs/erofs_fs.h | 24
fs/erofs/inode.c| 4 ++--
fs/ero
As Christoph claimed [1], on-disk format should have
explicitly assigned numbers.
[1] https://lore.kernel.org/r/20190829095954.gb20...@infradead.org/
Reported-by: Christoph Hellwig
Signed-off-by: Gao Xiang
---
fs/erofs/erofs_fs.h | 18 +-
1 file changed, 9 insertions(+), 9 delet
On Thu, Aug 29, 2019 at 09:53:59AM -0400, Joel Fernandes wrote:
> On Thu, Aug 29, 2019 at 08:42:29AM +0200, Greg KH wrote:
> > On Thu, Aug 29, 2019 at 01:49:53PM +0800, Peikan Tsai wrote:
> [snip]
> > > The allocated size for each binder_thread is 512 bytes by kzalloc.
> > > Because the size of bi
Hi Dan,
On Thu, Aug 29, 2019 at 06:11:44PM +0300, Dan Carpenter wrote:
> On Thu, Aug 29, 2019 at 01:18:10PM +0200, Greg Kroah-Hartman wrote:
> > It could always use more review, which the developers asked for
> > numerous times.
>
> I stopped commenting on erofs style because all the likely/unlik
Hi Christoph,
On Thu, Aug 29, 2019 at 02:59:54AM -0700, Christoph Hellwig wrote:
[]
>
> > +static bool erofs_inode_is_data_compressed(unsigned int datamode)
> > +{
> > + if (datamode == EROFS_INODE_FLAT_COMPRESSION)
> > + return true;
> > + return datamode == EROFS_INODE_FLAT_COMP
> p.s. There are 2947 (un)likely places in fs/ directory.
I was complaining about you adding new pointless ones, not existing
ones. The likely/unlikely annotations are supposed to be functional and
not decorative. I explained this very clearly.
Probably most of the annotations in fs/ are wrong
> +++ b/drivers/staging/exfat/exfat_core.c
> @@ -0,0 +1,3704 @@
…
> +static s32 __load_upcase_table(struct super_block *sb, sector_t sector,
> +u32 num_sectors, u32 utbl_checksum)
> +{
…
> +error:
An other label would be nicer, wouldn't it?
> + if (tmp_bh)
> +
On Thu, Aug 29, 2019 at 04:58:22PM +0300, Dmitry Osipenko wrote:
> 29.08.2019 15:40, Thierry Reding пишет:
> > On Thu, Aug 29, 2019 at 01:39:32PM +0200, Hans Verkuil wrote:
> >> On 8/26/19 3:31 PM, YueHaibing wrote:
> >>> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> >>> to m w
Hi Dan,
On Thu, Aug 29, 2019 at 06:43:46PM +0300, Dan Carpenter wrote:
> > p.s. There are 2947 (un)likely places in fs/ directory.
>
> I was complaining about you adding new pointless ones, not existing
> ones. The likely/unlikely annotations are supposed to be functional and
> not decorative.
Hi Dan,
On Thu, Aug 29, 2019 at 11:51:27PM +0800, Gao Xiang wrote:
> Hi Dan,
>
> On Thu, Aug 29, 2019 at 06:43:46PM +0300, Dan Carpenter wrote:
> > > p.s. There are 2947 (un)likely places in fs/ directory.
> >
> > I was complaining about you adding new pointless ones, not existing
> > ones. The
On Thu, 2019-08-29 at 18:32 +0800, Gao Xiang wrote:
> Hi Christoph,
>
> On Thu, Aug 29, 2019 at 02:59:54AM -0700, Christoph Hellwig wrote:
> > > --- /dev/null
> > > +++ b/fs/erofs/erofs_fs.h
> > > @@ -0,0 +1,316 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-only OR Apache-2.0 */
> > > +/*
> > > +
As Dan Carpenter suggested [1], I have to remove
all erofs likely/unlikely annotations.
[1] https://lore.kernel.org/linux-fsdevel/20190829154346.GK23584@kadam/
Reported-by: Dan Carpenter
Signed-off-by: Gao Xiang
---
fs/erofs/data.c | 22 ++---
fs/erofs/decompressor.c |
On Thu, Aug 29, 2019 at 10:10:52AM -0500, Tyler Hicks wrote:
Hello, Sasha!
On 2019-08-29 06:50:34, Sasha Levin wrote:
From: Tyler Hicks
[ Upstream commit 60d4885710836595192c42d3e04b27551d30ec91 ]
Restore the behavior of locking mmap_sem for reading in
binder_alloc_free_page(), as was first
Hi Dan,
On Thu, Aug 29, 2019 at 11:43:46PM +0800, Dan Carpenter wrote:
> > p.s. There are 2947 (un)likely places in fs/ directory.
>
> I was complaining about you adding new pointless ones, not existing
> ones. The likely/unlikely annotations are supposed to be functional and
> not decorative.
Hi Joe,
On Thu, Aug 29, 2019 at 09:59:21AM -0700, Joe Perches wrote:
> On Fri, 2019-08-30 at 00:44 +0800, Gao Xiang wrote:
> > Hi Dan,
> >
> > On Thu, Aug 29, 2019 at 11:43:46PM +0800, Dan Carpenter wrote:
> > > > p.s. There are 2947 (un)likely places in fs/ directory.
> > >
> > > I was complain
on 2019/8/15 at 12:41, Gao Xiang wrote:
> [I strip the previous cover letter, the old one can be found in v6:
> https://lore.kernel.org/r/20190802125347.166018-1-gaoxian...@huawei.com/]
>
> We'd like to submit a formal moving patch applied to staging tree
> for 5.4, before that we'd like to he
As Joe Perches suggested [1],
err = bio_add_page(bio, page, PAGE_SIZE, 0);
- if (unlikely(err != PAGE_SIZE)) {
+ if (err != PAGE_SIZE) {
err = -EFAULT;
goto err_out;
}
The initial assignment
Hi Joe,
On Thu, Aug 29, 2019 at 08:58:17AM -0700, Joe Perches wrote:
> On Thu, 2019-08-29 at 18:32 +0800, Gao Xiang wrote:
> > Hi Christoph,
> >
> > On Thu, Aug 29, 2019 at 02:59:54AM -0700, Christoph Hellwig wrote:
> > > > --- /dev/null
> > > > +++ b/fs/erofs/erofs_fs.h
> > > > @@ -0,0 +1,316 @@
From: Vitaly Kuznetsov
[ Upstream commit 89eb4d8d25722a0a0194cf7fa47ba602e32a6da7 ]
When building hv_kvp_daemon GCC-8.3 complains:
hv_kvp_daemon.c: In function ‘kvp_get_ip_info.constprop’:
hv_kvp_daemon.c:812:30: warning: ‘ip_buffer’ may be used uninitialized in this
function [-Wmaybe-uninitia
From: Vitaly Kuznetsov
[ Upstream commit 89eb4d8d25722a0a0194cf7fa47ba602e32a6da7 ]
When building hv_kvp_daemon GCC-8.3 complains:
hv_kvp_daemon.c: In function ‘kvp_get_ip_info.constprop’:
hv_kvp_daemon.c:812:30: warning: ‘ip_buffer’ may be used uninitialized in this
function [-Wmaybe-uninitia
Hi Dan,
On Thu, Aug 29, 2019 at 11:13:53PM +0800, Gao Xiang wrote:
> Hi Dan,
>
> On Thu, Aug 29, 2019 at 06:04:36PM +0300, Dan Carpenter wrote:
> > On Thu, Aug 29, 2019 at 10:15:22PM +0800, Gao Xiang wrote:
> > > I am very happy that you send a patch about this, but we have
> > > to take care of
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 08:42:29AM +0200, Greg KH wrote:
> > > On Thu, Aug 29, 2019 at 01:49:53PM +0800, Peikan Tsai wrote:
> > [snip]
> > > > The allocated size
Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
napisal(a):
> Hi Jernej,
>
> On Thu, 22 Aug 2019 21:44:57 +0200
>
> Jernej Skrabec wrote:
> > When codec supports multiple slices in one frame, VPU has to know when
> > first slice of each frame is being processed, presumably t
Dear Friend,
My name is Capt. Zaya Hero, am looking for a reliable and trust worthy person
for a cordial relationship, please I'll be glad if you can kindly get back to
me for more details about business transaction worth 2.5 Million Dollars in
box, i need your help to deliver this 2.5 Million
On August 29, 2019 2:59:01 PM EDT, 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 08:42:29AM +0200, Greg KH wrote:
>> > > On Thu, Aug 29, 2019 at 01:49:53PM +0
On Fri, 2019-08-30 at 00:44 +0800, Gao Xiang wrote:
> Hi Dan,
>
> On Thu, Aug 29, 2019 at 11:43:46PM +0800, Dan Carpenter wrote:
> > > p.s. There are 2947 (un)likely places in fs/ directory.
> >
> > I was complaining about you adding new pointless ones, not existing
> > ones. The likely/unlikely
On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> From: Valdis Klētnieks
>
> The exfat code needs a lot of work to get it into "real" shape for
> the fs/ part of the kernel, so put it into drivers/staging/ for now so
> that it can be worked on by everyone in the community.
>
> The
On Thu, 29 Aug 2019 22:56:31 +0200, Pali Roh�r said:
> I'm not really sure if this exfat implementation is fully suitable for
> mainline linux kernel.
>
> In my opinion, proper way should be to implement exFAT support into
> existing fs/fat/ code instead of replacing whole vfat/msdosfs by this
> n
On Thu, Aug 29, 2019 at 07:18:16PM -0400, Valdis Klētnieks wrote:
On Thu, 29 Aug 2019 22:56:31 +0200, Pali Roh?r said:
I'm not really sure if this exfat implementation is fully suitable for
mainline linux kernel.
In my opinion, proper way should be to implement exFAT support into
existing fs/f
Hi John...
I added this patch series on top of Linux 5.3rc6 and ran
xfstests with no regressions...
Acked-by: Mike Marshall
-Mike
On Tue, Aug 6, 2019 at 9:50 PM John Hubbard wrote:
>
> On 8/6/19 6:32 PM, john.hubb...@gmail.com wrote:
> > From: John Hubbard
> > ...
> >
> > John Hubbard (38):
On 2019/8/29 23:43, Dan Carpenter wrote:
>> p.s. There are 2947 (un)likely places in fs/ directory.
>
> I was complaining about you adding new pointless ones, not existing
> ones. The likely/unlikely annotations are supposed to be functional and
> not decorative. I explained this very clearly.
>
On 8/29/2019 6:29 PM, Mike Marshall wrote:
Hi John...
I added this patch series on top of Linux 5.3rc6 and ran
xfstests with no regressions...
Acked-by: Mike Marshall
Hi Mike (and I hope Ira and others are reading as well, because
I'm making a bunch of claims further down),
That's great ne
As Christoph suggested [1], these marcos are much
more readable as a function.
[1] https://lore.kernel.org/r/20190829095954.gb20...@infradead.org/
Reported-by: Christoph Hellwig
Signed-off-by: Gao Xiang
---
v2: no change, just resend in case of dependency problem;
fs/erofs/erofs_fs.h | 24
As Joe Perches [1] suggested, let's use a better
form to describe complicated on-disk fields.
p.s. it has different tab alignment looking between
the real file and patch file.
p.p.s. due to changing a different form, some lines
have to exceed 80 characters.
[1]
https://lore.kernel.org
As Christoph claimed "Please don't add __packed" [1],
I have to 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 naturally aligned.
[1] https://lore.kernel.org/lkml/20190829095954.gb20...@infrade
As Dan Carpenter suggested [1], I have to remove
all erofs likely/unlikely annotations.
[1] https://lore.kernel.org/linux-fsdevel/20190829154346.GK23584@kadam/
Reported-by: Dan Carpenter
Signed-off-by: Gao Xiang
---
v2: no change, just resend in case of dependency problem;
fs/erofs/data.c
As Christoph claimed [1], on-disk format should have
explicitly assigned numbers. I have to change it.
[1] https://lore.kernel.org/r/20190829095954.gb20...@infradead.org/
Reported-by: Christoph Hellwig
Signed-off-by: Gao Xiang
---
v2: no change, just resend in case of dependency problem;
I have
As Joe Perches suggested [1],
err = bio_add_page(bio, page, PAGE_SIZE, 0);
- if (unlikely(err != PAGE_SIZE)) {
+ if (err != PAGE_SIZE) {
err = -EFAULT;
goto err_out;
}
The initial assignment
As Christoph said [1] "having this function
seems entirely pointless", I have to kill those.
filesystem function name
ext2,f2fs,ext4,isofs,squashfs,cifs,... init_inodecache
In addition, add a "rcu_barrier()" when exit_fs();
[1] https://lore.kernel.org/r/201908291015
Hi Joe,
On Thu, Aug 29, 2019 at 08:16:27PM -0700, Joe Perches wrote:
> On Fri, 2019-08-30 at 11:00 +0800, Gao Xiang wrote:
> > As Christoph suggested [1], these marcos are much
> > more readable as a function
>
> s/marcos/macros/
> .
> []
> > diff --git a/fs/erofs/erofs_fs.h b/fs/erofs/erofs_fs.h
On 2019/8/30 11:00, Gao Xiang wrote:
> As Christoph claimed [1], on-disk format should have
> explicitly assigned numbers. I have to change it.
>
> [1] https://lore.kernel.org/r/20190829095954.gb20...@infradead.org/
> Reported-by: Christoph Hellwig
> Signed-off-by: Gao Xiang
Reviewed-by: Chao Y
On 2019/8/30 11:00, Gao Xiang wrote:
> As Joe Perches [1] suggested, let's use a better
> form to describe complicated on-disk fields.
>
> p.s. it has different tab alignment looking between
> the real file and patch file.
> p.p.s. due to changing a different form, some lines
>have to
As Christoph suggested [1], these marcos are much
more readable as a function.
[1] https://lore.kernel.org/r/20190829095954.gb20...@infradead.org/
Reported-by: Christoph Hellwig
Signed-off-by: Gao Xiang
---
v3: change as Joe suggested,
https://lore.kernel.org/r/5b2ecf5cec1a6aa3834e9af41886a7fc
As Christoph said [1] "having this function
seems entirely pointless", I have to kill those.
filesystem function name
ext2,f2fs,ext4,isofs,squashfs,cifs,... init_inodecache
In addition, add a "rcu_barrier()" when exit_fs();
[1] https://lore.kernel.org/r/201908291015
As Joe Perches [1] suggested, let's use a better
form to describe complicated on-disk fields.
p.s. it has different tab alignment looking between
the real file and patch file.
p.p.s. due to changing a different form, some lines
have to exceed 80 characters.
[1]
https://lore.kernel.org
As Christoph claimed [1], on-disk format should have
explicitly assigned numbers. I have to change it.
[1] https://lore.kernel.org/r/20190829095954.gb20...@infradead.org/
Reported-by: Christoph Hellwig
Reviewed-by: Chao Yu
Signed-off-by: Gao Xiang
---
no change
fs/erofs/erofs_fs.h | 18 ++
As Dan Carpenter suggested [1], I have to remove
all erofs likely/unlikely annotations.
[1] https://lore.kernel.org/linux-fsdevel/20190829154346.GK23584@kadam/
Reported-by: Dan Carpenter
Signed-off-by: Gao Xiang
---
no change.
fs/erofs/data.c | 22 ++---
fs/erofs/decomp
As Christoph claimed "Please don't add __packed" [1],
I have to 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 naturally aligned.
[1] https://lore.kernel.org/lkml/20190829095954.gb20...@infrade
As Joe Perches suggested [1],
err = bio_add_page(bio, page, PAGE_SIZE, 0);
- if (unlikely(err != PAGE_SIZE)) {
+ if (err != PAGE_SIZE) {
err = -EFAULT;
goto err_out;
}
The initial assignment
As Christoph suggested [1], these macros are much
more readable as a function.
[1] https://lore.kernel.org/r/20190829095954.gb20...@infradead.org/
Reported-by: Christoph Hellwig
Signed-off-by: Gao Xiang
---
v4: a type fix in commit message.
v3: change as Joe suggested,
https://lore.kernel.org/
On Fri, 2019-08-30 at 11:00 +0800, Gao Xiang wrote:
> As Christoph suggested [1], these marcos are much
> more readable as a function
s/marcos/macros/
.
[]
> diff --git a/fs/erofs/erofs_fs.h b/fs/erofs/erofs_fs.h
[]
> @@ -168,16 +168,24 @@ struct erofs_xattr_entry {
> char e_name[0];
On Thu, 29 Aug 2019 21:04:28 +0200
Jernej Škrabec wrote:
> Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
> napisal(a):
> > Hi Jernej,
> >
> > On Thu, 22 Aug 2019 21:44:57 +0200
> >
> > Jernej Skrabec wrote:
> > > When codec supports multiple slices in one frame, VPU ha
On 2019/8/30 11:36, Gao Xiang wrote:
> As Christoph suggested [1], these marcos are much
> more readable as a function.
>
> [1] https://lore.kernel.org/r/20190829095954.gb20...@infradead.org/
> Reported-by: Christoph Hellwig
> Signed-off-by: Gao Xiang
Reviewed-by: Chao Yu
Thanks,
On 2019/8/30 11:36, Gao Xiang wrote:
> As Christoph claimed "Please don't add __packed" [1],
> I have to 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 naturally aligned.
>
> [1] https://
1 - 100 of 110 matches
Mail list logo
