linux-kernel - Re: [PATCH] TTY: tty flip buffer change reserve memory strategy.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111025084543.09432276@pyx>
Date:	Tue, 25 Oct 2011 08:45:43 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Ilya Zykov <ilya@...x.ru>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>,
	Alan Cox <alan@...ux.intel.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] TTY: tty flip buffer change reserve memory strategy.

> free(kfree()) every chunk more 256 bytes every time,
> even we have in free buffer enough space, because we can't
> pass through chunk boundary in free buffer. Also we can't limit reserve
> memory size. In worse case we will have in free buffer:
> (256 * 256 byte chunk) = (256 * 552 ) = 141312 byte unused memory.

The idea is to trade off between the devices that need long linear blocks
(mostly for DMA) and devices that don't care - but many of which pass 1
or 2 bytes/irq so want a common buffer.

Most drivers should not be using tty_reserve_room in the first place.

> Also we can limit reserve memory size, but then,
> we will be use kmalloc()-kree() calls on intensive stream from the driver.

kmalloc is very fast anyway so I'd be interested in seeing the drivers
suffering and the profile traces of a real example.

I'm also not sure I agree with the maths - we chunk buffers to 256 byte
boundaries to avoid getting lots of queued buffers of different sizes. We
could in fact I think simplify the code from what we have learned using
it and simply treat the 256 byte buffer case as special rather than 256
and 512 as we do now. That would let us remove the more generic support
for free buffer sizes which is overcomplex and mean we could simply count
the number of 256 byte buffers we have to hand.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/