All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: linux-fbdev@vger.kernel.org
Subject: Re: fb_write unaligned writes
Date: Fri, 17 Sep 2010 18:11:00 +0000	[thread overview]
Message-ID: <4C93AF34.4030308@gmx.de> (raw)
In-Reply-To: <201009092338.59880.james@albanarts.com>

Hi,

James Hogan schrieb:
> Hi,
> 
> I came across a problem in fb_write (drivers/video/fbmem.c) which doesn't make 
> any effort to avoid unaligned writes. It copies up to a page at a time from 
> userspace into a buffer, then fb_writel's as much as possible from the buffer 
> into the framebuffer, then fb_writeb's any remaining bytes. However on 
> architectures which don't perform unaligned writes this can cause a bus error 
> or silently fail when it tries to fb_writel to an unaligned framebuffer 
> position.
> 
> My question is how best should this be fixed? I know I could avoid writing 
> more than 3 bytes to an unaligned framebuffer offset, but the standard write 
> syscall should be able to handle this, and Documentation/unaligned-memory-
> access.txt makes it clear that unaligned accesses are to be avoided and with 
> good reason.
> 
> Is it possible to just copy_from_user straight into the framebuffer, or should 
> I define an fb_memcpy to go with the other definitions around line 925 of 
> include/linux/fb.h, or something else?

Just doing copy_from_user straight into the framebuffer sounds like the right 
thing to me but my knowledge is limited to x86. As far as I can see this would 
make the functions (doing the same for fb_read can't hurt, can it?) in fbmem.c 
very similar to those in fb_sys_fops.c. Most users of the later functions can be 
easily eliminated as simply removing ".fb_{read,write} = fb_sys_{read,write}" is 
sufficient, only xen-fbfront.c looks more difficult as it also refreshes the 
screen so I'd suggest the following:
Merging fb_sys_fops.c in fbmem.c, adjusting the fb_{read,write} functions to use 
the the fb_sys_{read,write} copying and removing all trivial uses of 
fb_sys_{read,write}. As far as I can see this should solve your problem and 
would be a cleanup at the same time.
But it would be good if someone who knows other archs (especially sparc as they 
currently seem to perform some assembler that I can't decipher) could comment on 
this topic.


Thanks,

Florian Tobias Schandinat

  reply	other threads:[~2010-09-17 18:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-09 22:38 fb_write unaligned writes James Hogan
2010-09-17 18:11 ` Florian Tobias Schandinat [this message]
2010-09-17 23:57 ` [PATCH] fbmem: Fix fb_read, fb_write unaligned accesses James Hogan
2010-09-17 23:57   ` James Hogan
2010-09-18  0:15   ` David Miller
2010-09-18  0:15     ` David Miller
2010-09-18  0:23   ` James Hogan
2010-09-18  0:23     ` James Hogan
2010-09-18  3:17     ` David Miller
2010-09-18  3:17       ` David Miller
2010-09-20 19:27     ` Florian Tobias Schandinat
2010-09-20 19:27       ` Florian Tobias Schandinat
2010-09-21 23:19     ` Andrew Morton
2010-09-21 23:19       ` Andrew Morton
2010-09-22  0:00       ` James Hogan
2010-09-22  0:00         ` James Hogan
2010-09-18  0:11 ` fb_write unaligned writes James Hogan

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=4C93AF34.4030308@gmx.de \
    --to=florianschandinat@gmx.de \
    --cc=linux-fbdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.