On Mon, Aug 6, 2018 at 3:30 PM Peter Zijlstra wrote:
>
> On Mon, Aug 06, 2018 at 02:28:18PM -0700, Fubo Chen wrote:
> > Do you think the patch below is sufficient to suppress the sparse warning?
>
> Why would I want to make the code ugly to supress it?
There are many kernel
On Mon, Aug 6, 2018 at 11:04 AM Peter Zijlstra wrote:
> On Mon, Aug 06, 2018 at 09:54:23AM -0700, Fubo Chen wrote:
> > On Mon, Aug 6, 2018 at 8:42 AM Peter Zijlstra wrote:
> > > On Mon, Aug 06, 2018 at 08:35:07AM -0700, Fubo Chen wrote:
> > > > On Thu, Jul 19,
On Mon, Aug 6, 2018 at 8:42 AM Peter Zijlstra wrote:
>
> On Mon, Aug 06, 2018 at 08:35:07AM -0700, Fubo Chen wrote:
> > On Thu, Jul 19, 2018 at 2:21 PM Peter Zijlstra wrote:
> > > --- a/include/uapi/linux/perf_event.h
> > > +++ b/include/uapi/linux/perf_event.h
On Thu, Jul 19, 2018 at 2:21 PM Peter Zijlstra wrote:
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -143,6 +143,8 @@ enum perf_event_sample_format {
> PERF_SAMPLE_PHYS_ADDR = 1U << 19,
>
> PERF_SAMPLE_MAX = 1U << 20,
spin_unlock_irqrestore(&wq_head->lock, flags);
> }
> EXPORT_SYMBOL(add_wait_queue);
Reviewed-by: Fubo Chen
On Fri, Dec 16, 2016 at 10:39 AM, Johannes Berg
wrote:
>
>> > I can't see the using kmemleak_not_leak is possibly good form. I
>> > would much rather have suggestions about constructs that won't
>> > confuse kmemleak and won't need ugly annotations that serve no
>> > purpose but to appease a tool
On Thu, Nov 3, 2016 at 3:54 PM, Eric W. Biederman wrote:
> Dmitry Torokhov writes:
>
>> We do not ever intend to unregister "user" sysctl table, unfortunately
>> it leads kmemleak to believe that we are leaking memory:
>
> Sounds like an issue with kmemleak because we do retain references.
>
> So
On Wed, May 25, 2016 at 9:08 AM, Linus Torvalds
wrote:
> Ok, thanks. For some odd reason all your emails in this series got
> marked as spam. Every single one, including the cover letter (but not
> your replies to the replies to this).
I have added the following filter to my gmail account: "never
(adding Takashi Iwai)
On Thu, May 8, 2014 at 4:06 PM, Niccolò Belli wrote:
> Hi,
> Sorry for posting on linux-kernel but from my experience nobody ever looks
> at the kernel bug tracker and I would like to get it fixed before 3.15 gets
> released.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=7
On Sun, Jan 26, 2014 at 11:54 AM, Jose Alonso wrote:
> I observed that there are for_each macros that do an extra memory access
> beyond the defined area.
> Normally this does not cause problems.
> But, this can cause exceptions. For example: if the area is allocated at
> the end of a page and the
On Fri, Jan 18, 2013 at 9:21 PM, wrote:
> Please don't start another "SCST Vs. LIO" holy war here. We all know why LIO
> belongs to Linux kernel and SCST does not.
SCST is not familiar to me. Does this mean that SCST is competition
for the StarWind products but LIO not ?
Fubo.
--
To unsubscrib
On Mon, Dec 3, 2012 at 9:58 PM, Kent Overstreet wrote:
> +#define pr_fmt(fmt) "%s: " fmt "\n", __func__
Dynamic debug already allows to insert the function name. Please
consider leaving this line out entirely and move the "\n" to the end
of individual printed lines.
> +#define PCPU_REF_PTR
On Mon, Dec 3, 2012 at 9:58 PM, Kent Overstreet wrote:
> We want to remove retry-based AIO because it is fundemantally unsafe.
Instead of "fundemantally" that should have been "fundamentally" I guess ?
Thanks,
Fubo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Wed, Dec 12, 2012 at 5:12 PM, Leon Romanovsky wrote:
> On Wed, Dec 12, 2012 at 7:05 AM, Fubo Chen wrote:
>>
>> On Wed, Dec 12, 2012 at 3:37 PM, Namjae Jeon wrote:
>> > + /* dot and dotdot dentries should have zero-value hash code */
>> > + if
On Wed, Dec 12, 2012 at 3:37 PM, Namjae Jeon wrote:
> + /* dot and dotdot dentries should have zero-value hash code */
> + if (!memcmp(name, ".", 1) || !memcmp(name, "..", 2))
> + return 0;
That looks suspicious. If memcmp(name, "..", 2) == 0 then always
memcmp(name, "."
15 matches
Mail list logo
