On Wednesday 03/27 at 00:24 +0900, Masami Hiramatsu wrote:
> On Tue, 26 Mar 2024 14:46:10 +
> Mark Rutland wrote:
>
> > Hi Masami,
> >
> > On Mon, Mar 25, 2024 at 11:56:32AM +0900, Masami Hiramatsu wrote:
> > > Hi Jarkko,
> > >
> > > On Sun, 24 Mar 2024 01:29:08 +0200
> > > Jarkko Sakkinen
On Monday 03/25 at 11:56 +0900, Masami Hiramatsu wrote:
> Hi Jarkko,
>
> On Sun, 24 Mar 2024 01:29:08 +0200
> Jarkko Sakkinen wrote:
>
> > Tracing with kprobes while running a monolithic kernel is currently
> > impossible due the kernel module allocator dependency.
> >
> > Address the issue by
On Thursday 03/07 at 22:09 +, Christophe Leroy wrote:
>
>
> Le 06/03/2024 à 21:05, Calvin Owens a écrit :
> > [Vous ne recevez pas souvent de courriers de jcalvinow...@gmail.com.
> > Découvrez pourquoi ceci est important à
> > https://aka.ms/LearnAboutSenderIdent
On Thursday 03/07 at 22:16 +, Christophe Leroy wrote:
>
>
> Le 06/03/2024 à 21:05, Calvin Owens a écrit :
> > [Vous ne recevez pas souvent de courriers de jcalvinow...@gmail.com.
> > Découvrez pourquoi ceci est important à
> > https://aka.ms/LearnAboutSenderI
On Friday 03/08 at 11:46 +0900, Masami Hiramatsu wrote:
> On Wed, 6 Mar 2024 12:05:10 -0800
> Calvin Owens wrote:
>
> > If something like this is merged down the road, it can go in at leisure
> > once the module_alloc change is in: it's a one-way dependency.
> >
On Thursday 03/07 at 14:43 +, Christophe Leroy wrote:
> Hi Calvin,
>
> Le 06/03/2024 à 21:05, Calvin Owens a écrit :
> > [Vous ne recevez pas souvent de courriers de jcalvinow...@gmail.com.
> > Découvrez pourquoi ceci est important à
> > https://aka.ms/Lea
On Friday 03/08 at 11:16 +0900, Masami Hiramatsu wrote:
> Hi Calvin,
>
> On Wed, 6 Mar 2024 12:05:08 -0800
> Calvin Owens wrote:
>
> > Both BPF_JIT and KPROBES depend on CONFIG_MODULES, but only require
> > module_alloc() itself, which can be easily separated into
On Thursday 03/07 at 09:22 +0200, Mike Rapoport wrote:
> On Wed, Mar 06, 2024 at 12:05:10PM -0800, Calvin Owens wrote:
> > If something like this is merged down the road, it can go in at leisure
> > once the module_alloc change is in: it's a one-way dependency.
> >
>
! :)
> > >
> > > On Wed, Mar 6, 2024 at 3:23 PM Calvin Owens
> > > wrote:
> > > >
> > > > On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote:
> > > > > On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote:
> > &
On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote:
> On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote:
> > Hello all,
> >
> > This patchset makes it possible to use bpftrace with kprobes on kernels
> > built without loadable module support.
>
able to suggest a less ugly way I
can do this...
Signed-off-by: Calvin Owens
---
include/trace/events/bpf_testmod.h| 1 +
kernel/bpf/Kconfig| 9 ++
kernel/bpf/Makefile | 2 ++
kernel/bpf/bpf_testmod/Makefile
If something like this is merged down the road, it can go in at leisure
once the module_alloc change is in: it's a one-way dependency.
Signed-off-by: Calvin Owens
---
arch/Kconfig| 2 +-
kernel/kprobes.c| 22 ++
kernel/trace/trace_kprobe.c
://lore.kernel.org/all/20220716230953.442937...@linutronix.de/
I've simply extended that approach to the whole kernel.
Signed-off-by: Calvin Owens
---
arch/Kconfig | 2 +-
arch/arm/kernel/module.c | 35 -
arch/arm/mm/Makefile | 2 +
arch/a
once the module_alloc change is in: it's a one-way
dependency.
Signed-off-by: Calvin Owens
---
kernel/bpf/Kconfig | 2 +-
kernel/bpf/bpf_struct_ops.c | 28
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/kernel/bpf/Kconfig b/kerne
n future submissions of
the first patch. Of course, feedback on the arch bits is welcome here.
In addition to feedback on the patches themselves, I'm interested in
hearing from anybody else who might find this functionality useful.
Thanks,
Calvin
Calvin Owens (4):
module: mm: Make modul
On Monday 03/11 at 14:33 +0100, Petr Mladek wrote:
> On Fri 2019-03-01 16:48:19, Calvin Owens wrote:
> > This patch embeds a device struct in the console struct, and registers
> > them on a "console" bus so we can expose attributes in sysfs.
> >
> > Currently
On Friday 03/08 at 12:10 +0900, Sergey Senozhatsky wrote:
> On (03/01/19 16:48), Calvin Owens wrote:
> [..]
> > msg = log_from_idx(console_idx);
> > - if (suppress_message_printing(msg->level)) {
> > - /*
> > -
On Friday 03/08 at 16:53 +0100, Petr Mladek wrote:
> On Fri 2019-03-01 16:48:19, Calvin Owens wrote:
> > This patch embeds a device struct in the console struct, and registers
> > them on a "console" bus so we can expose attributes in sysfs.
> >
> > Early co
On Friday 03/08 at 17:34 +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 08, 2019 at 04:58:14PM +0100, Petr Mladek wrote:
> > On Fri 2019-03-08 03:56:19, John Ogness wrote:
> > > On 2019-03-02, Calvin Owens wrote:
> > > > This patch embeds a device struct in the
On Tuesday 03/12 at 13:04 -0400, Mimi Zohar wrote:
> On Mon, 2019-03-11 at 16:54 -0700, Calvin Owens wrote:
> > We're having lots of problems with TPM commands timing out, and we're
> > seeing these problems across lots of different hardware (both v1/v2).
> >
&
Mon, 2019-03-11 at 16:54 -0700, Calvin Owens wrote:
> > > > > e're having lots of problems with TPM commands timing out, and
> > > > > we're seeing these problems across lots of different hardware
> > > > > (both v1/v2).
> > > > &g
On Monday 03/11 at 17:27 -0700, James Bottomley wrote:
> On Mon, 2019-03-11 at 16:54 -0700, Calvin Owens wrote:
> > e're having lots of problems with TPM commands timing out, and we're
> > seeing these problems across lots of different hardware (both v1/v2).
> >
&
ggressive. So I tried replacing all the timeout logic with a single
universal long timeout, and found that makes our TPMs 100% reliable.
Given that this timeout logic is very complex, problematic, and appears
to serve no real purpose, I propose simply deleting all of it.
Signed-off-by: Calvin Owen
On Monday 03/04 at 17:06 +0900, Sergey Senozhatsky wrote:
> On (03/01/19 16:48), Calvin Owens wrote:
> > +static struct attribute *console_sysfs_attrs[] = {
> > + &dev_attr_loglevel.attr,
> > + NULL,
> > +};
> > +ATTRIBUTE_GROUPS(console_sysfs);
> > +
This extends the "console=" interface to allow setting the per-console
loglevel by adding "/N" to the string, where N is the desired loglevel
expressed as a base 10 integer. Invalid values are silently ignored.
Signed-off-by: Calvin Owens
---
.../admin-guide/kernel-paramet
ing a conservative system
loglevel setting to avoid disturbing applications.
Signed-off-by: Calvin Owens
---
include/linux/console.h | 1 +
kernel/printk/printk.c | 36 +++-
2 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/include/linux/console.h
Signed-off-by: Calvin Owens
---
kernel/printk/printk.c | 40
1 file changed, 40 insertions(+)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 67e1e993ab80..e7e602fa2d0b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
ributes in sysfs.
I left the very long list of driver maintainers off this first submission,
once there's agreement on the core idea here I'll add them.
Thanks,
Calvin
Calvin Owens (4):
printk: Introduce per-console loglevel setting
printk: Add ability to set loglevel via "c
increment rx_pkts on -ENOMEM and -EIO, resulting
in rx_pkts > 0. Fix this by only bumping rx_pkts if we were actually
given a non-zero budget.
Signed-off-by: Calvin Owens
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net
On 11/03/2017 07:32 AM, Kroah-Hartman wrote:
On Fri, Nov 03, 2017 at 03:21:14PM +0100, Petr Mladek wrote:
On Thu 2017-09-28 17:43:56, Calvin Owens wrote:
This adds a new sysfs interface that contains a directory for each
console registered on the system. Each directory contains a single
On 10/20/2017 01:05 AM, Petr Mladek wrote:
On Thu 2017-10-19 16:40:45, Calvin Owens wrote:
On 09/28/2017 05:43 PM, Calvin Owens wrote:
Not all consoles are created equal: depending on the actual hardware,
the latency of a printk() call can vary dramatically. The worst examples
are serial
On 09/28/2017 05:43 PM, Calvin Owens wrote:
Not all consoles are created equal: depending on the actual hardware,
the latency of a printk() call can vary dramatically. The worst examples
are serial consoles, where it can spin for tens of milliseconds banging
the UART to emit a message, which can
ing a conservative system
loglevel setting to avoid disturbing applications.
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: Sergey Senozhatsky
Signed-off-by: Calvin Owens
---
(V1: https://lkml.org/lkml/2017/4/4/783)
Changes in V2:
* Honor the ignore_loglevel setting in all cases
* Ch
This extends the "console=" interface to allow setting the per-console
loglevel by adding "/N" to the string, where N is the desired loglevel
expressed as a base 10 integer. Invalid values are silently ignored.
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: Sergey Senozhatsky
S
show,store}() will safely fail with -ENODEV. This is a little
weird, but avoids embedding the kobject and therefore needing to totally
refactor the way we handle console struct lifetime.
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: Sergey Senozhatsky
Signed-off-by: Calvin Owens
---
(V1: https://lkml.org/lkm
On Thursday 04/06 at 16:02 +0200, Petr Mladek wrote:
> On Wed 2017-04-05 17:38:19, Calvin Owens wrote:
> > On Wednesday 04/05 at 17:22 +0200, Petr Mladek wrote:
> > > I think about a reasonable behavior. There seems to be three variables
> > > that
On Wednesday 04/05 at 17:22 +0200, Petr Mladek wrote:
> On Wed 2017-04-05 11:16:28, Sergey Senozhatsky wrote:
> > On (04/05/17 11:08), Sergey Senozhatsky wrote:
> > [..]
> > > > stop_critical_timings();/* don't trace print
> > > > latency */
> > > > - call_con
On Tuesday 04/04 at 23:30 -0400, Steven Rostedt wrote:
> On Tue, 4 Apr 2017 16:03:20 -0700
> Calvin Owens wrote:
>
> > This does the simplest possible thing: add a directory at the root of
> > sysfs that allows setting the "maxlevel" parameter for each conso
On Tuesday 04/04 at 23:27 -0400, Steven Rostedt wrote:
> On Wed, 5 Apr 2017 11:16:28 +0900
> Sergey Senozhatsky wrote:
>
>
> > one more thing.
> >
> > this per-console filtering ignores... the "ignore_loglevel" param.
> >
> > early_param("ignore_loglevel", ignore_loglevel_setup);
> > module_pa
soles verbosity based on the speed of the slowest one,
we can limit each based on its own speed. A subsequent patch will
introduce a simple sysfs interface for changing this setting.
Signed-off-by: Calvin Owens
---
include/linux/console.h | 1 +
kernel/printk/printk.c | 13 ++---
2 fi
weird, but avoids embedding the kobject and therefore needing to totally
refactor the way we handle console struct lifetime.
Signed-off-by: Calvin Owens
---
include/linux/console.h | 1 +
kernel/printk/printk.c | 82 +
2 files changed, 83 insertion
this by reintroducing the checks xfs_zero_remaining_bytes() did
against i_size at the bottom of xfs_free_file_space().
Reported-by: Aaron Gao
Fixes: 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes")
Cc: Christoph Hellwig
Cc: Brian Foster
Cc: # 4.8+
Signed-off-by: Calvin Owen
On 03/21/2017 04:39 AM, Brian Foster wrote:
On Sun, Mar 19, 2017 at 09:54:51PM -0700, Calvin Owens wrote:
When punching past EOF on XFS, fallocate(mode=PUNCH_HOLE|KEEP_SIZE) will
round the file size up to the nearest multiple of PAGE_SIZE:
calvinow@vm-disks/generic-xfs-1 ~$ dd if=/dev
this by reintroducing the checks xfs_zero_remaining_bytes() did
against i_size at the bottom of xfs_free_file_space().
Reported-by: Aaron Gao
Fixes: 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes")
Cc: Christoph Hellwig
Cc: # 4.8+
Signed-off-by: Calvin Owens
---
fs/xfs/xfs_b
nge().
Reported-by: Aaron Gao
Fixes: 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes")
Cc: Christoph Hellwig
Cc: # 4.8+
Signed-off-by: Calvin Owens
---
fs/xfs/xfs_file.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index
> Fix this by reintroducing the checks xfs_zero_remaining_bytes() did
> against i_size into xfs_zero_range().
Sorry this is wrong: I missed that xfs_zero_range() has another caller that
depends on the behavior I'm changing. I'll send a v2 with the same hunk at
the bottom of xfs_free_file_space() i
On Friday 10/07 at 17:18 -0400, Calvin Owens wrote:
> On Friday 10/07 at 21:48 +0100, Al Viro wrote:
> > On Fri, Oct 07, 2016 at 01:35:52PM -0700, Calvin Owens wrote:
> > > Omitting the owner field in file_operations declared in modules is an
> > > easy mistake to make
On Friday 10/07 at 21:48 +0100, Al Viro wrote:
> On Fri, Oct 07, 2016 at 01:35:52PM -0700, Calvin Owens wrote:
> > Omitting the owner field in file_operations declared in modules is an
> > easy mistake to make, and can result in crashes when the module is
> > unloaded while us
Since the code explicilty falls back to a smaller allocation when the
large one fails, we shouldn't complain when that happens.
Signed-off-by: Calvin Owens
---
net/netfilter/nfnetlink_log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nfnetlink_log.c
reference on the containing module.
Signed-off-by: Calvin Owens
---
include/linux/fs.h | 13 -
kernel/module.c| 1 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 901e25d..fafda9e 100644
--- a/include/linux/fs.h
+++ b
This implements ndo_poll_controller in net_device_ops callbacks for mlx5,
which is necessary to use netconsole with this driver.
Acked-By: Saeed Mahameed
Signed-off-by: Calvin Owens
---
Changes in v2:
* Only iterate channels to avoid redundant napi_schedule() calls
drivers/net/ethernet
This implements ndo_poll_controller in net_device_ops callback for mlx5,
which is necessary to use netconsole with this driver.
Cc: Saeed Mahameed
Signed-off-by: Calvin Owens
---
Changes in v2:
* Only iterate channels to avoid redundant napi_schedule() calls
drivers/net/ethernet
This implements ndo_poll_controller in net_device_ops for mlx5, which is
necessary to use netconsole with this driver.
Signed-off-by: Calvin Owens
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/net/ethernet
With the exception of a single call to wait_for_doorbell_int(), all
this conditional sleeping code is dead. So delete it.
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 241 +--
drivers/scsi/mpt3sas/mpt3sas_base.h | 6 +-
drivers
This flag that conditionally acquires the mutex is confusing and prone
to bugginess: refactor it into two separate function calls, and make
the unlocked one complain if it's called outside the mutex.
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 16 +++--
dr
l with the potential error is non-trivial, so for now just WARN().
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 18 +++-
drivers/scsi/mpt3sas/mpt3sas_config.c| 4 +-
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 29 ++---
drivers/scsi/mpt3sas/mpt3s
e 2nd byte beyond our character array happens to be a NUL. Fix this
by explicitly writing '\0' to the end of the string to ensure we don't
run off the edge of the world in printk().
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +-
drivers/scsi/mpt3sas/
On 06/15/2016 01:24 PM, Calvin Owens wrote:
On Thursday 06/02 at 15:50 -0700, Calvin Owens wrote:
On 05/13/2016 01:28 PM, Calvin Owens wrote:
Currently we free the resources backing the enclosure device before we
call device_unregister(). This is racy: during rmmod of low-level SCSI
drivers
On 07/18/2016 07:05 PM, Calvin Owens wrote:
On 07/17/2016 11:02 PM, Dave Chinner wrote:
On Sun, Jul 17, 2016 at 10:00:03AM +1000, Dave Chinner wrote:
On Fri, Jul 15, 2016 at 05:18:02PM -0700, Calvin Owens wrote:
Hello all,
I've found a nasty source of slab corruption. Based on seeing si
On 07/17/2016 11:02 PM, Dave Chinner wrote:
On Sun, Jul 17, 2016 at 10:00:03AM +1000, Dave Chinner wrote:
On Fri, Jul 15, 2016 at 05:18:02PM -0700, Calvin Owens wrote:
Hello all,
I've found a nasty source of slab corruption. Based on seeing similar symptoms
on boxes at Facebook, I su
Hello all,
I've found a nasty source of slab corruption. Based on seeing similar symptoms
on boxes at Facebook, I suspect it's been around since at least 3.10.
It only reproduces under memory pressure so far as I can tell: the issue seems
to be that XFS reclaims pages from buffers that are still
On Friday 06/17 at 09:38 -0400, Benjamin Coddington wrote:
> On 16 Jun 2016, at 13:52, Calvin Owens wrote:
>
> > On Tuesday 03/08 at 11:37 +0100, Dmitry Vyukov wrote:
> > > On Tue, Mar 8, 2016 at 11:27 AM, Benjamin Coddington
> > > wrote:
> >
On Thursday 06/02 at 15:50 -0700, Calvin Owens wrote:
> On 05/13/2016 01:28 PM, Calvin Owens wrote:
> > Currently we free the resources backing the enclosure device before we
> > call device_unregister(). This is racy: during rmmod of low-level SCSI
> > drivers that hook into
On 05/13/2016 01:28 PM, Calvin Owens wrote:
Currently we free the resources backing the enclosure device before we
call device_unregister(). This is racy: during rmmod of low-level SCSI
drivers that hook into enclosure, we end up with a small window of time
during which writing to /sys can OOPS
On Wednesday 05/18 at 18:44 +0530, Sreekanth Reddy wrote:
> On Tue, May 17, 2016 at 8:43 AM, Calvin Owens wrote:
> > On Monday 05/16 at 15:51 -0600, Sathya Prakash Veerichetty wrote:
> >> Our understanding is the relationship between the SCSI host and SAS end
> >> de
e only driver besides mpt*sas that calls sas_delete_port() explicitly is
HPSA, and it does it in the opposite order mpt3sas does: scsi_remove_host()
first.
Thanks,
Calvin
> -Original Message-
> From: Calvin Owens [mailto:calvinow...@fb.com]
> Sent: Monday, May 16, 2016 2:25 PM
> To:
On Sunday 05/15 at 15:36 +0900, Sergey Senozhatsky wrote:
> Hello,
>
> On (05/13/16 13:58), Calvin Owens wrote:
> [..]
> > +#if defined(CONFIG_PRINTK_APPEND_UNAME)
> > +static ssize_t msg_print_ext_uname(char *buf, size_t size)
> > +{
> > + retu
On Sunday 05/15 at 00:19 +0200, Richard Weinberger wrote:
> On Fri, May 13, 2016 at 10:58 PM, Calvin Owens wrote:
> > We use netconsole to collect kernel logs from all the servers at
> > Facebook. We use this patch internally so each logline has a record of
> > which kern
On Friday 05/13 at 21:17 +, Elliott, Robert (Persistent Memory) wrote:
>
>
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Calvin Owens
> > Sent: Friday, May 13, 2016 3:2
that we always know exactly what version emitted a given message.
Doing it in printk() itself rather than extended netconsole ends up
being much simpler, and has the advantage that future extended console
implementations will be able to benefit from this as well.
Signed-off-by: Calvin Owens
mple: just call scsi_remove_host() before we call
sas_port_delete() and/or sas_remove_host().
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/sc
driver
core holds a reference over ->remove_dev(), so AFAICT this is safe.
Signed-off-by: Calvin Owens
---
drivers/scsi/ses.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index 53ef1cb..0e8601a 100644
--- a/drivers/scsi/ses.c
+++
pt3sas]
[] do_one_initcall+0x113/0x2b0
[] do_init_module+0x1d0/0x4d8
[] load_module+0x6729/0x8dc0
[] SYSC_init_module+0x183/0x1a0
[] SyS_init_module+0xe/0x10
[] entry_SYSCALL_64_fastpath+0x12/0x6a
Fix this by pulling the value at the beginning of the loop.
Signed-off-by:
On Friday 02/19 at 07:14 -0600, Corey Minyard wrote:
> On 02/19/2016 12:41 AM, Calvin Owens wrote:
> >Hello,
> >
> >I've got a few boxes that are leaking memory in handle_new_recv_msgs()
> >in ipmi_msghandler. AFAICS this is intentional, there's even an expli
any
discussion about it on LKML when the patch was accepted. Can you clarify
why something like the below patch won't work? I tried it on one of my
leaky boxes and nothing obviously horrible happened.
Thanks,
Calvin
8<
From: Calvin Owens
Subject: [PATCH] ipmi_msghandler: Don
On Thursday 12/17 at 17:46 -0800, Calvin Owens wrote:
> On Thursday 12/17 at 17:08 -0800, Eric Dumazet wrote:
> > On Thu, 2015-12-17 at 15:52 -0800, Calvin Owens wrote:
> > > With built-in netconsole and IXGBE, configuring netconsole via the kernel
> > > cmdline result
On Thursday 12/17 at 17:08 -0800, Eric Dumazet wrote:
> On Thu, 2015-12-17 at 15:52 -0800, Calvin Owens wrote:
> > With built-in netconsole and IXGBE, configuring netconsole via the kernel
> > cmdline results in the following panic at boot:
> >
> > netpoll: netcons
On Thursday 12/17 at 17:10 -0800, Stephen Hemminger wrote:
> On Thu, 17 Dec 2015 15:52:39 -0800
> Calvin Owens wrote:
>
> > With built-in netconsole and IXGBE, configuring netconsole via the kernel
> > cmdline results in the following panic at boot:
> >
> >
+0x3f/0x70
[] ? rest_init+0x80/0x80
This happens because IXGBE assumes that vxlan has already been initialized.
The cleanest way to fix this is to just initialize netconsole after all the
other core networking stuff has completed.
Signed-off-by: Calvin Owens
---
drivers/net/Makefile | 2 +-
1
t;cmd if it isn't
embedded in the object itself.
KASAN was extremely helpful in finding the root cause of this bug.
Signed-off-by: Calvin Owens
---
drivers/scsi/sg.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 9d7b7db
a safe way.
>
> This patch is a port of Calvin's PATCH-v4 for mpt2sas code.
>
> Cc: Calvin Owens
> Cc: Christoph Hellwig
> Cc: Sreekanth Reddy
> Cc: MPT-FusionLinux.pdl
> Signed-off-by: Nicholas Bellinger
> ---
> drivers/scsi/mpt3sas/mpt3s
eanup_queue() such that it
> no longer iterates over the list without holding the lock, since
> _firmware_event_work() concurrently deletes items from the list.
>
> This patch is a port of Calvin's PATCH-v4 for mpt2sas code.
>
> Cc: Calvin Owens
> Cc: Christoph Hellwig
>
On Wednesday 08/26 at 04:09 +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> Hi James & Co,
>
> This series is a mpt3sas forward port of Calvin Owens' in-flight
> reference counting bugfixes for mpt2sas LLD code here:
>
> [PATCH v4 0/2] Fixes
k, or we risk corrupting random memory if items are
added or deleted as we iterate. This patch refactors _scsih_probe_sas()
to use the sas_device_list in a safe way.
Cc: Christoph Hellwig
Cc: Bart Van Assche
Cc: Joe Lawrence
Signed-off-by: Calvin Owens
---
Changes in v4:
* Fix lack o
() concurrently deletes items from the list.
Cc: Christoph Hellwig
Signed-off-by: Calvin Owens
---
Changes in v4: None
Changes in v3:
* Add a break condition to the REMOVE_UNRESPONDING_DEVICES fw_event,
which can loop over a sleep forever (5m+ at least) at unloading. I
don't
Hello all,
This patchset attempts to address problems we've been having with
panics due to memory corruption from the mpt2sas driver.
Thanks,
Calvin
[PATCH v4 1/2] mpt2sas: Refcount sas_device objects and fix unsafe list
[PATCH v4 2/2] mpt2sas: Refcount fw_events and fix unsafe list usage
Tota
On Monday 08/10 at 18:45 +0530, Sreekanth Reddy wrote:
> On Sat, Aug 1, 2015 at 10:32 AM, Calvin Owens wrote:
Sreekanth,
Thanks for the review, responses below. I'll have a v4 out shortly.
Calvin
> > These objects can be referenced concurrently throughout the driver, we
> >
: limit tcp/udp rmem/wmem to SOCK_MIN...")
Cc: Eric Dumazet
Cc: Sorin Dumitru
Signed-off-by: Calvin Owens
---
net/ipv4/sysctl_net_ipv4.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 433231c..0330a
On Wednesday 08/12 at 10:46 -0700, Eric Dumazet wrote:
> On Wed, 2015-08-12 at 20:00 +0300, Sorin Dumitru wrote:
>
> > Would clamping the values to a min value, like setsockopt(SO_SNDBUF)
> > does, be an option?
> > I still find it odd that SO_SNDBUF limits you, while the /proc
> > interface doesn
ng to avoid, and it does so without breaking
anybody's sysctl configurations.
Fixes: 8133534c760d4083 ("net: limit tcp/udp rmem/wmem to SOCK_MIN...")
Signed-off-by: Calvin Owens
---
net/ipv4/sysctl_net_ipv4.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
On Sunday 08/09 at 22:41 -0700, David Miller wrote:
> From: Calvin Owens
> Date: Wed, 5 Aug 2015 13:26:54 -0700
>
> > Commit 8133534c760d4083 ("net: limit tcp/udp rmem/wmem to
> > SOCK_{RCV,SND}BUF_MIN") modified four sysctls to enforce that the values
> &
uot;net: limit tcp/udp rmem/wmem to SOCK_MIN...")
Signed-off-by: Calvin Owens
---
net/ipv4/sysctl_net_ipv4.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 433231c..a214b6a 100644
--- a/net/ipv4/sysctl_net
k, or we risk corrupting random memory if items are
added or deleted as we iterate. This patch refactors _scsih_probe_sas()
to use the sas_device_list in a safe way.
Cc: Christoph Hellwig
Cc: Bart Van Assche
Cc: Joe Lawrence
Signed-off-by: Calvin Owens
---
Changes in v3:
* Dro
() concurrently deletes items from the list.
Cc: Christoph Hellwig
Signed-off-by: Calvin Owens
---
Changes in v3:
* Add a break condition to the REMOVE_UNRESPONDING_DEVICES fw_event,
which can loop over a sleep forever (5m+ at least) at unloading. I
don't think anything prev
Hello all,
This patchset attempts to address problems we've been having with
panics due to memory corruption from the mpt2sas driver.
Changes are noted in the individual patches, I realized putting them in the
cover was probably a bit confusing.
Thanks,
Calvin
Patches in this series:
[PATCH v
On Sunday 07/12 at 23:52 -0700, Christoph Hellwig wrote:
> On Sat, Jul 11, 2015 at 09:24:55PM -0700, Calvin Owens wrote:
> > These objects can be referenced concurrently throughout the driver, we
> > need a way to make sure threads can't delete them out from under each
> &
On Monday 07/13 at 11:05 -0400, Joe Lawrence wrote:
> On 07/12/2015 12:24 AM, Calvin Owens wrote:
> > These objects can be referenced concurrently throughout the driver, we
> > need a way to make sure threads can't delete them out from under each
> > other. This pa
On Thursday 07/16 at 20:27 +0530, Sreekanth Reddy wrote:
> On Sun, Jul 12, 2015 at 9:54 AM, Calvin Owens wrote:
> > These objects can be referenced concurrently throughout the driver, we
> > need a way to make sure threads can't delete them out from under each
> >
On Wednesday 07/15 at 15:21 -0700, Andrew Morton wrote:
> On Thu, 18 Jun 2015 19:32:18 -0700 Calvin Owens wrote:
>
> > Currently, /proc//map_files/ is restricted to CAP_SYS_ADMIN, and
> > is only exposed if CONFIG_CHECKPOINT_RESTORE is set.
> >
> > Each mapped
() concurrently deletes items from the list.
Cc: Christoph Hellwig
Cc: Bart Van Assche
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 101 ---
1 file changed, 81 insertions(+), 20 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b
1 - 100 of 178 matches
Mail list logo
