On Fri, Apr 04, 2014 at 11:03:16AM +0800, Liu Bo wrote:
On Thu, Apr 03, 2014 at 06:18:40PM +0200, David Sterba wrote:
On Thu, Apr 03, 2014 at 01:34:23PM +0800, Liu Bo wrote:
On Wed, Apr 02, 2014 at 07:13:00PM +0200, David Sterba wrote:
Commit fae7f21cece9a4c181 (btrfs: Use WARN_ON()'s
On Thu, Apr 03, 2014 at 01:34:23PM +0800, Liu Bo wrote:
On Wed, Apr 02, 2014 at 07:13:00PM +0200, David Sterba wrote:
Commit fae7f21cece9a4c181 (btrfs: Use WARN_ON()'s return value in place of
WARN_ON(1)) cleaned up WARN_ON usage and in one place reversed the
condition
that led to loads
On Thu, Apr 03, 2014 at 06:18:40PM +0200, David Sterba wrote:
On Thu, Apr 03, 2014 at 01:34:23PM +0800, Liu Bo wrote:
On Wed, Apr 02, 2014 at 07:13:00PM +0200, David Sterba wrote:
Commit fae7f21cece9a4c181 (btrfs: Use WARN_ON()'s return value in place
of
WARN_ON(1)) cleaned up WARN_ON
Commit fae7f21cece9a4c181 (btrfs: Use WARN_ON()'s return value in place of
WARN_ON(1)) cleaned up WARN_ON usage and in one place reversed the condition
that led to loads of warnings that were not supposed to occur.
WARN_ON will trigger because it sees 'ret' though in the previous code
did not
On Wed, Apr 02, 2014 at 07:13:00PM +0200, David Sterba wrote:
Commit fae7f21cece9a4c181 (btrfs: Use WARN_ON()'s return value in place of
WARN_ON(1)) cleaned up WARN_ON usage and in one place reversed the condition
that led to loads of warnings that were not supposed to occur.
WARN_ON will
On Wed, Apr 02, 2014 at 07:13:00PM +0200, David Sterba wrote:
Commit fae7f21cece9a4c181 (btrfs: Use WARN_ON()'s return value in place of
WARN_ON(1)) cleaned up WARN_ON usage and in one place reversed the condition
that led to loads of warnings that were not supposed to occur.
WARN_ON will