Re: [PATCH v3] staging: usbip: userspace: add support for viewing imported devices

Reviewed-by: Ilija Hadzic On Tue, 24 Dec 2013, Valentina Manea wrote: As of Matt Mooney's major refactoring in 2011, usbip port option was left out. Add support for this option in a manner similar to the old implementation. Sample output: Imported USB devices Po

Re: [PATCH v2] staging: usbip: add support for viewing imported devices

This looks better, but there are still two minor issues: You have one trailing whtespace error. Please the scripts/checkpatch.pl script on the patch and correct the error. The title of the commit message should indicate that this is an userspace patch (this seems to be the convention that ot

Re: [PATCH] staging: usbip: add support for viewing imported devices

On Mon, 23 Dec 2013, Valentina Manea wrote: As of Matt Mooney's major refactoring in 2011, usbip port option was left out. Add support for this option in a manner similar to the old implementation. Yeah, I guess most people (incluing myself) have been just happy with just cat-ing the files

[PATCH] devpts: plug the memory leak in kill_sb

, shutting down an LXC container instead of a physical machine exposes the problem (the garbage is detectable with kmemleak). Signed-off-by: Ilija Hadzic Cc: sta...@vger.kernel.org --- fs/devpts/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index

Re: Standalone DRM application

On Thu, 18 Apr 2013, David Herrmann wrote: Hi On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek wrote: David, I'm developing a small application that uses libdrm (DRM ioctls) to change the resolution of a single graphics display and show a framebuffer. I've run into two problems with this

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

Best, Marco On 02.04.2013 13:23, Ilija Hadzic wrote: -- Ilija On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh mailto:mund...@tnt.uni-hannover.de>> wrote: Attached is a v2 of the patch, for reference. I would appreciate if the original reporter or you tested it in lieu of your propo

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

On Sun, 31 Mar 2013, Michal Hocko wrote: 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

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

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. I think the right way to fix it would be to separately store the original mapping for filp->f_

Re: [PATCH] drm/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

On Wed, Jan 23, 2013 at 11:07 AM, Herton Ronaldo Krzesinski wrote: > On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote: >> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote: >> > Actually, the code path affected by your patch is not executed in UMS mode >&g

Re: [PATCH] drm/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

Actually, the code path affected by your patch is not executed in UMS mode at all. Notice that radeon_cs_parser_fini is only called from radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c). The equivalent of the fix you are trying to do is in a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e