aboutsummaryrefslogtreecommitdiff
path: root/fs/ubifs/key.h
AgeCommit message (Collapse)Author
2017-07-14ubifs: Add assert to dent_key_init()Richard Weinberger
...to make sure that we don't use it for double hashed lookups instead of dent_key_init_hash(). Signed-off-by: Richard Weinberger <richard@nod.at>
2016-12-12ubifs: Implement encrypted filenamesRichard Weinberger
Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: David Gstir <david@sigma-star.at> Signed-off-by: Richard Weinberger <richard@nod.at>
2016-12-12ubifs: Make r5 hash binary string awareRichard Weinberger
As of now all filenames known by UBIFS are strings with a NUL terminator. With encrypted filenames a filename can be any binary string and the r5 function cannot search for the NUL terminator. UBIFS always knows how long a filename is, therefore we can change the hash function to iterate over the filename length to work correctly with binary strings. Signed-off-by: Richard Weinberger <richard@nod.at>
2016-01-10UBIFS: add a comment in key.h for unused parameterDongsheng Yang
Add a comment in key.h to explain why we keep an unused parameter in key helpers. Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2010-08-30UBIFS: mark unused key objects as invalidArtem Bityutskiy
When scanning the flash, UBIFS builds a list of flash nodes of type 'struct ubifs_scan_node'. Each scanned node has a 'snod->key' field. This field is valid for most of the nodes, but invalid for some node type, e.g., truncation nodes. It is safer to explicitly initialize such keys to something invalid, rather than leaving them initialized to all zeros, which has key type of UBIFS_INO_KEY. This patch introduces new "fake" key type UBIFS_INVALID_KEY and initializes unused 'snod->key' objects to this type. It also adds debugging assertions in the TNC code to make sure no one ever tries to look these nodes up in the TNC. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2009-09-10UBIFS: add inode size debugging checkArtem Bityutskiy
Add one more check to UBIFS - a check that makes sure that there are no data nodes beyond inode size. And few commantaries fixes along the line. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Reviewed-by: Adrian Hunter <Adrian.Hunter@nokia.com>
2009-07-24UBIFS: remove unused functionsSubrata Modak
Remove 'xent_key_init_hash()' and 'data_key_init_flash()' functions, as they are unot used anywhere. Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2009-03-08UBIFS: amend key_hash return valueArtem Bityutskiy
... which should be uint32_t, not int. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2008-12-03UBIFS: avoid unnecessary checksKukkonen Mika
I have a habit of compiling kernel with EXTRA_CFLAGS="-Wextra -Wno-unused -Wno-sign-compare -Wno-missing-field-initializers" and so fs/ubifs/key.h give lots (~10) of these every time: CC fs/ubifs/tnc_misc.o In file included from fs/ubifs/ubifs.h:1725, from fs/ubifs/tnc_misc.c:30: fs/ubifs/key.h: In function 'key_r5_hash': fs/ubifs/key.h:64: warning: comparison of unsigned expression >= 0 is always true fs/ubifs/key.h: In function 'key_test_hash': fs/ubifs/key.h:81: warning: comparison of unsigned expression >= 0 is always true This patch fixes the warnings. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2008-11-06UBIFS: endian handling fixes and annotationsHarvey Harrison
Noticed by sparse: fs/ubifs/file.c:75:2: warning: restricted __le64 degrades to integer fs/ubifs/file.c:629:4: warning: restricted __le64 degrades to integer fs/ubifs/dir.c:431:3: warning: restricted __le64 degrades to integer This should be checked to ensure the ubifs_assert is working as intended, I've done the suggested annotation in this patch. fs/ubifs/sb.c:298:6: warning: incorrect type in assignment (different base types) fs/ubifs/sb.c:298:6: expected int [signed] [assigned] tmp fs/ubifs/sb.c:298:6: got restricted __le64 [usertype] <noident> fs/ubifs/sb.c:299:19: warning: incorrect type in assignment (different base types) fs/ubifs/sb.c:299:19: expected restricted __le64 [usertype] atime_sec fs/ubifs/sb.c:299:19: got int [signed] [assigned] tmp fs/ubifs/sb.c:300:19: warning: incorrect type in assignment (different base types) fs/ubifs/sb.c:300:19: expected restricted __le64 [usertype] ctime_sec fs/ubifs/sb.c:300:19: got int [signed] [assigned] tmp fs/ubifs/sb.c:301:19: warning: incorrect type in assignment (different base types) fs/ubifs/sb.c:301:19: expected restricted __le64 [usertype] mtime_sec fs/ubifs/sb.c:301:19: got int [signed] [assigned] tmp This looks like a bugfix as your tmp was a u32 so there was truncation in the atime, mtime, ctime value, probably not intentional, add a tmp_le64 and use it here. fs/ubifs/key.h:348:9: warning: cast to restricted __le32 fs/ubifs/key.h:348:9: warning: cast to restricted __le32 fs/ubifs/key.h:419:9: warning: cast to restricted __le32 Read from the annotated union member instead. fs/ubifs/recovery.c:175:13: warning: incorrect type in assignment (different base types) fs/ubifs/recovery.c:175:13: expected unsigned int [unsigned] [usertype] save_flags fs/ubifs/recovery.c:175:13: got restricted __le32 [usertype] flags fs/ubifs/recovery.c:186:13: warning: incorrect type in assignment (different base types) fs/ubifs/recovery.c:186:13: expected restricted __le32 [usertype] flags fs/ubifs/recovery.c:186:13: got unsigned int [unsigned] [usertype] save_flags Do byteshifting at compile time of the flag value. Annotate the saved_flags as le32. fs/ubifs/debug.c:368:10: warning: cast to restricted __le32 fs/ubifs/debug.c:368:10: warning: cast from restricted __le64 Should be checked if the truncation was intentional, I've changed the printk to print the full width. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
2008-09-30UBIFS: add bulk-read facilityAdrian Hunter
Some flash media are capable of reading sequentially at faster rates. UBIFS bulk-read facility is designed to take advantage of that, by reading in one go consecutive data nodes that are also located consecutively in the same LEB. Read speed on Arm platform with OneNAND goes from 17 MiB/s to 19 MiB/s. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
2008-07-15UBIFS: add new flash file systemArtem Bityutskiy
This is a new flash file system. See http://www.linux-mtd.infradead.org/doc/ubifs.html Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>