Re: [kernel-locking] question about structure field initialization

Hi Chris, Quoting Chris Wilson : On Thu, May 11, 2017 at 03:00:02PM -0500, Gustavo A. R. Silva wrote: Hello everybody, While looking into Coverity ID 1402035 I ran into the following piece of code at kernel/locking/test-ww_mutex.c:197: 197static int test_abba(bool

Re: [kernel-locking] question about structure field initialization

Hi Chris, Quoting Chris Wilson : On Thu, May 11, 2017 at 03:00:02PM -0500, Gustavo A. R. Silva wrote: Hello everybody, While looking into Coverity ID 1402035 I ran into the following piece of code at kernel/locking/test-ww_mutex.c:197: 197static int test_abba(bool resolve) 198{ 199

Re: [kernel-locking] question about structure field initialization

On Thu, May 11, 2017 at 03:00:02PM -0500, Gustavo A. R. Silva wrote: > > Hello everybody, > > While looking into Coverity ID 1402035 I ran into the following > piece of code at kernel/locking/test-ww_mutex.c:197: > > 197static int test_abba(bool resolve) > 198{ > 199struct test_abba

Re: [kernel-locking] question about structure field initialization

On Thu, May 11, 2017 at 03:00:02PM -0500, Gustavo A. R. Silva wrote: > > Hello everybody, > > While looking into Coverity ID 1402035 I ran into the following > piece of code at kernel/locking/test-ww_mutex.c:197: > > 197static int test_abba(bool resolve) > 198{ > 199struct test_abba

[kernel-locking] question about structure field initialization

Hello everybody, While looking into Coverity ID 1402035 I ran into the following piece of code at kernel/locking/test-ww_mutex.c:197: 197static int test_abba(bool resolve) 198{ 199struct test_abba abba; 200struct ww_acquire_ctx ctx; 201int err, ret; 202 203

[kernel-locking] question about structure field initialization

Hello everybody, While looking into Coverity ID 1402035 I ran into the following piece of code at kernel/locking/test-ww_mutex.c:197: 197static int test_abba(bool resolve) 198{ 199struct test_abba abba; 200struct ww_acquire_ctx ctx; 201int err, ret; 202 203

Locking question (was: [CHECKER] 9 potential copy_*_user bugs in2.4.1)

On Thu, 15 Mar 2001, Dawson Engler wrote: > 2. And, unrelated: given the current locking discipline, is > it bad to hold any type of lock (not just a spin lock) when you > call a potentially blocking function? (It at least seems bad > for performance, since you'll hold

Locking question (was: [CHECKER] 9 potential copy_*_user bugs in2.4.1)

On Thu, 15 Mar 2001, Dawson Engler wrote: 2. And, unrelated: given the current locking discipline, is it bad to hold any type of lock (not just a spin lock) when you call a potentially blocking function? (It at least seems bad for performance, since you'll hold the

locking question

As part of better understanding some of the issues in SMP, I've been working at documenting all the global kernel locks in use, including what's left of the BKL, and have run into a use of the BKL that seems pretty consistent and also pretty obscure. The code base I'm inspecting is 2.4.0-test8.

Re: Locking question, is this cool?

Alan Cox wrote: > > > At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find: > > > > WRITE_LOCK_IRQSAVE(... > > > > this is followed by: > > > > COPY_FROM_USER(... > > > > It seems to me that this could result in a page fault with interrupts > > off. Is this ok? > > It wont do what you

Re: Locking question, is this cool?

> At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find: > > WRITE_LOCK_IRQSAVE(... > > this is followed by: > > COPY_FROM_USER(... > > It seems to me that this could result in a page fault with interrupts > off. Is this ok? It wont do what you want - it'll re-enable irqs and may

Locking question, is this cool?

At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find: WRITE_LOCK_IRQSAVE(... this is followed by: COPY_FROM_USER(... It seems to me that this could result in a page fault with interrupts off. Is this ok? George - To unsubscribe from this list: send the line "unsubscribe

Locking question, is this cool?

At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find: WRITE_LOCK_IRQSAVE(... this is followed by: COPY_FROM_USER(... It seems to me that this could result in a page fault with interrupts off. Is this ok? George - To unsubscribe from this list: send the line "unsubscribe

Re: Locking question, is this cool?

At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find: WRITE_LOCK_IRQSAVE(... this is followed by: COPY_FROM_USER(... It seems to me that this could result in a page fault with interrupts off. Is this ok? It wont do what you want - it'll re-enable irqs and may then

Re: Locking question, is this cool?

Alan Cox wrote: At line 1073 of ../drivers/char/i2lib.c (2.4.0-test9) we find: WRITE_LOCK_IRQSAVE(... this is followed by: COPY_FROM_USER(... It seems to me that this could result in a page fault with interrupts off. Is this ok? It wont do what you want - it'll re-enable