Felipe Monteiro de Carvalho | 22 Apr 13:09 2015
Picon

Strange dir inode

Hello,

I've been working hard to get jfs read support in my software, and I
try as hard as possible to figure out myself without asking question,
but there is a very strange point where I got stuck =( Its a dir
inode, which has 10.000 files inside it.

inode nr 12291 and offset 0x600460 presents us the following basic
inode information:

http://magnifier.sourceforge.net/tmp/jfs_inode_10k_files.png

di_fileset $10
di_number $303
di_gen $2A
di_size = $14000
di_nblocks = $140
di_nlink = 2
di_uid = 0
di_gid = 0
di_mode = $200041FF
di_next_index = $B0100
di_acltype = 0

dtroot_t
DASD = zeroes
flag = 0x85 = DXD_INDEX | BT_INTERNAL | BT_ROOT
nextindex = 1
freecnt: int8 = 7
freelistt: int8 = 2
(Continue reading)

Felipe Monteiro de Carvalho | 15 Apr 11:27 2015
Picon

Cannot Find the Root Inode of a JFS Disk

Hello,

I am implementing a software to read JFS partitions in Windows/Mac OS
X. Only reading, no writing involved.

It works already for many partitions, but someone sent me a disk, and
this is something wrong with my interpretation of the JFS
documentation or something like that, because for this particular
disk, it doesn't work =(

I read in this order:

1> Aggregate Map -> Always from offset A000

2> Fileset zero inode -> Always from offset D000

Here I read _xtroot: xtpage_t; in this inode to obtain the next
address. See the screenshot:

http://magnifier.sourceforge.net/tmp/jfs_fileset_zero_inode.png

And the data that I read here (data in the comments):

xtpage_t->xtpage_t = packed record
xtpage_t->case Integer of 0: (
// struct xtheader {
xtpage_t->next: le64; //  0
xtpage_t->prev: le64; //  0
xtpage_t->flag: Byte; //  $85
xtpage_t->rsrvd1: Byte; //  0
(Continue reading)

Dave Kleikamp | 14 Apr 17:46 2015
Picon

[GIT PULL] jfs changes for v4.1

Not much this time. Just a one-liner.

The following changes since commit 09d35919b06e8508b51ee8a643a67b56f7bea0dd:

  Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
(2015-03-12 09:50:45 -0700)

are available in the git repository at:

  git://github.com/kleikamp/linux-shaggy.git tags/jfs-4.1

for you to fetch changes up to 7d2ac45611b072a24e5014a56a65e6be31c1f884:

  jfs: %pf is only for function pointers (2015-03-12 12:32:19 -0500)

----------------------------------------------------------------
Just a one-liner format fix

----------------------------------------------------------------
Scott Wood (1):
      jfs: %pf is only for function pointers

 fs/jfs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
(Continue reading)

Andrey Ryabinin | 3 Apr 16:47 2015

[PATCH] mm, mempool: kasan: poison mempool elements

Mempools keep allocated objects in reserved for situations
when ordinary allocation may not be possible to satisfy.
These objects shouldn't be accessed before they leave
the pool.
This patch poison elements when get into the pool
and unpoison when they leave it. This will let KASan
to detect use-after-free of mempool's elements.

Signed-off-by: Andrey Ryabinin <a.ryabinin <at> samsung.com>
---
 include/linux/kasan.h |  2 ++
 mm/kasan/kasan.c      | 13 +++++++++++++
 mm/mempool.c          | 23 +++++++++++++++++++++++
 3 files changed, 38 insertions(+)

diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 5bb0744..5486d77 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
 <at>  <at>  -44,6 +44,7  <at>  <at>  void kasan_poison_object_data(struct kmem_cache *cache, void *object);

 void kasan_kmalloc_large(const void *ptr, size_t size);
 void kasan_kfree_large(const void *ptr);
+void kasan_kfree(void *ptr);
 void kasan_kmalloc(struct kmem_cache *s, const void *object, size_t size);
 void kasan_krealloc(const void *object, size_t new_size);

 <at>  <at>  -71,6 +72,7  <at>  <at>  static inline void kasan_poison_object_data(struct kmem_cache *cache,

 static inline void kasan_kmalloc_large(void *ptr, size_t size) {}
(Continue reading)

David Rientjes | 25 Mar 00:08 2015
Picon

[patch 1/4] fs, jfs: remove slab object constructor

Mempools based on slab caches with object constructors are risky because
element allocation can happen either from the slab cache itself, meaning
the constructor is properly called before returning, or from the mempool
reserve pool, meaning the constructor is not called before returning,
depending on the allocation context.

For this reason, we should disallow creating mempools based on slab
caches that have object constructors.  Callers of mempool_alloc() will
be responsible for properly initializing the returned element.

Then, it doesn't matter if the element came from the slab cache or the
mempool reserved pool.

The only occurrence of a mempool being based on a slab cache with an
object constructor in the tree is in fs/jfs/jfs_metapage.c.  Remove it
and properly initialize the element in alloc_metapage().

At the same time, META_free is never used, so remove it as well.

Signed-off-by: David Rientjes <rientjes <at> google.com>
---
 fs/jfs/jfs_metapage.c | 31 ++++++++++++-------------------
 fs/jfs/jfs_metapage.h |  1 -
 2 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/fs/jfs/jfs_metapage.c b/fs/jfs/jfs_metapage.c
--- a/fs/jfs/jfs_metapage.c
+++ b/fs/jfs/jfs_metapage.c
 <at>  <at>  -183,30 +183,23  <at>  <at>  static inline void remove_metapage(struct page *page, struct metapage *mp)

(Continue reading)

Dave Kleikamp | 23 Mar 22:06 2015
Picon

[PATCH][3.2.y][3.4.y][3.10.y] jfs: fix readdir regression

Upstream commit 44512449, "jfs: fix readdir cookie incompatibility
with NFSv4", was backported incorrectly into the stable trees which
used the filldir callback (rather than dir_emit). The position is
being incorrectly passed to filldir for the . and .. entries.

The still-maintained stable trees that need to be fixed are 3.2.y,
3.4.y and 3.10.y.

https://bugzilla.kernel.org/show_bug.cgi?id=94741

Signed-off-by: Dave Kleikamp <dave.kleikamp <at> oracle.com>
Cc: jfs-discussion <at> lists.sourceforge.net
Cc: stable <at> vger.kernel.org
---
 fs/jfs/jfs_dtree.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
index 9f7c758..f6f32fa 100644
--- a/fs/jfs/jfs_dtree.c
+++ b/fs/jfs/jfs_dtree.c
 <at>  <at>  -3103,7 +3103,7  <at>  <at>  int jfs_readdir(struct file *filp, void *dirent, filldir_t filldir)
 				 * self "."
 				 */
 				filp->f_pos = 1;
-				if (filldir(dirent, ".", 1, 0, ip->i_ino,
+				if (filldir(dirent, ".", 1, 1, ip->i_ino,
 					    DT_DIR))
 					return 0;
 			}
(Continue reading)

Richard Weinberger | 21 Mar 00:33 2015
Picon

JFS readdir() issues in stable 3.2

Hi!

Mainline commit 44512449c0ab368889dd13ae0031fba74ee7e1d2
(jfs: fix readdir cookie incompatibility with NFSv4) does not work as expected on 3.2.
Maybe on other stable kernels too.

UML stumbled over it:
https://bugzilla.kernel.org/show_bug.cgi?id=94741

If you run the attached readdir.c on a JFS on stable 3.2.51+ readdir() will not
increment the directory offset nor return NULL, hence the caller will loop forever.
It looks like if the current directory offset is > 0 and you run seekdir(telldir())
the next readdir() call will not increment it.

Dave, has your fix some unnamed dependencies which need backporting too?

Thanks,
//richard
Attachment (readdir.c): text/x-csrc, 442 bytes
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jfs-discussion mailing list
(Continue reading)

Omar Sandoval | 16 Mar 12:33 2015

[RFC PATCH 0/5] Remove rw parameter from direct_IO()

Hi,

Al, here's some cleanup that you mentioned back in December that I got
around to (https://lkml.org/lkml/2014/12/15/28).

In summary, the rw parameter to a_ops->direct_IO() is redundant with
.type in struct iov_iter. Additionally, rw is inconsistently checked for
being a WRITE; some filesystems do rw == WRITE, others do rw & WRITE,
and others do both within the same function :) The distinction is that
swapout may OR in the ITER_BVEC flag in the rw passed to ->direct_IO(),
so the two are not equivalent (although this really only happens for
swap-over-NFS, but it's scary nonetheless). After looking through all of
these, it definitely looks like every check means for ANY write, not
just non-kernel writes.

So, the solution presented here is:

- Add a helper, iov_iter_rw(), which always returns either READ or
  WRITE, no ITER_.* or REQ_.* nonsense mixed in. For consistency, the
  return value is always checked for equality
- Get rid of all uses of rw in any implementations of direct_IO,
  starting with the generic code
- Nuke the actual parameter and update the documentation

I decided to squish all of the filesystems together in patch 4 to avoid
inundating the mailing lists with 20+ mostly two-line patches, but I can
split those out if that's any better. Additionally, patch 1 pulls fs.h
into uio.h, which seems undesirable.

These were mostly just compile tested, with a couple of direct I/O
(Continue reading)

Rasmus Villemoes | 19 Mar 12:28 2015
Picon

[PATCH] fs: cleanup slight list_entry abuse

list_entry is just a wrapper for container_of, but it is arguably
wrong (and slightly confusing) to use it when the pointed-to struct
member is not a struct list_head. Use container_of directly instead.

Signed-off-by: Rasmus Villemoes <linux <at> rasmusvillemoes.dk>
---
Most of these predate git. If I'm the only one who has been confused
by this in 10 years, maybe it's not worth the churn.

 fs/affs/affs.h              | 2 +-
 fs/befs/befs.h              | 2 +-
 fs/coda/coda_linux.h        | 2 +-
 fs/hfs/hfs_fs.h             | 2 +-
 fs/hfsplus/hfsplus_fs.h     | 2 +-
 fs/hpfs/hpfs_fn.h           | 2 +-
 fs/jffs2/os-linux.h         | 2 +-
 fs/jfs/jfs_incore.h         | 2 +-
 fs/minix/minix.h            | 2 +-
 fs/ntfs/inode.h             | 2 +-
 fs/squashfs/squashfs_fs_i.h | 2 +-
 fs/sysv/sysv.h              | 2 +-
 fs/udf/udf_i.h              | 2 +-
 13 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/fs/affs/affs.h b/fs/affs/affs.h
index c8764bd7497d..64469527d445 100644
--- a/fs/affs/affs.h
+++ b/fs/affs/affs.h
 <at>  <at>  -64,7 +64,7  <at>  <at>  struct affs_inode_info {
 /* short cut to get to the affs specific inode data */
(Continue reading)

Felipe Monteiro de Carvalho | 21 Feb 11:26 2015
Picon

Cannot find inode

Hello,

I am writing a software to read jfs partitions, and I can already read
the root and many directories / files inside it.

But some dirs / files have a high inode number (0x106 and 0x107), but
my Fileset Inode Map has only 3 extents, which means that I have only
32*3 inodes available, so I cannot locate this high inode nr =(

Any ideas of what I am failing to understand here??? How to find inode
with number 0x106?

Here is the screenshot of the root inode:

http://magnifier.sourceforge.net/tmp/jfs_strange_inode_nr.png

Note the selected area:

06010000 FF 07 <item name>

I interpreted this as being:

struct ldtentry {
__le32 inumber;-> $106
s8 next; -> FF
u8 namlen; -> 07
...

And therefore inode nr 0x106 but like I said, my Fileset Inode
Allocation Map has only 3 extents in iag.inoext each with len=4 which
(Continue reading)

Dave Kleikamp | 12 Feb 17:32 2015
Picon

[GIT PULL] jfs changes for v3.20

The following changes since commit 53262d12d1658669029ab39a63e3d314108abe66:

  Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
(2014-12-23 11:03:28 -0800)

are available in the git repository at:

  git://github.com/kleikamp/linux-shaggy.git tags/jfs-3.20

for you to fetch changes up to 648695c74811f09a8ad80d7c3be72b8169589a64:

  jfs: Deletion of an unnecessary check before the function call "unload_nls" (2015-02-02 15:02:34 -0600)

----------------------------------------------------------------
a couple cleanups for jfs

----------------------------------------------------------------
Al Viro (1):
      jfs: get rid of homegrown endianness helpers

Markus Elfring (1):
      jfs: Deletion of an unnecessary check before the function call "unload_nls"

 fs/jfs/endian24.h  | 49 ------------------------------------------------
 fs/jfs/jfs_dtree.c |  4 ++--
 fs/jfs/jfs_types.h | 55 ++++++++++++++++++++++++++++++++----------------------
 fs/jfs/jfs_xtree.h | 25 +++++++++----------------
 fs/jfs/super.c     |  3 +--
 5 files changed, 45 insertions(+), 91 deletions(-)
 delete mode 100644 fs/jfs/endian24.h
(Continue reading)


Gmane