Re: [PATCH] cifs: handle -EINTR in cifs_setattr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tentatively merged updated version of this patch into cifs-2.6.git
for-next pending more testing and reviews

On Tue, Oct 6, 2020 at 5:22 PM ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
>
> On Tue, Oct 6, 2020 at 8:57 PM Aurélien Aptel <aaptel@xxxxxxxx> wrote:
> >
> > Hi Ronnie,
> >
> > Ronnie Sahlberg <lsahlber@xxxxxxxxxx> writes:
> > > Some calls that set attributes, like utimensat(), are not supposed to return
> > > -EINTR and thus do not have handlers for this in glibc which causes us
> > > to leak -EINTR to the applications which are also unprepared to handle it.
> >
> > EINTR happens when the task receives a signal right?
> >
> > https://www.gnu.org/software/libc/manual/html_node/Interrupted-Primitives.html
> >
> > Given what you said and what the glibc doc reads it seems like the fix
> > should go in glibc. Otherwise we need to care about every single syscall.
>
> glibc have handling for EINTR in most places, but not in for example utimensat()
> because this function is not supposed to be able to return this error.
> Similarly we have functions like chmod and chown that also come into cifs.ko
> via the same entrypoint: cifs_setattr()
> I think all of these "update inode data" are never supposed to be
> interruptible since
> they were classically just updating the in-memory inode and the thread
> would never hit d-state.
>
> Anyway, for these functions EINTR is not a valid return code so I
> think we should take care to not
> return it. Even if we change glibc adn the very very thin wrapper for
> this functions there are applications
> that might call the systemcall directly or via a different c-library.
>
>
> >
> > Cheers,
> > --
> > Aurélien Aptel / SUSE Labs Samba Team
> > GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
> > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
> > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)



-- 
Thanks,

Steve




[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux