On Fri 04-10-13 16:42:19, KOSAKI Motohiro wrote:
> (10/4/13 4:31 PM), KOSAKI Motohiro wrote:
> >(10/2/13 4:29 PM), Jan Kara wrote:
> >>On Wed 02-10-13 09:20:09, Christoph Hellwig wrote:
> >>>On Wed, Oct 02, 2013 at 04:27:41PM +0200, Jan Kara wrote:
> >>>> Hello,
> >>>>
> >>>> In my quest for changing locking around page faults to make things easier for
> >>>>filesystems I found out get_user_pages() …
[View More]users could use a cleanup. The
> >>>>knowledge about necessary locking for get_user_pages() is in tons of places in
> >>>>drivers and quite a few of them actually get it wrong (don't have mmap_sem when
> >>>>calling get_user_pages() or hold mmap_sem when calling copy_from_user() in the
> >>>>surrounding code). Rather often this actually doesn't seem necessary. This
> >>>>patch series converts lots of places to use either get_user_pages_fast()
> >>>>or a new simple wrapper get_user_pages_unlocked() to remove the knowledge
> >>>>of mmap_sem from the drivers. I'm still looking into converting a few remaining
> >>>>drivers (most notably v4l2) which are more complex.
> >>>
> >>>Even looking over the kerneldoc comment next to it I still fail to
> >>>understand when you'd want to use get_user_pages_fast and when not.
> >> AFAIU get_user_pages_fast() should be used
> >>1) if you don't need any special get_user_pages() arguments (like calling
> >> it for mm of a different process, forcing COW, or similar).
> >>2) you don't expect pages to be unmapped (then get_user_pages_fast() is
> >>actually somewhat slower because it walks page tables twice).
> >
> >If target page point to anon or private mapping pages, get_user_pages_fast()
> >is fork unsafe. O_DIRECT man pages describe a bit about this.
> >
> >
> >see http://man7.org/linux/man-pages/man2/open.2.html
> >
> >> O_DIRECT I/Os should never be run concurrently with the fork(2)
> >> system call, if the memory buffer is a private mapping (i.e., any
> >> mapping created with the mmap(2) MAP_PRIVATE flag; this includes
> >> memory allocated on the heap and statically allocated buffers). Any
> >> such I/Os, whether submitted via an asynchronous I/O interface or
> >> from another thread in the process, should be completed before
> >> fork(2) is called. Failure to do so can result in data corruption
> >> and undefined behavior in parent and child processes. This
> >> restriction does not apply when the memory buffer for the O_DIRECT
> >> I/Os was created using shmat(2) or mmap(2) with the MAP_SHARED flag.
> >> Nor does this restriction apply when the memory buffer has been
> >> advised as MADV_DONTFORK with madvise(2), ensuring that it will not
> >> be available to the child after fork(2).
>
> IMHO, get_user_pages_fast() should be renamed to get_user_pages_quirk(). Its
> semantics is not equal to get_user_pages(). When someone simply substitute
> get_user_pages() to get_user_pages_fast(), they might see huge trouble.
I forgot about this speciality (and actually comments didn't remind me
:(). But thinking about this some more get_user_pages_fast() seems as save
as get_user_pages() in presence of threads sharing mm, doesn't it? Because
while get_user_pages() are working, other thread can happilly trigger COW
on some of the pages and thus get_user_pages() can return pages some of
which are invisible in our mm by the time get_user_pages() returns. So
although in practice I agree problems of get_user_pages_fast() with fork(2)
are more visible, in essence they are still present with clone(2) and
get_user_pages().
Honza
--
Jan Kara <jack(a)suse.cz>
SUSE Labs, CR
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=59720
Priority: medium
Bug ID: 59720
Assignee: dri-devel(a)lists.freedesktop.org
Summary: kwin_gles freezes on Mesa from git
Severity: critical
Classification: Unclassified
OS: Linux (All)
Reporter: ken20001(a)ukr.net
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
…
[View More]Created attachment 73459
--> https://bugs.freedesktop.org/attachment.cgi?id=73459&action=edit
kwin_gles backtrace logfile
Using kwin_gles instead of kwin causes freeze after entering KDE. This bug is
reproducible not each time when starting kwin_gles by hand but it's
reproducible almost each time when kwin_gles starting automatically with system
booting. This issue appeared since Jan. ~18-20.
kwin developers believe that problem is in driver. Here is bug report:
https://bugs.kde.org/show_bug.cgi?id=313599
While freeze moment turning compositing off gives nothing. But switching from
kwin_gles to kwin from any VT unfreezes desktop.
Software:
Kubuntu 12.10 x86_64
Linux 3.5.0-22
KDE 4.9.5, desktop effects enabled.
Mesa: 2.1 Mesa 9.1-devel (git-148fc6d quantal-oibaf-ppa)
libdrm-radeon1: 2.4.41+git1301220934.303ca3~gd~q
xserver-xorg-video-radeon: 1:7.0.0+git1301160928.102ee4~gd~q
xserver-xorg-core: 2:1.13.0-0ubuntu6.1
Hardware:
Intel C2D 7200
ASUS P5B Deluxe
AMD Radeon HD 2600 TX
Note. Please se in atachment: kwin_gles backtrace logfile (the same is on
https://bugs.kde.org/show_bug.cgi?id=313599) and two log files with driver
versions that was upgraded at Jan. 18 and Jan. 20.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=69729
Priority: medium
Bug ID: 69729
Assignee: dri-devel(a)lists.freedesktop.org
Summary: HDMI audio stopped working on HD 3470 (RV620/M82)
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: paul.bodenbenner(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: unspecified
Component: DRM/Radeon
…
[View More] Product: DRI
Using Arch Linux 64 bit on HD 3470 (RV620/M82). With kernel 3.10.10 HDMI audio
did work and with no other package changed, audio over HDMI doesn't work
anymore with kernel 3.11.1.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=54867
Bug #: 54867
Summary: bug in r300 compiler
Classification: Unclassified
Product: Mesa
Version: git
Platform: All
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: son_of_the_osiris(a)interia.pl
Orginally posted …
[View More]on mailing list:
In playing with Coccinelle, I discovered a signed/unsigned bug in
radeon_rename_regs.c:rc_rename_regs.
unsigned new_index;
unsigned writemask;
struct rc_variable * var = var_ptr->Item;
if (var->Inst->U.I.DstReg.File != RC_FILE_TEMPORARY) {
continue;
}
new_index = rc_find_free_temporary_list(c, used, used_length,
RC_MASK_XYZW);
if (new_index < 0) {
rc_error(c, "Ran out of temporary registers\n");
return;
}
unsigned new_index is compared with < 0.
I don't know the code, but I can't imagine that you'd need an unsigned
to represent a register index value.
Matt Turner
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]