On Mon, Apr 28, 2008 at 09:01:42AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 28 Apr 2008, Adrian Bunk wrote:
> <
> > This patch fixes the following build error with UML and gcc 4.3:
> >
> > <-- snip -->
> >
> > ...
> > CC fs/buffer.o
> > /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/buffer.c: In function ‘init_page_buffers’:
> > /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/buffer.c:51: sorry, unimplemented: inlining failed in call to ‘init_buffer’: function body not available
> > /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/buffer.c:1007: sorry, unimplemented: called from here
> > make[2]: *** [fs/buffer.o] Error 1
>
> Can somebody tell why this is not a gcc bug?

It is a gcc bug.

But having a global function marked as extern was already questionable,
and all assumptions an "inline" would always inline the code are anyway
now broken in your tree.

So let's work around a gcc bug by fixing the kernel...

> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, 28 Apr 2008, Adrian Bunk wrote:
> >
> > Can somebody tell why this is not a gcc bug?
>
> It is a gcc bug.
>
> But having a global function marked as extern was already questionable,
> and all assumptions an "inline" would always inline the code are anyway
> now broken in your tree.
>
> So let's work around a gcc bug by fixing the kernel...

But when doing this, MARK IT LOUDLY AS A GCC BUG!

The thing is, reading that log message, it was not at all clear why that
change was made. Please make it clear why, rather than quoting a totally
useless error message that doesn't actually tell what is going on.

I agree that having work-arounds for compiler bugs is worth it (assuming
the version is common enough to worry about), but I also don't want to
have unexplained commits doing something that on the face of it is just
odd

Put another way: looking at the actual diff and looking at the commit
message, the only sane reaction from somebody who knows the code is:
"Whaa? WTF?". Saying "This is a gcc bug" would have turned that "WTF?"
into a "Oh, ok then".

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Apr 26, 2008 at 07:22:22PM +0200, Ingo Molnar wrote:
> > It also makes me wonder why Kconfig.i386 can just include
> > arch/x86/Kconfig.cpu, but x86_64 cannot?
>
> hm, indeed arch/um/Kconfig.i386 is assymetric to Kconfig.x86_64. Jeff
> Cc:-ed.

In current git, they look pretty symmetric to me, and it boots and runs.

> arch/um/os-Linux/helper.c: In function 'run_helper':
> arch/um/os-Linux/helper.c:73: error: 'PATH_MAX' undeclared (first use in this function)
>
> it needs the patch below.

Applied, thanks.

> then it fails with:
>
> mm/filemap.c: In function '__generic_file_aio_write_nolock':
> mm/filemap.c:1831: sorry, unimplemented: inlining failed in call to
> 'generic_write_checks': function body not available

Looks like Adrian just hit that too. As Linus pointed out,
__generic_file_aio_write_nolock calls generic_write_checks at line
2383, and that's available at line 1831, which the error message
helpfully points out. I don't see how gcc can be claiming that the
function body isn't available when it's telling you exactly where it
is.

Jeff

--
Work email - jdike at linux dot intel dot com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 29 Apr 2008, Al Viro wrote:
>
> AFAICS, it's a gcc bug.

So did the "always_inline" thing just hide this? Or what is going on?

We can just say that gcc-3 has to always_inline if so.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, Apr 28, 2008 at 05:41:11PM -0700, Linus Torvalds wrote:
> So just removing the inline is simply not acceptable any more, since it
> just implies total and utter breakage of the compiler. At some point you
> just have to say: "That is sh*t", and not take it any more.
>
> What is UML doing to trigger this?

Beats the crap out of me. These things are very generic code from
UML's point of view.

Jeff

--
Work email - jdike at linux dot intel dot com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, Apr 28, 2008 at 10:32:17PM -0400, Jeff Dike wrote:
> On Mon, Apr 28, 2008 at 05:41:11PM -0700, Linus Torvalds wrote:
> > So just removing the inline is simply not acceptable any more, since it
> > just implies total and utter breakage of the compiler. At some point you
> > just have to say: "That is sh*t", and not take it any more.
> >
> > What is UML doing to trigger this?
>
> Beats the crap out of me. These things are very generic code from
> UML's point of view.

How does the preprocessed code look like around the definition
and the declaration + use of said function?

Try to do an:
make path/to/file.i

To see the preprocessed output.

Just in case we have some subtle things going on..

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, Apr 28 2008, Adrian Bunk wrote:
> This patch fixes the following build error with UML and gcc 4.3:
>
> <-- snip -->
>
> ...
> CC block/blk-barrier.o
> /home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c: In function ???blk_do_ordered???:
> /home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c:57: sorry, unimplemented: inlining failed in call to ???blk_ordered_cur_seq???: function body not available
> /home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c:252: sorry, unimplemented: called from here
> /home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c:57: sorry, unimplemented: inlining failed in call to ???blk_ordered_cur_seq???: function body not available
> /home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c:253: sorry, unimplemented: called from here
> make[2]: *** [block/blk-barrier.o] Error 1
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk

Applied

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, Apr 28, 2008 at 05:41:11PM -0700, Linus Torvalds wrote:
>...
> > -inline struct block_device *I_BDEV(struct inode *inode)
> > +struct block_device *I_BDEV(struct inode *inode)
> > {
> > return &BDEV_I(inode)->bdev;
> > }
>
> There is NO WAY IN HELL this function shouldn't be inlined,
>...

Then CONFIG_OPTIMIZE_INLINING already broke it in your tree.

> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, Apr 29, 2008 at 11:06:31AM +0300, Adrian Bunk wrote:
> On Mon, Apr 28, 2008 at 05:41:11PM -0700, Linus Torvalds wrote:
> >...
> > > -inline struct block_device *I_BDEV(struct inode *inode)
> > > +struct block_device *I_BDEV(struct inode *inode)
> > > {
> > > return &BDEV_I(inode)->bdev;
> > > }
> >
> > There is NO WAY IN HELL this function shouldn't be inlined,
> >...
>
> Then CONFIG_OPTIMIZE_INLINING already broke it in your tree.

Can you please help me here.
Previously we said: gcc shall inline
Now we say: hi gcc - it is a good idea to inline this

But even without any inline annotation we would expect gcc
to inline it based on normal heuristics simply due to the
small size/footprint of the function.

So I cannot see how the CONFIG_OPTIMIZE_INLINING have any
effect here.
It all smells like a gcc bug to me.


Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, Apr 29, 2008 at 10:17:05AM +0200, Sam Ravnborg wrote:
> On Tue, Apr 29, 2008 at 11:06:31AM +0300, Adrian Bunk wrote:
> > On Mon, Apr 28, 2008 at 05:41:11PM -0700, Linus Torvalds wrote:
> > >...
> > > > -inline struct block_device *I_BDEV(struct inode *inode)
> > > > +struct block_device *I_BDEV(struct inode *inode)
> > > > {
> > > > return &BDEV_I(inode)->bdev;
> > > > }
> > >
> > > There is NO WAY IN HELL this function shouldn't be inlined,
> > >...
> >
> > Then CONFIG_OPTIMIZE_INLINING already broke it in your tree.
>
> Can you please help me here.
> Previously we said: gcc shall inline
> Now we say: hi gcc - it is a good idea to inline this

Previosly we said:
"inline" means "must inline"

With CONFIG_OPTIMIZE_INLINING=y we say:
"inline" means "try a bit harder to inline"

> But even without any inline annotation we would expect gcc
> to inline it based on normal heuristics simply due to the
> small size/footprint of the function.

gcc anyway has to emit one global copy of this function.

And with the common CONFIG_CC_OPTIMIZE_FOR_SIZE=y we tell gcc to focus
on getting the smallest possible code.

> So I cannot see how the CONFIG_OPTIMIZE_INLINING have any
> effect here.
> It all smells like a gcc bug to me.

The compile error is a gcc bug.

> Sam

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Monday 28 April 2008 19:38, Adrian Bunk wrote:
> This patch fixes the following build errors with UML and gcc 4.3:
>
> <-- snip -->
>
> ...
> CC fs/reiserfs/do_balan.o
> /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c: In function ‘balance_leaf’:
> /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c:34: sorry, unimplemented: inlining failed in call to ‘do_balance_mark_leaf_dirty’: function body not available
> /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c:1018: sorry, unimplemented: called from here
> /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c:34: sorry, unimplemented: inlining failed in call to ‘do_balance_mark_leaf_dirty’: function body not available
> /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c:1174: sorry, unimplemented: called from here
> make[3]: *** [fs/reiserfs/do_balan.o] Error 1

Hello.
I would make some of them static inline (my version is appended).

Thanks,
Edward.

Make the following functions static inline:

.. do_balance_mark_leaf_dirty
.. set_de_name_and_namelen
.. comp_short_keys
.. B_IS_IN_TREE
.. copy_item_head
.. le_key2cpu_key
.. decrement_bcount

Signed-off-by: Edward Shishkin

---
linux-2.6.25-mm1/fs/reiserfs/do_balan.c | 10 --
linux-2.6.25-mm1/fs/reiserfs/inode.c | 8 +-
linux-2.6.25-mm1/fs/reiserfs/namei.c | 12 ---
linux-2.6.25-mm1/fs/reiserfs/stree.c | 77 ---------------------
linux-2.6.25-mm1/include/linux/reiserfs_fs.h | 99 +++++++++++++++++++++++----
5 files changed, 93 insertions(+), 113 deletions(-)

--- linux-2.6.25-mm1/fs/reiserfs/do_balan.c.orig
+++ linux-2.6.25-mm1/fs/reiserfs/do_balan.c
@@ -29,16 +29,6 @@
is interrupting do_balance */
#endif

-inline void do_balance_mark_leaf_dirty(struct tree_balance *tb,
- struct buffer_head *bh, int flag)
-{
- journal_mark_dirty(tb->transaction_handle,
- tb->transaction_handle->t_super, bh);
-}
-
-#define do_balance_mark_internal_dirty do_balance_mark_leaf_dirty
-#define do_balance_mark_sb_dirty do_balance_mark_leaf_dirty
-
/* summary:
if deleting something ( tb->insert_size[0] < 0 )
return(balance_leaf_when_delete()); (flag d handled here)
--- linux-2.6.25-mm1/fs/reiserfs/inode.c.orig
+++ linux-2.6.25-mm1/fs/reiserfs/inode.c
@@ -101,10 +101,10 @@
//
// when key is 0, do not set version and short key
//
-inline void make_le_item_head(struct item_head *ih, const struct cpu_key *key,
- int version,
- loff_t offset, int type, int length,
- int entry_count /*or ih_free_space */ )
+void make_le_item_head(struct item_head *ih, const struct cpu_key *key,
+ int version,
+ loff_t offset, int type, int length,
+ int entry_count /*or ih_free_space */ )
{
if (key) {
ih->ih_key.k_dir_id = cpu_to_le32(key->on_disk_key.k_dir_id);
--- linux-2.6.25-mm1/fs/reiserfs/namei.c.orig
+++ linux-2.6.25-mm1/fs/reiserfs/namei.c
@@ -62,18 +62,6 @@
}

// de_bh, de_ih, de_deh (points to first element of array), de_item_num is set
-inline void set_de_name_and_namelen(struct reiserfs_dir_entry *de)
-{
- struct reiserfs_de_head *deh = de->de_deh + de->de_entry_num;
-
- BUG_ON(de->de_entry_num >= ih_entry_count(de->de_ih));
-
- de->de_entrylen = entry_length(de->de_bh, de->de_ih, de->de_entry_num);
- de->de_namelen = de->de_entrylen - (de_with_sd(deh) ? SD_SIZE : 0);
- de->de_name = B_I_PITEM(de->de_bh, de->de_ih) + deh_location(deh);
- if (de->de_name[de->de_namelen - 1] == 0)
- de->de_namelen = strlen(de->de_name);
-}

// what entry points to
static inline void set_de_object_key(struct reiserfs_dir_entry *de)
--- linux-2.6.25-mm1/fs/reiserfs/stree.c.orig
+++ linux-2.6.25-mm1/fs/reiserfs/stree.c
@@ -11,18 +11,13 @@
/*
* This file contains functions dealing with S+tree
*
- * B_IS_IN_TREE
- * copy_item_head
- * comp_short_keys
* comp_keys
* comp_short_le_keys
- * le_key2cpu_key
* comp_le_keys
* bin_search
* get_lkey
* get_rkey
* key_in_buffer
- * decrement_bcount
* decrement_counters_in_path
* reiserfs_check_path
* pathrelse_and_restore
@@ -56,48 +51,6 @@
#include
#include

-/* Does the buffer contain a disk block which is in the tree. */
-inline int B_IS_IN_TREE(const struct buffer_head *p_s_bh)
-{
-
- RFALSE(B_LEVEL(p_s_bh) > MAX_HEIGHT,
- "PAP-1010: block (%b) has too big level (%z)", p_s_bh, p_s_bh);
-
- return (B_LEVEL(p_s_bh) != FREE_LEVEL);
-}
-
-//
-// to gets item head in le form
-//
-inline void copy_item_head(struct item_head *p_v_to,
- const struct item_head *p_v_from)
-{
- memcpy(p_v_to, p_v_from, IH_SIZE);
-}
-
-/* k1 is pointer to on-disk structure which is stored in little-endian
- form. k2 is pointer to cpu variable. For key of items of the same
- object this returns 0.
- Returns: -1 if key1 < key2
- 0 if key1 == key2
- 1 if key1 > key2 */
-inline int comp_short_keys(const struct reiserfs_key *le_key,
- const struct cpu_key *cpu_key)
-{
- __u32 n;
- n = le32_to_cpu(le_key->k_dir_id);
- if (n < cpu_key->on_disk_key.k_dir_id)
- return -1;
- if (n > cpu_key->on_disk_key.k_dir_id)
- return 1;
- n = le32_to_cpu(le_key->k_objectid);
- if (n < cpu_key->on_disk_key.k_objectid)
- return -1;
- if (n > cpu_key->on_disk_key.k_objectid)
- return 1;
- return 0;
-}
-
/* k1 is pointer to on-disk structure which is stored in little-endian
form. k2 is pointer to cpu variable.
Compare keys using all 4 key fields.
@@ -150,19 +103,6 @@
return 0;
}

-inline void le_key2cpu_key(struct cpu_key *to, const struct reiserfs_key *from)
-{
- int version;
- to->on_disk_key.k_dir_id = le32_to_cpu(from->k_dir_id);
- to->on_disk_key.k_objectid = le32_to_cpu(from->k_objectid);
-
- // find out version of the key
- version = le_key_version(from);
- to->version = version;
- to->on_disk_key.k_offset = le_key_k_offset(version, from);
- to->on_disk_key.k_type = le_key_k_type(version, from);
-}
-
// this does not say which one is bigger, it only returns 1 if keys
// are not equal, 0 otherwise
inline int comp_le_keys(const struct reiserfs_key *k1,
@@ -289,8 +229,8 @@
}

/* Get delimiting key of the buffer at the path and its right neighbor. */
-inline const struct reiserfs_key *get_rkey(const struct treepath *p_s_chk_path,
- const struct super_block *p_s_sb)
+const struct reiserfs_key *get_rkey(const struct treepath *p_s_chk_path,
+ const struct super_block *p_s_sb)
{
int n_position, n_path_offset = p_s_chk_path->path_length;
struct buffer_head *p_s_parent;
@@ -359,19 +299,6 @@
return 1;
}

-inline void decrement_bcount(struct buffer_head *p_s_bh)
-{
- if (p_s_bh) {
- if (atomic_read(&(p_s_bh->b_count))) {
- put_bh(p_s_bh);
- return;
- }
- reiserfs_panic(NULL,
- "PAP-5070: decrement_bcount: trying to free free buffer %b",
- p_s_bh);
- }
-}
-
/* Decrement b_count field of the all buffers in the path. */
void decrement_counters_in_path(struct treepath *p_s_search_path)
{
--- linux-2.6.25-mm1/include/linux/reiserfs_fs.h.orig
+++ linux-2.6.25-mm1/include/linux/reiserfs_fs.h
@@ -1770,14 +1770,37 @@
int reiserfs_convert_objectid_map_v1(struct super_block *);

/* stree.c */
-int B_IS_IN_TREE(const struct buffer_head *);
-extern void copy_item_head(struct item_head *p_v_to,
- const struct item_head *p_v_from);
-
-// first key is in cpu form, second - le
-extern int comp_short_keys(const struct reiserfs_key *le_key,
- const struct cpu_key *cpu_key);
-extern void le_key2cpu_key(struct cpu_key *to, const struct reiserfs_key *from);
+
+/* to get item head in le form */
+static inline void copy_item_head(struct item_head *p_v_to,
+ const struct item_head *p_v_from)
+{
+ memcpy(p_v_to, p_v_from, IH_SIZE);
+}
+
+/* first key is in cpu form, second - le */
+/* k1 is pointer to on-disk structure which is stored in little-endian
+ form. k2 is pointer to cpu variable. For key of items of the same
+ object this returns 0.
+ Returns: -1 if key1 < key2
+ 0 if key1 == key2
+ 1 if key1 > key2 */
+static inline int comp_short_keys(const struct reiserfs_key *le_key,
+ const struct cpu_key *cpu_key)
+{
+ __u32 n;
+ n = le32_to_cpu(le_key->k_dir_id);
+ if (n < cpu_key->on_disk_key.k_dir_id)
+ return -1;
+ if (n > cpu_key->on_disk_key.k_dir_id)
+ return 1;
+ n = le32_to_cpu(le_key->k_objectid);
+ if (n < cpu_key->on_disk_key.k_objectid)
+ return -1;
+ if (n > cpu_key->on_disk_key.k_objectid)
+ return 1;
+ return 0;
+}

// both are in le form
extern int comp_le_keys(const struct reiserfs_key *,
@@ -1801,6 +1824,20 @@

}

+static inline void le_key2cpu_key(struct cpu_key *to,
+ const struct reiserfs_key *from)
+{
+ int version;
+ to->on_disk_key.k_dir_id = le32_to_cpu(from->k_dir_id);
+ to->on_disk_key.k_objectid = le32_to_cpu(from->k_objectid);
+
+ // find out version of the key
+ version = le_key_version(from);
+ to->version = version;
+ to->on_disk_key.k_offset = le_key_k_offset(version, from);
+ to->on_disk_key.k_type = le_key_k_type(version, from);
+}
+
static inline void copy_key(struct reiserfs_key *to,
const struct reiserfs_key *from)
{
@@ -1816,7 +1853,6 @@
int search_for_position_by_key(struct super_block *p_s_sb,
const struct cpu_key *p_s_cpu_key,
struct treepath *p_s_search_path);
-extern void decrement_bcount(struct buffer_head *p_s_bh);
void decrement_counters_in_path(struct treepath *p_s_search_path);
void pathrelse(struct treepath *p_s_search_path);
int reiserfs_check_path(struct treepath *p);
@@ -1913,7 +1949,19 @@
int reiserfs_setattr(struct dentry *dentry, struct iattr *attr);

/* namei.c */
-void set_de_name_and_namelen(struct reiserfs_dir_entry *de);
+static inline void set_de_name_and_namelen(struct reiserfs_dir_entry *de)
+{
+ struct reiserfs_de_head *deh = de->de_deh + de->de_entry_num;
+
+ BUG_ON(de->de_entry_num >= ih_entry_count(de->de_ih));
+
+ de->de_entrylen = entry_length(de->de_bh, de->de_ih, de->de_entry_num);
+ de->de_namelen = de->de_entrylen - (de_with_sd(deh) ? SD_SIZE : 0);
+ de->de_name = B_I_PITEM(de->de_bh, de->de_ih) + deh_location(deh);
+ if (de->de_name[de->de_namelen - 1] == 0)
+ de->de_namelen = strlen(de->de_name);
+}
+
int search_by_entry_key(struct super_block *sb, const struct cpu_key *key,
struct treepath *path, struct reiserfs_dir_entry *de);
struct dentry *reiserfs_get_parent(struct dentry *);
@@ -2030,8 +2078,12 @@
struct buffer_head **);

/* do_balance.c */
-void do_balance_mark_leaf_dirty(struct tree_balance *tb,
- struct buffer_head *bh, int flag);
+static inline void do_balance_mark_leaf_dirty(struct tree_balance *tb,
+ struct buffer_head *bh, int flag)
+{
+ journal_mark_dirty(tb->transaction_handle,
+ tb->transaction_handle->t_super, bh);
+}
#define do_balance_mark_internal_dirty do_balance_mark_leaf_dirty
#define do_balance_mark_sb_dirty do_balance_mark_leaf_dirty

@@ -2148,6 +2200,29 @@
void reiserfs_discard_all_prealloc(struct reiserfs_transaction_handle *th);
#endif

+static inline void decrement_bcount(struct buffer_head *p_s_bh)
+{
+ if (p_s_bh) {
+ if (atomic_read(&(p_s_bh->b_count))) {
+ put_bh(p_s_bh);
+ return;
+ }
+ reiserfs_panic(NULL,
+ "PAP-5070: decrement_bcount: trying to free free buffer %b",
+ p_s_bh);
+ }
+}
+
+/* Does the buffer contain a disk block which is in the tree. */
+static inline int B_IS_IN_TREE(const struct buffer_head *p_s_bh)
+{
+
+ RFALSE(B_LEVEL(p_s_bh) > MAX_HEIGHT,
+ "PAP-1010: block (%b) has too big level (%z)", p_s_bh, p_s_bh);
+
+ return (B_LEVEL(p_s_bh) != FREE_LEVEL);
+}
+
/* hashes.c */
__u32 keyed_hash(const signed char *msg, int len);
__u32 yura_hash(const signed char *msg, int len);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/