On 1/6/2021 2:33 AM, Greg KH wrote:
On Tue, Jan 05, 2021 at 05:00:58PM -0800, Siddharth Gupta wrote:
On 1/4/2021 10:36 PM, Greg KH wrote:
On Mon, Jan 04, 2021 at 02:43:45PM -0800, Siddharth Gupta wrote:
Hi all,
With the introduction of the filesystem change "fs: don't allow splice
read/write without explicit ops"[1] the fallback mechanism of the firmware
loader[2] no longer works when using sendfile[3] from the userspace.
What userspace program are you using to load firmware?
The userspace program is in the android userspace which listens to a uevent
from the firmware loader and then loads the firmware using sendfile[1].
Are you not using the in-kernel firmware loader for some reason?
We have certain non-standard firmware paths that should not be added to the
linux kernel, and the firmware_class.path only supports a single path.
That option is just for a single override, which should be all that you
need if the other paths that are built into the kernel do not work.
Surely one of the 5 different paths here are acceptable?
Unfortunately they are not, and we understand that such changes
shouldn't make it to upstream hence it was not a part of the request. If
the firmware loader fallback mechanism was being deprecated then we
would have to look into our options. As of now the series of changes
breaking the sysfs bin attributes is the only bug that affects us.
If not, how many more do you need?
We need 2 paths.
And last I looked, Android wants you to use the built-in kernel firmware
loader, and NOT an external firmware binary anymore. So this shouldn't
be an issue for your newer systems anyway :)
In our discussion with the Android team that is not the case currently.
In the future yes, but not now :)
Regardless this bug is in the kernel and not Android. If the firmware
loader fallback mechanism is used on the current kernel we would see the
issue with sendfile in the userspace whether Android is running or not.
Since the binary attributes don't support splice_{read,write} functions the
calls to splice_{read,write} used the default kernel_{read,write} functions.
With the above change this results in an -EINVAL return from
do_splice_from[4].
This essentially means that sendfile will not work for any binary attribute
in the sysfs.
Have you tried fixing this with a patch much like what we did for the
proc files that needed this? If not, can you?
I am not aware of this fix, could you provide me a link for reference? I
will try it out.
Look at the series of commits starting at fe33850ff798 ("proc: wire up
generic_file_splice_read for iter ops") for how this was fixed in procfs
as an example of what also needs to be done for binary sysfs files.
I tried to follow these fixes, but I am unfamiliar with fs code. I don't
see the generic_file_splice_write function anymore on newer kernels,
also AFAICT kernfs_ops does not define {read,write}_iter operations. If
the solution is simple and someone could provide the patches I would be
happy to test them out. If not, some more information about how to
proceed would be nice.
Thanks,
Sid
thanks,
greg k-h
