linux-kernel - Re: [PATCH] increase pipe size/buffers/atomicity :D

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]

Date:	Thu, 08 Apr 2010 10:14:47 -0500
From:	"Steven J. Magnani" <steve@...idescorp.com>
To:	brian <knotwurk@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] increase pipe size/buffers/atomicity :D

Brian -

On Wed, 2010-04-07 at 19:38 -0600, brian wrote:
> (tested and working with 2.6.32.8 kernel, on a Athlon/686)

It would be good to know what issue this addresses. Gives people a way
to weigh any side-effects/drawbacks against the benefits, and an
opportunity to suggest alternate/better approaches.

> --- include/linux/pipe_fs_i.h.orig      2010-04-06 22:56:51.000000000 -0500
> +++ include/linux/pipe_fs_i.h   2010-04-06 22:56:58.000000000 -0500
> @@ -3,7 +3,7 @@
> 
>  #define PIPEFS_MAGIC 0x50495045
> 
> -#define PIPE_BUFFERS (16)
> +#define PIPE_BUFFERS (32)

This worries me. In several places there are functions with 2 or 3
pointer arrays of dimension [PIPE_BUFFERS] on the stack. So this adds
anywhere from 128 to 384 bytes to the stack in these functions depending
on sizeof(void*) and the number of arrays.

> 
>  #define PIPE_BUF_FLAG_LRU      0x01    /* page is on the LRU */
>  #define PIPE_BUF_FLAG_ATOMIC   0x02    /* was atomically mapped */
> --- include/asm-generic/page.h.orig     2010-04-06 22:57:08.000000000 -0500
> +++ include/asm-generic/page.h  2010-04-06 22:57:23.000000000 -0500
> @@ -12,7 +12,7 @@
> 
>  /* PAGE_SHIFT determines the page size */
> 
> -#define PAGE_SHIFT     12
> +#define PAGE_SHIFT     13

This has pretty wide-ranging implications, both within and across
arches. I don't think it's something that can be changed easily. Also I
don't believe this #define used in your configuration (Athlon/686)
unless you're running without a MMU.

>  #ifdef __ASSEMBLY__
>  #define PAGE_SIZE      (1 << PAGE_SHIFT)
>  #else
> --- include/linux/limits.h.orig 2010-04-06 22:54:15.000000000 -0500
> +++ include/linux/limits.h      2010-04-06 22:56:28.000000000 -0500
> @@ -10,7 +10,7 @@
>  #define MAX_INPUT        255   /* size of the type-ahead buffer */
>  #define NAME_MAX         255   /* # chars in a file name */
>  #define PATH_MAX        4096   /* # chars in a path name including nul */
> -#define PIPE_BUF        4096   /* # bytes in atomic write to a pipe */
> +#define PIPE_BUF        8192   /* # bytes in atomic write to a pipe */

I don't see this being used within the kernel, so I assume its a
userspace representation of PAGE_SIZE (ARM seems to associate these
explicitly). I would think you'd need to rebuild your glibc or
equivalent to notice any difference from a change.

Regards,
------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"

 #include <standard.disclaimer>

--
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/