Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon wrote: > - shmulik.ladk...@gmail.com wrote: > > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon > > wrote: > > > > > > I still think that default behavior should be to zero skb->mark

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon wrote: > - shmulik.ladk...@gmail.com wrote: > > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon > > wrote: > > > > > > I still think that default behavior should be to zero skb->mark only > > when skb > > > cross netdevs in

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon wrote: > > I still think that default behavior should be to zero skb->mark only when skb > cross netdevs in different netns. But the previous default was scrub the mark in *both* xnet and non-xnet situations.

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon wrote: > > I still think that default behavior should be to zero skb->mark only when skb > cross netdevs in different netns. But the previous default was scrub the mark in *both* xnet and non-xnet situations. Therefore, there might be users

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Thu, 15 Mar 2018 16:13:39 +0100 Daniel Borkmann <dan...@iogearbox.net> wrote: > On 03/15/2018 01:50 PM, Shmulik Ladkani wrote: > > > > It would be beneficial to have the mark preserved when skb is injected > > to the slave device's rx path (especially when it's on th

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Thu, 15 Mar 2018 16:13:39 +0100 Daniel Borkmann wrote: > On 03/15/2018 01:50 PM, Shmulik Ladkani wrote: > > > > It would be beneficial to have the mark preserved when skb is injected > > to the slave device's rx path (especially when it's on the same netns). > &g

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

Hi, On Thu, 15 Mar 2018 12:56:13 +0100 Daniel Borkmann <dan...@iogearbox.net> wrote: > On 03/15/2018 10:21 AM, Shmulik Ladkani wrote: > > > > Regarding veth xmit, it does makes sense to preserve the fields if not > > crossing netns. This is also the c

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

Hi, On Thu, 15 Mar 2018 12:56:13 +0100 Daniel Borkmann wrote: > On 03/15/2018 10:21 AM, Shmulik Ladkani wrote: > > > > Regarding veth xmit, it does makes sense to preserve the fields if not > > crossing netns. This is also the case when one uses tc mirred. > > >

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

Hi, On Tue, 13 Mar 2018 17:07:22 +0200 Liran Alon wrote: > Before this commit, dev_forward_skb() always cleared packet's > per-network-namespace info. Even if the packet doesn't cross > network namespaces. > > The comment above dev_forward_skb() describes that this is

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

Hi, On Tue, 13 Mar 2018 17:07:22 +0200 Liran Alon wrote: > Before this commit, dev_forward_skb() always cleared packet's > per-network-namespace info. Even if the packet doesn't cross > network namespaces. > > The comment above dev_forward_skb() describes that this is done > because the

Re: [PATCH 4.4 10/34] net/sched: act_vlan: Push skb->data to mac_header prior calling skb_vlan_*() functions

On Sun, 13 Nov 2016 12:24:42 +0100 Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > Looks ok, thanks. Reviewed-by: Shmulik Ladkani <shmulik.ladk...@gmail.com>

Re: [PATCH 4.4 10/34] net/sched: act_vlan: Push skb->data to mac_header prior calling skb_vlan_*() functions

On Sun, 13 Nov 2016 12:24:42 +0100 Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > Looks ok, thanks. Reviewed-by: Shmulik Ladkani

Re: [PATCH 1/2] tun: Use memdup_user() rather than duplicating its implementation

> duplicate source code. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> Reviewed-by: Shmulik Ladkani <shmulik.ladk...@gmail.com>

Re: [PATCH 1/2] tun: Use memdup_user() rather than duplicating its implementation

e Coccinelle software. > > Signed-off-by: Markus Elfring Reviewed-by: Shmulik Ladkani

Re: [RFC/PATCH] ubi: Replace wear leveling thread with a workqueue

Hi Ezequiel, On Fri, 23 Nov 2012 09:13:29 -0300 Ezequiel Garcia wrote: > /** > - * ubi_thread - UBI background thread. > + * ubi_wl_do_work - UBI background wl worker function. > * @u: the UBI device description object pointer > */ > -int ubi_thread(void *u) > +void ubi_wl_do_work(struct

Re: [RFC/PATCH] ubi: Replace wear leveling thread with a workqueue

Hi Ezequiel, On Fri, 23 Nov 2012 09:13:29 -0300 Ezequiel Garcia elezegar...@gmail.com wrote: /** - * ubi_thread - UBI background thread. + * ubi_wl_do_work - UBI background wl worker function. * @u: the UBI device description object pointer */ -int ubi_thread(void *u) +void

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs

On Wed, 29 Aug 2012 11:16:05 +0300 Artem Bityutskiy wrote: > On Sun, 2012-08-26 at 09:06 +0300, Shmulik Ladkani wrote: > > root100m@0 > > kernel 100m@100m > > rootfs 800m@200m (truncated) > > user0@1g (truncated) > > rest0@1g &

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs

On Wed, 29 Aug 2012 11:16:05 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: On Sun, 2012-08-26 at 09:06 +0300, Shmulik Ladkani wrote: root100m@0 kernel 100m@100m rootfs 800m@200m (truncated) user0@1g (truncated) rest0@1g Who would benefit from

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs

Hi, On Sat, 25 Aug 2012 05:26:51 -0400 Huang Shijie wrote: > On Sat, Aug 25, 2012 at 5:02 AM, Shmulik Ladkani > wrote: > > Your analysis seems right, but let me offer an alternative approach. > > > > I would simply: > > > > -

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs

Hi, On Sat, 25 Aug 2012 05:26:51 -0400 Huang Shijie shij...@gmail.com wrote: On Sat, Aug 25, 2012 at 5:02 AM, Shmulik Ladkani shmulik.ladk...@gmail.com wrote: Your analysis seems right, but let me offer an alternative approach. I would simply

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs

On Sat, 25 Aug 2012 05:26:51 -0400 Huang Shijie wrote: > > The specified cmdline partitions might not be ordered (according to > > start offset), so next partition specified after the truncated one might > > define a partition at the beginning of the device, which is okay > > (regardless the

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong check condition

Hi Huang, Artem, On Sat, 25 Aug 2012 16:06:50 -0400 Huang Shijie wrote: > diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c > index fc960a3..216d751 100644 > --- a/drivers/mtd/cmdlinepart.c > +++ b/drivers/mtd/cmdlinepart.c > @@ -322,13 +322,16 @@ static int

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs

Hi Huang, On Sat, 25 Aug 2012 10:26:07 -0400 Huang Shijie wrote: > diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c > index 4558e0f..fc960a3 100644 > --- a/drivers/mtd/cmdlinepart.c > +++ b/drivers/mtd/cmdlinepart.c > @@ -344,7 +344,8 @@ static int

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs

Hi Huang, On Sat, 25 Aug 2012 10:26:07 -0400 Huang Shijie shij...@gmail.com wrote: diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c index 4558e0f..fc960a3 100644 --- a/drivers/mtd/cmdlinepart.c +++ b/drivers/mtd/cmdlinepart.c @@ -344,7 +344,8 @@ static int

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong check condition

Hi Huang, Artem, On Sat, 25 Aug 2012 16:06:50 -0400 Huang Shijie shij...@gmail.com wrote: diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c index fc960a3..216d751 100644 --- a/drivers/mtd/cmdlinepart.c +++ b/drivers/mtd/cmdlinepart.c @@ -322,13 +322,16 @@ static int

Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs

On Sat, 25 Aug 2012 05:26:51 -0400 Huang Shijie shij...@gmail.com wrote: The specified cmdline partitions might not be ordered (according to start offset), so next partition specified after the truncated one might define a partition at the beginning of the device, which is okay (regardless

Re: [PATCH 6/8] UBI: replace MTD_UBI_BEB_LIMIT with module parameter

Hi Richard, On Fri, 17 Aug 2012 16:35:22 +0200 Richard Genoud wrote: > + "MTD devices may be specified by their number, name, or > path to the MTD character device node.\n" > + "Optional \"vid_hdr_offs\" parameter specifies UBI VID > header position to be

Re: [PATCH 5/8] UBI: check max_beb_per1024 value in ubi_attach_mtd_dev

Hi Richard, On Fri, 17 Aug 2012 16:35:21 +0200 Richard Genoud wrote: > + /* > + * A value of 0 is forced to the default value to keep the same > + * behavior between ubiattach command and module parameter > + */ Minor thing. Since the module parameter is not yet introduced

Re: [PATCH 4/8] UBI: prepare for max_beb_per1024 module parameter addition

On Fri, 17 Aug 2012 16:35:20 +0200 Richard Genoud wrote: > This patch prepare the way for the addition of max_beb_per1024 module > parameter. > There's no functional change. > > Signed-off-by: Richard Genoud Reviewed-by: Shmulik Ladkani -- To unsubscribe from this list

Re: [PATCH 2/8] UBI: separate bad_peb_limit in a function

On Fri, 17 Aug 2012 16:35:18 +0200 Richard Genoud wrote: > No functional changes here, just to prepare for next patch. > > Signed-off-by: Richard Genoud Reviewed-by: Shmulik Ladkani -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter

On Thu, 16 Aug 2012 16:33:32 +0300 Artem Bityutskiy wrote: > We do not have that big user-base. No one uses 0 in the tree, most use > the default. I never heard anyone using 0. I did not use it also. I > think it is OK to have the lower range start from non-zero. But why it > is 2 and not 1 - I

Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter

On Thu, 16 Aug 2012 16:33:32 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: We do not have that big user-base. No one uses 0 in the tree, most use the default. I never heard anyone using 0. I did not use it also. I think it is OK to have the lower range start from non-zero. But why it is 2

Re: [PATCH 2/8] UBI: separate bad_peb_limit in a function

On Fri, 17 Aug 2012 16:35:18 +0200 Richard Genoud richard.gen...@gmail.com wrote: No functional changes here, just to prepare for next patch. Signed-off-by: Richard Genoud richard.gen...@gmail.com Reviewed-by: Shmulik Ladkani shmulik.ladk...@gmail.com -- To unsubscribe from this list: send

Re: [PATCH 4/8] UBI: prepare for max_beb_per1024 module parameter addition

On Fri, 17 Aug 2012 16:35:20 +0200 Richard Genoud richard.gen...@gmail.com wrote: This patch prepare the way for the addition of max_beb_per1024 module parameter. There's no functional change. Signed-off-by: Richard Genoud richard.gen...@gmail.com Reviewed-by: Shmulik Ladkani shmulik.ladk

Re: [PATCH 5/8] UBI: check max_beb_per1024 value in ubi_attach_mtd_dev

Hi Richard, On Fri, 17 Aug 2012 16:35:21 +0200 Richard Genoud richard.gen...@gmail.com wrote: + /* + * A value of 0 is forced to the default value to keep the same + * behavior between ubiattach command and module parameter + */ Minor thing. Since the module parameter is

Re: [PATCH 6/8] UBI: replace MTD_UBI_BEB_LIMIT with module parameter

Hi Richard, On Fri, 17 Aug 2012 16:35:22 +0200 Richard Genoud richard.gen...@gmail.com wrote: + MTD devices may be specified by their number, name, or path to the MTD character device node.\n + Optional \vid_hdr_offs\ parameter specifies UBI VID header

Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter

On Thu, 16 Aug 2012 16:28:38 +0300 Artem Bityutskiy wrote: > On Thu, 2012-08-16 at 11:57 +0300, Shmulik Ladkani wrote: > > > > For the simplest systems (those having one ubi device) that need a > > limit > > *other* than the default (20 per 1024), the

Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter

Hi Richard, Artem, On Thu, 16 Aug 2012 12:07:01 +0200 Richard Genoud wrote: > > With you approach, these system MUST pass the limit parameter via the > > ioctl / module-parameter. > That's right. > We can add a kernel config option to change the max_beb_per1024 > default value (actually, this

Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter

Hi Richard, Sorry for reviewing this late... On Tue, 10 Jul 2012 18:23:42 +0200 Richard Genoud wrote: > -config MTD_UBI_BEB_LIMIT > - int "Maximum expected bad eraseblocks per 1024 eraseblocks" > - default 20 > - range 2 256 I see some benefit keeping the config. For the simplest

Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit

Hi, One more thing... On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy wrote: > config MTD_UBI_BEB_LIMIT > - int "Percentage of maximum expected bad eraseblocks" > - default 2 > - range 0 25 > + int "Maximum expected bad eraseblock count per 1024 eraseblocks" > + default

Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit

Hi Artem, Richard, On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy wrote: > 1. Invalid blocks are block that contain one or more bad bits beyond > ECC. I would remove this one sentence from the log, it is misleading; invalid blocks are not necessarily related to ECC. > if

Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit

Hi Artem, Richard, On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: 1. Invalid blocks are block that contain one or more bad bits beyond ECC. I would remove this one sentence from the log, it is misleading; invalid blocks are not necessarily related to ECC.

Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit

Hi, One more thing... On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: config MTD_UBI_BEB_LIMIT - int Percentage of maximum expected bad eraseblocks - default 2 - range 0 25 + int Maximum expected bad eraseblock count per 1024 eraseblocks +

Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter

Hi Richard, Sorry for reviewing this late... On Tue, 10 Jul 2012 18:23:42 +0200 Richard Genoud richard.gen...@gmail.com wrote: -config MTD_UBI_BEB_LIMIT - int Maximum expected bad eraseblocks per 1024 eraseblocks - default 20 - range 2 256 I see some benefit keeping the config.

Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter

Hi Richard, Artem, On Thu, 16 Aug 2012 12:07:01 +0200 Richard Genoud richard.gen...@gmail.com wrote: With you approach, these system MUST pass the limit parameter via the ioctl / module-parameter. That's right. We can add a kernel config option to change the max_beb_per1024 default value

Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter

On Thu, 16 Aug 2012 16:28:38 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: On Thu, 2012-08-16 at 11:57 +0300, Shmulik Ladkani wrote: For the simplest systems (those having one ubi device) that need a limit *other* than the default (20 per 1024), they can simply set the config

Re: [PATCH] mtd: kill MTD_NAND_VERIFY_WRITE

Hi Huang, On Tue, 14 Aug 2012 22:38:45 -0400 Huang Shijie wrote: > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 588e989..0ca7257 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -22,15 +22,6 @@ menuconfig MTD_NAND > > if MTD_NAND > >

Re: [PATCH] mtd: kill MTD_NAND_VERIFY_WRITE

Hi Huang, On Tue, 14 Aug 2012 22:38:45 -0400 Huang Shijie shij...@gmail.com wrote: diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 588e989..0ca7257 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -22,15 +22,6 @@ menuconfig MTD_NAND if

Re: UBI fastmap updates

Hi, On Thu, 2 Aug 2012 19:45:38 +0200 Richard Weinberger wrote: > Okay, then let's explicitly reserve a few PEBs for fastmap. > This should be very easy task. Need to consider what's expected when migrating from a former non-FM UBI system to an FM enabled system, in the case where all PEBs

Re: UBI fastmap updates

Hi, On Thu, 2 Aug 2012 19:45:38 +0200 Richard Weinberger rich...@nod.at wrote: Okay, then let's explicitly reserve a few PEBs for fastmap. This should be very easy task. Need to consider what's expected when migrating from a former non-FM UBI system to an FM enabled system, in the case where

Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation

Hi Artem, On Mon, 30 Jul 2012 16:56:50 +0300 Artem Bityutskiy wrote: > Hi Shmulik, I've separated out the defconfig changes and pushed patches > 1,2, and 3 to the UBI tree (the master branch). Patches 4 and 5 are > already merged upstream. I did a couple of minor modifications in > commentaries

Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation

Hi Artem, On Mon, 30 Jul 2012 16:56:50 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: Hi Shmulik, I've separated out the defconfig changes and pushed patches 1,2, and 3 to the UBI tree (the master branch). Patches 4 and 5 are already merged upstream. I did a couple of minor modifications in

Re: [PATCH 1/5] ubi: introduce ubi->bad_peb_limit

On Wed, 18 Jul 2012 13:40:53 +0300 Artem Bityutskiy wrote: > I've also amended the Kconfig text a tiny bit and dropped the defconfig > changes - let's have them separately as a single patch at the end of the > series. Wouldn't having the defconfig change as the last patch break things for those

Re: [PATCH 1/5] ubi: introduce ubi-bad_peb_limit

On Wed, 18 Jul 2012 13:40:53 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: I've also amended the Kconfig text a tiny bit and dropped the defconfig changes - let's have them separately as a single patch at the end of the series. Wouldn't having the defconfig change as the last patch break

Re: [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling

Hi Artem, On Wed, 18 Jul 2012 13:28:37 +0300 Artem Bityutskiy wrote: > The whole thing will become simpler if we first mark the PEB as bad > unconditionally (because it _is_ bad), then grab the lock and do all the > re-calculations. On first glance that would sound the right thing to do.

Re: [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling

Hi Artem, On Wed, 18 Jul 2012 13:28:37 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: The whole thing will become simpler if we first mark the PEB as bad unconditionally (because it _is_ bad), then grab the lock and do all the re-calculations. On first glance that would sound the right

Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation

Hi Artem, On Mon, 16 Jul 2012 18:33:57 +0300 Artem Bityutskiy wrote: > But one more think is the mtd web-site. I've grepped for '1%' and there > are plenty of them. I've changed them all to 2% more or less > mechanically - only cleaned up one section by removing out-of-date > information. Would

Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation

Hi Artem, On Mon, 16 Jul 2012 18:33:57 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: But one more think is the mtd web-site. I've grepped for '1%' and there are plenty of them. I've changed them all to 2% more or less mechanically - only cleaned up one section by removing out-of-date

Re: [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling

On Mon, 9 Jul 2012 12:15:17 +0200 Richard Genoud wrote: > 2012/7/4 Shmulik Ladkani : > > + /* > > +* Calculate the actual number of PEBs currently needed to be > > reserved > > +* for future bad eraseblock handling. > > +*/ >

Re: UBI fastmap updates

Hi Richard, On Sun, 08 Jul 2012 14:07:41 +0200 Richard Weinberger wrote: > > + /* TODO: in the new locking scheme, produce_free_peb is > > +* called under wl_lock taken. > > +* so when returning, should reacquire the lock > > +

Re: UBI fastmap updates

Hi Richard, On Sun, 08 Jul 2012 14:07:41 +0200 Richard Weinberger rich...@nod.at wrote: + /* TODO: in the new locking scheme, produce_free_peb is +* called under wl_lock taken. +* so when returning, should reacquire the lock +

Re: [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling

On Mon, 9 Jul 2012 12:15:17 +0200 Richard Genoud richard.gen...@gmail.com wrote: 2012/7/4 Shmulik Ladkani shmulik.ladk...@gmail.com: + /* +* Calculate the actual number of PEBs currently needed to be reserved +* for future bad eraseblock handling

Re: UBI fastmap updates

Hi Richard, On Fri, 29 Jun 2012 17:14:18 +0200 Richard Weinberger wrote: > This is the next round of UBI fastmap updates. Please examine some TODOs (and questions) I've spotted while diffing against "vanilla" ubi. This patch should apply to linux-ubi at d41a140 Sorry I couldn't review

Re: UBI fastmap updates

Hi Richard, On Fri, 29 Jun 2012 17:14:18 +0200 Richard Weinberger rich...@nod.at wrote: This is the next round of UBI fastmap updates. Please examine some TODOs (and questions) I've spotted while diffing against vanilla ubi. This patch should apply to linux-ubi at d41a140 Sorry I couldn't

Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation

Hi Richard, On Fri, 6 Jul 2012 17:27:59 +0200 Richard Genoud wrote: > I've got an oops... > this is my dev-kernel in 3.5-rc5 + some work to be able to boot on my board > NB: If I use ubi_format it's ok. > the mtd1 device has 1984 PEB > the 4 last are UBI reserved + BBT > > I didn't test

Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation

Hi Richard, On Fri, 6 Jul 2012 17:27:59 +0200 Richard Genoud richard.gen...@gmail.com wrote: I've got an oops... this is my dev-kernel in 3.5-rc5 + some work to be able to boot on my board NB: If I use ubi_format it's ok. the mtd1 device has 1984 PEB the 4 last are UBI reserved + BBT I