it with a
declared global static mutex.
Fixes: a3df30984f4f ("vhost_task: Handle SIGKILL by flushing work and exiting")
Reported--by: syzbot+98edc2df894917b34...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis
---
kernel/vhost_task.c | 13 ++---
1 file changed, 6 insertions(+), 7
Confirm that skb->len is not 0 to ensure that skb length is valid.
Fixes: 114039b34201 ("bpf: Move skb->len == 0 checks into __bpf_redirect")
Reported-by: syzbot+e2c932aec5c8a6e1d...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis
---
net/bpf/test_run.c | 3 +++
1
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I’ve
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I’ve
before I die
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment. Since my days are numbered, I’ve
decided
Hi Jens and Neil,
Is there any feedback on this patch?
Thank you,
Edward Hsieh
On 3/3/2021 11:22 AM, Edward Hsieh wrote:
From: Edward Hsieh
For chained bio, trace_block_bio_complete in bio_endio is currently called
only by the parent bio once upon all chained bio completed.
However
On 28/02/2021 17:05, Alexey Dobriyan wrote:
> From 251ca5673886b5bb0a42004944290b9d2b267a4a Mon Sep 17 00:00:00 2001
> From: Alexey Dobriyan
> Date: Fri, 19 Feb 2021 13:37:24 +0300
> Subject: [PATCH 10/11] pragma once: delete few backslashes
>
> Some macros contain one backslash too many and end
On 02/16/2021 04:56 PM, Jose R Rodriguez wrote:
On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote:
On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <
edward.shish...@gmail.com> wrote:
On 12/23/2020 05:01 PM, M
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I’ve
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I have
On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin
wrote:
On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
I built Linux kernel 5.10.1-1 within the 'Debian way
On 05/02/2021 12:47, Bhaskar Chowdhury wrote:
>
>
> s/fuck/mess/
> s/fucking/s/
>
> Signed-off-by: Bhaskar Chowdhury
Right or wrong, these are not "spelling fixes".
Please do not misrepresent your patch in your Subject: line.
(Also, subsystem prefix should probably just be "net:
other channels, max 32)
>
> Which in turn triggers EINVAL on XDP processing:
>
> sfc :86:00.0 ext0: XDP TX failed (-22)
>
> Signed-off-by: Ivan Babrou
Acked-by: Edward Cree
Without wishing to weigh in on whether this caching is a good idea...
Wouldn't it be simpler, rather than having two separate "alloc" and "flush"
caches, to have a single larger cache, such that whenever it becomes full
we bulk flush the top half, and when it's empty we bulk alloc the bottom
[ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1
across:9765884k FS
[ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol
(fs/reiser4/init_volume.c:222)[edward-1932]:
[ 636.240812] NOTICE: brick /dev/sda6 has been registered
[ 636.243003] reiser4 (sda6): found disk
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I’ve
On 16/12/2020 08:45, Jesper Dangaard Brouer wrote:
> So, what I hear is that this fix is just pampering over the real issue.
Yes, it is, but it's better than nothing in the meantime while we work
out the complete fix.
> I suggest that you/we detect the situation, and have a code path that
> will
es from the driver's channel structures having been designed a
decade ago when 32 cpus ought to be enough for anybody... AFAIR the
hardware is capable of giving us something like 1024 evqs if we ask
for them, it just might not have that many msi-x vectors for us.)
Anyway, the patch looks correct, so
Acked-by: Edward Cree
-ed
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I have
On 27/11/2020 19:37, t...@redhat.com wrote:
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
> ---
> net/core/flow_offload.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/flow_offload.c b/net/core/flow_offload.c
>
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I’ve
On 24/11/2020 21:25, Kees Cook wrote:
> I still think this isn't right -- it's a case statement that runs off
> the end without an explicit flow control determination.
Proves too much — for instance
case foo:
case bar:
thing;
break;
doesn't require a fallthrough; after
On 25/11/2020 00:32, Miguel Ojeda wrote:
> I have said *authoring* lines of *this* kind takes a minute per line.
> Specifically: lines fixing the fallthrough warning mechanically and
> repeatedly where the compiler tells you to, and doing so full-time for
> a month.
> It is useful since it makes
Reiser5 Logical Volume Management - Updates
I am happy to inform, that Logical Volumes stuff has become more
stable. Also we introduce the following changes, which make logical
volumes administration more flexible and simple:
1. No balancing by default
Now all
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I have
On 10/27/2020 08:36 PM, Theodore Y. Ts'o wrote:
On Tue, Oct 27, 2020 at 01:53:31AM +0100, Edward Shishkin wrote:
reiser4progs 1.1.x Software Framework Release Number (SFRN) 4.0.1 file
system utilities should not be used to check/fix media formatted 'a
priori' in SFRN 4.0.2 and vice-versa
On 26/10/2020 23:47, Sasha Levin wrote:
> From: Edward Cree
>
> [ Upstream commit 1c0544d24927e4fad04f858216b8ea767a3bd123 ]
>
> Instead of using efx_tx_queue_partner(), which relies on the assumption
> that tx_queues_per_channel is 2, efx_tx_send_pending() ite
On 10/26/2020 02:07 AM, David Niklas wrote:
I'll reply to both of you in this email.
On Sun, 25 Oct 2020 02:04:22 -0700 (PDT)
Metztli Information Technology wrote:
Niltze, David-
A few observations are in order below:
On Sat, Oct 24, 2020 at 1:39 PM David Niklas
wrote:
Hello,
under removal == doesn't exist for user).
Thanks,
Edward.
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I’ve
Hello, I am Barrister Chris Tetteh Attorney to the late Engr. Steve Moore who
died with his wife and their three kids in a car accident. Before his death he
had funds valued at twenty seven Million dollars deposited in a bank. I need
your assistance to retrieve the money left behind by my
> On Mon, Sep 28 2020 at 21:05, Edward Cree wrote:
>> Only compile-tested so far, because I'm waiting for my kernel to
>> finish rebuilding with CONFIG_DEBUG_ATOMIC_SLEEP
I've now tested and confirmed that the might_sleep warning goes
away with this patch.
Thomas, do y
, which are happy with being
called from atomic contexts.
Fixes: f00bf2305cab ("sfc: don't update stats on VF when called in atomic
context")
Reported-by: Sebastian Andrzej Siewior
Signed-off-by: Edward Cree
---
Only compile-tested so far, because I'm waiting for my kernel to
finish
eck and the code concerned
doesn't seemto have changed a great deal since.
Anyway, this fix looks correct, and you can have my
Acked-by: Edward Cree
but I thinkit might be cleaner to avoid having to have this unused
can_sleep argument on all the NICs that don't need it, by instead
adding an upd
free to ignore it.
Thanks,
Edward.
I
thought it good to ignore the missing member instead of trying to dig up
what it was used for and why it was removed.
Thanks,
David
ropped by the core stack, but it seems to have no impact on related
> drivers' functionality.
> gro_normal_batch is left untouched as it's very individual for every
> single system configuration and might be tuned in manual order to
> achieve an optimal performance.
>
> Signed-
Hi!
Hope you are having a great day! I have come across your site, and I strongly
feel that your website is a perfect match for us.
We are a content marketing agency, and wed be thrilled if youd allow us to
post relevant and non-promotional content on your website. You can help us by
placing
On 08/28/2020 01:50 AM, Edward Shishkin wrote:
On 08/27/2020 11:53 PM, Metztli Information Technology wrote:
On Wed, Aug 26, 2020 at 2:13 PM Edward Shishkin
wrote:
[...]
FYI Although not officially, the Debian metaframework Buster AMD64
distribution might be the first to support native
On 08/27/2020 11:53 PM, Metztli Information Technology wrote:
On Wed, Aug 26, 2020 at 2:13 PM Edward Shishkin
wrote:
[...]
FYI Although not officially, the Debian metaframework Buster AMD64 distribution
might be the first to support native installation of Reiser4 SFRN 5.1.3, kernel
r4progs-2.0.3 (check by
"mkfs.reiser4 -p") - there is no need to specify it via option.
Have you had a chance to play with logical volumes (add/remove
bricks, etc)?
Thanks!
Edward.
On 13/08/2020 15:39, Christophe Leroy wrote:
> ppc6xx_defconfig fails building sfc.ko module, complaining
> about the lack of _umoddi3 symbol.
>
> This is due to the following test
>
> if (EFX_MIN_DMAQ_SIZE % reader->value) {
>
> Because reader->value is u64.
Already fixed in net.git
On 10/08/2020 16:51, Guenter Roeck wrote:
> On Thu, Aug 06, 2020 at 07:17:43PM +0100, Edward Cree wrote:
>> Maybe I should add a
>>
>> static inline u32 mod_u64(u64 dividend, u32 divisor)
>> {
>> return do_div(dividend, divisor);
>> }
> Yo
On 06/08/2020 00:48, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> master
> head: d15fe4ec043588beee823781602ddb51d0bc84c8
> commit: adcfc3482813fa2c34e5902005853f79c2aa [13398/13940] sfc_ef100:
> read Design Parameters at probe
erfs-devel mailing list.
(*) https://reiser4.wiki.kernel.org/index.php/Reiser4_Howto
https://sourceforge.net/projects/reiser4/files/
(**) https://sourceforge.net/projects/reiser4/files/reiser4-utils/
(***) https://marc.info/?l=reiserfs-devel=158086248927420=2
Thanks,
Edward.
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I’ve
On 02/08/2020 16:39, Jia-Ju Bai wrote:
> To fix this problem, "req->op" is assigned to a local variable, and then
> the driver accesses this variable instead of "req->op".
>
> Signed-off-by: Jia-Ju Bai
Not sure how necessary this is (or even if anyone's still usingSiena
SR-IOV, since it needed a
On 26/07/2020 11:58, Julia Lawall wrote:
> list_for_each_safe is able to handle an empty list.
> The only effect of avoiding the loop is not initializing the
> index variable.
> Drop list_empty tests in cases where these variables are not
> used.
Sure, why not.
Acked-by: Edward Cree
On 23/07/2020 20:08, David Miller wrote:
> From: Luo bin
> Date: Thu, 23 Jul 2020 22:40:37 +0800
>
>> +static int hinic_fw_reporter_dump(struct devlink_health_reporter *reporter,
>> + struct devlink_fmsg *fmsg, void *priv_ctx,
>> + struct
Reiser5: selective file migration.
Setting/clearing file "immobile" status
Earlier any migration of data blocks in reiser5 logical volumes
occurred only in the context of some volume balancing procedure, which
actually is a massive migration, aiming to keep
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I’ve
final wish before I die.
I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I
am suffering from a pro-long critical cancer, my doctors confirmed I
may not live beyond two months from now as my ill health has defiled
all forms of medical treatment.
Since my days are numbered, I’ve
On 24/06/2020 22:06, Jason A. Donenfeld wrote:
> Hi Alexander,
>
> This patch introduced a behavior change around GRO_DROP:
>
> napi_skb_finish used to sometimes return GRO_DROP:
>
>> -static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
>> +static gro_result_t
Disclaimer: *definitely* not speaking for my employer.
On 09/06/2020 18:19, Stephen Hemminger wrote:
> How many times have you or Linus argued about variable naming.
> Yes, words do matter and convey a lot of implied connotation and meaning.
Connotation, unlike denotation, is widely variable. I
On 09/06/2020 18:56, Joe Perches wrote:
> These are _not_ netif_ control flags. Some are though.
> For instance:
>
> $ git grep "MODULE_PARM.*\bdebug\b" drivers/net | head -10
> [...]
>
> These are all level/class output controls.
TIL, thanks! I should have looked deeperrather than assuming
they
On 09/06/2020 17:58, Joe Perches wrote:
> On Tue, 2020-06-09 at 13:16 +0200, Greg Kroah-Hartman wrote:
>> What is wrong with the existing control of dynamic
>> debug messages that you want to add another type of arbitrary grouping
>> to it?
> There is no existing grouping mechanism.
>
> Many
*/
...
Currently it works as if all files are "cold" (i.e. migrates
everything).
Once I find the current stuff more-or-less stable I'll add temperature
support and send the patch.
Thanks,
Edward.
On 05/30/2020 02:32 PM, jose@metztli.com wrote:
On Mon, May 25, 2020 at 6:08 PM Edward Shishkin
wrote:
Reiser5: Data Tiering. Burst Buffers
Speedup synchronous modifications
Dumping peaks of IO load to a proxy device
Now you can
On 28/05/2020 20:49, David Miller wrote:
> From: Arnd Bergmann
> Date: Wed, 27 May 2020 15:41:06 +0200
>
>> 'nic_data' is no longer used outside of the #ifdef block
>> in efx_ef10_set_mac_address:
>>
>> drivers/net/ethernet/sfc/ef10.c:3231:28: error: unused variable 'nic_data'
>>
Reiser5: Data Tiering. Burst Buffers
Speedup synchronous modifications
Dumping peaks of IO load to a proxy device
Now you can add a small high-performance block device to your large
logical volume composed of relatively slow commodity disks and
checking table before dereferencing it when checking for a null
> table->must_restore_filters.
>
> Addresses-Coverity: ("Dereference before null check")
> Fixes: e4fe938cff04 ("sfc: move 'must restore' flags out of ef10-specific
> nic_data")
> Signed-off-by: Colin Ian King
Acked-by: Edward Cree
in a way more common napi_gro_receive()
>>> to speed up non-merged (GRO_NORMAL) skbs for a wide range of drivers,
>>> including gro_cells and mac80211 users.
>>>
>>> Signed-off-by: Alexander Lobakin
Acked-by: Edward Cree
but I think this needs review from the socionext folks as well.
On 10/10/2019 15:42, Alexander Lobakin wrote:
> Commit 323ebb61e32b4 ("net: use listified RX for handling GRO_NORMAL
> skbs") made use of listified skb processing for the users of
> napi_gro_frags().
> The same technique can be used in a way more common napi_gro_receive()
> to speed up non-merged
On 10/10/2019 15:42, Alexander Lobakin wrote:
> Commit 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL
> skbs") have introduced a sysctl variable gro_normal_batch for defining
> a limit for listified Rx of GRO_NORMAL skbs. The initial value of 8 is
> purely arbitrary and has been
On Thu, Aug 29, 2019 at 11:44 AM Qian Cai wrote:
>
> On Thu, 2019-08-29 at 09:09 -0700, Edward Chron wrote:
>
> > > Feel like you are going in circles to "sell" without any new information.
> > > If
> > > you
> > > need to deal w
On Thu, Aug 29, 2019 at 9:18 AM Michal Hocko wrote:
>
> On Thu 29-08-19 08:03:19, Edward Chron wrote:
> > On Thu, Aug 29, 2019 at 4:56 AM Michal Hocko wrote:
> [...]
> > > Or simply provide a hook with the oom_control to be called to report
> > > without replac
On Thu, Aug 29, 2019 at 8:42 AM Qian Cai wrote:
>
> On Thu, 2019-08-29 at 08:03 -0700, Edward Chron wrote:
> > On Thu, Aug 29, 2019 at 4:56 AM Michal Hocko wrote:
> > >
> > > On Thu 29-08-19 19:14:46, Tetsuo Handa wrote:
> > > > On 2019/08/29 16:11, Mic
On Thu, Aug 29, 2019 at 7:09 AM Tetsuo Handa
wrote:
>
> On 2019/08/29 20:56, Michal Hocko wrote:
> >> But please be aware that, I REPEAT AGAIN, I don't think neither eBPF nor
> >> SystemTap will be suitable for dumping OOM information. OOM situation means
> >> that even single page fault event
On Thu, Aug 29, 2019 at 12:11 AM Michal Hocko wrote:
>
> On Wed 28-08-19 12:46:20, Edward Chron wrote:
> [...]
> > Our belief is if you really think eBPF is the preferred mechanism
> > then move OOM reporting to an eBPF.
>
> I've said that all this additional inform
On Thu, Aug 29, 2019 at 4:56 AM Michal Hocko wrote:
>
> On Thu 29-08-19 19:14:46, Tetsuo Handa wrote:
> > On 2019/08/29 16:11, Michal Hocko wrote:
> > > On Wed 28-08-19 12:46:20, Edward Chron wrote:
> > >> Our belief is if you really think eBPF is the preferr
On Wed, Aug 28, 2019 at 1:04 PM Edward Chron wrote:
>
> On Wed, Aug 28, 2019 at 3:12 AM Tetsuo Handa
> wrote:
> >
> > On 2019/08/28 16:08, Michal Hocko wrote:
> > > On Tue 27-08-19 19:47:22, Edward Chron wrote:
> > >> For production systems instal
On Wed, Aug 28, 2019 at 1:18 PM Qian Cai wrote:
>
> On Wed, 2019-08-28 at 12:46 -0700, Edward Chron wrote:
> > But with the caveat that running a eBPF script that it isn't standard Linux
> > operating procedure, at this point in time any way will not be well
> > rec
On Wed, Aug 28, 2019 at 3:12 AM Tetsuo Handa
wrote:
>
> On 2019/08/28 16:08, Michal Hocko wrote:
> > On Tue 27-08-19 19:47:22, Edward Chron wrote:
> >> For production systems installing and updating EBPF scripts may someday
> >> be very common, but I wonder how d
On Tue, Aug 27, 2019 at 6:32 PM Qian Cai wrote:
>
>
>
> > On Aug 27, 2019, at 9:13 PM, Edward Chron wrote:
> >
> > On Tue, Aug 27, 2019 at 5:50 PM Qian Cai wrote:
> >>
> >>
> >>
> >>> On Aug 27, 2019, at 8:23 PM, Edward Chron w
On Tue, Aug 27, 2019 at 5:50 PM Qian Cai wrote:
>
>
>
> > On Aug 27, 2019, at 8:23 PM, Edward Chron wrote:
> >
> >
> >
> > On Tue, Aug 27, 2019 at 5:40 AM Qian Cai wrote:
> > On Mon, 2019-08-26 at 12:36 -0700, Edward Chron wrote:
> > >
On Tue, Aug 27, 2019 at 12:15 AM Michal Hocko wrote:
>
> On Mon 26-08-19 12:36:28, Edward Chron wrote:
> [...]
> > Extensibility using OOM debug options
> > -
> > What is needed is an extensible system to optionally configure
Output:
-
Sample Tasks Summary message output:
Aug 13 18:52:48 yoursystem kernel: Threads: 492 Processes: 248
forks_since_boot: 7786 procs_runable: 4 procs_iowait: 0
Signed-off-by: Edward Chron
---
mm/Kconfig.debug| 16
mm/oom_kill_debug.c | 27
ObjSize AlignSize Objs/Slab Pgs/Slab ActiveSlab TotalSlab Slab_Name
Aug 13 18:52:47 mysrvr kernel: 403412 1613 1648
224 256161103103 skbuff_head..
Signed-off-by: Edward Chron
---
mm/Kconfig.debug| 15 +++
mm
t (minsize = 0.1% of totalpages):
Aug 13 20:16:30 yourserver kernel: Summary: OOM Tasks considered:245
printed:33 minimum size:32576kB total-pages:32579084kB
Signed-off-by: Edward Chron
---
include/linux/oom.h | 1 +
mm/Kconfig.debug| 34 ++
mm/oom_kill.c
6 09:37:21 egc103 kernel: [ 7707]7553 10383 10383
7707 S 0.132 0.350 1056804 1054040 1052796
2092 0 0 1944 684 1052860
136 4 0 0 0 0
0 1000 oomprocs
Signed-off-by: Edward
line output:
Jul 22 20:16:09 yoursystem kernel: Vmalloc size=2625536 pages=640
caller=__do_sys_swapon+0x78e/0x1130
Sample summary print line output:
Jul 22 19:03:26 yoursystem kernel: Summary: Vmalloc entries examined:1070
printed:989 minsize:0kB
Signed-off-by: Edward Chron
---
include
entries: 6 lastFlush: 1720s
hGrows: 0 allocs: 7 destroys: 1 lookups: 0 hits: 0
resFailed: 0 gcRuns/Forced: 110 / 0 tblFull: 0 proxyQlen: 0
Signed-off-by: Edward Chron
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
---
include/net/neighbour.h | 12 +
to enabled.
Sample Output
-
There is no change to the standard OOM output with this option other than
the stanrd Linux OOM report Unreclaimable info is output for every OOM
Event, not just OOM Events where slab usage exceeds user process memory
usage.
Signed-off-by: Edward Chron
:26:34 yoursystem kernel: Slabs Total: 151212kB Reclaim: 50632kB
Unreclaim: 100580kB
Signed-off-by: Edward Chron
---
mm/Kconfig.debug| 30 +
mm/oom_kill.c | 11 +++-
mm/oom_kill_debug.c | 42 +
mm/oom_kill_debug.h | 4 +++
mm/sla
t file
as needed.
-----
Edward Chron (10):
mm/oom_debug: Add Debug base code
mm/oom_debug: Add System State Summary
mm/oom_debug: Add Tasks Summary
mm/oom_debug: Add ARP and ND Table Summary usage
mm/oom_debug: Add Select Slabs Print
mm/oom_debug: Ad
nabled. By default each configured Select Print OOM debug option
has a default print limiting minimum entry size of 10 or 1% of memory.
-
Signed-off-by: Edward Chron
---
mm/Kconfig.debug| 17 +++
mm/Makefile | 1
message:
Jul 27 10:56:46 yoursystem kernel: System Uptime:0 days 00:17:27
CPUs:4 Machine:x86_64 Node:yoursystem Domain:localdomain
Kernel Release:5.3.0-rc2+ Version: #49 SMP Mon Jul 27 10:35:32 PDT 2019
Signed-off-by: Edward Chron
---
mm/Kconfig.debug| 15 +
mm/oom_kill_debug.c | 81
that the process
was correctly targeted by OOM due to the miconfiguration. This can
be quite helpful for triage and problem determination.
The addition of the pgtables_bytes shows page table usage by the
process and is a useful measure of the memory size of the process.
Signed-off-by: Edward Chron
Acked
output potentially. Think of a workload
> > with too many tasks which is not uncommon.
>
> Probably better to always print all the info for the victim so we don't
> need to duplicate everything between dump_tasks() and dump_oom_summary().
>
> Edward, how about this?
It is worth mention
On Thu, Aug 22, 2019 at 12:09 AM Michal Hocko wrote:
>
> On Wed 21-08-19 15:25:13, Edward Chron wrote:
> > On Tue, Aug 20, 2019 at 8:25 PM David Rientjes wrote:
> > >
> > > On Tue, 20 Aug 2019, Edward Chron wrote:
> > >
> > > > For an OOM
On Thu, Aug 22, 2019 at 12:21 AM Michal Hocko wrote:
>
> On Wed 21-08-19 16:12:08, Edward Chron wrote:
> [...]
> > Additionally (which you know, but mentioning for reference) the OOM
> > output used to look like this:
> >
> > Nov 14 15:23:48 oldserver kernel: [3
On Thu, Aug 22, 2019 at 12:15 AM Michal Hocko wrote:
>
> On Wed 21-08-19 15:22:07, Edward Chron wrote:
> > On Wed, Aug 21, 2019 at 12:19 AM David Rientjes wrote:
> > >
> > > On Wed, 21 Aug 2019, Michal Hocko wrote:
> > >
> > > > > vm.oom_dum
.
My understanding now is that printing the oom_score is discouraged.
This seems unfortunate. The oom_score_adj can be adjusted
appropriately if oom_score is known.
So It would be useful to have both.
But at least if oom_score_adj is printed you can confirm the value at
the time of the OOM
On Tue, Aug 20, 2019 at 8:25 PM David Rientjes wrote:
>
> On Tue, 20 Aug 2019, Edward Chron wrote:
>
> > For an OOM event: print oom_score_adj value for the OOM Killed process to
> > document what the oom score adjust value was at the time the process was
> > OOM Kille
output potentially. Think of a workload
> > with too many tasks which is not uncommon.
>
> Probably better to always print all the info for the victim so we don't
> need to duplicate everything between dump_tasks() and dump_oom_summary().
>
> Edward, how about this?
>
> diff --gi
and if you prefer a fresh submission, let me know and
I'll do that.
Thank-you for reviewing this patch.
-Edward Chron
Arista Networks
On Tue, Aug 20, 2019 at 8:25 PM David Rientjes wrote:
>
> On Tue, 20 Aug 2019, Edward Chron wrote:
>
> > For an OOM event: print oom_score_adj va
targeted by OOM due to the miconfiguration. Having
the oom_score_adj on the Killed message ensures that it is documented.
Signed-off-by: Edward Chron
Acked-by: Michal Hocko
---
mm/oom_kill.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index
On Mon, Aug 12, 2019 at 4:42 AM Michal Hocko wrote:
>
> On Fri 09-08-19 15:15:18, Edward Chron wrote:
> [...]
> > So it is optimal if you only have to go and find the correct log and search
> > or run your script(s) when you absolutely need to, not on every OOM even
output:
Aug 14 23:00:02 testserver kernel: Out of memory: Killed process 2692
(oomprocs) total-vm:1056800kB, anon-rss:1052760kB, file-rss:4kB,i
shmem-rss:0kB oom_score_adj:1000
Signed-off-by: Edward Chron
---
mm/oom_kill.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
Sorry about top posting, responses inline.
On Thu, Aug 8, 2019 at 11:40 PM Michal Hocko wrote:
>
> [Again, please do not top post - it makes a mess of any longer
> discussion]
>
> On Thu 08-08-19 15:15:12, Edward Chron wrote:
> > In our experience far more (99.9%+) OOM
p-post]
>
> On Thu 08-08-19 12:21:30, Edward Chron wrote:
> > It is helpful to the admin that looks at the kill message and records this
> > information. OOMs can come in bunches.
> > Knowing how much resource the oom selected process was using at the time of
> > the OOM event i
1 - 100 of 573 matches
Mail list logo
