Bug#970639: ZSWAP still considered experimental?

On Tue, 31 May 2022 10:41:05 +0200 Diederik de Haas wrote: > In https://bugs.debian.org/970639 the request was made to enable ZSWAP. > > Upon it was (rightly) noted that zswap.rst contained this: > > Zswap is a new feature as of v3.11 and interacts heavily with memory > > reclaim. This interac

Bug#695182: [PATCH] MAX_PAUSE to be at least 4

On Mon, 21 Jan 2013 14:07:34 +1100 paul.sz...@sydney.edu.au wrote: > Ensure MAX_PAUSE is 4 or larger, so limits in > return clamp_val(t, 4, MAX_PAUSE); > (the only use of it) are not back-to-front. MAX_PAUSE is not used in this fashion in current kernels. > (This patch does not solve the P

Bug#695182: [PATCH] Subtract min_free_kbytes from dirtyable memory

some such > sysctl values. urgh, not that way. Let's do it properly: From: Andrew Morton Subject: page-writebackc-subtract-min_free_kbytes-from-dirtyable-memory-fix fix up min_free_kbytes extern declarations Cc: Paul Szabo Cc: Rik van Riel Cc: Wu Fengguang Signed-off-by: Andrew Morto

Bug#695182: [RFC] Reproducible OOM with partial workaround

On Fri, 11 Jan 2013 22:51:35 +1100 paul.sz...@sydney.edu.au wrote: > Dear Andrew, > > > Check /proc/slabinfo, see if all your lowmem got eaten up by buffer_heads. > > Please see below: I do not know what any of that means. This machine has > been running just fine, with all my users logging in h

Bug#695182: [RFC] Reproducible OOM with partial workaround

On Fri, 11 Jan 2013 12:46:15 +1100 paul.sz...@sydney.edu.au wrote: > > ... I don't believe 64GB of RAM has _ever_ been booted on a 32-bit > > kernel without either violating the ABI (3GB/1GB split) or doing > > something that never got merged upstream ... > > Sorry to be so contradictory: > > ps

Bug#504391: [PATCH] mmc: add module parameter to set whether cards are assumed removable

On Wed, 11 Nov 2009 04:44:36 + Ben Hutchings wrote: > Some people run general-purpose distribution kernels on netbooks with > a card that is physically non-removable or logically non-removable > (e.g. used for /home) and cannot be cleanly unmounted during suspend. > Add a module parameter to

Bug#550010: [PATCH] hfsplus: Refuse to mount volumes larger than 2TB

On Sun, 11 Oct 2009 03:11:27 +0100 Ben Hutchings wrote: > As found in , hfsplus is using type u32 > rather than sector_t for some sector number calculations. > > In particular, hfsplus_get_block() does: > > u32 ablock, dblock, mask; > ... > map_bh(

Re: asm-{alpha,h8300,um,v850,xtensa}/param.h: unbreak HZ for userspace

On Wed, 14 May 2008 13:05:31 +0200 maximilian attems <[EMAIL PROTECTED]> wrote: > without it currently perl 5.10 doesn't build on alpha: > perl.c: In function 'perl_construct': > perl.c:388: error: 'CONFIG_HZ' undeclared (first use in this function) > -> > http://buildd.debian.org/fetch.cgi?pkg=p

Re: [Bugme-new] [Bug 8028] New: capi_{cmsg,message}2str not thread-safe; vulnerable to buffer overflow

(cc's restored. Please don't do that) On Sat, 17 Feb 2007 23:30:35 + Ben Hutchings <[EMAIL PROTECTED]> wrote: > On Sat, 2007-02-17 at 14:49 -0800, Andrew Morton wrote: > > On Sat, 17 Feb 2007 13:03:02 -0800 [EMAIL PROTECTED] wrote: > > > > > http://

Bug#356458: [EMAIL PROTECTED]: Re: Bug#356458: linux-2.6: please include bigphysarea patch]

Ryan Underwood <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 25, 2006 at 12:38:11AM -0700, Andrew Morton wrote: > > > > We already have infrastructure for managing and allocating large > > physically-contiguous hunks of memory: arch/*/mm/hugetlb.c. On x86 that &

Bug#356458: [EMAIL PROTECTED]: Re: Bug#356458: linux-2.6: please include bigphysarea patch]

Ryan Underwood <[EMAIL PROTECTED]> wrote: > > > On Mon, Apr 24, 2006 at 09:09:39PM -0700, Andrew Morton wrote: > > > > I don't know what to suggest, really. I don't think that adding complexity > > to MM to support rare and broken hardware is likely t

Bug#334113: [Security] kernel allows loadkeys to be used by any user, allowing for local root compromise

Horms <[EMAIL PROTECTED]> wrote: > > drivers/char/vt_ioctl.c: vt_ioctl(): line 377 > > /* > * To have permissions to do most of the vt ioctls, we either > * have > * to be the owner of the tty, or have CAP_SYS_TTY_CONFIG. > */ > perm = 0; >

Re: [Prism54-devel] Re: [PATCH 0/14] prism54: bring up to sync with prism54.org cvs rep

Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Luis, you, or somebody should create a new patch series with just the > critical fixes, NO WHITESPACE/FORMATTING CHANGES mixed in, and send > those first. Whitespace changes are often nice, but they should be the very first patch[es] in the series.