The following commit has been merged into the sched/core branch of tip:
Commit-ID: 6db12ee0456d0e369c7b59788d46e15a56ad0294
Gitweb:
https://git.kernel.org/tip/6db12ee0456d0e369c7b59788d46e15a56ad0294
Author:Josh Hunt
AuthorDate:Thu, 01 Apr 2021 22:58:33 -04:00
Committer
On 4/2/21 12:25 PM, Jiri Kosina wrote:
On Thu, 3 Sep 2020, John Fastabend wrote:
At this point I fear we could consider reverting the NOLOCK stuff.
I personally would hate doing so, but it looks like NOLOCK benefits are
outweighed by its issues.
I agree, NOLOCK brings more pains than gains. T
Currently only root can write files under /proc/pressure. Relax this to
allow tasks running as unprivileged users with CAP_SYS_RESOURCE to be
able to write to these files.
Signed-off-by: Josh Hunt
Acked-by: Johannes Weiner
---
kernel/sched/psi.c | 20 ++--
1 file changed, 14
On 4/1/21 10:47 AM, Eric W. Biederman wrote:
Kees Cook writes:
On Wed, Mar 31, 2021 at 11:36:28PM -0500, Eric W. Biederman wrote:
Josh Hunt writes:
Currently only root can write files under /proc/pressure. Relax this to
allow tasks running as unprivileged users with CAP_SYS_RESOURCE to be
Currently only root can write files under /proc/pressure. Relax this to
allow tasks running as unprivileged users with CAP_SYS_RESOURCE to be
able to write to these files.
Signed-off-by: Josh Hunt
---
kernel/sched/psi.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
Hi Jike
On 8/20/20 12:43 AM, Jike Song wrote:
Hi Josh,
We met possibly the same problem when testing nvidia/mellanox's
GPUDirect RDMA product, we found that changing NET_SCH_DEFAULT to
DEFAULT_FQ_CODEL mitigated the problem, having no idea why. Maybe you
can also have a try?
We also did some
On 7/2/20 2:45 AM, Paolo Abeni wrote:
Hi all,
On Thu, 2020-07-02 at 08:14 +0200, Jonas Bonn wrote:
Hi Cong,
On 01/07/2020 21:58, Cong Wang wrote:
On Wed, Jul 1, 2020 at 9:05 AM Cong Wang wrote:
On Tue, Jun 30, 2020 at 2:08 PM Josh Hunt wrote:
Do either of you know if there's bee
On 7/1/20 12:58 PM, Cong Wang wrote:
On Wed, Jul 1, 2020 at 9:05 AM Cong Wang wrote:
On Tue, Jun 30, 2020 at 2:08 PM Josh Hunt wrote:
Do either of you know if there's been any development on a fix for this
issue? If not we can propose something.
If you have a reproducer, I can look
On 6/23/20 6:42 AM, Michael Zhivich wrote:
From: Jonas Bonn
To: Paolo Abeni ,
"net...@vger.kernel.org" ,
LKML ,
"David S . Miller" ,
John Fastabend
Subject: Re: Packet gets stuck in NOLOCK pfifo_fast qdisc
Date: Fri, 11 Oct 2019 02:39:48 +0200
Message-ID: <465a54
On 10/3/19 3:03 AM, Jiri Olsa wrote:
On Thu, Oct 03, 2019 at 12:54:09AM -0700, Josh Hunt wrote:
The following commit is breaking dwarf unwinding on 4.19 kernels:
how?
When doing something like:
perf record -p $(cat /var/run/app.pid) -g --call-graph dwarf -F 999 --
sleep 3
with 4.19.75
The following commit is breaking dwarf unwinding on 4.19 kernels:
commit e5adfc3e7e774ba86f7bb725c6eef5f32df8630e
Author: Konstantin Khlebnikov
Date: Tue Aug 7 12:09:01 2018 +0300
perf map: Synthesize maps only for thread group leader
It looks like this was fixed later by:
commit e8ba29
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 44d3bbb6f5e501b873218142fe08cdf62a4ac1f3
Gitweb:
https://git.kernel.org/tip/44d3bbb6f5e501b873218142fe08cdf62a4ac1f3
Author:Josh Hunt
AuthorDate:Mon, 19 Aug 2019 19:13:31 -04:00
Committer
On Mon, Aug 19, 2019 at 4:16 PM Josh Hunt wrote:
>
> On Mon, Aug 19, 2019 at 2:17 PM Josh Hunt wrote:
> >
> > On Mon, Aug 12, 2019 at 12:42 PM Josh Hunt wrote:
> > >
> > > On Mon, Aug 12, 2019 at 12:34 PM Thomas Gleixner
> > > wrote:
> &g
On Mon, Aug 19, 2019 at 2:17 PM Josh Hunt wrote:
>
> On Mon, Aug 12, 2019 at 12:42 PM Josh Hunt wrote:
> >
> > On Mon, Aug 12, 2019 at 12:34 PM Thomas Gleixner wrote:
> > >
> > > On Mon, 12 Aug 2019, Josh Hunt wrote:
> > > > On Mon, Aug 12,
earing PMU state on CPU#0
I found that a period limit of 32 was the lowest I could set it to without
the problem reoccurring. The idea for the patch and approach to find the
target value were suggested by Ingo and Thomas.
Signed-off-by: Josh Hunt
Reported-by: Bhupesh Purandare
Suggested-by: Thoma
On Mon, Aug 12, 2019 at 12:42 PM Josh Hunt wrote:
>
> On Mon, Aug 12, 2019 at 12:34 PM Thomas Gleixner wrote:
> >
> > On Mon, 12 Aug 2019, Josh Hunt wrote:
> > > On Mon, Aug 12, 2019 at 10:55 AM Thomas Gleixner
> > > wrote:
> > > >
> > &
On Mon, Aug 12, 2019 at 12:34 PM Thomas Gleixner wrote:
>
> On Mon, 12 Aug 2019, Josh Hunt wrote:
> > On Mon, Aug 12, 2019 at 10:55 AM Thomas Gleixner wrote:
> > >
> > > On Mon, 12 Aug 2019, Josh Hunt wrote:
> > > > Was there any progress made on debuggi
On Mon, Aug 12, 2019 at 10:55 AM Thomas Gleixner wrote:
>
> On Mon, 12 Aug 2019, Josh Hunt wrote:
> > Was there any progress made on debugging this issue? We are still
> > seeing it on 4.19.44:
>
> I haven't seen anyone looking at this.
>
> Can you please try
On Mon, Feb 26, 2018 at 12:40 PM Andi Kleen wrote:
>
> > Given the HSD143 errata and its possible relevance, have you tried
> > changing the magic number to 32, does it then still fix things?
> >
> > No real objection to the patch as such, it just needs a coherent comment
> > and a tested-by tag I
On Fri, Jun 21, 2019 at 4:07 PM Pierre-Loup A. Griffais
wrote:
>
>
>
> On 6/21/19 3:38 PM, Eric Dumazet wrote:
> > Please look at my recent patch.
> > Sorry I am travelling
> >
> > On Fri, Jun 21, 2019, 6:19 PM Linus Torvalds
> > mailto:torva...@linux-foundation.org>>
> > wrote:
> >
> >
Hi Thomas
We have a class of machines that appear to be exhausting the vector
space on cpus 0 and 1 which causes some breakage later on when trying to
set the affinity. The boxes are running the 4.14 LTS kernel.
I instrumented 4.14 and here's what I see:
[ 28.328849] __assign_irq_vector: i
On Fri, Nov 2, 2018 at 12:00 PM Greg Kroah-Hartman
wrote:
>
> 4.14-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> Upstream commit bffa72cf7f9d ("net: sk_buff rbnode reorg") got
> backported as commit 6b921536f170 ("net: sk_buff rbnode reorg") int
On 05/07/2018 11:40 AM, Andi Kleen wrote:
On Mon, May 07, 2018 at 02:24:16PM -0400, Josh Hunt wrote:
Add the ability to specify a DSO in the /tmp/perf-.map file.
The DSO should be the first line in the file and readable by the
running user. If a valid DSO is found all other contents of the
file
Nan
Signed-off-by: Josh Hunt
---
We have an application which uses huge pages for its text section, but
still needs the ability to do callchain unwinding with DWARF. We use
the perf-.map file setup to do symbol resolution and that works
great, but callchain unwinding fails.
A few months ago I
On Thu, Nov 16, 2017 at 3:13 PM, wrote:
>
> It's possible, but I didn't want to add a bunch of clutter to the
> commit message. Right now it's somewhat easy to track it back to
> automatic selection because:
>
> 1. I'm signed off on all of them, so I could chime in in the case
> concerns/issues
On Tue, Oct 10, 2017 at 10:31 AM, Julia Lawall wrote:
>
>
> On Tue, 10 Oct 2017, Levin, Alexander (Sasha Levin) wrote:
>
>> (Cc'ed Julia)
>>
>> On Mon, Oct 09, 2017 at 09:33:01AM -0700, Laura Abbott wrote:
>> >On 10/06/2017 08:10 PM, Levin, Alexander (Sasha Levin) wrote:
>> >> We are experimenting
On 01/25/2017 08:37 PM, Masami Hiramatsu wrote:
On Tue, 24 Jan 2017 16:41:28 -0500
Josh Hunt wrote:
Commit e50243bb ("perf probe: Ignore vmlinux Build-id when offline vmlinux
given")
added the ability to ignore vmlinux when an offline vmlinux is passed and no
l, d, or a flag is a
ate:
do_sys_open+91 filename_string=+0(%si):string dfd=%di:s32 flags=%bx:s32
op=-60(%bp):u64
and then copy/paste this to the machine running the 3.14.59 kernel.
Signed-off-by: Josh Hunt
---
tools/perf/builtin-probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-
On Fri, Jul 15, 2016 at 6:54 AM, Sasha Levin wrote:
> On 07/15/2016 07:38 AM, Thomas Voegtle wrote:
>> On Wed, 13 Jul 2016, Sasha Levin wrote:
>>
>>> I'm announcing the release of the 4.1.28 kernel.
>>
>> I have a serious memleak with 4.1.28 (like 20mb/s)
>> I stripped down my kernel config and st
On 03/16/2016 04:21 AM, Ulrich Obergfell wrote:
Josh,
I haven't tried to reproduce the soft lockups with kernel 4.1, but I
believe I found an explanation in terms of how your test case breaks
the watchdog mechanism in kernel 4.1:
The soft lockup detector is implemented via two components (per-
On 03/14/2016 11:29 AM, Don Zickus wrote:
Hi Josh,
I believe Uli thought the below patch might fix it.
Cheers,
Don
Don
It looks like I was incorrect when I said 4.5 was getting the soft
lockup. I originally found this problem on 4.1.19 and saw both the
problem my patch solves and the soft
de a patch I'm happy to test. I can also attempt to debug
that part more if needed.
Josh
Cheers,
Don
Signed-off-by: Josh Hunt
---
kernel/watchdog.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index b3ace6e.
On 03/04/2016 04:47 PM, Bill Sommerfeld wrote:
IPv4 interprets a negative return value from a protocol handler as a
request to redispatch to a new protocol. In contrast, IPv6 interprets a
negative value as an error, and interprets a positive value as a request
for redispatch.
UDP for IPv6 was u
On Tue, Nov 10, 2015 at 1:47 PM, Gratian Crisan wrote:
>
> The observed behavior does seem to match BT81 errata i.e. the TSC does
> not get reset on warm reboots and it is otherwise stable.
>
If you have a simple testcase to reproduce the problem I'd be
interested in seeing it.
--
Josh
--
To uns
On Tue, Nov 10, 2015 at 12:24 PM, Josh Hunt wrote:
>
> On Mon, Nov 9, 2015 at 4:02 PM, Peter Zijlstra wrote:
>>
>> On Mon, Nov 09, 2015 at 01:59:02PM -0600, gratian.cri...@ni.com wrote:
>>
>> > The Intel Xeon E5 processor family suffers from errata[1] BT8
On Wed, Mar 4, 2015 at 12:13 AM, Greg Kroah-Hartman
wrote:
> 3.19-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Calvin Owens
>
> commit 28423ad283d5348793b0c45cc9b1af058e776fd6 upstream.
>
> While debugging an issue with excessive softirq
On 06/24/2014 07:45 PM, David Rientjes wrote:
On Tue, 24 Jun 2014, Josh Hunt wrote:
Anyone you'd suggest adding to this thread to get other feedback about
tracking page allocation failures? I could also spin up a patch and cc them.
Page allocation failures happen all the time, m
On 06/23/2014 05:51 PM, Andrew Morton wrote:
On Mon, 23 Jun 2014 17:45:00 -0500 Josh Hunt wrote:
On 06/23/2014 05:11 PM, Andrew Morton wrote:
On Tue, 3 Jun 2014 22:12:35 -0400 Josh Hunt wrote:
This taint flag will be set if the system has ever entered a softlockup
state. Similar to
On 06/23/2014 05:11 PM, Andrew Morton wrote:
On Tue, 3 Jun 2014 22:12:35 -0400 Josh Hunt wrote:
This taint flag will be set if the system has ever entered a softlockup
state. Similar to TAINT_WARN it is useful to know whether or not the system
has been in a softlockup state when debugging
This taint flag will be set if the system has ever entered a softlockup
state. Similar to TAINT_WARN it is useful to know whether or not the system
has been in a softlockup state when debugging.
Signed-off-by: Josh Hunt
---
Documentation/oops-tracing.txt |2 ++
Documentation/sysctl
On Sun, Feb 16, 2014 at 8:38 PM, Banerjee, Debabrata
wrote:
> On 2/16/14, 7:41 PM, "Linus Torvalds"
> wrote:
>
>>On Sun, Feb 16, 2014 at 4:19 PM, Banerjee, Debabrata
>> wrote:
>>>
>>> No that can't be right, the prev value after every loop is the
>>>msg->flags
>>> from the *last* line in the list
On Tue, Dec 3, 2013 at 9:19 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Dec 03, 2013 at 08:28:43AM -0600, Josh Hunt wrote:
>> You're right. Thanks for pointing this out. I did not realize there
>> was a bug in the init script. The version of initramfs-tools I was
>
On Tue, Nov 26, 2013 at 4:29 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Nov 26, 2013 at 04:12:41PM -0600, Josh Hunt wrote:
>> I should have clarified that I'm not using dm/md in my setup. I know
>> the modules are getting loaded in the log I attached, but root is not
>
On Tue, Nov 26, 2013 at 3:53 PM, Linus Torvalds
wrote:
> On Tue, Nov 26, 2013 at 1:29 PM, Josh Hunt wrote:
>>
>> Both ahci and sata_svw call ata_host_activate(), which call
>> ata_host_register() and async_schedule(async_port_probe, ap).
>
> Well, with the modern
On Mon, Aug 12, 2013 at 10:09 AM, Tejun Heo wrote:
> Hello, Jonathan.
>
> On Mon, Aug 12, 2013 at 12:04:11AM -0700, Jonathan Nieder wrote:
>> My laptop fails to boot[1] with the message 'Volume group "data" not
>> found'. Bisects to v3.8-rc4~17 (the above commit). Reverting that
>> commit on top
On 11/14/2013 01:03 AM, David Miller wrote:
From: Josh Hunt
Date: Wed, 13 Nov 2013 17:15:43 -0800
The rds_ib_xmit function in net/rds/ib_send.c in the Reliable Datagram Sockets
(RDS) protocol implementation allows local users to cause a denial of service
(BUG_ON and kernel panic) by
On Wed, Nov 13, 2013 at 6:55 PM, Honggang LI wrote:
> On 11/14/2013 01:40 AM, Josh Hunt wrote:
>> On Wed, Nov 13, 2013 at 9:16 AM, Venkat Venkatsubra
>> wrote:
>>>
>>> -Original Message-
>>> From: Josh Hunt [mailto:joshhun...@gmail.com]
>
s, as demonstrated by
rds-ping.
A local unprivileged user could use this flaw to crash the system.
CVE-2012-2372
Reported-by: Honggang Li
Signed-off-by: Josh Hunt
---
net/rds/ib_send.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
On Wed, Nov 13, 2013 at 9:16 AM, Venkat Venkatsubra
wrote:
>
>
> -Original Message-
> From: Josh Hunt [mailto:joshhun...@gmail.com]
> Sent: Tuesday, November 12, 2013 10:25 PM
> To: David Miller
> Cc: jjo...@suse.com; LKML; Venkat Venkatsubra; net...@vger.kernel.org
On Tue, Nov 12, 2013 at 10:22 PM, Josh Hunt wrote:
> On Sat, Sep 22, 2012 at 2:25 PM, David Miller wrote:
>>
>> From: John Jolly
>> Date: Fri, 21 Sep 2012 15:32:40 -0600
>>
>> > Attempting an rds connection from the IP address of an IPoIB interface
>>
On 12/03/2012 06:06 PM, Andrew Morton wrote:
On Mon, 19 Nov 2012 18:56:49 -0800
Josh Hunt wrote:
We found with newer kernels we started seeing the cdrom device showing
up in /proc/partitions, but it was not there before. Looking into this I found
that commit d27769ec... block: add
ping?
On 11/19/2012 08:56 PM, Josh Hunt wrote:
We found with newer kernels we started seeing the cdrom device showing
up in /proc/partitions, but it was not there before. Looking into this I found
that commit d27769ec... block: add GENHD_FL_NO_PART_SCAN introduces this change
in behavior. It&#
7769ec... block: add GENHD_FL_NO_PART_SCAN, /proc/partitions
started printing removable devices with only one partition. This is different
than prior to the commit. This restores /proc/partitions to behave as it did
before.
Signed-off-by: Josh Hunt
---
block/genhd.c |2 +-
1 files changed, 1 insert
On 09/14/2012 07:55 AM, Josh Hunt wrote:
Thanks to your help I was able to test your branch, but it still does
not resolve the problem. Removal of the "factor=1" workaround fixes the
memory size reporting on boot, but the sysfs values are still incorrect.
Please disregard what I sa
On 09/12/2012 12:23 PM, Borislav Petkov wrote:
Ok, I have something preliminary which seems to work fine on my K8 here.
If you'd like, you can give it a run:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git error-queue
I've changed also debug messages, etc, so pls take a look at those an
On 09/12/2012 11:48 AM, Borislav Petkov wrote:
Can I have /proc/cpuinfo and full dmesg with EDAC_DEBUG enabled from
that machine please?
Actually my apologies. I was looking at the 3.0 code. This issue is
fixed in the latest kernel.
Sorry for the noise on that.
Josh
--
To unsubscribe from t
On 09/12/2012 10:49 AM, Borislav Petkov wrote:
Yes, that's because the whole init_csrows thing has been b0rked since
forever. In your case, amd64_csrow_nr_pages() should pay attention to
the dct (second argument) which on K8 is always 0 (we have only one DCT
aka Dram ConTroller on K8) and the fu
On 09/12/2012 10:30 AM, Borislav Petkov wrote:
Yes, you're basically right. Here's what I see from here:
In 2009 I added
commit 603adaf6b3e37450235f0ddb5986b961b3146a79
Author: Borislav Petkov
Date: Mon Dec 21 14:52:53 2009 +0100
amd64_edac: fix K8 chip select reporting
Fix the c
On 09/12/2012 07:38 AM, Josh Hunt wrote:
> On 09/12/2012 03:51 AM, Borislav Petkov wrote:
>> On Tue, Sep 11, 2012 at 06:02:01PM -0500, Josh Hunt wrote:
>>> On 09/11/2012 05:52 PM, Josh Hunt wrote:
>>>> With recent kernels we noticed that edac was reporting d
On 09/12/2012 03:51 AM, Borislav Petkov wrote:
> On Tue, Sep 11, 2012 at 06:02:01PM -0500, Josh Hunt wrote:
>> On 09/11/2012 05:52 PM, Josh Hunt wrote:
>>> With recent kernels we noticed that edac was reporting double the memory
>>> size on
>>> systems running
[fixing lkml address]
On 09/11/2012 05:52 PM, Josh Hunt wrote:
With recent kernels we noticed that edac was reporting double the memory size on
systems running with AMD family 0Fh processors. I'm not very familiar with the
code, but this resolves it from what I can see on my systems. At
61 matches
Mail list logo
