t we
need to disable TBOOT PMR registers. For system without the boot option,
nothing is changed.
Signed-off-by: Shaohua Li
---
Documentation/admin-guide/kernel-parameters.txt | 5 +
arch/x86/kernel/tboot.c | 3 +++
drivers/iommu/intel-iommu.c
t we
need to disable TBOOT PMR registers. For system without the boot option,
nothing is changed.
Signed-off-by: Shaohua Li
---
Documentation/admin-guide/kernel-parameters.txt | 9 +
arch/x86/kernel/tboot.c | 3 +++
drivers/iommu/intel-iommu.c
On Thu, Apr 27, 2017 at 10:42:07AM +0200, Joerg Roedel wrote:
> On Thu, Apr 27, 2017 at 08:51:42AM +0200, Ingo Molnar wrote:
> > > + tboot_noforce [Default Off]
> > > + Do not force the Intel IOMMU enabled under tboot.
> > > + By default, tboot will force Int
On Thu, Apr 27, 2017 at 05:18:55PM +0200, Joerg Roedel wrote:
> On Thu, Apr 27, 2017 at 07:49:02AM -0700, Shaohua Li wrote:
> > This is exactly the usage for us. And please note, not everybody should
> > sacrifice the DMA security. It is only required when the pcie device
On Wed, Mar 22, 2017 at 07:50:55AM -0400, Shaohua Li wrote:
> On Wed, Mar 22, 2017 at 11:49:00AM +0100, Joerg Roedel wrote:
> > Hi Shaohua,
> >
> > On Tue, Mar 21, 2017 at 11:37:51AM -0700, Shaohua Li wrote:
> > > IOMMU harms performance signficantly wh
ar_disable=1.
The tboot code (tboot_force_iommu) runs later and force dmar_disabled = 0.
Thanks,
Shaohua
> Thanks,
> -ning
>
> -Original Message-
> From: Joerg Roedel [mailto:jroe...@suse.de]
> Sent: Friday, April 07, 2017 3:09 AM
> To: Shaohua Li
> Cc: linux-kern
ce hungry tboot users, so
> long as the users are aware of the security implication behind of this option.
>
> Thanks,
> -ning
>
> -----Original Message-
> From: Shaohua Li [mailto:s...@fb.com]
> Sent: Sunday, April 09, 2017 9:31 PM
> To: Sun, Ning
> Cc: Joe
From: Shaohua Li
Add an API to get kernfs node from inode number. We will need this to
implement exportfs operations.
This API will be used in blktrace too later, so it should be as fast as
possible. To make the API lock free, kernfs node is freed in RCU
context. And we depend on kernfs_node
From: Shaohua Li
blkcg_bio_issue_check() already gets blkcg for a BIO.
bio_associate_blkcg() uses a percpu refcounter, so it's a very cheap
operation. There is no point we don't attach the cgroup info into bio at
blkcg_bio_issue_check. This also makes blktrace outputs correct cgroup
in
From: Shaohua Li
Set i_generation for kernfs inode. This is required to implement
exportfs operations. The generation is 32-bit, so it's possible the
generation wraps up and we find stale files. To reduce the posssibility,
we don't reuse inode numer immediately. When the inode number
From: Shaohua Li
Hi,
Currently blktrace isn't cgroup aware. blktrace prints out task name of current
context, but the task of current context isn't always in the cgroup where the
BIO comes from. We can't use task name to find out IO cgroup. For example,
Writeback BIOs always com
From: Shaohua Li
When working on adding exportfs operations in kernfs, I found it's hard
to initialize dentry->d_fsdata in the exportfs operations. Looks there
is no way to do it without race condition. Look at the kernfs code
closely, there is no point to set dentry->d_fsdata. inode
From: Shaohua Li
Currently cfq/bfq/blk-throttle output cgroup info in trace in their own
way. Now we have standard blktrace API for this, so convert them to use
it.
Note, this changes the behavior a little bit. cgroup info isn't output
by default, we only do this with 'blk_cgro
From: Shaohua Li
By default we output cgroup id in blktrace. This adds an option to
display cgroup path. Since get cgroup path is a relativly heavy
operation, we don't enable it by default.
with the option enabled, blktrace will output something like this:
dd-1353 [007] d..2 293.0
From: Shaohua Li
Currently blktrace isn't cgroup aware. blktrace prints out task name of
current context, but the task of current context isn't always in the
cgroup where the BIO comes from. We can't use task name to find out IO
cgroup. For example, Writeback BIOs always com
From: Shaohua Li
bio_free isn't a good place to free cgroup/integrity info. There are a
lot of cases bio is allocated in special way (for example, in stack) and
never gets called by bio_put hence bio_free, we are leaking memory. This
patch moves the free to bio endio, which should be c
From: Shaohua Li
Now we have the facilities to implement exportfs operations. The idea is
cgroup can export the fhandle info to userspace, then userspace uses
fhandle to find the cgroup name. Another example is userspace can get
fhandle for a cgroup and BPF uses the fhandle to filter info for
From: Shaohua Li
Add an API to export cgroup fhandle info. We don't export a full 'struct
file_handle', there are unrequired info. Sepcifically, cgroup is always
a directory, so we don't need a 'FILEID_INO32_GEN_PARENT' type fhandle,
we only need export the inod
From: Shaohua Li
inode number and generation can identify a kernfs node. We are going to
export the identification by exportfs operations, so put ino and
generation into a separate structure. It's convenient when later patches
use the identification.
Signed-off-by: Shaohua Li
---
fs/k
From: Shaohua Li
kernfs uses ida to manage inode number. The problem is we can't get
kernfs_node from inode number with ida. Switching to use idr, next patch
will add an API to get kernfs_node from inode number.
Acked-by: Tejun Heo
Signed-off-by: Shaohua Li
---
fs/kernfs/dir.c
On Wed, Jun 28, 2017 at 10:43:48AM -0600, Jens Axboe wrote:
> On 06/28/2017 10:29 AM, Shaohua Li wrote:
> > From: Shaohua Li
> >
> > Hi,
> >
> > Currently blktrace isn't cgroup aware. blktrace prints out task name of
> > current
> > context, b
)
Artur Paszkiewicz (1):
md: don't return -EAGAIN in md_allow_write for external metadata arrays
Julia Cartwright (1):
md/raid5: make use of spin_lock_irq over local_irq_disable + spin_lock
Shaohua Li (2):
md/md0: optimize raid0 discard han
;
> Signed-off-by: Amir Goldstein
> Signed-off-by: Christoph Hellwig
Reviewed-by: Shaohua Li
On Wed, May 24, 2017 at 01:46:04PM -0400, Tejun Heo wrote:
> Hello, Christoph.
>
> On Wed, May 24, 2017 at 10:41:38AM -0700, Christoph Hellwig wrote:
> > > But how do you map that back to the cgroup without scanning the cgroup
> > > hierarchy?
> >
> > I'm totally lost on why you would do that. S
From: Shaohua Li
Currently cfq/bfq/blk-throttle output cgroup info in trace in their own
way. Now we have standard blktrace API for this, so convert them to use
it.
Note, this changes the behavior a little bit. cgroup info isn't output
by default, we only do this with 'blk_cgro
From: Shaohua Li
Add an API to export cgroup fhandle info. We don't export a full 'struct
file_handle', there are unrequired info. Sepcifically, cgroup is always
a directory, so we don't need a 'FILEID_INO32_GEN_PARENT' type fhandle,
we only need export the inod
From: Shaohua Li
Currently blktrace isn't cgroup aware. blktrace prints out task name of
current context, but the task of current context isn't always in the
cgroup where the BIO comes from. We can't use task name to find out IO
cgroup. For example, Writeback BIOs always com
From: Shaohua Li
blkcg_bio_issue_check() already gets blkcg for a BIO.
bio_associate_blkcg() uses a percpu refcounter, so it's a very cheap
operation. There is no point we don't attach the cgroup info into bio at
blkcg_bio_issue_check. This also makes blktrace outputs correct cgroup
in
From: Shaohua Li
Now we have the facilities to implement exportfs operations. The idea is
cgroup can export the fhandle info to userspace, then userspace uses
fhandle to find the cgroup name. Another example is userspace can get
fhandle for a cgroup and BPF uses the fhandle to filter info for
From: Shaohua Li
By default we output cgroup id in blktrace. This adds an option to
display cgroup path. Since get cgroup path is a relativly heavy
operation, we don't enable it by default.
with the option enabled, blktrace will output something like this:
dd-1353 [007] d..2 293.0
From: Shaohua Li
inode number and generation can identify a kernfs node. We are going to
export the identification by exportfs operations, so put ino and
generation into a separate structure. It's convenient when later patches
use the identification.
Acked-by: Greg Kroah-Hartman
Signed-o
From: Shaohua Li
Set i_generation for kernfs inode. This is required to implement
exportfs operations. The generation is 32-bit, so it's possible the
generation wraps up and we find stale files. To reduce the posssibility,
we don't reuse inode numer immediately. When the inode number
From: Shaohua Li
Hi,
Currently blktrace isn't cgroup aware. blktrace prints out task name of current
context, but the task of current context isn't always in the cgroup where the
BIO comes from. We can't use task name to find out IO cgroup. For example,
Writeback BIOs always com
From: Shaohua Li
Add an API to get kernfs node from inode number. We will need this to
implement exportfs operations.
This API will be used in blktrace too later, so it should be as fast as
possible. To make the API lock free, kernfs node is freed in RCU
context. And we depend on kernfs_node
From: Shaohua Li
When working on adding exportfs operations in kernfs, I found it's hard
to initialize dentry->d_fsdata in the exportfs operations. Looks there
is no way to do it without race condition. Look at the kernfs code
closely, there is no point to set dentry->d_fsdata. inode
From: Shaohua Li
kernfs uses ida to manage inode number. The problem is we can't get
kernfs_node from inode number with ida. Switching to use idr, next patch
will add an API to get kernfs_node from inode number.
Acked-by: Tejun Heo
Acked-by: Greg Kroah-Hartman
Signed-off-by: Shaoh
On Wed, Jun 28, 2017 at 12:57:50PM -0600, Jens Axboe wrote:
> On 06/28/2017 12:52 PM, Christoph Hellwig wrote:
> > On Wed, Jun 28, 2017 at 12:44:00PM -0600, Jens Axboe wrote:
> >> On 06/28/2017 12:38 PM, Christoph Hellwig wrote:
> >>> On Wed, Jun 28, 2017 at 12:34:15PM -0600, Jens Axboe wrote:
> >>
On Wed, Jun 28, 2017 at 11:29:08PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 28, 2017 at 09:30:00AM -0700, Shaohua Li wrote:
> > From: Shaohua Li
> >
> > bio_free isn't a good place to free cgroup/integrity info. There are a
> > lot of cases bio is allocated
On Thu, Jun 29, 2017 at 07:15:52PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 28, 2017 at 02:42:49PM -0700, Shaohua Li wrote:
> > > bio_integrity_endio -> bio_integrity_verify_fn -> bio_integrity_process
> > > access the integrity data, so I don't think this work
On Wed, Jun 28, 2017 at 02:57:38PM -0600, Jens Axboe wrote:
> On 06/28/2017 12:11 PM, Tejun Heo wrote:
> > Hello,
> >
> > On Wed, Jun 28, 2017 at 10:54:28AM -0600, Jens Axboe wrote:
> Series looks fine to me. I don't know how you want to split or funnel it,
> since it touches multiple di
he standardy way instead of writing the
> > > talbe directly. Otherwise it won't work any more once
> > > multipage bvec is enabled.
> > >
> > > Cc: Shaohua Li
> > > Cc: linux-r...@vger.kernel.org
> > > Signed-off-by: Ming Lei
> >
between mddev_suspend() and md_write_start()
md: use a separate bio_set for synchronous IO.
Shaohua Li (2):
MD: fix a null dereference
MD: fix sleep in atomic
drivers/md/faulty.c| 5 +++--
drivers/md/linear.c| 7 ---
drivers/md/md.c| 47 +
Hi,
Please pull 3 MD fixes:
- raid5-ppl fix by Artur. This one is introduced in this release cycle.
- raid5 reshape fix by Xiao. This is an old bug and will be added to stable.
- Bitmap fix by Guoqing.
Thanks,
Shaohua
The following changes since commit af3c8d98508d37541d4bf57f13a984a7f73a328c:
On Tue, Feb 20, 2018 at 02:09:11PM +0100, Arnd Bergmann wrote:
> gcc warns about a possible overflow of the kmem_cache string, when adding
> four characters to a string of the same length:
>
> drivers/md/raid5.c: In function 'setup_conf':
> drivers/md/raid5.c:2207:34: error: '-alt' directive writi
On Wed, Jan 17, 2018 at 01:38:02PM +, Luis de Bethencourt wrote:
> The trailing semicolon is an empty statement that does no operation.
> Removing it since it doesn't do anything.
>
> Signed-off-by: Luis de Bethencourt
> ---
>
> Hi,
>
> After fixing the same thing in drivers/staging/rtl8723
On Sat, Jan 13, 2018 at 09:55:08AM +0100, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 13 Jan 2018 09:49:03 +0100
>
> A single character (closing square bracket) should be put into a sequence.
> Thus use the corresponding function "seq_putc".
>
> This issue was detected by using
On Fri, Feb 02, 2018 at 11:13:19PM +0100, Heinz Mauelshagen wrote:
> If no metadata devices are configured on raid1/4/5/6/10
> (e.g. via dm-raid), md_write_start() unconditionally waits
> for superblocks to be written thus deadlocking.
>
> Fix introduces mddev->has_superblocks bool, defines it in
On Tue, Nov 14, 2017 at 03:10:22PM -0800, Khazhismel Kumykov wrote:
> Allows configuration additional bytes or ios before a throttle is
> triggered.
>
> This allows implementation of a bucket style rate-limit/throttle on a
> block device. Previously, bursting to a device was limited to allowance
>
On Tue, Dec 19, 2017 at 10:17:43AM -0600, Bruno Wolff III wrote:
> On Sun, Dec 17, 2017 at 21:43:50 +0800,
> weiping zhang wrote:
> > Hi, thanks for testing, I think you first reproduce this issue(got WARNING
> > at device_add_disk) by your own build, then add my debug patch.
>
> The problem is
From: Shaohua Li
loop block device handles IO in a separate thread. The actual IO
dispatched isn't cloned from the IO loop device received, so the
dispatched IO loses the cgroup context.
I'm ignoring buffer IO case now, which is quite complicated. Making the
loop thread aware cgro
From: Shaohua Li
Hi,
The IO dispatched to under layer disk by loop block device isn't cloned from
original bio, so the IO loses cgroup information of original bio. These IO
escapes from cgroup control. The patches try to address this issue. The idea is
quite generic, but we currently only
From: Shaohua Li
bio_blkcg is the only API to get cgroup info for a bio right now. If
bio_blkcg finds current task is a kthread and has original blkcg
associated, it will use the css instead of associating the bio to
current task. This makes it possible that kthread dispatches bios on
behalf of
From: Shaohua Li
kthread usually runs jobs on behalf of other threads. The jobs should be
charged to cgroup of original threads. But the jobs run in a kthread,
where we lose the cgroup context of original threads. The patch adds a
machanism to record cgroup info of original threads in kthread
From: Shaohua Li
Nobody uses the APIs right now.
Signed-off-by: Shaohua Li
---
block/bio.c| 31 ---
include/linux/bio.h| 2 --
include/linux/blk-cgroup.h | 12
3 files changed, 45 deletions(-)
diff --git a/block/bio.c b/block
On Wed, Sep 13, 2017 at 02:38:20PM -0700, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 13, 2017 at 02:01:26PM -0700, Shaohua Li wrote:
> > diff --git a/kernel/kthread.c b/kernel/kthread.c
> > index 26db528..3107eee 100644
> > --- a/kernel/kthread.c
> > +++ b/ke
From: Shaohua Li
bio_blkcg is the only API to get cgroup info for a bio right now. If
bio_blkcg finds current task is a kthread and has original blkcg
associated, it will use the css instead of associating the bio to
current task. This makes it possible that kthread dispatches bios on
behalf of
From: Shaohua Li
loop block device handles IO in a separate thread. The actual IO
dispatched isn't cloned from the IO loop device received, so the
dispatched IO loses the cgroup context.
I'm ignoring buffer IO case now, which is quite complicated. Making the
loop thread aware cgro
From: Shaohua Li
Nobody uses the APIs right now.
Acked-by: Tejun Heo
Signed-off-by: Shaohua Li
---
block/bio.c| 31 ---
include/linux/bio.h| 2 --
include/linux/blk-cgroup.h | 12
3 files changed, 45 deletions(-)
diff --git a
From: Shaohua Li
Hi,
The IO dispatched to under layer disk by loop block device isn't cloned from
original bio, so the IO loses cgroup information of original bio. These IO
escapes from cgroup control. The patches try to address this issue. The idea is
quite generic, but we currently only
From: Shaohua Li
kthread usually runs jobs on behalf of other threads. The jobs should be
charged to cgroup of original threads. But the jobs run in a kthread,
where we lose the cgroup context of original threads. The patch adds a
machanism to record cgroup info of original threads in kthread
If the worker thread continues getting work, it will hog the cpu and rcu
stall complains. Make it a good citizen. This is triggered in a loop
block device test.
Signed-off-by: Shaohua Li
---
kernel/kthread.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/kthread.c b/kernel/kthread.c
)
Dennis Yang (1):
md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list
Shaohua Li (1):
md/raid5: fix a race condition in stripe batch
drivers/md/raid5.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
On Fri, Sep 08, 2017 at 07:35:37AM -0700, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 06, 2017 at 07:00:51PM -0700, Shaohua Li wrote:
> > +#ifdef CONFIG_CGROUPS
> > +void kthread_set_orig_css(struct cgroup_subsys_state *css);
> > +struct cgroup_subsys_state *kthread_ge
On Fri, Sep 08, 2017 at 07:48:09AM -0700, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 06, 2017 at 07:00:53PM -0700, Shaohua Li wrote:
> > diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> > index 9d4545f..9850b27 100644
> > --- a/drivers/block/loop.c
>
On Mon, Aug 28, 2017 at 08:01:59PM +0800, Dennis Yang wrote:
> break_stripe_batch_list() did not preserve STRIPE_ON_UNPLUG_LIST which is
> set when a stripe_head gets queued to the stripe_head list maintained by
> raid5_plug_cb and waiting for releasing after blk_unplug().
>
> In release_stripe_pl
On Fri, Sep 01, 2017 at 05:26:48PM +0800, Dennis Yang wrote:
> >On Mon, Aug 28, 2017 at 08:01:59PM +0800, Dennis Yang wrote:
> >> break_stripe_batch_list() did not preserve STRIPE_ON_UNPLUG_LIST which is
> >> set when a stripe_head gets queued to the stripe_head list maintained by
> >> raid5_plug_c
On Thu, Aug 31, 2017 at 09:24:23AM +0200, Paolo VALENTE wrote:
>
> > Il giorno 15 gen 2017, alle ore 04:42, Shaohua Li ha scritto:
> >
> > Hi,
> >
> > cgroup still lacks a good iocontroller. CFQ works well for hard disk, but
> > not
> > much for
On Wed, Sep 06, 2017 at 11:02:35AM +0800, Dennis Yang wrote:
> In release_stripe_plug(), if a stripe_head has its STRIPE_ON_UNPLUG_LIST
> set, it indicates that this stripe_head is already in the raid5_plug_cb
> list and release_stripe() would be called instead to drop a reference
> count. Otherwis
On Wed, Sep 06, 2017 at 09:12:20AM +0800, Joseph Qi wrote:
> Hi Shaohua,
>
> On 17/9/6 05:02, Shaohua Li wrote:
> > On Thu, Aug 31, 2017 at 09:24:23AM +0200, Paolo VALENTE wrote:
> >>
> >>> Il giorno 15 gen 2017, alle ore 04:42, Shaohua Li ha
> >>
o 512 bits, not bytes
Guoqing Jiang (1):
raid5: remove raid5_build_block
NeilBrown (1):
md/bitmap: disable bitmap_resize for file-backed bitmaps.
Pawel Baldysiak (2):
md: Runtime support for multiple ppls
raid5-ppl: Recovery support for multiple partial parity logs
Shaohua
From: Shaohua Li
Several blkcg APIs are deprecated. After removing them, bio_blkcg is the
only API to get cgroup info for a bio. If bio_blkcg finds current task
is a kthread and has original css recorded, it will use the css instead
of associating the bio to current task.
Signed-off-by: Shaohua
From: Shaohua Li
loop block device handles IO in a separate thread. The actual IO
dispatched isn't cloned from the IO loop device received, so the
dispatched IO loses the cgroup context.
I'm ignoring buffer IO case now, which is quite complicated. Making the
loop thread aware cgro
From: Shaohua Li
Hi,
The IO dispatched to under layer disk by loop block device isn't cloned from
original bio, so the IO loses cgroup information of original bio. These IO
escapes from cgroup control. The patches try to address this issue. The idea is
quite generic, but we currently only
From: Shaohua Li
kthread usually runs jobs on behalf of other threads. The jobs should be
charged to cgroup of original threads. But the jobs run in a kthread,
where we lose the cgroup context of original threads. The patch adds a
machanism to record cgroup info of original threads in kthread
Ix: 5ecda13(generic_file_read_iter(): make use of iov_iter_revert())
Cc: Al Viro
Signed-off-by: Shaohua Li
---
mm/filemap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 681da61..df227638 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -205
best to identify a cgroup. So
this is what this series try to do.
Thanks,
Shaohua
Shaohua Li (5):
kernfs: implement i_generation
kernfs: use idr instead of ida to manage inode number
kernfs: add an API to get kernfs node from inode number
kernfs: don't set dentry->d_fsdata
eady points to kernfs_node, and we can get inode from a dentry. So
this patch just delete the d_fsdata usage.
Signed-off-by: Shaohua Li
---
fs/kernfs/dir.c | 22 +++---
fs/kernfs/file.c| 6 +++---
fs/kernfs/inode.c | 6 +++---
fs/kernfs/kernfs-i
Add an API to get kernfs node from inode number. We will need this to
implement exportfs operations.
To make the API lock free, kernfs node is freed in RCU context. And we
depend on kernfs_node count/ino number to filter stale kernfs nodes.
Signed-off-by: Shaohua Li
---
fs/kernfs/dir.c
kernfs uses ida to manage inode number. The problem is we can't get
kernfs_node from inode number with ida. Switching to use idr, next patch
will add an API to get kernfs_node from inode number.
Signed-off-by: Shaohua Li
---
fs/kernfs/dir.c| 17 -
include/linux/ker
Set i_generation for kernfs inod. This is required to implement exportfs
operations.
Signed-off-by: Shaohua Li
---
fs/kernfs/dir.c| 2 ++
fs/kernfs/inode.c | 1 +
include/linux/kernfs.h | 2 ++
3 files changed, 5 insertions(+)
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index
Now we have the facilities to implement exportfs operations.
Signed-off-by: Shaohua Li
---
fs/kernfs/mount.c | 55 +++
1 file changed, 55 insertions(+)
diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c
index 462a40c..5af88cc 100644
--- a/fs
On Tue, May 23, 2017 at 12:41:12AM -0700, Christoph Hellwig wrote:
> On Mon, May 22, 2017 at 03:53:05PM -0700, Shaohua Li wrote:
> > Set i_generation for kernfs inod. This is required to implement exportfs
> > operations.
> >
> > Signed-off-by: Shaohua Li
> > --
On Tue, May 23, 2017 at 12:39:41AM -0700, Christoph Hellwig wrote:
> On Mon, May 22, 2017 at 03:53:04PM -0700, Shaohua Li wrote:
> > Hi,
> >
> > The goal isn't to export kernfs to NFS. The intention is to make tracing
> > cgroup
> > aware. To do this, tracin
Hi,
One bug fix from Neil Brown for MD. The bug is introduced in this cycle. Please
pull!
Thanks,
Shaohua
The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f:
Linux 4.12-rc4 (2017-06-04 16:47:43 -0700)
are available in the git repository at:
git://git.kernel.org/pub
On Wed, May 03, 2017 at 10:27:47AM -0700, Linus Torvalds wrote:
> On Mon, May 1, 2017 at 3:50 PM, Shaohua Li wrote:
> >
> > Please pull MD update for 4.12. There are conflicts between MD tree and
> > block
> > tree, so I did a merge before the pull request.
>
>
From: Shaohua Li
Now we have the facilities to implement exportfs operations. The idea is
cgroup can export the fhandle info to userspace, then userspace uses
fhandle to find the cgroup name. Another example is userspace can get
fhandle for a cgroup and BPF uses the fhandle to filter info for
From: Shaohua Li
By default we output cgroup id in blktrace. This adds an option to
display cgroup path. Since get cgroup path is a relativly heavy
operation, we don't enable it by default.
with the option enabled, blktrace will output something like this:
dd-1353 [007] d..2 293.0
From: Shaohua Li
Hi,
Currently blktrace isn't cgroup aware. blktrace prints out task name of current
context, but the task of current context isn't always in the cgroup where the
BIO comes from. We can't use task name to find out IO cgroup. For example,
Writeback BIOs always com
From: Shaohua Li
bio_free isn't a good place to free cgroup/integrity info. There are a
lot of cases bio is allocated in special way (for example, in stack) and
never gets called by bio_put hence bio_free, we are leaking memory. This
patch moves the free to bio endio, which should be c
From: Shaohua Li
inode number and generation can identify a kernfs node. We are going to
export the identification by exportfs operations, so put ino and
generation into a separate structure. It's convenient when later patches
use the identification.
Please note, I extend inode number
From: Shaohua Li
Currently blktrace isn't cgroup aware. blktrace prints out task name of
current context, but the task of current context isn't always in the
cgroup where the BIO comes from. We can't use task name to find out IO
cgroup. For example, Writeback BIOs always com
From: Shaohua Li
Currently cfq/bfq/blk-throttle output cgroup info in trace in their own
way. Now we have standard blktrace API for this, so convert them to use
it.
Note, this changes the behavior a little bit. cgroup info isn't output
by default, we only do this with 'blk_cgro
From: Shaohua Li
Set i_generation for kernfs inode. This is required to implement exportfs
operations.
Note, the generation is 32-bit, so it's possible the generation wraps up
and we find stale files. The possiblity is low, since fhandle matches
both inode number and generation. In most fs
From: Shaohua Li
kernfs uses ida to manage inode number. The problem is we can't get
kernfs_node from inode number with ida. Switching to use idr, next patch
will add an API to get kernfs_node from inode number.
Signed-off-by: Shaohua Li
---
fs/kernfs/dir.c
From: Shaohua Li
blkcg_bio_issue_check() already gets blkcg for a BIO.
bio_associate_blkcg() uses a percpu refcounter, so it's a very cheap
operation. There is no point we don't attach the cgroup info into bio at
blkcg_bio_issue_check. This also makes blktrace outputs correct c
From: Shaohua Li
When working on adding exportfs operations in kernfs, I found it's hard
to initialize dentry->d_fsdata in the exportfs operations. Looks there
is no way to do it without race condition. Look at the kernfs code
closely, there is no point to set dentry->d_fsdata. inode
From: Shaohua Li
Add an API to get kernfs node from inode number. We will need this to
implement exportfs operations.
To make the API lock free, kernfs node is freed in RCU context. And we
depend on kernfs_node count/ino number to filter stale kernfs nodes.
Signed-off-by: Shaohua Li
---
fs
From: Shaohua Li
Add an API to export cgroup fhandle info. We don't export a full 'struct
file_handle', there are unrequired info. Sepcifically, cgroup is always
a directory, so we don't need a 'FILEID_KERNFS_WITH_PARENT' type
fhandle, we only need export the inod
md: allow creation of mdNNN arrays via md_mod/parameters/new_array
md: support disabling of create-on-open semantics.
md: handle read-only member devices better.
Shaohua Li (7):
md/raid5: prioritize stripes for writeback
md/raid5-cache: bump flush stripe batch size
On Fri, Apr 28, 2017 at 12:41:02PM -0500, Julia Cartwright wrote:
> On mainline, there is no functional difference, just less code, and
> symmetric lock/unlock paths.
>
> On PREEMPT_RT builds, this fixes the following warning, seen by
> Alexander GQ Gerasiov, due to the sleeping nature of spinlock
701 - 800 of 876 matches
Mail list logo
