Re: Linux 5.2-RC regression bisected, mounting glusterfs volumes fails after commit: fuse: require /dev/fuse reads to have enough buffer capacity

[Miklos Szeredi]

On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov  wrote:

> Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for
> header room change be accepted?

Yes, next cycle.   For 4.2 I'll just push the revert.

Thanks,
Miklos

[Gluster-devel] Removing glupy from release 5.7

[Hari Gowtham]

Hi,

Due to the recent changes we made. we have a build issue because of glupy.
As glupy is already removed from master, we are thinking of removing
it in 5.7 as well rather than fixing the issue.

The release of 5.7 will be delayed as we have send a patch to fix this issue.
And if anyone has any concerns, do let us know.

-- 
Regards,
Hari Gowtham.
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

[PATCH] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)

[Kirill Smelkov]

On Wed, Jun 12, 2019 at 09:44:49AM +0200, Miklos Szeredi wrote:
> On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov  wrote:
> 
> > Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for
> > header room change be accepted?
> 
> Yes, next cycle.   For 4.2 I'll just push the revert.

Thanks Miklos. Please consider queuing the following patch for 5.3.
Sander, could you please confirm that glusterfs is not broken with this
version of the check?

Thanks beforehand,
Kirill

 8< 
>From 24a04e8be9bbf6e67de9e1908dcbe95d426d2521 Mon Sep 17 00:00:00 2001
From: Kirill Smelkov 
Date: Wed, 27 Mar 2019 10:15:15 +
Subject: [PATCH] fuse: require /dev/fuse reads to have enough buffer capacity 
(take 2)

[ This retries commit d4b13963f217 which was reverted in 766741fcaa1f.

  In this version we require only `sizeof(fuse_in_header) + 
sizeof(fuse_write_in)`
  instead of 4K for FUSE request header room, because, contrary to
  libfuse and kernel client behaviour, GlusterFS actually provides only
  so much room for request header. ]

A FUSE filesystem server queues /dev/fuse sys_read calls to get
filesystem requests to handle. It does not know in advance what would be
that request as it can be anything that client issues - LOOKUP, READ,
WRITE, ... Many requests are short and retrieve data from the
filesystem. However WRITE and NOTIFY_REPLY write data into filesystem.

Before getting into operation phase, FUSE filesystem server and kernel
client negotiate what should be the maximum write size the client will
ever issue. After negotiation the contract in between server/client is
that the filesystem server then should queue /dev/fuse sys_read calls with
enough buffer capacity to receive any client request - WRITE in
particular, while FUSE client should not, in particular, send WRITE
requests with > negotiated max_write payload. FUSE client in kernel and
libfuse historically reserve 4K for request header. However an existing
filesystem server - GlusterFS - was found which reserves only 80 bytes
for header room (= `sizeof(fuse_in_header) + sizeof(fuse_write_in)`).

https://lore.kernel.org/linux-fsdevel/20190611202738.ga22...@deco.navytux.spb.ru/
https://github.com/gluster/glusterfs/blob/v3.8.15-0-gd174f021a/xlators/mount/fuse/src/fuse-bridge.c#L4894

Since

`sizeof(fuse_in_header) + sizeof(fuse_write_in)` ==
`sizeof(fuse_in_header) + sizeof(fuse_read_in)`  ==
`sizeof(fuse_in_header) + sizeof(fuse_notify_retrieve_in)`

is the absolute minimum any sane filesystem should be using for header
room, the contract is that filesystem server should queue sys_reads with
`sizeof(fuse_in_header) + sizeof(fuse_write_in)` + max_write buffer.

If the filesystem server does not follow this contract, what can happen
is that fuse_dev_do_read will see that request size is > buffer size,
and then it will return EIO to client who issued the request but won't
indicate in any way that there is a problem to filesystem server.
This can be hard to diagnose because for some requests, e.g. for
NOTIFY_REPLY which mimics WRITE, there is no client thread that is
waiting for request completion and that EIO goes nowhere, while on
filesystem server side things look like the kernel is not replying back
after successful NOTIFY_RETRIEVE request made by the server.

We can make the problem easy to diagnose if we indicate via error return to
filesystem server when it is violating the contract.  This should not
practically cause problems because if a filesystem server is using shorter
buffer, writes to it were already very likely to cause EIO, and if the
filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER
minimum buffer size.

Please see [1] for context where the problem of stuck filesystem was hit
for real (because kernel client was incorrectly sending more than
max_write data with NOTIFY_REPLY; see also previous patch), how the
situation was traced and for more involving patch that did not make it
into the tree.

[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2

Signed-off-by: Kirill Smelkov 
Cc: Han-Wen Nienhuys 
Cc: Jakob Unterwurzacher 
Signed-off-by: Miklos Szeredi 
---
 fs/fuse/dev.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index ea8237513dfa..15531ba560b5 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -1317,6 +1317,25 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, 
struct file *file,
unsigned reqsize;
unsigned int hash;
 
+   /*
+* Require sane minimum read buffer - that has capacity for fixed part
+* of any request header + negotiated max_write room for data. If the
+* requirement is not satisfied return EINVAL to the filesystem server
+* to indicate that it is not following FUSE server/client contract.
+* Don't dequeue / abort any request.
+*
+* Historically libfuse reserves 4K for fixed header room, but e.g.
+* GlusterFS res

Re: [Gluster-devel] [PATCH] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)

[Sander Eikelenboom]

On 12/06/2019 13:25, Kirill Smelkov wrote:
> On Wed, Jun 12, 2019 at 09:44:49AM +0200, Miklos Szeredi wrote:
>> On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov  wrote:
>>
>>> Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for
>>> header room change be accepted?
>>
>> Yes, next cycle.   For 4.2 I'll just push the revert.
> 
> Thanks Miklos. Please consider queuing the following patch for 5.3.
> Sander, could you please confirm that glusterfs is not broken with this
> version of the check?
> 
> Thanks beforehand,
> Kirill

Sure will give it a spin this evening and report back.

--
Sander
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [PATCH] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)

[Sander Eikelenboom]

On 12/06/2019 13:25, Kirill Smelkov wrote:
> On Wed, Jun 12, 2019 at 09:44:49AM +0200, Miklos Szeredi wrote:
>> On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov  wrote:
>>
>>> Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for
>>> header room change be accepted?
>>
>> Yes, next cycle.   For 4.2 I'll just push the revert.
> 
> Thanks Miklos. Please consider queuing the following patch for 5.3.
> Sander, could you please confirm that glusterfs is not broken with this
> version of the check?
> 
> Thanks beforehand,
> Kirill


Hmm unfortunately it doesn't build, see below.

--
Sander


In file included from ./include/linux/list.h:9:0,
 from ./include/linux/wait.h:7,
 from ./include/linux/wait_bit.h:8,
 from ./include/linux/fs.h:6,
 from fs/fuse/fuse_i.h:17,
 from fs/fuse/dev.c:9:
fs/fuse/dev.c: In function ‘fuse_dev_do_read’:
fs/fuse/dev.c:1336:14: error: ‘fuse_in_header’ undeclared (first use in this 
function)
   sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write))
  ^
./include/linux/kernel.h:818:40: note: in definition of macro ‘__typecheck’
   (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
^
./include/linux/kernel.h:842:24: note: in expansion of macro ‘__safe_cmp’
  __builtin_choose_expr(__safe_cmp(x, y), \
^~
./include/linux/kernel.h:918:27: note: in expansion of macro ‘__careful_cmp’
 #define max_t(type, x, y) __careful_cmp((type)(x), (type)(y), >)
   ^
fs/fuse/dev.c:1335:15: note: in expansion of macro ‘max_t’
  if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER,
   ^
fs/fuse/dev.c:1336:14: note: each undeclared identifier is reported only once 
for each function it appears in
   sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write))
  ^
./include/linux/kernel.h:818:40: note: in definition of macro ‘__typecheck’
   (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
^
./include/linux/kernel.h:842:24: note: in expansion of macro ‘__safe_cmp’
  __builtin_choose_expr(__safe_cmp(x, y), \
^~
./include/linux/kernel.h:918:27: note: in expansion of macro ‘__careful_cmp’
 #define max_t(type, x, y) __careful_cmp((type)(x), (type)(y), >)
   ^
fs/fuse/dev.c:1335:15: note: in expansion of macro ‘max_t’
  if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER,
   ^
fs/fuse/dev.c:1336:39: error: ‘fuse_write_in’ undeclared (first use in this 
function)
   sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write))
   ^
./include/linux/kernel.h:818:40: note: in definition of macro ‘__typecheck’
   (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
^
./include/linux/kernel.h:842:24: note: in expansion of macro ‘__safe_cmp’
  __builtin_choose_expr(__safe_cmp(x, y), \
^~
./include/linux/kernel.h:918:27: note: in expansion of macro ‘__careful_cmp’
 #define max_t(type, x, y) __careful_cmp((type)(x), (type)(y), >)
   ^
fs/fuse/dev.c:1335:15: note: in expansion of macro ‘max_t’
  if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER,
   ^
./include/linux/kernel.h:842:2: error: first argument to 
‘__builtin_choose_expr’ not a constant
  __builtin_choose_expr(__safe_cmp(x, y), \
  ^
./include/linux/kernel.h:918:27: note: in expansion of macro ‘__careful_cmp’
 #define max_t(type, x, y) __careful_cmp((type)(x), (type)(y), >)
   ^
fs/fuse/dev.c:1335:15: note: in expansion of macro ‘max_t’
  if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER,
   ^
scripts/Makefile.build:278: recipe for target 'fs/fuse/dev.o' failed
make[3]: *** [fs/fuse/dev.o] Error 1
scripts/Makefile.build:489: recipe for target 'fs/fuse' failed
make[2]: *** [fs/fuse] Error 2

Re: [Gluster-devel] Removing glupy from release 5.7

[Niels de Vos]

On Wed, Jun 12, 2019 at 02:44:04PM +0530, Hari Gowtham wrote:
> Hi,
> 
> Due to the recent changes we made. we have a build issue because of glupy.
> As glupy is already removed from master, we are thinking of removing
> it in 5.7 as well rather than fixing the issue.
> 
> The release of 5.7 will be delayed as we have send a patch to fix this issue.
> And if anyone has any concerns, do let us know.

Could you link to the BZ with the build error and patches that attempt
fixing it?

We normally do not remove features with minor updates. Fixing the build
error would be the preferred approach.

Thanks,
Niels
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [PATCH] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)

[Kirill Smelkov]

On Wed, Jun 12, 2019 at 03:03:49PM +0200, Sander Eikelenboom wrote:
> On 12/06/2019 13:25, Kirill Smelkov wrote:
> > On Wed, Jun 12, 2019 at 09:44:49AM +0200, Miklos Szeredi wrote:
> >> On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov  wrote:
> >>
> >>> Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for
> >>> header room change be accepted?
> >>
> >> Yes, next cycle.   For 4.2 I'll just push the revert.
> >
> > Thanks Miklos. Please consider queuing the following patch for 5.3.
> > Sander, could you please confirm that glusterfs is not broken with this
> > version of the check?
> >
> > Thanks beforehand,
> > Kirill
>
>
> Hmm unfortunately it doesn't build, see below.
> [...]
> fs/fuse/dev.c:1336:14: error: ‘fuse_in_header’ undeclared (first use in this 
> function)
>sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write))

Sorry, my bad, it was missing "struct" before fuse_in_header. I
originally compile-tested the patch with `make -j4`, was distracted onto
other topic and did not see the error after returning due to long tail
of successful CC lines. Apologize for the inconvenience. Below is a
fixed patch that was both compile-tested and runtime-tested with my FUSE
workloads (non-glusterfs).

Kirill

 8< 
>From 98fd29bb6789d5f6c346274b99d47008ad856607 Mon Sep 17 00:00:00 2001
From: Kirill Smelkov 
Date: Wed, 12 Jun 2019 17:06:18 +0300
Subject: [PATCH v2] fuse: require /dev/fuse reads to have enough buffer 
capacity (take 2)

[ This retries commit d4b13963f217 which was reverted in 766741fcaa1f.

  In this version we require only `sizeof(fuse_in_header) + 
sizeof(fuse_write_in)`
  instead of 4K for FUSE request header room, because, contrary to
  libfuse and kernel client behaviour, GlusterFS actually provides only
  so much room for request header. ]

A FUSE filesystem server queues /dev/fuse sys_read calls to get
filesystem requests to handle. It does not know in advance what would be
that request as it can be anything that client issues - LOOKUP, READ,
WRITE, ... Many requests are short and retrieve data from the
filesystem. However WRITE and NOTIFY_REPLY write data into filesystem.

Before getting into operation phase, FUSE filesystem server and kernel
client negotiate what should be the maximum write size the client will
ever issue. After negotiation the contract in between server/client is
that the filesystem server then should queue /dev/fuse sys_read calls with
enough buffer capacity to receive any client request - WRITE in
particular, while FUSE client should not, in particular, send WRITE
requests with > negotiated max_write payload. FUSE client in kernel and
libfuse historically reserve 4K for request header. However an existing
filesystem server - GlusterFS - was found which reserves only 80 bytes
for header room (= `sizeof(fuse_in_header) + sizeof(fuse_write_in)`).

https://lore.kernel.org/linux-fsdevel/20190611202738.ga22...@deco.navytux.spb.ru/
https://github.com/gluster/glusterfs/blob/v3.8.15-0-gd174f021a/xlators/mount/fuse/src/fuse-bridge.c#L4894

Since

`sizeof(fuse_in_header) + sizeof(fuse_write_in)` ==
`sizeof(fuse_in_header) + sizeof(fuse_read_in)`  ==
`sizeof(fuse_in_header) + sizeof(fuse_notify_retrieve_in)`

is the absolute minimum any sane filesystem should be using for header
room, the contract is that filesystem server should queue sys_reads with
`sizeof(fuse_in_header) + sizeof(fuse_write_in)` + max_write buffer.

If the filesystem server does not follow this contract, what can happen
is that fuse_dev_do_read will see that request size is > buffer size,
and then it will return EIO to client who issued the request but won't
indicate in any way that there is a problem to filesystem server.
This can be hard to diagnose because for some requests, e.g. for
NOTIFY_REPLY which mimics WRITE, there is no client thread that is
waiting for request completion and that EIO goes nowhere, while on
filesystem server side things look like the kernel is not replying back
after successful NOTIFY_RETRIEVE request made by the server.

We can make the problem easy to diagnose if we indicate via error return to
filesystem server when it is violating the contract.  This should not
practically cause problems because if a filesystem server is using shorter
buffer, writes to it were already very likely to cause EIO, and if the
filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER
minimum buffer size.

Please see [1] for context where the problem of stuck filesystem was hit
for real (because kernel client was incorrectly sending more than
max_write data with NOTIFY_REPLY; see also previous patch), how the
situation was traced and for more involving patch that did not make it
into the tree.

[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2

Signed-off-by: Kirill Smelkov 
Cc: Han-Wen Nienhuys 
Cc: Jakob Unterwurzacher 
---
 fs/fuse/dev.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/f

Re: [Gluster-devel] Removing glupy from release 5.7

[Hari Gowtham]

We haven't sent any patch to fix it.
Waiting for the decision to be made.
The bz: https://bugzilla.redhat.com/show_bug.cgi?id=1719778
The link to the build log:
https://build.gluster.org/job/strfmt_errors/1/artifact/RPMS/el6/i686/build.log

The last few messages in the log:

config.status: creating xlators/features/changelog/lib/src/Makefile
config.status: creating xlators/features/changetimerecorder/Makefile
config.status: creating xlators/features/changetimerecorder/src/Makefile
BUILDSTDERR: config.status: error: cannot find input file:
xlators/features/glupy/Makefile.in
RPM build errors:
BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
Child return code was: 1
EXCEPTION: [Error()]
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py",
line 96, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.6/site-packages/mockbuild/util.py", line 736,
in do_with_status
raise exception.Error("Command failed: \n # %s\n%s" % (command,
output), child.returncode)
mockbuild.exception.Error: Command failed:
 # bash --login -c /usr/bin/rpmbuild -bb --target i686 --nodeps
/builddir/build/SPECS/glusterfs.spec

On Wed, Jun 12, 2019 at 7:04 PM Niels de Vos  wrote:
>
> On Wed, Jun 12, 2019 at 02:44:04PM +0530, Hari Gowtham wrote:
> > Hi,
> >
> > Due to the recent changes we made. we have a build issue because of glupy.
> > As glupy is already removed from master, we are thinking of removing
> > it in 5.7 as well rather than fixing the issue.
> >
> > The release of 5.7 will be delayed as we have send a patch to fix this 
> > issue.
> > And if anyone has any concerns, do let us know.
>
> Could you link to the BZ with the build error and patches that attempt
> fixing it?
>
> We normally do not remove features with minor updates. Fixing the build
> error would be the preferred approach.
>
> Thanks,
> Niels



-- 
Regards,
Hari Gowtham.
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Removing glupy from release 5.7

[Niels de Vos]

On Wed, Jun 12, 2019 at 07:54:17PM +0530, Hari Gowtham wrote:
> We haven't sent any patch to fix it.
> Waiting for the decision to be made.
> The bz: https://bugzilla.redhat.com/show_bug.cgi?id=1719778
> The link to the build log:
> https://build.gluster.org/job/strfmt_errors/1/artifact/RPMS/el6/i686/build.log
> 
> The last few messages in the log:
> 
> config.status: creating xlators/features/changelog/lib/src/Makefile
> config.status: creating xlators/features/changetimerecorder/Makefile
> config.status: creating xlators/features/changetimerecorder/src/Makefile
> BUILDSTDERR: config.status: error: cannot find input file:
> xlators/features/glupy/Makefile.in
> RPM build errors:
> BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
> BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
> Child return code was: 1
> EXCEPTION: [Error()]
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py",
> line 96, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.6/site-packages/mockbuild/util.py", line 736,
> in do_with_status
> raise exception.Error("Command failed: \n # %s\n%s" % (command,
> output), child.returncode)
> mockbuild.exception.Error: Command failed:
>  # bash --login -c /usr/bin/rpmbuild -bb --target i686 --nodeps
> /builddir/build/SPECS/glusterfs.spec

Those messages are caused by missing files. The 'make dist' that
generates the tarball in the previous step did not included the glupy
files.

https://build.gluster.org/job/strfmt_errors/1/console contains the
following message:

configure: WARNING:

-
cannot build glupy. python 3.6 and python-devel/python-dev package 
are required.

-

I am not sure if there have been any recent backports to release-5 that
introduced this behaviour. Maybe it is related to the builder where the
tarball is generated. The job seems to detect python-3.6.8, which is not
included in CentOS-7 for all I know?

Maybe someone else understands how this can happen?

HTH,
Niels


> 
> On Wed, Jun 12, 2019 at 7:04 PM Niels de Vos  wrote:
> >
> > On Wed, Jun 12, 2019 at 02:44:04PM +0530, Hari Gowtham wrote:
> > > Hi,
> > >
> > > Due to the recent changes we made. we have a build issue because of glupy.
> > > As glupy is already removed from master, we are thinking of removing
> > > it in 5.7 as well rather than fixing the issue.
> > >
> > > The release of 5.7 will be delayed as we have send a patch to fix this 
> > > issue.
> > > And if anyone has any concerns, do let us know.
> >
> > Could you link to the BZ with the build error and patches that attempt
> > fixing it?
> >
> > We normally do not remove features with minor updates. Fixing the build
> > error would be the preferred approach.
> >
> > Thanks,
> > Niels
> 
> 
> 
> -- 
> Regards,
> Hari Gowtham.
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [PATCH] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)

[Sander Eikelenboom]

On 12/06/2019 16:12, Kirill Smelkov wrote:
> On Wed, Jun 12, 2019 at 03:03:49PM +0200, Sander Eikelenboom wrote:
>> On 12/06/2019 13:25, Kirill Smelkov wrote:
>>> On Wed, Jun 12, 2019 at 09:44:49AM +0200, Miklos Szeredi wrote:
 On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov  wrote:

> Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for
> header room change be accepted?

 Yes, next cycle.   For 4.2 I'll just push the revert.
>>>
>>> Thanks Miklos. Please consider queuing the following patch for 5.3.
>>> Sander, could you please confirm that glusterfs is not broken with this
>>> version of the check?
>>>
>>> Thanks beforehand,
>>> Kirill
>>
>>
>> Hmm unfortunately it doesn't build, see below.
>> [...]
>> fs/fuse/dev.c:1336:14: error: ‘fuse_in_header’ undeclared (first use in this 
>> function)
>>sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write))
> 
> Sorry, my bad, it was missing "struct" before fuse_in_header. I
> originally compile-tested the patch with `make -j4`, was distracted onto
> other topic and did not see the error after returning due to long tail
> of successful CC lines. Apologize for the inconvenience. Below is a
> fixed patch that was both compile-tested and runtime-tested with my FUSE
> workloads (non-glusterfs).
> 
> Kirill
> 

Just tested and it works for me, thanks !

--
Sander

Re: [PATCH] fuse: require /dev/fuse reads to have enough buffer capacity (take 2)

[Kirill Smelkov]

On Wed, Jun 12, 2019 at 06:28:17PM +0200, Sander Eikelenboom wrote:
> On 12/06/2019 16:12, Kirill Smelkov wrote:
> > On Wed, Jun 12, 2019 at 03:03:49PM +0200, Sander Eikelenboom wrote:
> >> On 12/06/2019 13:25, Kirill Smelkov wrote:
> >>> On Wed, Jun 12, 2019 at 09:44:49AM +0200, Miklos Szeredi wrote:
>  On Tue, Jun 11, 2019 at 10:28 PM Kirill Smelkov  wrote:
> 
> > Miklos, would 4K -> `sizeof(fuse_in_header) + sizeof(fuse_write_in)` for
> > header room change be accepted?
> 
>  Yes, next cycle.   For 4.2 I'll just push the revert.
> >>>
> >>> Thanks Miklos. Please consider queuing the following patch for 5.3.
> >>> Sander, could you please confirm that glusterfs is not broken with this
> >>> version of the check?
> >>>
> >>> Thanks beforehand,
> >>> Kirill
> >>
> >>
> >> Hmm unfortunately it doesn't build, see below.
> >> [...]
> >> fs/fuse/dev.c:1336:14: error: ‘fuse_in_header’ undeclared (first use in 
> >> this function)
> >>sizeof(fuse_in_header) + sizeof(fuse_write_in) + fc->max_write))
> >
> > Sorry, my bad, it was missing "struct" before fuse_in_header. I
> > originally compile-tested the patch with `make -j4`, was distracted onto
> > other topic and did not see the error after returning due to long tail
> > of successful CC lines. Apologize for the inconvenience. Below is a
> > fixed patch that was both compile-tested and runtime-tested with my FUSE
> > workloads (non-glusterfs).
> >
> > Kirill
> >
>
> Just tested and it works for me, thanks !

Thanks for feedback. Kirill

Re: [Gluster-devel] Removing glupy from release 5.7

[Amar Tumballi Suryanarayan]

On Wed, Jun 12, 2019 at 8:42 PM Niels de Vos  wrote:

> On Wed, Jun 12, 2019 at 07:54:17PM +0530, Hari Gowtham wrote:
> > We haven't sent any patch to fix it.
> > Waiting for the decision to be made.
> > The bz: https://bugzilla.redhat.com/show_bug.cgi?id=1719778
> > The link to the build log:
> >
> https://build.gluster.org/job/strfmt_errors/1/artifact/RPMS/el6/i686/build.log
> >
> > The last few messages in the log:
> >
> > config.status: creating xlators/features/changelog/lib/src/Makefile
> > config.status: creating xlators/features/changetimerecorder/Makefile
> > config.status: creating xlators/features/changetimerecorder/src/Makefile
> > BUILDSTDERR: config.status: error: cannot find input file:
> > xlators/features/glupy/Makefile.in
> > RPM build errors:
> > BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
> > BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.kGZI5V (%build)
> > Child return code was: 1
> > EXCEPTION: [Error()]
> > Traceback (most recent call last):
> >   File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py",
> > line 96, in trace
> > result = func(*args, **kw)
> >   File "/usr/lib/python3.6/site-packages/mockbuild/util.py", line 736,
> > in do_with_status
> > raise exception.Error("Command failed: \n # %s\n%s" % (command,
> > output), child.returncode)
> > mockbuild.exception.Error: Command failed:
> >  # bash --login -c /usr/bin/rpmbuild -bb --target i686 --nodeps
> > /builddir/build/SPECS/glusterfs.spec
>
> Those messages are caused by missing files. The 'make dist' that
> generates the tarball in the previous step did not included the glupy
> files.
>
> https://build.gluster.org/job/strfmt_errors/1/console contains the
> following message:
>
> configure: WARNING:
>
> -
> cannot build glupy. python 3.6 and python-devel/python-dev
> package are required.
>
> -
>
> I am not sure if there have been any recent backports to release-5 that
> introduced this behaviour. Maybe it is related to the builder where the
> tarball is generated. The job seems to detect python-3.6.8, which is not
> included in CentOS-7 for all I know?
>
>
We recently noticed that in one of the package update on builder (ie,
centos7.x machines), python3.6 got installed as a dependency. So, yes, it
is possible to have python3 in centos7 now.

-Amar


> Maybe someone else understands how this can happen?
>
> HTH,
> Niels
>
>
> >
> > On Wed, Jun 12, 2019 at 7:04 PM Niels de Vos  wrote:
> > >
> > > On Wed, Jun 12, 2019 at 02:44:04PM +0530, Hari Gowtham wrote:
> > > > Hi,
> > > >
> > > > Due to the recent changes we made. we have a build issue because of
> glupy.
> > > > As glupy is already removed from master, we are thinking of removing
> > > > it in 5.7 as well rather than fixing the issue.
> > > >
> > > > The release of 5.7 will be delayed as we have send a patch to fix
> this issue.
> > > > And if anyone has any concerns, do let us know.
> > >
> > > Could you link to the BZ with the build error and patches that attempt
> > > fixing it?
> > >
> > > We normally do not remove features with minor updates. Fixing the build
> > > error would be the preferred approach.
> > >
> > > Thanks,
> > > Niels
> >
> >
> >
> > --
> > Regards,
> > Hari Gowtham.
> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>

-- 
Amar Tumballi (amarts)
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Removing glupy from release 5.7

[Kaleb Keithley]

On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan <
atumb...@redhat.com> wrote:

>
> We recently noticed that in one of the package update on builder (ie,
> centos7.x machines), python3.6 got installed as a dependency. So, yes, it
> is possible to have python3 in centos7 now.
>

EPEL updated from python34 to python36 recently, but C7 doesn't have
python3 in the base. I don't think we've ever used EPEL packages for
building.

And GlusterFS-5 isn't python3 ready.

--

Kaleb
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Removing glupy from release 5.7

[Kaleb Keithley]

On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley  wrote:

>
> On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan <
> atumb...@redhat.com> wrote:
>
>>
>> We recently noticed that in one of the package update on builder (ie,
>> centos7.x machines), python3.6 got installed as a dependency. So, yes, it
>> is possible to have python3 in centos7 now.
>>
>
> EPEL updated from python34 to python36 recently, but C7 doesn't have
> python3 in the base. I don't think we've ever used EPEL packages for
> building.
>
> And GlusterFS-5 isn't python3 ready.
>

Correction: GlusterFS-5 is mostly or completely python3 ready.  FWIW,
python33 is available on both RHEL7 and CentOS7 from the Software
Collection Library (SCL), and python34 and now python36 are available from
EPEL.

But packages built for the CentOS Storage SIG have never used the SCL or
EPEL (EPEL not allowed) and the shebangs in the .py files are converted
from /usr/bin/python3 to /usr/bin/python2 during the rpmbuild %prep stage.
All the python dependencies for the packages remain the python2 flavors.
AFAIK the centos-regression machines ought to be building the same way.

--

Kaleb
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Fwd: Details on the Scan.coverity.com June 2019 Upgrade

[Atin Mukherjee]

Fyi..no scan for 3-4 days starting from June 17th for the upgrade. Post
that we may have to do some changes to use the new build tool?

-- Forwarded message -
From: Peter Degen-Portnoy 
Date: Thu, 13 Jun 2019 at 00:48
Subject: Details on the Scan.coverity.com June 2019 Upgrade


June 17, 9 a.m. MDT
View this email in a browser


[image: Synopsys]

Coverity Scan 2019 Upgrade


Dear Atin Mukherjee,
Thank you for being an active user of scan.coverity.com
.
We have some important news to share with you.

As you know, the version of Coverity used by the Scan website is somewhat
out of date. So we’re pleased to announce that we’re upgrading to the
latest stable production version.

We’re currently verifying the upgrade. Here’s what you can expect:

We plan to start the upgrade *Monday, June 17, around 9 a.m. MDT*. We
expect the process to last 3–4 days.

During this time, scan.coverity.com

may be offline and unavailable. If possible, we’ll provide access to
scan.coverity.com

in read-only mode.

After the upgrade, you should use the new Build tool that matches the
upgraded version of Coverity. Specifically, the build tool from Coverity
8.7 will no longer be supported.

You can find details about the upgrade and the new build tool on the Scan
Status Community

page. You can also subscribe to scan.coverity.com

status updates on this page by clicking the “Follow” button and selecting
“Every Post.”

Please take a look at the information on the Scan Status Community page. If
you have any questions about the upgrade, post them on the Synopsys
Software Integrity Community
.
We’ll answer as soon as we can.

Sincerely yours,
The Scan Administrators

scan-ad...@coverity.com


Follow









© 2019 Synopsys, Inc. All Rights Reserved
690 E Middlefield Rd, Mountain View, CA 94043


About

   Privacy

   Unsubscribe




-- 
--Atin
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Removing glupy from release 5.7

[Deepshikha Khandelwal]

On Thu, Jun 13, 2019 at 4:41 AM Kaleb Keithley  wrote:

>
>
> On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley 
> wrote:
>
>>
>> On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan <
>> atumb...@redhat.com> wrote:
>>
>>>
>>> We recently noticed that in one of the package update on builder (ie,
>>> centos7.x machines), python3.6 got installed as a dependency. So, yes, it
>>> is possible to have python3 in centos7 now.
>>>
>>
>> EPEL updated from python34 to python36 recently, but C7 doesn't have
>> python3 in the base. I don't think we've ever used EPEL packages for
>> building.
>>
>> And GlusterFS-5 isn't python3 ready.
>>
>
> Correction: GlusterFS-5 is mostly or completely python3 ready.  FWIW,
> python33 is available on both RHEL7 and CentOS7 from the Software
> Collection Library (SCL), and python34 and now python36 are available from
> EPEL.
>
> But packages built for the CentOS Storage SIG have never used the SCL or
> EPEL (EPEL not allowed) and the shebangs in the .py files are converted
> from /usr/bin/python3 to /usr/bin/python2 during the rpmbuild %prep stage.
> All the python dependencies for the packages remain the python2 flavors.
> AFAIK the centos-regression machines ought to be building the same way.
>

centos-regression machines have 'CentOS Linux release 7.6.1810 (Core)' and
using python3.6. Looking at the tracebacks when compiling we confirmed that
it is picking up python3.6 somehow.

To resolve this issue either we can remove glupy from the release(which is
dead anyways) or install glupy on the instances.

>
> --
>
> Kaleb
> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Fwd: Details on the Scan.coverity.com June 2019 Upgrade

[Deepshikha Khandelwal]

Thanks Atin for pointing this out. Yes, I'll upgrade the matching build
tool on builders once coverity is upgraded on scan.coverity.com

On Thu, Jun 13, 2019 at 8:01 AM Atin Mukherjee 
wrote:

> Fyi..no scan for 3-4 days starting from June 17th for the upgrade. Post
> that we may have to do some changes to use the new build tool?
>
> -- Forwarded message -
> From: Peter Degen-Portnoy 
> Date: Thu, 13 Jun 2019 at 00:48
> Subject: Details on the Scan.coverity.com June 2019 Upgrade
>
>
> June 17, 9 a.m. MDT
> View this email in a browser
> 
>
> [image: Synopsys]
> 
> Coverity Scan 2019 Upgrade
>
>
> Dear Atin Mukherjee,
> Thank you for being an active user of scan.coverity.com
> .
> We have some important news to share with you.
>
> As you know, the version of Coverity used by the Scan website is somewhat
> out of date. So we’re pleased to announce that we’re upgrading to the
> latest stable production version.
>
> We’re currently verifying the upgrade. Here’s what you can expect:
>
> We plan to start the upgrade *Monday, June 17, around 9 a.m. MDT*. We
> expect the process to last 3–4 days.
>
> During this time, scan.coverity.com
> 
> may be offline and unavailable. If possible, we’ll provide access to
> scan.coverity.com
> 
> in read-only mode.
>
> After the upgrade, you should use the new Build tool that matches the
> upgraded version of Coverity. Specifically, the build tool from Coverity
> 8.7 will no longer be supported.
>
> You can find details about the upgrade and the new build tool on the Scan
> Status Community
> 
> page. You can also subscribe to scan.coverity.com
> 
> status updates on this page by clicking the “Follow” button and selecting
> “Every Post.”
>
> Please take a look at the information on the Scan Status Community page.
> If you have any questions about the upgrade, post them on the Synopsys
> Software Integrity Community
> .
> We’ll answer as soon as we can.
>
> Sincerely yours,
> The Scan Administrators
>
> scan-ad...@coverity.com
>
>
> Follow
>
>
> 
>
> 
>
> 
>
> 
>
> © 2019 Synopsys, Inc. All Rights Reserved
> 690 E Middlefield Rd, Mountain View, CA 94043
> 
>
> About
> 
>Privacy
> 
>Unsubscribe
> 
>
>
>
> --
> --Atin
> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.

Re: [Gluster-devel] Removing glupy from release 5.7

[Kaleb Keithley]

On Wed, Jun 12, 2019 at 8:13 PM Deepshikha Khandelwal 
wrote:

>
> On Thu, Jun 13, 2019 at 4:41 AM Kaleb Keithley 
> wrote:
>
>>
>>
>> On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley 
>> wrote:
>>
>>>
>>> On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan <
>>> atumb...@redhat.com> wrote:
>>>

 We recently noticed that in one of the package update on builder (ie,
 centos7.x machines), python3.6 got installed as a dependency. So, yes, it
 is possible to have python3 in centos7 now.

>>>
>>> EPEL updated from python34 to python36 recently, but C7 doesn't have
>>> python3 in the base. I don't think we've ever used EPEL packages for
>>> building.
>>>
>>> And GlusterFS-5 isn't python3 ready.
>>>
>>
>> Correction: GlusterFS-5 is mostly or completely python3 ready.  FWIW,
>> python33 is available on both RHEL7 and CentOS7 from the Software
>> Collection Library (SCL), and python34 and now python36 are available from
>> EPEL.
>>
>> But packages built for the CentOS Storage SIG have never used the SCL or
>> EPEL (EPEL not allowed) and the shebangs in the .py files are converted
>> from /usr/bin/python3 to /usr/bin/python2 during the rpmbuild %prep stage.
>> All the python dependencies for the packages remain the python2 flavors.
>> AFAIK the centos-regression machines ought to be building the same way.
>>
>
> centos-regression machines have 'CentOS Linux release 7.6.1810 (Core)' and
> using python3.6. Looking at the tracebacks when compiling we confirmed that
> it is picking up python3.6 somehow.
>

We need to figure out why? BTW, my CentOS 7 box is up to date and does not
have any version of python3. I would have to use the SCL or EPEL to get it.

What changed on June 5th?  Between
https://build.gluster.org/job/centos7-regression/6309/consoleFull and
https://build.gluster.org/job/centos7-regression/6310/consoleFull?

6309 was the last centos-regression with python2.7.  6310 and all
subsequent centos-regressions have been built with python3.6.

Somebody added EPEL!  Do we not have a record of the changes made and who
made them?

And BTW, this affects more than just glusterfs-5, it's affecting all
versions: glusterfs-4.1, glusterfs-5, glusterfs-6, and master.


> To resolve this issue either we can remove glupy from the release(which is
> dead anyways) or install glupy on the instances.
>

Or you can resolve where python36 came from and undo the change that
introduced it.

At the risk of being repetitious – reiterating what Niels said – it's
highly unusual to remove features in a bug fix update.

It's also unusual to have switched to python3 on rhel7 like this. Was there
any discussion of such a change? If there was I seem to have missed it.

I suggest figuring out where python3.6 on rhel7 came from. Fix that first.
Removing glupy is a bandaid over a unrelated problem. Once the real problem
is fixed then there can be a separate discussion about removing the glupy
feature in glusterfs-5.

--

Kaleb
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel