public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Jiri Slaby <jslaby@suse.cz>, gregkh@linuxfoundation.org
Cc: jirislaby@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] TTY: tty_buffer, warn on leaks
Date: Tue, 26 Nov 2013 20:13:36 -0500	[thread overview]
Message-ID: <52954740.5030801@hurleysoftware.com> (raw)
In-Reply-To: <528164AA.4070300@hurleysoftware.com>

On 11/11/2013 06:13 PM, Peter Hurley wrote:
> On 11/11/2013 03:05 PM, Jiri Slaby wrote:
>> When we leak something, warn about that. For that we need to account
>> the memory used also in the free_all method. It is handled elsewhere
>> correctly.
>
> Hi Jiri,
>
> Good idea.
>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> ---
>>   drivers/tty/tty_buffer.c | 10 ++++++++--
>>   1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index 5f08c39e76ab..20cb9492dbf8 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++ b/drivers/tty/tty_buffer.c
>> @@ -115,21 +115,27 @@ void tty_buffer_free_all(struct tty_port *port)
>>       struct tty_bufhead *buf = &port->buf;
>>       struct tty_buffer *p, *next;
>>       struct llist_node *llist;
>> +    int zero = 0;
>>
>>       while ((p = buf->head) != NULL) {
>>           buf->head = p->next;
>> +        atomic_sub(p->size, &buf->memory_used);
>
> buf->memory_used doesn't need to be treated atomically here,
> and doing so implies that it's necessary.
>
> Accumulating p->size in a non-atomic local is probably better.
>
>>           if (p->size > 0)
>>               kfree(p);
>>       }
>>       llist = llist_del_all(&buf->free);
>> -    llist_for_each_entry_safe(p, next, llist, free)
>> +    llist_for_each_entry_safe(p, next, llist, free) {
>> +        atomic_sub(p->size, &buf->memory_used);
>
> Same here.

Sorry, I forgot:  the buffers on the free list have already been
accounted for in tty_buffer_free() so don't form part of the
buf->mem_used total.

The buffer memory accounting was like that in 3.7 so I left it in.

static void tty_buffer_free(struct tty_port *port, struct tty_buffer *b)
{
	struct tty_bufhead *buf = &port->buf;

	/* Dumb strategy for now - should keep some stats */
	WARN_ON(atomic_sub_return(b->size, &buf->mem_used) < 0);

	if (b->size > MIN_TTYB_SIZE)
		kfree(b);
	else if (b->size > 0)
		llist_add(&b->free, &buf->free);
}

Regards,
Peter Hurley


      reply	other threads:[~2013-11-27  1:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11 20:05 [PATCH 1/1] TTY: tty_buffer, warn on leaks Jiri Slaby
2013-11-11 23:13 ` Peter Hurley
2013-11-27  1:13   ` Peter Hurley [this message]

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=52954740.5030801@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox