On Fri, Nov 4, 2016 at 3:33 PM, Nathan Zimmer <nzim...@sgi.com> wrote:
> On Thu, Nov 03, 2016 at 06:25:46PM -0600, Peter Hurley wrote:
>> On Wed, Nov 2, 2016 at 9:29 AM, Nathan Zimmer <nzim...@sgi.com> wrote:
>> > On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurl
On Fri, Nov 4, 2016 at 3:33 PM, Nathan Zimmer wrote:
> On Thu, Nov 03, 2016 at 06:25:46PM -0600, Peter Hurley wrote:
>> On Wed, Nov 2, 2016 at 9:29 AM, Nathan Zimmer wrote:
>> > On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurley wrote:
>> >> On Mon, Oct 31, 2016
especially that I've
> seen patches flying around fixing such issues. Unfortunately I
> cannot reliably reproduce this and booting a production machine
> with lockdep would be problematic.
Too bad because lockdep would definitively tell you what process is
holding the ldsem for this tty.
If you paste *all the tasks*, I can try to see if I recognize the task
stack that is holding the ldsem.
Regards,
Peter Hurley
en patches flying around fixing such issues. Unfortunately I
> cannot reliably reproduce this and booting a production machine
> with lockdep would be problematic.
Too bad because lockdep would definitively tell you what process is
holding the ldsem for this tty.
If you paste *all the tasks*, I can try to see if I recognize the task
stack that is holding the ldsem.
Regards,
Peter Hurley
On Wed, Nov 2, 2016 at 9:29 AM, Nathan Zimmer <nzim...@sgi.com> wrote:
> On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurley wrote:
>> On Mon, Oct 31, 2016 at 2:27 PM, Sean Young <s...@mess.org> wrote:
>> > On Sun, Oct 30, 2016 at 10:33:02AM -0500, Nathan wr
On Wed, Nov 2, 2016 at 9:29 AM, Nathan Zimmer wrote:
> On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurley wrote:
>> On Mon, Oct 31, 2016 at 2:27 PM, Sean Young wrote:
>> > On Sun, Oct 30, 2016 at 10:33:02AM -0500, Nathan wrote:
>> >> I think this should
is buggy, but also that something else is using IRQ 3?
Regards,
Peter Hurley
rial
port w/ driver never actually worked.
2. Can you post dmesg for the SLES 11 setup? That would show if there
were probe errors even on that.
An alternative that should be equivalent to your previous setup is to
build w/ CONFIG_SERIAL_8250_PNP=n
Seems like your ACPI BIOS is buggy, but also that something else is using IRQ 3?
Regards,
Peter Hurley
o discuss this.
Hey Rob,
I'm here so let's make time to discuss this.
Regards,
Peter Hurley
I'm here so let's make time to discuss this.
Regards,
Peter Hurley
match consoles against
>> data specified in a string, for example taken from command line or
>> compiled by ACPI SPCR table handler.
>>
>> Signed-off-by: Aleksey Makarov <aleksey.maka...@linaro.org>
>> Reviewed-by: Peter Hurley <pe.
gt; data specified in a string, for example taken from command line or
>> compiled by ACPI SPCR table handler.
>>
>> Signed-off-by: Aleksey Makarov
>> Reviewed-by: Peter Hurley
>> ---
>> drivers/tty/serial/amba-pl011.c | 56
>> +
error:
>
> [5.541751] ttyS0 - failed to request DMA
>
> Reverting the commit ec5a11a91eec removes the error.
The error is that your dmaengine driver doesn't support the functionality
required by the 8250 driver.
Regards,
Peter Hurley
> I saw that you started the d
error:
>
> [5.541751] ttyS0 - failed to request DMA
>
> Reverting the commit ec5a11a91eec removes the error.
The error is that your dmaengine driver doesn't support the functionality
required by the 8250 driver.
Regards,
Peter Hurley
> I saw that you started the d
ind of naming scheme that preserves
both the command line parameters (uart,uart8250,pl011,etc.) and uniquely
identifies which uart driver is the earlycon.
The current scheme could be fixed easily enough (by just using a single digit).
Or using a separator, ie. uart/0, pl011/0, etc.
Regards
ind of naming scheme that preserves
both the command line parameters (uart,uart8250,pl011,etc.) and uniquely
identifies which uart driver is the earlycon.
The current scheme could be fixed easily enough (by just using a single digit).
Or using a separator, ie. uart/0, pl011/0, etc.
Regards
port mutex */
> page = get_zeroed_page(GFP_KERNEL);
> - if (!page)
> + if (!page) {
if (!uart_console(uport))
Otherwise, you'll be powering off the console.
Just out of curiosity, did you actually hit this error?
Regards,
Peter Hurley
> +
age = get_zeroed_page(GFP_KERNEL);
> - if (!page)
> + if (!page) {
if (!uart_console(uport))
Otherwise, you'll be powering off the console.
Just out of curiosity, did you actually hit this error?
Regards,
Peter Hurley
> + uart_change
)
> and noticed that the most recent builds were against GCC 4.6.3.
Someone's been making them.
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/
arm64
alpha
arm = gnueabi
parisc = hppa
parisc64 = hppa64
mips
mips64
powerpc
powerpc64
sparc
sparc64
s390
...
Regards,
Peter Hurley
)
> and noticed that the most recent builds were against GCC 4.6.3.
Someone's been making them.
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/
arm64
alpha
arm = gnueabi
parisc = hppa
parisc64 = hppa64
mips
mips64
powerpc
powerpc64
sparc
sparc64
s390
...
Regards,
Peter Hurley
robably not going to cost anything in
> practice. It would be better to avoid adding any special macros for this
> which may just add more complexity.
See, I don't understand this line of reasoning at all.
I read this as "it's ok to be non-optimal here where were spinning CPU
time but not ok to be non-optimal generally elsewhere where it's
way less important like at init time".
And by the way, it's not just "here" but _everywhere_.
What about reading ->on_cpu locklessly?
Sure it's a bool, but doesn't the "we need to document lockless access"
argument equally apply here?
Regards,
Peter Hurley
robably not going to cost anything in
> practice. It would be better to avoid adding any special macros for this
> which may just add more complexity.
See, I don't understand this line of reasoning at all.
I read this as "it's ok to be non-optimal here where were spinning CPU
time but not ok to be non-optimal generally elsewhere where it's
way less important like at init time".
And by the way, it's not just "here" but _everywhere_.
What about reading ->on_cpu locklessly?
Sure it's a bool, but doesn't the "we need to document lockless access"
argument equally apply here?
Regards,
Peter Hurley
Hi Paul,
You can disregard this as I think we're talking about
the same things with the other email thread.
Regards,
Peter Hurley
On 05/17/2016 12:46 PM, Peter Hurley wrote:
> On 05/16/2016 10:22 AM, Paul E. McKenney wrote:
>> On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hur
Hi Paul,
You can disregard this as I think we're talking about
the same things with the other email thread.
Regards,
Peter Hurley
On 05/17/2016 12:46 PM, Peter Hurley wrote:
> On 05/16/2016 10:22 AM, Paul E. McKenney wrote:
>> On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hur
On 05/16/2016 10:22 AM, Paul E. McKenney wrote:
> On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote:
>> On 05/16/2016 05:17 AM, Paul E. McKenney wrote:
>>> On Mon, May 16, 2016 at 01:09:48PM +0200, Peter Zijlstra wrote:
>>>> On Fri, May 13, 2016 at 10:58:
On 05/16/2016 10:22 AM, Paul E. McKenney wrote:
> On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote:
>> On 05/16/2016 05:17 AM, Paul E. McKenney wrote:
>>> On Mon, May 16, 2016 at 01:09:48PM +0200, Peter Zijlstra wrote:
>>>> On Fri, May 13, 2016 at 10:58:
On 05/16/2016 10:50 AM, Peter Zijlstra wrote:
> On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote:
>
>>>> Correct; which is why we should always use {READ,WRITE}_ONCE() for
>>>> anything that is used locklessly.
>>>
>>> Completely
On 05/16/2016 10:50 AM, Peter Zijlstra wrote:
> On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote:
>
>>>> Correct; which is why we should always use {READ,WRITE}_ONCE() for
>>>> anything that is used locklessly.
>>>
>>> Completely
interrupt-issue/20160513-162046 HEAD
>> 0354112aa9821bec8d278ad06b3d543724f5291d builds fine.
>> It only hurts bisectibility.
>>
>> All errors (new ones prefixed by >>):
>
> Peter, what happened to your DMA series in the linux-next? Did I miss
> any discu
interrupt-issue/20160513-162046 HEAD
>> 0354112aa9821bec8d278ad06b3d543724f5291d builds fine.
>> It only hurts bisectibility.
>>
>> All errors (new ones prefixed by >>):
>
> Peter, what happened to your DMA series in the linux-next? Did I miss
> any discu
On 05/17/2016 08:57 AM, Peter Hurley wrote:
> On 05/16/2016 04:36 PM, Peter Hurley wrote:
>> > Hi Mikulas,
>> >
>> > On 05/16/2016 01:12 PM, Mikulas Patocka wrote:
>>> >> Hi
>>> >>
>>> >> In the kernel 4.6 I
On 05/17/2016 08:57 AM, Peter Hurley wrote:
> On 05/16/2016 04:36 PM, Peter Hurley wrote:
>> > Hi Mikulas,
>> >
>> > On 05/16/2016 01:12 PM, Mikulas Patocka wrote:
>>> >> Hi
>>> >>
>>> >> In the kernel 4.6 I
On 05/12/2016 03:56 PM, Waiman Long wrote:
> This patch moves the owner loading and checking code entirely inside of
> rwsem_spin_on_owner() to simplify the logic of rwsem_optimistic_spin()
> loop.
Thanks for this.
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
On 05/12/2016 03:56 PM, Waiman Long wrote:
> This patch moves the owner loading and checking code entirely inside of
> rwsem_spin_on_owner() to simplify the logic of rwsem_optimistic_spin()
> loop.
Thanks for this.
Reviewed-by: Peter Hurley
ough there's no particular harm in the current code, this at
least spells out this condition is normal (ie., when a failed reader
wakes itself while waking the other waiting readers).
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
ough there's no particular harm in the current code, this at
least spells out this condition is normal (ie., when a failed reader
wakes itself while waking the other waiting readers).
Reviewed-by: Peter Hurley
check. If another reader is present, the code
> will still break out and exit even if the writer is gone. This patch
> changes it to check the same "< RWSEM_WAITING_BIAS" condition to
> reduce the chance of false positive.
Nice.
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
check. If another reader is present, the code
> will still break out and exit even if the writer is gone. This patch
> changes it to check the same "< RWSEM_WAITING_BIAS" condition to
> reduce the chance of false positive.
Nice.
Reviewed-by: Peter Hurley
On 05/16/2016 04:36 PM, Peter Hurley wrote:
> Hi Mikulas,
>
> On 05/16/2016 01:12 PM, Mikulas Patocka wrote:
>> Hi
>>
>> In the kernel 4.6 I get crashes in the tty layer. I can reproduce the
>> crash by logging into the machine with ssh and typing before th
On 05/16/2016 04:36 PM, Peter Hurley wrote:
> Hi Mikulas,
>
> On 05/16/2016 01:12 PM, Mikulas Patocka wrote:
>> Hi
>>
>> In the kernel 4.6 I get crashes in the tty layer. I can reproduce the
>> crash by logging into the machine with ssh and typing before th
[ +to Scot Doyle ]
Scot, please take a look at this soft lockup.
Regards,
Peter Hurley
Hi Ming,
On 05/17/2016 02:12 AM, Ming Lei wrote:
> Hi,
>
> On Tue, May 17, 2016 at 4:07 AM, Dann Frazier
> <dann.fraz...@canonical.com> wrote:
>> Hi,
>> I'm observing a s
[ +to Scot Doyle ]
Scot, please take a look at this soft lockup.
Regards,
Peter Hurley
Hi Ming,
On 05/17/2016 02:12 AM, Ming Lei wrote:
> Hi,
>
> On Tue, May 17, 2016 at 4:07 AM, Dann Frazier
> wrote:
>> Hi,
>> I'm observing a soft lockup issue w/ the ASPEED c
the crashes are caused by the patch
> 892d1fa7eaaed9d3c04954cb140c34ebc3393932 ("tty: Destroy ldisc instance on
> hangup").
Can you try the test patch below?
Regards,
Peter Hurley
> Kernel Fault: Code=15 regs=7d9e0720 (Addr=2260)
> CPU: 0 PID: 3319 Comm: kworker/u8:0 Not t
the crashes are caused by the patch
> 892d1fa7eaaed9d3c04954cb140c34ebc3393932 ("tty: Destroy ldisc instance on
> hangup").
Can you try the test patch below?
Regards,
Peter Hurley
> Kernel Fault: Code=15 regs=7d9e0720 (Addr=2260)
> CPU: 0 PID: 3319 Comm: kworker/u8:0 Not t
not opened any
> other serial drivers, because SERIAL_CORE would not be selected.
I don't understand what this means.
Regards,
Peter Hurley
> Signed-off-by: Zhen Lei <thunder.leiz...@huawei.com>
> ---
> drivers/tty/serial/8250/Kconfig | 9 +++--
> drivers/tty/seria
not opened any
> other serial drivers, because SERIAL_CORE would not be selected.
I don't understand what this means.
Regards,
Peter Hurley
> Signed-off-by: Zhen Lei
> ---
> drivers/tty/serial/8250/Kconfig | 9 +++--
> drivers/tty/serial/8250/Makefile | 1 -
> drivers/tt
On 05/16/2016 05:17 AM, Paul E. McKenney wrote:
> On Mon, May 16, 2016 at 01:09:48PM +0200, Peter Zijlstra wrote:
>> On Fri, May 13, 2016 at 10:58:05AM -0700, Peter Hurley wrote:
>>>> Note that barrier() and READ_ONCE() have overlapping but not identical
>>>> resu
On 05/16/2016 05:17 AM, Paul E. McKenney wrote:
> On Mon, May 16, 2016 at 01:09:48PM +0200, Peter Zijlstra wrote:
>> On Fri, May 13, 2016 at 10:58:05AM -0700, Peter Hurley wrote:
>>>> Note that barrier() and READ_ONCE() have overlapping but not identical
>>>> resu
On 05/13/2016 08:07 AM, Peter Zijlstra wrote:
> On Wed, May 11, 2016 at 03:04:20PM -0700, Peter Hurley wrote:
>>> + return !rwsem_is_reader_owned(READ_ONCE(sem->owner));
>>
>> It doesn't make sense to force reload sem->owner here; if sem->owner
>> is
On 05/13/2016 08:07 AM, Peter Zijlstra wrote:
> On Wed, May 11, 2016 at 03:04:20PM -0700, Peter Hurley wrote:
>>> + return !rwsem_is_reader_owned(READ_ONCE(sem->owner));
>>
>> It doesn't make sense to force reload sem->owner here; if sem->owner
>> is
On 05/12/2016 01:15 PM, Waiman Long wrote:
> On 05/11/2016 06:04 PM, Peter Hurley wrote:
[...]
>>
>>> @@ -328,8 +329,6 @@ done:
>>> static noinline
>>> bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct
>
On 05/12/2016 01:15 PM, Waiman Long wrote:
> On 05/11/2016 06:04 PM, Peter Hurley wrote:
[...]
>>
>>> @@ -328,8 +329,6 @@ done:
>>> static noinline
>>> bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct
>
t rw_semaphore
> *sem)
>* When there's no owner, we might have preempted between the
>* owner acquiring the lock and setting the owner field. If
>* we're an RT task that will live-lock because we won't let
> - * the owner complete.
> +
re's no owner, we might have preempted between the
>* owner acquiring the lock and setting the owner field. If
>* we're an RT task that will live-lock because we won't let
> - * the owner complete.
> + * the owner complete. We
ull barriers which will force reloading from sem->count.
I think the patch is ok if you want it just for consistency anyway,
but please change $subject and changelog.
Regards,
Peter Hurley
> Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
> ---
> kernel/locking/rwsem-xadd
ull barriers which will force reloading from sem->count.
I think the patch is ok if you want it just for consistency anyway,
but please change $subject and changelog.
Regards,
Peter Hurley
> Signed-off-by: Davidlohr Bueso
> ---
> kernel/locking/rwsem-xadd.c | 2 +-
> 1 file
hanges look good to me and I've been running them cherry-picked on
my private tty-next testing tree since.
When Greg picks up -rc6 (not sure he was going to do that pre-merge window?),
I'd also like to push the devpts_mutex locking down into fs/devpts/inode.c,
but I'd be willing to do that later, if it's going to get in the way.
Regards,
Peter Hurley
n running them cherry-picked on
my private tty-next testing tree since.
When Greg picks up -rc6 (not sure he was going to do that pre-merge window?),
I'd also like to push the devpts_mutex locking down into fs/devpts/inode.c,
but I'd be willing to do that later, if it's going to get in the way.
Regards,
Peter Hurley
On 05/05/2016 03:08 AM, One Thousand Gnomes wrote:
> On Wed, 4 May 2016 16:07:44 -0700
> Peter Hurley <pe...@hurleysoftware.com> wrote:
>
>> Hi Julio,
>>
>> On 05/04/2016 04:00 PM, Julio Guerra wrote:
>>> Hi,
>>>
>>> When a tty
On 05/05/2016 03:08 AM, One Thousand Gnomes wrote:
> On Wed, 4 May 2016 16:07:44 -0700
> Peter Hurley wrote:
>
>> Hi Julio,
>>
>> On 05/04/2016 04:00 PM, Julio Guerra wrote:
>>> Hi,
>>>
>>> When a tty (here a slave pty) is set in noncanonical
es.
>>
>
> This does not appear in my man...
>
> Anyway, how do you explain the random behavior then?
A long standing bug in this read mode allows the asynchronous input
processing thread to race with the read() thread and become confused
about how much data remains.
I fixed this in 4.6; when I run your test on 4.6, it consistently
returns the full user buffer.
Regards,
Peter Hurley
es.
>>
>
> This does not appear in my man...
>
> Anyway, how do you explain the random behavior then?
A long standing bug in this read mode allows the asynchronous input
processing thread to race with the read() thread and become confused
about how much data remains.
I fixed this in 4.6; when I run your test on 4.6, it consistently
returns the full user buffer.
Regards,
Peter Hurley
os(3) man page:
* MIN > 0; TIME == 0: read(2) blocks until the lesser of MIN bytes or
the number of bytes requested are avail‐
able, and returns the lesser of these two values.
Regards,
Peter Hurley
> I isolated it in the following example (with VMIN = 5, received = 4, u
os(3) man page:
* MIN > 0; TIME == 0: read(2) blocks until the lesser of MIN bytes or
the number of bytes requested are avail‐
able, and returns the lesser of these two values.
Regards,
Peter Hurley
> I isolated it in the following example (with VMIN = 5, received = 4, u
art port access, part 3")
This should be fixed on most recent tty-testing and tty-next branches.
Please re-test on last tty-testing branch including commit
7da4b8b7378790dd1e4af1bb7522863127fa1438
("serial: core: Fix port mutex assert if lockdep disabled")
Regards,
Peter Hurley
> on test
art port access, part 3")
This should be fixed on most recent tty-testing and tty-next branches.
Please re-test on last tty-testing branch including commit
7da4b8b7378790dd1e4af1bb7522863127fa1438
("serial: core: Fix port mutex assert if lockdep disabled")
Regards,
Peter Hurley
> on test
On 04/29/2016 05:03 PM, Doug Anderson wrote:
> Hi,
>
> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley <pe...@hurleysoftware.com>
> wrote:
>
> On 04/29/2016 04:01 PM, Doug Anderson wrote:
> > * serial allows numbering devices by alias.
>
>
On 04/29/2016 05:03 PM, Doug Anderson wrote:
> Hi,
>
> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley
> wrote:
>
> On 04/29/2016 04:01 PM, Doug Anderson wrote:
> > * serial allows numbering devices by alias.
>
> Which is in fact a total nightmare.
>
eg., by performing minimal scan
serially and more expensive portion of the probe async.
Regards,
Peter Hurley
eg., by performing minimal scan
serially and more expensive portion of the probe async.
Regards,
Peter Hurley
On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote:
> Correct pin initialization on (H)SCIF:
> - RTS must be deasserted (it's active low),
> - SCK must be an input, as it may be used as the optional external
> clock input.
>
> Initial pin configuration must always be done:
> - Regardless
On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote:
> Correct pin initialization on (H)SCIF:
> - RTS must be deasserted (it's active low),
> - SCK must be an input, as it may be used as the optional external
> clock input.
>
> Initial pin configuration must always be done:
> - Regardless
pins.
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
pins.
Reviewed-by: Peter Hurley
On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote:
> Improve documentation for the (H)SCIF Serial Port Register:
> - Make it clear the RTS and CTS lines are active-low,
> - Document the bits related to the serial port's clock pin.
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote:
> Improve documentation for the (H)SCIF Serial Port Register:
> - Make it clear the RTS and CTS lines are active-low,
> - Document the bits related to the serial port's clock pin.
Reviewed-by: Peter Hurley
On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote:
> Replace open-coded variants of sci_getreg() by function calls, and drop
> intermediate variables where appropriate.
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
ted modem lines are
> not available. Invalid configurations specifying both GPIO RTS/CTS and
> dedicated RTS/CTS are rejected.
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote:
> Replace open-coded variants of sci_getreg() by function calls, and drop
> intermediate variables where appropriate.
Reviewed-by: Peter Hurley
ted modem lines are
> not available. Invalid configurations specifying both GPIO RTS/CTS and
> dedicated RTS/CTS are rejected.
Reviewed-by: Peter Hurley
't look at the CTS
> hardware line state at all.
>
> FWIW, this fixes the transmit path when hardware-assisted flow control
> is enabled, and userspace enables CRTSCTS.
> The receive path is still broken, as RTS is never asserted.
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
't look at the CTS
> hardware line state at all.
>
> FWIW, this fixes the transmit path when hardware-assisted flow control
> is enabled, and userspace enables CRTSCTS.
> The receive path is still broken, as RTS is never asserted.
Reviewed-by: Peter Hurley
bove, but must be before console_init()
3. Don't enumerate PNP0501 ACPI devices
These are going to be probed dynamically
4. Add ACPI/PNP custom device
Fixing the port type isn't supported now but could be
5. Modify the SERIAL_PORT_DFNS
Fixing the port type isn't supported now either but could be
Regards,
Peter Hurley
bove, but must be before console_init()
3. Don't enumerate PNP0501 ACPI devices
These are going to be probed dynamically
4. Add ACPI/PNP custom device
Fixing the port type isn't supported now but could be
5. Modify the SERIAL_PORT_DFNS
Fixing the port type isn't supported now either but could be
Regards,
Peter Hurley
On 04/28/2016 12:28 PM, Richard Guy Briggs wrote:
> On 16/04/27, Peter Hurley wrote:
>> On 04/27/2016 06:31 PM, Richard Guy Briggs wrote:
>>> On 16/04/22, Peter Hurley wrote:
>>>> On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
>>>>> The
On 04/28/2016 12:28 PM, Richard Guy Briggs wrote:
> On 16/04/27, Peter Hurley wrote:
>> On 04/27/2016 06:31 PM, Richard Guy Briggs wrote:
>>> On 16/04/22, Peter Hurley wrote:
>>>> On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
>>>>> The
On 04/27/2016 06:31 PM, Richard Guy Briggs wrote:
> On 16/04/22, Peter Hurley wrote:
>> On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
>>> The tty field was missing from AUDIT_LOGIN events.
>>>
>>> Refactor code to create a new function audit_get_tty
On 04/27/2016 06:31 PM, Richard Guy Briggs wrote:
> On 16/04/22, Peter Hurley wrote:
>> On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
>>> The tty field was missing from AUDIT_LOGIN events.
>>>
>>> Refactor code to create a new function audit_get_tty
On 04/27/2016 10:24 AM, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 12:20:02 Paul Moore wrote:
>>> diff --git a/include/linux/tty.h b/include/linux/tty.h
>>> index 3b09f235db66..17b247c94440 100644
>>> --- a/include/linux/tty.h
>>> +++ b/include/linux/tty.h
>>> @@ -371,6 +371,7 @@ extern
On 04/27/2016 10:24 AM, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 12:20:02 Paul Moore wrote:
>>> diff --git a/include/linux/tty.h b/include/linux/tty.h
>>> index 3b09f235db66..17b247c94440 100644
>>> --- a/include/linux/tty.h
>>> +++ b/include/linux/tty.h
>>> @@ -371,6 +371,7 @@ extern
On 04/26/2016 03:34 PM, Paul Moore wrote:
> On Fri, Apr 22, 2016 at 1:16 PM, Peter Hurley <pe...@hurleysoftware.com>
> wrote:
>> On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
>>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>>> index b40ed
On 04/26/2016 03:34 PM, Paul Moore wrote:
> On Fri, Apr 22, 2016 at 1:16 PM, Peter Hurley
> wrote:
>> On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
>>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>>> index b40ed5d..32cdafb 100644
>>>
On 04/26/2016 04:15 AM, Roman Pen wrote:
> The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
> with the following backtrace:
>
> [ 601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120
> seconds.
> [ 601.347574] Tainted: G O
On 04/26/2016 04:15 AM, Roman Pen wrote:
> The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
> with the following backtrace:
>
> [ 601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120
> seconds.
> [ 601.347574] Tainted: G O
On 04/26/2016 10:45 AM, Tejun Heo wrote:
> As long as what's happening is clearly documented, I think either is
> fine. I'm gonna go with Roman's mb patch for -stable fix but think
> it'd be nice to have a separate patch to consolidate the paths which
> clear PENDING and make them use xchg. If
On 04/26/2016 10:45 AM, Tejun Heo wrote:
> As long as what's happening is clearly documented, I think either is
> fine. I'm gonna go with Roman's mb patch for -stable fix but think
> it'd be nice to have a separate patch to consolidate the paths which
> clear PENDING and make them use xchg. If
Hi Tejun,
On 04/26/2016 08:15 AM, Tejun Heo wrote:
> Hello, Peter.
>
> On Mon, Apr 25, 2016 at 06:22:01PM -0700, Peter Hurley wrote:
>> This is the same bug I wrote about 2 yrs ago (but with the wrong fix).
>>
>> http://lkml.iu.edu/hypermail/linux/kernel/1402.2/04697
Hi Tejun,
On 04/26/2016 08:15 AM, Tejun Heo wrote:
> Hello, Peter.
>
> On Mon, Apr 25, 2016 at 06:22:01PM -0700, Peter Hurley wrote:
>> This is the same bug I wrote about 2 yrs ago (but with the wrong fix).
>>
>> http://lkml.iu.edu/hypermail/linux/kernel/1402.2/04697
ed barrier:
1. set_work_pool_and_clear_pending() has the same requirements as
clear_work_data(); note that both require write barrier before and
full barrier after.
2. xchg() et al imply full barrier before and full barrier after.
3. The naked barriers could be removed, while improving efficiency.
On x86, mov + mfence => xchg
4. Maybe fixes other hidden bugs.
For example, I'm wondering if reordering with set_work_pwq/list_add_tail
would be a problem; ie., what if work is visible on the worklist _before_
data is initialized by set_work_pwq()?
Regards,
Peter Hurley
ed barrier:
1. set_work_pool_and_clear_pending() has the same requirements as
clear_work_data(); note that both require write barrier before and
full barrier after.
2. xchg() et al imply full barrier before and full barrier after.
3. The naked barriers could be removed, while improving efficiency.
On x86, mov + mfence => xchg
4. Maybe fixes other hidden bugs.
For example, I'm wondering if reordering with set_work_pwq/list_add_tail
would be a problem; ie., what if work is visible on the worklist _before_
data is initialized by set_work_pwq()?
Regards,
Peter Hurley
1 - 100 of 4882 matches
Mail list logo
