Merge version 3.17.2-2+rpi1 and 3.17.2-3 to produce 3.17.2-3+rpi1

Merge fuse3 (3.17.2-3) import into refs/heads/workingbranch

[PATCH] memfs_ll: fix deadlock in truncate operation

Remove redundant mutex lock acquisition in the truncate() method to
prevent deadlock. The issue occurs when memfs_setattr() already holds
the mutex lock and then calls truncate(), which attempts to acquire
the same lock again.

Signed-off-by: Long Li <leo.lilong@huawei.com>
Gbp-Pq: Name memfs_ll-fix-deadlock.patch

[PATCH] fusermount: Fix the close_range ifdef

This fixes commit 82bcd818
That commit had removed HAVE_LINUX_CLOSE_RANGE in meson generation,
but didn't remove the usage in fusermount.c - fusermount was then
not using the close_range syscall.

Closes: https://github.com/libfuse/libfuse/issues/1284
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
Gbp-Pq: Name Fix-the-close_range-ifdef.patch

[PATCH] conn->want conversion: Fix fuse_apply_conn_info_opts()

fuse_apply_conn_info_opts() was applying to 'want_ext',
which would cause conflicts with 'want' if the application
applied its own flags to 'conn->want'.

Solution is:
    - to move fuse_{set,unset,get}_feature_flag and
      convert_to_conn_want_ext() to fuse_lowlevel.c and
      to define them as part of the public API, although
      convert_to_conn_want_ext() should not be used - it is
      currently needed to be a public function due as it needs
      to be defined for the tests.

Related to https://github.com/libfuse/libfuse/issues/1171 and
https://github.com/libfuse/libfuse/pull/1172.

Closes: https://github.com/libfuse/libfuse/issues/1171
Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Gbp-Pq: Name Fix-fuse_apply_conn_info_opts.patch

[PATCH] Add container_of and ROUND_UP macros

Needed by follow up commits. container_of is actually
just moved/consolidated to util.h.

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
(cherry picked from commit c5a032b3410d7225ac0355355faa63565a209943)

Gbp-Pq: Name Add-container_of-and-ROUND_UP-macros.patch

[PATCH] Make conn->want/want_ext conversion non fatal

there are too many issues with conn->want and conn->want_ext
conversion, for now just log a warning, but setting both
flags is now not fatal anymore.

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Gbp-Pq: Name Make_conn-want-want_ext_conversion_non_fatal.patch

[PATCH] meson.build: make special_funcs check more reliable

Unfortunately while cross-compiling with build tools like Buildroot it
happens to have repeated flags or anything that could lead to a warning.
This way the check fails because of a warning not related to the special
function. So let's use cc.links() and increase minimum meson_version to
0.60 since cc.links() has been added during that version.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name meson.build-make-special_funcs-check-more-reliable.patch

[PATCH] Fix meson function tests

Several meson tests were incorrectly failing

Checking for function "static_assert" : NO (cached)
Checking for function "pthread_setname_np" : NO (cached)
Check usable header "#include <linux/close_range.h>" : NO (cached)

These functions get now tested with compilation tests
and get found on my system.

Checking if "static_assert check" compiles: YES
Checking if "pthread_setname_np check" compiles: YES
Checking if "close_range check" compiles: YES

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name Fix_meson_function_tests.patch

fuse3 (3.17.2-3) unstable; urgency=medium

  * Backport upstream fixes:
    - fix the close_range ifdef,
    - fix deadlock in truncate operation in memfs_ll.cc example.

[dgit import unpatched fuse3 3.17.2-3]

Import fuse3_3.17.2-3.debian.tar.xz

[dgit import tarball fuse3 3.17.2-3 fuse3_3.17.2-3.debian.tar.xz]

Manual merge of version 3.17.2-1+rpi1 and 3.17.2-2 to produce 3.17.2-2+rpi1

Merge fuse3 (3.17.2-2) import into refs/heads/workingbranch

[PATCH] conn->want conversion: Fix fuse_apply_conn_info_opts()

fuse_apply_conn_info_opts() was applying to 'want_ext',
which would cause conflicts with 'want' if the application
applied its own flags to 'conn->want'.

Solution is:
    - to move fuse_{set,unset,get}_feature_flag and
      convert_to_conn_want_ext() to fuse_lowlevel.c and
      to define them as part of the public API, although
      convert_to_conn_want_ext() should not be used - it is
      currently needed to be a public function due as it needs
      to be defined for the tests.

Related to https://github.com/libfuse/libfuse/issues/1171 and
https://github.com/libfuse/libfuse/pull/1172.

Closes: https://github.com/libfuse/libfuse/issues/1171
Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Gbp-Pq: Name Fix-fuse_apply_conn_info_opts.patch

[PATCH] Add container_of and ROUND_UP macros

Needed by follow up commits. container_of is actually
just moved/consolidated to util.h.

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
(cherry picked from commit c5a032b3410d7225ac0355355faa63565a209943)

Gbp-Pq: Name Add-container_of-and-ROUND_UP-macros.patch

[PATCH] Make conn->want/want_ext conversion non fatal

there are too many issues with conn->want and conn->want_ext
conversion, for now just log a warning, but setting both
flags is now not fatal anymore.

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Gbp-Pq: Name Make_conn-want-want_ext_conversion_non_fatal.patch

[PATCH] meson.build: make special_funcs check more reliable

Unfortunately while cross-compiling with build tools like Buildroot it
happens to have repeated flags or anything that could lead to a warning.
This way the check fails because of a warning not related to the special
function. So let's use cc.links() and increase minimum meson_version to
0.60 since cc.links() has been added during that version.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name meson.build-make-special_funcs-check-more-reliable.patch

[PATCH] Fix meson function tests

Several meson tests were incorrectly failing

Checking for function "static_assert" : NO (cached)
Checking for function "pthread_setname_np" : NO (cached)
Check usable header "#include <linux/close_range.h>" : NO (cached)

These functions get now tested with compilation tests
and get found on my system.

Checking if "static_assert check" compiles: YES
Checking if "pthread_setname_np check" compiles: YES
Checking if "close_range check" compiles: YES

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name Fix_meson_function_tests.patch

fuse3 (3.17.2-2) unstable; urgency=medium

  [ Laszlo Boszormenyi (GCS) ]
  * Backport upstream fixes (closes: #1101305):
    - make conn->want/want_ext conversion non fatal,
    - add container_of and ROUND_UP macros,
    - conn->want conversion: fix fuse_apply_conn_info_opts() .
  * Update symbols file (closes: #1105099).

  [ Helmut Grohne <helmut@subdivi.de> ]
  * Update -latomic architecture list (closes: #1105150).

[dgit import unpatched fuse3 3.17.2-2]

Import fuse3_3.17.2-2.debian.tar.xz

[dgit import tarball fuse3 3.17.2-2 fuse3_3.17.2-2.debian.tar.xz]

Merge fuse3 (3.17.2-1+rpi1) import into refs/heads/workingbranch

[PATCH] meson.build: make special_funcs check more reliable

Unfortunately while cross-compiling with build tools like Buildroot it
happens to have repeated flags or anything that could lead to a warning.
This way the check fails because of a warning not related to the special
function. So let's use cc.links() and increase minimum meson_version to
0.60 since cc.links() has been added during that version.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name meson.build-make-special_funcs-check-more-reliable.patch

[PATCH] Fix meson function tests

Several meson tests were incorrectly failing

Checking for function "static_assert" : NO (cached)
Checking for function "pthread_setname_np" : NO (cached)
Check usable header "#include <linux/close_range.h>" : NO (cached)

These functions get now tested with compilation tests
and get found on my system.

Checking if "static_assert check" compiles: YES
Checking if "pthread_setname_np check" compiles: YES
Checking if "close_range check" compiles: YES

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name Fix_meson_function_tests.patch

fuse3 (3.17.2-1+rpi1) trixie-staging; urgency=medium

  * Link with libatomic on raspbian too.

[dgit import unpatched fuse3 3.17.2-1+rpi1]

Import fuse3_3.17.2-1+rpi1.debian.tar.xz

[dgit import tarball fuse3 3.17.2-1+rpi1 fuse3_3.17.2-1+rpi1.debian.tar.xz]

Import fuse3_3.17.2.orig.tar.gz

[dgit import orig fuse3_3.17.2.orig.tar.gz]

Merge fuse3 (3.17.2-1) import into refs/heads/workingbranch

[PATCH] meson.build: make special_funcs check more reliable

Unfortunately while cross-compiling with build tools like Buildroot it
happens to have repeated flags or anything that could lead to a warning.
This way the check fails because of a warning not related to the special
function. So let's use cc.links() and increase minimum meson_version to
0.60 since cc.links() has been added during that version.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name meson.build-make-special_funcs-check-more-reliable.patch

[PATCH] Fix meson function tests

Several meson tests were incorrectly failing

Checking for function "static_assert" : NO (cached)
Checking for function "pthread_setname_np" : NO (cached)
Check usable header "#include <linux/close_range.h>" : NO (cached)

These functions get now tested with compilation tests
and get found on my system.

Checking if "static_assert check" compiles: YES
Checking if "pthread_setname_np check" compiles: YES
Checking if "close_range check" compiles: YES

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Gbp-Pq: Name Fix_meson_function_tests.patch

fuse3 (3.17.2-1) unstable; urgency=medium

  * New upstream release:
    - check if pthread_setname_np() exists before use it,
    - fix example/memfs_ll rename deadlock error,
    - signal handlers: Store fuse_session unconditionally.
  * Backport upstream fixes:
    - fix meson function tests,
    - meson.build: make special_funcs check more reliable.

[dgit import unpatched fuse3 3.17.2-1]

Import fuse3_3.17.2-1.debian.tar.xz

[dgit import tarball fuse3 3.17.2-1 fuse3_3.17.2-1.debian.tar.xz]

Merge fuse3 (3.14.0-10) import into refs/heads/workingbranch

[PATCH] Fix memory leak in high level API (#781)

Previously, in the high level API if we received a signal between
setting up signal handlers and processing INIT, we would leak

```
$ ./example/hello -s -d -f mountpoint/
[9/9] Linking target example/hello_ll
FUSE library version: 3.14.1
nullpath_ok: 0

=================================================================
==178330==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 352 byte(s) in 1 object(s) allocated from:
    #0 0x7fbb19abf411 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x7fbb1a0efd3b in fuse_fs_new ../lib/fuse.c:4814
    #2 0x7fbb1a0f02b5 in fuse_new_31 ../lib/fuse.c:4913
    #3 0x7fbb1a10ec5e in fuse_main_real ../lib/helper.c:345
    #4 0x5625db8ab418 in main ../example/hello.c:176
    #5 0x7fbb1983c78f  (/usr/lib/libc.so.6+0x2378f)

SUMMARY: AddressSanitizer: 352 byte(s) leaked in 1 allocation(s).
```

That's because `fuse_lowlevel.c`s `fuse_session_destroy` would only call
the user supplied `op.destroy`, if INIT had been processed, but the high
level API relied on `op.destroy` to free `f->fs`.

This patch moves the freeing into `fuse_destroy` that will always be
called by our high-level API.

Gbp-Pq: Name Fix_memory_leak_in_high_level_API.patch

[PATCH] Fix max_threads command line parameter propagation

The fuse_main_real() method doesn't apply the max_threads parameter
parsed through the commandline arguments. This commit fixes the wiring
of max_threads argument.

Gbp-Pq: Name Fix-max_threads-command-line-parameter-propagation.patch

use new header name of fuse

Bug-Debian: https://bugs.debian.org/1031544
Forwarded: no
Last-Update: 2023-03-17

Just rename fuse_config.h to libfuse_config.h

Gbp-Pq: Name update_header_name.patch

[PATCH] upgrade of fuse_kernel.h based on Miklos expire_only kernel patch https://git./linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next&id=53e949edb7692dce02220eba926c9d75ecbb47f7

Gbp-Pq: Name revert_upgrade_of_fuse_kernel.h.patch

fuse3 (3.14.0-10) unstable; urgency=medium

  [ Helmut Grohne <helmut@subdivi.de> ]
  * Upgrade Breaks for fuse to Conflicts to prevent accidental file loss
    (DEP17, closes: #1082357).

[dgit import unpatched fuse3 3.14.0-10]

Import fuse3_3.14.0-10.debian.tar.xz

[dgit import tarball fuse3 3.14.0-10 fuse3_3.14.0-10.debian.tar.xz]

Merge fuse3 (3.14.0-4) import into refs/heads/workingbranch

[PATCH] Fix memory leak in high level API (#781)

Previously, in the high level API if we received a signal between
setting up signal handlers and processing INIT, we would leak

```
$ ./example/hello -s -d -f mountpoint/
[9/9] Linking target example/hello_ll
FUSE library version: 3.14.1
nullpath_ok: 0

=================================================================
==178330==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 352 byte(s) in 1 object(s) allocated from:
    #0 0x7fbb19abf411 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x7fbb1a0efd3b in fuse_fs_new ../lib/fuse.c:4814
    #2 0x7fbb1a0f02b5 in fuse_new_31 ../lib/fuse.c:4913
    #3 0x7fbb1a10ec5e in fuse_main_real ../lib/helper.c:345
    #4 0x5625db8ab418 in main ../example/hello.c:176
    #5 0x7fbb1983c78f  (/usr/lib/libc.so.6+0x2378f)

SUMMARY: AddressSanitizer: 352 byte(s) leaked in 1 allocation(s).
```

That's because `fuse_lowlevel.c`s `fuse_session_destroy` would only call
the user supplied `op.destroy`, if INIT had been processed, but the high
level API relied on `op.destroy` to free `f->fs`.

This patch moves the freeing into `fuse_destroy` that will always be
called by our high-level API.

Gbp-Pq: Name Fix_memory_leak_in_high_level_API.patch

[PATCH] Fix max_threads command line parameter propagation

The fuse_main_real() method doesn't apply the max_threads parameter
parsed through the commandline arguments. This commit fixes the wiring
of max_threads argument.

Gbp-Pq: Name Fix-max_threads-command-line-parameter-propagation.patch

use new header name of fuse

Bug-Debian: https://bugs.debian.org/1031544
Forwarded: no
Last-Update: 2023-03-17

Just rename fuse_config.h to libfuse_config.h

Gbp-Pq: Name update_header_name.patch

[PATCH] upgrade of fuse_kernel.h based on Miklos expire_only kernel patch https://git./linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next&id=53e949edb7692dce02220eba926c9d75ecbb47f7

Gbp-Pq: Name revert_upgrade_of_fuse_kernel.h.patch

fuse3 (3.14.0-4) unstable; urgency=medium

  * Backport upstream fixes:
    - fix max_threads command line parameter propagation,
    - fix memory leak in high level API.

[dgit import unpatched fuse3 3.14.0-4]

Import fuse3_3.14.0-4.debian.tar.xz

[dgit import tarball fuse3 3.14.0-4 fuse3_3.14.0-4.debian.tar.xz]

Import fuse3_3.14.0.orig.tar.xz

[dgit import orig fuse3_3.14.0.orig.tar.xz]

fuse3 (3.10.3-2) unstable; urgency=medium

  * Do not try to alter cuse device permissions (closes: #947229, #989977).

[dgit import unpatched fuse3 3.10.3-2]

Import fuse3_3.10.3-2.debian.tar.xz

[dgit import tarball fuse3 3.10.3-2 fuse3_3.10.3-2.debian.tar.xz]

Import fuse3_3.10.3.orig.tar.xz

[dgit import orig fuse3_3.10.3.orig.tar.xz]