All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aurélien Aptel" <aaptel@suse.com>
To: Shyam Prasad N <nspmangalore@gmail.com>
Cc: Pavel Shilovsky <piastryyy@gmail.com>,
	Steve French <smfrench@gmail.com>,
	CIFS <linux-cifs@vger.kernel.org>,
	sribhat.msa@outlook.com
Subject: Re: [PATCH][SMB3] mount.cifs: use SUDO_UID env variable for cruid
Date: Thu, 17 Sep 2020 10:57:39 +0200	[thread overview]
Message-ID: <87wo0slr0c.fsf@suse.com> (raw)
In-Reply-To: <CANT5p=qV6BWojwBET+kYUwJf7tQDFoRtUb8O+pWHrqWMw5e5LQ@mail.gmail.com>

Shyam Prasad N <nspmangalore@gmail.com> writes:
>> This function later forks, so if you allocate before the fork, you need
>> to free in parent and in the child.
>
> Good point.
> I think I'm doing it right though. I allocate all that I need at the beginning.
> And the function always terminates in mount_exit, both for parent and
> child. That is where the allocations are freed.

Ah yes ok

> I know the child will have the options buffer unnecessarily allocated,
> but isn't the code flow simpler this way?
> Please let me know if you see an issue there.

No it's fine I think

> Good catch. This code existed before my changes, and I had noted this
> bug. But forgot it during my changes. :)
> I was actually confused if I should reset after the label, or before the goto.
> After the label is an added overhead in the "happy" code path, so went
> with this. But it does reduce the chances of missing out a reset.
> For now I'll reset options before each goto mount_retry. Please let me
> know if you feel the other approach is better.

I think we can agree that mount.cifs is not performance critical code
but that it should be safe so I think reset after the label is
better. (To be honnest the whole function could use some refactoring and
be split up probably, but that can be a patch for later on)

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)

  reply	other threads:[~2020-09-17  9:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16 10:00 [PATCH][SMB3] mount.cifs: use SUDO_UID env variable for cruid Shyam Prasad N
2020-09-16 10:56 ` Aurélien Aptel
2020-09-16 16:17   ` Shyam Prasad N
2020-09-17  8:57     ` Aurélien Aptel [this message]
2020-09-17  9:11       ` Shyam Prasad N
2020-09-17 10:13         ` Aurélien Aptel
2020-09-21  3:50           ` Shyam Prasad N
2020-09-21  8:19             ` Aurélien Aptel
2020-11-09 23:43               ` Pavel Shilovsky
2020-11-27 10:24                 ` Shyam Prasad N
2020-12-09 19:32                   ` Pavel Shilovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wo0slr0c.fsf@suse.com \
    --to=aaptel@suse.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=nspmangalore@gmail.com \
    --cc=piastryyy@gmail.com \
    --cc=smfrench@gmail.com \
    --cc=sribhat.msa@outlook.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.