> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of K. Y. Srinivasan
> Sent: Wednesday, December 16, 2015 8:27
> To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com;
On Tue, 15 Dec 2015 07:55:15 -0700
Mathieu Poirier wrote:
> I must admit you lost me here - what is this new version about? I
> suggest you used the [PATCH v#] convention along with a log of
> modifications from one version to another when sending new revisions.
> That way people know what to loo
From: Vitaly Kuznetsov
The return type of hvt_op_poll() is unsigned int and -EBADF is
inappropriate, poll functions return POLL* statuses.
Reported-by: Dexuan Cui
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_utils_transport.c |2 +-
1 files changed, 1
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/connection.c |4 ++--
drivers/hv/hv.c | 16
drivers/hv/hyperv_vmbus.h |4 +---
3 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 3dc5a9c..4a
For performance critical devices, we distribute the incoming
channel interrupt load across available CPUs in the guest.
Include Fibre channel devices in the set of devices for which
we would distribute the interrupt load.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c |3 +++
Currently all channels of a Fibre channel device are being bound to CPU 0.
Correct this by including Fibre Channel devices in the list of
performance critical devices. Also included is a patch to correct the
returned error code for util drivers as well as cleanup of the
vmbus signaling function.
K
> On 15 Dec 2015, at 18:48, Greg KH wrote:
>
>> On Tue, Dec 15, 2015 at 04:50:45PM +, Okash Khawaja wrote:
>> This patch fixes address space warnings from sparse. Function
>> lprocfs_write_helper() accepts user space buffer but was being
>> passed kernel space buffer by these functions:
>>
On Tue, Dec 15, 2015 at 07:48:22PM +, Simmons, James A. wrote:
> >On Tue, Dec 15, 2015 at 06:14:19PM +, Simmons, James A. wrote:
> >>
> >> >> struct libcfs_ioctl_hdr {
> >> >> __u32 ioc_len;
> >> >> @@ -87,6 +88,13 @@ do { \
> >> >>
>On Tue, Dec 15, 2015 at 06:14:19PM +, Simmons, James A. wrote:
>>
>> >> struct libcfs_ioctl_hdr {
>> >> __u32 ioc_len;
>> >> @@ -87,6 +88,13 @@ do { \
>> >> data.ioc_hdr.ioc_len = sizeof(data);\
>> >> } while (0)
>> >>
On Tue, 2015-12-15 at 20:48 +0300, Dan Carpenter wrote:
> On Tue, Dec 15, 2015 at 07:02:31AM -0800, Joe Perches wrote:
> > This is the original code:
> >
> > result = foo();
> > if (result)
> > goto label;
> >
> > result = bar();
> > if (result)
> > goto la
On Tue, 2015-12-15 at 19:02 +0100, SF Markus Elfring wrote:
> > This is the original code:
> Really …?
> > result = baz();
> > if (result)
> > goto label;
> >
> > label:
> > go on...
>
> I do not see such a source code structure
> at the six places I propose to clean-up.
>
On Tue, Dec 15, 2015 at 11:00 AM, Gustavo Padovan wrote:
> 2015-12-15 Daniel Vetter :
>
>> On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokhov wrote:
>> > Userspace can close the sync device while there are still active fence
>> > points, in which case kernel produces the following warning:
On Tue, 2015-12-15 at 19:26 +0100, SF Markus Elfring wrote:
> > rc = mdc_queue_wait(req);
> > goto out;
> > out:
> > ptlrpc_req_finished(req);
> > return rc;
> > }
> > -
> >
> > I think if the last goto out; is to be removed,
> > then it should be replaced by a
2015-12-15 Daniel Vetter :
> On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokhov wrote:
> > Userspace can close the sync device while there are still active fence
> > points, in which case kernel produces the following warning:
> >
> > [ 43.853176] [ cut here ]
> >
> I think there should _not_ be a hardened rule.
I guess that it can become hard to achieve consensus on a precise rule.
> Style is just a guide.
Generally nice …
> Do what you think appropriate.
I'm sorry for my evolving understanding. - But I imagine that your feedback
can cause further
On Tue, 2015-12-15 at 19:49 +0100, SF Markus Elfring wrote:
> > I think there should _not_ be a hardened rule.
> I guess that it can become hard to achieve consensus on a precise rule.
Consensus isn't unanimity.
> I imagine that your feedback
> can cause further software development troubles if t
On Tue, Dec 15, 2015 at 06:14:19PM +, Simmons, James A. wrote:
>
> >> struct libcfs_ioctl_hdr {
> >>__u32 ioc_len;
> >> @@ -87,6 +88,13 @@ do {\
> >>data.ioc_hdr.ioc_len = sizeof(data);\
> >> } while (0)
> >>
> >
>> struct libcfs_ioctl_hdr {
>> __u32 ioc_len;
>> @@ -87,6 +88,13 @@ do { \
>> data.ioc_hdr.ioc_len = sizeof(data);\
>> } while (0)
>>
>> +#define LIBCFS_IOC_INIT_V2(data, hdr) \
>> +do {
On Tue, Dec 15, 2015 at 05:10:39PM +, Simmons, James A. wrote:
>I have been pondering if pushing bug fixes before style cleanups
> is the right thing to do.
Generally push the least controversial patches first so that if you
have to redo one patch, then the rest are already applied and don't n
On Tue, Dec 15, 2015 at 07:02:31AM -0800, Joe Perches wrote:
> This is the original code:
>
> result = foo();
> if (result)
> goto label;
>
> result = bar();
> if (result)
> goto label;
>
> result = baz();
> if (result)
>
On Tue, Dec 15, 2015 at 04:50:45PM +, Okash Khawaja wrote:
> This patch fixes address space warnings from sparse. Function
> lprocfs_write_helper() accepts user space buffer but was being
> passed kernel space buffer by these functions:
>
> contention_seconds_store()
> lockless_truncate_store
On Tue, Dec 15, 2015 at 10:21:38AM -0800, Kamal Mostafa wrote:
> >From f424410bf4a6a0dd6ff88bec808798016f4161a0 Mon Sep 17 00:00:00 2001
> From: Kamal Mostafa
> Date: Wed, 11 Nov 2015 19:16:59 +
> Subject: tools/hv: Use include/uapi with __EXPORTED_HEADERS__
Why is all of this mess here?
Ple
>On Tue, Dec 15, 2015 at 06:14:19PM +, Simmons, James A. wrote:
>>
>> >> struct libcfs_ioctl_hdr {
>> >> __u32 ioc_len;
>> >> @@ -87,6 +88,13 @@ do { \
>> >> data.ioc_hdr.ioc_len = sizeof(data);\
>> >> } while (0)
>> >>
> rc = mdc_queue_wait(req);
> goto out;
> out:
> ptlrpc_req_finished(req);
> return rc;
> }
> -
>
> I think if the last goto out; is to be removed,
> then it should be replaced by a blank line.
>
> It separates the last operation block from the return.
On Tue, Dec 15, 2015 at 06:14:19PM +, Simmons, James A. wrote:
>
> >> struct libcfs_ioctl_hdr {
> >>__u32 ioc_len;
> >> @@ -87,6 +88,13 @@ do {\
> >>data.ioc_hdr.ioc_len = sizeof(data);\
> >> } while (0)
> >>
> >
>From f424410bf4a6a0dd6ff88bec808798016f4161a0 Mon Sep 17 00:00:00 2001
From: Kamal Mostafa
Date: Wed, 11 Nov 2015 19:16:59 +
Subject: tools/hv: Use include/uapi with __EXPORTED_HEADERS__
Use the local uapi headers to keep in sync with "recently" added #define's
(e.g. VSS_OP_REGISTER1).
Fixe
On Mon, 2015-12-14 at 19:11 -0800, Greg KH wrote:
> On Mon, Dec 14, 2015 at 04:01:53PM -0800, K. Y. Srinivasan wrote:
> > From: Kamal Mostafa
> >
> > Use the local uapi headers to keep in sync with "recently" added #define's
> > (e.g. VSS_OP_REGISTER1).
> >
> > Fixes: 3eb2094c59e89db2bedd401e23c
This patch fixes address space warnings from sparse. Function
lprocfs_write_helper() accepts user space buffer but was being
passed kernel space buffer by these functions:
contention_seconds_store()
lockless_truncate_store()
Since these functions are used to implement show and store functions of
>> diff --git a/drivers/staging/lustre/lnet/selftest/conctl.c
>> b/drivers/staging/lustre/lnet/selftest/conctl.c
>> index 556c837..2ca7d0e 100644
>> --- a/drivers/staging/lustre/lnet/selftest/conctl.c
>> +++ b/drivers/staging/lustre/lnet/selftest/conctl.c
>> @@ -679,45 +679,46 @@ static int
>> ls
> This is the original code:
Really …?
> result = baz();
> if (result)
> goto label;
>
> label:
> go on...
I do not see such a source code structure
at the six places I propose to clean-up.
> I don't find the test->goto label; label: use offensive,
> but if he doe
On Tue, Dec 15, 2015 at 1:26 AM, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokhov wrote:
>> Userspace can close the sync device while there are still active fence
>> points, in which case kernel produces the following warning:
>>
>> [ 43.853176] [ cut
The return type of hvt_op_poll() is unsigned int and -EBADF is
inappropriate, poll functions return POLL* statuses.
Reported-by: Dexuan Cui
Signed-off-by: Vitaly Kuznetsov
---
- This is a follow-up to the previously sent 'Drivers: hv: utils: introduce
HVUTIL_TRANSPORT_DESTROY mode' patch which
> -Original Message-
> From: ja...@microsoft.com [mailto:ja...@microsoft.com]
> Sent: Wednesday, December 9, 2015 2:55 PM
> To: gre...@linuxfoundation.org; KY Srinivasan ; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; vkuzn...@redhat.
On Tue, Dec 15, 2015 at 5:30 AM, Gustavo Padovan wrote:
> 2015-12-14 Dmitry Torokhov :
>
>> Userspace can close the sync device while there are still active fence
>> points, in which case kernel produces the following warning:
>>
>> [ 43.853176] [ cut here ]
>> [ 43.857
>Actually we're going to have to redo so much code that it's not worth it
>for me to review the rest of these patches.
Sorry I didn't get back to you sooner but I was on vacation. Thanks for
reviewing this work. Especially since this is the first major bug fixing merge
for the lustre client wh
On Tue, Dec 15, 2015 at 2:01 AM, Maarten Lankhorst
wrote:
> Op 15-12-15 om 02:29 schreef Dmitry Torokhov:
>> Userspace can close the sync device while there are still active fence
>> points, in which case kernel produces the following warning:
>>
>> [ 43.853176] [ cut here ]-
On Tue, Dec 15, 2015 at 5:50 AM, Frank Binns wrote:
> Is this not the issue fixed by 8e43c9c75?
No because if we start teardown without waiting for the fence to be
signaled it will still be on the active_list.
Thanks.
--
Dmitry
___
devel mailing list
Dexuan Cui writes:
>> -Original Message-
>> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
>> Of K. Y. Srinivasan
>> Sent: Tuesday, December 15, 2015 11:02
>> To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
>> de...@linuxdriverproject.org; o...
On Tue, 2015-12-15 at 17:41 +0300, Dan Carpenter wrote:
> On Tue, Dec 15, 2015 at 06:27:56AM -0800, Joe Perches wrote:
> > On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote:
> > > From: Markus Elfring
> > > Date: Sun, 13 Dec 2015 09:30:47 +0100
> > >
> > > Six goto statements referred to
Use list_for_each_entry*() instead of list_for_each*() to simplify
the code.
Signed-off-by: Geliang Tang
---
drivers/staging/wlan-ng/hfa384x_usb.c | 17 -
drivers/staging/wlan-ng/prism2usb.c | 15 +++
2 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/d
On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 13 Dec 2015 09:30:47 +0100
>
> Six goto statements referred to a source code position directly behind them.
> Thus omit such unnecessary jumps.
I suggest you leave a blank line instead
of deleting the
> If you were a lustre dev then I would accept these renames definitely.
I find this information interesting.
Would any more contributors like to share their opinion?
> I do not think I have been unfair to you.
This view is correct in principle.
> There was no element of surprise.
I am tryin
On 14 December 2015 at 17:08, Sanidhya Solanki wrote:
> The original code defined macros in the source code, making it
> harder to read. Moved them to the header file, as per the TODO file.
>
> Updated the TODO file.
>
> Signed-off-by: Sanidhya Solanki
> ---
> drivers/staging/skein/TODO
On Tue, Dec 15, 2015 at 06:27:56AM -0800, Joe Perches wrote:
> On Sun, 2015-12-13 at 14:52 +0100, SF Markus Elfring wrote:
> > From: Markus Elfring
> > Date: Sun, 13 Dec 2015 09:30:47 +0100
> >
> > Six goto statements referred to a source code position directly behind them.
> > Thus omit such unn
Is this not the issue fixed by 8e43c9c75?
Thanks
Frank
On 15/12/15 13:30, Gustavo Padovan wrote:
> 2015-12-14 Dmitry Torokhov :
>
>> Userspace can close the sync device while there are still active fence
>> points, in which case kernel produces the following warning:
>>
>> [ 43.853176]
2015-12-14 Dmitry Torokhov :
> Userspace can close the sync device while there are still active fence
> points, in which case kernel produces the following warning:
>
> [ 43.853176] [ cut here ]
> [ 43.857834] WARNING: CPU: 0 PID: 892 at
> /mnt/host/source/src/third_p
> -Original Message-
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of K. Y. Srinivasan
> Sent: Tuesday, December 15, 2015 11:02
> To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.
On Mon, Dec 14, 2015 at 06:43:15PM +0100, SF Markus Elfring wrote:
> Our software development dialogue seems to trigger special
> challenges between us so far.
I try very hard to review patches mechanically and not be biased so that
after a while people know if their patches will be merged or not
Op 15-12-15 om 02:29 schreef Dmitry Torokhov:
> Userspace can close the sync device while there are still active fence
> points, in which case kernel produces the following warning:
>
> [ 43.853176] [ cut here ]
> [ 43.857834] WARNING: CPU: 0 PID: 892 at
> /mnt/host/sou
On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokhov wrote:
> Userspace can close the sync device while there are still active fence
> points, in which case kernel produces the following warning:
>
> [ 43.853176] [ cut here ]
> [ 43.857834] WARNING: CPU: 0 PID: 892
50 matches
Mail list logo
