Re: [PATCH 0/3] fs: minor fs thaw fixes and adjustments

On Fri, Apr 20, 2018 at 04:59:01PM -0700, Luis R. Rodriguez wrote: > Here's a few minor fs thaw fixes and adjustments I ran accross > as I started to refresh my development for to use freeze_fs on > suspend/hibernation [0]. These are just prep commits for the real > work, I'm sti

Re: [PATCH 0/3] fs: minor fs thaw fixes and adjustments

On Fri, Apr 20, 2018 at 04:59:01PM -0700, Luis R. Rodriguez wrote: > Here's a few minor fs thaw fixes and adjustments I ran accross > as I started to refresh my development for to use freeze_fs on > suspend/hibernation [0]. These are just prep commits for the real > work, I'm sti

[PATCH 3/3] fs: fix corner case race on freeze_bdev() when sb disappears

generic freeze feature") Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- fs/block_dev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index b54966679833..7a532aa58c07 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @

[PATCH 3/3] fs: fix corner case race on freeze_bdev() when sb disappears

generic freeze feature") Signed-off-by: Luis R. Rodriguez --- fs/block_dev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index b54966679833..7a532aa58c07 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -507,8 +507,10 @@ struct supe

[PATCH 1/3] fs: move documentation for thaw_super() where appropriate

On commit 08fdc8a0138a ("buffer.c: call thaw_super during emergency thaw") Mateusz added thaw_super_locked() and made thaw_super() use it, but forgot to move the documentation. Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- fs/super.c | 12 ++-- 1 file chang

[PATCH 2/3] fs: make thaw_super_locked() really just a helper

r handling. This commit introeuces no functional changes. Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- fs/super.c | 27 --- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/fs/super.c b/fs/super.c index 9d0eb5e20a1f..82bc74a16f06 100644 --- a/fs/

[PATCH 1/3] fs: move documentation for thaw_super() where appropriate

On commit 08fdc8a0138a ("buffer.c: call thaw_super during emergency thaw") Mateusz added thaw_super_locked() and made thaw_super() use it, but forgot to move the documentation. Signed-off-by: Luis R. Rodriguez --- fs/super.c | 12 ++-- 1 file changed, 6 insertions(+), 6

[PATCH 2/3] fs: make thaw_super_locked() really just a helper

r handling. This commit introeuces no functional changes. Signed-off-by: Luis R. Rodriguez --- fs/super.c | 27 --- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/fs/super.c b/fs/super.c index 9d0eb5e20a1f..82bc74a16f06 100644 --- a/fs/super.c +++ b/fs/super.c

[PATCH 0/3] fs: minor fs thaw fixes and adjustments

/085 on xfs and found no regressions. Luis R. Rodriguez (3): fs: move documentation for thaw_super() where appropriate fs: make thaw_super_locked() really just a helper fs: fix corner case race on freeze_bdev() when sb disappears fs/block_dev.c | 4 +++- fs/super.c | 39

[PATCH 0/3] fs: minor fs thaw fixes and adjustments

/085 on xfs and found no regressions. Luis R. Rodriguez (3): fs: move documentation for thaw_super() where appropriate fs: make thaw_super_locked() really just a helper fs: fix corner case race on freeze_bdev() when sb disappears fs/block_dev.c | 4 +++- fs/super.c | 39

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Tue, Apr 17, 2018 at 05:59:36PM -0700, Luis R. Rodriguez wrote: > On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote: > > Hello, > > > > I think I owe you a reply here... Sorry that it took so long. > > Took me just as long :) > > > On Fri 01-12-

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Tue, Apr 17, 2018 at 05:59:36PM -0700, Luis R. Rodriguez wrote: > On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote: > > Hello, > > > > I think I owe you a reply here... Sorry that it took so long. > > Took me just as long :) > > > On Fri 01-12-

Re: [PATCH driver-core 2/2] test_firmware: fix setting old custom fw path back on exit, second try

Ben Hutchings <ben.hutchi...@codethink.co.uk> Acked-by: Luis R. Rodriguez <mcg...@kernel.org> Greg, let me know if you want to take these two in now, or if you want me to queue them up on my own and then send you what I get in the queue later. Luis

Re: [PATCH driver-core 2/2] test_firmware: fix setting old custom fw path back on exit, second try

ue stored > and fw_get_filesystem_firmware() only ignores zero-length paths. > > Instead, write a null byte. > > Fixes: 0a8adf58475 ("test: add firmware_class loader test") > Fixes: 65c79230576 ("test_firmware: fix setting old custom fw path back on > exit") > Signed-off-b

Re: [PATCH driver-core 1/2] test_firmware: Install all scripts

b3cf21fae1fe0 ("test_firmware: test three firmware kernel configs ...") > Signed-off-by: Ben Hutchings <ben.hutchi...@codethink.co.uk> Acked-by: Luis R. Rodriguez <mcg...@kernel.org> Luis

Re: [PATCH driver-core 1/2] test_firmware: Install all scripts

b3cf21fae1fe0 ("test_firmware: test three firmware kernel configs ...") > Signed-off-by: Ben Hutchings Acked-by: Luis R. Rodriguez Luis

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote: > Hello, > > I think I owe you a reply here... Sorry that it took so long. Took me just as long :) > On Fri 01-12-17 22:13:27, Luis R. Rodriguez wrote: > > > > I'll note that its still not perfectly clear if rea

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote: > Hello, > > I think I owe you a reply here... Sorry that it took so long. Took me just as long :) > On Fri 01-12-17 22:13:27, Luis R. Rodriguez wrote: > > > > I'll note that its still not perfectly clear if rea

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote: > static void firmware_free_data(const struct firmware *fw) > { > @@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p, > const char *name, > goto out; > > ret =

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote: > static void firmware_free_data(const struct firmware *fw) > { > @@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p, > const char *name, > goto out; > > ret =

Re: [PATCH AUTOSEL for 4.9 188/293] fs: warn in case userspace lied about modprobe return

On Sun, Apr 8, 2018 at 5:25 PM, Sasha Levin <alexander.le...@microsoft.com> wrote: > From: "Luis R. Rodriguez" <mcg...@kernel.org> > > [ Upstream commit 41124db869b7e00e12052555f8987867ac01d70c ] > > kmod <= v19 was broken -- it could return 0 t

Re: [PATCH AUTOSEL for 4.9 188/293] fs: warn in case userspace lied about modprobe return

On Sun, Apr 8, 2018 at 5:25 PM, Sasha Levin wrote: > From: "Luis R. Rodriguez" > > [ Upstream commit 41124db869b7e00e12052555f8987867ac01d70c ] > > kmod <= v19 was broken -- it could return 0 to modprobe calls, > incorrectly assuming that a kernel module was

Re: [PATCH] firmware: Fix firmware documentation for recent file renames

On Sun, Apr 08, 2018 at 03:47:49PM +0200, Hans de Goede wrote: > firmware_class.c was split into several files under > drivers/base/firmware_loader. The new main.c has the functions which > /request_firmware.rst references. > > Signed-off-by: Hans de Goede <hdego...@redhat.com&

Re: [PATCH] firmware: Fix firmware documentation for recent file renames

On Sun, Apr 08, 2018 at 03:47:49PM +0200, Hans de Goede wrote: > firmware_class.c was split into several files under > drivers/base/firmware_loader. The new main.c has the functions which > /request_firmware.rst references. > > Signed-off-by: Hans de Goede Acked-by: Luis R. Rodriguez Luis

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Thu, Apr 05, 2018 at 07:43:49AM +0200, Lukas Wunner wrote: > On Wed, Apr 04, 2018 at 01:18:36PM -0400, Peter Jones wrote: > > > On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote: > > > > * Add the EFI Firmware Volume Protocol to include/linux/efi.h: > > > > > > > >

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Thu, Apr 05, 2018 at 07:43:49AM +0200, Lukas Wunner wrote: > On Wed, Apr 04, 2018 at 01:18:36PM -0400, Peter Jones wrote: > > > On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote: > > > > * Add the EFI Firmware Volume Protocol to include/linux/efi.h: > > > > > > > >

Re: [PATCH] test_firmware: fix setting old custom fw path back on exit, second try

On Tue, Apr 3, 2018 at 1:10 PM, Ben Hutchings <ben.hutchi...@codethink.co.uk> wrote: > On Tue, 2018-04-03 at 12:54 -0700, Luis R. Rodriguez wrote: >> On Tue, Apr 3, 2018 at 12:48 PM, Ben Hutchings >> > <ben.hutchi...@codethink.co.uk> wrote: >> > Commi

Re: [PATCH] test_firmware: fix setting old custom fw path back on exit, second try

On Tue, Apr 3, 2018 at 1:10 PM, Ben Hutchings wrote: > On Tue, 2018-04-03 at 12:54 -0700, Luis R. Rodriguez wrote: >> On Tue, Apr 3, 2018 at 12:48 PM, Ben Hutchings >> > wrote: >> > Commit 65c79230576 tried to clear the custom firmware path on exit by

Re: [PATCH] test_firmware: fix setting old custom fw path back on exit, second try

On Tue, Apr 3, 2018 at 12:48 PM, Ben Hutchings wrote: > Commit 65c79230576 tried to clear the custom firmware path on exit by > writing a single space to the firmware_class.path parameter. This > doesn't work because nothing strips this space from the value stored

Re: [PATCH] test_firmware: fix setting old custom fw path back on exit, second try

On Tue, Apr 3, 2018 at 12:48 PM, Ben Hutchings wrote: > Commit 65c79230576 tried to clear the custom firmware path on exit by > writing a single space to the firmware_class.path parameter. This > doesn't work because nothing strips this space from the value stored > and

Re: [PATCH 4.4 085/134] test_firmware: fix setting old custom fw path back on exit

On Sun, Apr 01, 2018 at 07:56:55PM +0100, Ben Hutchings wrote: > On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > -- > > > > From: "

Re: [PATCH 4.4 085/134] test_firmware: fix setting old custom fw path back on exit

On Sun, Apr 01, 2018 at 07:56:55PM +0100, Ben Hutchings wrote: > On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > -- > > > > From: "Luis R

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote: > On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote: > > I asked Peter Jones for suggestions how to extract this during boot and > > he suggested seeing if there was a copy of the firmware in the > > EFI_BOOT_SERVICES_CODE

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote: > On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote: > > I asked Peter Jones for suggestions how to extract this during boot and > > he suggested seeing if there was a copy of the firmware in the > > EFI_BOOT_SERVICES_CODE

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

he review. > > On 03-04-18 01:23, Luis R. Rodriguez wrote: > > On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote: > > > Just like with PCI options ROMs, which we save in the setup_efi_pci* > > > functions from arch/x86/boot/compressed/eboot.c, the EFI code /

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

he review. > > On 03-04-18 01:23, Luis R. Rodriguez wrote: > > On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote: > > > Just like with PCI options ROMs, which we save in the setup_efi_pci* > > > functions from arch/x86/boot/compressed/eboot.c, the EFI code /

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Tue, Apr 3, 2018 at 9:56 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > The biggest thing which has changed since then is that we decided to *not* > support or streamline generic firmware signing (non-IMA) for now for a few > reasons [0] [1] which are importan

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Tue, Apr 3, 2018 at 9:56 AM, Luis R. Rodriguez wrote: > The biggest thing which has changed since then is that we decided to *not* > support or streamline generic firmware signing (non-IMA) for now for a few > reasons [0] [1] which are important to re-iterate as these are easy

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Mon, Apr 02, 2018 at 05:42:22PM -0700, Andy Lutomirski wrote: > On 11/10/2017 01:02 PM, Mimi Zohar wrote: > > If the kernel is locked down and IMA-appraisal is not enabled, prevent > > loading of unsigned firmware. > > > diff --git a/security/fw_lockdown/Kconfig b/security/fw_lockdown/Kconfig

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Mon, Apr 02, 2018 at 05:42:22PM -0700, Andy Lutomirski wrote: > On 11/10/2017 01:02 PM, Mimi Zohar wrote: > > If the kernel is locked down and IMA-appraisal is not enabled, prevent > > loading of unsigned firmware. > > > diff --git a/security/fw_lockdown/Kconfig b/security/fw_lockdown/Kconfig

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote: > Just like with PCI options ROMs, which we save in the setup_efi_pci* > functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself > sometimes may contain data which is useful/necessary for peripheral drivers > to have

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote: > Just like with PCI options ROMs, which we save in the setup_efi_pci* > functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself > sometimes may contain data which is useful/necessary for peripheral drivers > to have

Re: [PATCH 002/109] kernel: use kernel_wait4() instead of sys_wait4()

moves in-kernel calls to syscalls. > On this basis, the syscall entry path can be streamlined. For details, see > http://lkml.kernel.org/r/20180325162527.ga17...@light.dominikbrodowski.net > > Cc: Luis R. Rodriguez <mcg...@kernel.org> > Cc: Al Viro <v...@zeniv.linux.

Re: [PATCH 002/109] kernel: use kernel_wait4() instead of sys_wait4()

moves in-kernel calls to syscalls. > On this basis, the syscall entry path can be streamlined. For details, see > http://lkml.kernel.org/r/20180325162527.ga17...@light.dominikbrodowski.net > > Cc: Luis R. Rodriguez > Cc: Al Viro > Cc: Andrew Morton > Signed-off-by: Dominik Bro

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Fri, Mar 30, 2018 at 02:47:05AM +, Sasha Levin wrote: > On Thu, Mar 29, 2018 at 10:05:35AM +1100, Dave Chinner wrote: > >On Wed, Mar 28, 2018 at 07:30:06PM +, Sasha Levin wrote: > >"./check -g auto" runs the full "expected to pass" regression test > >suite for all configured test

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Fri, Mar 30, 2018 at 02:47:05AM +, Sasha Levin wrote: > On Thu, Mar 29, 2018 at 10:05:35AM +1100, Dave Chinner wrote: > >On Wed, Mar 28, 2018 at 07:30:06PM +, Sasha Levin wrote: > >"./check -g auto" runs the full "expected to pass" regression test > >suite for all configured test

Re: [PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

On Thu, Mar 29, 2018 at 02:47:18PM -0400, Waiman Long wrote: > On 03/29/2018 02:15 PM, Luis R. Rodriguez wrote: > > On Mon, Mar 19, 2018 at 11:39:19AM -0400, Waiman Long wrote: > >> On 03/16/2018 09:10 PM, Luis R. Rodriguez wrote: > >>> On Fri, Mar 16, 2018 at 02:13

Re: [PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

On Thu, Mar 29, 2018 at 02:47:18PM -0400, Waiman Long wrote: > On 03/29/2018 02:15 PM, Luis R. Rodriguez wrote: > > On Mon, Mar 19, 2018 at 11:39:19AM -0400, Waiman Long wrote: > >> On 03/16/2018 09:10 PM, Luis R. Rodriguez wrote: > >>> On Fri, Mar 16, 2018 at 02:13

Re: [PATCH v5 0/9] ipc: Clamp *mni to the real IPCMNI limit & increase that limit

On Thu, Mar 29, 2018 at 06:19:35PM +, Luis R. Rodriguez wrote: > Andrew, > > please drop these patches until further notice. I would recommend we avoid > merging > these patches until we get proper Acked-by for the entire set. Waiman has a > bit more > work to do a

Re: [PATCH v5 0/9] ipc: Clamp *mni to the real IPCMNI limit & increase that limit

On Thu, Mar 29, 2018 at 06:19:35PM +, Luis R. Rodriguez wrote: > Andrew, > > please drop these patches until further notice. I would recommend we avoid > merging > these patches until we get proper Acked-by for the entire set. Waiman has a > bit more > work to do a

Re: [PATCH v5 0/9] ipc: Clamp *mni to the real IPCMNI limit & increase that limit

Andrew, please drop these patches until further notice. I would recommend we avoid merging these patches until we get proper Acked-by for the entire set. Waiman has a bit more work to do and even after the 5th iteration this is not right yet. Luis

Re: [PATCH v5 0/9] ipc: Clamp *mni to the real IPCMNI limit & increase that limit

Andrew, please drop these patches until further notice. I would recommend we avoid merging these patches until we get proper Acked-by for the entire set. Waiman has a bit more work to do and even after the 5th iteration this is not right yet. Luis

Re: [PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

On Mon, Mar 19, 2018 at 11:35:19AM -0400, Waiman Long wrote: > On 03/16/2018 08:54 PM, Luis R. Rodriguez wrote: > > On Fri, Mar 16, 2018 at 02:13:43PM -0400, Waiman Long wrote: > >> Checking code is added to provide the following additional > >> ctl_table.flags check

Re: [PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

On Mon, Mar 19, 2018 at 11:35:19AM -0400, Waiman Long wrote: > On 03/16/2018 08:54 PM, Luis R. Rodriguez wrote: > > On Fri, Mar 16, 2018 at 02:13:43PM -0400, Waiman Long wrote: > >> Checking code is added to provide the following additional > >> ctl_table.flags check

Re: [PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

On Mon, Mar 19, 2018 at 11:39:19AM -0400, Waiman Long wrote: > On 03/16/2018 09:10 PM, Luis R. Rodriguez wrote: > > On Fri, Mar 16, 2018 at 02:13:42PM -0400, Waiman Long wrote: > >> When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table > >> entry, an

Re: [PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

On Mon, Mar 19, 2018 at 11:39:19AM -0400, Waiman Long wrote: > On 03/16/2018 09:10 PM, Luis R. Rodriguez wrote: > > On Fri, Mar 16, 2018 at 02:13:42PM -0400, Waiman Long wrote: > >> When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table > >> entry, an

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Thu, Mar 29, 2018 at 10:05:35AM +1100, Dave Chinner wrote: > On Wed, Mar 28, 2018 at 07:30:06PM +, Sasha Levin wrote: > > > > This is actually something I want maintainers to dictate. What sort of > > testing would make the XFS folks happy here? Right now I'm doing > > "./check 'xfs/*'"

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Thu, Mar 29, 2018 at 10:05:35AM +1100, Dave Chinner wrote: > On Wed, Mar 28, 2018 at 07:30:06PM +, Sasha Levin wrote: > > > > This is actually something I want maintainers to dictate. What sort of > > testing would make the XFS folks happy here? Right now I'm doing > > "./check 'xfs/*'"

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Tue, Mar 27, 2018 at 09:06:37AM +0200, Michal Hocko wrote: > So by no means the MM backports were reviewed by me. And considering how hard > it is to get any review for MM patches in general I strongly suspect that > others didn't review either. > > In general I am quite skeptical about the

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Tue, Mar 27, 2018 at 09:06:37AM +0200, Michal Hocko wrote: > So by no means the MM backports were reviewed by me. And considering how hard > it is to get any review for MM patches in general I strongly suspect that > others didn't review either. > > In general I am quite skeptical about the

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Mon, Mar 26, 2018 at 04:54:59AM +, Sasha Levin wrote: > On Sat, Mar 24, 2018 at 10:21:59AM -0700, Darrick J. Wong wrote: > >On Sat, Mar 24, 2018 at 10:06:38AM +0100, Greg Kroah-Hartman wrote: > >> On Fri, Mar 23, 2018 at 06:23:02PM +, Luis R. Rodriguez wrote: > >

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Mon, Mar 26, 2018 at 04:54:59AM +, Sasha Levin wrote: > On Sat, Mar 24, 2018 at 10:21:59AM -0700, Darrick J. Wong wrote: > >On Sat, Mar 24, 2018 at 10:06:38AM +0100, Greg Kroah-Hartman wrote: > >> On Fri, Mar 23, 2018 at 06:23:02PM +, Luis R. Rodriguez wrote: > >

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Fri, Mar 23, 2018 at 10:26:20AM -0700, Darrick J. Wong wrote: > On Fri, Mar 23, 2018 at 05:08:13PM +0000, Luis R. Rodriguez wrote: > > On Thu, Mar 22, 2018 at 08:41:45PM -0700, Darrick J. Wong wrote: > > > On Fri, Mar 23, 2018 at 01:30:37AM +, Luis R. Rodriguez wrote: >

Re: [PATCH] xfs: always free inline data before resetting inode fork during ifree

On Fri, Mar 23, 2018 at 10:26:20AM -0700, Darrick J. Wong wrote: > On Fri, Mar 23, 2018 at 05:08:13PM +0000, Luis R. Rodriguez wrote: > > On Thu, Mar 22, 2018 at 08:41:45PM -0700, Darrick J. Wong wrote: > > > On Fri, Mar 23, 2018 at 01:30:37AM +, Luis R. Rodriguez wrote: >

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Thu, Mar 22, 2018 at 3:15 PM, Andy Lutomirski wrote: > All we need to do is to make sure that, if this is > distributed as a module, that it's init routine doesn't wait for a > long time, right? Yeap. Luis

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Thu, Mar 22, 2018 at 3:15 PM, Andy Lutomirski wrote: > All we need to do is to make sure that, if this is > distributed as a module, that it's init routine doesn't wait for a > long time, right? Yeap. Luis

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Sat, Mar 10, 2018 at 03:16:52PM +, Luis R. Rodriguez wrote: > On Sat, Mar 10, 2018 at 02:08:43PM +0000, Luis R. Rodriguez wrote: > > The alternative to this would be a simple equivalent of > > try_then_request_module() > > for UMH modules: try_umhm_then_request_umh_mod

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Sat, Mar 10, 2018 at 03:16:52PM +, Luis R. Rodriguez wrote: > On Sat, Mar 10, 2018 at 02:08:43PM +0000, Luis R. Rodriguez wrote: > > The alternative to this would be a simple equivalent of > > try_then_request_module() > > for UMH modules: try_umhm_then_request_umh_mod

[PATCH v4 1/3] firmware: fix typo on pr_info_once() when ignore_sysfs_fallback is used

When the sysctl knob is used ignore the fallback mechanism we pr_info_once() to ensure its noted the knob was used. The print incorrectly states its a debugfs knob, its a sysctl knob, so correct this typo. Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- drivers/base/firmware_

[PATCH v4 1/3] firmware: fix typo on pr_info_once() when ignore_sysfs_fallback is used

When the sysctl knob is used ignore the fallback mechanism we pr_info_once() to ensure its noted the knob was used. The print incorrectly states its a debugfs knob, its a sysctl knob, so correct this typo. Signed-off-by: Luis R. Rodriguez --- drivers/base/firmware_loader/fallback.c | 2 +- 1

[PATCH v4 0/3] firmware: add firmware_request_cache()

addressing the firmware API rename for the rest of the callers. That will take some time as I'm running quite a bit of tests on those changes and I am going to wait for 0-day to give me its blesssings. Question, feedback, and specially rants are greatly appreciated. Luis Luis R. Rodriguez (3

[PATCH v4 0/3] firmware: add firmware_request_cache()

addressing the firmware API rename for the rest of the callers. That will take some time as I'm running quite a bit of tests on those changes and I am going to wait for 0-day to give me its blesssings. Question, feedback, and specially rants are greatly appreciated. Luis Luis R. Rodriguez (3

[PATCH v4 2/3] firmware: add firmware_request_cache() to help with cache on reboot

the firmware on a reboot and then suspend they can miss looking for the firmware on resume. To help with this we need a way to cache the firmware when such an optimization has taken place. Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- .../driver-api/firmware/request_firmwa

[PATCH v4 2/3] firmware: add firmware_request_cache() to help with cache on reboot

the firmware on a reboot and then suspend they can miss looking for the firmware on resume. To help with this we need a way to cache the firmware when such an optimization has taken place. Signed-off-by: Luis R. Rodriguez --- .../driver-api/firmware/request_firmware.rst | 14

[PATCH v4 3/3] mt7601u: use firmware_request_cache() to address cache on reboot

back this fixes his woes with both suspend and hibernation. Reported-by: Cantabile <cantabile.d...@gmail.com> Tested-by: Cantabile <cantabile.d...@gmail.com> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- drivers/net/wireless/mediatek/mt7601u/mcu.c | 2 +- 1 file ch

[PATCH v4 3/3] mt7601u: use firmware_request_cache() to address cache on reboot

back this fixes his woes with both suspend and hibernation. Reported-by: Cantabile Tested-by: Cantabile Signed-off-by: Luis R. Rodriguez --- drivers/net/wireless/mediatek/mt7601u/mcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c

Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

On Tue, Mar 20, 2018 at 02:54:44PM -0400, Konstantin Ryabitsev wrote: > On 03/20/18 14:24, Luis R. Rodriguez wrote: > > *Iff* this seems sensible, this would only mean kernel.org would have to > > start > > accepting git notes long term, for those who optionally want to p

Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

On Tue, Mar 20, 2018 at 02:54:44PM -0400, Konstantin Ryabitsev wrote: > On 03/20/18 14:24, Luis R. Rodriguez wrote: > > *Iff* this seems sensible, this would only mean kernel.org would have to > > start > > accepting git notes long term, for those who optionally want to p

Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

On Tue, Mar 20, 2018 at 06:38:01PM +0100, Greg KH wrote: > On Tue, Mar 20, 2018 at 05:34:09PM +0000, Luis R. Rodriguez wrote: > > On Tue, Mar 20, 2018 at 09:30:55AM +0100, Greg KH wrote: > > > On Sat, Mar 10, 2018 at 06:15:00AM -0800, Luis R. Rodriguez wrote: > >

Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

On Tue, Mar 20, 2018 at 06:38:01PM +0100, Greg KH wrote: > On Tue, Mar 20, 2018 at 05:34:09PM +0000, Luis R. Rodriguez wrote: > > On Tue, Mar 20, 2018 at 09:30:55AM +0100, Greg KH wrote: > > > On Sat, Mar 10, 2018 at 06:15:00AM -0800, Luis R. Rodriguez wrote: > >

Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

On Tue, Mar 20, 2018 at 09:30:55AM +0100, Greg KH wrote: > On Sat, Mar 10, 2018 at 06:15:00AM -0800, Luis R. Rodriguez wrote: > > +EXPORT_SYMBOL_GPL(request_firmware_cache); > > I know you are just following the existing naming scheme, but please > let's not continue the prob

Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

On Tue, Mar 20, 2018 at 09:30:55AM +0100, Greg KH wrote: > On Sat, Mar 10, 2018 at 06:15:00AM -0800, Luis R. Rodriguez wrote: > > +EXPORT_SYMBOL_GPL(request_firmware_cache); > > I know you are just following the existing naming scheme, but please > let's not continue the prob

Re: [PATCH v3 11/20] firmware: enable to force disable the fallback mechanism at run time

On Wed, Mar 14, 2018 at 12:00 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Sat, Mar 10, 2018 at 06:14:52AM -0800, Luis R. Rodriguez wrote: >> You currently need four different kernel builds to test the firmware >> API fully. By adding a proc knob to force disable t

Re: [PATCH v3 11/20] firmware: enable to force disable the fallback mechanism at run time

On Wed, Mar 14, 2018 at 12:00 PM, Greg KH wrote: > On Sat, Mar 10, 2018 at 06:14:52AM -0800, Luis R. Rodriguez wrote: >> You currently need four different kernel builds to test the firmware >> API fully. By adding a proc knob to force disable the fallback mechanism >> c

WARNING: CPU: 5 PID: 74 at ../drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nvkm_dp_enable+0xbe/0x140 [nouveau]

I have been getting the following splat for while now, guess its time to report, this is on 4.15.8-1-default (OpenSUSE Tumbleweed). I could try a more up to date kernel if we think this can be fixed. Mar 16 16:48:18 olga kernel: kvm: SMP vm created on host with unstable TSC; guest TSC will not

WARNING: CPU: 5 PID: 74 at ../drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nvkm_dp_enable+0xbe/0x140 [nouveau]

I have been getting the following splat for while now, guess its time to report, this is on 4.15.8-1-default (OpenSUSE Tumbleweed). I could try a more up to date kernel if we think this can be fixed. Mar 16 16:48:18 olga kernel: kvm: SMP vm created on host with unstable TSC; guest TSC will not

Re: [PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

On Fri, Mar 16, 2018 at 02:13:42PM -0400, Waiman Long wrote: > When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table > entry, any update from the userspace will be clamped to the given > range without error if either the proc_dointvec_minmax() or the > proc_douintvec_minmax() handlers is

Re: [PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

On Fri, Mar 16, 2018 at 02:13:42PM -0400, Waiman Long wrote: > When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table > entry, any update from the userspace will be clamped to the given > range without error if either the proc_dointvec_minmax() or the > proc_douintvec_minmax() handlers is

Re: [PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

On Fri, Mar 16, 2018 at 02:13:43PM -0400, Waiman Long wrote: > Checking code is added to provide the following additional > ctl_table.flags checks: > > 1) No unknown flag is allowed. > 2) Minimum of a range cannot be larger than the maximum value. > 3) The signed and unsigned flags are

Re: [PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

On Fri, Mar 16, 2018 at 02:13:43PM -0400, Waiman Long wrote: > Checking code is added to provide the following additional > ctl_table.flags checks: > > 1) No unknown flag is allowed. > 2) Minimum of a range cannot be larger than the maximum value. > 3) The signed and unsigned flags are

Re: [PATCH v2 02/36] kernel: use kernel_wait4() instead of sys_wait4()

On Thu, Mar 15, 2018 at 08:04:55PM +0100, Dominik Brodowski wrote: > diff --git a/kernel/umh.c b/kernel/umh.c > index 18e5fa4b0e71..f4b557cadf08 100644 > --- a/kernel/umh.c > +++ b/kernel/umh.c > @@ -135,7 +135,7 @@ static void call_usermodehelper_exec_sync(struct > subprocess_info *sub_info) >

Re: [PATCH v2 02/36] kernel: use kernel_wait4() instead of sys_wait4()

On Thu, Mar 15, 2018 at 08:04:55PM +0100, Dominik Brodowski wrote: > diff --git a/kernel/umh.c b/kernel/umh.c > index 18e5fa4b0e71..f4b557cadf08 100644 > --- a/kernel/umh.c > +++ b/kernel/umh.c > @@ -135,7 +135,7 @@ static void call_usermodehelper_exec_sync(struct > subprocess_info *sub_info) >

Re: [PATCH v3 05/20] firmware: simplify CONFIG_FW_LOADER_USER_HELPER_FALLBACK further

On Wed, Mar 14, 2018 at 11:53 AM, Greg KH <gre...@linuxfoundation.org> wrote: > On Sat, Mar 10, 2018 at 06:14:46AM -0800, Luis R. Rodriguez wrote: >> All CONFIG_FW_LOADER_USER_HELPER_FALLBACK really is, is just a bool, >> initailized at build time. Define it as such. This si

Re: [PATCH v3 05/20] firmware: simplify CONFIG_FW_LOADER_USER_HELPER_FALLBACK further

On Wed, Mar 14, 2018 at 11:53 AM, Greg KH wrote: > On Sat, Mar 10, 2018 at 06:14:46AM -0800, Luis R. Rodriguez wrote: >> All CONFIG_FW_LOADER_USER_HELPER_FALLBACK really is, is just a bool, >> initailized at build time. Define it as such. This simplifies the >> logic even

Re: [PATCH v3 07/20] firmware: move loading timeout under struct firmware_fallback_config

On Wed, Mar 14, 2018 at 11:56 AM, Greg KH <gre...@linuxfoundation.org> wrote: > On Sat, Mar 10, 2018 at 06:14:48AM -0800, Luis R. Rodriguez wrote: >> The timeout is a fallback construct, so we can just stuff the >> timeout configuration under struct firmware_fallback_config

Re: [PATCH v3 07/20] firmware: move loading timeout under struct firmware_fallback_config

On Wed, Mar 14, 2018 at 11:56 AM, Greg KH wrote: > On Sat, Mar 10, 2018 at 06:14:48AM -0800, Luis R. Rodriguez wrote: >> The timeout is a fallback construct, so we can just stuff the >> timeout configuration under struct firmware_fallback_config. > > Why? What does it mat

Re: [PATCH v3 00/20] firmware: development for v4.17

On Sat, Mar 10, 2018 at 09:16:36AM -0800, Kees Cook wrote: > On Sat, Mar 10, 2018 at 6:14 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > > Greg, > > > > Here's a respin of what I have queued up for v4.17 for the firmware API. It > > combines the cleanup I've

Re: [PATCH v3 00/20] firmware: development for v4.17

On Sat, Mar 10, 2018 at 09:16:36AM -0800, Kees Cook wrote: > On Sat, Mar 10, 2018 at 6:14 AM, Luis R. Rodriguez wrote: > > Greg, > > > > Here's a respin of what I have queued up for v4.17 for the firmware API. It > > combines the cleanup I've been working on and

Re: [PATCH] firmware: add a function to load optional firmware v2

On Tue, Mar 13, 2018 at 03:16:34PM +0200, Kalle Valo wrote: > "Luis R. Rodriguez" <mcg...@kernel.org> writes: > > >> +/** > >> + * request_firmware_optional: - request for an optional fw module > >> + * @firmware_p: pointer to firmware image >

Re: [PATCH] firmware: add a function to load optional firmware v2

On Tue, Mar 13, 2018 at 03:16:34PM +0200, Kalle Valo wrote: > "Luis R. Rodriguez" writes: > > >> +/** > >> + * request_firmware_optional: - request for an optional fw module > >> + * @firmware_p: pointer to firmware image > >> + * @name: name

<    1   2   3   4   5   6   7   8   9   10   >