[PATCH 1/1] drivers: net: cpsw: Fix TX_IN_SEL offset

is to: ... allow packets from both ethernet ports to be written into the FIFO without one port starving the other port. - AM335x ARM TRM Signed-off-by: John Ogness john.ogn...@linutronix.de --- drivers/net/ethernet/ti/cpsw.c |6 +++--- 1 file changed

[PATCH 1/1] uio: uio_fsl_elbc_gpcm: new driver

This driver provides UIO access to memory of a peripheral connected to the Freescale enhanced local bus controller (eLBC) interface using the general purpose chip-select mode (GPCM). Signed-off-by: John Ogness john.ogn...@linutronix.de --- There are currently drivers that use FCM and UPM modes

[PATCH 2/3] dmaenegine: edma: allow pause/resume for non-cyclic mode

-by: John Ogness john.ogn...@linutronix.de --- drivers/dma/edma.c |7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index bf09db7..88853af 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -300,8 +300,7 @@ static int

[PATCH 3/3] tty: serial: 8250: omap: synchronize rx_running

transfer using a buffer that is already setup to be used for a DMA transfer. This patch adds a spinlock to synchronize the rx_running flag and close the above mentioned window. Signed-off-by: John Ogness john.ogn...@linutronix.de --- drivers/tty/serial/8250/8250_omap.c | 65

[PATCH 1/3] ARM: common: edma: clear completion interrupts on stop

for the stopping channel it is ensured that no completion event will be generated after the stop. Signed-off-by: John Ogness john.ogn...@linutronix.de --- arch/arm/common/edma.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 5662a87..873dbfc

[PATCH 3/3] serial: 8250: omap: restore registers on shutdown

If DMA is active during a shutdown, a delayed restore of the registers may be pending. The restore must be performed after the DMA is stopped, otherwise the delayed restore remains pending and will fire upon the first DMA TX complete of a totally different serial session. Signed-off-by: John

[PATCH 0/3] serial: 8250: fix locking/race/cleanup issues

This patch series addresses some locking, race condition, and cleanup issues identified with the 8250 serial driver on omap boards. John Ogness (3): serial: 8250: unlock port for uart_write_wakeup() serial: 8250: move rx_running out of the bitfield serial: 8250: omap: restore registers

[PATCH 1/3] serial: 8250: unlock port for uart_write_wakeup()

() st_core.c:st_tty_wakeup() st_core.c:st_tx_wakeup() st_core.c:st_int_write() serial_core.c:uart_write() - locks port Signed-off-by: John Ogness john.ogn...@linutronix.de --- drivers/tty/serial/8250/8250_core.c |6 +- drivers/tty/serial/8250/8250_omap.c |6 +- 2 files changed, 10

[PATCH 2/3] serial: 8250: move rx_running out of the bitfield

That bitfield is modified by read + or + write operation. If someone sets any of the other two bits it might render the lock useless. Signed-off-by: John Ogness john.ogn...@linutronix.de Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/tty/serial/8250/8250.h |2

[PATCH] powerpc: IRQF_NO_SUSPEND not IRQF_TIMER for non-timer

Since gpio1 is not a timer, it also should not use IRQF_TIMER. Similar to commit ba461f094bab ("powerpc: Use IRQF_NO_SUSPEND not IRQF_TIMER for non-timer interrupts"). Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- drivers/macintosh/via-pmu.c |5 +++-- 1

[PATCH] powerpc: set IRQF_NO_THREAD for xmon/cascade handlers

The xmon and cascade irq handlers must not run as threads. pmac_pic_lock is already a raw_spinlock, but the irq flag IRQF_NO_THREAD needs to be set as well. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- arch/powerpc/platforms/powermac/pic.c |3 ++- 1 file changed, 2 inse

[PATCH] ARM: edma: fix residue race for cyclic

is a boolean that is set if any TR is being processed by either the EMDA3CC or EDMA3TC. By polling this register it is possible to ensure that the residue value returned is valid for immediate processing. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- arch/arm/common/

[PATCH] ARM: edma: special case slot limit workaround

-off-by: John Ogness <john.ogn...@linutronix.de> --- drivers/dma/edma.c | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 493c774..16bd193 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@

[PATCH v2] ARM: edma: fix residue race for cyclic

never hit a moment where no TR is being processed. To handle this, the SRC/DST is also polled to see if it changes. And as a last resort, a max loop count for the busy waiting exists to avoid an infinite loop. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- v1-v2 changes . r

[PATCH v2] ARM: edma: special case slot limit workaround

-off-by: John Ogness <john.ogn...@linutronix.de> --- v1-v2 changes . rebased for next-20151016 drivers/dma/edma.c | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 7eefbf1..f846935 100644 --- a/drive

Re: [PATCH v2] ARM: edma: fix residue race for cyclic

On 2015-10-16, Peter Ujfalusi <peter.ujfal...@ti.com> wrote: > On 10/16/2015 01:26 PM, John Ogness wrote: >> When retrieving the residue value for cyclic transfers, the >> SRC/DST fields of the active PaRAM are read. However, the AM335x >> Technical Reference Manua

Re: [PATCH] irqchip: omap-intc: fix spurious irq handling

in the interrupt priority conditions would cause the priority sorting to become invalid and thus cause the spurious interrupt. I'm not sure if we can/should do anything more than Sekhar's patch of acknowledging the spurious interrupt so the priority sorting algorithm can run again. John Ogness

[RFC PATCH] perf tools: add on-the-fly ctf conversion

A new argument --format is added to specify an alternate output format. If perf is compiled with libbabeltrace, support for the ctf format is available. An example: perf record --format ctf -e sched:sched_switch ls Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- Patch agains

Re: [PATCH 0/4] serial: omap: robustify for high speed transfers

the source of 500ms latency. All my experimentation and testing has showed that the latency occurs because the CPU has too much to handle. So I devised an implementation based on cyclic transfers and a ring buffer to free up the CPU. With the new implementation the CPU is not required to setup a DMA transfer every 112-192us. And if the CPU is only able to service a small percentage of the DMA completion interrupts, there can still exist full speed transfers with no data loss. Now if the tty layer is unable to handle 3Mbit because the CPU is so busy, then it may be necessary to offload more work from the CPU. For example, giving the tty its own high priority workqueue also eased the situation. Now the CPU will miss even more of the DMA completion interrupts, but the watchdog and ring buffer can allow that. Perhaps instead we should be discussing a new API where UART drivers can DMA bulk transfers directly to userspace. Until now my efforts have been focussed on improving performance of the existing framework. John Ogness [0] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1000296.html

Re: [PATCH 0/4] serial: omap: robustify for high speed transfers

cause the tty buffer kworker will buffer-overflow too and > its much more susceptible to timing latency (although not as bad now > that it's exclusively on the unbounded workqueue). Yes, you are correct. But I think that is a problem that should be addressed at the tty layer. John Ogness

[PATCH v4] dmaengine: edma: fix residue race for cyclic

may be active, polling may never hit a moment where no TR is being processed. To handle this, the SRC/DST is also polled to see if it changes. And as a last resort, a max loop count for the busy waiting exists to avoid an infinite loop. Signed-off-by: John Ogness <john.ogn...@linutronix

[PATCH] usb: musb: gadget: fix possible NULL pointer dereference

channel is already gone. Thus, the next time txstate() is called, there is a NULL pointer exception because the buffer is mapped but no DMA channel is allocated. This patch adds an extra call unmap_dma_buffer() before releasing the channel. Signed-off-by: John Ogness <john.ogn...@linutronix

Re: [PATCH 0/4] serial: omap: robustify for high speed transfers

ce that the eDMA is pulling the data from the FIFO. But only when the irq-omap-intc in involved. Tony, if you have any futher ideas, I'd be happy to try them out. Summary: If DMA is ever going to be re-enabled for am335x/8250_omap, then it will be necessary to return IRQ_HANDLED for the spurious

[PATCH v3] ARM: edma: fix residue race for cyclic

never hit a moment where no TR is being processed. To handle this, the SRC/DST is also polled to see if it changes. And as a last resort, a max loop count for the busy waiting exists to avoid an infinite loop. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- v1-v2 changes . r

[PATCH 3/4] tty: serial: 8250: omap: convert to using cyclic transfers

. This is necessary because the sDMA driver does not implement pause/resume correctly and therefore requires slightly different logic for the UART driver. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- patch against next-20160122 drivers/tty/serial/8250/8250.h |2 + drivers/tty/

[PATCH 4/4] tty: serial: 8250: omap: consume spurious interrupts

, the irq cannot be shared with other drivers. (It is never really shared anyway.) Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- patch against next-20160122 drivers/tty/serial/8250/8250_omap.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drive

[PATCH 0/4] serial: omap: robustify for high speed transfers

is resilent against latencies up to 500ms. This means that if no flow control is used, data will not be dropped until such latencies occur. If hardware flow control is used, real transfer speeds will not be affected until such latencies occur. Patch series against next-20160122. John Ogness (4

[PATCH 1/4] ARM: edma: special case slot limit workaround

. Signed-off-by: John Ogness <john.ogn...@linutronix.de> Acked-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- This particular patch was previously posted as v2: http://lkml.kernel.org/r/87a8rjt7p9.fsf...@linutronix.de It is being reposted because it is a necessary pre-requisite o

[PATCH 2/4] tty: serial: 8250: add optional spinlock arg to serial8250_rx_chars

serial8250_rx_chars() with other contexts. Since the port lock cannot be used for this synchronization, an optional spinlock argument is added. If non-NULL, this will be locked during the tty_flip_buffer_push() call. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- patch against next-20160122 d

[PATCH REPOST] tty: serial: 8250: omap: restore registers on shutdown

If DMA is active during a shutdown, a delayed restore of the registers may be pending. The restore must be performed after the DMA is stopped, otherwise the delayed restore remains pending and will fire upon the first DMA TX complete of a totally different serial session. Signed-off-by: John

[PATCH] tty: serial: 8250_omap: do not defer termios changes

ration is completed. Now set_termios will block until the operation is completed, proceed with the changes, then schedule any pending next operation. Commit message and forward port by John Ogness. Tested-by: John Ogness <john.ogn...@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bige..

Re: [PATCH] tty: serial: 8250_omap: do not defer termios changes

On 2016-04-05, Peter Hurley <pe...@hurleysoftware.com> wrote: > On 03/31/2016 01:41 AM, John Ogness wrote: >> It has been observed that the TX-DMA can stall > > Does this happen on any other OMAP part besides am335x? > I looked back over the LKML history of this and didn'

Re: [PATCH 3/3] serial: 8250: omap: restore registers on shutdown

c void omap_8250_dma_tx_complete(void *param) > p->ier |= UART_IER_THRI; > serial_port_out(>port, UART_IER, p->ier); > } > - > +out: > spin_unlock_irqrestore(>port.lock, flags); > } > > @@ -1216,6 +1228,7 @@ static int omap8250_probe(struct platform_device *pdev) > priv->omap8250_dma.rx_size = RX_TRIGGER; > priv->omap8250_dma.rxconf.src_maxburst = RX_TRIGGER; > priv->omap8250_dma.txconf.dst_maxburst = TX_TRIGGER; > + init_waitqueue_head(>termios_wait); > > if (of_machine_is_compatible("ti,am33xx")) > priv->habit |= OMAP_DMA_TX_KICK; > John Ogness

Re: [PATCH] tty: serial: 8250_omap: do not defer termios changes

On 2016-03-31, John Ogness <john.ogn...@linutronix.de> wrote: > diff --git a/drivers/tty/serial/8250/8250_omap.c > b/drivers/tty/serial/8250/8250_omap.c > index 6f76051..9459b4d 100644 > --- a/drivers/tty/serial/8250/8250_omap.c > +++ b/drivers/tty/serial/8250/8250_omap.

[PATCH] regulator: core: grab supply info before unlocking

It is necessary to check if there is a supply while still holding the regulator lock. Otherwise a theoretical race can occur that someone else can add a supply and then we incorrectly try to unlock that newly added regulator. Signed-off-by: John Ogness <john.ogn...@linutronix.de> ---

[PATCHv2] x86/mm/cpa: avoid wbinvd() for PREEMPT

g those pages individually can take up to 2200us, but the task remains fully preemptible during that time. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- v1-v2: changed CONFIG_PREEMPT_RT_FULL to CONFIG_PREEMPT It was suggested that wbinvd() is removed altogether, but any kernel

[PATCH] powerpc: Avoid reserving hugepages twice on PPC32

On PPC32, reserve_hugetlb_gpages() is already called in MMU_init(). Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- arch/powerpc/kernel/setup-common.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-co

Re: timer_create affinity

g a cyclic task. With that simple example you have complete control over the context of your task. This is necessary to avoid things like priority inversion and page-faults, and gives you control over things like affinity or cgroups. John Ogness [0] https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/cyclic

[PATCH] fs/proc: report eip/esp in /prod/PID/stat for coredumping

e and make the readout possible for tasks with the proper permissions and only if the target task has the PF_DUMPCORE flag set. Reported-by: Marco Felsch <marco.fel...@preh.de> Signed-off-by: John Ogness <john.ogn...@linutronix.de> Cc: sta...@vger.kernel.org Fixes: 0a1eb2d474ed ("

Re: Query: Crash is coming during /prod/PID/stat and do_exit of same task

e = 0x6 > >    struct task_struct.state -x 0xFFE80D8C2280 >   state = 0x40 I am confused why this task is in the TASK_PARKED state. What kind of task is this? > In our build both patches are there , > fs/proc: report eip/esp in /prod/PID/stat for coredumping > > and also  task.state has already set PF_DUMPCORE as it got the sigabrt > signal. John Ogness

Re: [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

nice helper > function. IMHO the original v1 patchset is the simplest codewise. And if the comments were updated to not mislead, it is the way I would want to go. Adding all the code to verbosely model a fast path just seems to me to add too much code to an already complex part of the VFS. John Ogness

Re: [PATCH 3/4] fs/dcache: Avoid the try_lock loop in d_delete()

if d_count is greater than 1 drop it and bugger off if !dentry_lock_inode(dentry) drop it and bugger off fetch inode clear CANT_MOUNT calculate isdir unlink_inode fsnotify shite John Ogness

[PATCH 3/4] fs/dcache: Avoid the try_lock loop in d_delete()

d_inode is still pointing to inode as it might have been changed after dropping dentry->d_lock. If it matches d_delete() can proceed, if not the whole operation has to be repeated. Implement this in a new function dentry_lock_inode() which will be used in a subsequent patch as well. Signed-off-by: Jo

[PATCH 0/4] fs/dcache: avoid trylock loops

hange while dentry->d_lock was dropped. If they changed, the whole operation must be repeated. John Ogness (4): fs/dcache: Remove stale comment from dentry_kill() fs/dcache: Move dentry_kill() below lock_parent() fs/dcache: Avoid the try_lock loop in d_delete() fs/dcache: Avoid the try_

[PATCH 1/4] fs/dcache: Remove stale comment from dentry_kill()

Commit 0d98439ea3c6 ("vfs: use lockred "dead" flag to mark unrecoverably dead dentries") removed the `ref' parameter in dentry_kill() but its documentation remained. Remove it. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- fs/dcache.c | 1 - 1 file changed,

[PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

functions drop dentry->lock briefly, this requires rechecking of the dentry content as it might have changed after dropping the lock. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- fs/dcache.c | 76 - 1 file changed, 60 ins

[PATCH 2/4] fs/dcache: Move dentry_kill() below lock_parent()

A subsequent patch will modify dentry_kill() to call lock_parent(). Move the dentry_kill() implementation "as is" below lock_parent() first. This will help simplify the review of the subsequent patch with dentry_kill() changes. Signed-off-by: John Ogness <john.ogn...@linutroni

Re: [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

On 2018-02-16, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Fri, Feb 16, 2018 at 7:09 AM, John Ogness <john.ogn...@linutronix.de> > wrote: >> dentry_kill() holds dentry->d_lock and needs to acquire both >> dentry->d_inode->i_lock and dentry-&g

[PATCH v2 1/6] fs/dcache: Remove stale comment from dentry_kill()

Commit 0d98439ea3c6 ("vfs: use lockred "dead" flag to mark unrecoverably dead dentries") removed the `ref' parameter in dentry_kill() but its documentation remained. Remove it. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- fs/dcache.c | 1 - 1 file changed,

[PATCH v2 5/6] fs/dcache: Avoid a try_lock loop in shrink_dentry_list()

locking order is now the same. First the inode is locked, then the parent. Signed-off-by: John Ogness <john.ogn...@linutronix.de> --- fs/dcache.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 082361939b84..e470d49daa5

[PATCH v2 0/6] fs/dcache: avoid trylock loops

ct order. After the locks are acquired it is necessary to verify that the relevant dentry members did not change while dentry->d_lock was dropped. If they changed, the whole operation must be repeated. John Ogness (6): fs/dcache: Remove stale comment from dentry_kill() fs/dcache: Move dentry_kill

[PATCH v2 3/6] fs/dcache: Avoid the try_lock loop in d_delete()

fy whether dentry->d_inode is still pointing to inode as it might have been changed after dropping dentry->d_lock. If it matches d_delete() can proceed, if not the whole operation has to be repeated. Implement this in a new function dentry_lock_inode() which will be used in a subs

[PATCH v2 4/6] fs/dcache: Avoid the try_lock loops in dentry_kill()

ons might drop dentry->lock briefly, this requires rechecking of the dentry content as it might have changed while the lock was dropped. dentry_lock_inode() performs the checks internally, but lock_parent() relies on the caller to perform the checks. Signed-off-by: John Ogness <john.og

[PATCH v2 6/6] fs/dcache: Avoid remaining try_lock loop in shrink_dentry_list()

previous dentry_kill() users. Then shrink_dentry_list() can use the dentry_kill() to cleanup the dispose list. This also has the benefit that the locking order is now the same. First the inode is locked, then the parent. Signed-off-by: John Ogness <john.ogn...@linu

[PATCH v2 2/6] fs/dcache: Move dentry_kill() below lock_parent()

A subsequent patch will modify dentry_kill() to call lock_parent(). Move the dentry_kill() implementation "as is" below lock_parent() first. This will help simplify the review of the subsequent patch with dentry_kill() changes. Signed-off-by: John Ogness <john.ogn...@linutroni

Re: [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

" thing is not a defense. > Would you jump off a bridge just because your friend did it? dentry_kill() calls both dentry_lock_inode() and lock_parent() in the common case. So by changing the semantics of lock_parent(), I am removing two "recheck in case I dropped" in the common case rather than just the one you pointed out. John Ogness

Re: [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

ut the re-checking, but about just how it > made that function look much more complicated. I understand what you are saying and I appreciate the comments. I will code up some variations for myself and try to pick the one that is the least complicated for my v2. John Ogness

Re: [PATCH v2 6/6] fs/dcache: Avoid remaining try_lock loop in shrink_dentry_list()

ur concerns about them but then by the end of the 6th patch we still end up where we are now, is that something that is palatable? IOW, do the patches only need (possibly a lot of) refinement or do you consider this approach fundamentally flawed? John Ogness

Re: [PATCH] proc: fix coredump vs read /proc/*/stat race

ode: 03 b7 a0 01 00 00 4c 8b 4c 24 70 4c 8b 44 24 78 4c 89 74 24 18 e9 91 f9 > ff ff f6 45 4d 02 0f 84 fd f7 ff ff 48 8b 45 40 48 89 ef <48> 8b 80 d8 3f 00 > 00 48 89 44 24 20 e8 9b 97 eb ff 48 89 44 24 > RIP: do_task_stat+0x8b4/0xaf0 RSP: c9607cc8 > CR2: 3

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

ck > for any work) going through dcache.c and related code; hopefully > this time I will get the documentation into postable shape ;-/ Thank you for all your help in getting these changes cleaned and correctly implemented so quickly. I've reviewed your latest trylock loop removal patches and found only 1 minor issue. I'll post that separately. John Ogness

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

d_shrink_add(dentry, list); > - spin_unlock(>d_lock); > - if (parent) > - spin_unlock(>d_lock); > - continue; > - } > - > + d_shrink_del(dentry); > + parent = dentry->d_parent; > __dentry_kill(dentry); > - > + if (parent == dentry) > + continue; > /* >* We need to prune ancestors too. This is necessary to prevent >* quadratic behavior of shrink_dcache_parent(), but is also John Ogness

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

if (dentry->d_lockref.count < 0) > can_free = dentry->d_flags & DCACHE_MAY_FREE; > @@ -1054,6 +1050,7 @@ static void shrink_dentry_list(struct list_head *list) > dentry_free(dentry); > continue; > } > + rcu_read_unlock(); > d_shrink_del(dentry); > parent = dentry->d_parent; > __dentry_kill(dentry); John Ogness

dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

On 2018-02-25, Al Viro wrote: > I'll play with cleaning up and reordering tomorrow after I get some > sleep. In the meanwhile, the current state of that set is at > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.dcache I have one comment on your new

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

cache.c and related code; hopefully > this time I will get the documentation into postable shape ;-/ Thank you for all your help in getting these changes cleaned and correctly implemented so quickly. I've reviewed your latest trylock loop removal patches and found only 1 minor issue. I'll post that separately. John Ogness

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

dentry_free(dentry); > continue; > } > - > - inode = dentry->d_inode; > - if (inode && unlikely(!spin_trylock(>i_lock))) { > - d_shrink_add(dentry, list); > -

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

f.count < 0) > can_free = dentry->d_flags & DCACHE_MAY_FREE; > @@ -1054,6 +1050,7 @@ static void shrink_dentry_list(struct list_head *list) > dentry_free(dentry); > continue; > } > + rcu_read_unlock(); > d_shrink_del(dentry); > parent = dentry->d_parent; > __dentry_kill(dentry); John Ogness

Re: [PATCH 3/4] fs/dcache: Avoid the try_lock loop in d_delete()

drop it and bugger off if !dentry_lock_inode(dentry) drop it and bugger off fetch inode clear CANT_MOUNT calculate isdir unlink_inode fsnotify shite John Ogness

[PATCH v2 4/6] fs/dcache: Avoid the try_lock loops in dentry_kill()

ons might drop dentry->lock briefly, this requires rechecking of the dentry content as it might have changed while the lock was dropped. dentry_lock_inode() performs the checks internally, but lock_parent() relies on the caller to perform the checks. Signed-off-

[PATCH v2 6/6] fs/dcache: Avoid remaining try_lock loop in shrink_dentry_list()

previous dentry_kill() users. Then shrink_dentry_list() can use the dentry_kill() to cleanup the dispose list. This also has the benefit that the locking order is now the same. First the inode is locked, then the parent. Signed-off-by: John

[PATCH v2 2/6] fs/dcache: Move dentry_kill() below lock_parent()

A subsequent patch will modify dentry_kill() to call lock_parent(). Move the dentry_kill() implementation "as is" below lock_parent() first. This will help simplify the review of the subsequent patch with dentry_kill() changes. Signed-off-by: John Ogness --- fs/dca

[PATCH v2 0/6] fs/dcache: avoid trylock loops

ct order. After the locks are acquired it is necessary to verify that the relevant dentry members did not change while dentry->d_lock was dropped. If they changed, the whole operation must be repeated. John Ogness (6): fs/dcache: Remove stale comment from dentry_kill() fs/dcache: Move dentry_kill

[PATCH v2 3/6] fs/dcache: Avoid the try_lock loop in d_delete()

fy whether dentry->d_inode is still pointing to inode as it might have been changed after dropping dentry->d_lock. If it matches d_delete() can proceed, if not the whole operation has to be repeated. Implement this in a new function dentry_lock_inode() which will be used in a subsequent patch

[PATCH v2 1/6] fs/dcache: Remove stale comment from dentry_kill()

Commit 0d98439ea3c6 ("vfs: use lockred "dead" flag to mark unrecoverably dead dentries") removed the `ref' parameter in dentry_kill() but its documentation remained. Remove it. Signed-off-by: John Ogness --- fs/dcache.c | 1 - 1 file changed, 1 deletion(-) diff --gi

[PATCH v2 5/6] fs/dcache: Avoid a try_lock loop in shrink_dentry_list()

locking order is now the same. First the inode is locked, then the parent. Signed-off-by: John Ogness --- fs/dcache.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 082361939b84..e470d49daa54 100644 --- a/fs/dcache.c +++ b/fs

[PATCH] fs/proc: report eip/esp in /prod/PID/stat for coredumping

e and make the readout possible for tasks with the proper permissions and only if the target task has the PF_DUMPCORE flag set. Reported-by: Marco Felsch Signed-off-by: John Ogness Cc: sta...@vger.kernel.org Fixes: 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in> /proc/PID/stat"

[PATCH] powerpc: Avoid reserving hugepages twice on PPC32

On PPC32, reserve_hugetlb_gpages() is already called in MMU_init(). Signed-off-by: John Ogness --- arch/powerpc/kernel/setup-common.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c index 94a9482..1d5d2de 100644

Re: [PATCH v2 6/6] fs/dcache: Avoid remaining try_lock loop in shrink_dentry_list()

nd of the 6th patch we still end up where we are now, is that something that is palatable? IOW, do the patches only need (possibly a lot of) refinement or do you consider this approach fundamentally flawed? John Ogness

dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

On 2018-02-25, Al Viro wrote: > I'll play with cleaning up and reordering tomorrow after I get some > sleep. In the meanwhile, the current state of that set is at > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.dcache I have one comment on your new dentry_kill()... > From

Re: Query: Crash is coming during /prod/PID/stat and do_exit of same task

k_struct.state -x 0xFFE80D8C2280 >   state = 0x40 I am confused why this task is in the TASK_PARKED state. What kind of task is this? > In our build both patches are there , > fs/proc: report eip/esp in /prod/PID/stat for coredumping > > and also  task.state has already set PF_DUMPCORE as it got the sigabrt > signal. John Ogness

[PATCH 3/4] fs/dcache: Avoid the try_lock loop in d_delete()

d_inode is still pointing to inode as it might have been changed after dropping dentry->d_lock. If it matches d_delete() can proceed, if not the whole operation has to be repeated. Implement this in a new function dentry_lock_inode() which will be used in a subsequent patch

[PATCH 0/4] fs/dcache: avoid trylock loops

hange while dentry->d_lock was dropped. If they changed, the whole operation must be repeated. John Ogness (4): fs/dcache: Remove stale comment from dentry_kill() fs/dcache: Move dentry_kill() below lock_parent() fs/dcache: Avoid the try_lock loop in d_delete() fs/dcache: Avoid the try_

[PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

functions drop dentry->lock briefly, this requires rechecking of the dentry content as it might have changed after dropping the lock. Signed-off-by: John Ogness --- fs/dcache.c | 76 - 1 file changed, 60 insertions(+), 16 deletions(-) diff -

[PATCH 2/4] fs/dcache: Move dentry_kill() below lock_parent()

A subsequent patch will modify dentry_kill() to call lock_parent(). Move the dentry_kill() implementation "as is" below lock_parent() first. This will help simplify the review of the subsequent patch with dentry_kill() changes. Signed-off-by: John Ogness --- fs/dca

[PATCH 1/4] fs/dcache: Remove stale comment from dentry_kill()

Commit 0d98439ea3c6 ("vfs: use lockred "dead" flag to mark unrecoverably dead dentries") removed the `ref' parameter in dentry_kill() but its documentation remained. Remove it. Signed-off-by: John Ogness --- fs/dcache.c | 1 - 1 file changed, 1 deletion(-) diff --gi

Re: [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

On 2018-02-16, Linus Torvalds wrote: > On Fri, Feb 16, 2018 at 7:09 AM, John Ogness > wrote: >> dentry_kill() holds dentry->d_lock and needs to acquire both >> dentry->d_inode->i_lock and dentry->d_parent->d_lock. This cannot be >> done with spin_loc

Re: [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

you jump off a bridge just because your friend did it? dentry_kill() calls both dentry_lock_inode() and lock_parent() in the common case. So by changing the semantics of lock_parent(), I am removing two "recheck in case I dropped" in the common case rather than just the one you pointed out. John Ogness

Re: [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

w it > made that function look much more complicated. I understand what you are saying and I appreciate the comments. I will code up some variations for myself and try to pick the one that is the least complicated for my v2. John Ogness

Re: [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()

original v1 patchset is the simplest codewise. And if the comments were updated to not mislead, it is the way I would want to go. Adding all the code to verbosely model a fast path just seems to me to add too much code to an already complex part of the VFS. John Ogness

[PATCH 1/1] printk: fix syslog_print_all() 1024-byte edge case

test.sh 929 kmsg: klogctl(SYSLOG_ACTION_READ_ALL) with buffer of 1024 bytes read 0 bytes from klogctl Fixes: 3ce9a7c0ac28 ("printk() - restore prefix/timestamp printing for multi-newline strings") Signed-off-by: John Ogness --- kernel/printk/printk.c | 2 +- 1 file changed, 1 insertio

[PATCH 0/1] another size-1 fixup from msg_print_text()

message as you feel fit. This change as a separate commit is important because I will be to posting a series that consolidates this code and I don't want my consolidation secretly fixing such long-standing issues. John Ogness (1): printk: fix syslog_print_all() 1024-byte edge case kernel/printk

Re: [PATCH 1/1] printk: fix syslog_print_all() 1024-byte edge case

On 2021-01-20, John Ogness wrote: > If klogctl(SYSLOG_ACTION_READ_ALL) is called with a buffer size > of 1024 and the message data will exactly fill 1024 bytes and the > last message of that is multi-line, the last line of the last > message will be silently dropped. Sorry, plea

Re: [PATCH] printk: ringbuffer: fix line counting

_size = min_t(u16, buf_size, len); memcpy([0], data, data_size); } if (line_count) *line_count = count_lines(data, data_size); return true; John Ogness

[PATCH] printk: kmsg_dump: revert msg_print_text() workaround

less ringbuffer"), msg_print_text() was replaced by record_print_text(), which will fill the full buffer. Therefore, the workaround is now incorrectly assuming less data can fit into the buffer. Revert the workaround. Fixes: 896fbe20b4e2 ("printk: use the lockless ringbuffer") Signed-off-by

Re: RFC: printk: kmsg_dump_get_line_nolock() buffer overflow

estore the original record_printk_text() behavior > and add the comment explaining why it is done this way. OK. > And I would even explicitly add the trailing '\0' as suggested at > https://lore.kernel.org/lkml/20190710121049.rwhk7fknfzn3c...@pathway.suse.cz/#t OK. But then this becomes official

[PATCH] printk: fix buffer overflow potential for print_text()

noia sakes, add a terminator after the text data. And finally, document this behavior so that it is clear that only size-1 bytes are used and a terminator is added. Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer") Signed-off-by: John Ogness --- kernel/

Re: [PATCH] printk: fix buffer overflow potential for print_text()

t normally get truncated (800+ characters) this patch simply adds a string terminator. I do not see how that could possibly cause this kind of damage. When this triggers, there is nothing happening with consoles registering or deregistering, right? The string terminator (kernel/printk/printk.c:1402) is only added for paranoia. If you comment that out, this patch will have no effect (for "normal" length lines). I would be curious if that somehow makes a difference for you. John Ogness

Re: KASAN: slab-out-of-bounds Write in record_print_text

kaller.appspot.com/x/repro.c?x=17aea4e8d0 > > The issue was bisected to: > > commit f0e386ee0c0b71ea6f7238506a4d0965a2dbef11 > Author: John Ogness > Date: Thu Jan 14 17:04:12 2021 + > > printk: fix buffer overflow potential for print_text() Thank you syzbot

Re: [PATCH] printk: fix buffer overflow potential for print_text()

On 2021-01-19, Sergey Senozhatsky wrote: >>> John, how did you spot these problems? >> >> I am preparing my series to remove the logbuf_lock, which also >> refactors and consolidates code from syslog_print_all() and >> kmsg_dump_get_buffer(). While testing/verifying my series, I noticed >> the

[PATCH] printk: fix kmsg_dump_get_buffer length calulations

of records that can fit into the buffer. Fixes: e2ae715d66bf ("kmsg - kmsg_dump() use iterator to receive log buffer content") Signed-off-by: John Ogness --- kernel/printk/printk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/printk/printk.c b/kernel/print

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

ing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now. John Ogness

  1   2   3   4   5   6   7   >