On Sat, Jun 22, 2019 at 03:04:08AM +0800, kbuild test robot wrote:
> From: kbuild test robot
>
> drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c:200:3-8: No need to set
> .owner here. The core will do it.
>
> Remove .owner field if calls are used which set it automatically
>
> Generated by:
This patch is the extension of following upstream commit to fix
the race condition between get_task_mm() and core dumping
for IB->mlx4 and IB->mlx5 drivers:
commit 04f5866e41fb ("coredump: fix race condition between
mmget_not_zero()/get_task_mm() and core dumping")'
Thanks to Jason for pointing t
coredump: fix race condition between mmget_not_zero()/get_task_mm()
and core dumping
[PATCH v3 1/2]:
Backporting of commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream.
[PATCH v3 2/2]:
Extension of commit 04f5866e41fb to fix the race condition between
get_task_mm() and core dumping for IB->m
From: Andrea Arcangeli
commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream.
The core dumping code has always run without holding the mmap_sem for
writing, despite that is the only way to ensure that the entire vma
layout will not change from under it. Only using some signal
serialization o
From: Dexuan Cui Sent: Friday, June 21, 2019 4:45 PM
>
> The commit 05f151a73ec2 itself is correct, but it exposes this
> use-after-free bug, which is caught by some memory debug options.
>
> Add a Fixes tag to indicate the dependency.
>
> Fixes: 05f151a73ec2 ("PCI: hv: Fix a memory leak in hv_
The commit 05f151a73ec2 itself is correct, but it exposes this
use-after-free bug, which is caught by some memory debug options.
Add a Fixes tag to indicate the dependency.
Fixes: 05f151a73ec2 ("PCI: hv: Fix a memory leak in hv_eject_device_work()")
Signed-off-by: Dexuan Cui
Cc: sta...@vger.ke
> From: Michael Kelley
> > @@ -1880,6 +1880,7 @@ static void hv_pci_devices_present(struct
> hv_pcibus_device
> > *hbus,
> > static void hv_eject_device_work(struct work_struct *work)
> > {
> > struct pci_eject_response *ejct_pkt;
> > + struct hv_pcibus_device *hbus;
> > struct hv_pc
From: Dexuan Cui Sent: Friday, June 21, 2019 12:02 PM
>
> The commit 05f151a73ec2 itself is correct, but it exposes this
> use-after-free bug, which is caught by some memory debug options.
>
> Add the Fixes tag to indicate the dependency.
>
> Fixes: 05f151a73ec2 ("PCI: hv: Fix a memory leak in
From: kbuild test robot
drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c:200:3-8: No need to set .owner
here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Fixes: abddd78ef465 ("staging:
The commit 05f151a73ec2 itself is correct, but it exposes this
use-after-free bug, which is caught by some memory debug options.
Add the Fixes tag to indicate the dependency.
Fixes: 05f151a73ec2 ("PCI: hv: Fix a memory leak in hv_eject_device_work()")
Signed-off-by: Dexuan Cui
Cc: sta...@vger.
syzkallar found a 32-byte memory leak in a rarely executed error
case. The transaction complete work item was not freed if put_user()
failed when writing the BR_TRANSACTION_COMPLETE to the user command
buffer. Fixed by freeing it before put_user() is called.
Reported-by: syzbot+182ce46596c3f2e1e..
On Thu, Jun 13, 2019 at 2:56 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:d1fdb6d8 Linux 5.2-rc4
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15e5ce1ea0
> kernel config: https://syzkaller.appspot.com/x/.conf
The pull request you sent on Fri, 21 Jun 2019 10:11:02 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> tags/staging-5.2-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/db54615e21419c3cb4d699a0b0aa16cc44d0e9da
Thank you!
--
Deet-doot-d
If most_register_configfs_subsys fails, call
most_deregister_component to clean up.
Fixes: 919c03ae11b9 ("staging: most: enable configfs support")
Signed-off-by: YueHaibing
---
drivers/staging/most/sound/sound.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drive
Hi Greg,
On Fri, Jun 21, 2019 at 2:35 PM Greg Ungerer wrote:
>
> Hi Sergio,
>
> On 21/6/19 4:15 pm, Sergio Paracuellos wrote:
> > This patch series properly handle minor issues in this driver. These are:
> > * Disable pcie port clock on pci dirver instead of doing it in the phy
> >driver. The
Am 21.06.2019 um 13:04 schrieb Pavel Machek:
On Wed 2019-06-19 17:46:48, Lukas Schneider wrote:
This patch fixes the issue reported by checkpatch:
CHECK: usleep_range is preferred over udelay;
see Doucmentation/timers/timers-howto.txt
It's save to sleep here instead of using busy waiting,
be
Hi Sergio,
On 21/6/19 4:15 pm, Sergio Paracuellos wrote:
This patch series properly handle minor issues in this driver. These are:
* Disable pcie port clock on pci dirver instead of doing it in the phy
driver. The pci driver is the correct place to do this.
* Add a missing call to phy_exit fu
On Wed 2019-06-19 17:46:48, Lukas Schneider wrote:
> This patch fixes the issue reported by checkpatch:
>
> CHECK: usleep_range is preferred over udelay;
> see Doucmentation/timers/timers-howto.txt
>
> It's save to sleep here instead of using busy waiting,
> because we are not in an atomic contex
Hi Chao,
On 2019/6/21 17:46, Chao Yu wrote:
> On 2019/6/21 0:07, Gao Xiang wrote:
>> This patch adds a new generic decompression framework
>> in order to replace the old LZ4-specific decompression code.
>>
>> Even though LZ4 is still the only supported algorithm, yet
>> it is more cleaner and easy
On 2019/6/21 0:07, Gao Xiang wrote:
> This patch integrates new decompression framework to
> erofs decompression path, and remove the old
> decompression implementation as well.
>
> On kirin980 platform, sequential read is slightly
> improved to 778MiB/s after the new decompression
> backend is us
On 2019/6/21 0:07, Gao Xiang wrote:
> Decompressor needs to know whether it's a partial
> or full decompression since only full decompression
> can be decompressed in-place.
>
> On kirin980 platform, sequential read is finally
> increased to 812MiB/s after decompression inplace
> is enabled.
>
>
On 2019/6/21 0:07, Gao Xiang wrote:
> compressed data will be usually loaded into last pages of
> the extent (the last page for 4k) for in-place decompression
> (more specifically, in-place IO), as ilustration below,
>
> start of compressed logical extent
>|
On 2019/6/21 0:07, Gao Xiang wrote:
> This patch adds a new generic decompression framework
> in order to replace the old LZ4-specific decompression code.
>
> Even though LZ4 is still the only supported algorithm, yet
> it is more cleaner and easy to integrate new algorithm than
> the old almost h
Hi Chao,
On 2019/6/21 15:57, Chao Yu wrote:
> On 2019/6/21 0:07, Gao Xiang wrote:
>> +static inline void *erofs_get_pcpubuf(unsigned int pagenr)
>> +{
>> +return ERR_PTR(-ENOTSUPP);
>> +}
>
> [snip]
>
>> +percpu_data = erofs_get_pcpubuf(0);
>
> If erofs_get_pcpubuf may return error once
The following changes since commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a:
Linux 5.2-rc3 (2019-06-02 13:55:33 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-5.2-rc6
for you to fetch changes up to 9b9410766f5422
On 2019/6/21 15:53, Chao Yu wrote:
> On 2019/6/21 0:07, Gao Xiang wrote:
>> This patch aims at compacted compression indexes:
>> 1) cleanup z_erofs_map_blocks_iter and move into zmap.c;
>> 2) add compacted 4/2B decoding support.
>>
>> On kirin980 platform, sequential read is increased about
>>
Hi Chao,
On 2019/6/21 15:46, Chao Yu wrote:
> On 2019/6/21 0:07, Gao Xiang wrote:
>> This patch introduces new compacted compression indexes.
>>
>> In contract to legacy compression indexes that
>>each 4k logical cluster has an 8-byte index,
>> compacted ondisk compression indexes will have
>>
On 2019/6/21 0:07, Gao Xiang wrote:
> stagingpages are behaved as bounce pages for temporary use.
> Move to compress.h since the upcoming decompressor will
> allocate stagingpages as well.
>
> Signed-off-by: Gao Xiang
Reviewed-by: Chao Yu
Thanks,
___
On 2019/6/21 0:07, Gao Xiang wrote:
> +static inline void *erofs_get_pcpubuf(unsigned int pagenr)
> +{
> + return ERR_PTR(-ENOTSUPP);
> +}
[snip]
> + percpu_data = erofs_get_pcpubuf(0);
If erofs_get_pcpubuf may return error once EROFS_PCPUBUF_NR_PAGES equals to
zero, we'd better to check
On 2019/6/21 0:07, Gao Xiang wrote:
> This patch aims at compacted compression indexes:
> 1) cleanup z_erofs_map_blocks_iter and move into zmap.c;
> 2) add compacted 4/2B decoding support.
>
> On kirin980 platform, sequential read is increased about
> 6% (725MiB/s -> 770MiB/s) on enwik9 dataset
On 2019/6/21 0:07, Gao Xiang wrote:
> This patch introduces new compacted compression indexes.
>
> In contract to legacy compression indexes that
>each 4k logical cluster has an 8-byte index,
> compacted ondisk compression indexes will have
>amortized 2 bytes for each 4k logical cluster (c
when CRYPTO is m and KS7010 is y, building fails:
drivers/staging/ks7010/ks_hostif.o: In function `michael_mic.constprop.13':
ks_hostif.c:(.text+0x560): undefined reference to `crypto_alloc_shash'
ks_hostif.c:(.text+0x580): undefined reference to `crypto_shash_setkey'
ks_hostif.c:(.text+0x5e0): un
On Fri, Jun 21, 2019 at 11:42:21AM +0800, YueHaibing wrote:
> when CRYPTO is m and KS7010 is y, building fails:
>
> drivers/staging/ks7010/ks_hostif.o: In function `michael_mic.constprop.13':
> ks_hostif.c:(.text+0x560): undefined reference to `crypto_alloc_shash'
> ks_hostif.c:(.text+0x580): unde
33 matches
Mail list logo
