[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fw: [PATCH] sort: Add --threads option, which parallelizes internal sort
From: |
Chen Guo |
Subject: |
Fw: [PATCH] sort: Add --threads option, which parallelizes internal sort. |
Date: |
Mon, 19 Oct 2009 21:35:05 -0700 (PDT) |
Forgot to cc the mailing list:
----- Forwarded Message ----
From: Chen Guo <address@hidden>
To: Jim Meyering <address@hidden>
Sent: Monday, October 19, 2009 9:25:15 PM
Subject: Re: [PATCH] sort: Add --threads option, which parallelizes internal
sort.
Oooh one thing that got lost amongst the git problems I was having:
In the function sortlines, this line:
if (nlines < 200)
Should be:
/* 10000 is a guess. The goal is to prevent exploitation of predictable
pivot selection by attackers. */
if (nlines < 10000)
200 was a ridiculously low first guess, and upping this to 10,000 improves
performance greatly. The idea is with further experimentation this value can be
adjusted. In the case an attacker manages to sort a file that reduces the
quicksort algorithm to n^2, I imagine it would still take many more lines than
10,000 to successfully carry out a DoS attack.
----- Original Message ----
From: Jim Meyering <address@hidden>
To: Chen Guo <address@hidden>
Cc: Bug Coreutils <address@hidden>
Sent: Sunday, October 18, 2009 10:31:51 PM
Subject: Re: [PATCH] sort: Add --threads option, which parallelizes internal
sort.
Chen Guo wrote:
> Ah how ridiculously careless of me. >.<
>
> I've ran through the checklist you provided, minus the mallocs.
Thanks!
> When would it be not ok to exit upon malloc failure? I've ran through all of
> sort.c and it seems in all cases of memory allocation xmalloc or xnmalloc are
> used. Thanks!
It's inappropriate in library-style code, and sort.c is not that,
so using x*alloc is all you need to do.