On Sat, Jan 17, 2015 at 03:29:01PM -0800, Greg KH wrote:
> On Sat, Dec 13, 2014 at 03:58:46PM +0100, Loïc Pefferkorn wrote:
> > > >>> Don't hide "implementation of locks" in functions like this, it only
> > > >>> causes problems. This code has layers of layers of layers of
> > > >>> abstractions d
On Sat, Dec 13, 2014 at 03:58:46PM +0100, Loïc Pefferkorn wrote:
> > >>> Don't hide "implementation of locks" in functions like this, it only
> > >>> causes problems. This code has layers of layers of layers of
> > >>> abstractions due to it wanting to be originally ported to other
> > >>> operati
> >>> Don't hide "implementation of locks" in functions like this, it only
> >>> causes problems. This code has layers of layers of layers of
> >>> abstractions due to it wanting to be originally ported to other
> >>> operating systems and lots of different kernel versions of Linux itself.
> >>> U
On Dec 7, 2014, at 4:57 AM, Loïc Pefferkorn wrote:
>
> On Tue, Dec 02, 2014 at 02:11:33PM -0700, Andreas Dilger wrote:
>> On Nov 28, 2014, at 11:50 AM, Greg KH wrote:
>>> On Thu, Nov 27, 2014 at 07:34:10PM +0100, Loïc Pefferkorn wrote:
Hello Greg,
After some investigation, I thin
On Tue, Dec 02, 2014 at 02:11:33PM -0700, Andreas Dilger wrote:
> On Nov 28, 2014, at 11:50 AM, Greg KH wrote:
> > On Thu, Nov 27, 2014 at 07:34:10PM +0100, Loïc Pefferkorn wrote:
> >> Hello Greg,
> >>
> >> After some investigation, I think that removing these wrappers is not
> >> going to impro
On Nov 28, 2014, at 11:50 AM, Greg KH wrote:
> On Thu, Nov 27, 2014 at 07:34:10PM +0100, Loïc Pefferkorn wrote:
>> Hello Greg,
>>
>> After some investigation, I think that removing these wrappers is not going
>> to improve the code readability:
>>
>> On Wed, Nov 26, 2014 at 12:54:43PM -0800, Gr
On Fri, Nov 28, 2014 at 02:22:07PM -0800, Greg KH wrote:
>
> That's even worse than I imagined. Putting sparse markings on these
> function calls is just papering over nonsense. Please work on unwinding
> the mess so that you don't need callbacks for locks, that is an
> abstraction that isn't ne
On Thu, Nov 27, 2014 at 07:34:10PM +0100, Loïc Pefferkorn wrote:
> Hello Greg,
>
> After some investigation, I think that removing these wrappers is not going
> to improve the code readability:
>
> On Wed, Nov 26, 2014 at 12:54:43PM -0800, Greg KH wrote:
> > On Wed, Nov 26, 2014 at 05:15:48PM +0
On Thu, Nov 27, 2014 at 07:34:10PM +0100, Loïc Pefferkorn wrote:
> 1827 if (valid != 0) {
> 1828 cl_object_attr_lock(obj);
> 1829 cl_object_attr_set(env, obj, attr, valid);
> 1830 cl_object_attr_unlock(obj);
>
> after:
>
> 1827 if (valid != 0) {
Hello Greg,
After some investigation, I think that removing these wrappers is not going to
improve the code readability:
On Wed, Nov 26, 2014 at 12:54:43PM -0800, Greg KH wrote:
> On Wed, Nov 26, 2014 at 05:15:48PM +0100, Loic Pefferkorn wrote:
> > Add __acquires() and __releases() function anno
On Wed, Nov 26, 2014 at 12:54:43PM -0800, Greg KH wrote:
>
> Ugh, how horrid, please just delete these functions and push down the
> spin_lock/unlock calls down into the places these are called.
>
> Same for these.
>
> Same thing here.
Hello Greg,
Thanks for your comments, I will write a v2.
-
On Wed, Nov 26, 2014 at 05:15:48PM +0100, Loic Pefferkorn wrote:
> Add __acquires() and __releases() function annotations, to fix sparse
> warnings related to lock context imbalance.
>
> This fixes the following warnings:
>
> drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c:153:5: wa
12 matches
Mail list logo
