答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
Hi, I do not think Huawei has hacked make_ext4fs. For it could be reproduced in make_ext4fs master brach before Jun 21th 2018. Like below, I think we just choose not recommended parameter "-b 1024" for small partition like below, but it's legal though not good. ./host/linux-x86/bin/make_ext4fs -s -l 20M -b 1024 gaoming.img Creating filesystem with parameters: Size: 20971520 Block size: 1024 Blocks per group: 8192 Inodes per group: 1708 Inode size: 256 Journal blocks: 1024 Label: Blocks: 20480 Block groups: 3 Reserved block group size: 95 Created filesystem with 11/5124 inodes and 2509/20480 blocks Other vendors may choose this para, or not, we don't know. maybe they are lucky or wise not choosing 1024. Of course we will choose 4096, or mke2fs from now on. We just want to fix historical problem. We will fix it by ourselves. I fully understand your attitude. Thanks a lot. Regards, Ming -邮件原件- 发件人: Theodore Y. Ts'o [mailto:ty...@mit.edu] 发送时间: 2018年7月4日 0:03 收件人: Gaoming (ming, consumer BG) 抄送: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Liqingchao (sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver) 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices On Tue, Jul 03, 2018 at 11:15:21AM +, Gaoming (ming, consumer BG) wrote: > > You misunderstand my question. Why was the choice of a blocksize of > 1024 made? > > -some one choose, not me . I guess they want get more inodes in 20M > filesystem. That can't be the explanation. I just checked the sources for make_ext4fs; the blocksize was hard-coded, as was the number of inodes. So in order to use a block_size of 1024 bytes, someone must have hacked the sources directly and modified compute_block_size(). And in fact, it would have been *easier* to simply hack compute_inodes() which is just a few lines below in make_ext4fs.c: static u32 compute_block_size() { return 4096; } static u32 compute_inodes() { return DIV_ROUND_UP(info.len, info.block_size) / 4; } This also means commit 06c35f935a7a which fixed make_ext4fs.c wasn't buggy; it was a valid fix given the complete-non-adjustability of the blocksize in make_ext4fs. Yes, it's not a great fix, since it was fragile --- but that's hardly the smallest problem in make_ext4fs, there was plenty of other super-fragile bits in make_ext4fs. There's a *reason* I was pushing hard to make make_ext4fs go away. That being said, given the block size of make_ext4fs was hard-coded to 4096, it makes it clear that the change to make it create a blocksize of 1024 must have beeen a Huawei-local change, and it was never sent back to the the common AOSP tree. (If it had, I would have gotten an e-mail, and I would have explained to whoever had made this Huawei-local hack why it was such a incredibly bad idea.) In any case, what I would recommend at this point if you need to support Huawei devices that do this, is that you keep your e2fsprogs as a Huawei-specific e2fsprogs repo. > How long has Huawei been using a 1024 byte blocksize? And why? And > for how many devices? Essentially, I'm trying to figure out if this > was a Huawei-specific mistake. > - I cannot answer this question. Well, actually, it should be very easy for you to detremine the answer this question --- it should just be a matter of checking git source control history and see which product trees has the change to platforms/system/extras/ext4_utils/make_ext4fs.c --- and you must have platform-specific source trees in order to be compliant with the GNU Public License (GPL). Even if you didn't, it would just be a matter using dumpe2fs or debugfs (they aren't built by default in e2fsprogs by the AOSP build trees, but they should be buildable) to those Huawei devices that you still support, and then run either dumpe2fs or debugfs via adb shell and see what block size is reported. Even if you aren't allowed to answer this question publically, I'd strongly recommend you figure it out, so you know when your local change to e2fsprogs can be dropped. I'd further recommend that you make sure all new Huawei devices use a block size of 4096, preferably using mke2fs and e2fsdroid, as is currently done in AOSP. Failing that, at least please use the stock make_ext4fs which doesn't have the Huawei-specific hack to support 1024 byte block sizes, or have that Huawei-specific hack reverted. Regards, - Ted
答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
Hi, I do not think Huawei has hacked make_ext4fs. For it could be reproduced in make_ext4fs master brach before Jun 21th 2018. Like below, I think we just choose not recommended parameter "-b 1024" for small partition like below, but it's legal though not good. ./host/linux-x86/bin/make_ext4fs -s -l 20M -b 1024 gaoming.img Creating filesystem with parameters: Size: 20971520 Block size: 1024 Blocks per group: 8192 Inodes per group: 1708 Inode size: 256 Journal blocks: 1024 Label: Blocks: 20480 Block groups: 3 Reserved block group size: 95 Created filesystem with 11/5124 inodes and 2509/20480 blocks Other vendors may choose this para, or not, we don't know. maybe they are lucky or wise not choosing 1024. Of course we will choose 4096, or mke2fs from now on. We just want to fix historical problem. We will fix it by ourselves. I fully understand your attitude. Thanks a lot. Regards, Ming -邮件原件- 发件人: Theodore Y. Ts'o [mailto:ty...@mit.edu] 发送时间: 2018年7月4日 0:03 收件人: Gaoming (ming, consumer BG) 抄送: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Liqingchao (sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver) 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices On Tue, Jul 03, 2018 at 11:15:21AM +, Gaoming (ming, consumer BG) wrote: > > You misunderstand my question. Why was the choice of a blocksize of > 1024 made? > > -some one choose, not me . I guess they want get more inodes in 20M > filesystem. That can't be the explanation. I just checked the sources for make_ext4fs; the blocksize was hard-coded, as was the number of inodes. So in order to use a block_size of 1024 bytes, someone must have hacked the sources directly and modified compute_block_size(). And in fact, it would have been *easier* to simply hack compute_inodes() which is just a few lines below in make_ext4fs.c: static u32 compute_block_size() { return 4096; } static u32 compute_inodes() { return DIV_ROUND_UP(info.len, info.block_size) / 4; } This also means commit 06c35f935a7a which fixed make_ext4fs.c wasn't buggy; it was a valid fix given the complete-non-adjustability of the blocksize in make_ext4fs. Yes, it's not a great fix, since it was fragile --- but that's hardly the smallest problem in make_ext4fs, there was plenty of other super-fragile bits in make_ext4fs. There's a *reason* I was pushing hard to make make_ext4fs go away. That being said, given the block size of make_ext4fs was hard-coded to 4096, it makes it clear that the change to make it create a blocksize of 1024 must have beeen a Huawei-local change, and it was never sent back to the the common AOSP tree. (If it had, I would have gotten an e-mail, and I would have explained to whoever had made this Huawei-local hack why it was such a incredibly bad idea.) In any case, what I would recommend at this point if you need to support Huawei devices that do this, is that you keep your e2fsprogs as a Huawei-specific e2fsprogs repo. > How long has Huawei been using a 1024 byte blocksize? And why? And > for how many devices? Essentially, I'm trying to figure out if this > was a Huawei-specific mistake. > - I cannot answer this question. Well, actually, it should be very easy for you to detremine the answer this question --- it should just be a matter of checking git source control history and see which product trees has the change to platforms/system/extras/ext4_utils/make_ext4fs.c --- and you must have platform-specific source trees in order to be compliant with the GNU Public License (GPL). Even if you didn't, it would just be a matter using dumpe2fs or debugfs (they aren't built by default in e2fsprogs by the AOSP build trees, but they should be buildable) to those Huawei devices that you still support, and then run either dumpe2fs or debugfs via adb shell and see what block size is reported. Even if you aren't allowed to answer this question publically, I'd strongly recommend you figure it out, so you know when your local change to e2fsprogs can be dropped. I'd further recommend that you make sure all new Huawei devices use a block size of 4096, preferably using mke2fs and e2fsdroid, as is currently done in AOSP. Failing that, at least please use the stock make_ext4fs which doesn't have the Huawei-specific hack to support 1024 byte block sizes, or have that Huawei-specific hack reverted. Regards, - Ted
Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
On Tue, Jul 03, 2018 at 11:15:21AM +, Gaoming (ming, consumer BG) wrote: > > You misunderstand my question. Why was the choice of a blocksize of > 1024 made? > > -some one choose, not me . I guess they want get more inodes in 20M > filesystem. That can't be the explanation. I just checked the sources for make_ext4fs; the blocksize was hard-coded, as was the number of inodes. So in order to use a block_size of 1024 bytes, someone must have hacked the sources directly and modified compute_block_size(). And in fact, it would have been *easier* to simply hack compute_inodes() which is just a few lines below in make_ext4fs.c: static u32 compute_block_size() { return 4096; } static u32 compute_inodes() { return DIV_ROUND_UP(info.len, info.block_size) / 4; } This also means commit 06c35f935a7a which fixed make_ext4fs.c wasn't buggy; it was a valid fix given the complete-non-adjustability of the blocksize in make_ext4fs. Yes, it's not a great fix, since it was fragile --- but that's hardly the smallest problem in make_ext4fs, there was plenty of other super-fragile bits in make_ext4fs. There's a *reason* I was pushing hard to make make_ext4fs go away. That being said, given the block size of make_ext4fs was hard-coded to 4096, it makes it clear that the change to make it create a blocksize of 1024 must have beeen a Huawei-local change, and it was never sent back to the the common AOSP tree. (If it had, I would have gotten an e-mail, and I would have explained to whoever had made this Huawei-local hack why it was such a incredibly bad idea.) In any case, what I would recommend at this point if you need to support Huawei devices that do this, is that you keep your e2fsprogs as a Huawei-specific e2fsprogs repo. > How long has Huawei been using a 1024 byte blocksize? And why? And > for how many devices? Essentially, I'm trying to figure out if this > was a Huawei-specific mistake. > - I cannot answer this question. Well, actually, it should be very easy for you to detremine the answer this question --- it should just be a matter of checking git source control history and see which product trees has the change to platforms/system/extras/ext4_utils/make_ext4fs.c --- and you must have platform-specific source trees in order to be compliant with the GNU Public License (GPL). Even if you didn't, it would just be a matter using dumpe2fs or debugfs (they aren't built by default in e2fsprogs by the AOSP build trees, but they should be buildable) to those Huawei devices that you still support, and then run either dumpe2fs or debugfs via adb shell and see what block size is reported. Even if you aren't allowed to answer this question publically, I'd strongly recommend you figure it out, so you know when your local change to e2fsprogs can be dropped. I'd further recommend that you make sure all new Huawei devices use a block size of 4096, preferably using mke2fs and e2fsdroid, as is currently done in AOSP. Failing that, at least please use the stock make_ext4fs which doesn't have the Huawei-specific hack to support 1024 byte block sizes, or have that Huawei-specific hack reverted. Regards, - Ted
Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
On Tue, Jul 03, 2018 at 11:15:21AM +, Gaoming (ming, consumer BG) wrote: > > You misunderstand my question. Why was the choice of a blocksize of > 1024 made? > > -some one choose, not me . I guess they want get more inodes in 20M > filesystem. That can't be the explanation. I just checked the sources for make_ext4fs; the blocksize was hard-coded, as was the number of inodes. So in order to use a block_size of 1024 bytes, someone must have hacked the sources directly and modified compute_block_size(). And in fact, it would have been *easier* to simply hack compute_inodes() which is just a few lines below in make_ext4fs.c: static u32 compute_block_size() { return 4096; } static u32 compute_inodes() { return DIV_ROUND_UP(info.len, info.block_size) / 4; } This also means commit 06c35f935a7a which fixed make_ext4fs.c wasn't buggy; it was a valid fix given the complete-non-adjustability of the blocksize in make_ext4fs. Yes, it's not a great fix, since it was fragile --- but that's hardly the smallest problem in make_ext4fs, there was plenty of other super-fragile bits in make_ext4fs. There's a *reason* I was pushing hard to make make_ext4fs go away. That being said, given the block size of make_ext4fs was hard-coded to 4096, it makes it clear that the change to make it create a blocksize of 1024 must have beeen a Huawei-local change, and it was never sent back to the the common AOSP tree. (If it had, I would have gotten an e-mail, and I would have explained to whoever had made this Huawei-local hack why it was such a incredibly bad idea.) In any case, what I would recommend at this point if you need to support Huawei devices that do this, is that you keep your e2fsprogs as a Huawei-specific e2fsprogs repo. > How long has Huawei been using a 1024 byte blocksize? And why? And > for how many devices? Essentially, I'm trying to figure out if this > was a Huawei-specific mistake. > - I cannot answer this question. Well, actually, it should be very easy for you to detremine the answer this question --- it should just be a matter of checking git source control history and see which product trees has the change to platforms/system/extras/ext4_utils/make_ext4fs.c --- and you must have platform-specific source trees in order to be compliant with the GNU Public License (GPL). Even if you didn't, it would just be a matter using dumpe2fs or debugfs (they aren't built by default in e2fsprogs by the AOSP build trees, but they should be buildable) to those Huawei devices that you still support, and then run either dumpe2fs or debugfs via adb shell and see what block size is reported. Even if you aren't allowed to answer this question publically, I'd strongly recommend you figure it out, so you know when your local change to e2fsprogs can be dropped. I'd further recommend that you make sure all new Huawei devices use a block size of 4096, preferably using mke2fs and e2fsdroid, as is currently done in AOSP. Failing that, at least please use the stock make_ext4fs which doesn't have the Huawei-specific hack to support 1024 byte block sizes, or have that Huawei-specific hack reverted. Regards, - Ted
答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
-邮件原件- 发件人: Theodore Y. Ts'o [mailto:ty...@mit.edu] 发送时间: 2018年7月3日 18:36 收件人: Gaoming (ming, consumer BG) 抄送: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Liqingchao (sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver) 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices On Tue, Jul 03, 2018 at 12:58:48AM +, Gaoming (ming, consumer BG) wrote: > And can you help me understand *why* such a choice was made? > -if there is such a problem in your devices, how will you do? Is there > any other choice? > - of course, you cannot format the partition. You misunderstand my question. Why was the choice of a blocksize of 1024 made? -some one choose, not me . I guess they want get more inodes in 20M filesystem. I'm trying to understand how many devices, and why any other manufacture would make, what seems to me, to be a completely insane choice. How long has Huawei been using a 1024 byte blocksize? And why? And for how many devices? Essentially, I'm trying to figure out if this was a Huawei-specific mistake. - I cannot answer this question. - Ted
答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
-邮件原件- 发件人: Theodore Y. Ts'o [mailto:ty...@mit.edu] 发送时间: 2018年7月3日 18:36 收件人: Gaoming (ming, consumer BG) 抄送: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Liqingchao (sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver) 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices On Tue, Jul 03, 2018 at 12:58:48AM +, Gaoming (ming, consumer BG) wrote: > And can you help me understand *why* such a choice was made? > -if there is such a problem in your devices, how will you do? Is there > any other choice? > - of course, you cannot format the partition. You misunderstand my question. Why was the choice of a blocksize of 1024 made? -some one choose, not me . I guess they want get more inodes in 20M filesystem. I'm trying to understand how many devices, and why any other manufacture would make, what seems to me, to be a completely insane choice. How long has Huawei been using a 1024 byte blocksize? And why? And for how many devices? Essentially, I'm trying to figure out if this was a Huawei-specific mistake. - I cannot answer this question. - Ted
Re: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
On Tue, Jul 03, 2018 at 12:58:48AM +, Gaoming (ming, consumer BG) wrote: > And can you help me understand *why* such a choice was made? > -if there is such a problem in your devices, how will you do? Is there > any other choice? > - of course, you cannot format the partition. You misunderstand my question. Why was the choice of a blocksize of 1024 made? I'm trying to understand how many devices, and why any other manufacture would make, what seems to me, to be a completely insane choice. How long has Huawei been using a 1024 byte blocksize? And why? And for how many devices? Essentially, I'm trying to figure out if this was a Huawei-specific mistake. - Ted
Re: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
On Tue, Jul 03, 2018 at 12:58:48AM +, Gaoming (ming, consumer BG) wrote: > And can you help me understand *why* such a choice was made? > -if there is such a problem in your devices, how will you do? Is there > any other choice? > - of course, you cannot format the partition. You misunderstand my question. Why was the choice of a blocksize of 1024 made? I'm trying to understand how many devices, and why any other manufacture would make, what seems to me, to be a completely insane choice. How long has Huawei been using a 1024 byte blocksize? And why? And for how many devices? Essentially, I'm trying to figure out if this was a Huawei-specific mistake. - Ted
答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
And can you help me understand *why* such a choice was made? -if there is such a problem in your devices, how will you do? Is there any other choice? - of course, you cannot format the partition. -邮件原件- 发件人: Theodore Y. Ts'o [mailto:ty...@mit.edu] 发送时间: 2018年7月2日 20:17 收件人: Gaoming (ming, consumer BG) 抄送: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Liqingchao (sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver) 主题: Re: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices On Mon, Jul 02, 2018 at 09:34:28AM +, Gaoming (ming, consumer BG) wrote: > I got it. You hate make_ext4fs, and me too. > You don't like to merge this patch in upstream e2fsprogs to resolve the bug > of make_ext4fs. > > Of course we will fix the bug on our ancient devices, we have to . > If this problem fixed or this patch merges in latest e2fsprogs, we will > backport the latest e2fsprogs. > If not, we have no motivation to backport it. > > I don't know whether other android devices suffer this problem. Can you be explicit and tell me how many Huawei devices uses a block size of 1024? And can you help me understand *why* such a choice was made? - Ted
答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
And can you help me understand *why* such a choice was made? -if there is such a problem in your devices, how will you do? Is there any other choice? - of course, you cannot format the partition. -邮件原件- 发件人: Theodore Y. Ts'o [mailto:ty...@mit.edu] 发送时间: 2018年7月2日 20:17 收件人: Gaoming (ming, consumer BG) 抄送: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Liqingchao (sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver) 主题: Re: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices On Mon, Jul 02, 2018 at 09:34:28AM +, Gaoming (ming, consumer BG) wrote: > I got it. You hate make_ext4fs, and me too. > You don't like to merge this patch in upstream e2fsprogs to resolve the bug > of make_ext4fs. > > Of course we will fix the bug on our ancient devices, we have to . > If this problem fixed or this patch merges in latest e2fsprogs, we will > backport the latest e2fsprogs. > If not, we have no motivation to backport it. > > I don't know whether other android devices suffer this problem. Can you be explicit and tell me how many Huawei devices uses a block size of 1024? And can you help me understand *why* such a choice was made? - Ted
Re: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
On Mon, Jul 02, 2018 at 09:34:28AM +, Gaoming (ming, consumer BG) wrote: > I got it. You hate make_ext4fs, and me too. > You don't like to merge this patch in upstream e2fsprogs to resolve the bug > of make_ext4fs. > > Of course we will fix the bug on our ancient devices, we have to . > If this problem fixed or this patch merges in latest e2fsprogs, we will > backport the latest e2fsprogs. > If not, we have no motivation to backport it. > > I don't know whether other android devices suffer this problem. Can you be explicit and tell me how many Huawei devices uses a block size of 1024? And can you help me understand *why* such a choice was made? - Ted
Re: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
On Mon, Jul 02, 2018 at 09:34:28AM +, Gaoming (ming, consumer BG) wrote: > I got it. You hate make_ext4fs, and me too. > You don't like to merge this patch in upstream e2fsprogs to resolve the bug > of make_ext4fs. > > Of course we will fix the bug on our ancient devices, we have to . > If this problem fixed or this patch merges in latest e2fsprogs, we will > backport the latest e2fsprogs. > If not, we have no motivation to backport it. > > I don't know whether other android devices suffer this problem. Can you be explicit and tell me how many Huawei devices uses a block size of 1024? And can you help me understand *why* such a choice was made? - Ted
答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
I got it. You hate make_ext4fs, and me too. You don't like to merge this patch in upstream e2fsprogs to resolve the bug of make_ext4fs. Of course we will fix the bug on our ancient devices, we have to . If this problem fixed or this patch merges in latest e2fsprogs, we will backport the latest e2fsprogs. If not, we have no motivation to backport it. I don't know whether other android devices suffer this problem. If someone else come to complain this problem, you should consider to fix it. Best wishes. Ming -邮件原件- 发件人: Theodore Y. Ts'o [mailto:ty...@mit.edu] 发送时间: 2018年6月30日 21:04 收件人: Gaoming (ming, consumer BG) 抄送: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Liqingchao (sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver) 主题: Re: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices On Sat, Jun 30, 2018 at 01:26:43AM +, Gaoming (ming, consumer BG) wrote: > Yes, it is caused by using 1024 blocksize. > It is historical problem, and I have to admit that's not good idea. I don't > know why somebody choose it some years before. > It has been corrected two years before or more early. But some ancient > devices exist. > It is not user data, no need to do file-based encryption. It is a small > partition for some use. > > However, 1024 is legal though not good, somebody may use it. > And we should fix it. So you understand my position --- the reason why I've been pushing so hard is I'm trying to figure out how big of a problem this is. Specifically speaking, is this a Huawei-specific problem, or something across the entire Android ecosystem. I *thought* I had fixed most of the disaster back in 2011. There have periodic headaches where testers would discover problems where android handsets get bricked after doing a factory reset that I had tracked down to make_ext4fs, and the existence of make_ext4fs is not something I agreed to, and have been fighting for years. So I've been cleaning up after make_ext4fs for a while, even though it's not my responsiblity. (For one thing my work responsibilities are for data center servers at Google, *not* Android; for another, no one asked *me* before they came up with the abomination which is make_ext4fs.) So I don't feel particularly, or personally, responsible for bugs caused by make_ext4fs, because if it had been up to me, it would have never existed in the first place. If it's only in ancient Huawei devices, I don't see a strong reason to support his in upstream e2fsprogs. Are you really going to be backporting the latest e2fsprogs into these ancient Huawei devices? In my experience, the Android team has a hard enough time getting their Android partners to backport kernel fixes for severe security bugs into old Android devices --- never mind versions of e2fsprogs. If not, what's the point? Regards, - Ted
答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
I got it. You hate make_ext4fs, and me too. You don't like to merge this patch in upstream e2fsprogs to resolve the bug of make_ext4fs. Of course we will fix the bug on our ancient devices, we have to . If this problem fixed or this patch merges in latest e2fsprogs, we will backport the latest e2fsprogs. If not, we have no motivation to backport it. I don't know whether other android devices suffer this problem. If someone else come to complain this problem, you should consider to fix it. Best wishes. Ming -邮件原件- 发件人: Theodore Y. Ts'o [mailto:ty...@mit.edu] 发送时间: 2018年6月30日 21:04 收件人: Gaoming (ming, consumer BG) 抄送: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Liqingchao (sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver) 主题: Re: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices On Sat, Jun 30, 2018 at 01:26:43AM +, Gaoming (ming, consumer BG) wrote: > Yes, it is caused by using 1024 blocksize. > It is historical problem, and I have to admit that's not good idea. I don't > know why somebody choose it some years before. > It has been corrected two years before or more early. But some ancient > devices exist. > It is not user data, no need to do file-based encryption. It is a small > partition for some use. > > However, 1024 is legal though not good, somebody may use it. > And we should fix it. So you understand my position --- the reason why I've been pushing so hard is I'm trying to figure out how big of a problem this is. Specifically speaking, is this a Huawei-specific problem, or something across the entire Android ecosystem. I *thought* I had fixed most of the disaster back in 2011. There have periodic headaches where testers would discover problems where android handsets get bricked after doing a factory reset that I had tracked down to make_ext4fs, and the existence of make_ext4fs is not something I agreed to, and have been fighting for years. So I've been cleaning up after make_ext4fs for a while, even though it's not my responsiblity. (For one thing my work responsibilities are for data center servers at Google, *not* Android; for another, no one asked *me* before they came up with the abomination which is make_ext4fs.) So I don't feel particularly, or personally, responsible for bugs caused by make_ext4fs, because if it had been up to me, it would have never existed in the first place. If it's only in ancient Huawei devices, I don't see a strong reason to support his in upstream e2fsprogs. Are you really going to be backporting the latest e2fsprogs into these ancient Huawei devices? In my experience, the Android team has a hard enough time getting their Android partners to backport kernel fixes for severe security bugs into old Android devices --- never mind versions of e2fsprogs. If not, what's the point? Regards, - Ted