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
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
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
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: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.
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
Am 18.08.19 um 04:29 schrieb Chuanhong Guo:
> Hi!
>
> On Sun, Aug 18, 2019 at 2:06 AM Oleksij Rempel wrote:
SYSC_REG_CPLL_CLKCFG1 register is a clock gate controller. It is used to
enable or disable clocks.
Jist wild assumption. All peripheral devices are suing bus clock.
>>>
>>>
- 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
- 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
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:
>
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]
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
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: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
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.
>
- 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
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
/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: 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]
>
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
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
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
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 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,
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
/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 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:
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
On Sun, Aug 18, 2019 at 01:47:38AM -0400, Donald Yandt wrote:
> On Sun, Aug 18, 2019 at 1:03 AM Greg KH wrote:
> >
> > On Sat, Aug 17, 2019 at 05:37:58PM -0400, Donald Yandt wrote:
> > > This patch removes the todo for the ion chunk and
> > > carveout device tree bindings.
> > >
> > >
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
- 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():
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;
> >
> >
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
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
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
---
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.
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
>
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
>
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
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 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
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
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" ,
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:
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
> > >
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
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!
--
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
- 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
- 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" ,
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
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:
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.
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
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, );
+ if (unlikely(ret != 1) || !page) {
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
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
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
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
> > >
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
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
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
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.
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
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
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
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
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
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
70 matches
Mail list logo
