From: Michal Hocko <mhocko@suse.cz>
To: Ilija Hadzic <ilijahadzic@gmail.com>
Cc: dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
Thomas Hellstrom <thellstrom@vmware.com>,
Marco Munderloh <munderl@tnt.uni-hannover.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path
Date: Sun, 31 Mar 2013 12:34:18 +0200 [thread overview]
Message-ID: <20130331103418.GA18476@dhcp22.suse.cz> (raw)
In-Reply-To: <CA+4h6Hnhm-Ox_5dRdBH3C9Lh_qVNac8_oL=3ruy75jBX7xp9OQ@mail.gmail.com>
On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
> This looks a bit like a hack and it doesn't look right,
> conceptually. If the call fails, it should restore things as if
> nothing has ever happened and overwriting old_mapping is not going to
> do the trick.
OK, I thought this is what the patch does as it falls back to
&inode->i_data which is the default mapping for all inodes or it uses
what used to be in device mapping.
I am obviously not familiar with the drm code but it feels a bit strange
that the device mapping can be different than inode's resp. file's one
and even more confusing that inode and file are saved separately.
> I think the right way to fix it would be to separately store the
> original mapping for filp->f_mapping and inode->i_mapping and restore
> it from their respective temporary variables if drm_open_helper or
> drm_setup fail. Attached is a quick patch to show you
[...]
> @@ -137,6 +139,8 @@ int drm_open(struct inode *inode, struct file *filp)
> if (!dev->open_count++)
> need_setup = 1;
> mutex_lock(&dev->struct_mutex);
> + old_fmapping = filp->f_mapping;
> + old_imapping = inode->i_mapping;
How can file and inode mappings be different?
> old_mapping = dev->dev_mapping;
> if (old_mapping == NULL)
> dev->dev_mapping = &inode->i_data;
> @@ -159,8 +163,8 @@ int drm_open(struct inode *inode, struct file *filp)
>
> err_undo:
> mutex_lock(&dev->struct_mutex);
> - filp->f_mapping = old_mapping;
> - inode->i_mapping = old_mapping;
> + filp->f_mapping = old_fmapping;
> + inode->i_mapping = old_imapping;
> iput(container_of(dev->dev_mapping, struct inode, i_data));
> dev->dev_mapping = old_mapping;
> mutex_unlock(&dev->struct_mutex);
--
1.8.1.5
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2013-03-31 10:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 19:56 [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path Michal Hocko
2013-03-30 22:26 ` Ilija Hadzic
2013-03-31 10:34 ` Michal Hocko [this message]
2013-04-01 18:14 ` Ilija Hadzic
2013-04-02 8:25 ` Michal Hocko
2013-04-02 10:36 ` Marco Munderloh
[not found] ` <CA+4h6HkOSPUpfT-5Hwe+zRkmSdhURM6Tv4RxM+9PMCEvG+tjZw@mail.gmail.com>
2013-04-02 12:01 ` Marco Munderloh
2013-04-02 13:31 ` Ilija Hadzic
2013-04-02 13:48 ` Alex Deucher
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=20130331103418.GA18476@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=ilijahadzic@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=munderl@tnt.uni-hannover.de \
--cc=thellstrom@vmware.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