Message ID | CAGG-pUTqVk5JkhWDU6-EicWzQT-rhiXBuXRm6uPmVSVifQ_FzQ@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
2013/10/28 Geyslan Gregório Bem <geyslan@gmail.com>: > 2013/10/28 Geyslan Gregório Bem <geyslan@gmail.com> >> >> 2013/10/27 Eric Van Hensbergen <ericvh@gmail.com> >>> >>> Looks like the right approach. The one other optional thing I mentioned was support for passing NULL for rdev and not trying to parse the device info when rdev == NULL. Its a very slight optimization in the grand scheme of things, but would seem to be cleaner for the folks calling the function who don't touch rdev after the fact... >>> >>> -eric >>> >> Great. Let me do the changes this afternoon. >> >> > Hi Eric and all. > > You requested to avoid the parsing of device when rdev is NULL, all > right? But I'm afraid that that manner the res (return value) can be > returned wrong when the bit mode is a device. Well, I did some > changes. In this new approach, when rdev is NULL, the function only > doesn't make the device, but returns the res (umode_t) nicely. > > Tell me if this approach is correct. Do I have to modify something else? > > -- > Regards, > > Geyslan G. Bem > hackingbits.com Eric, I sent the new patch: [PATCH] 9p: code refactor in vfs_inode.c
okay, thanks. It might not make this merge window because time is so short, but I'll try to get some time to bring it in today or tomorrow. If it doesn't make this one, it'll be queued up for the next. -eric On Tue, Oct 29, 2013 at 3:59 PM, Geyslan Gregório Bem <geyslan@gmail.com>wrote: > 2013/10/28 Geyslan Gregório Bem <geyslan@gmail.com>: > > 2013/10/28 Geyslan Gregório Bem <geyslan@gmail.com> > >> > >> 2013/10/27 Eric Van Hensbergen <ericvh@gmail.com> > >>> > >>> Looks like the right approach. The one other optional thing I > mentioned was support for passing NULL for rdev and not trying to parse the > device info when rdev == NULL. Its a very slight optimization in the grand > scheme of things, but would seem to be cleaner for the folks calling the > function who don't touch rdev after the fact... > >>> > >>> -eric > >>> > >> Great. Let me do the changes this afternoon. > >> > >> > > Hi Eric and all. > > > > You requested to avoid the parsing of device when rdev is NULL, all > > right? But I'm afraid that that manner the res (return value) can be > > returned wrong when the bit mode is a device. Well, I did some > > changes. In this new approach, when rdev is NULL, the function only > > doesn't make the device, but returns the res (umode_t) nicely. > > > > Tell me if this approach is correct. Do I have to modify something else? > > > > -- > > Regards, > > > > Geyslan G. Bem > > hackingbits.com > > Eric, I sent the new patch: > [PATCH] 9p: code refactor in vfs_inode.c > > -- > Regards, > > Geyslan G. Bem > hackingbits.com > ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c index 94de6d1..e3d56f1 100644 --- a/fs/9p/vfs_inode.c +++ b/fs/9p/vfs_inode.c @@ -63,7 +63,7 @@ static const struct inode_operations v9fs_symlink_inode_operations; static u32 unixmode2p9mode(struct v9fs_session_info *v9ses, umode_t mode) { - int res; + u32 res; res = mode & 0777; if (S_ISDIR(mode))