public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Horacio Mijail Antón Quiles" <hmijail@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	David Howells <dhowells@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	linux-kernel@vger.kernel.org, trivial@kernel.org,
	Joe Perches <joe@perches.com>
Subject: [RESEND][PATCH v4] hexdump: fix for non-aligned buffers
Date: Mon, 29 Jun 2015 19:41:47 +0200	[thread overview]
Message-ID: <20150629174147.GA5757@mija-VirtualBox> (raw)

An hexdump with a buf not aligned to the groupsize causes
non-naturally-aligned memory accesses. This was causing a kernel panic on
the processor BlackFin BF527, when such an unaligned buffer was fed by the
function ubifs_scanned_corruption in fs/ubifs/scan.c .

To fix this, if the buffer is not aligned to groupsize in a platform which
does not define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, then change the
groupsize to 1, so alignment is no longer a problem.
This behavior is coherent with the way the function currently deals with
inappropriate parameter combinations, which is to fall back to safe
"defaults", even if that means changing the output format and the implicit
access patterns that could have been expected.

Signed-off-by: Horacio Mijail Antón Quiles <hmijail@gmail.com>
---
Changes in v4:
 - Added space before "*/" (per Joe Perches' indication)

Changes in v3:
 - Removed trailing whitespace (per Joe Perches' indication)
 - Changed git-generated mail header to avoid encoding issues (per
     Joe Perches' hint)
  
Changes in v2:
  - Changed from ad-hoc calculation to IS_ALIGNED() for readability (per 
      Joe Perches' indication)
  - Made the explanation clearer (aligned vs naturally aligned)

---
 lib/hexdump.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/lib/hexdump.c b/lib/hexdump.c
index 7ea0969..a3bd5d5 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -124,6 +124,11 @@ int hex_dump_to_buffer(const void *buf, size_t len, int rowsize, int groupsize,
 	if ((len % groupsize) != 0)	/* no mixed size output */
 		groupsize = 1;
 
+	/* fall back to 1-byte groups if buf is not aligned to groupsize */
+	if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) &&
+	    !IS_ALIGNED((uintptr_t)buf, groupsize))
+		groupsize = 1;
+
 	ngroups = len / groupsize;
 	ascii_column = rowsize * 2 + rowsize / groupsize + 1;
 
-- 
2.1.4


                 reply	other threads:[~2015-06-29 17:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150629174147.GA5757@mija-VirtualBox \
    --to=hmijail@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dhowells@redhat.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trivial@kernel.org \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox