ch 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 to get u
he performance
of tasklets was 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
work->ret = ret;
> +}
> +
> +int rxe_init_work(void *obj, struct rxe_work *work,
> + void *arg, int (*func)(void *), char *name)
> +{
> + work->obj = obj;
> + work->arg = arg;
> + work->func = func;
> + snprintf(work->name, sizeof(work->name), "%s", name);
> + work->destroyed = false;
> + atomic_set(&work->suspended, 0);
> +
> + work->worker = create_singlethread_workqueue(name);
> + INIT_WORK(&work->work, rxe_do_work);
> +
> + work->state = WQ_STATE_START;
> + spin_lock_init(&work->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(&work->state_lock);
> + idle = (work->state == WQ_STATE_START);
> + spin_unlock_bh(&work->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(&work->suspended))
> + continue;
> +
> + if (sched)
> + queue_work(work->worker, &work->work);
> + else
> + rxe_do_work(&work->work);
> +}
> +
> +void rxe_disable_work(struct rxe_work *work)
> +{
> + atomic_inc(&work->suspended);
> + flush_workqueue(work->worker);
> +}
> +
> +void rxe_enable_work(struct rxe_work *work)
> +{
> + atomic_dec(&work->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
a slight disagreement about 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
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&id=0e787a0bfabb8be323f575d5cdda48e607840eb5
Regards,
Bob Peterson
ng your patch. I like 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
this sort 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:
>
of the bug.
Thanks
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.
&
ll, 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.
After some experiments, I've determined that my fears about the count are
unfounded.
Consider my patch withdrawn. Sorry for the noise.
Bob Peterson
number of thaws should match your
freezes, and if they don't: user 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
ike: "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
- 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 free
bdev->bd_fsfreeze_count++;
> > + else
> > + bdev->bd_fsfreeze_sb = NULL;
> > out:
> > mutex_unlock(&bdev->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
; 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
_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
ser"
>> into the 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
hread+0x4a/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
disp: 0c10: cf00
---
If you need anything else, please email me directly as I'm not on the list.
Bob
MODULE_LICENSE("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:
>
withdraw to replay journals and 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
s I am not on the list,
Bob
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 objtoo
- 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 -
> >
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&#
- 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
- 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
t;< SECTOR_SHIFT);
> num_feature_args += test_bit(CRYPT_IV_LARGE_SECTORS,
> &cc->cipher_flags);
> if (cc->on_disk_tag_size)
> @@ -3208,6 +3238,10 @@ static void crypt_status(struct dm_target *ti,
> status_type_t type,
> DMEMIT(" same_cpu_crypt");
> if (test_bit(DM_CRYPT_NO_OFFLOAD, &cc->flags))
> DMEMIT(" submit_from_crypt_cpus");
> + if (test_bit(DM_CRYPT_NO_READ_WORKQUEUE, &cc->flags))
> + DMEMIT(" no_read_workqueue");
> + if (test_bit(DM_CRYPT_NO_WRITE_WORKQUEUE, &cc->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
329MB), 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' |
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 &&
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 &&
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.
&
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_acti
olation, but 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
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 +
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
ues/852
Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible")
Cc: sta...@vger.kernel.org
Reported-by: 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 Kl
.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
0) {
> printk(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
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
el.org
Reported-by: Nathan Chancellor
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
e.kernel.org/lkml/20190703163158.937-1-huangfq.dax...@gmail.com/
--
Bob Copeland %% https://bobcopeland.com/
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
a memory leak bug. To fix this issue,
> go to the 'nomem_free' label to free 'sbi->s_imap'.
Nice catch, thanks.
Acked-by: Bob Copeland
--
Bob Copeland %% https://bobcopeland.com/
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/
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
ty, 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/
4: 7ffdfc946600 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
#x27;m fairly certain the
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
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)
are
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
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
t; md2: don'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
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
- 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
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
ches
the semantic 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/
> > +
> >
> > 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&
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
.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
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
https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/?h=for-next&id=450b1f6f56350c630e795f240dc5a77aa8aa2419
https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/?h=for-next&id=3fd5d3ad35dc44aaf0f28d60cc0eb75887bff54d
Regards,
Bob Peterson
Red Hat File Systems
---
> 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
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.
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.o
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/
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
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
- 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 add
t 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 print
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings
Regards,
Bob Peterson
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
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 ge
sage about firmware for
devices 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
-next&id=8b0d7f56b97b95a442b6785027a0f80ad1ea54af
Regards,
Bob Peterson
Red Hat File Systems
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
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
because of the unkillable process: hitting the reset switch is
the only way forward.
Video driver is "radeon", reporting "ATOM BIOS: REDWOOD" at boot time.
Console is fb0 == radeondrmfb.
--Bob
following changes for the GFS2 file system.
Regards,
Bob Peterson
The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:
Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)
are available in the git repository
- Original Message -
| Hi Linus,
|
| Please consider pulling the following changes for the GFS2 file system.
|
| Regards,
|
| Bob Peterson
|
| The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff
Hi Linus,
Please consider pulling the following changes for the GFS2 file system.
Regards,
Bob Peterson
The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:
Linux 4.14-rc3 (2017-10-01 14:54:54 -0700
gt; these already freed memory through tlb entries.
>
> This patch gather each vma instead of gathering full vm space,
> tlb->fullmm is not true. The behavior of oom reaper become similar
> to munmapping before do_exit, which should be safe for all archs.
>
> Signed-off-by: Wang Nan
emblock.c | 60 --
> mm/page_alloc.c | 224
> +---
> mm/sparse-vmemmap.c | 15 ++-
> mm/sparse.c | 6 +-
> 13 files changed, 469 insertions(+), 184 deletions(-)
>
> --
> 2.14.2
>
Boot tested on ThunderX2 VM.
Tested-by: Bob Picco
On 2017/10/12 17:50, Liu, Yi L wrote:
>
>
>> -Original Message-----
>> From: Bob Liu [mailto:liub...@huawei.com]
>> Sent: Thursday, October 12, 2017 5:39 PM
>> To: Jean-Philippe Brucker ; Joerg Roedel
>> ; Liu, Yi L
>> Cc: Lan, Tianyu ; Liu,
On 2017/10/11 20:48, Jean-Philippe Brucker wrote:
> On 11/10/17 13:15, Joerg Roedel wrote:
>> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote:
>>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea?
>>
>> It's short for IO Virtual Memory, basically a replacement term for
On Sun, Oct 1, 2017 at 6:49 AM, Jerome Glisse wrote:
> On Sat, Sep 30, 2017 at 10:57:38AM +0800, Bob Liu wrote:
>> On 2017/9/27 0:16, Jerome Glisse wrote:
>> > On Tue, Sep 26, 2017 at 05:56:26PM +0800, Bob Liu wrote:
>> >> On Tue, Sep 12, 2017 at 7:36 AM, Jerome Gli
On 2017/9/27 0:16, Jerome Glisse wrote:
> On Tue, Sep 26, 2017 at 05:56:26PM +0800, Bob Liu wrote:
>> On Tue, Sep 12, 2017 at 7:36 AM, Jerome Glisse wrote:
>>> On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote:
>>>> On Wed, Sep 6, 2017 at 3:36 AM, Jerome Gliss
On Tue, Sep 12, 2017 at 7:36 AM, Jerome Glisse wrote:
> On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote:
>> On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse wrote:
>> > On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote:
>> >> On Thu, Jul 20, 2017 at
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 46c1e79fee417f151547aa46fae04ab06cb666f4:
Merge branch 'perf-urgent-for-linus' of
git://git.kernel.org/pub/scm/li
he size of the one containing 2.6 and
later kernel versions.
Definitely not looking to make this maintenance action a regular thing.
The system was barely usable during the time it was running, but only
having 1.5 GB RAM (maxed-out) definitely has a lot to do with that :-).
--Bob
On 2017/9/6 17:57, Jean-Philippe Brucker wrote:
> On 06/09/17 02:02, Bob Liu wrote:
>> On 2017/9/5 20:56, Jean-Philippe Brucker wrote:
>>> On 31/08/17 09:20, Yisheng Xie wrote:
>>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM
>>>
On 2017/9/12 7:36, Jerome Glisse wrote:
> On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote:
>> On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse wrote:
>>> On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote:
>>>> On Thu, Jul 20, 2017 at 6:41 PM, Jero
On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse wrote:
> On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote:
>> On Thu, Jul 20, 2017 at 6:41 PM, Jerome Glisse wrote:
>> > On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote:
>> >> On 2017/7/20 23:03, J
On 2017/9/8 1:27, Jerome Glisse wrote:
>> On 2017/9/6 10:12, Jerome Glisse wrote:
>>> On Wed, Sep 06, 2017 at 09:25:36AM +0800, Bob Liu wrote:
>>>> On 2017/9/6 2:54, Ross Zwisler wrote:
>>>>> On Mon, Sep 04, 2017 at 10:38:27PM -0400, Jerome Glisse wrote:
On 2017/9/6 10:12, Jerome Glisse wrote:
> On Wed, Sep 06, 2017 at 09:25:36AM +0800, Bob Liu wrote:
>> On 2017/9/6 2:54, Ross Zwisler wrote:
>>> On Mon, Sep 04, 2017 at 10:38:27PM -0400, Jerome Glisse wrote:
>>>> On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu
ak to the invalidation, I have one more question.
There is a time window between 1) modify page table; 2) tlb invalidate;
ARM-CPU Device
1. modify page table
^
Can still write data through smmu tlb even page
table was already modified.
(At this point, the same virtual addr may not
point to the same thing for CPU and device!!!
I'm afraid there may be some data-loss or other
potential problems if this situation happens.)
2. tlb invalidate range
--
Thanks,
Bob
On 2017/9/6 17:57, Jean-Philippe Brucker wrote:
> On 06/09/17 02:02, Bob Liu wrote:
>> On 2017/9/5 20:56, Jean-Philippe Brucker wrote:
>>> On 31/08/17 09:20, Yisheng Xie wrote:
>>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM
>>>
On 2017/9/6 2:54, Ross Zwisler wrote:
> On Mon, Sep 04, 2017 at 10:38:27PM -0400, Jerome Glisse wrote:
>> On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu wrote:
>>> On 2017/9/4 23:51, Jerome Glisse wrote:
>>>> On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu
On 2017/9/5 20:56, Jean-Philippe Brucker wrote:
> On 31/08/17 09:20, Yisheng Xie wrote:
>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:
>> https://www.spinics.net/lists/arm-kernel/msg565155.html
>>
>> But for some platform devices(aka on-chip integrated devices), the
On 2017/9/5 20:53, Jean-Philippe Brucker wrote:
> On 31/08/17 09:20, Yisheng Xie wrote:
>> From: Jean-Philippe Brucker
>>
>> Platform device can realise SVM function by using the stall mode. That
>> is to say, when device access a memory via iova which is not populated,
>> it will stalled and when
On 2017/9/5 10:38, Jerome Glisse wrote:
> On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu wrote:
>> On 2017/9/4 23:51, Jerome Glisse wrote:
>>> On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu wrote:
>>>> On 2017/8/17 8:05, Jérôme Glisse wrote:
>>>>>
1 - 100 of 862 matches
Mail list logo
