Hi,
currently I'm porting UML to s390 31-bit.
A first 2.6.11 UML system already is running in UML-SKAS0 mode,
which normally should run on an unpatched host (no skas3-patch).
To make UML build and run on s390, I needed to do these two little
changes (the patches are copy and paste. I hope that does
Robert Wilkens wrote:
Kernel code blocks both "handled signal" _and_ sa_mask only if SA_NODEFER
isn't set.
Which is the right behavior?
Perhaps both?
I'm novice here, but if i'm reading the man page correctly, it says:
SA_NODEFER
Do not prevent the signal from being received from within
ge if you don't understand what I seem to understand.
-Rob
On Tue, 2005-08-09 at 20:32 +0200, Bodo Stroesser wrote:
Sorry, unfortunately you are not right. See this (from man page for sigaction):
struct sigaction {
void (*sa_handler)(int);
void (*sa_sigac
Steven Rostedt wrote:
On Tue, 2005-08-09 at 15:04 -0400, Robert Wilkens wrote:
[resent - previous message not properly addressed]
It says "signal is blocked, UNLESS SA_NODEFER is used.."
Which means if NODEFER is used, it's not masked (SA_NOMASK)..
I believe I understand what Bodo is sayi
Chris Wright wrote:
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
Where, sa_mask is _ignored_ if NODEFER is set. (I now have woken up!).
The attached program shows that the sa_mask is indeed ignored when
SA_NODEFER is set.
Now the real question is... Is this a bug?
That's not correct w.r.t. S
Linus Torvalds wrote:
On Tue, 9 Aug 2005, Steven Rostedt wrote:
If this is indeed the way things should work. I'll go ahead and fix all
the other architectures.
It does appear that this is what the standards describe in the section
quoted by Chris.
On the other hand, the standard seems t
Bodo Stroesser wrote:
Hi,
my dual Xeon machine freezes, if connection between
FC switch and tape drives is broken while writing to tapes.
There is one SCSI target with 16 tape LUNs connected to my
FC controller via FC switch. I can reproduce the problem by
starting "dd if=/dev/zero of=/d
Hi
IMHO, there is a bug in s390's signal frame handling:
If a signal handler is set to use the signal stack (SA_ONSTACK), but
the signal stack is disabled, the signal frame should be written to
the current stack without stack switching.
S390 doesn't note, that the signal stack is disabled, so it do
[EMAIL PROTECTED] wrote:
Use rep_nop instead of barrier for cpu_relax, following $(SUBARCH)'s doing
that (i.e. i386 and x86_64).
IIRC, Jeff had the idea, to use sched_yield() for this (from a discussion
on #uml).
S390 does something similar using a special DIAG-opcode that gives permission
to zVM
Nick Piggin wrote:
Bodo Stroesser wrote:
Working with the new UML skas0 mode on my Xeon HT host, sporadically I
saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment
register,
that had the wrong contents.
This again is caused by a problem in
Nick Piggin wrote:
Your one liner would fix the problem too, of course. The important
thing at this stage is that it gets fixed for 2.6.11.
Sorry, have been off the net last week.
Thank you for the patches. Have tested Ingo's one liner.
It works fine for me, as expected.
Bodo
-
To unsubscribe from
Working with the new UML skas0 mode on my Xeon HT host, sporadically I saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment register,
that had the wrong contents.
This again is caused by a problem in the host linux: A ptraced child going to
stop
On 11.02.21 07:51, Greg Kroah-Hartman wrote:
On Wed, Feb 10, 2021 at 08:57:11PM +0100, Bodo Stroesser wrote:
On 10.02.21 20:47, Greg Kroah-Hartman wrote:
On Wed, Feb 10, 2021 at 08:40:30PM +0100, Bodo Stroesser wrote:
If uio_unregister_device() is called while userspace daemon
still holds the
A couple of weeks ago I found a huge memory leak in tcmu:
tcmu needs to keep resources as long as userspace holds the uio
device open or mmap'ed. Therefore tcmu increments and decrements
a refcnt during uio_info::uio_open (tcmu_open) and
uio_info::uio_release (tcmu_release).
If via configFS user
vice() to notify userspace
that we are going to destroy the device, but still get a call
to late_release when uio device is finally closed.
Signed-off-by: Bodo Stroesser
---
Documentation/driver-api/uio-howto.rst | 10 ++
drivers/uio/uio.c | 4
include/linux/uio
after tcmu had
executed uio_unregister_device. So tcmu device and its allocated
resources are not freed in this situation.
tcmu now sets uio_info->late_release which is called by uio in
the described situation. That way the memory leak is fixed.
Signed-off-by: Bodo Stroesser
---
On 10.02.21 20:47, Greg Kroah-Hartman wrote:
On Wed, Feb 10, 2021 at 08:40:30PM +0100, Bodo Stroesser wrote:
If uio_unregister_device() is called while userspace daemon
still holds the uio device open or mmap'ed, uio will not call
uio_info->release() on later close / munmap.
At least
I'm sending a gentle ping for the below patch.
Especially I'm wondering whether the way how tcmu_destroy_device()
now 'stops' the uio device is ok. Should we better have something
like uio_stop_device() instead?
Thank you,
Bodo
On 18.12.20 15:15, Bodo Stroesse
On 12.01.21 19:36, Mike Christie wrote:
On 12/18/20 8:15 AM, Bodo Stroesser wrote:
tcmu calls uio_unregister_device from tcmu_destroy_device.
After that uio will never call tcmu_release for this device.
If userspace still had the uio device open and / or mmap'ed
during uio_unregister_d
ondition.
My "log of both sides" proposal at least got around the overflowing
left shift problem. And one reviewer, Bodo Stroesser, liked it.
I added my Reviewed-by after you added a working check of nent overflow.
I did not oppose to the usage of ilog() there. But now I think Jaso
On 18.01.21 21:24, Jason Gunthorpe wrote:
> On Mon, Jan 18, 2021 at 03:08:51PM -0500, Douglas Gilbert wrote:
>> On 2021-01-18 1:28 p.m., Jason Gunthorpe wrote:
>>> On Mon, Jan 18, 2021 at 11:30:03AM -0500, Douglas Gilbert wrote:
>>>
After several flawed attempts to detect overflow, take the fa
On 19.01.21 00:48, Jason Gunthorpe wrote:
On Mon, Jan 18, 2021 at 10:22:56PM +0100, Bodo Stroesser wrote:
On 18.01.21 21:24, Jason Gunthorpe wrote:
On Mon, Jan 18, 2021 at 03:08:51PM -0500, Douglas Gilbert wrote:
On 2021-01-18 1:28 p.m., Jason Gunthorpe wrote:
On Mon, Jan 18, 2021 at 11:30
On 19.01.21 19:17, Jason Gunthorpe wrote:
On Tue, Jan 19, 2021 at 07:08:32PM +0100, Bodo Stroesser wrote:
On 19.01.21 19:03, Jason Gunthorpe wrote:
On Tue, Jan 19, 2021 at 06:24:49PM +0100, Bodo Stroesser wrote:
I had a second look into math.h, but I don't find any reason why round_up
On 19.01.21 19:03, Jason Gunthorpe wrote:
On Tue, Jan 19, 2021 at 06:24:49PM +0100, Bodo Stroesser wrote:
I had a second look into math.h, but I don't find any reason why round_up
could overflow. Can you give a hint please?
#define round_up(x, y) x)-1) | __round_mask(x,
On 13.01.21 22:04, Mike Christie wrote:
On 1/13/21 11:59 AM, Bodo Stroesser wrote:
On 12.01.21 19:36, Mike Christie wrote:
On 12/18/20 8:15 AM, Bodo Stroesser wrote:
tcmu calls uio_unregister_device from tcmu_destroy_device.
After that uio will never call tcmu_release for this device.
If
On 22.02.21 16:12, Romain Perier wrote:
The strlcpy() reads the entire source buffer first, it is dangerous if
the source buffer lenght is unbounded or possibility non NULL-terminated.
It can lead to linear read overflows, crashes, etc...
As recommended in the deprecated interfaces [1], it shoul
On 03.12.20 12:40, Xiaohui Zhang wrote:
> From: Zhang Xiaohui
>
> The fix makes sure no zero value in the buffer, by comparing the
> strlen() of the original buffer with the size variable.
What problem do you want to fix here?
I think, presently iblock_set_configfs_dev_params() just ignores inpu
the read
fails with -EIO
Avoid possible races in tcmu_open by replacing kref_get with
kref_get_unless_zero.
Signed-off-by: Bodo Stroesser
---
drivers/target/target_core_user.c | 54 ---
1 file changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/t
Hi Douglas,
AFAICS this patch - and also patch 3 - are not correct.
When started with SG_MITER_ATOMIC, sg_miter_next and sg_miter_stop use
the k(un)map_atomic calls. But these have to be used strictly nested
according to docu and code.
The below code uses the atomic mappings in overlapping mode.
AFAICS, there are 2 unneeded lines in the new implementation
of sgl_memset. Please see details below.
Am 18.10.20 um 19:13 schrieb Douglas Gilbert:
The existing sg_zero_buffer() function is a bit restrictive.
For example protection information (PI) blocks are usually
initialized to 0xff bytes.
Am 19.10.20 um 21:19 schrieb Douglas Gilbert:
> This patch removes a check done by sgl_alloc_order() before it starts
> any allocations. The comment before the removed code says: "Check for
> integer overflow" arguably gives a false sense of security. The right
> hand side of the expression in the
en;
+ sg_miter_stop(&s_iter);
+ }
+fini:
+ sg_miter_stop(&d_iter);
+ sg_miter_stop(&s_iter);
+ return offset;
+}
+EXPORT_SYMBOL(sgl_copy_sgl);
+
Reviewed-by: Bodo Stroesser
;
+ sg_miter_stop(&x_iter);
+ return equ;
+}
+EXPORT_SYMBOL(sgl_compare_sgl);
Reviewed-by: Bodo Stroesser
en;
+ sg_miter_stop(&s_iter);
+ }
+fini:
+ sg_miter_stop(&d_iter);
+ sg_miter_stop(&s_iter);
+ return offset;
+}
+EXPORT_SYMBOL(sgl_copy_sgl);
+
Second try, this time with correct tag.
Reviewed-by: Bodo Stroesser
e ((offset < n_bytes) && sg_miter_next(&miter)) {
+ len = min(miter.length, n_bytes - offset);
+ memset(miter.addr, val, len);
+ offset += len;
+ }
+fini:
+ sg_miter_stop(&miter);
+ return offset;
+}
+EXPORT_SYMBOL(sgl_memset);
+
Reviewed-by: Bodo Stroesser
35 matches
Mail list logo
