All of lore.kernel.org
 help / color / mirror / Atom feed
From: "xinhui.pan" <xinhuix.pan@intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>,
	linux-kernel@vger.kernel.org, "Zhang,
	Yanmin" <yanmin_zhang@linux.intel.com>, mnipxh <mnipxh@gmail.com>,
	Peter Hurley <peter@hurleysoftware.com>,
	gnomes@lxorguk.ukuu.org.uk
Subject: Re: [PATCH] tty/n_gsm.c: do not clear gsm_mux entry when the gsm is not closed
Date: Mon, 28 Jul 2014 15:16:25 +0800	[thread overview]
Message-ID: <53D5F8C9.4070008@intel.com> (raw)
In-Reply-To: <20140727180953.GA7232@kroah.com>

hi, Greg

于 2014年07月28日 02:09, Greg Kroah-Hartman 写道:
> On Thu, Jul 24, 2014 at 05:17:01PM +0800, xinhui.pan wrote:
>> If the gsmtty is still used by some process, we could not just
>> simply clear gsm_mux[gsm->num]. Clear it when gsm is being free.
>> Otherwise we will hit crashes when userspace close the gsmtty.
>>
>> Also add gsm_mux_get() and gsm_mux_put() to make gsm_mux[] is used safely.
>> We can do activation/deactivation with same gsm more than once now.
>> This is for fixing the FIXME.
>>
>> Signed-off-by: xinhui.pan <xinhuiX.pan@intel.com>
>> Reviewed-by: Zhang Yanmin <yanmin_zhang@linux.intel.com>
>> ---
>>  drivers/tty/n_gsm.c |   84 ++++++++++++++++++++++++++++++++++++---------------
>>  1 file changed, 60 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
>> index 81e7ccb..290df56 100644
>> --- a/drivers/tty/n_gsm.c
>> +++ b/drivers/tty/n_gsm.c
>> @@ -2020,6 +2020,58 @@ static void gsm_error(struct gsm_mux *gsm,
>>  }
>>  
>>  /**
>> + *	gsm_mux_get		-	get/fill one entry in gsm_mux
>> + *	@gsm: our gsm
>> + *
>> + *	Although its name end with get, it don't inc ref-count actually.
> 
> Then don't call it a 'get' function :(
> 

Thanks for you nice advices!
I will change its name. This is really a confusable name.

>> + *	get one entry is just like fill pte, first memory access will
>> + *	cause page_fault, the next accesses don't. So do here.
> 
> This doesn't make much sense to me, can you please explain it better?
> 
>> + */
>> +
> 
> blank line?
> 

Sorry about that. But I notice the other function's introduce in n_gsm.c is done in same way.
I just wanted to keep same code style.
OK, I will change it.
I think no blank line is better. :)

>> +static int gsm_mux_get(struct gsm_mux *gsm)
>> +{
>> +	int i;
>> +
>> +	if (gsm->num >= MAX_MUX) /* gsm is alloc by kzalloc, just be careful */
>> +		return -EIO;
> 
> -EIO?
> 

Thanks for pointing out the mistake.
perhaps -EINVAL is better.

>> +	if (gsm_mux[gsm->num] == gsm) /* We have already set gsm->num */
>> +		return 0;
>> +
>> +	spin_lock(&gsm_mux_lock);
>> +	for (i = 0; i < MAX_MUX; i++) {
>> +		if (gsm_mux[i] == NULL) {
>> +			gsm->num = i;
>> +			gsm_mux[i] = gsm;
>> +			break;
>> +		}
>> +	}
>> +	spin_unlock(&gsm_mux_lock);
>> +
>> +	if (i == MAX_MUX)
>> +		return -EBUSY;
>> +	return 0;
>> +}
>> +
>> +/**
>> + *	gsm_mux_put		-	put/clear one entry in gsm_mux
>> + *	@gsm: our gsm
>> + *
>> + *	Although its name end with put, it don't dec ref-count actually.
>> + *	put one entry is just like clear pte, So do here.
>> + */
>> +
>> +static void gsm_mux_put(struct gsm_mux *gsm)
>> +{
>> +	if (gsm->num >= MAX_MUX)
>> +		return;
>> +
>> +	spin_lock(&gsm_mux_lock);
>> +	if (gsm_mux[gsm->num] == gsm)
> 
> How can this not be true?

That is a big problem. let me explain it.

In current code, we add gsm into gsm_mux[] in gsm_activate_mux(). So if gsm_activate_mux() fails when gsm_mux[] is full, gsm->num is invaild, it is zero in fact.
So when will free this gsm, we have to check if gsm_mux[gsm->num] is really the one we are deleting.
The scenario is like below.
gsmld_open -> gsmld_attach_gsm -> gsm_activate_mux(fails) -> .... -> mux_put -> gsm_free_muxr -> gsm_mux_put(need check gsm_mux[gsm->num] == gsm).

Current code is a little hard to understand, So I suggest that move the *codes that changes gsm_mux[]* into gsm_alloc_mux(), then we don't need this check anymore.
Actually I have worked out a new patch with such idea.
And I am doing the normal tests set up by Intel test team and other trigger tests set up by myself. :)

> 
>> +		gsm_mux[gsm->num] = NULL;
>> +	spin_unlock(&gsm_mux_lock);
>> +}
> 
> Why can't you do dynamic reference counting of your structure, that
> would allow you to get rid of your global array, right?
> 

Thanks for your nice comments.
Struct gsm has a ref-count already. :)
And also adding a ref-count is a little hard to me. :(
This global array is used to keep tracking the gsms that stands for the gsmttyXX.
and it can tell us if we can create a new gsm. :)
In gsm_init we set *gsm_tty_driver = alloc_tty_driver(256);*

thanks,

xinhui

> thanks,
> 
> greg k-h
> 

Your reply really helps us a lot.
thanks,

xinhui


  reply	other threads:[~2014-07-28  7:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-24  9:17 [PATCH] tty/n_gsm.c: do not clear gsm_mux entry when the gsm is not closed xinhui.pan
2014-07-27 18:09 ` Greg Kroah-Hartman
2014-07-28  7:16   ` xinhui.pan [this message]
2014-07-28 15:13     ` Greg Kroah-Hartman
2014-10-09 19:01       ` Peter Hurley
2014-10-09 19:13         ` Greg Kroah-Hartman
2014-10-09 19:23           ` Peter Hurley
2014-10-09 19:30             ` Greg Kroah-Hartman
2014-10-09 21:49             ` One Thousand Gnomes

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=53D5F8C9.4070008@intel.com \
    --to=xinhuix.pan@intel.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mnipxh@gmail.com \
    --cc=peter@hurleysoftware.com \
    --cc=yanmin_zhang@linux.intel.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.