On Wed, Mar 23, 2016 at 3:14 PM, Miklos Szeredi wrote:
> Use "--contains", otherwise "git describe" will just say which kernel
> the patch has been committed to, not which release it appears in.
>
> git describe --contains 4bacc9c9234c
> v4.2-rc1~2^2~27
Indeed; I saw the patch in v4.1.x stable
ht
Hello Miklos,
On Wed, Mar 23, 2016 at 2:36 PM, Miklos Szeredi wrote:
> This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs:
> Make f_path always point to the overlay and f_inode to the underlay").
>
> Regular files opened on overlayfs will result in the file being opened on
> t
Hi Maarten,
Thank you for your quick reply.
On Thu, Mar 17, 2016 at 12:27 PM, Maarten Lankhorst
wrote:
> Does it happen with latest -nightly?
The issue is indeed fixed in last linux.git, so there must be a fix
which is not yet backported in -stable. Could you point it to me? I
may ask for -stab
On Mon, Jan 11, 2016 at 2:35 AM, kernel test robot
wrote:
> FYI, we noticed the below changes on
>
> git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
> commit 396e33ae204f52abebec9e578f44c749305500f4 ("drm/i915: Add two-stage
> ILK-style watermark programming (v10)")
>
>
> +-
On Wed, Feb 3, 2016 at 7:26 PM, Jeff Layton wrote:
> Yes...this commit in mainline fixes it:
Thanks Jeff, I missed it.
--
William
Hello Jeff,
On Wed, Dec 23, 2015 at 2:54 PM, Jeff Layton wrote:
> Ooh, nice catch...and just in time for Christmas.
>
> filp_close does this after the fd has been detached from the file table
> in __close_fd:
>
> if (likely(!(filp->f_mode & FMODE_PATH))) {
> dnotify_flush(
On Wed, Nov 25, 2015 at 5:45 PM, Jens Axboe wrote:
> I'd say it's borderline. It's fixing a tracking bug. Unless others feel
> strongly otherwise, I don't think it's stable material.
ok thanks for your feedback.
--
William
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
Hi Jens,
On Mon, Sep 14, 2015 at 7:21 PM, Jens Axboe wrote:
> On 09/14/2015 11:16 AM, Catalin Marinas wrote:
>>
>> The pages allocated for struct request contain pointers to other slab
>> allocations (via ops->init_request). Since kmemleak does not track/scan
>> page allocations, the slab objects
Hi Sasha,
I think there might be a problem with the changelog on kernel.org
https://kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.18.24
it shows the entry of tty only.
Best regards,
--
William
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
On Mon, Oct 19, 2015 at 6:53 PM, William Dauchy wrote:
> On Mon, Oct 19, 2015 at 6:44 PM, Jeff Layton wrote:
>> This should be fixed by this series of four commits that are already in
>> mainline:
>> bcd7f78d078ff6197715c1ed070c92aca57ec12c..ee296d7c5709440f8abd36b5b65c6
&g
Hi Jeff,
Thank you for you reply.
On Mon, Oct 19, 2015 at 6:44 PM, Jeff Layton wrote:
> This should be fixed by this series of four commits that are already in
> mainline:
> bcd7f78d078ff6197715c1ed070c92aca57ec12c..ee296d7c5709440f8abd36b5b65c6
> b3e388538d9
Am I missing something, I see three
Hello Dmitry,
On Mon, Oct 19, 2015 at 5:27 PM, Dmitry Vyukov wrote:
> I would expect that you see something else.
> The issue that I fixed would fire very infrequently and unreproducibly.
Thanks for the quick reply. I will open another thread for this issue.
--
William
--
To unsubscribe from th
Hello Dmitry,
On Mon, Sep 21, 2015 at 1:44 PM, Jeff Layton wrote:
> Ok, thanks for the explanation. Patch looks fine to me. I'll go ahead
> and merge it for v4.4. Let me know though if you think this needs to go
> in sooner.
I am getting a null deref on a v4.1.x
Do you think your patch could fix
On Oct10 04:40, Greg Kroah-Hartman wrote:
> The last 3.14.x release had a bunch of these patches already in them,
> with more to come in future releases, so yes, 3.14.x is going to benefit
> from it, and you didn't even notice :)
oh true; did not catch the last one.
> But 3.10 will probably not,
Hi stable release team,
On Wed, Oct 1, 2014 at 10:57 AM, Jiri Slaby wrote:
> This one is special. First, it is rounded (30). Second, most of the
> patches are performance improvements. They are coming from SUSE
> Enterprise Linux and all are backed by proper testing and performance
> measurements
Hi Rafael,
On Wed, Jul 30, 2014 at 12:39 AM, Rafael J. Wysocki wrote:
> William, it would be good if you could test it too as I'd like to
> push it for 3.16.
It also fixes the issue in 3.14.x
Tested-by: William Dauchy
Thanks,
--
William
--
To unsubscribe from this list: se
Hi Vinson,
On Mon, Jul 28, 2014 at 9:11 PM, Vinson Lee wrote:
> The warning first happens with 3.14-rc1. The warning does not occur with
> 3.13.0.
Hitting the same issue here with a similar trace on 3.14.x. Did you
start bisecting?
Regards,
--
William
--
To unsubscribe from this list: send th
On Apr02 11:01, Borislav Petkov wrote:
> It is too late for that now as the patch is in -tip already... Unless
> Ingo can still amend it, that is.
>
> But, we're working on a real solution for the storm issue and there
> we'll be asking you to test stuff anyway so we'll make sure to use this
> mai
uot; so we will skip the bank when polling
> (so we fail to see that the storm continues because we stop looking).
> New cmci_storm_disable_banks() just disables the interrupt while
> allowing polling to continue.
>
> Reported-by: William Dauchy
Could you use the following address inste
On Tue, Dec 3, 2013 at 9:22 PM, Oleg Nesterov wrote:
>> Before this patch, I was testing this one
>> https://lkml.org/lkml/2013/11/13/336
>
> perhaps this patch makes more sense for stable.
I guess we should consider it.
> But, to clarify just in case, it is not needed after this series.
>
>> wh
Hello Oleg,
On Mon, Dec 2, 2013 at 4:24 PM, Oleg Nesterov wrote:
> This was reported several times, I believe the first report is
> http://marc.info/?l=linux-kernel&m=127688978121665. Hmm, 3 years
> ago. The lockless while_each_thread() is racy and broken, almost
> every user can loop forever.
>
Hi Li,
On Mon, Nov 25, 2013 at 2:20 AM, Li Zefan wrote:
> I'll do this after the patch hits mainline, if Tejun doesn't plan to.
Do you have some news about it?
--
William
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
Hi Johannes,
On Thu, Nov 28, 2013 at 7:35 AM, Johannes Weiner wrote:
> Cc William and azur who might have encountered this problem.
Thank you for letting me know.
Note that before this patch I saw the one from Sameer Nanda
mm, oom: Fix race when selecting process to kill
https://lkml.org/lkml/20
Hi Cyrill,
On Wed, Nov 27, 2013 at 12:50 PM, Cyrill Gorcunov wrote:
> "Soft dirty bit" feature introduced in 3.11 kernel and as far as I know
> we've no plans to backport it on 3.10 series.
ok thanks for the information and the quick reply.
--
William
--
To unsubscribe from this list: send the
Hi Greg,
I was wondering if v3.10.x stable branch was also concerned by this
patch since I did not found it in this later branch.
Maybe too hard to backport? (I saw that it requires new functions like
pte_swp_soft_dirty which is not present in v3.10.x)
Maybe it was planned in the future?
Thanks,
Hi Tejun,
On Fri, Nov 22, 2013 at 11:18 PM, Tejun Heo wrote:
> Just applied to cgroup/for-3.13-fixes w/ stable cc'd. Will push to
> Linus next week.
Thank your for your quick reply. Do you also have a backport for
v3.10.x already available?
Best regards,
--
William
--
To unsubscribe from this
On Mon, Nov 18, 2013 at 3:17 AM, Hugh Dickins wrote:
> Sorry for the delay: I was on the point of reporting success last
> night, when I tried a debug kernel: and that didn't work so well
> (got spinlock bad magic report in pwd_adjust_max_active(), and
> tests wouldn't run at all).
>
> Even the no
On Wed, Jun 26, 2013 at 8:15 AM, Stanislav Kinsbursky
wrote:
> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> index b827a4b..41f180c 100644
> --- a/net/sunrpc/clnt.c
> +++ b/net/sunrpc/clnt.c
> @@ -236,8 +236,6 @@ static struct rpc_clnt *rpc_get_client_for_event(struct
> net *net, int event
On Tue, Mar 12, 2013 at 11:10 PM, Greg Kroah-Hartman
wrote:
>> > >> IOW I don't see why this got proposed for stable at all.
>> > >
>> > > So, you suggest to just drop this patch for v3.8.3, don't you?
>> >
>> > I do, yes. But I'd suggest to get Konrad to agree.
>>
>> Yes. Lets drop it.
>
> Now re
On Wed, Apr 3, 2013 at 3:42 PM, Jan Beulich wrote:
> ChangeLog-3.8.3 for example has
oh sorry, you are right. I wasn't looking is the 3.8.x branch.
The thing is, the revert seems present only in 3.8.x branch. For
example in 3.4.x the last patch is still 01c681d
Should we consider this normal or i
Hello Jan,
On Wed, Apr 3, 2013 at 3:01 PM, Jan Beulich wrote:
> Iirc we requested the earlier commit to be removed from stable
> trees, and I think Greg also did so.
I'm sorry but I'm unable to find a revert of 01c681d in stable tree.
Regards,
--
William
--
To unsubscribe from this list: send t
Hello,
On Thu, Feb 28, 2013 at 3:34 AM, Chen Gang wrote:
> additional information:
> before commit 01c681d4c70d64cb72142a2823f27c4146a02e63, the value printed
> here was bogus, as it was the guest provided value from req->u.rw.handle
> rather than the actual device.
>
> Signed-off-by: Chen
On Feb22 17:44, Ian Campbell wrote:
> He likes to soak thing in mainline for a bit before forwarding to stable
> which is likely why they aren't there yet
> http://marc.info/?l=xen-devel&m=136029801624783&w=2
ack, didn't know that.
--
William
signature.asc
Description: Digital signature
On Feb22 09:28, Greg Kroah-Hartman wrote:
> What does that mean? Should they be applied for those kernels or not?
Yes indeed.
Sorry for my confused answer.
Thanks,
--
William
signature.asc
Description: Digital signature
On Feb22 09:08, Greg Kroah-Hartman wrote:
> You mean 3.4 and newer, right?
> Are you sure that 3.2 and 3.0 aren't also relevant here?
They are, but didn't test them directly.
I just applied them without trouble.
Thanks,
--
William
signature.asc
Description: Digital signature
these patches in stable tree at least for v3.4?
Tested-by: William Dauchy
Cc: sta...@vger.kernel.org
commit 35876b5ffc154c357476b2c3bdab10feaf4bd8f0
Author: David Vrabel
Date: Thu Feb 14 03:18:57 2013 +
xen-netback: correctly return errors from netbk_count_requests
;t found the time to fix it.
Applying the patch fixes the problem.
Tested-by: William Dauchy
Thanks,
--
William
signature.asc
Description: Digital signature
Hello Dave,
Thanks for your reply.
On Tue, Oct 16, 2012 at 1:21 AM, Dave Chinner wrote:
> You're running a CONFIG_XFS_DEBUG kernel. If you can reproduce the
> problem with CONFIG_XFS_DEBUG, then it probably should be
> backported.
Yes indeed.
Tested-by: William Dauchy
Cc: sta
Hello Konrad,
On Thu, Aug 16, 2012 at 6:03 PM, Konrad Rzeszutek Wilk
wrote:
> (XEN) mm.c:908:d0 Error getting mfn 116a83 (pfn 14e2a) from L1 entry
> 800116a83067 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn 4040 (pfn ) from L1 entry
> 04040601 fo
39 matches
Mail list logo
