On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote:
> Not sure whether it can be sent in two patch sets?
> The first is to add the required APIs for ACRN driver.
> The second is to add the ACRN driver
One patchset adding the APIs and its user(s).
And make sure to refresh on
https://www.
Hi Joe,
On Sun, Aug 18, 2019 at 10:47:17PM -0700, Joe Perches wrote:
> On Mon, 2019-08-19 at 13:52 +0800, Gao Xiang wrote:
> > Hi Joe,
>
> Hello.
>
> > On Sun, Aug 18, 2019 at 10:28:41PM -0700, Joe Perches wrote:
> > > Rename errln, infoln, and debugln to the typical pr_ uses
> > > to the typica
On Mon, 2019-08-19 at 13:52 +0800, Gao Xiang wrote:
> Hi Joe,
Hello.
> On Sun, Aug 18, 2019 at 10:28:41PM -0700, Joe Perches wrote:
> > Rename errln, infoln, and debugln to the typical pr_ uses
> > to the typical kernel styles of pr_
>
> How about using erofs_err / ... to instead that?
I've n
On 2019年08月19日 13:25, Greg KH wrote:
On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote:
On 2019年08月16日 14:39, Borislav Petkov wrote:
On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote:
The first three patches are the changes under x86/acrn, which adds the
required APIs fo
Rename errln, infoln, and debugln to the typical pr_ uses
to the typical kernel styles of pr_
Miscellanea:
o Add newline terminations to the uses
o Use "%s: ...", __func__ and not the atypical "%s, ...", __func__
o Trivial grammar changes in output logging
o Delete the now unused macros
Signed-o
On 2019年08月16日 20:58, Dan Carpenter wrote:
On Fri, Aug 16, 2019 at 10:25:49AM +0800, Zhao Yakui wrote:
+int hugepage_map_guest(struct acrn_vm *vm, struct vm_memmap *memmap)
+{
+ struct page *page = NULL, *regions_buf_pg = NULL;
+ unsigned long len, guest_gpa, vma;
+ struct vm
Hi Joe,
On Sun, Aug 18, 2019 at 10:28:41PM -0700, Joe Perches wrote:
> Rename errln, infoln, and debugln to the typical pr_ uses
> to the typical kernel styles of pr_
How about using erofs_err / ... to instead that?
- I can hardly see directly use pr_ for those filesystems in fs/...
- maybe we
On Mon, Aug 19, 2019 at 12:02:33PM +0800, Zhao, Yakui wrote:
>
>
> On 2019年08月16日 15:05, Greg KH wrote:
> > On Fri, Aug 16, 2019 at 10:25:45AM +0800, Zhao Yakui wrote:
> > > ACRN hypervisor service module is the important middle layer that allows
> > > the Linux kernel to communicate with the ACR
On Mon, Aug 19, 2019 at 10:39:32AM +0800, Zhao, Yakui wrote:
>
>
> On 2019年08月16日 15:03, Greg KH wrote:
> > On Fri, Aug 16, 2019 at 08:39:25AM +0200, Borislav Petkov wrote:
> > > On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote:
> > > > The first three patches are the changes under x86/
On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote:
>
>
> On 2019年08月16日 14:39, Borislav Petkov wrote:
> > On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote:
> > > The first three patches are the changes under x86/acrn, which adds the
> > > required APIs for the driver and repor
On 2019年08月16日 21:12, Dan Carpenter wrote:
On Fri, Aug 16, 2019 at 10:25:51AM +0800, Zhao Yakui wrote:
+ case IC_VM_INTR_MONITOR: {
+ struct page *page;
+
+ ret = get_user_pages_fast(ioctl_param, 1, 1, &page);
+ if (unlikely(ret != 1) || !page) {
On 2019年08月16日 21:39, Dan Carpenter wrote:
On Fri, Aug 16, 2019 at 10:25:52AM +0800, Zhao Yakui wrote:
+int acrn_ioreq_create_client(unsigned short vmid,
+ioreq_handler_t handler,
+void *client_priv,
+char *nam
Hi Hans,
On Thu, Jul 25, 2019 at 8:50 PM Boris Brezillon
wrote:
>
> On Thu, 25 Jul 2019 08:36:02 +0530
> Hariprasad Kelam wrote:
>
> > fix below issue reported by coccicheck
> > /drivers/staging/media/hantro/hantro_vp8.c:149:16-34: WARNING:
> > dma_alloc_coherent use in aux_buf -> cpu already ze
On Mon, Aug 19, 2019 at 1:17 PM Tomasz Figa wrote:
>
> Hi Hans,
>
> On Thu, Jul 25, 2019 at 8:50 PM Boris Brezillon
> wrote:
> >
> > On Thu, 25 Jul 2019 08:36:02 +0530
> > Hariprasad Kelam wrote:
> >
> > > fix below issue reported by coccicheck
> > > /drivers/staging/media/hantro/hantro_vp8.c:14
On 2019年08月16日 15:05, Greg KH wrote:
On Fri, Aug 16, 2019 at 10:25:45AM +0800, Zhao Yakui wrote:
ACRN hypervisor service module is the important middle layer that allows
the Linux kernel to communicate with the ACRN hypervisor. It includes
the management of virtualized CPU/memory/device/interr
On 2019年08月16日 15:03, Greg KH wrote:
On Fri, Aug 16, 2019 at 08:39:25AM +0200, Borislav Petkov wrote:
On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote:
The first three patches are the changes under x86/acrn, which adds the
required APIs for the driver and reports the X2APIC caps.
Th
On 2019年08月16日 14:39, Borislav Petkov wrote:
On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote:
The first three patches are the changes under x86/acrn, which adds the
required APIs for the driver and reports the X2APIC caps.
The remaining patches add the ACRN driver module, which acce
On 8/14/19 2:25 AM, Russell King - ARM Linux admin wrote:
I just did this:
rmmod imx-media
modprobe imx-media
and was greeted by the below kernel messages.
Yes this needs fixing, the CSI needs to check first that it is already
registered before going through the ->registered() steps. Posti
Hi all,
On Mon, Aug 19, 2019 at 02:16:55AM +0800, Gao Xiang wrote:
> Hi Hch,
>
> On Sun, Aug 18, 2019 at 10:47:02AM -0700, Christoph Hellwig wrote:
> > On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote:
> > > Not sure what you're even disagreeing with, as I *do* expect new
> > > files
On Wed, 14 Aug 2019 06:56:18 +
"Ardelean, Alexandru" wrote:
> On Tue, 2019-08-13 at 16:31 -0300, Rodrigo Ribeiro wrote:
> > [External]
> >
> > Replace shift and minus operation by GENMASK macro and remove the local
> > variables used to store intermediate data.
> >
>
> Reviewed-by: Alexa
From: Colin Ian King
Variable retval is initialized to a value that is never read and it
is re-assigned later. The initialization is redundant and can be
removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/staging/rts5208/ms.c | 2 +-
1 file changed, 1 inser
Hi Richard,
On Sun, Aug 18, 2019 at 08:00:28PM +0200, Richard Weinberger wrote:
> - Ursprüngliche Mail -
> > Von: "tytso"
> > An: "richard"
> > CC: "Greg Kroah-Hartman" , "Gao Xiang"
> > , "Jan Kara" , "Chao
> > Yu" , "Dave Chinner" , "David
> > Sterba" , "Miao Xie"
> > , "devel" , "St
This patch fixes the following sparse warnings:
kpc2000_i2c.c:137: warning: incorrect type in argument 1
(different address spaces)
kpc2000_i2c.c:137:expected void const volatile [noderef] *addr
kpc2000_i2c.c:137:got void *
kpc2000_i2c.c:146: warning: in
Hi Hch,
On Sun, Aug 18, 2019 at 10:47:02AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote:
> > Not sure what you're even disagreeing with, as I *do* expect new
> > filesystems to
> > be held to a high standard, and to be written with the assumption
- Ursprüngliche Mail -
> Von: "tytso"
> An: "richard"
> CC: "Greg Kroah-Hartman" , "Gao Xiang"
> , "Jan Kara" , "Chao
> Yu" , "Dave Chinner" , "David
> Sterba" , "Miao Xie"
> , "devel" , "Stephen
> Rothwell" , "Darrick"
> , "Christoph Hellwig" , "Amir
> Goldstein" ,
> "linux-erofs" ,
On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote:
> Not sure what you're even disagreeing with, as I *do* expect new filesystems
> to
> be held to a high standard, and to be written with the assumption that the
> on-disk data may be corrupted or malicious. We just can't expect the bar
On Sun, Aug 18, 2019 at 07:06:40PM +0200, Richard Weinberger wrote:
> > So holding a file system like EROFS to a higher standard than say,
> > ext4, xfs, or btrfs hardly seems fair.
>
> Nobody claimed that.
Pointing out that erofs has issues in this area when Gao Xiang is
asking if erofs can be m
On Sun, Aug 18, 2019 at 08:58:12AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> > Note that of the mainstream file systems, ext4 and xfs don't guarantee
> > that it's safe to blindly take maliciously provided file systems, such
> > as those p
On Sun, Aug 18, 2019 at 09:22:01AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote:
> > Ted's observation was about maliciously-crafted filesystems, though, so
> > integrity-only features such as metadata checksums are irrelevant. Also the
> > filesys
- Ursprüngliche Mail -
> So holding a file system like EROFS to a higher standard than say,
> ext4, xfs, or btrfs hardly seems fair.
Nobody claimed that.
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linu
The pull request you sent on Sun, 18 Aug 2019 10:57:12 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> tags/staging-5.3-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ae1a616af36e5ad0726407b76feed5060a424744
Thank you!
--
Deet-doot-d
Hi Hch,
On Sun, Aug 18, 2019 at 09:22:01AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote:
> > Ted's observation was about maliciously-crafted filesystems, though, so
> > integrity-only features such as metadata checksums are irrelevant. Also the
>
On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote:
> Ted's observation was about maliciously-crafted filesystems, though, so
> integrity-only features such as metadata checksums are irrelevant. Also the
> filesystem version is irrelevant; anything accepted by the kernel code (even
> if
On Sun, Aug 18, 2019 at 08:58:12AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> > Note that of the mainstream file systems, ext4 and xfs don't guarantee
> > that it's safe to blindly take maliciously provided file systems, such
> > as those p
Hi Ted,
On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> On Sun, Aug 18, 2019 at 11:21:13AM +0200, Richard Weinberger wrote:
> > > Not to say that erofs shouldn't be worked on to fix these kinds of
> > > issues, just that it's not an unheard of thing to trust the disk image.
> >
On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> Note that of the mainstream file systems, ext4 and xfs don't guarantee
> that it's safe to blindly take maliciously provided file systems, such
> as those provided by a untrusted container, and mount it on a file
> system without p
Commit 23a4388f24f5 ("staging: android: ion: Remove file ion_chunk_heap.c")
and eadbf7a34e44 ("staging: android: ion: Remove file ion_carveout_heap.c")
removed the chunk and carveout heaps from ion but left behind the device
tree bindings for them in the TODO, this patch removes it.
Signed-off-by:
On Sun, Aug 18, 2019 at 11:21:13AM +0200, Richard Weinberger wrote:
> > Not to say that erofs shouldn't be worked on to fix these kinds of
> > issues, just that it's not an unheard of thing to trust the disk image.
> > Especially for the normal usage model of erofs, where the whole disk
> > image i
Choose a better name for the include hearder guard used in rtl871x_io.h.
'_IO_H_' is to generic and does not match the comment after the #endif.
Use '_RTL871X_IO_H_' instead.
Also make the comments in the #endif /* XXX */ match the name used in
#ifndef.
Signed-off-by: Christophe JAILLET
---
__RT
us a note to
> help improve the system]
... those patches should be applied to staging tree
since linux-next has not been updated yet...
Thanks,
Gao Xiang
>
> url:
> https://github.com/0day-ci/linux/commits/Gao-Xiang/staging-erofs-fix-an-error-handling-in-erofs_readdi
/staging-erofs-fix-an-error-handling-in-erofs_readdir/20190818-191344
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin
On 2019-8-18 18:28, Gao Xiang wrote:
> From: Gao Xiang
>
> As Richard reminder [1], A valid volume name should be
> ended in NIL terminator within the length of volume_name.
>
> Since this field currently isn't really used, let's fix
> it to avoid potential bugs in the future.
>
> [1]
> https:
From: Gao Xiang
Richard observed a forever loop of erofs_read_raw_page() [1]
which can be generated by forcely setting ->u.i_blkaddr
to 0xdeadbeef (as my understanding block layer can
handle access beyond end of device correctly).
After digging into that, it seems the problem is highly
related w
On Sun, Aug 18, 2019 at 05:33:14AM -0700, Matthew Wilcox wrote:
> On Sun, Aug 18, 2019 at 11:21:11AM +0800, Gao Xiang wrote:
> > + if (dentry_page == ERR_PTR(-ENOMEM)) {
> > + errln("no memory to readdir of logical block %u of nid
> > %llu",
> > +
On Sun, Aug 18, 2019 at 11:21:11AM +0800, Gao Xiang wrote:
> + if (dentry_page == ERR_PTR(-ENOMEM)) {
> + errln("no memory to readdir of logical block %u of nid
> %llu",
> + i, EROFS_V(dir)->nid);
I don't think you need the error message.
On 2019-8-18 11:21, Gao Xiang wrote:
> From: Gao Xiang
>
> Richard observed a forever loop of erofs_read_raw_page() [1]
> which can be generated by forcely setting ->u.i_blkaddr
> to 0xdeadbeef (as my understanding block layer can
> handle access beyond end of device correctly).
>
> After diggin
Hi Xiang,
On 2019-8-18 18:52, Gao Xiang wrote:
> Hi Chao,
>
> On Sun, Aug 18, 2019 at 06:39:52PM +0800, Chao Yu wrote:
>> On 2019-8-18 10:53, Matthew Wilcox wrote:
>>> On Sun, Aug 18, 2019 at 10:32:45AM +0800, Gao Xiang wrote:
On Sat, Aug 17, 2019 at 07:20:55PM -0700, Matthew Wilcox wrote:
>
/staging-erofs-refuse-to-mount-images-with-malformed-volume-name/20190818-193037
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
/staging-erofs-fix-an-error-handling-in-erofs_readdir/20190818-191344
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin
Hi Chao,
On Sun, Aug 18, 2019 at 06:39:52PM +0800, Chao Yu wrote:
> On 2019-8-18 10:53, Matthew Wilcox wrote:
> > On Sun, Aug 18, 2019 at 10:32:45AM +0800, Gao Xiang wrote:
> >> On Sat, Aug 17, 2019 at 07:20:55PM -0700, Matthew Wilcox wrote:
> >>> On Sun, Aug 18, 2019 at 09:56:31AM +0800, Gao Xian
On 2019-8-18 10:53, Matthew Wilcox wrote:
> On Sun, Aug 18, 2019 at 10:32:45AM +0800, Gao Xiang wrote:
>> On Sat, Aug 17, 2019 at 07:20:55PM -0700, Matthew Wilcox wrote:
>>> On Sun, Aug 18, 2019 at 09:56:31AM +0800, Gao Xiang wrote:
@@ -82,8 +82,12 @@ static int erofs_readdir(struct file *f, s
From: Gao Xiang
As Richard reminder [1], A valid volume name should be
ended in NIL terminator within the length of volume_name.
Since this field currently isn't really used, let's fix
it to avoid potential bugs in the future.
[1]
https://lore.kernel.org/r/1133002215.69049.1566119033047.javama
Hi Richard,
On 2019-8-18 17:21, Richard Weinberger wrote:
> For normal use I see no problem at all.
> I fear distros that try to mount anything you plug into your USB.
>
> At least SUSE already blacklists erofs:
> https://github.com/openSUSE/suse-module-tools/blob/master/suse-module-tools.spec#L2
Hi!
On Sun, Aug 18, 2019 at 5:51 PM Oleksij Rempel wrote:
>
> lets see more code:
> drivers/staging/mt7621-mmc/sd.c
> /* clock source for host: global */
> #if defined(CONFIG_SOC_MT7620)
> static u32 hclks[] = {4800}; /* +/- by chhung */
> #elif defined(CONFIG_SOC_MT7621)
> static u32 hclks[]
Am 18.08.19 um 10:44 schrieb Chuanhong Guo:
> On Sun, Aug 18, 2019 at 4:26 PM Chuanhong Guo wrote:
>>
>> Hi!
>>
>> On Sun, Aug 18, 2019 at 3:59 PM Oleksij Rempel
>> wrote:
>>>
>>> Am 18.08.19 um 09:19 schrieb Chuanhong Guo:
Hi!
On Sun, Aug 18, 2019 at 2:10 PM Oleksij Rempel
On Sun, Aug 18, 2019 at 11:03:53AM +0200, Richard Weinberger wrote:
> - Urspr??ngliche Mail -
> > I agree with you, but what can we do now is trying our best to fuzz
> > all the fields.
> >
> > So, what is your opinion about EROFS?
>
> All I'm saying is that you should not blindly trust t
- Ursprüngliche Mail -
> You have looked at reiserfs lately, right? :)
Don't remind me of that. ;-)
> Not to say that erofs shouldn't be worked on to fix these kinds of
> issues, just that it's not an unheard of thing to trust the disk image.
> Especially for the normal usage model of e
On Sun, Aug 18, 2019 at 05:10:38PM +0800, Gao Xiang via Linux-erofs wrote:
> Hi Richard,
>
> On Sun, Aug 18, 2019 at 10:33:33AM +0200, Richard Weinberger wrote:
> > - Urspr?ngliche Mail -
> > > changelog from v2:
> > > - transform EIO to EFSCORRUPTED as suggested by Matthew;
> >
> > erofs
Hi Richard,
On Sun, Aug 18, 2019 at 10:33:33AM +0200, Richard Weinberger wrote:
> - Urspr?ngliche Mail -
> > changelog from v2:
> > - transform EIO to EFSCORRUPTED as suggested by Matthew;
>
> erofs does not define EFSCORRUPTED, so the build fails.
> At least on Linus' tree as of today.
On Sun, Aug 18, 2019 at 11:03:53AM +0200, Richard Weinberger wrote:
> - Ursprüngliche Mail -
> > I agree with you, but what can we do now is trying our best to fuzz
> > all the fields.
> >
> > So, what is your opinion about EROFS?
>
> All I'm saying is that you should not blindly trust th
- Ursprüngliche Mail -
> I agree with you, but what can we do now is trying our best to fuzz
> all the fields.
>
> So, what is your opinion about EROFS?
All I'm saying is that you should not blindly trust the disk.
Another thing that raises my attention is in superblock_read():
m
The following changes since commit d45331b00ddb179e291766617259261c112db872:
Linux 5.3-rc4 (2019-08-11 13:26:41 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-5.3-rc5
for you to fetch changes up to 48b30e10bfc20e
On Sun, Aug 18, 2019 at 10:16:50AM +0200, Richard Weinberger wrote:
> - Urspr?ngliche Mail -
> >> While digging a little into the code I noticed that you have very few
> >> checks of the on-disk data.
> >> For example ->u.i_blkaddr. I gave it a try and created a
> >> malformed filesystem wh
On Sun, Aug 18, 2019 at 4:26 PM Chuanhong Guo wrote:
>
> Hi!
>
> On Sun, Aug 18, 2019 at 3:59 PM Oleksij Rempel wrote:
> >
> > Am 18.08.19 um 09:19 schrieb Chuanhong Guo:
> > > Hi!
> > >
> > > On Sun, Aug 18, 2019 at 2:10 PM Oleksij Rempel
> > > wrote:
> > >>
> > We have at least 2 know re
- Ursprüngliche Mail -
> changelog from v2:
> - transform EIO to EFSCORRUPTED as suggested by Matthew;
erofs does not define EFSCORRUPTED, so the build fails.
At least on Linus' tree as of today.
Thanks,
//richard
___
devel mailing list
de...@li
Hi!
On Sun, Aug 18, 2019 at 3:59 PM Oleksij Rempel wrote:
>
> Am 18.08.19 um 09:19 schrieb Chuanhong Guo:
> > Hi!
> >
> > On Sun, Aug 18, 2019 at 2:10 PM Oleksij Rempel
> > wrote:
> >>
> We have at least 2 know registers:
> SYSC_REG_CPLL_CLKCFG0 - it provides some information about bo
- Ursprüngliche Mail -
>> While digging a little into the code I noticed that you have very few
>> checks of the on-disk data.
>> For example ->u.i_blkaddr. I gave it a try and created a
>> malformed filesystem where u.i_blkaddr is 0xdeadbeef, it causes the kernel
>> to loop forever around
Am 18.08.19 um 09:19 schrieb Chuanhong Guo:
> Hi!
>
> On Sun, Aug 18, 2019 at 2:10 PM Oleksij Rempel wrote:
>>
We have at least 2 know registers:
SYSC_REG_CPLL_CLKCFG0 - it provides some information about boostrapped
refclock. PLL and dividers used for CPU and some sort of BUS (AHB?
Hi!
On Sun, Aug 18, 2019 at 2:10 PM Oleksij Rempel wrote:
>
> >> We have at least 2 know registers:
> >> SYSC_REG_CPLL_CLKCFG0 - it provides some information about boostrapped
> >> refclock. PLL and dividers used for CPU and some sort of BUS (AHB?).
> >> SYSC_REG_CPLL_CLKCFG1 - a banch of gates t
69 matches
Mail list logo