Re: [PATCH for-next v3 1/7] RDMA/rxe: Convert triple tasklets to use workqueue

patch replaces the tasklets with a workqueue, but still allows direct- > call of works from softirq context if it is obvious that MRs are not going > to be accessed and there is no work being processed in the workqueue. There are already at least two patch sets that do this waiting

Re: [RFC PATCH 2/7] RDMA/rxe: Convert the triple tasklets to workqueues

noticeably better for one IO stream but for 2 or more IO streams work queues were better because we could place the work on separate cpus. Tasklets have a tendency to bunch up on the same cpu. I am interested in how Matsuda got better/same performance for work queues. Bob

Re: [RFC PATCH 2/7] RDMA/rxe: Convert the triple tasklets to workqueues

rxe_do_work); > + > + work->state = WQ_STATE_START; > + spin_lock_init(>state_lock); > + > + return 0; > +} > + > +void rxe_cleanup_work(struct rxe_work *work) > +{ > + bool idle; > + > + /* > + * Mark the work, then wait for it to finish. It might be > + * running in a non-workqueue (direct call) context. > + */ > + work->destroyed = true; > + flush_workqueue(work->worker); > + > + do { > + spin_lock_bh(>state_lock); > + idle = (work->state == WQ_STATE_START); > + spin_unlock_bh(>state_lock); > + } while (!idle); > + > + destroy_workqueue(work->worker); > +} > + > +void rxe_run_work(struct rxe_work *work, int sched) > +{ > + if (work->destroyed) > + return; > + > + /* busy-loop while qp reset is in progress */ > + while (atomic_read(>suspended)) > + continue; > + > + if (sched) > + queue_work(work->worker, >work); > + else > + rxe_do_work(>work); > +} > + > +void rxe_disable_work(struct rxe_work *work) > +{ > + atomic_inc(>suspended); > + flush_workqueue(work->worker); > +} > + > +void rxe_enable_work(struct rxe_work *work) > +{ > + atomic_dec(>suspended); > +} > diff --git a/drivers/infiniband/sw/rxe/rxe_wq.h > b/drivers/infiniband/sw/rxe/rxe_wq.h > new file mode 100644 > index ..b40af598dcc0 > --- /dev/null > +++ b/drivers/infiniband/sw/rxe/rxe_wq.h > @@ -0,0 +1,71 @@ > +/* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */ > +/* > + * Copyright (c) 2016 Mellanox Technologies Ltd. All rights reserved. > + * Copyright (c) 2015 System Fabric Works, Inc. All rights reserved. > + */ > + > +#ifndef RXE_WQ_H > +#define RXE_WQ_H > + > +enum { > + WQ_STATE_START = 0, > + WQ_STATE_BUSY = 1, > + WQ_STATE_ARMED = 2, > +}; > + > +/* > + * data structure to describe a 'work' which is a short > + * function that returns 0 as long as it needs to be > + * called again. > + */ > +struct rxe_work { > + void*obj; > + struct workqueue_struct *worker; > + struct work_struct work; > + int state; > + spinlock_t state_lock; /* spinlock for work state */ > + void*arg; > + int (*func)(void *arg); > + int ret; > + charname[16]; > + booldestroyed; > + atomic_tsuspended; /* used to {dis,en}able workqueue */ > +}; > + > +/* > + * init rxe_work structure > + * arg => parameter to pass to fcn > + * func => function to call until it returns != 0 > + */ > +int rxe_init_work(void *obj, struct rxe_work *work, > + void *arg, int (*func)(void *), char *name); > + > +/* cleanup work */ > +void rxe_cleanup_work(struct rxe_work *work); > + > +/* > + * raw call to func in loop without any checking > + * can call when workqueues are suspended. > + */ > +int __rxe_do_work(struct rxe_work *work); > + > +/* > + * common function called by any of the main workqueues > + * If there is any chance that there is additional > + * work to do someone must reschedule the work before > + * leaving > + */ > +void rxe_do_work(struct work_struct *w); > + > +/* run a work, else schedule it to run as a workqueue, The decision > + * to run or schedule workqueue is based on the parameter sched. > + */ > +void rxe_run_work(struct rxe_work *work, int sched); > + > +/* keep a work from scheduling */ > +void rxe_disable_work(struct rxe_work *work); > + > +/* allow work to run */ > +void rxe_enable_work(struct rxe_work *work); > + > +#endif /* RXE_WQ_H */ Daiskuke, We (hpe) have an internal patch set that also allows using work queues instead of tasklets. There is a certain amount of work to allow control over cpu assignment from ulp or application level. This is critical for high performance in multithreaded IO applications. It would be in both of our interests if we could find a common implementation that works for everyone. Perhaps we could arrange for a call to discuss? Bob Pearson

Re: [PATCH 00/18] Rid W=1 warnings from GFS2

out them. I wanted to merge them, but Andreas is concerned that there may be some cases in which we should get rid of parameter descriptions altogether. So I've been waiting for Andreas to review them all before we push them. Also, the dir.c patch might be out of date because of a patch I recently did that was recently added to for-next. I'll work with Andreas to expedite them so they can go into the next merge window. Regards, Bob Peterson

Re: [PATCH] gfs2: make function gfs2_make_fs_ro() to void type

ger needed the variable "error" so I removed it to avoid warnings. https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next=0e787a0bfabb8be323f575d5cdda48e607840eb5 Regards, Bob Peterson

Re: [PATCH] gfs2: Remove unneeded return variable

ike it. However, since gfs2_make_fs_ro always returns 0, we should also be able to make it a void function instead of int, and change its callers to not act on any return code. Regards, Bob Peterson Red Hat File Systems

Re: [PATCH] hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist

of stuff to the Dell Developers ... Cheers Bob On Thu, 28 Jan 2021 at 11:46, Guenter Roeck wrote: > > On 1/27/21 3:00 PM, Pali Rohár wrote: > > On Monday 25 January 2021 21:21:30 Pali Rohár wrote: > >> On Monday 25 January 2021 12:19:38 Guenter Roeck wrote: > >>&

Re: [PATCH] hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist

Bob On Wed, 27 Jan 2021 at 19:19, Pali Rohár wrote: > > On Tuesday 26 January 2021 00:15:13 Tom Hebb wrote: > > Bob reports that blacklisting the fan type label is not sufficient. > > See his message to me below. > > Ok! Thank you for confirmation. > > And my seco

Re: [PATCH] fs: Fix freeze_bdev()/thaw_bdev() accounting of bd_fsfreeze_sb

gt; something about it, like refuse to mount a frozen device. Perhaps it already > does that; I'll need to do some research. After some experiments, I've determined that my fears about the count are unfounded. Consider my patch withdrawn. Sorry for the noise. Bob Peterson

Re: [PATCH] fs: Fix freeze_bdev()/thaw_bdev() accounting of bd_fsfreeze_sb

er error. Still, it seems like we should do something about it, like refuse to mount a frozen device. Perhaps it already does that; I'll need to do some research. Like I said, I don't know this code. I'm just trying to fix a problem I observed. I'll defer to the experts. Regards, Bob Peterson

[fs PATCH] fs: fix freeze count problem in freeze_bdev

e: "unable to handle page fault for address." This patch adds the necessary decrement of bd_fsfreeze_count for that error path. It also adds code to set the bd_fsfreeze_sb to NULL when the last reference is reached in thaw_bdev. Signed-off-by: Bob Peterson --- fs/block_dev.c | 5

Re: [PATCH] fs: Fix freeze_bdev()/thaw_bdev() accounting of bd_fsfreeze_sb

- Original Message - > Can someone pick this up? Maybe through Jens' block tree as that is > where my commit this is fixing up came from. Christoph and Al, Here is my version: Bob Peterson fs: fix freeze count problem in freeze_bdev Before this patch, if you tried to freeze a

Re: [PATCH] fs: Fix freeze_bdev()/thaw_bdev() accounting of bd_fsfreeze_sb

freeze_count++; > > + else > > + bdev->bd_fsfreeze_sb = NULL; > > out: > > mutex_unlock(>bd_fsfreeze_mutex); > > return error; > > -- > > 2.29.2.729.g45daf8777d-goog > ---end quoted text--- > > Funny you should ask. I came across this bug in my testing of gfs2 and my patch is slightly different. I was wondering who to send it to. Perhaps Viro? Regards, Bob Peterson

Re: [PATCH v2] fs: amend SLAB_RECLAIM_ACCOUNT on gfs2 related slab cache

; v2: add gfs2_glock_cachep for same operation > --- Hi, Thanks. Your patch is now pushed to the linux-gfs2/for-next branch. I cleaned up the description a bit. For example, I changed "fs:" to "gfs2:" to conform to other gfs2 patches. Regards, Bob Peterson

Re: [PATCH] fs: amend SLAB_RECLAIM_ACCOUNT on gfs2_quotad_cachep

_quotad_cachep) > goto fail_cachep6; > > -- > 1.9.1 > > Hi, Thanks for the patch. We should also do this for gfs2_glock_cachep. Can you add that to your patch? Regards, Bob Peterson

Re: [PATCH 0/3] block: blk_interposer - Block Layer Interposer

he core block layer. >> > Which is my plan, too. > > I'll be working with the Veeam folks to present a joint patchset (including > the DM bits) for the next round. > Besides the dm approach, do you think Veeam's original requirement is a good use case of "block/bpf: add eBPF based block layer IO filtering"? https://lwn.net/ml/bpf/20200812163305.545447-1-leah.ruman...@gmail.com/ Thanks, Bob

Nouveau video --- [ cut here ] ----- crash dump 5.10.0-rc6

/0x3b0 [39019.426697]  ? process_one_work+0x370/0x370 [39019.426699]  kthread+0xfe/0x140 [39019.426701]  ? kthread_park+0x90/0x90 [39019.426704]  ret_from_fork+0x22/0x30 [39019.426706] ---[ end trace d512d675211c738c ]--- [39021.426751] [ cut here ] Thanks in advance, Bob

nouveau stalling on stable kernel 5.9.0

    0c10: cf00 --- If you need anything else, please email me directly as I'm not on the list. Bob

Re: [PATCH v3 0/3] Support NVIDIA Tegra-based Ouya game console

t;GPL") declaration added. Lukas, did you get clear permission to license the driver as GPL? Alternatively, kernel developers with greater legal or Ouya knowledge, is this actually a concern or is it nothing to worry about? Thanks, Bob On 07/10/2020 08:22, Stefan Agner wrote: > Hi Peter, > &g

Re: [Cluster-devel] general protection fault in gfs2_withdraw

nd wait for it to > finish > > Andy Hi Andy. Thanks for your analysis. I suspect you're right. It's probably another exception to the rule. We knew there would be a few of those with 601ef0d52e96, such as the one we made for "withdrawing during withdraw". We should probably just add a check for NULL and make it do the right thing. Regards, Bob Peterson

nouveau in kernel v5.9-rc7

s I am not on the list, Bob

kernel v5.9-rc6 not compiling

Hi.  I've been building kernels weekly since 1996.  Never had one not build before today.  v5.9-rc6 does not compile. Error:   AR  drivers/gpu/built-in.a make: *** [Makefile:1784: drivers] Error 2   CALL    scripts/checksyscalls.sh   CALL    scripts/atomic/check-atomics.sh   DESCEND 

Re: [PATCH 4.19 142/206] gfs2: fix use-after-free on transaction ail lists

- Original Message - > Hi Bob, hi Greg, > > On Fri, Sep 11, 2020 at 08:49:14AM -0400, Bob Peterson wrote: > > - Original Message - > > > On Fri, Sep 11, 2020 at 08:08:35AM -0400, Bob Peterson wrote: > > > > - Original Message - > >

Re: [PATCH] fs: omfs: use kmemdup() rather than kmalloc+memcpy

On Wed, Sep 09, 2020 at 08:04:15PM +0100, Alex Dewar wrote: > On 24/08/2020 22:17, Alex Dewar wrote: > > Issue identified with Coccinelle. > Gentle ping? > > > > Signed-off-by: Alex Dewar Acked-by: Bob Copeland However, I don't have a git tree for OMFS so you'll nee

Re: [PATCH 4.19 142/206] gfs2: fix use-after-free on transaction ail lists

- Original Message - > On Fri, Sep 11, 2020 at 08:08:35AM -0400, Bob Peterson wrote: > > - Original Message - > > > On Thu, Sep 10, 2020 at 09:43:19PM +0200, Salvatore Bonaccorso wrote: > > > > Hi, > > > > > > > > On Tue, Jun

Re: [PATCH 4.19 142/206] gfs2: fix use-after-free on transaction ail lists

- Original Message - > On Thu, Sep 10, 2020 at 09:43:19PM +0200, Salvatore Bonaccorso wrote: > > Hi, > > > > On Tue, Jun 23, 2020 at 09:57:50PM +0200, Greg Kroah-Hartman wrote: > > > From: Bob Peterson > > > > > > [ Upstream

Re: [PATCH v3] dm crypt: add flags to optionally bypass dm-crypt workqueues

_type_t type, > DMEMIT(" same_cpu_crypt"); > if (test_bit(DM_CRYPT_NO_OFFLOAD, >flags)) > DMEMIT(" submit_from_crypt_cpus"); > + if (test_bit(DM_CRYPT_NO_READ_WORKQUEUE, >flags)) > + DMEMIT(" no_read_workqueue"); > + if (test_bit(DM_CRYPT_NO_WRITE_WORKQUEUE, >flags)) > + DMEMIT(" no_write_workqueue"); > if (cc->on_disk_tag_size) > DMEMIT(" integrity:%u:%s", > cc->on_disk_tag_size, cc->cipher_auth); > if (cc->sector_size != (1 << SECTOR_SHIFT)) > @@ -3320,7 +3354,7 @@ static void crypt_io_hints(struct dm_target *ti, struct > queue_limits *limits) > > static struct target_type crypt_target = { > .name = "crypt", > - .version = {1, 21, 0}, > + .version = {1, 22, 0}, > .module = THIS_MODULE, > .ctr= crypt_ctr, > .dtr= crypt_dtr, > This patch looks good to me, I tested with null_blk and got similar improvement. Thanks! Reviewed-by: Bob Liu

Re: [dm-devel] [PATCH v2] dm crypt: add flags to optionally bypass dm-crypt workqueues

), run=27753-27753msec WRITE: bw=149MiB/s (156MB/s), 149MiB/s-149MiB/s (156MB/s-156MB/s), io=4124MiB (4324MB), run=27753-27753msec Looks like the result is worse after this patch, or I may miss something.. Regards, Bob > echo '0 8388608 crypt capi:ecb(cipher_null) - 0 /dev/ram0 0' | \ > sudo dm

Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

On 6/29/20 8:37 AM, Lai Jiangshan wrote: > On Mon, Jun 29, 2020 at 8:13 AM Bob Liu wrote: >> >> On 6/28/20 11:54 PM, Lai Jiangshan wrote: >>> On Thu, Jun 11, 2020 at 6:29 PM Bob Liu wrote: >>>> >>>> Current code always set 'Unbound && max_a

Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

On 6/29/20 8:37 AM, Lai Jiangshan wrote: > On Mon, Jun 29, 2020 at 8:13 AM Bob Liu wrote: >> >> On 6/28/20 11:54 PM, Lai Jiangshan wrote: >>> On Thu, Jun 11, 2020 at 6:29 PM Bob Liu wrote: >>>> >>>> Current code always set 'Unbound && max_a

Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

On 6/28/20 11:54 PM, Lai Jiangshan wrote: > On Thu, Jun 11, 2020 at 6:29 PM Bob Liu wrote: >> >> Current code always set 'Unbound && max_active == 1' workqueues to ordered >> implicitly, while this may be not an expected behaviour for some use cases. >> &g

Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

ping.. On 6/11/20 6:07 PM, Bob Liu wrote: > Current code always set 'Unbound && max_active == 1' workqueues to ordered > implicitly, while this may be not an expected behaviour for some use cases. > > E.g some scsi and iscsi workqueues(unbound && max_active = 1) wa

[PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

ut their cpumask can't be changed because WQ_ORDERED is set implicitly. This patch adds a flag __WQ_ORDERED_DISABLE and also create_singlethread_workqueue_noorder() to offer an new option. Signed-off-by: Bob Liu --- include/linux/workqueue.h | 4 kernel/workqueue.c| 4 +++- 2

[PATCH 2/2] scsi: register sysfs for scsi/iscsi workqueues

This patch enable setting cpu affinity through "cpumask" for below scsi/iscsi workqueues, so as to get better isolation. - scsi_wq_* - scsi_tmf_* - iscsi_q_xx - iscsi_eh Signed-off-by: Bob Liu --- drivers/scsi/hosts.c| 4 ++-- drivers/scsi/libiscsi.c | 2 +

[tip: x86/urgent] x86_64: Fix jiffies ODR violation

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: d8ad6d39c35d2b44b3d48b787df7f3359381dcbf Gitweb: https://git.kernel.org/tip/d8ad6d39c35d2b44b3d48b787df7f3359381dcbf Author:Bob Haarman AuthorDate:Tue, 02 Jun 2020 12:30:59 -07:00 Committer

[PATCH v2] x86_64: fix jiffies ODR violation

y: Nathan Chancellor Reported-by: Alistair Delva Suggested-by: Fangrui Song Debugged-by: Nick Desaulniers Debugged-by: Sami Tolvanen Signed-off-by: Bob Haarman Reviewed-by: Andi Kleen Reviewed-by: Josh Poimboeuf --- v2: * Changed commit message as requested by Josh Poimboeuf (no code change

Re: [PATCH 1/1] blk-mq: get ctx in order to handle BLK_MQ_S_INACTIVE in blk_mq_get_tag()

.q = rq->q, > + .ctx = rq->mq_ctx, > .hctx = rq->mq_hctx, > .flags = BLK_MQ_REQ_NOWAIT, > .cmd_flags = rq->cmd_flags, > Nice catch! Reviewed-by: Bob Liu

Re: [PATCH] block/bio-integrity: don't free 'buf' if bio_integrity_add_page() failed

KERN_ERR "could not attach integrity payload\n"); > - kfree(buf); > status = BLK_STS_RESOURCE; > goto err_end_io; > } > Looks good to me. Reviewed-by: Bob Liu

Re: [PATCH] x86_64: fix jiffies ODR violation

On Mon, May 18, 2020 at 08:17:42PM -0700, Andi Kleen wrote: > > Instead, we can avoid the ODR violation by matching other arch's by > > defining jiffies only by linker script. For -fno-semantic-interposition > > + Full LTO, there is no longer a global definition of jiffies for the > > compiler to

[PATCH] x86_64: fix jiffies ODR violation

ncellor Reported-by: Alistair Delva Suggested-by: Fangrui Song Debugged-by: Nick Desaulniers Debugged-by: Sami Tolvanen Signed-off-by: Bob Haarman --- arch/x86/kernel/time.c| 4 arch/x86/kernel/vmlinux.lds.S | 4 ++-- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/arc

Re: [PATCH] fs: omfs: Use kmemdup rather than duplicating its implementation in omfs_get_imap

e.kernel.org/lkml/20190703163158.937-1-huangfq.dax...@gmail.com/ -- Bob Copeland %% https://bobcopeland.com/

Re: [PATCH net-next v5] sched: Add dualpi2 qdisc

Dave, On 28/08/2019 17:55, Dave Taht wrote: On Wed, Aug 28, 2019 at 7:00 AM Bob Briscoe wrote: Olivier, Dave, On 23/08/2019 13:59, Tilmans, Olivier (Nokia - BE/Antwerp) wrote: as best as I can tell (but could be wrong) the NQB idea wants to put something into the l4s fast queue? Or is NQB

Re: [PATCH] omfs: Fix a memory leak bug

his issue, > go to the 'nomem_free' label to free 'sbi->s_imap'. Nice catch, thanks. Acked-by: Bob Copeland -- Bob Copeland %% https://bobcopeland.com/

Re: [PATCH 18/20] fs: omfs: Initialize filesystem timestamp ranges

t know if it should be s64 rather than u64, but considering that none of the devices with this filesystem ever exposed dates to users in the negative era, it should be fine. Acked-by: Bob Copeland -- Bob Copeland %% https://bobcopeland.com/

Re: [PATCH] fs/omfs: make use of kmemdup

On Sun, Jul 21, 2019 at 04:53:27PM +0530, Hariprasad Kelam wrote: > kmalloc + memcpy can be replaced with kmemdup. > > fix below issue reported by coccicheck > ./fs/omfs/inode.c:366:9-16: WARNING opportunity for kmemdup > > Signed-off-by: Hariprasad Kelam Thanks! Acke

Re: [PATCH v2 32/35] omfs: Use kmemdup rather than duplicating its implementation

ility, leads to smaller code and also reduce the chances of mistakes. > Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy. Acked-by: Bob Copeland -- Bob Copeland %% https://bobcopeland.com/

NFS oops

dfc946600 R15: 7ffdfc9482df ...and the oops repeats I'm running kernel Linux freedom 5.2.0-rc6 #1 SMP Sun Jun 23 18:31:56 MDT 2019 x86_64 x86_64 x86_64 GNU/Linux If you need more info, please reply to me directly as I'm not on the list, Thanks, Bob

NFS won't finish

NAS machine is using the ext4 filesystem and I don't think its a filesystem size limit. Thanks in advance, please email me directly as I am not on the list, Bob

GFS2: Pull request (merge window)

Hi Linus, Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd: Linux 5.0-rc3 (2019-01-21 13:14:44 +1300

[PATCH] Revert "gfs2: read journal in large chunks to locate the head"

This reverts commit 2a5f14f279f59143139bcd1606903f2f80a34241. This patch causes xfstests generic/311 to fail. Reverting this for now until we have a proper fix. Signed-off-by: Abhi Das Signed-off-by: Bob Peterson --- fs/gfs2/glops.c | 1 - fs/gfs2/log.c| 4 +- fs/gfs2/lops.c

GFS2: Pull request (merge window)

Hi Linus, Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson The following changes since commit 40e020c129cfc991e8ab4736d2665351ffd1468d: Linux 4.20-rc6 (2018-12-09 15:31:00 -0800

Re: [RFC PATCH v1 0/7] Block/XFS: Support alternative mirror device retry

n't know how to do fs-metadata verify. => md0: fs verify fail, retry md1(preserve md2). Then md2 will never be retried even dev3 may also has the right copy. Unless the upper layer device(md0) can know the amount of copy is 4 instead of 2? And need a way to handle the mapping. Did I miss so

GFS2: Pull request (merge window)

Hi Linus, Welcome back. Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson The following changes since commit 050cdc6c9501abcd64720b8cc3e7941efee9547d: Merge git://git.kernel.org/pub

GFS2: Pull request (merge window)

Hi Linus, Welcome back. Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson The following changes since commit 050cdc6c9501abcd64720b8cc3e7941efee9547d: Merge git://git.kernel.org/pub

Re: linux-next: Signed-off-by missing for commit in the gfs2 tree

- Original Message - > Hi all, > > Commit > > b7f5a2cd27b7 ("GFS2: Flush the GFS2 delete workqueue before stopping the > kernel threads") > > is missing a Signed-off-by from its committer. > > -- > Cheers, > Stephen Rothwell Fixed now. Sorry about that. Regards, Bob Peterson

Re: linux-next: Signed-off-by missing for commit in the gfs2 tree

- Original Message - > Hi all, > > Commit > > b7f5a2cd27b7 ("GFS2: Flush the GFS2 delete workqueue before stopping the > kernel threads") > > is missing a Signed-off-by from its committer. > > -- > Cheers, > Stephen Rothwell Fixed now. Sorry about that. Regards, Bob Peterson

[BUG] 4.18-rcX iptables regression

With iptables v1.6.0 and kernel version 4.18-rc7, "iptables [-t table] -L" produces diagnostic output to the effect of not being able to find the table. Kernel version 4.17.0 and earlier work fine. --Bob

[BUG] 4.18-rcX iptables regression

With iptables v1.6.0 and kernel version 4.18-rc7, "iptables [-t table] -L" produces diagnostic output to the effect of not being able to find the table. Kernel version 4.17.0 and earlier work fine. --Bob

Re: [PATCH] ath10k: transmit queued frames after waking queues

emantic of "tx fields under tx_lock." On the other hand, maybe it's just me, but I tend to look askance at just-in-case READ_ONCEs sprinkled about. -- Bob Copeland %% https://bobcopeland.com/

Re: [PATCH] ath10k: transmit queued frames after waking queues

emantic of "tx fields under tx_lock." On the other hand, maybe it's just me, but I tend to look askance at just-in-case READ_ONCEs sprinkled about. -- Bob Copeland %% https://bobcopeland.com/

Re: [PATCH] ath10k: transmit queued frames after waking queues

ar); > > > + > > > > Just sanity checking - what's protecting htt->num_pending_tx? or is it > > serialised some other way? [...] > I can't see that any of the examples applies, but let's add READ_ONCE(), > to make sure that the compiler doesn't try to optimize thi

Re: [PATCH] ath10k: transmit queued frames after waking queues

> > Just sanity checking - what's protecting htt->num_pending_tx? or is it > > serialised some other way? [...] > I can't see that any of the examples applies, but let's add READ_ONCE(), > to make sure that the compiler doesn't try to optimize this. Couldn't you just move the num_pending_tx read inside tx_lock which is 2 lines above? I think all the other manipulations are protected by tx_lock. -- Bob Copeland %% https://bobcopeland.com/

Re: [BUG] 4.17-rcX delays during boot and memory mapping errors

On Fri, May 18, 2018 at 07:32:59PM -0500, Bob Tracy wrote: > Every one of the 4.17-rcX series has hung during boot at the point where > "acpid" starts up. Beginning with -rc5, the boot actually proceeds to > completion after an "uncomfortably" long delay. > &g

Re: [BUG] 4.17-rcX delays during boot and memory mapping errors

On Fri, May 18, 2018 at 07:32:59PM -0500, Bob Tracy wrote: > Every one of the 4.17-rcX series has hung during boot at the point where > "acpid" starts up. Beginning with -rc5, the boot actually proceeds to > completion after an "uncomfortably" long delay. > &g

[BUG] 4.17-rcX delays during boot and memory mapping errors

.0.log" for additional information. [ 109.952] (EE) [ 109.971] (EE) Server terminated with error (1). Closing log file. Everything works normally with a 4.16 kernel. --Bob

[BUG] 4.17-rcX delays during boot and memory mapping errors

.0.log" for additional information. [ 109.952] (EE) [ 109.971] (EE) Server terminated with error (1). Closing log file. Everything works normally with a 4.16 kernel. --Bob

GFS2: Pull request #2 (merge window)

Hi Linus, Please consider pulling the following additional 3 patches for the GFS2 file system. Regards, Bob Peterson The following changes since commit e241e3f2bf975788a1b70dff2eb5180ca395b28e: Merge tag 'for_linus' of git

GFS2: Pull request #2 (merge window)

Hi Linus, Please consider pulling the following additional 3 patches for the GFS2 file system. Regards, Bob Peterson The following changes since commit e241e3f2bf975788a1b70dff2eb5180ca395b28e: Merge tag 'for_linus' of git

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/?h=for-next=450b1f6f56350c630e795f240dc5a77aa8aa2419 https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/?h=for-next=3fd5d3ad35dc44aaf0f28d60cc0eb75887bff54d Regards, Bob Peterson Red Hat File Systems

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/?h=for-next=450b1f6f56350c630e795f240dc5a77aa8aa2419 https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/?h=for-next=3fd5d3ad35dc44aaf0f28d60cc0eb75887bff54d Regards, Bob Peterson Red Hat File Systems

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

t; include/linux/lockref.h | 1 + > lib/lockref.c | 28 > 3 files changed, 57 insertions(+), 19 deletions(-) > > -- > 2.14.3 Hi, The patches look good. The big question is whether to add them to this merge window while it's still open. Opinions? Acked-by: Bob Peterson <rpete...@redhat.com> Regards, Bob Peterson

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

t; include/linux/lockref.h | 1 + > lib/lockref.c | 28 > 3 files changed, 57 insertions(+), 19 deletions(-) > > -- > 2.14.3 Hi, The patches look good. The big question is whether to add them to this merge window while it's still open. Opinions? Acked-by: Bob Peterson Regards, Bob Peterson

GFS2: Pull request (merge window)

Hi Linus, Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson The following changes since commit 1b88accf6a659c46d5c8e68912896f112bf882bb: Merge tag 'for_linus' of git://git.kernel.org

GFS2: Pull request (merge window)

Hi Linus, Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson The following changes since commit 1b88accf6a659c46d5c8e68912896f112bf882bb: Merge tag 'for_linus' of git://git.kernel.org

GFS2: Please pull patch tagged gfs2-4.16.rc4.fixes

Hi Linus, Would you please pull this additional patch from Andreas Gruenbacher that fixes another unfortunate GFS2 regression? Thanks. Bob Peterson --- The following changes since commit 86f84779d8e92a690b2f281175ea06b884cb6fa4: Merge branch 'siginfo-linus' of git://git.kernel.org/pub/scm

GFS2: Please pull patch tagged gfs2-4.16.rc4.fixes

Hi Linus, Would you please pull this additional patch from Andreas Gruenbacher that fixes another unfortunate GFS2 regression? Thanks. Bob Peterson --- The following changes since commit 86f84779d8e92a690b2f281175ea06b884cb6fa4: Merge branch 'siginfo-linus' of git://git.kernel.org/pub/scm

GFS2: Please pull patch tagged gfs2-4.16.rc1.fixes

Hi Linus, Would you please pull this one-off patch from Andreas Gruenbacher that fixes a GFS2 regression? Thanks. Bob Peterson --- The following changes since commit 35277995e17919ab838beae765f440674e8576eb: Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git

GFS2: Please pull patch tagged gfs2-4.16.rc1.fixes

Hi Linus, Would you please pull this one-off patch from Andreas Gruenbacher that fixes a GFS2 regression? Thanks. Bob Peterson --- The following changes since commit 35277995e17919ab838beae765f440674e8576eb: Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git

GFS2: Second Pull request (merge window)

Hi Linus, Sorry to bother you with a second merge request for GFS2, but we found a couple regressions and want to get them fixed in this merge window. Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson

GFS2: Second Pull request (merge window)

Hi Linus, Sorry to bother you with a second merge request for GFS2, but we found a couple regressions and want to get them fixed in this merge window. Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson

GFS2: Pull request (merge window)

Hi Linus, Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson The following changes since commit 1291a0d5049dbc06baaaf66a9ff3f53db493b19b: Linux 4.15-rc4 (2017-12-17 18:59:59 -0800

GFS2: Pull request (merge window)

Hi Linus, Please consider pulling the following changes for the GFS2 file system. Regards, Bob Peterson The following changes since commit 1291a0d5049dbc06baaaf66a9ff3f53db493b19b: Linux 4.15-rc4 (2017-12-17 18:59:59 -0800

Re: linux-next: Signed-off-by missing for commit in the gfs2 tree

- Original Message - | | | On 16/01/18 20:51, Stephen Rothwell wrote: | > Hi all, | > | > Commit | > | >7d2040199855 ("gfs2: Add gfs2_blk2rgrpd comment and fix incorrect use") | > | > is missing a Signed-off-by from its author. | > | Bob, can you

Re: linux-next: Signed-off-by missing for commit in the gfs2 tree

- Original Message - | | | On 16/01/18 20:51, Stephen Rothwell wrote: | > Hi all, | > | > Commit | > | >7d2040199855 ("gfs2: Add gfs2_blk2rgrpd comment and fix incorrect use") | > | > is missing a Signed-off-by from its author. | > | Bob, can you

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

the accepted Linux coding style document. See: | | https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings | | Regards, | | Bob Peterson | | Hm. I guess I stand corrected. The document reads: "However, never break user-visible strings such as printk mes

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

the accepted Linux coding style document. See: | | https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings | | Regards, | | Bob Peterson | | Hm. I guess I stand corrected. The document reads: "However, never break user-visible strings such as printk mes

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings Regards, Bob Peterson

Re: [Cluster-devel] [PATCH 00/12] drop unneeded newline

://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings Regards, Bob Peterson

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 11:38, Lu Baolu wrote: > Hi, > > On 12/14/2017 11:10 AM, Bob Liu wrote: >> On 2017/12/14 9:02, Lu Baolu wrote: >>>> From: Huang Ying <ying.hu...@intel.com> >>>> >>>> Shared Virtual Memory (SVM) allows a kernel memory map

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 11:38, Lu Baolu wrote: > Hi, > > On 12/14/2017 11:10 AM, Bob Liu wrote: >> On 2017/12/14 9:02, Lu Baolu wrote: >>>> From: Huang Ying >>>> >>>> Shared Virtual Memory (SVM) allows a kernel memory mapping to be >>>> s

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 9:02, Lu Baolu wrote: > From: Huang Ying > > Shared Virtual Memory (SVM) allows a kernel memory mapping to be > shared between CPU and and a device which requested a supervisor > PASID. Both devices and IOMMU units have TLBs that cache entries > from CPU's

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 9:02, Lu Baolu wrote: > From: Huang Ying > > Shared Virtual Memory (SVM) allows a kernel memory mapping to be > shared between CPU and and a device which requested a supervisor > PASID. Both devices and IOMMU units have TLBs that cache entries > from CPU's page tables. We need to

4.14.0: built-in drivers now require built-in firmware?

evices whose drivers are built-in rather than built as modules. This is presumably a non-issue for people who run distro-provided kernels where everything is modularized. --Bob

4.14.0: built-in drivers now require built-in firmware?

evices whose drivers are built-in rather than built as modules. This is presumably a non-issue for people who run distro-provided kernels where everything is modularized. --Bob

Re: [PATCH] gfs2: Fix wrong error handling in init_gfs2_fs()

el/git/gfs2/linux-gfs2.git/commit/?h=for-next=8b0d7f56b97b95a442b6785027a0f80ad1ea54af Regards, Bob Peterson Red Hat File Systems

Re: [PATCH] gfs2: Fix wrong error handling in init_gfs2_fs()

=for-next=8b0d7f56b97b95a442b6785027a0f80ad1ea54af Regards, Bob Peterson Red Hat File Systems

Re: [BUG] 4.14 regression: Xorg hangs on exit

nt as I type this: Xorg has been started and exited multiple times with no issue. Still going to keep an eye on it for a while. --Bob

Re: [BUG] 4.14 regression: Xorg hangs on exit

nt as I type this: Xorg has been started and exited multiple times with no issue. Still going to keep an eye on it for a while. --Bob

Re: [BUG] 4.14 regression: Xorg hangs on exit

On Tue, Nov 21, 2017 at 11:12:35AM -0600, Bob Tracy wrote: > Apologies for the lack of detail, but the subject pretty much says it > all. Xorg works fine with 4.13, but hangs on exit with 4.14. > > Logging in remotely and applying the "kill -9" sledgehammer has no > e

Re: [BUG] 4.14 regression: Xorg hangs on exit

On Tue, Nov 21, 2017 at 11:12:35AM -0600, Bob Tracy wrote: > Apologies for the lack of detail, but the subject pretty much says it > all. Xorg works fine with 4.13, but hangs on exit with 4.14. > > Logging in remotely and applying the "kill -9" sledgehammer has no > e

  1   2   3   4   5   6   7   8   9   10   >