#4184 BLOC First D: JFFS2 Dirent Anomaly

[Zarro Boogs per Child]

#4184: JFFS2 Dirent Anomaly
--------------------------------+-------------------------------------------
  Reporter:  wmb at firmworks.com  |       Owner:  dwmw2                 
      Type:  defect             |      Status:  new                   
  Priority:  blocker            |   Milestone:  First Deployment, V1.0
 Component:  kernel             |     Version:                        
Resolution:                     |    Keywords:                        
  Verified:  0                  |  
--------------------------------+-------------------------------------------

Comment(by dwmw2):

 This is the offending directory entry:

 {{{
 1c616bd0  .................................... 85 19 01 e0
 |...:@....G;0....|
 1c616be0  32 00 00 00 f3 76 37 50  ef b2 02 00 12 00 00 00
 |2....v7P........|
 1c616bf0  68 be 02 00 32 26 05 47  0a 08 00 00 0f 40 39 10
 |h...2&.G..... at 9.|
 1c616c00  a3 38 58 41 6a 6f 79 64  65 76 2e 6b 6f 00 ff ff
 |.8XAjoydev.ko...|
 }}}

 Note the recorded name length of ten bytes, and the tenth byte being zero.
 When we try to replace this directory entry, we end up creating a new
 dirent "joydev.ko" with a _different_ hash value, which doesn't succeed in
 displacing the offending "joydev.ko\0" from the list.

 There are other strange dirents too, for example:

 {{{
 1c6157a0  .......................  85 19 01 e0 32 00 00 00
 |.....P......2...|
 1c6157b0  f3 76 37 50 ef b2 02 00  11 00 00 00 68 be 02 00
 |.v7P........h...|
 1c6157c0  32 26 05 47 0a 08 00 00  fd f4 f1 39 ef 23 52 ee
 |2&.G.......9.#R.|
 1c6157d0  6a 6f 79 64 65 76 2e 6b  6f a9 ff ff ...........
 |joydev.ko.......|
 }}}

 This time, the length was extended to 10 bytes and one '0xa9' byte was
 appended.

 I don't know why that would have happened in the first place -- I'll
 continue to investigate, and add a sanity check to catch it at least when
 the name contains zero bytes, at the time of creation.

 The symptoms can be addressed in two ways -- firstly, we can abandon GC
 immediately when we attempt to GC and find that the node we were
 attempting to obsolete _isn't_ now obsolete. And secondly, we can check
 for zeroes in existing nodes and cope with them so that the name hash
 _does_ start to match.

-- 
Ticket URL: <https://dev.laptop.org/ticket/4184#comment:5>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system