[PATCH] scsi: 3ware: fix a missing-check bug

In twl_chrdev_ioctl(), the ioctl driver command is firstly copied from the userspace pointer 'argp' and saved to the kernel object 'driver_command'. Then a security check is performed on the data buffer size indicated by 'driver_command', which is 'driver_command.buffer_length'. If the security

Re: [PATCH v3 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

Hi Changbin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] scsi: 3ware: fix a missing-check bug

In twl_chrdev_ioctl(), the ioctl driver command is firstly copied from the userspace pointer 'argp' and saved to the kernel object 'driver_command'. Then a security check is performed on the data buffer size indicated by 'driver_command', which is 'driver_command.buffer_length'. If the security

Re: [PATCH v3 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

Hi Changbin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] scsi: 3w-xxxx: fix a missing-check bug

In tw_chrdev_ioctl(), the length of the data buffer is firstly copied from the userspace pointer 'argp' and saved to the kernel object 'data_buffer_length'. Then a security check is performed on it to make sure that the length is not more than 'TW_MAX_IOCTL_SECTORS * 512'. Otherwise, an error code

[PATCH] scsi: 3w-xxxx: fix a missing-check bug

In tw_chrdev_ioctl(), the length of the data buffer is firstly copied from the userspace pointer 'argp' and saved to the kernel object 'data_buffer_length'. Then a security check is performed on it to make sure that the length is not more than 'TW_MAX_IOCTL_SECTORS * 512'. Otherwise, an error code

[PATCH v3] block: add verifier for cmdline partition

I meet strange filesystem corruption issue recently, the reason is there are overlaps partitions in cmdline partition argument. This patch add verifier for cmdline partition, then if there are overlaps partitions, cmdline_partition will log a warning. Signed-off-by: Wang YanQing

[PATCH v3] block: add verifier for cmdline partition

I meet strange filesystem corruption issue recently, the reason is there are overlaps partitions in cmdline partition argument. This patch add verifier for cmdline partition, then if there are overlaps partitions, cmdline_partition will log a warning. Signed-off-by: Wang YanQing --- Changes

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

On Sun, May 06, 2018 at 08:00:49AM +1000, NeilBrown wrote: > > The insert function must (and does) take the lock on the bucket before > testing if there is a "next" table. > If one inserter finds that it has locked the "last" table (because there > is no next) and successfully inserts, then the

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

On Sun, May 06, 2018 at 08:00:49AM +1000, NeilBrown wrote: > > The insert function must (and does) take the lock on the bucket before > testing if there is a "next" table. > If one inserter finds that it has locked the "last" table (because there > is no next) and successfully inserts, then the

Re: [PATCH 4/8] rhashtable: fix race in nested_table_alloc()

On Sun, May 06, 2018 at 07:48:20AM +1000, NeilBrown wrote: > > The spinlock protects 2 or more buckets. The nested table contains at > least 512 buckets, maybe more. > It is quite possible for two insertions into 2 different buckets to both > get their spinlock and both try to instantiate the

Re: [PATCH 4/8] rhashtable: fix race in nested_table_alloc()

On Sun, May 06, 2018 at 07:48:20AM +1000, NeilBrown wrote: > > The spinlock protects 2 or more buckets. The nested table contains at > least 512 buckets, maybe more. > It is quite possible for two insertions into 2 different buckets to both > get their spinlock and both try to instantiate the

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On 2018/05/06 11:24, Theodore Y. Ts'o wrote: > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm >> syz-executor909: root inode unallocated >> Kernel panic - not syncing:

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On 2018/05/06 11:24, Theodore Y. Ts'o wrote: > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm >> syz-executor909: root inode unallocated >> Kernel panic - not syncing:

Re: [PATCH] nubus: Unconditionally register bus type

On Sun, May 06, 2018 at 11:47:52AM +1000, Finn Thain wrote: > Loading a NuBus driver module on a non-NuBus machine triggers the > BUG_ON(!drv->bus->p) in driver_register() because the bus does not get > registered unless MACH_IS_MAC(). Avoid this by registering the bus > unconditionally using

Re: [PATCH] nubus: Unconditionally register bus type

On Sun, May 06, 2018 at 11:47:52AM +1000, Finn Thain wrote: > Loading a NuBus driver module on a non-NuBus machine triggers the > BUG_ON(!drv->bus->p) in driver_register() because the bus does not get > registered unless MACH_IS_MAC(). Avoid this by registering the bus > unconditionally using

[PATCH v2] block: add verifier for cmdline partition

I meet strange filesystem corruption issue recently, the reason is there are overlaps partitions in cmdline partition argument. This patch add verifier for cmdline partition, then if there are overlaps partitions, cmdline_partition will log a warning. We don't treat overlaps partition as a error:

[PATCH v2] block: add verifier for cmdline partition

I meet strange filesystem corruption issue recently, the reason is there are overlaps partitions in cmdline partition argument. This patch add verifier for cmdline partition, then if there are overlaps partitions, cmdline_partition will log a warning. We don't treat overlaps partition as a error:

Re: [PATCH] x86/kvm: replace TASK_UNINTERRUPTIBLE with TASK_KILLABLE

On Thu, Mar 29, 2018 at 11:41:20PM +0200, Radim Krčmář wrote: > I remember we had a bug where tasks were getting stuck when running > nested and maybe there are going to be other cases to excuse the change. > I'm slightly against changing the behavior as it's pretty hard to test, > but I can be

Re: [PATCH] x86/kvm: replace TASK_UNINTERRUPTIBLE with TASK_KILLABLE

On Thu, Mar 29, 2018 at 11:41:20PM +0200, Radim Krčmář wrote: > I remember we had a bug where tasks were getting stuck when running > nested and maybe there are going to be other cases to excuse the change. > I'm slightly against changing the behavior as it's pretty hard to test, > but I can be

Re: BUG: corrupted list in rdma_listen

syzbot has found a reproducer for the following crash on: HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages git tree: https://github.com/google/kmsan.git/master console output: https://syzkaller.appspot.com/x/log.txt?x=126df29780 kernel config:

Re: BUG: corrupted list in rdma_listen

syzbot has found a reproducer for the following crash on: HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages git tree: https://github.com/google/kmsan.git/master console output: https://syzkaller.appspot.com/x/log.txt?x=126df29780 kernel config:

[PATCH] scsi: 3w-9xxx: fix a missing-check bug

In twa_chrdev_ioctl(), the ioctl driver command is firstly copied from the userspace pointer 'argp' and saved to the kernel object 'driver_command'. Then a security check is performed on the data buffer size indicated by 'driver_command', which is 'driver_command.buffer_length'. If the security

[PATCH] scsi: 3w-9xxx: fix a missing-check bug

In twa_chrdev_ioctl(), the ioctl driver command is firstly copied from the userspace pointer 'argp' and saved to the kernel object 'driver_command'. Then a security check is performed on the data buffer size indicated by 'driver_command', which is 'driver_command.buffer_length'. If the security

Re: [PATCH 05/12] perf pmu: Fix pmu events parsing rule

Jiri Olsa writes: Please fix this quickly, PT is currently totally non functional in Linus mainline. -Andi

Re: [PATCH 05/12] perf pmu: Fix pmu events parsing rule

Jiri Olsa writes: Please fix this quickly, PT is currently totally non functional in Linus mainline. -Andi

[PATCH] virt: vbox: fix a missing-check bug

In vbg_misc_device_ioctl(), the header of the ioctl argument is copied from the userspace pointer 'arg' and saved to the kernel object 'hdr'. Then the 'version', 'size_in', and 'size_out' fields of 'hdr' are verified. For example, if 'hdr.version' is not VBG_IOCTL_HDR_VERSION, an error code

[PATCH] virt: vbox: fix a missing-check bug

In vbg_misc_device_ioctl(), the header of the ioctl argument is copied from the userspace pointer 'arg' and saved to the kernel object 'hdr'. Then the 'version', 'size_in', and 'size_out' fields of 'hdr' are verified. For example, if 'hdr.version' is not VBG_IOCTL_HDR_VERSION, an error code

[PATCH] scsi: sg: fix a missing-check bug

In sg_write(), the opcode of the command is firstly copied from the userspace pointer 'buf' and saved to the kernel variable 'opcode', using the __get_user() function. The size of the command, i.e., 'cmd_size' is then calculated based on the 'opcode'. After that, the whole command, including the

[PATCH] scsi: sg: fix a missing-check bug

In sg_write(), the opcode of the command is firstly copied from the userspace pointer 'buf' and saved to the kernel variable 'opcode', using the __get_user() function. The size of the command, i.e., 'cmd_size' is then calculated based on the 'opcode'. After that, the whole command, including the

Re: [PATCH v2 2/2] MIPS: Convert update_persistent_clock() to update_persistent_clock64()

On Fri, May 4, 2018 at 3:07 AM, Baolin Wang wrote: > Since struct timespec is not y2038 safe on 32bit machines, this patch > converts update_persistent_clock() to update_persistent_clock64() using > struct timespec64. > > The rtc_mips_set_time() and rtc_mips_set_mmss()

Re: [PATCH v2 2/2] MIPS: Convert update_persistent_clock() to update_persistent_clock64()

On Fri, May 4, 2018 at 3:07 AM, Baolin Wang wrote: > Since struct timespec is not y2038 safe on 32bit machines, this patch > converts update_persistent_clock() to update_persistent_clock64() using > struct timespec64. > > The rtc_mips_set_time() and rtc_mips_set_mmss() interfaces were using >

Re: [RFC PATCH] locking/atomics/powerpc: Introduce optimized cmpxchg_release() family of APIs for PowerPC

On Sat, 2018-05-05 at 12:00 +0200, Ingo Molnar wrote: > This clearly suggests that PPC_RELEASE_BARRIER is in active use and 'lwsync' > is > the 'release barrier' instruction, if I interpreted that right. The closest to one we got. The semantics are that it orders all load/store pairs to

Re: [RFC PATCH] locking/atomics/powerpc: Introduce optimized cmpxchg_release() family of APIs for PowerPC

On Sat, 2018-05-05 at 12:00 +0200, Ingo Molnar wrote: > This clearly suggests that PPC_RELEASE_BARRIER is in active use and 'lwsync' > is > the 'release barrier' instruction, if I interpreted that right. The closest to one we got. The semantics are that it orders all load/store pairs to

Re: crosstool requirements?

On Sat, May 5, 2018 at 2:20 PM, Randy Dunlap wrote: > Hi Arnd, > > I was trying to use the x86_64 hosted openrisc/or1k gcc compiler > (7.3.0-nolibc) > but I mostly what I get are errors like the following: > >

Re: crosstool requirements?

On Sat, May 5, 2018 at 2:20 PM, Randy Dunlap wrote: > Hi Arnd, > > I was trying to use the x86_64 hosted openrisc/or1k gcc compiler > (7.3.0-nolibc) > but I mostly what I get are errors like the following: > > crosstool/gcc-7.3.0-nolibc/or1k-linux/bin/../libexec/gcc/or1k-linux/7.3.0/cc1: >

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm > syz-executor909: root inode unallocated > Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error I

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm > syz-executor909: root inode unallocated > Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error I

[GIT PULL] platform-drivers-x86 for 4.17-2

Hi Linus, I was trying to keep DELL_LAPTOP visible in the menu, but the "select" behavior makes that impossible. I'm planning on refactoring the Kconfig by vendor for those with many options in 4.18 which should clean things up. This fix from Mario corrects the potential for misconfiguration for

[GIT PULL] platform-drivers-x86 for 4.17-2

Hi Linus, I was trying to keep DELL_LAPTOP visible in the menu, but the "select" behavior makes that impossible. I'm planning on refactoring the Kconfig by vendor for those with many options in 4.18 which should clean things up. This fix from Mario corrects the potential for misconfiguration for

Re: [Intel-wired-lan] [PATCH v2 1/1] drivers core: multi-threading device shutdown

Hi Pavel, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on driver-core/driver-core-testing] [also build test WARNING on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [Intel-wired-lan] [PATCH v2 1/1] drivers core: multi-threading device shutdown

Hi Pavel, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on driver-core/driver-core-testing] [also build test WARNING on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[RFC PATCH] drivers core: device_root_tasks_done can be static

Fixes: 6d54ba128905 ("drivers core: multi-threading device shutdown") Signed-off-by: Fengguang Wu --- core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 110d797..666c163 100644 ---

[RFC PATCH] drivers core: device_root_tasks_done can be static

Fixes: 6d54ba128905 ("drivers core: multi-threading device shutdown") Signed-off-by: Fengguang Wu --- core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 110d797..666c163 100644 --- a/drivers/base/core.c +++

[PATCH] nubus: Unconditionally register bus type

Loading a NuBus driver module on a non-NuBus machine triggers the BUG_ON(!drv->bus->p) in driver_register() because the bus does not get registered unless MACH_IS_MAC(). Avoid this by registering the bus unconditionally using postcore_initcall(). Cc: Greg Kroah-Hartman

[PATCH] nubus: Unconditionally register bus type

Loading a NuBus driver module on a non-NuBus machine triggers the BUG_ON(!drv->bus->p) in driver_register() because the bus does not get registered unless MACH_IS_MAC(). Avoid this by registering the bus unconditionally using postcore_initcall(). Cc: Greg Kroah-Hartman Reported-by: Michael

Re: moving affs + RDB partition support to staging?

On Thu, Apr 26, 2018 at 12:45:41PM +0200, John Paul Adrian Glaubitz wrote: > Exactly. It works fine as is: > > root@elgar:~> uname -a > Linux elgar 4.16.0-rc2-amiga-16784-ga8917fc #650 Mon Mar 5 15:32:52 NZDT 2018 > m68k GNU/Linux > root@elgar:~> mount /dev/sda1 /mnt -taffs > root@elgar:~> ls

Re: moving affs + RDB partition support to staging?

On Thu, Apr 26, 2018 at 12:45:41PM +0200, John Paul Adrian Glaubitz wrote: > Exactly. It works fine as is: > > root@elgar:~> uname -a > Linux elgar 4.16.0-rc2-amiga-16784-ga8917fc #650 Mon Mar 5 15:32:52 NZDT 2018 > m68k GNU/Linux > root@elgar:~> mount /dev/sda1 /mnt -taffs > root@elgar:~> ls

BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

Hello, syzbot found the following crash on: HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780 kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27

kernel panic: EXT4-fs (device loop0): panic forced after error

Hello, syzbot found the following crash on: HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11a8a07b80 kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27

BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

Hello, syzbot found the following crash on: HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780 kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27

kernel panic: EXT4-fs (device loop0): panic forced after error

Hello, syzbot found the following crash on: HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11a8a07b80 kernel config: https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

On 05/05/2018 04:22 PM, kbuild test robot wrote: > Hi Maciej, > > FYI, the error/warning still remains. Hi M. Robot, I am cc-ing dri-de...@lists.freedesktop.org so that they are aware of the multiple times that you have posted this kbuild error (I have 3 different posts in my Inbox with the

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

On 05/05/2018 04:22 PM, kbuild test robot wrote: > Hi Maciej, > > FYI, the error/warning still remains. Hi M. Robot, I am cc-ing dri-de...@lists.freedesktop.org so that they are aware of the multiple times that you have posted this kbuild error (I have 3 different posts in my Inbox with the

[PATCH v3 4/5] kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og optimization

From: Changbin Du This will apply GCC '-Og' optimization level which is supported since GCC 4.8. This optimization level offers a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is similar to '-O1' while perferring to

[PATCH v3 4/5] kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og optimization

From: Changbin Du This will apply GCC '-Og' optimization level which is supported since GCC 4.8. This optimization level offers a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is similar to '-O1' while perferring to keep debug ability

[PATCH v3 2/5] regulator: add dummy function of_find_regulator_by_node

From: Changbin Du If device tree is not enabled, of_find_regulator_by_node() should have a dummy function since the function call is still there. This is to fix build error after CONFIG_NO_AUTO_INLINE is introduced. If this option is enabled, GCC will not auto-inline

[PATCH v3 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

From: Changbin Du This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting this option will prevent the compiler from optimizing the kernel by auto-inlining functions not marked with the inline keyword. With this option, only functions explicitly marked with

[PATCH v3 2/5] regulator: add dummy function of_find_regulator_by_node

From: Changbin Du If device tree is not enabled, of_find_regulator_by_node() should have a dummy function since the function call is still there. This is to fix build error after CONFIG_NO_AUTO_INLINE is introduced. If this option is enabled, GCC will not auto-inline functions that are not

[PATCH v3 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

From: Changbin Du This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting this option will prevent the compiler from optimizing the kernel by auto-inlining functions not marked with the inline keyword. With this option, only functions explicitly marked with "inline" will be

[PATCH v3 5/5] asm-generic: fix build error in fix_to_virt with CONFIG_CC_OPTIMIZE_FOR_DEBUGGING

From: Changbin Du With '-Og' optimization level, GCC would not optimize a count for a loop as a constant value. But BUILD_BUG_ON() only accept compile-time constant values. Let's use __fix_to_virt() to avoid the error. arch/arm/mm/mmu.o: In function `fix_to_virt':

[PATCH v3 0/5] kernel hacking: GCC optimization for better debug experience (-Og)

From: Changbin Du Hi all, I know some kernel developers was searching for a method to dissable GCC optimizations, probably they want to apply GCC '-O0' option. But since Linux kernel replys on GCC optimization to remove some dead code, so '-O0' just breaks the build. They

[PATCH v3 1/5] x86/mm: surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif

From: Changbin Du The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to make code correct. Signed-off-by: Changbin Du --- arch/x86/include/asm/pgtable_64.h | 2 ++

[PATCH v3 5/5] asm-generic: fix build error in fix_to_virt with CONFIG_CC_OPTIMIZE_FOR_DEBUGGING

From: Changbin Du With '-Og' optimization level, GCC would not optimize a count for a loop as a constant value. But BUILD_BUG_ON() only accept compile-time constant values. Let's use __fix_to_virt() to avoid the error. arch/arm/mm/mmu.o: In function `fix_to_virt':

[PATCH v3 0/5] kernel hacking: GCC optimization for better debug experience (-Og)

From: Changbin Du Hi all, I know some kernel developers was searching for a method to dissable GCC optimizations, probably they want to apply GCC '-O0' option. But since Linux kernel replys on GCC optimization to remove some dead code, so '-O0' just breaks the build. They do need this because

[PATCH v3 1/5] x86/mm: surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif

From: Changbin Du The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to make code correct. Signed-off-by: Changbin Du --- arch/x86/include/asm/pgtable_64.h | 2 ++ arch/x86/kernel/head64.c | 13

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

On 05/05/2018 04:57 PM, Du, Changbin wrote: > On Thu, May 03, 2018 at 10:28:23AM -0400, Steven Rostedt wrote: >> On Thu, 3 May 2018 21:45:46 +0800 >> "Du, Changbin" wrote: >> With that gcc comment, I still think CONFIG_OPTIMIZE_DEBUG is more inline with what it is

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

On 05/05/2018 04:57 PM, Du, Changbin wrote: > On Thu, May 03, 2018 at 10:28:23AM -0400, Steven Rostedt wrote: >> On Thu, 3 May 2018 21:45:46 +0800 >> "Du, Changbin" wrote: >> With that gcc comment, I still think CONFIG_OPTIMIZE_DEBUG is more inline with what it is and understandable

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

On Thu, May 03, 2018 at 10:28:23AM -0400, Steven Rostedt wrote: > On Thu, 3 May 2018 21:45:46 +0800 > "Du, Changbin" wrote: > > > > With that gcc comment, I still think CONFIG_OPTIMIZE_DEBUG is more > > > inline with what it is and understandable than > > >

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

On Thu, May 03, 2018 at 10:28:23AM -0400, Steven Rostedt wrote: > On Thu, 3 May 2018 21:45:46 +0800 > "Du, Changbin" wrote: > > > > With that gcc comment, I still think CONFIG_OPTIMIZE_DEBUG is more > > > inline with what it is and understandable than > > > CONFIG_DEBUG_EXPERIENCE. The

[GIT PULL] USB driver fixes for 4.17-rc4

The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64: Linux v4.17-rc3 (2018-04-29 14:17:42 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.17-rc4 for you to fetch changes up to

[GIT PULL] USB driver fixes for 4.17-rc4

The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64: Linux v4.17-rc3 (2018-04-29 14:17:42 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.17-rc4 for you to fetch changes up to

drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

Hi Maciej, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c1c07416cdd47161a359286021d483f449ad8c4f commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use micro-USB cable detection logic to detect

drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

Hi Maciej, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c1c07416cdd47161a359286021d483f449ad8c4f commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use micro-USB cable detection logic to detect

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

On Mon Apr 16 18, Jacob Pan wrote: From: "Liu, Yi L" When an SVM capable device is assigned to a guest, the first level page tables are owned by the guest and the guest PASID table pointer is linked to the device context entry of the physical IOMMU. Host IOMMU driver

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

On Mon Apr 16 18, Jacob Pan wrote: From: "Liu, Yi L" When an SVM capable device is assigned to a guest, the first level page tables are owned by the guest and the guest PASID table pointer is linked to the device context entry of the physical IOMMU. Host IOMMU driver has no knowledge of

Re: WARNING in kernfs_add_one

On Sat, May 05, 2018 at 10:43:45AM -0700, Eric Dumazet wrote: > > > On 05/05/2018 09:40 AM, Greg KH wrote: > > On Sat, May 05, 2018 at 08:47:02AM -0700, syzbot wrote: > >> Hello, > >> > >> syzbot found the following crash on: > >> > >> HEAD commit:8fb11a9a8d51 net/ipv6: rename rt6_next to

Re: WARNING in kernfs_add_one

On Sat, May 05, 2018 at 10:43:45AM -0700, Eric Dumazet wrote: > > > On 05/05/2018 09:40 AM, Greg KH wrote: > > On Sat, May 05, 2018 at 08:47:02AM -0700, syzbot wrote: > >> Hello, > >> > >> syzbot found the following crash on: > >> > >> HEAD commit:8fb11a9a8d51 net/ipv6: rename rt6_next to

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> rhashtable_try_insert() currently hold a lock on the bucket in >> the first table, while also locking buckets in subsequent tables. >> This is unnecessary and looks like a hold-over from some

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> rhashtable_try_insert() currently hold a lock on the bucket in >> the first table, while also locking buckets in subsequent tables. >> This is unnecessary and looks like a hold-over from some

Re: [PATCH 6/8] rhashtable: further improve stability of rhashtable_walk

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> If the sequence: >>obj = rhashtable_walk_next(iter); >>rhashtable_walk_stop(iter); >>rhashtable_remove_fast(ht, >head, params); >>rhashtable_walk_start(iter); >> >> races with

Re: [PATCH 6/8] rhashtable: further improve stability of rhashtable_walk

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> If the sequence: >>obj = rhashtable_walk_next(iter); >>rhashtable_walk_stop(iter); >>rhashtable_remove_fast(ht, >head, params); >>rhashtable_walk_start(iter); >> >> races with

Re: [PATCH 1/8] rhashtable: silence RCU warning in rhashtable_test.

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> print_ht in rhashtable_test calls rht_dereference() with neither >> RCU protection or the mutex. This triggers an RCU warning. >> So take the mutex to silence the warning. >> >> Signed-off-by:

Re: [PATCH 1/8] rhashtable: silence RCU warning in rhashtable_test.

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> print_ht in rhashtable_test calls rht_dereference() with neither >> RCU protection or the mutex. This triggers an RCU warning. >> So take the mutex to silence the warning. >> >> Signed-off-by:

Re: [PATCH 4/8] rhashtable: fix race in nested_table_alloc()

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> If two threads run nested_table_alloc() at the same time >> they could both allocate a new table. >> Best case is that one of them will never be freed, leaking memory. >> Worst case is hat entry

Re: [PATCH 4/8] rhashtable: fix race in nested_table_alloc()

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> If two threads run nested_table_alloc() at the same time >> they could both allocate a new table. >> Best case is that one of them will never be freed, leaking memory. >> Worst case is hat entry

Re: [PATCH 3/8] rhashtable: use cmpxchg() to protect ->future_tbl.

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> Rather than borrowing one of the bucket locks to >> protect ->future_tbl updates, use cmpxchg(). >> This gives more freedom to change how bucket locking >> is implemented. >> >> Signed-off-by:

Re: [PATCH 3/8] rhashtable: use cmpxchg() to protect ->future_tbl.

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> Rather than borrowing one of the bucket locks to >> protect ->future_tbl updates, use cmpxchg(). >> This gives more freedom to change how bucket locking >> is implemented. >> >> Signed-off-by:

Handling lm3559 flash on Motorola Droid 4 and others

Hi! It seems lm3559 flash driver is available on github ( https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/tree/master/linux/modules/camera/drivers/media/i2c ) but there'll be some fun getting it cleaned up and merged. Did anyone start doing anything in that area? Is there possibly

Handling lm3559 flash on Motorola Droid 4 and others

Hi! It seems lm3559 flash driver is available on github ( https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/tree/master/linux/modules/camera/drivers/media/i2c ) but there'll be some fun getting it cleaned up and merged. Did anyone start doing anything in that area? Is there possibly

[RFC PATCH 2/3] arcnet: com20020: Fixup missing SLOWARB bit

From: Andrea Greco If com20020 clock is major of 40Mhz SLOWARB bit is requested. Signed-off-by: Andrea Greco --- drivers/net/arcnet/com20020.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/arcnet/com20020.c

[RFC PATCH 2/3] arcnet: com20020: Fixup missing SLOWARB bit

From: Andrea Greco If com20020 clock is major of 40Mhz SLOWARB bit is requested. Signed-off-by: Andrea Greco --- drivers/net/arcnet/com20020.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c index f09ea77dd6a8..abd32ed8ec9b

Re: [PATCH 2/8] rhashtable: remove nulls_base and related code.

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> This "feature" is unused, undocumented, and untested and so >> doesn't really belong. If a use for the nulls marker >> is found, all this code would need to be reviewed to >> ensure it works as

Re: [PATCH 2/8] rhashtable: remove nulls_base and related code.

On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> This "feature" is unused, undocumented, and untested and so >> doesn't really belong. If a use for the nulls marker >> is found, all this code would need to be reviewed to >> ensure it works as

[RFC PATCH 3/3] arcnet: com20020: Add ethtool support

From: Andrea Greco Setup ethtols for export com20020 diag register Signed-off-by: Andrea Greco --- drivers/net/arcnet/com20020-isa.c| 1 + drivers/net/arcnet/com20020-membus.c | 1 + drivers/net/arcnet/com20020.c| 29

[RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020

From: Andrea Greco Add support for com20022I/com20020, memory mapped chip version. Support bus: Intel 80xx and Motorola 68xx. Bus size: Only 8 bit bus size is supported. Added related device tree bindings Signed-off-by: Andrea Greco ---

[RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020

From: Andrea Greco Add support for com20022I/com20020, memory mapped chip version. Support bus: Intel 80xx and Motorola 68xx. Bus size: Only 8 bit bus size is supported. Added related device tree bindings Signed-off-by: Andrea Greco --- .../devicetree/bindings/net/smsc-com20020.txt | 23

[RFC PATCH 3/3] arcnet: com20020: Add ethtool support

From: Andrea Greco Setup ethtols for export com20020 diag register Signed-off-by: Andrea Greco --- drivers/net/arcnet/com20020-isa.c| 1 + drivers/net/arcnet/com20020-membus.c | 1 + drivers/net/arcnet/com20020.c| 29 + drivers/net/arcnet/com20020.h

Re: [PATCH] ANDROID: binder: remove 32-bit binder interface.

/linux/commits/Martijn-Coenen/ANDROID-binder-remove-32-bit-binder-interface/20180505-130632 config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin

Re: [PATCH] ANDROID: binder: remove 32-bit binder interface.

/linux/commits/Martijn-Coenen/ANDROID-binder-remove-32-bit-binder-interface/20180505-130632 config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin

  1   2   3   4   5   >