Fw: [PATCH] sort: Add --threads option, which parallelizes internal sort.

[Chen Guo]

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.