Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-05 Thread Artem Bityutskiy
On Mon, 2016-12-05 at 09:23 +0100, Boris Brezillon wrote: > I started to implement that too but unfortunately never had the time > to > finish it :-(. > Don't know why you were trying to move to kzalloc-ed buffer, but my > goal was to avoid the extra copy when the controller transfers data > using

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-05 Thread Artem Bityutskiy
On Mon, 2016-12-05 at 09:23 +0100, Boris Brezillon wrote: > I started to implement that too but unfortunately never had the time > to > finish it :-(. > Don't know why you were trying to move to kzalloc-ed buffer, but my > goal was to avoid the extra copy when the controller transfers data > using

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-05 Thread Boris Brezillon
On Mon, 05 Dec 2016 09:09:34 +0200 Artem Bityutskiy wrote: > On Sun, 2016-12-04 at 21:52 +0100, Richard Weinberger wrote: > > We should better think about how to get ubi_self_check_all_ff() > > fixed. > > When enabled on a modern NAND, vmalloc() is likely to fail now and > >

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-05 Thread Boris Brezillon
On Mon, 05 Dec 2016 09:09:34 +0200 Artem Bityutskiy wrote: > On Sun, 2016-12-04 at 21:52 +0100, Richard Weinberger wrote: > > We should better think about how to get ubi_self_check_all_ff() > > fixed. > > When enabled on a modern NAND, vmalloc() is likely to fail now and > > then > > since len

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Artem Bityutskiy
On Sun, 2016-12-04 at 21:52 +0100, Richard Weinberger wrote: > We should better think about how to get ubi_self_check_all_ff() > fixed. > When enabled on a modern NAND, vmalloc() is likely to fail now and > then > since len is the erase block size and can be up to a few mega bytes. I did an

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Artem Bityutskiy
On Sun, 2016-12-04 at 21:52 +0100, Richard Weinberger wrote: > We should better think about how to get ubi_self_check_all_ff() > fixed. > When enabled on a modern NAND, vmalloc() is likely to fail now and > then > since len is the erase block size and can be up to a few mega bytes. I did an

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Marek Vasut
On 12/04/2016 09:33 PM, Joe Perches wrote: > On Sun, 2016-12-04 at 13:48 +0100, Marek Vasut wrote: >> On 12/04/2016 07:12 AM, Pan Bian wrote: >>> From: Pan Bian >>> >>> When __vmalloc() returns a NULL pointer, the region is not checked, and >>> we cannot make sure that only

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Marek Vasut
On 12/04/2016 09:33 PM, Joe Perches wrote: > On Sun, 2016-12-04 at 13:48 +0100, Marek Vasut wrote: >> On 12/04/2016 07:12 AM, Pan Bian wrote: >>> From: Pan Bian >>> >>> When __vmalloc() returns a NULL pointer, the region is not checked, and >>> we cannot make sure that only 0xFF bytes are present

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Richard Weinberger
On 04.12.2016 21:33, Joe Perches wrote: >>> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c > [] >>> @@ -1413,7 +1413,7 @@ int ubi_self_check_all_ff(struct ubi_device *ubi, int >>> pnum, int offset, int len) >>> buf = __vmalloc(len, GFP_NOFS, PAGE_KERNEL); >>> if (!buf) { >>>

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Richard Weinberger
On 04.12.2016 21:33, Joe Perches wrote: >>> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c > [] >>> @@ -1413,7 +1413,7 @@ int ubi_self_check_all_ff(struct ubi_device *ubi, int >>> pnum, int offset, int len) >>> buf = __vmalloc(len, GFP_NOFS, PAGE_KERNEL); >>> if (!buf) { >>>

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Joe Perches
On Sun, 2016-12-04 at 13:48 +0100, Marek Vasut wrote: > On 12/04/2016 07:12 AM, Pan Bian wrote: > > From: Pan Bian > > > > When __vmalloc() returns a NULL pointer, the region is not checked, and > > we cannot make sure that only 0xFF bytes are present at offset. Thus, > >

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Joe Perches
On Sun, 2016-12-04 at 13:48 +0100, Marek Vasut wrote: > On 12/04/2016 07:12 AM, Pan Bian wrote: > > From: Pan Bian > > > > When __vmalloc() returns a NULL pointer, the region is not checked, and > > we cannot make sure that only 0xFF bytes are present at offset. Thus, > > returning 0 seems

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Marek Vasut
On 12/04/2016 07:12 AM, Pan Bian wrote: > From: Pan Bian > > When __vmalloc() returns a NULL pointer, the region is not checked, and > we cannot make sure that only 0xFF bytes are present at offset. Thus, > returning 0 seems improper. > > Bugzilla:

Re: [PATCH 1/1] mtd: ubi: fix improper return value

2016-12-04 Thread Marek Vasut
On 12/04/2016 07:12 AM, Pan Bian wrote: > From: Pan Bian > > When __vmalloc() returns a NULL pointer, the region is not checked, and > we cannot make sure that only 0xFF bytes are present at offset. Thus, > returning 0 seems improper. > > Bugzilla:

[PATCH 1/1] mtd: ubi: fix improper return value

2016-12-03 Thread Pan Bian
From: Pan Bian When __vmalloc() returns a NULL pointer, the region is not checked, and we cannot make sure that only 0xFF bytes are present at offset. Thus, returning 0 seems improper. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189081 Signed-off-by: Pan Bian

[PATCH 1/1] mtd: ubi: fix improper return value

2016-12-03 Thread Pan Bian
From: Pan Bian When __vmalloc() returns a NULL pointer, the region is not checked, and we cannot make sure that only 0xFF bytes are present at offset. Thus, returning 0 seems improper. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189081 Signed-off-by: Pan Bian ---