On Thu, Nov 02, 2023 at 08:29:17AM +0100, Andrea Righi wrote:
> On Wed, Nov 01, 2023 at 09:21:09PM -1000, Linus Torvalds wrote:
> > On Wed, 1 Nov 2023 at 21:02, Linus Torvalds
> > wrote:
> > >
> > > kmalloc() isn't just about "use physically contiguou
On Wed, Nov 01, 2023 at 09:21:09PM -1000, Linus Torvalds wrote:
> On Wed, 1 Nov 2023 at 21:02, Linus Torvalds
> wrote:
> >
> > kmalloc() isn't just about "use physically contiguous allocations".
> > It's also more memory-efficient, and a *lot* faster than vmalloc(),
> > which has to play VM tricks
On Wed, Nov 01, 2023 at 09:02:51PM -1000, Linus Torvalds wrote:
> On Wed, 1 Nov 2023 at 10:13, Luis Chamberlain wrote:
> >
> > The only thing worth highligthing is that gzip moves to use vmalloc()
> > instead of
> > kmalloc just as we had a fix for this for zstd on v6.6-rc1.
>
> Actually, that's
On Sun, Mar 07, 2021 at 10:02:32AM +0800, Boqun Feng wrote:
> On Sat, Mar 06, 2021 at 09:39:54PM +0100, Marc Kleine-Budde wrote:
> > Hello *,
> >
> > On 02.11.2020 11:41:52, Andrea Righi wrote:
> > > We have the followin
ot;)
Signed-off-by: Andrea Righi
---
arch/x86/entry/Makefile | 3 ++-
arch/x86/entry/thunk_32.S | 2 --
arch/x86/entry/thunk_64.S | 4
arch/x86/um/Makefile | 3 ++-
4 files changed, 4 insertions(+), 8 deletions(-)
ChangeLog (v1 -> v2):
- do not break UML build
diff --git a/arch/
On Thu, Jan 21, 2021 at 09:52:01AM +0100, Andrea Righi wrote:
> On Thu, Jan 21, 2021 at 08:49:28AM +0100, Ingo Molnar wrote:
> >
> > * tip-bot2 for Andrea Righi wrote:
> >
> > > The following commit has been merged into the x86/entry branch
On Thu, Jan 21, 2021 at 08:49:28AM +0100, Ingo Molnar wrote:
>
> * tip-bot2 for Andrea Righi wrote:
>
> > The following commit has been merged into the x86/entry branch of tip:
> >
> > Commit-ID: e6d92b6680371ae1aeeb6c5eb2387fdc5d9a2c89
> > Gitweb:
The following commit has been merged into the x86/entry branch of tip:
Commit-ID: e6d92b6680371ae1aeeb6c5eb2387fdc5d9a2c89
Gitweb:
https://git.kernel.org/tip/e6d92b6680371ae1aeeb6c5eb2387fdc5d9a2c89
Author:Andrea Righi
AuthorDate:Thu, 14 Jan 2021 12:48:35 +01:00
Committer
ot;)
Signed-off-by: Andrea Righi
---
arch/x86/entry/Makefile | 3 ++-
arch/x86/entry/thunk_32.S | 2 --
arch/x86/entry/thunk_64.S | 4
3 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile
index 08bf95dbc911..83c98dae74a6 100644
event that we are currently processing is not the last
event in the buffer.
Link: https://lwn.net/Articles/831207
Fixes: a389d86f7fd0 ("ring-buffer: Have nested events still record running time
stamp")
Signed-off-by: Andrea Righi
---
kernel/trace/ring_buffer.c | 6 +++---
1 file
On Wed, Nov 25, 2020 at 03:15:18PM +0100, Andrea Righi wrote:
...
> > I'd hate to see this in stable 3 days after Linus merges it...
> >
> > Do these need _irqsave, too?
> >
> > drivers/leds/led-triggers.c: read_lock(&trig->leddev_list_lock);
>
ower_supply_update_bat_leds()
-> led_trigger_blink() -> led_trigger_blink_setup() (workqueue context),
and potentially prevent other similar usages.
Link: https://lore.kernel.org/lkml/20201101092614.GB3989@xps-13-7390/
Fixes: eb25cb9956cc ("leds: convert IDE trigger to common disk trigger&qu
: CPU 1:CPU 2:
> > - - -
> > led_trigger_event():
> >read_lock(&trig->leddev_list_lock);
> >
> >
On Mon, Nov 02, 2020 at 10:09:28AM +0100, Andrea Righi wrote:
> On Mon, Nov 02, 2020 at 09:56:58AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > > I'm getting the following lockdep splat (see below).
> > > > >
> > > >
ock_irqsave(&host->lock);
Fix by using read_lock_irqsave/irqrestore() in led_trigger_event(), so
that no interrupt can happen in between, preventing the deadlock
condition.
Link: https://lore.kernel.org/lkml/20201101092614.GB3989@xps-13-7390/
Fixes: eb25cb9956cc ("leds: convert IDE tri
On Mon, Nov 02, 2020 at 09:56:58AM +0100, Pavel Machek wrote:
> Hi!
>
> > > > I'm getting the following lockdep splat (see below).
> > > >
> > > > Apparently this warning starts to be reported after applying:
> > > >
> > > > e918188611f0 ("locking: More accurate annotations for read_lock()")
>
On Sun, Nov 01, 2020 at 05:28:38PM +0100, Pavel Machek wrote:
> Hi!
>
> > I'm getting the following lockdep splat (see below).
> >
> > Apparently this warning starts to be reported after applying:
> >
> > e918188611f0 ("locking: More accurate annotations for read_lock()")
> >
> > It looks like
On Sat, Oct 31, 2020 at 06:17:40PM +0800, Boqun Feng wrote:
> Hi Andrea,
>
> On Sun, Nov 01, 2020 at 10:26:14AM +0100, Andrea Righi wrote:
> > I'm getting the following lockdep splat (see below).
> >
> > Apparently this warning starts to be reported after
I'm getting the following lockdep splat (see below).
Apparently this warning starts to be reported after applying:
e918188611f0 ("locking: More accurate annotations for read_lock()")
It looks like a false positive to me, but it made me think a bit and
IIUC there can be still a potential deadloc
: https://lore.kernel.org/lkml/20201024131333.GA32124@xps-13-7390
Fixes: aa75f4d3daae ("ext4: main fast-commit commit path")
Signed-off-by: Andrea Righi
---
fs/ext4/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 03c2253
On Sat, Oct 24, 2020 at 03:13:37PM +0200, Andrea Righi wrote:
> I'm getting the following error if I try to create and activate a swap
> file defined on an ext4 filesystem:
>
> [ 34.406479] swapon: file is not committed
>
> The swap file is created in the root filesy
I'm getting the following error if I try to create and activate a swap
file defined on an ext4 filesystem:
[ 34.406479] swapon: file is not committed
The swap file is created in the root filesystem (ext4 mounted with the
following options):
$ grep " / " /proc/mounts
/dev/vda1 / ext4 rw,relati
On Mon, Oct 05, 2020 at 03:46:12PM +0100, Chris Down wrote:
> Andrea Righi writes:
> > senpai is focused at estimating the ideal memory requirements without
> > affecting performance. And this covers the use case about reducing
> > memory footprint.
> >
> > In my
On Mon, Oct 05, 2020 at 12:25:55PM +0100, Chris Down wrote:
> Andrea Righi writes:
> > This feature has been successfully used to improve hibernation time of
> > cloud computing instances.
> >
> > Certain cloud providers allow to run "spot instances": low
On Mon, Oct 05, 2020 at 10:35:16AM +0200, Michal Hocko wrote:
> A similar thing has been proposed recently by Shakeel
> http://lkml.kernel.org/r/20200909215752.1725525-1-shake...@google.com
> Please have a look at the follow up discussion.
Thanks for pointing this out, I wasn't aware of that patch
is writing to memory.swap.reclaim (i.e., to set a timeout for the whole
memory reclaim run).
Signed-off-by: Andrea Righi
---
Documentation/admin-guide/cgroup-v2.rst | 18
include/linux/memcontrol.h | 4 ++
mm/memcontrol.c | 59 ++
ease functionality (to re-load swapped out pages,
since it ended being not very useful)
- added the possibility to show the number of memory reclaimed in the
last attempt (per-memcg)
----
Andrea Righi (2):
mm: memcontrol: make
: Andrea Righi
---
include/linux/swap.h | 9 -
mm/vmscan.c | 6 +++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 661046994db4..1490b09a6e6c 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -368,7
On Mon, Sep 21, 2020 at 05:36:30PM +0200, Rafael J. Wysocki wrote:
...
> > > 3. It is not clear how much mm_reclaim/release is going to help. If
> > > the preloading of the swapped-out pages uses some kind of LIFO order,
> > > and can batch multiple pages, then it might help. Otherwise demand
> >
On Thu, Jul 30, 2020 at 10:11:52AM -0500, Justin Forbes wrote:
> On Mon, Jul 27, 2020 at 8:05 AM Andrea Righi
> wrote:
> >
> > I'm experiencing this build error on arm64 after updating to gcc 10:
> >
> > crypto/aegis128-neon-inner.c: In function 'crypto_
I'm experiencing this build error on arm64 after updating to gcc 10:
crypto/aegis128-neon-inner.c: In function 'crypto_aegis128_init_neon':
crypto/aegis128-neon-inner.c:151:3: error: incompatible types when initializing
type 'unsigned char' using type 'uint8x16_t'
151 | k ^ vld1q_u8(const0),
re to check also for state == "Closed" in step 4 to prevent the
deadlock.
Also add a 5 sec timeout any time we wait for the bus state to change,
to avoid getting stuck forever in wait_event().
Signed-off-by: Andrea Righi
---
Changes in v2:
- remove all dev_dbg() calls (as suggested by
On Thu, Jul 23, 2020 at 02:57:22PM -0700, David Miller wrote:
> From: Andrea Righi
> Date: Wed, 22 Jul 2020 08:52:11 +0200
>
> > +static int xennet_remove(struct xenbus_device *dev)
> > +{
> > + struct netfront_info *info = dev_get_drvdata(&dev->dev);
>
On Wed, Jul 22, 2020 at 07:04:25PM +0100, Matthew Wilcox wrote:
> On Wed, Jul 22, 2020 at 07:44:36PM +0200, Andrea Righi wrote:
> > Waiting for lock_page() with mm->mmap_sem held in unuse_pte_range() can
> > lead to stalls while running swapoff (i.e., not being able to ssh i
ation.
Under these conditions and without this patch applied the system can be
stalled even for 15min, with this patch applied the system is always
responsive.
Signed-off-by: Andrea Righi
---
mm/swapfile.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a
re to check also for state == "Closed" in step 4 to prevent the
deadlock.
Also add a 5 sec timeout any time we wait for the bus state to change,
to avoid getting stuck forever in wait_event() and add a debug message
to help tracking down potential similar issues.
Signed-off-by: An
On Mon, Jun 08, 2020 at 03:23:22PM -0700, Luigi Semenzato wrote:
> Hi Andrea,
>
> 1. This mechanism is quite general. It is possible that, although
> hibernation may be an important use, there will be other uses for it.
> I suggest leaving the hibernation example and performance analysis,
> but n
ot; pages are unused, if it is true
simply ignore "pages_to_unuse" and wait until all the pages are unused.
In any case the value of 0 in "pages_to_unuse" means "all pages".
This is required by the PM / hibernation opportunistic memory reclaim
feature.
Signed-off-by:
e a better quality of
service in the overall cloud infrastructure.
== See also ==
[1] https://lwn.net/Articles/821158/
[2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html
Signed-off-by: Andrea Righi
---
Documentation/ABI/testing/sysfs-power | 38 +++
include/
amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html
[2] https://lwn.net/Articles/821158/
--------
Andrea Righi (2):
mm: swap: allow partial swapoff with try_to_unuse()
PM: hibernate: introduce opportunistic memo
On Wed, Aug 07, 2019 at 09:53:46PM +0800, Coly Li wrote:
> On 2019/8/7 6:38 下午, Andrea Righi wrote:
> > bcache_allocator can call the following:
> >
> > bch_allocator_thread()
> > -> bch_prio_write()
> > -> bch_bucket_alloc()
> > ->
Commit-ID: f1c6ece23729257fb46562ff9224cf5f61b818da
Gitweb: https://git.kernel.org/tip/f1c6ece23729257fb46562ff9224cf5f61b818da
Author: Andrea Righi
AuthorDate: Mon, 12 Aug 2019 20:43:02 +0200
Committer: Ingo Molnar
CommitDate: Mon, 19 Aug 2019 12:22:19 +0200
kprobes: Fix potential
t*'
That immediately triggers the lockdep splat.
Fix by acquiring text_mutex before module_mutex in kprobe_optimizer().
Fixes: d5b844a2cf50 ("ftrace/x86: Remove possible deadlock between
register_kprobe() and ftrace_run_update_code()")
Signed-off-by: Andrea Righi
---
kernel/kp
Moreover, make sure to wake up the garbage collector thread when
bch_prio_write() is failing to allocate buckets.
BugLink: https://bugs.launchpad.net/bugs/1784665
BugLink: https://bugs.launchpad.net/bugs/1796292
Signed-off-by: Andrea Righi
---
Changes in v3:
- prevent buckets leak in bch_prio_write(
On Tue, Aug 06, 2019 at 07:36:48PM +0200, Andrea Righi wrote:
> On Tue, Aug 06, 2019 at 11:18:01AM +0200, Andrea Righi wrote:
> > bcache_allocator() can call the following:
> >
> > bch_allocator_thread()
> > -> bch_prio_write()
> > -> bch_bucket_
On Tue, Aug 06, 2019 at 11:18:01AM +0200, Andrea Righi wrote:
> bcache_allocator() can call the following:
>
> bch_allocator_thread()
> -> bch_prio_write()
> -> bch_bucket_alloc()
> -> wait on &ca->set->bucket_wait
>
> But the wake up ev
Moreover, make sure to wake up the garbage collector thread when
bch_prio_write() is failing to allocate buckets.
BugLink: https://bugs.launchpad.net/bugs/1784665
BugLink: https://bugs.launchpad.net/bugs/1796292
Signed-off-by: Andrea Righi
---
Changes in v2:
- prevent retry_invalidate busy loop
On Wed, Jul 10, 2019 at 05:46:56PM +0200, Andrea Righi wrote:
> On Wed, Jul 10, 2019 at 11:11:37PM +0800, Coly Li wrote:
> > On 2019/7/10 5:31 下午, Andrea Righi wrote:
> > > bcache_allocator() can call the following:
> > >
> > > bch_allocato
On Wed, Jul 10, 2019 at 11:11:37PM +0800, Coly Li wrote:
> On 2019/7/10 5:31 下午, Andrea Righi wrote:
> > bcache_allocator() can call the following:
> >
> > bch_allocator_thread()
> > -> bch_prio_write()
> > -> bch_bucket_alloc()
> >
er waits on itself.
Moreover, make sure to wake up the garbage collector thread when
bch_prio_write() is failing to allocate buckets.
BugLink: https://bugs.launchpad.net/bugs/1784665
Signed-off-by: Andrea Righi
---
drivers/md/bcache/alloc.c | 6 +-
drivers/md/bcache/bcache.h | 2
in all the
requested data.
BugLink: https://bugs.launchpad.net/bugs/1813244
Signed-off-by: Andrea Righi
---
Changes in v2:
- correctly resize to current_size+req_size (thanks to Pravin)
net/openvswitch/flow_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/o
his breaks one of my tests (which I probe on do_IRQ).
>
> OK, it seems this patch is a bit redundant, because
> I found that these interrupt handler issue has been fixed
> by Andrea's commit before merge this patch.
>
> commit a50480cb6d61d5c5fc13308479407b628b6bc1c5
> A
dev/sde
- mount it:
# mount /dev/sdb /mnt
- run btrfs scrub in a loop:
# while :; do btrfs scrub start -BR /mnt; done
BugLink: https://bugs.launchpad.net/bugs/1812845
Reviewed-by: Johannes Thumshirn
Signed-off-by: Andrea Righi
---
Changes in v2:
- added a better description about this
g/lkml/2019/3/7/640
Signed-off-by: Andrea Righi
---
Changes in v4:
- fix a build bug when CONFIG_BLOCK is unset
block/blk-cgroup.c | 130 +++
block/blk-throttle.c | 11 ++-
fs/fs-writeback.c| 5 ++
fs/sync.c
g/lkml/2019/3/7/640
Signed-off-by: Andrea Righi
---
Changes in v3:
- drop sync(2) isolation patches (this will be addressed by another
patch, potentially operating at the fs namespace level)
- use a per-bdi lock and a per-bdi list instead of a global lock and a
global list to save the
On Fri, Mar 08, 2019 at 12:22:20PM -0500, Josef Bacik wrote:
> On Thu, Mar 07, 2019 at 07:08:31PM +0100, Andrea Righi wrote:
> > = Problem =
> >
> > When sync() is executed from a high-priority cgroup, the process is forced
> > to
> > wait the completion of the
On Thu, Mar 07, 2019 at 05:07:01PM -0500, Josef Bacik wrote:
> On Thu, Mar 07, 2019 at 07:08:34PM +0100, Andrea Righi wrote:
> > Keep track of the inodes that have been dirtied by each blkcg cgroup and
> > make sure that a blkcg issuing a sync() can trigger the writeback + wait
&g
On Thu, Mar 07, 2019 at 05:10:53PM -0500, Josef Bacik wrote:
> On Thu, Mar 07, 2019 at 07:08:32PM +0100, Andrea Righi wrote:
> > Prevent priority inversion problem when a high-priority blkcg issues a
> > sync() and it is forced to wait the completion of all the writeback I/O
>
e out only dirty pages that
belong to the cgroup itself (except for the root cgroup that would still
be able to write out all pages globally).
Signed-off-by: Andrea Righi
---
Documentation/admin-guide/cgroup-v2.rst | 9 ++
block/blk-throttle.c
behavior is applied: sync() triggers the
writeback of any dirty page.
Signed-off-by: Andrea Righi
---
block/blk-cgroup.c | 47 ++
fs/fs-writeback.c | 52 +++---
fs/inode.c | 1 +
include/linux/blk
i.e., a better policy could be to
adjust the throttling I/O rate using the blkcg with the highest speed
from the list of waiters - priority inheritance, kinda).
Signed-off-by: Andrea Righi
---
block/blk-cgroup.c | 131 +++
block/blk-throttle.c |
e sync
real 0m0,768s
user 0m0,001s
sys0m0,008s
[ Time range goes from 0.7s to 1.6s ]
Changes in v2:
- fix: properly keep track of sync waiters when a blkcg is writing to
many block devices at the same time
Andrea Righi (3):
blkcg: prevent priority inversion problem during sync
e sync
real 0m0,768s
user 0m0,001s
sys 0m0,008s
[ Time range goes from 0.7s to 1.6s ]
Andrea Righi (3):
blkcg: prevent priority inversion problem during sync()
blkcg: introduce io.sync_isolation
blkcg: implement sync() isolation
Documentation/admin-guide/cgroup-v2.rs
behavior is applied: sync() triggers the
writeback of any dirty page.
Signed-off-by: Andrea Righi
---
block/blk-cgroup.c | 47 ++
fs/fs-writeback.c | 52 +++---
fs/inode.c | 1 +
include/linux/blk
i.e., a better policy could be to
adjust the throttling I/O rate using the blkcg with the highest speed
from the list of waiters - priority inheritance, kinda).
Signed-off-by: Andrea Righi
---
block/blk-cgroup.c | 73
block/blk-throttle.c |
e out only dirty pages that
belong to the cgroup itself (except for the root cgroup that would still
be able to write out all pages globally).
Signed-off-by: Andrea Righi
---
Documentation/admin-guide/cgroup-v2.rst | 9 ++
block/blk-throttle.c
Commit-ID: 02106f883cd745523f7766d90a739f983f19e650
Gitweb: https://git.kernel.org/tip/02106f883cd745523f7766d90a739f983f19e650
Author: Andrea Righi
AuthorDate: Wed, 13 Feb 2019 01:15:34 +0900
Committer: Ingo Molnar
CommitDate: Wed, 13 Feb 2019 08:16:41 +0100
kprobes: Prohibit probing
On Mon, Feb 11, 2019 at 10:39:34AM -0500, Josef Bacik wrote:
> On Sat, Feb 09, 2019 at 03:07:49PM +0100, Andrea Righi wrote:
> > This is an attempt to mitigate the priority inversion problem of a
> > high-priority blkcg issuing a sync() and being forced to wait the
> >
didn't come up with any definitive solution.
This patch is not a definitive solution either, but it's an attempt to
continue addressing this issue and handling the priority inversion
problem with sync() in a better way.
Signed-off-by: Andrea Righi
---
Changes in v2:
- fix: use th
On Sat, Feb 09, 2019 at 01:06:33PM +0100, Andrea Righi wrote:
...
> +/**
> + * blkcg_wb_waiters_on_bdi - check for writeback waiters on a block device
> + * @bdi: block device to check
> + *
> + * Return true if any other blkcg is waiting for writeback on the target
> block
&
didn't come up with any definitive solution.
This patch is not a definitive solution either, but it's an attempt to
continue addressing the issue and, hopefully, handle the priority
inversion problem with sync() in a better way.
Signed-off-by: Andrea Righi
---
block/blk-cg
On Mon, Jan 28, 2019 at 02:26:20PM -0500, Vivek Goyal wrote:
> On Mon, Jan 28, 2019 at 06:41:29PM +0100, Andrea Righi wrote:
> > Hi Vivek,
> >
> > sorry for the late reply.
> >
> > On Mon, Jan 21, 2019 at 04:47:15PM -0500, Vivek Goyal wrote:
> > > On Sat
Hi Vivek,
sorry for the late reply.
On Mon, Jan 21, 2019 at 04:47:15PM -0500, Vivek Goyal wrote:
> On Sat, Jan 19, 2019 at 11:08:27AM +0100, Andrea Righi wrote:
>
> [..]
> > Alright, let's skip the root cgroup for now. I think the point here is
> > if we want to prov
On Fri, Jan 18, 2019 at 02:46:53PM -0500, Josef Bacik wrote:
> On Fri, Jan 18, 2019 at 07:44:03PM +0100, Andrea Righi wrote:
> > On Fri, Jan 18, 2019 at 11:35:31AM -0500, Josef Bacik wrote:
> > > On Fri, Jan 18, 2019 at 11:31:24AM +0100, Andrea Righi wrote:
> > > >
On Fri, Jan 18, 2019 at 06:07:45PM +0100, Paolo Valente wrote:
>
>
> > Il giorno 18 gen 2019, alle ore 17:35, Josef Bacik
> > ha scritto:
> >
> > On Fri, Jan 18, 2019 at 11:31:24AM +0100, Andrea Righi wrote:
> >> This is a redesign of my old cgroup-io-th
On Fri, Jan 18, 2019 at 11:35:31AM -0500, Josef Bacik wrote:
> On Fri, Jan 18, 2019 at 11:31:24AM +0100, Andrea Righi wrote:
> > This is a redesign of my old cgroup-io-throttle controller:
> > https://lwn.net/Articles/330531/
> >
> > I'm resuming this old patch to
On Fri, Jan 18, 2019 at 12:04:17PM +0100, Paolo Valente wrote:
>
>
> > Il giorno 18 gen 2019, alle ore 11:31, Andrea Righi
> > ha scritto:
> >
> > This is a redesign of my old cgroup-io-throttle controller:
> > https://lwn.net/Articles/330531/
> >
&g
Document the filesystem I/O controller: description, usage, design,
etc.
Signed-off-by: Andrea Righi
---
Documentation/cgroup-v1/fsio-throttle.txt | 142 ++
1 file changed, 142 insertions(+)
create mode 100644 Documentation/cgroup-v1/fsio-throttle.txt
diff --git a
event I/O spikes during
writeback, right?
A: Correct, the tradeoff here is to tolerate I/O bursts during writeback to
avoid priority inversion problems in the system.
Andrea Righi (3):
fsio-throttle: documentation
fsio-throttle: controller infrastructure
fsio-throttle: instrum
Apply the fsio controller to the opportune kernel functions to evaluate
and throttle filesystem I/O.
Signed-off-by: Andrea Righi
---
block/blk-core.c | 10 ++
include/linux/writeback.h | 7 ++-
mm/filemap.c | 20 +++-
mm/page-writeback.c
This is the core of the fsio-throttle controller: it defines the
interface to the cgroup subsystem and implements the I/O measurement and
throttling logic.
Signed-off-by: Andrea Righi
---
include/linux/cgroup_subsys.h | 4 +
include/linux/fsio-throttle.h | 43 +++
init/Kconfig
can be called
> by configuration change, I'll continue to test it.
Hi Masami,
I think I've found another recursion problem. Could you include also
this one?
Thanks,
From: Andrea Righi
Subject: [PATCH] kprobes: prohibit probing on bsearch()
Since kprobe breakpoing handler is usi
//lore.kernel.org/lkml/20190111095108.b79a2ee026185cbd62365...@kernel.org
Fixes: 6212dd29683e ("tracing/kprobes: Use dyn_event framework for kprobe
events")
Cc: sta...@vger.kernel.org
Signed-off-by: Andrea Righi
Signed-off-by: Masami Hiramatsu
---
v2: argument check refactoring
kernel/trace/tra
0xf0
? _cond_resched+0x19/0x40
vfs_write+0xb1/0x1a0
ksys_write+0x55/0xc0
__x64_sys_write+0x1a/0x20
do_syscall_64+0x5a/0x120
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fix by doing the proper argument check when a NULL symbol is passed in
trace_kprobe_create().
Signed-off-by: Andrea Ri
duced with the asm-coded trampoline
> code, since previously it used another kprobe for hooking
> the function return placeholder (which only has a nop) and
> trampoline handler was called from that kprobe.
>
> To fix this bug, I introduced a dummy kprobe and set it in
> current_kprobe as we did in old days.
>
> Thank you,
It looks all good to me, with this patch set I couldn't break the
kernel in any way.
Tested-by: Andrea Righi
Thanks,
-Andrea
On Mon, Jan 07, 2019 at 04:28:33PM -0500, Steven Rostedt wrote:
> On Mon, 7 Jan 2019 22:19:04 +0100
> Andrea Righi wrote:
>
> > > > If we put a kretprobe to raw_spin_lock_irqsave() it looks like
> > > > kretprobe is going to call kretprobe...
> > >
On Mon, Jan 07, 2019 at 02:59:18PM -0500, Steven Rostedt wrote:
> On Mon, 7 Jan 2019 20:52:09 +0100
> Andrea Righi wrote:
>
> > > Ug, kretprobe calls spinlocks in the callback? I wonder if we can
> > > remove them.
> > >
> > > I'm guessing this
On Mon, Jan 07, 2019 at 02:27:49PM -0500, Steven Rostedt wrote:
> On Mon, 7 Jan 2019 19:34:44 +0100
> Andrea Righi wrote:
>
> > On Mon, Jan 07, 2019 at 10:31:34PM +0900, Masami Hiramatsu wrote:
> > ...
> > > BTW, this is not all of issues. To remove CONFIG_KPRO
endif
#ifndef CONFIG_INLINE_SPIN_UNLOCK_BH
@@ -200,6 +210,7 @@ void __lockfunc _raw_spin_unlock_bh(raw_spinlock_t *lock)
__raw_spin_unlock_bh(lock);
}
EXPORT_SYMBOL(_raw_spin_unlock_bh);
+NOKPROBE_SYMBOL(_raw_spin_unlock_bh);
#endif
#ifndef CONFIG_INLINE_READ_TRYLOCK
Signed-off-by: Andrea Righi
kernel panic happens only when we put 2 k*ret*probes on
> ftrace_ops_assist_func() and other functions. If we put kprobes, it
> doesn't cause any issue, since it doesn't change the return address.
>
> To fix (or just avoid) this issue, we can introduce a frame pointer
> verification to skip wrong order entries. And I also would like to
> blacklist those functions because those are part of ftrace-based
> kprobe handling routine.
>
> BTW, this is not all of issues. To remove CONFIG_KPROBE_EVENTS_ON_NOTRACE
> I'm trying to find out other notrace functions which can cause
> kernel crash by probing. Mostly done on x86, so I'll post it
> after this series.
>
> Thank you,
Apart than the missing include in PATCH 2/2
everything else looks good to me.
Tested-by: Andrea Righi
Thanks!
-Andrea
On Mon, Jan 07, 2019 at 10:32:32PM +0900, Masami Hiramatsu wrote:
> Mark ftrace mcount handler functions nokprobe since
> probing on these functions with kretprobe pushes
> return address incorrectly on kretprobe shadow stack.
>
> Signed-off-by: Masami Hiramatsu
> Reported-by: Francis Deslauriers
On Tue, Jan 01, 2019 at 10:16:54PM +0900, Masami Hiramatsu wrote:
...
> > > > > Do you see a nice and clean way to blacklist all these functions
> > > > > (something like arch_populate_kprobe_blacklist()), or should we just
> > > > > flag all of them explicitly with NOKPROBE_SYMBOL()?
> > > >
> >
On Tue, Dec 18, 2018 at 06:24:35PM +0100, Andrea Righi wrote:
> On Tue, Dec 18, 2018 at 01:50:26PM +0900, Masami Hiramatsu wrote:
> ...
> > > Side question: there are certain symbols in arch/x86/xen that should be
> > > blacklisted explicitly, because they're non-
On Tue, Dec 18, 2018 at 01:50:26PM +0900, Masami Hiramatsu wrote:
...
> > Side question: there are certain symbols in arch/x86/xen that should be
> > blacklisted explicitly, because they're non-attachable.
> >
> > More exactly, all functions defined in arch/x86/xen/spinlock.c,
> > arch/x86/xen/tim
ch_populate_kprobe_blacklist()
> so that user can get the correct kprobe blacklist in debugfs.
>
> Thank you,
Looks good to me. Thanks!
Tested-by: Andrea Righi
Side question: there are certain symbols in arch/x86/xen that should be
blacklisted explicitly, because they're non-attac
Blacklist symbols in Xen probe-prohibited areas, so that user can see
these prohibited symbols in debugfs.
See also: a50480cb6d61.
Signed-off-by: Andrea Righi
---
arch/x86/xen/xen-asm_64.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64
On Sat, Dec 08, 2018 at 12:48:59PM +0900, Masami Hiramatsu wrote:
> On Fri, 7 Dec 2018 18:58:05 +0100
> Andrea Righi wrote:
>
> > On Sat, Dec 08, 2018 at 01:01:20AM +0900, Masami Hiramatsu wrote:
> > > Hi Andrea and Ingo,
> > >
> > > Here is the pat
On Sat, Dec 08, 2018 at 12:42:10PM +0900, Masami Hiramatsu wrote:
> On Fri, 7 Dec 2018 18:00:26 +0100
> Andrea Righi wrote:
>
> > On Sat, Dec 08, 2018 at 01:01:20AM +0900, Masami Hiramatsu wrote:
> > > Hi Andrea and Ingo,
> > >
> > > Here is the pat
need to blacklist them or not.
In this way we don't have to introduce an
arch_populate_kprobe_blacklist() for each architecture.
Something like the following maybe.
Thanks.
[RFC] kprobes: blacklist all symbols in arch-defined prohibited area
From: Andrea Righi
Blacklist symbols in arch-d
debugfs.
>
> All archtectures which have custom prohibit areas should define
> its own arch_populate_kprobe_blacklist() function, but unless that,
> all symbols marked __kprobes are blacklisted.
>
> Reported-by: Andrea Righi
> Signed-off-by: Masami Hiramatsu
1 - 100 of 183 matches
Mail list logo
