Hi,
On 04/05/2014 08:24 PM, KOSAKI Motohiro wrote:
On Fri, Apr 4, 2014 at 1:00 AM, Davidlohr Bueso <davidlohr@xxxxxx> wrote:
I don't think it makes much sense to set unlimited for both 0 and
ULONG_MAX, that would probably just create even more confusion.
I agree.
Unlimited was INT_MAX since 0.99.10 and ULONG_MAX since 2.3.39 (with
proper backward compatibility for user space).
Adding a second value for unlimited just creates confusion.
But then again, we shouldn't even care about breaking things with shmmax
or shmall with 0 value, it just makes no sense from a user PoV. shmmax
cannot be 0 unless there's an overflow, which voids any valid cases, and
thus shmall cannot be 0 either as it would go against any values set for
shmmax. I think it's safe to ignore this.
Agreed.
IMHO, until you find out any incompatibility issue of this, we don't
need the switch
because we can't make good workaround for that. I'd suggest to merge your patch
and see what happen.
I disagree:
- "shmctl(,IPC_INFO,&buf); if (my_memory_size > buf.shmmax)
perror("change shmmax");" worked correctly since 0.99.10. I don't think
that merging the patch and seeing what happens is the right approach.
- setting shmmax by default to ULONG_MAX is the perfect workaround.
What reasons are there against the one-line patch?
>
> -#define SHMMAX 0x2000000 /* max shared seg size
(bytes) */
> +#define SHMMAX ULONG_MAX /* max shared seg size
(bytes) */
>
--
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>