Re: [PATCH v6] fuse: Add support for passthrough read/write

Hi Alessio, Thank you for working on this, I'm excited to see things moving again on this front! What I would really like to see in the long-term is the ability for FUSE to support passthrough for specific areas of a file, i.e. the ability to specify different passthrough fds for different

Re: [PATCH v2 02/30] fuse: Clear setuid bit even in cache=never path

On May 20 2019, Miklos Szeredi wrote: > On Mon, May 20, 2019 at 04:41:37PM +0200, Miklos Szeredi wrote: >> On Wed, May 15, 2019 at 03:26:47PM -0400, Vivek Goyal wrote: >> > If fuse daemon is started with cache=never, fuse falls back to direct IO. >> > In that write path we don't call

Re: [PATCH 1/2] Alps HID I2C T4 device support

ever, your patch still prevented hid_generic from taking control of the touchpad. After I explicitly enabled the hid_alps module, my touchpad is now working again and, thanks to your patch, can now also be configured. Thanks again! Feel free to add a: Tested-By: Nikolaus Rath <nikol...@r

Re: [PATCH 1/2] Alps HID I2C T4 device support

ever, your patch still prevented hid_generic from taking control of the touchpad. After I explicitly enabled the hid_alps module, my touchpad is now working again and, thanks to your patch, can now also be configured. Thanks again! Feel free to add a: Tested-By: Nikolaus Rath wrote: > Hi, Nikola

Re: [PATCH 1/2] Alps HID I2C T4 device support

nux_kr_rebuild_tool_hid.sh /build DebugSrc > > After that Touchpad all features should work. > If Touchpad does not work, something error appears on dmesg. > > Best Regards, > Masaki Ota > -Original Message- > From: Nikolaus Rath [mailto:nikol...@rath.org] > S

Re: [PATCH 1/2] Alps HID I2C T4 device support

DebugSrc > > After that Touchpad all features should work. > If Touchpad does not work, something error appears on dmesg. > > Best Regards, > Masaki Ota > -Original Message- > From: Nikolaus Rath [mailto:nikol...@rath.org] > Sent: Wednesday, April 05,

Re: [PATCH 1/2] Alps HID I2C T4 device support

this? Best, -Nikolaus On Apr 04 2017, Masaki Ota <masaki@jp.alps.com> wrote: > Hi, Nikolaus, > > Um, but demesg log does not have any error of this Touchpad. > It's a strange. > > Best Regards, > Masaki Ota > -Original Message- > From: Nikolaus Rath [

Re: [PATCH 1/2] Alps HID I2C T4 device support

this? Best, -Nikolaus On Apr 04 2017, Masaki Ota wrote: > Hi, Nikolaus, > > Um, but demesg log does not have any error of this Touchpad. > It's a strange. > > Best Regards, > Masaki Ota > -Original Message----- > From: Nikolaus Rath [mailto:nikol...@rath.org] > Sen

Re: [PATCH 1/2] Alps HID I2C T4 device support

erface should work properly on Linux. > I tested it on Ubuntu +4.10 kernel. > > If you don't apply my patch, does device work as I2C? (044E:120C appears?) > > Best Regards, > Masaki Ota > -Original Message- > From: Nikolaus Rath [mailto:nikol...@rath.org] > Sent: W

Re: [PATCH 1/2] Alps HID I2C T4 device support

Linux. > I tested it on Ubuntu +4.10 kernel. > > If you don't apply my patch, does device work as I2C? (044E:120C appears?) > > Best Regards, > Masaki Ota > -Original Message- > From: Nikolaus Rath [mailto:nikol...@rath.org] > Sent: Wednesday, April 05, 2017 2

Re: [PATCH 1/2] Alps HID I2C T4 device support

about this. > > If Touchpad does not work completely, there is something an error. > What does dmesg show? > > Best Regards, > Masaki Ota > -Original Message- > From: Nikolaus Rath [mailto:nikol...@rath.org] > Sent: Tuesday, April 04, 2017 12:09 PM > To: 太田 真喜 Mas

Re: [PATCH 1/2] Alps HID I2C T4 device support

Touchpad does not work completely, there is something an error. > What does dmesg show? > > Best Regards, > Masaki Ota > -Original Message- > From: Nikolaus Rath [mailto:nikol...@rath.org] > Sent: Tuesday, April 04, 2017 12:09 PM > To: 太田 真喜 Masaki Ota ; linux-kernel > ;

Re: [PATCH 1/2] Alps HID I2C T4 device support

Hi Ota, > -Support Alps HID I2C T4 Touchpad device. > -Laptop names that use this Touchpad:HP Zbook Studio, Elitebook Folio G1, > Elitebook 1030 G1, Elitebook 1040 G3 > > Signed-off-by: Masaki Ota > --- > drivers/hid/hid-alps.c | 500 >

Re: [PATCH 1/2] Alps HID I2C T4 device support

Hi Ota, > -Support Alps HID I2C T4 Touchpad device. > -Laptop names that use this Touchpad:HP Zbook Studio, Elitebook Folio G1, > Elitebook 1030 G1, Elitebook 1040 G3 > > Signed-off-by: Masaki Ota > --- > drivers/hid/hid-alps.c | 500 > +++-- >

Re: [fuse-devel] fuse: feasible to distinguish between umount and abort?

On Nov 29 2016, Miklos Szeredi <mik...@szeredi.hu> wrote: > On Fri, Nov 25, 2016 at 1:33 AM, Nikolaus Rath <nikol...@rath.org> wrote: >> On Nov 24 2016, Miklos Szeredi <mik...@szeredi.hu> wrote: >>> On Thu, Nov 24, 2016 at 12:11 AM, Nikolaus Rath &

Re: [fuse-devel] fuse: feasible to distinguish between umount and abort?

On Nov 29 2016, Miklos Szeredi wrote: > On Fri, Nov 25, 2016 at 1:33 AM, Nikolaus Rath wrote: >> On Nov 24 2016, Miklos Szeredi wrote: >>> On Thu, Nov 24, 2016 at 12:11 AM, Nikolaus Rath wrote: >>>> Hello, >>>> >>>> Currently, both a

Re: [fuse-devel] fuse: feasible to distinguish between umount and abort?

On Nov 24 2016, Miklos Szeredi <mik...@szeredi.hu> wrote: > On Thu, Nov 24, 2016 at 12:11 AM, Nikolaus Rath <nikol...@rath.org> wrote: >> Hello, >> >> Currently, both a call to umount(2) and writing "1" to >> /sys/fs/fuse/connections/NNN/abort

Re: [fuse-devel] fuse: feasible to distinguish between umount and abort?

On Nov 24 2016, Miklos Szeredi wrote: > On Thu, Nov 24, 2016 at 12:11 AM, Nikolaus Rath wrote: >> Hello, >> >> Currently, both a call to umount(2) and writing "1" to >> /sys/fs/fuse/connections/NNN/abort will put the /dev/fuse fd into the >>

fuse: feasible to distinguish between umount and abort?

Hello, Currently, both a call to umount(2) and writing "1" to /sys/fs/fuse/connections/NNN/abort will put the /dev/fuse fd into the same state: reading from it returns ENODEV, and polling on it returns POLLERR. This causes problems for filesystems that want to ensure that the mountpoint is free

fuse: feasible to distinguish between umount and abort?

Hello, Currently, both a call to umount(2) and writing "1" to /sys/fs/fuse/connections/NNN/abort will put the /dev/fuse fd into the same state: reading from it returns ENODEV, and polling on it returns POLLERR. This causes problems for filesystems that want to ensure that the mountpoint is free

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

Hi Maxim, On Nov 22 2016, Maxim Patlasov wrote: Could someone explain to me the meaning of the max_background and congestion_threshold settings of the fuse module? At first I assumed that max_background specifies the maximum number of

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

Hi Maxim, On Nov 22 2016, Maxim Patlasov wrote: Could someone explain to me the meaning of the max_background and congestion_threshold settings of the fuse module? At first I assumed that max_background specifies the maximum number of pending requests

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

On Nov 16 2016, Maxim Patlasov <mpatla...@virtuozzo.com> wrote: > On 11/16/2016 12:19 PM, Nikolaus Rath wrote: > >> On Nov 16 2016, Maxim Patlasov <mpatla...@virtuozzo.com> wrote: >>> On 11/16/2016 11:19 AM, Nikolaus Rath wrote: >>> >>>> Hi M

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

On Nov 16 2016, Maxim Patlasov wrote: > On 11/16/2016 12:19 PM, Nikolaus Rath wrote: > >> On Nov 16 2016, Maxim Patlasov wrote: >>> On 11/16/2016 11:19 AM, Nikolaus Rath wrote: >>> >>>> Hi Maxim, >>>> >>>> On Nov 15 2016, Maxim

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

On Nov 16 2016, Maxim Patlasov <mpatla...@virtuozzo.com> wrote: > On 11/16/2016 11:19 AM, Nikolaus Rath wrote: > >> Hi Maxim, >> >> On Nov 15 2016, Maxim Patlasov <mpatla...@virtuozzo.com> wrote: >>> On 11/15/2016 08:18 AM, Nikolaus Rath wrote:

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

On Nov 16 2016, Maxim Patlasov wrote: > On 11/16/2016 11:19 AM, Nikolaus Rath wrote: > >> Hi Maxim, >> >> On Nov 15 2016, Maxim Patlasov wrote: >>> On 11/15/2016 08:18 AM, Nikolaus Rath wrote: >>>> Could someone explain to me the meaning of the

commit 5e940c: fuse: handle killpriv in userspace fs

Hi Miklos, In commit 5e940c you introduced a new FUSE_HANDLE_KILLPRIV flag, but as far as I know no corresponding userspace support has landed in libfuse yet. Are you planning to provide a patch? Thanks, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31

commit 5e940c: fuse: handle killpriv in userspace fs

Hi Miklos, In commit 5e940c you introduced a new FUSE_HANDLE_KILLPRIV flag, but as far as I know no corresponding userspace support has landed in libfuse yet. Are you planning to provide a patch? Thanks, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31

commit 0b5da8d: fuse: add support for SEEK_HOLE and SEEK_DATA in lseek

Hi Ravishankar, In commit 0b5da8d you added support for a new FUSE_LSEEK operation. However, as far as I can tell the corresponding userspace code never landed in libfuse. Do you have a corresponding patch for libfuse? Looking at the commit message, I assume this functionality was added

commit 0b5da8d: fuse: add support for SEEK_HOLE and SEEK_DATA in lseek

Hi Ravishankar, In commit 0b5da8d you added support for a new FUSE_LSEEK operation. However, as far as I can tell the corresponding userspace code never landed in libfuse. Do you have a corresponding patch for libfuse? Looking at the commit message, I assume this functionality was added

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

Hi Maxim, On Nov 15 2016, Maxim Patlasov <mpatla...@virtuozzo.com> wrote: > On 11/15/2016 08:18 AM, Nikolaus Rath wrote: >> Could someone explain to me the meaning of the max_background and >> congestion_threshold settings of the fuse module? >> >> At first I assu

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

Hi Maxim, On Nov 15 2016, Maxim Patlasov wrote: > On 11/15/2016 08:18 AM, Nikolaus Rath wrote: >> Could someone explain to me the meaning of the max_background and >> congestion_threshold settings of the fuse module? >> >> At first I assumed that max_background s

fuse: max_background and congestion_threshold settings

Hello, Could someone explain to me the meaning of the max_background and congestion_threshold settings of the fuse module? At first I assumed that max_background specifies the maximum number of pending requests (i.e., requests that have been send to userspace but for which no reply was received

fuse: max_background and congestion_threshold settings

Hello, Could someone explain to me the meaning of the max_background and congestion_threshold settings of the fuse module? At first I assumed that max_background specifies the maximum number of pending requests (i.e., requests that have been send to userspace but for which no reply was received

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 15 2016, Miklos Szeredi <mszer...@redhat.com> wrote: > On Fri, Nov 11, 2016 at 6:27 PM, Nikolaus Rath <nikol...@rath.org> wrote: > >> Yeah, I'd expect most people to do that. But FUSE file systems are often >> a little more exotic and produce error co

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 15 2016, Miklos Szeredi wrote: > On Fri, Nov 11, 2016 at 6:27 PM, Nikolaus Rath wrote: > >> Yeah, I'd expect most people to do that. But FUSE file systems are often >> a little more exotic and produce error conditions that don't match well >> with any

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Mike Marshall wrote: > There was a memorable place in the Orangefs code where > the original programmer did that (pick something appropriate > from errno.h) and put in a comment about how it was a more > reasonable return code... > > When Al Viro saw it, he

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Mike Marshall wrote: > There was a memorable place in the Orangefs code where > the original programmer did that (pick something appropriate > from errno.h) and put in a comment about how it was a more > reasonable return code... > > When Al Viro saw it, he said it was: > > ...

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Mike Marshall <hub...@omnibond.com> wrote: > On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath <nikol...@rath.org> wrote: >> On Nov 11 2016, Miklos Szeredi <mszer...@redhat.com> wrote: >>> On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath <nikol.

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Mike Marshall wrote: > On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath wrote: >> On Nov 11 2016, Miklos Szeredi wrote: >>> On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath wrote: >>>> On Nov 11 2016, Miklos Szeredi wrote: >>>>> On

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Miklos Szeredi <mszer...@redhat.com> wrote: > On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath <nikol...@rath.org> wrote: >> On Nov 11 2016, Miklos Szeredi <mszer...@redhat.com> wrote: >>> On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath <n

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Miklos Szeredi wrote: > On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath wrote: >> On Nov 11 2016, Miklos Szeredi wrote: >>> On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath wrote: >>>> Hi Andrew, >>>> >>>> In commit d7afae

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Miklos Szeredi <mszer...@redhat.com> wrote: > On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath <nikol...@rath.org> wrote: >> Hi Andrew, >> >> In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT >> flag. But as far as I can te

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Miklos Szeredi wrote: > On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath wrote: >> Hi Andrew, >> >> In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT >> flag. But as far as I can tell, the flag is simply accepted without >

Re: commit 5c672ab3f0ee0f78f: fuse: serialize dirops by default

On Nov 10 2016, Miklos Szeredi <mszer...@redhat.com> wrote: > On Thu, Nov 10, 2016 at 11:21 PM, Nikolaus Rath <nikol...@rath.org> wrote: >> Hi Miklos, >> >> In commit 5c672ab3f0ee0f78f7acad183f34db0f8781a200 you introduced a new >> FUSE_PARALLEL_DIROPS cap

Re: commit 5c672ab3f0ee0f78f: fuse: serialize dirops by default

On Nov 10 2016, Miklos Szeredi wrote: > On Thu, Nov 10, 2016 at 11:21 PM, Nikolaus Rath wrote: >> Hi Miklos, >> >> In commit 5c672ab3f0ee0f78f7acad183f34db0f8781a200 you introduced a new >> FUSE_PARALLEL_DIROPS capability and bumped the kernel interface no to

commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

Hi Andrew, In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT flag. But as far as I can tell, the flag is simply accepted without having any effect (including in libfuse). I tried to find related later commits, but did not find anything either. Am I missing something? Best,

commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

Hi Andrew, In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT flag. But as far as I can tell, the flag is simply accepted without having any effect (including in libfuse). I tried to find related later commits, but did not find anything either. Am I missing something? Best,

commit 5c672ab3f0ee0f78f: fuse: serialize dirops by default

Hi Miklos, In commit 5c672ab3f0ee0f78f7acad183f34db0f8781a200 you introduced a new FUSE_PARALLEL_DIROPS capability and bumped the kernel interface no to 25 - but there have been no corresponding changes to userspace. Is this still preliminary and thus deliberately not in libfuse? I only noticed

commit 5c672ab3f0ee0f78f: fuse: serialize dirops by default

Hi Miklos, In commit 5c672ab3f0ee0f78f7acad183f34db0f8781a200 you introduced a new FUSE_PARALLEL_DIROPS capability and bumped the kernel interface no to 25 - but there have been no corresponding changes to userspace. Is this still preliminary and thus deliberately not in libfuse? I only noticed

Re: Help with debugging intermittent crash on resume from hibernation

On Apr 17 2015, Mike Galbraith wrote: > On Fri, 2015-04-17 at 20:15 -0700, Nikolaus Rath wrote: >> >> Is there anything I can do to help debug this issue? > > You could try to bisect it, but judging from the problem description, > that could be more like a career than a

Re: Help with debugging intermittent crash on resume from hibernation

On 03/19/2015 08:57 PM, Mike Galbraith wrote: > (+CC) > > On Thu, 2015-03-19 at 20:21 -0700, Nikolaus Rath wrote: >> On Mar 13 2015, Nikolaus Rath wrote: >>> Hello, >>> >>> In about one out of 10 resumes from hibernation, my system resets after >&

Re: Help with debugging intermittent crash on resume from hibernation

On Apr 17 2015, Mike Galbraith umgwanakikb...@gmail.com wrote: On Fri, 2015-04-17 at 20:15 -0700, Nikolaus Rath wrote: Is there anything I can do to help debug this issue? You could try to bisect it, but judging from the problem description, that could be more like a career than

Re: Help with debugging intermittent crash on resume from hibernation

On 03/19/2015 08:57 PM, Mike Galbraith wrote: (+CC) On Thu, 2015-03-19 at 20:21 -0700, Nikolaus Rath wrote: On Mar 13 2015, Nikolaus Rath nikol...@rath.org wrote: Hello, In about one out of 10 resumes from hibernation, my system resets after the hibernation image has been loaded. I am

Re: Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

On Mar 26 2015, Chris Murphy wrote: > On Thu, Mar 26, 2015 at 6:38 PM, Nikolaus Rath wrote: > >> I'm running 4.0-rc3, and I'm regularly getting these warnings in my >> kernel log: > >> Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: >&g

Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

Hello, I'm running 4.0-rc3, and I'm regularly getting these warnings in my kernel log: Mar 26 17:31:13 vostro kernel: [21480.088671] [ cut here ] Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: 28958 at fs/btrfs/inode.c:8693

Re: Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

On Mar 26 2015, Chris Murphy li...@colorremedies.com wrote: On Thu, Mar 26, 2015 at 6:38 PM, Nikolaus Rath nikol...@rath.org wrote: I'm running 4.0-rc3, and I'm regularly getting these warnings in my kernel log: Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: 28958 at fs

Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

Hello, I'm running 4.0-rc3, and I'm regularly getting these warnings in my kernel log: Mar 26 17:31:13 vostro kernel: [21480.088671] [ cut here ] Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: 28958 at fs/btrfs/inode.c:8693

Re: Help with debugging intermittent crash on resume from hibernation

On Mar 13 2015, Nikolaus Rath wrote: > Hello, > > In about one out of 10 resumes from hibernation, my system resets after > the hibernation image has been loaded. I am hibernating using > > # echo platform > /sys/power/disk > # echo disk > /sys/power/state > &g

Re: Help with debugging intermittent crash on resume from hibernation

On Mar 13 2015, Nikolaus Rath nikol...@rath.org wrote: Hello, In about one out of 10 resumes from hibernation, my system resets after the hibernation image has been loaded. I am hibernating using # echo platform /sys/power/disk # echo disk /sys/power/state When testing hibernation using

Help with debugging intermittent crash on resume from hibernation

Hello, In about one out of 10 resumes from hibernation, my system resets after the hibernation image has been loaded. I am hibernating using # echo platform > /sys/power/disk # echo disk > /sys/power/state When testing hibernation using # echo core > /sys/power/pm_test # echo platform >

Help with debugging intermittent crash on resume from hibernation

Hello, In about one out of 10 resumes from hibernation, my system resets after the hibernation image has been loaded. I am hibernating using # echo platform /sys/power/disk # echo disk /sys/power/state When testing hibernation using # echo core /sys/power/pm_test # echo platform