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
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:
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
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:
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
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
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
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
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
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
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
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
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:
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:
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
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
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:
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:
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
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
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:
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:
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
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
Jiri Olsa writes:
Please fix this quickly, PT is currently totally non functional in Linus
mainline.
-Andi
Jiri Olsa writes:
Please fix this quickly, PT is currently totally non functional in Linus
mainline.
-Andi
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
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
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
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
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()
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
>
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
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
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:
>
>
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:
>
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
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
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
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
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:
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:
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
---
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
+++
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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':
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
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 ++
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':
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
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
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
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
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
> > >
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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:
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
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
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:
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:
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
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
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
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
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
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
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
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
---
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
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
/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
/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 - 100 of 462 matches
Mail list logo