, this will be cleaned up in the next patch.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/ipc/sem.c b/ipc/sem.c
index 5749b9c..dc648f8 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1047,6 +1047,16 @@ static int
.
The series got fairly long, because I also noticed that semzcnt was calculated
incorrectly.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
INT_MAX;
^^
This code should handle MSG_NOERROR:
If MSG_NOERROR is set, then maxsize is set to INT_MAX, therefore -E2BIG
should never be returned.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
On 05/13/2014 10:27 PM, Davidlohr Bueso wrote:
Nothing big and no logical changes, just get rid of some
redundant function declarations. Move msg_[init/exit]_ns
down the end of the file.
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
---
ipc/msg.c | 132
On 05/13/2014 10:27 PM, Davidlohr Bueso wrote:
Call __set_current_state() instead of assigning
the new state directly.
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
---
ipc/msg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
On 05/13/2014 10:27 PM, Davidlohr Bueso wrote:
Call __set_current_state() instead of assigning
the new state directly.
Signed-off-by: Davidlohr Bueso davidl...@hp.com
Signed-off-by: Manfred Spraul manf...@colorfullif.com
---
ipc/msg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
On 05/13/2014 10:27 PM, Davidlohr Bueso wrote:
Nothing big and no logical changes, just get rid of some
redundant function declarations. Move msg_[init/exit]_ns
down the end of the file.
Signed-off-by: Davidlohr Bueso davidl...@hp.com
Signed-off-by: Manfred Spraul manf...@colorfullife.com
;
^^
This code should handle MSG_NOERROR:
If MSG_NOERROR is set, then maxsize is set to INT_MAX, therefore -E2BIG
should never be returned.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
kling
BUG_ONs in the kernel I'm not sure we want this. Yes, all those calls
are correct from a logical pov and should never occur, however, would
WARN be more suitable instead? I don't know.
Well, this BUG_ON is so old that a decent approach would be to just
delete the thing, if only Manfred wasn't changin
messages.
Worst case scenario, we should update the msgsnd(2) manpage and document
this unique Linux behavior.
I would document the current behavior.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
that it is related to MSGTQL:
http://fxr.watson.org/fxr/source/common/os/msg.c?v=OPENSOLARIS;im=bigexcerpts#L652
I.e.: We cannot remove the check unless we add another mechanism that
limits the number of messages.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-k
messages.
Worst case scenario, we should update the msgsnd(2) manpage and document
this unique Linux behavior.
I would document the current behavior.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
BUG_ONs in the kernel I'm not sure we want this. Yes, all those calls
are correct from a logical pov and should never occur, however, would
WARN be more suitable instead? I don't know.
Well, this BUG_ON is so old that a decent approach would be to just
delete the thing, if only Manfred wasn't changing
that it is related to MSGTQL:
http://fxr.watson.org/fxr/source/common/os/msg.c?v=OPENSOLARIS;im=bigexcerpts#L652
I.e.: We cannot remove the check unless we add another mechanism that
limits the number of messages.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Hi Davidlohr,
On 05/12/2014 08:11 PM, Davidlohr Bueso wrote:
On Sat, 2014-05-10 at 12:03 +0200, Manfred Spraul wrote:
GETZCNT is supposed to return the number of threads that wait until
a semaphore value becomes 0.
The current implementation overlooks complex operations that contain
both wait
Hello,
Excuse me for this way to contact you, I just saw your profile and I
said you're the one I need. In short my name is Manfred EGGERT French
origin and I live in Germany. I suffer from a serious illness which
condemns me to certain death is throat cancer, and I have a large sum
of 22.7
?
Best Regards
Manfred
--
: Manfred Ostermann
: Senior Sales & Marketing Manager
: LINBIT | Your Way to High Availability
: Tel: +43-1-8178292-54, Fax: +43-1-8178292-82
:
: http://www.linbit.at
: http://www.xing.com/profile/Manfred_Ostermann
DRBD® and LINBIT® are registered trademarks of LI
you can help us?
Best Regards
Manfred
--
: Manfred Ostermann
: Senior Sales Marketing Manager
: LINBIT | Your Way to High Availability
: Tel: +43-1-8178292-54, Fax: +43-1-8178292-82
:
: http://www.linbit.at
: http://www.xing.com/profile/Manfred_Ostermann
DRBD® and LINBIT® are registered
Hello,
Excuse me for this way to contact you, I just saw your profile and I
said you're the one I need. In short my name is Manfred EGGERT French
origin and I live in Germany. I suffer from a serious illness which
condemns me to certain death is throat cancer, and I have a large sum
of 22.7
Hi Davidlohr,
On 05/12/2014 08:11 PM, Davidlohr Bueso wrote:
On Sat, 2014-05-10 at 12:03 +0200, Manfred Spraul wrote:
GETZCNT is supposed to return the number of threads that wait until
a semaphore value becomes 0.
The current implementation overlooks complex operations that contain
both wait
Hi Davidlohr,
On 05/12/2014 01:34 AM, Davidlohr Bueso wrote:
On Sat, 2014-05-10 at 12:03 +0200, Manfred Spraul wrote:
Somehow $ was overlooked in the last round of whitespace
cleanups.
Do that now, before making further changes.
No big deal, but this patch could easily be included
Hi Michael,
On 05/12/2014 10:02 AM, Michael Kerrisk (man-pages) wrote:
Hi Manfred,
On Sat, May 10, 2014 at 12:03 PM, Manfred Spraul
wrote:
Hi all,
According to the man page of semop(), semzcnt or semncnt are increased
exactly for the operation that couldn't proceed.
Perhaps it's woth
Hi Michael,
On 05/12/2014 10:02 AM, Michael Kerrisk (man-pages) wrote:
Hi Manfred,
On Sat, May 10, 2014 at 12:03 PM, Manfred Spraul
manf...@colorfullife.com wrote:
Hi all,
According to the man page of semop(), semzcnt or semncnt are increased
exactly for the operation that couldn't proceed
Hi Davidlohr,
On 05/12/2014 01:34 AM, Davidlohr Bueso wrote:
On Sat, 2014-05-10 at 12:03 +0200, Manfred Spraul wrote:
Somehow TAB$ was overlooked in the last round of whitespace
cleanups.
Do that now, before making further changes.
No big deal, but this patch could easily be included
, this will be cleaned up in the next patch.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/ipc/sem.c b/ipc/sem.c
index 5749b9c..dc648f8 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1047,6 +1047,16 @@ static int count_semzcnt(struct sem_array
GETNCNT or GETZCNT?
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
count_semzcnt and count_semncnt are more of less identical.
The patch creates a single function that either counts the number of tasks
waiting for zero or waiting due to a decrease operation.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 103
Preparation for the next patch:
In the slow-path of perform_atomic_semop(), store a pointer to the operation
that caused the operation to block.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ipc/sem.c b/ipc/sem.c
index 3962cca..22a4c12 100644
Right now, perform_atomic_semop gets the content of sem_queue as individual
fields.
Changes that, instead pass a pointer to sem_queue.
This is a preparation for the next patch: it uses
sem_queue to store the reason why a task must sleep.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 38
Somehow $ was overlooked in the last round of whitespace
cleanups.
Do that now, before making further changes.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index bee5554..5749b9c 100644
--- a/ipc
:
The implementation assumes that GETNCNT and GETZCNT are rare operations,
therefore the code counts them only on demand.
(If they wouldn't be rare, then the non-compliance would have
been found earlier)
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 37 -
1 file
Somehow TAB$ was overlooked in the last round of whitespace
cleanups.
Do that now, before making further changes.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index bee5554
:
The implementation assumes that GETNCNT and GETZCNT are rare operations,
therefore the code counts them only on demand.
(If they wouldn't be rare, then the non-compliance would have
been found earlier)
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 37
Right now, perform_atomic_semop gets the content of sem_queue as individual
fields.
Changes that, instead pass a pointer to sem_queue.
This is a preparation for the next patch: it uses
sem_queue to store the reason why a task must sleep.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
Preparation for the next patch:
In the slow-path of perform_atomic_semop(), store a pointer to the operation
that caused the operation to block.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ipc/sem.c b/ipc/sem.c
index
GETNCNT or GETZCNT?
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
count_semzcnt and count_semncnt are more of less identical.
The patch creates a single function that either counts the number of tasks
waiting for zero or waiting due to a decrease operation.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 103
, this will be cleaned up in the next patch.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/ipc/sem.c b/ipc/sem.c
index 5749b9c..dc648f8 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1047,6 +1047,16 @@ static int
of writing, which guarantees
>> the commit value read is the latest value written if the head is
>> advancing.
This is a fine solution! I'll verify this against my previous experimental setup
(3.12.x and 3.12.x-rt25), but I dont't expect any problems.
>>
>> Reported-by:
.
Reported-by: Manfred Schlaegl manfred.schla...@gmx.at
Cc: sta...@vger.kernel.org # 3.12.x+
The patch submitted by Manfred notes the commits which introduced the
race [1], but attributes those commits to the 3.11 cycle. Those commits
were merged in the 3.12 cycle.
You are right. I'm sorry
.
With regards to breaking user space, I must think about it a bit more.
Right now, each new namespace starts with SEMMAX=32MB, i.e. an often
unusable default.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
.
With regards to breaking user space, I must think about it a bit more.
Right now, each new namespace starts with SEMMAX=32MB, i.e. an often
unusable default.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On 04/23/2014 04:53 AM, Davidlohr Bueso wrote:
- Breakup long function names/args.
- Cleaup variable declaration.
s/Cleaup/Cleanup/
- s/current->mm/mm
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
@@ -681,7 +679,8 @@ copy_shmid_from_user(struct shmid64_ds *out, v
On 04/23/2014 04:53 AM, Davidlohr Bueso wrote:
- Breakup long function names/args.
- Cleaup variable declaration.
s/Cleaup/Cleanup/
- s/current-mm/mm
Signed-off-by: Davidlohr Bueso davidl...@hp.com
Signed-off-by: Manfred Spraul manf...@colorfullife.com
@@ -681,7 +679,8
On 04/21/2014 07:25 PM, Davidlohr Bueso wrote:
On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote:
Hi all,
the increase of SHMMAX/SHMALL is now a 4 patch series.
I don't have ideas how to improve it further.
Manfred, is there any difference between this set and the one you sent a
couple
find_vma_intersection does not work as intended if addr+size overflows.
The patch adds a manual check before the call to find_vma_intersection.
Signed-off-by: Manfred Spraul
---
ipc/shm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ipc/shm.c b/ipc/shm.c
index 7645961..382e2fb 100644
as a magic value for infinity is even worse, because
right now 0 means 0, i.e. fail all allocations.
Andrew: Could you add it into -akpm and move it towards linux-next?
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
kernel.shmall=0
(not a new feature, also per-namespace)
- The limits are intentionally set to a value slightly less than ULONG_MAX,
to avoid triggering overflows in user space apps.
[not unreasonable, see http://marc.info/?l=linux-mm=139638334330127]
Signed-off-by: Manfred Spraul
Reported
SHMMAX is the upper limit for the size of a shared memory segment,
counted in bytes. The actual allocation is that size, rounded up to
the next full page.
Add a check that prevents the creation of segments where the
rounded up size causes an integer overflow.
Signed-off-by: Manfred Spraul
shm_tot counts the total number of pages used by shm segments.
If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number
can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return
wrong values for shm_tot.
The patch adds a detection for overflows.
Signed-off-by: Manfred Spraul
shm_tot counts the total number of pages used by shm segments.
If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number
can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return
wrong values for shm_tot.
The patch adds a detection for overflows.
Signed-off-by: Manfred Spraul manf
kernel.shmall=0
(not a new feature, also per-namespace)
- The limits are intentionally set to a value slightly less than ULONG_MAX,
to avoid triggering overflows in user space apps.
[not unreasonable, see http://marc.info/?l=linux-mmm=139638334330127]
Signed-off-by: Manfred Spraul manf
SHMMAX is the upper limit for the size of a shared memory segment,
counted in bytes. The actual allocation is that size, rounded up to
the next full page.
Add a check that prevents the creation of segments where the
rounded up size causes an integer overflow.
Signed-off-by: Manfred Spraul manf
find_vma_intersection does not work as intended if addr+size overflows.
The patch adds a manual check before the call to find_vma_intersection.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/shm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ipc/shm.c b/ipc/shm.c
index
right now 0 means 0, i.e. fail all allocations.
Andrew: Could you add it into -akpm and move it towards linux-next?
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 04/21/2014 07:25 PM, Davidlohr Bueso wrote:
On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote:
Hi all,
the increase of SHMMAX/SHMALL is now a 4 patch series.
I don't have ideas how to improve it further.
Manfred, is there any difference between this set and the one you sent a
couple
find_vma_intersection does not work properly if addr+size overflows.
The patch adds a manual check before the call to find_vma_intersection.
Signed-off-by: Manfred Spraul
---
ipc/shm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ipc/shm.c b/ipc/shm.c
index 7645961..382e2fb 100644
nt task size for current.
And it seems that the task size can change based on
(virtual) memory pressure (s390_mmap_check()).
For new namespaces, this might have interesting effects, i.e.
this must be fixed.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscr
shm_tot counts the total number of pages used by shm segments.
If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number
can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return
wrong values for shm_tot.
The patch adds a detection for overflows.
Signed-off-by: Manfred Spraul
SHMMAX is the upper limit of a shared memory segment,
counted in bytes. The actual allocation is that size, rounded
up to the next full page.
Add a check that prevents the creation of segments where the
rounded up size causes an integer overflow.
Signed-off-by: Manfred Spraul
---
ipc/shm.c | 3
TASK_SIZE do not make sense, because such segments can't be mapped.
- The limit for the total memory is 256*TASK_SIZE.
This would be 768 GB for x86-32 and 64 PB for x86-64.
Values larger than that might make sense, but not in the next few weeks.
Signed-off-by: Manfred Spraul
Reported
On 04/19/2014 09:10 AM, Michael Kerrisk (man-pages) wrote:
On Sat, Apr 19, 2014 at 8:55 AM, Davidlohr Bueso wrote:
On Fri, 2014-04-18 at 11:18 +0200, Manfred Spraul wrote:
Risks:
- The patch breaks installations that use "take current value and increase
it a bit". [seems to e
On 04/19/2014 08:55 AM, Davidlohr Bueso wrote:
On Fri, 2014-04-18 at 11:18 +0200, Manfred Spraul wrote:
- ULONG_MAX is not really infinity, but 18 Exabyte segment size and
75 Zettabyte total size. This should be enough for the next few weeks.
(assuming a 64-bit system with 4k pages)
Note
On 04/19/2014 08:55 AM, Davidlohr Bueso wrote:
On Fri, 2014-04-18 at 11:18 +0200, Manfred Spraul wrote:
- ULONG_MAX is not really infinity, but 18 Exabyte segment size and
75 Zettabyte total size. This should be enough for the next few weeks.
(assuming a 64-bit system with 4k pages)
Note
On 04/19/2014 09:10 AM, Michael Kerrisk (man-pages) wrote:
On Sat, Apr 19, 2014 at 8:55 AM, Davidlohr Bueso davidl...@hp.com wrote:
On Fri, 2014-04-18 at 11:18 +0200, Manfred Spraul wrote:
Risks:
- The patch breaks installations that use take current value and increase
it a bit. [seems
than
TASK_SIZE do not make sense, because such segments can't be mapped.
- The limit for the total memory is 256*TASK_SIZE.
This would be 768 GB for x86-32 and 64 PB for x86-64.
Values larger than that might make sense, but not in the next few weeks.
Signed-off-by: Manfred Spraul manf
.
And it seems that the task size can change based on
(virtual) memory pressure (s390_mmap_check()).
For new namespaces, this might have interesting effects, i.e.
this must be fixed.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
shm_tot counts the total number of pages used by shm segments.
If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number
can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return
wrong values for shm_tot.
The patch adds a detection for overflows.
Signed-off-by: Manfred Spraul manf
SHMMAX is the upper limit of a shared memory segment,
counted in bytes. The actual allocation is that size, rounded
up to the next full page.
Add a check that prevents the creation of segments where the
rounded up size causes an integer overflow.
Signed-off-by: Manfred Spraul manf
find_vma_intersection does not work properly if addr+size overflows.
The patch adds a manual check before the call to find_vma_intersection.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/shm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ipc/shm.c b/ipc/shm.c
index
On 04/18/2014 05:36 PM, Michael Kerrisk (man-pages) wrote:
On Fri, Apr 18, 2014 at 11:26 AM, Manfred Spraul
wrote:
Obviously my patch has the opposite problem: 64-bit wrap-arounds.
I know you alluded to a case in another thread, but I couldn't quite
work out from the mail you referred
#define SHMSEG SHMMNI /* max shared segs per process */
The "#ifndef __KERNEL__" is not required:
As there is no reference to PAGE_SIZE anymore, one definition for SHMALL
is sufficient.
--
Manfred
--
To unsubscribe from this list: send the line "un
llocations.
- There is no wrap-around protection for ns->shm_ctlall, i.e. the 75 ZB
limit is not enforced.
Signed-off-by: Manfred Spraul
Reported-by: Davidlohr Bueso
Cc: mtk.manpa...@gmail.com
---
include/linux/shm.h | 1 -
include/uapi/linux/shm.h | 8 +++-
2 files changed, 3 insertions(+), 6 delet
On 2014-04-08 14:42, Manfred Schlaegl wrote:
> The race was introduced while development of linux-3.11 by
> e8437d7ecbc50198705331449367d401ebb3181f and
> e9975fdec0138f1b2a85b9624e41660abd9865d4.
> Originally it was found and reproduced on linux-3.12.15 and
> linux-3.12.15-rt25,
On 04/18/2014 05:36 PM, Michael Kerrisk (man-pages) wrote:
On Fri, Apr 18, 2014 at 11:26 AM, Manfred Spraul
manf...@colorfullife.com wrote:
Obviously my patch has the opposite problem: 64-bit wrap-arounds.
I know you alluded to a case in another thread, but I couldn't quite
work out from
On 2014-04-08 14:42, Manfred Schlaegl wrote:
The race was introduced while development of linux-3.11 by
e8437d7ecbc50198705331449367d401ebb3181f and
e9975fdec0138f1b2a85b9624e41660abd9865d4.
Originally it was found and reproduced on linux-3.12.15 and
linux-3.12.15-rt25, by sending 500 byte
-around protection for ns-shm_ctlall, i.e. the 75 ZB
limit is not enforced.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
Reported-by: Davidlohr Bueso davidl...@hp.com
Cc: mtk.manpa...@gmail.com
---
include/linux/shm.h | 1 -
include/uapi/linux/shm.h | 8 +++-
2 files changed
#define SHMSEG SHMMNI /* max shared segs per process */
The #ifndef __KERNEL__ is not required:
As there is no reference to PAGE_SIZE anymore, one definition for SHMALL
is sufficient.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 04/17/2014 12:41 PM, Michael Kerrisk wrote:
On Thu, Apr 17, 2014 at 12:46 AM, Andrew Morton
wrote:
On Sun, 13 Apr 2014 20:05:34 +0200 Manfred Spraul
wrote:
Hi Andrew,
On 04/02/2014 12:08 AM, Andrew Morton wrote:
Well, I'm assuming 64GB==infinity. It *was* infinity in the RHEL5
t;
/proc/sys/kernel/shmmax
With my patch, shmmax would end up as 0 and all allocations fail.
- My patch handles the case if some startup code/installer checks
shmmax and complains if it is below the requirement of the application.
--
Manfred
--
To unsubscribe from this list: send
startup code/installer checks
shmmax and complains if it is below the requirement of the application.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On 04/17/2014 12:41 PM, Michael Kerrisk wrote:
On Thu, Apr 17, 2014 at 12:46 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Sun, 13 Apr 2014 20:05:34 +0200 Manfred Spraul manf...@colorfullife.com
wrote:
Hi Andrew,
On 04/02/2014 12:08 AM, Andrew Morton wrote:
Well, I'm assuming 64GB
- and
Android disables sysv shm entirely.
There are two patches:
http://marc.info/?l=linux-kernel=139730332306185=raw
http://marc.info/?l=linux-kernel=139727299800644=raw
Could you apply one of them?
I wrote the first one, thus I'm biased which one is better.
--
Manfred
--
To unsubscribe from
- and
Android disables sysv shm entirely.
There are two patches:
http://marc.info/?l=linux-kernelm=139730332306185q=raw
http://marc.info/?l=linux-kernelm=139727299800644q=raw
Could you apply one of them?
I wrote the first one, thus I'm biased which one is better.
--
Manfred
--
To unsubscribe
incompatibilities.
Signed-off-by: Manfred Spraul
---
include/linux/shm.h | 2 +-
include/uapi/linux/shm.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/shm.h b/include/linux/shm.h
index 1e2cd2e..37bf9c6 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
On 04/11/2014 10:27 PM, Davidlohr Bueso wrote:
On Fri, 2014-04-11 at 20:28 +0200, Manfred Spraul wrote:
Hi Davidlohr,
On 04/03/2014 02:20 AM, Davidlohr Bueso wrote:
The default size for shmmax is, and always has been, 32Mb.
Today, in the XXI century, it seems that this value is rather small
On 04/11/2014 10:27 PM, Davidlohr Bueso wrote:
On Fri, 2014-04-11 at 20:28 +0200, Manfred Spraul wrote:
Hi Davidlohr,
On 04/03/2014 02:20 AM, Davidlohr Bueso wrote:
The default size for shmmax is, and always has been, 32Mb.
Today, in the XXI century, it seems that this value is rather small
incompatibilities.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
include/linux/shm.h | 2 +-
include/uapi/linux/shm.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/shm.h b/include/linux/shm.h
index 1e2cd2e..37bf9c6 100644
--- a/include/linux/shm.h
mmary is misleading, the impact on SHMMIN is not mentioned.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
*AND* checking for SHMMIN.
a) Have you double checked that 0-sized shm segments work properly?
Does the swap code handle it properly, ...?
b) It's that yet another risk for user space incompatibility?
c) The patch summary is misleading, the impact on SHMMIN is not mentioned.
--
Manfred
// ERROR: tty_buffer head freed -> 6 bytes lost
continue;
}
}}}
This patch reintroduces a spin_lock to protect this case. Perhaps later
a lock-less solution could be found.
Signed-off-by: Manfred Schlaegl
---
drivers/tty/tty_buffer.c | 16 ++--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
;
}
}}}
This patch reintroduces a spin_lock to protect this case. Perhaps later
a lock-less solution could be found.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
drivers/tty/tty_buffer.c | 16 ++--
include/linux/tty.h |1 +
2 files changed, 15 insertions
oach.
- setting shmmax by default to ULONG_MAX is the perfect workaround.
What reasons are there against the one-line patch?
>
> -#define SHMMAX 0x200/* max shared seg size
(bytes) */
> +#define SHMMAX ULONG_MAX/* max shared seg size
(bytes) */
>
--
shmmax by default to ULONG_MAX is the perfect workaround.
What reasons are there against the one-line patch?
-#define SHMMAX 0x200/* max shared seg size
(bytes) */
+#define SHMMAX ULONG_MAX/* max shared seg size
(bytes) */
--
Manfred
--
To unsubscribe
sure that no user space apps uses shmctl(IPC_INFO) and prints a
pretty error message if shmall is too small?
We would break these apps.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
sure that no user space apps uses shmctl(IPC_INFO) and prints a
pretty error message if shmall is too small?
We would break these apps.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
Hallo,
Entschuldigen Sie mich auf diese Weise , Sie zu kontaktieren , ich sah
Ihr Profil und ich sage Ihnen das , was ich brauche bist . Kurz
gesagt, mein Name ist Manfred EGGERT , von Französisch Herkunft , und
ich lebe in Deutschland. Ich leide an einer schweren Krankheit , die
mich in den
Hallo,
Entschuldigen Sie mich auf diese Weise , Sie zu kontaktieren , ich sah
Ihr Profil und ich sage Ihnen das , was ich brauche bist . Kurz
gesagt, mein Name ist Manfred EGGERT , von Französisch Herkunft , und
ich lebe in Deutschland. Ich leide an einer schweren Krankheit , die
mich in den
601 - 700 of 1478 matches
Mail list logo
