linux-kernel - RE: [PATCH] fs/ceph/io: make ceph_start_io

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <caf3a8455673bc602194c702de9b1013722ce4a2.camel@ibm.com>
Date: Mon, 9 Dec 2024 18:59:51 +0000
From: Viacheslav Dubeyko <Slava.Dubeyko@....com>
To: "max.kellermann@...os.com" <max.kellermann@...os.com>
CC: "idryomov@...il.com" <idryomov@...il.com>,
        Alex Markuze
	<amarkuze@...hat.com>,
        "ceph-devel@...r.kernel.org"
	<ceph-devel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        Xiubo Li <xiubli@...hat.com>
Subject: RE: [PATCH] fs/ceph/io: make ceph_start_io_*() killable

On Fri, 2024-12-06 at 23:48 +0100, Max Kellermann wrote:
> On Fri, Dec 6, 2024 at 8:11 PM Viacheslav Dubeyko
> <Slava.Dubeyko@....com> wrote:
> > Should be the check of
> > this function's output mandatory? I am not fully sure.
> 
> But I am fully sure.
> If you don't check the return value, you don't know whether the inode
> was locked. If you don't know that, you can't decide whether you need
> to unlock it. That being optional now (cancel locking if SIGKILL was
> received) is the sole point of my patch. You MUST check the return
> value. There is no other way. Don't trust my word - just read the
> code.


The down_write_killable() can return -EINTR, currently:
https://elixir.bootlin.com/linux/v6.12.4/source/kernel/locking/rwsem.c#L1593

And -EINTR can imply that client has been killed:
https://elixir.bootlin.com/linux/v6.12.4/source/include/uapi/asm-generic/errno-base.h#L8

It sounds to me that we simply need not to execute the logic. But do we
really need to report
the error to the caller? I am simply trying to double check that
caller's logic is ready
to process the error condition in the correct way.

Thanks,
Slava.