- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "nfsd: Make init_open_stateid() a bit more whole" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: Make init_open_stateid() a bit more whole to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-make-init_open_stateid-a-bit-more-whole.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8c7245abda877d4689b3371db8ae2a4400d7d9ce Mon Sep 17 00:00:00 2001 From: Oleg Drokin <green(a)linuxhacker.ru> Date: Tue, 14 Jun 2016 23:28:06 -0400 Subject: nfsd: Make init_open_stateid() a bit more whole From: Oleg Drokin <green(a)linuxhacker.ru> commit 8c7245abda877d4689b3371db8ae2a4400d7d9ce upstream. Move the state selection logic inside from the caller, always making it return correct stp to use. Signed-off-by: J . Bruce Fields <bfields(a)fieldses.org> Signed-off-by: Oleg Drokin <green(a)linuxhacker.ru> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -3420,13 +3420,14 @@ alloc_init_open_stateowner(unsigned int } static struct nfs4_ol_stateid * -init_open_stateid(struct nfs4_ol_stateid *stp, struct nfs4_file *fp, - struct nfsd4_open *open) +init_open_stateid(struct nfs4_file *fp, struct nfsd4_open *open) { struct nfs4_openowner *oo = open->op_openowner; struct nfs4_ol_stateid *retstp = NULL; + struct nfs4_ol_stateid *stp; + stp = open->op_stp; /* We are moving these outside of the spinlocks to avoid the warnings */ mutex_init(&stp->st_mutex); mutex_lock(&stp->st_mutex); @@ -3437,6 +3438,8 @@ init_open_stateid(struct nfs4_ol_stateid retstp = nfsd4_find_existing_open(fp, open); if (retstp) goto out_unlock; + + open->op_stp = NULL; atomic_inc(&stp->st_stid.sc_count); stp->st_stid.sc_type = NFS4_OPEN_STID; INIT_LIST_HEAD(&stp->st_locks); @@ -3454,10 +3457,11 @@ out_unlock: spin_unlock(&oo->oo_owner.so_client->cl_lock); if (retstp) { mutex_lock(&retstp->st_mutex); - /* Not that we need to, just for neatness */ + /* To keep mutex tracking happy */ mutex_unlock(&stp->st_mutex); + stp = retstp; } - return retstp; + return stp; } /* @@ -4260,7 +4264,6 @@ nfsd4_process_open2(struct svc_rqst *rqs struct nfs4_client *cl = open->op_openowner->oo_owner.so_client; struct nfs4_file *fp = NULL; struct nfs4_ol_stateid *stp = NULL; - struct nfs4_ol_stateid *swapstp = NULL; struct nfs4_delegation *dp = NULL; __be32 status; @@ -4297,16 +4300,10 @@ nfsd4_process_open2(struct svc_rqst *rqs goto out; } } else { - stp = open->op_stp; - open->op_stp = NULL; - /* - * init_open_stateid() either returns a locked stateid - * it found, or initializes and locks the new one we passed in - */ - swapstp = init_open_stateid(stp, fp, open); - if (swapstp) { - nfs4_put_stid(&stp->st_stid); - stp = swapstp; + /* stp is returned locked. */ + stp = init_open_stateid(fp, open); + /* See if we lost the race to some other thread */ + if (stp->st_access_bmap != 0) { status = nfs4_upgrade_open(rqstp, fp, current_fh, stp, open); if (status) { Patches currently in stable-queue which might be from green(a)linuxhacker.ru are queue-4.4/nfsd-make-init_open_stateid-a-bit-more-whole.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: Fix another OPEN stateid race" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: Fix another OPEN stateid race to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-fix-another-open-stateid-race.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d8a1a000555ecd1b824ac1ed6df8fe364dfbbbb0 Mon Sep 17 00:00:00 2001 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 3 Nov 2017 08:00:11 -0400 Subject: nfsd: Fix another OPEN stateid race From: Trond Myklebust <trond.myklebust(a)primarydata.com> commit d8a1a000555ecd1b824ac1ed6df8fe364dfbbbb0 upstream. If nfsd4_process_open2() is initialising a new stateid, and yet the call to nfs4_get_vfs_file() fails for some reason, then we must declare the stateid closed, and unhash it before dropping the mutex. Right now, we unhash the stateid after dropping the mutex, and without changing the stateid type, meaning that another OPEN could theoretically look it up and attempt to use it. Reported-by: Andrew W Elble <aweits(a)rit.edu> Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -4319,6 +4319,7 @@ nfsd4_process_open2(struct svc_rqst *rqs struct nfs4_ol_stateid *stp = NULL; struct nfs4_delegation *dp = NULL; __be32 status; + bool new_stp = false; /* * Lookup file; if found, lookup stateid and check open request, @@ -4338,11 +4339,19 @@ nfsd4_process_open2(struct svc_rqst *rqs goto out; } + if (!stp) { + stp = init_open_stateid(fp, open); + if (!open->op_stp) + new_stp = true; + } + /* * OPEN the file, or upgrade an existing OPEN. * If truncate fails, the OPEN fails. + * + * stp is already locked. */ - if (stp) { + if (!new_stp) { /* Stateid was found, this is an OPEN upgrade */ status = nfs4_upgrade_open(rqstp, fp, current_fh, stp, open); if (status) { @@ -4350,22 +4359,11 @@ nfsd4_process_open2(struct svc_rqst *rqs goto out; } } else { - /* stp is returned locked. */ - stp = init_open_stateid(fp, open); - /* See if we lost the race to some other thread */ - if (stp->st_access_bmap != 0) { - status = nfs4_upgrade_open(rqstp, fp, current_fh, - stp, open); - if (status) { - mutex_unlock(&stp->st_mutex); - goto out; - } - goto upgrade_out; - } status = nfs4_get_vfs_file(rqstp, fp, current_fh, stp, open); if (status) { - mutex_unlock(&stp->st_mutex); + stp->st_stid.sc_type = NFS4_CLOSED_STID; release_open_stateid(stp); + mutex_unlock(&stp->st_mutex); goto out; } @@ -4374,7 +4372,7 @@ nfsd4_process_open2(struct svc_rqst *rqs if (stp->st_clnt_odstate == open->op_odstate) open->op_odstate = NULL; } -upgrade_out: + nfs4_inc_and_copy_stateid(&open->op_stateid, &stp->st_stid); mutex_unlock(&stp->st_mutex); Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.4/nfsd-fix-stateid-races-between-open-and-close.patch queue-4.4/nfsd-fix-another-open-stateid-race.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "nfsd: Fix stateid races between OPEN and CLOSE" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfsd: Fix stateid races between OPEN and CLOSE to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsd-fix-stateid-races-between-open-and-close.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 15ca08d3299682dc49bad73251677b2c5017ef08 Mon Sep 17 00:00:00 2001 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 3 Nov 2017 08:00:10 -0400 Subject: nfsd: Fix stateid races between OPEN and CLOSE From: Trond Myklebust <trond.myklebust(a)primarydata.com> commit 15ca08d3299682dc49bad73251677b2c5017ef08 upstream. Open file stateids can linger on the nfs4_file list of stateids even after they have been closed. In order to avoid reusing such a stateid, and confusing the client, we need to recheck the nfs4_stid's type after taking the mutex. Otherwise, we risk reusing an old stateid that was already closed, which will confuse clients that expect new stateids to conform to RFC7530 Sections 9.1.4.2 and 16.2.5 or RFC5661 Sections 8.2.2 and 18.2.4. Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: J. Bruce Fields <bfields(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfsd/nfs4state.c | 67 +++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 59 insertions(+), 8 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -3379,7 +3379,9 @@ nfsd4_find_existing_open(struct nfs4_fil /* ignore lock owners */ if (local->st_stateowner->so_is_open_owner == 0) continue; - if (local->st_stateowner == &oo->oo_owner) { + if (local->st_stateowner != &oo->oo_owner) + continue; + if (local->st_stid.sc_type == NFS4_OPEN_STID) { ret = local; atomic_inc(&ret->st_stid.sc_count); break; @@ -3388,6 +3390,52 @@ nfsd4_find_existing_open(struct nfs4_fil return ret; } +static __be32 +nfsd4_verify_open_stid(struct nfs4_stid *s) +{ + __be32 ret = nfs_ok; + + switch (s->sc_type) { + default: + break; + case NFS4_CLOSED_STID: + case NFS4_CLOSED_DELEG_STID: + ret = nfserr_bad_stateid; + break; + case NFS4_REVOKED_DELEG_STID: + ret = nfserr_deleg_revoked; + } + return ret; +} + +/* Lock the stateid st_mutex, and deal with races with CLOSE */ +static __be32 +nfsd4_lock_ol_stateid(struct nfs4_ol_stateid *stp) +{ + __be32 ret; + + mutex_lock(&stp->st_mutex); + ret = nfsd4_verify_open_stid(&stp->st_stid); + if (ret != nfs_ok) + mutex_unlock(&stp->st_mutex); + return ret; +} + +static struct nfs4_ol_stateid * +nfsd4_find_and_lock_existing_open(struct nfs4_file *fp, struct nfsd4_open *open) +{ + struct nfs4_ol_stateid *stp; + for (;;) { + spin_lock(&fp->fi_lock); + stp = nfsd4_find_existing_open(fp, open); + spin_unlock(&fp->fi_lock); + if (!stp || nfsd4_lock_ol_stateid(stp) == nfs_ok) + break; + nfs4_put_stid(&stp->st_stid); + } + return stp; +} + static struct nfs4_openowner * alloc_init_open_stateowner(unsigned int strhashval, struct nfsd4_open *open, struct nfsd4_compound_state *cstate) @@ -3432,6 +3480,7 @@ init_open_stateid(struct nfs4_file *fp, mutex_init(&stp->st_mutex); mutex_lock(&stp->st_mutex); +retry: spin_lock(&oo->oo_owner.so_client->cl_lock); spin_lock(&fp->fi_lock); @@ -3456,7 +3505,11 @@ out_unlock: spin_unlock(&fp->fi_lock); spin_unlock(&oo->oo_owner.so_client->cl_lock); if (retstp) { - mutex_lock(&retstp->st_mutex); + /* Handle races with CLOSE */ + if (nfsd4_lock_ol_stateid(retstp) != nfs_ok) { + nfs4_put_stid(&retstp->st_stid); + goto retry; + } /* To keep mutex tracking happy */ mutex_unlock(&stp->st_mutex); stp = retstp; @@ -4277,9 +4330,7 @@ nfsd4_process_open2(struct svc_rqst *rqs status = nfs4_check_deleg(cl, open, &dp); if (status) goto out; - spin_lock(&fp->fi_lock); - stp = nfsd4_find_existing_open(fp, open); - spin_unlock(&fp->fi_lock); + stp = nfsd4_find_and_lock_existing_open(fp, open); } else { open->op_file = NULL; status = nfserr_bad_stateid; @@ -4293,7 +4344,6 @@ nfsd4_process_open2(struct svc_rqst *rqs */ if (stp) { /* Stateid was found, this is an OPEN upgrade */ - mutex_lock(&stp->st_mutex); status = nfs4_upgrade_open(rqstp, fp, current_fh, stp, open); if (status) { mutex_unlock(&stp->st_mutex); @@ -5150,7 +5200,6 @@ static void nfsd4_close_open_stateid(str bool unhashed; LIST_HEAD(reaplist); - s->st_stid.sc_type = NFS4_CLOSED_STID; spin_lock(&clp->cl_lock); unhashed = unhash_open_stateid(s, &reaplist); @@ -5189,10 +5238,12 @@ nfsd4_close(struct svc_rqst *rqstp, stru nfsd4_bump_seqid(cstate, status); if (status) goto out; + + stp->st_stid.sc_type = NFS4_CLOSED_STID; nfs4_inc_and_copy_stateid(&close->cl_stateid, &stp->st_stid); - mutex_unlock(&stp->st_mutex); nfsd4_close_open_stateid(stp); + mutex_unlock(&stp->st_mutex); /* put reference from nfs4_preprocess_seqid_op */ nfs4_put_stid(&stp->st_stid); Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.4/nfsd-fix-stateid-races-between-open-and-close.patch queue-4.4/nfsd-fix-another-open-stateid-race.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Prevent zero length "index" write" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Prevent zero length "index" write to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-prevent-zero-length-index-write.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 56350fb8978bbf4aafe08f21234e161dd128b417 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 23 Nov 2017 21:41:57 +0200 Subject: drm/i915: Prevent zero length "index" write MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit 56350fb8978bbf4aafe08f21234e161dd128b417 upstream. The hardware always writes one or two bytes in the index portion of an indexed transfer. Make sure the message we send as the index doesn't have a zero length. Cc: Daniel Kurtz <djkurtz(a)chromium.org> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sean Paul <seanpaul(a)chromium.org> Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.… Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> (cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_i2c.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -441,7 +441,8 @@ gmbus_is_index_read(struct i2c_msg *msgs { return (i + 1 < num && msgs[i].addr == msgs[i + 1].addr && - !(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 && + !(msgs[i].flags & I2C_M_RD) && + (msgs[i].len == 1 || msgs[i].len == 2) && (msgs[i + 1].flags & I2C_M_RD)); } Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.4/drm-i915-prevent-zero-length-index-write.patch queue-4.4/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Don't try indexed reads to alternate slave addresses" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Don't try indexed reads to alternate slave addresses to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ae5c631e605a452a5a0e73205a92810c01ed954b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 23 Nov 2017 21:41:56 +0200 Subject: drm/i915: Don't try indexed reads to alternate slave addresses MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit ae5c631e605a452a5a0e73205a92810c01ed954b upstream. We can only specify the one slave address to indexed reads/writes. Make sure the messages we check are destined to the same slave address before deciding to do an indexed transfer. Cc: Daniel Kurtz <djkurtz(a)chromium.org> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sean Paul <seanpaul(a)chromium.org> Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.… Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> (cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_i2c.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -440,6 +440,7 @@ static bool gmbus_is_index_read(struct i2c_msg *msgs, int i, int num) { return (i + 1 < num && + msgs[i].addr == msgs[i + 1].addr && !(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 && (msgs[i + 1].flags & I2C_M_RD)); } Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.4/drm-i915-prevent-zero-length-index-write.patch queue-4.4/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "[PATCH] Revert "x86/entry/64: Add missing irqflags tracing to" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [PATCH] Revert "x86/entry/64: Add missing irqflags tracing to to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: revert-x86-entry-64-add-missing-irqflags-tracing-to.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0ed6c0c778e67f00978a778612862441e48cc529 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Mon, 4 Dec 2017 12:59:57 +0100 Subject: [PATCH] Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()" This reverts commit f9a64e23a9da528e7d8aa1bd2c7bb92be4ebb724 which is commit 0d794d0d018f23fb09c50f6ae26868bd6ae343d6 upstream. Andy writes: I think the thing to do is to revert the patch from -stable. The bug it fixes is very minor, and the regression is that it made a pre-existing bug in some nearly-undebuggable core resume code much easier to hit. I don't feel comfortable with a backport of the latter fix until it has a good long soak in Linus' tree. Reported-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bpetkov(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/entry/entry_64.S | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -51,19 +51,15 @@ ENTRY(native_usergs_sysret64) END(native_usergs_sysret64) #endif /* CONFIG_PARAVIRT */ -.macro TRACE_IRQS_FLAGS flags:req +.macro TRACE_IRQS_IRETQ #ifdef CONFIG_TRACE_IRQFLAGS - bt $9, \flags /* interrupts off? */ + bt $9, EFLAGS(%rsp) /* interrupts off? */ jnc 1f TRACE_IRQS_ON 1: #endif .endm -.macro TRACE_IRQS_IRETQ - TRACE_IRQS_FLAGS EFLAGS(%rsp) -.endm - /* * When dynamic function tracer is enabled it will add a breakpoint * to all locations that it is about to modify, sync CPUs, update @@ -927,13 +923,11 @@ ENTRY(native_load_gs_index) FRAME_BEGIN pushfq DISABLE_INTERRUPTS(CLBR_ANY & ~CLBR_RDI) - TRACE_IRQS_OFF SWAPGS .Lgs_change: movl %edi, %gs 2: ALTERNATIVE "", "mfence", X86_BUG_SWAPGS_FENCE SWAPGS - TRACE_IRQS_FLAGS (%rsp) popfq FRAME_END ret Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-4.14/nvme-pci-add-quirk-for-delay-before-chk-rdy-for-wdc-sn200.patch queue-4.14/drm-i915-prevent-zero-length-index-write.patch queue-4.14/autofs-revert-autofs-fix-at_no_automount-not-being-honored.patch queue-4.14/crypto-af_alg-remove-locking-in-async-callback.patch queue-4.14/i2c-i801-fix-failed-to-allocate-irq-2147483648-error.patch queue-4.14/drm-amd-pp-fix-typecast-error-in-powerplay.patch queue-4.14/mmc-block-check-return-value-of-blk_get_request.patch queue-4.14/drm-panel-simple-add-missing-panel_simple_unprepare-calls.patch queue-4.14/drm-ttm-fix-ttm_bo_cleanup_refs_or_queue-once-more.patch queue-4.14/drm-i915-re-register-pmic-bus-access-notifier-on-runtime-resume.patch queue-4.14/platform-x86-hp-wmi-fix-tablet-mode-detection-for-convertibles.patch queue-4.14/mm-hugetlbfs-introduce-split-to-vm_operations_struct.patch queue-4.14/mmc-block-fix-missing-blk_put_request.patch queue-4.14/ib-hfi1-do-not-warn-on-lid-conversions-for-opa.patch queue-4.14/mmc-block-ensure-that-debugfs-files-are-removed.patch queue-4.14/mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch queue-4.14/arm64-ftrace-emit-ftrace-mod.o-contents-through-code.patch queue-4.14/kvm-lapic-fixup-ldr-on-load-in-x2apic.patch queue-4.14/powerpc-powernv-fix-kexec-crashes-caused-by-tlbie-tracing.patch queue-4.14/s390-revert-elf_et_dyn_base-base-changes.patch queue-4.14/mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry.patch queue-4.14/drm-omapdrm-fix-dpi-on-platforms-using-the-dsi-vdds.patch queue-4.14/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch queue-4.14/mm-memory_hotplug-do-not-back-off-draining-pcp-free-pages-from-kworker-context.patch queue-4.14/ib-core-disable-memory-registration-of-filesystem-dax-vmas.patch queue-4.14/drm-hisilicon-ensure-ldi-regs-are-properly-configured.patch queue-4.14/bcache-fix-building-error-on-mips.patch queue-4.14/exec-avoid-rlimit_stack-races-with-prlimit.patch queue-4.14/nfsd-fix-stateid-races-between-open-and-close.patch queue-4.14/drm-i915-gvt-correct-addr_4k-2m-1g_mask-definition.patch queue-4.14/drm-ttm-once-more-fix-ttm_buffer_object_transfer.patch queue-4.14/mm-introduce-get_user_pages_longterm.patch queue-4.14/bcache-only-permit-to-recovery-read-error-when-cache-device-is-clean.patch queue-4.14/mm-fail-get_vaddr_frames-for-filesystem-dax-mappings.patch queue-4.14/revert-x86-entry-64-add-missing-irqflags-tracing-to.patch queue-4.14/ib-core-do-not-warn-on-lid-conversions-for-opa.patch queue-4.14/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch queue-4.14/drm-edid-don-t-send-non-zero-yq-in-avi-infoframe-for-hdmi-1.x-sinks.patch queue-4.14/acpi-ec-fix-regression-related-to-pm-ops-support-in-ecdt-device.patch queue-4.14/arm64-module-plts-factor-out-plt-generation-code-for-ftrace.patch queue-4.14/device-dax-implement-split-to-catch-invalid-munmap-attempts.patch queue-4.14/drm-radeon-fix-atombios-on-big-endian.patch queue-4.14/eeprom-at24-fix-reading-from-24mac402-24mac602.patch queue-4.14/drm-amdgpu-reserve-root-pd-while-releasing-it.patch queue-4.14/hwmon-jc42-optionally-try-to-disable-the-smbus-timeout.patch queue-4.14/e1000e-fix-the-use-of-magic-numbers-for-buffer-overrun-issue.patch queue-4.14/powerpc-kexec-fix-kexec-kdump-in-p9-guest-kernels.patch queue-4.14/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch queue-4.14/drm-amdgpu-properly-allocate-vm-invalidate-eng-v2.patch queue-4.14/v4l2-disable-filesystem-dax-mapping-support.patch queue-4.14/lockd-lost-rollback-of-set_grace_period-in-lockd_down_net.patch queue-4.14/eeprom-at24-check-at24_read-write-arguments.patch queue-4.14/kvm-lapic-split-out-x2apic-ldr-calculation.patch queue-4.14/mmc-core-prepend-0x-to-ocr-entry-in-sysfs.patch queue-4.14/fs-fat-inode.c-fix-sb_rdonly-change.patch queue-4.14/mm-memcg-fix-mem_cgroup_swapout-for-thps.patch queue-4.14/nfsd-fix-panic-in-posix_unblock_lock-called-from-nfs4_laundromat.patch queue-4.14/bcache-recover-data-from-backing-when-data-is-clean.patch queue-4.14/crypto-algif_aead-skip-sgl-entries-with-null-page.patch queue-4.14/drm-amdgpu-correct-reference-clock-value-on-vega10.patch queue-4.14/mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages.patch queue-4.14/mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine.patch queue-4.14/drm-i915-fix-false-positive-assert_rpm_wakelock_held-in-i915_pmic_bus_access_notifier-v2.patch queue-4.14/drm-tilcdc-precalculate-total-frametime-in-tilcdc_crtc_set_mode.patch queue-4.14/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch queue-4.14/drm-amdgpu-set-adev-vcn.irq.num_types-for-vcn.patch queue-4.14/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch queue-4.14/nfsd-fix-another-open-stateid-race.patch queue-4.14/crypto-skcipher-fix-skcipher_walk_aead_common.patch queue-4.14/drm-amdgpu-fix-error-handling-in-amdgpu_bo_do_create.patch queue-4.14/md-forbid-a-raid5-from-having-both-a-bitmap-and-a-journal.patch queue-4.14/drm-fsl-dcu-don-t-set-connector-dpms-property.patch queue-4.14/omapdrm-hdmi4-correct-the-soc-revision-matching.patch queue-4.14/btrfs-clear-space-cache-inode-generation-always.patch queue-4.14/mmc-sdhci-avoid-swiotlb-buffer-being-full.patch queue-4.14/mmc-core-prepend-0x-to-pre_eol_info-entry-in-sysfs.patch queue-4.14/autofs-revert-autofs-take-more-care-to-not-update-last_used-on-path-walk.patch queue-4.14/eeprom-at24-correctly-set-the-size-for-at24mac402.patch queue-4.14/mm-cma-fix-alloc_contig_range-ret-code-potential-leak.patch queue-4.14/drm-i915-fbdev-serialise-early-hotplug-events-with-async-fbdev-config.patch queue-4.14/cxl-check-if-vphb-exists-before-iterating-over-afu-devices.patch queue-4.14/include-linux-compiler-clang.h-handle-randomizable-anonymous-structs.patch queue-4.14/drm-ttm-always-and-only-destroy-bo-ttm_resv-in-ttm_bo_release_list.patch queue-4.14/mm-thp-do-not-make-page-table-dirty-unconditionally-in-touch_pd.patch queue-4.14/revert-drm-radeon-dont-switch-vt-on-suspend.patch queue-4.14/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch queue-4.14/drm-amdgpu-remove-check-which-is-not-valid-for-certain-vbios.patch queue-4.14/mm-migrate-fix-an-incorrect-call-of-prep_transhuge_page.patch queue-4.14/apparmor-fix-oops-in-audit_signal_cb-hook.patch queue-4.14/dma-buf-make-reservation_object_copy_fences-rcu-save.patch queue-4.14/drm-amdgpu-move-uvd-vce-and-vcn-structure-out-from-union.patch queue-4.14/drm-vblank-fix-flip-event-vblank-count.patch queue-4.14/drm-fb_helper-disable-all-crtc-s-when-initial-setup-fails.patch queue-4.14/drm-vblank-tune-drm_crtc_accurate_vblank_count-warn-down-to-a-debug.patch queue-4.14/mm-madvise.c-fix-madvise-infinite-loop-under-special-circumstances.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Re-register PMIC bus access notifier on runtime resume" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Re-register PMIC bus access notifier on runtime resume to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-re-register-pmic-bus-access-notifier-on-runtime-resume.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 294cf1af8cf2eb0d1eced377fdfb9a2d3f0e8b42 Mon Sep 17 00:00:00 2001 From: Hans de Goede <j.w.r.degoede(a)gmail.com> Date: Tue, 14 Nov 2017 14:55:17 +0100 Subject: drm/i915: Re-register PMIC bus access notifier on runtime resume From: Hans de Goede <j.w.r.degoede(a)gmail.com> commit 294cf1af8cf2eb0d1eced377fdfb9a2d3f0e8b42 upstream. intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier and call that on runtime resume. Reported-by: Imre Deak <imre.deak(a)intel.com> Reviewed-by: Imre Deak <imre.deak(a)intel.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoe… (cherry picked from commit bedf4d79c3654921839b62246b0965ddb308b201) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/i915_drv.c | 2 ++ drivers/gpu/drm/i915/intel_uncore.c | 6 ++++++ drivers/gpu/drm/i915/intel_uncore.h | 1 + 3 files changed, 9 insertions(+) --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -2591,6 +2591,8 @@ static int intel_runtime_resume(struct d ret = vlv_resume_prepare(dev_priv, true); } + intel_uncore_runtime_resume(dev_priv); + /* * No point of rolling back things in case of an error, as the best * we can do is to hope that things will still work (and disable RPM). --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -434,6 +434,12 @@ void intel_uncore_resume_early(struct dr i915_check_and_clear_faults(dev_priv); } +void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv) +{ + iosf_mbi_register_pmic_bus_access_notifier( + &dev_priv->uncore.pmic_bus_access_nb); +} + void intel_uncore_sanitize(struct drm_i915_private *dev_priv) { i915.enable_rc6 = sanitize_rc6_option(dev_priv, i915.enable_rc6); --- a/drivers/gpu/drm/i915/intel_uncore.h +++ b/drivers/gpu/drm/i915/intel_uncore.h @@ -121,6 +121,7 @@ bool intel_uncore_arm_unclaimed_mmio_det void intel_uncore_fini(struct drm_i915_private *dev_priv); void intel_uncore_suspend(struct drm_i915_private *dev_priv); void intel_uncore_resume_early(struct drm_i915_private *dev_priv); +void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv); u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv); void assert_forcewakes_inactive(struct drm_i915_private *dev_priv); Patches currently in stable-queue which might be from j.w.r.degoede(a)gmail.com are queue-4.14/drm-i915-re-register-pmic-bus-access-notifier-on-runtime-resume.patch queue-4.14/drm-i915-fix-false-positive-assert_rpm_wakelock_held-in-i915_pmic_bus_access_notifier-v2.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Prevent zero length "index" write" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Prevent zero length "index" write to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-prevent-zero-length-index-write.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 56350fb8978bbf4aafe08f21234e161dd128b417 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 23 Nov 2017 21:41:57 +0200 Subject: drm/i915: Prevent zero length "index" write MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit 56350fb8978bbf4aafe08f21234e161dd128b417 upstream. The hardware always writes one or two bytes in the index portion of an indexed transfer. Make sure the message we send as the index doesn't have a zero length. Cc: Daniel Kurtz <djkurtz(a)chromium.org> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sean Paul <seanpaul(a)chromium.org> Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.… Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> (cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_i2c.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -439,7 +439,8 @@ gmbus_is_index_read(struct i2c_msg *msgs { return (i + 1 < num && msgs[i].addr == msgs[i + 1].addr && - !(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 && + !(msgs[i].flags & I2C_M_RD) && + (msgs[i].len == 1 || msgs[i].len == 2) && (msgs[i + 1].flags & I2C_M_RD)); } Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.14/drm-i915-prevent-zero-length-index-write.patch queue-4.14/drm-edid-don-t-send-non-zero-yq-in-avi-infoframe-for-hdmi-1.x-sinks.patch queue-4.14/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch queue-4.14/drm-vblank-fix-flip-event-vblank-count.patch queue-4.14/drm-vblank-tune-drm_crtc_accurate_vblank_count-warn-down-to-a-debug.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-gvt-correct-addr_4k-2m-1g_mask-definition.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b721b65af4eb46df6a1d9e34b14003225e403565 Mon Sep 17 00:00:00 2001 From: Xiong Zhang <xiong.y.zhang(a)intel.com> Date: Tue, 28 Nov 2017 07:29:54 +0800 Subject: drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition From: Xiong Zhang <xiong.y.zhang(a)intel.com> commit b721b65af4eb46df6a1d9e34b14003225e403565 upstream. For ADDR_4K_MASK, bit[45..12] should be 1, all other bits should be 0. The current definition wrongly set bit[46] as 1 also. This path fixes this. v2: Add commit message, fixes and cc stable.(Zhenyu) Fixes: 2707e4446688("drm/i915/gvt: vGPU graphics memory virtualization") Signed-off-by: Xiong Zhang <xiong.y.zhang(a)intel.com> Signed-off-by: Zhenyu Wang <zhenyuw(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/gvt/gtt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/i915/gvt/gtt.c +++ b/drivers/gpu/drm/i915/gvt/gtt.c @@ -311,9 +311,9 @@ static inline int gtt_set_entry64(void * #define GTT_HAW 46 -#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30 + 1)) - 1) << 30) -#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21 + 1)) - 1) << 21) -#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12 + 1)) - 1) << 12) +#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30)) - 1) << 30) +#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21)) - 1) << 21) +#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12)) - 1) << 12) static unsigned long gen8_gtt_get_pfn(struct intel_gvt_gtt_entry *e) { Patches currently in stable-queue which might be from xiong.y.zhang(a)intel.com are queue-4.14/drm-i915-gvt-correct-addr_4k-2m-1g_mask-definition.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-fix-false-positive-assert_rpm_wakelock_held-in-i915_pmic_bus_access_notifier-v2.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f4359cedfb43b934f38c50d1604db21333abe57b Mon Sep 17 00:00:00 2001 From: Hans de Goede <j.w.r.degoede(a)gmail.com> Date: Fri, 10 Nov 2017 16:03:01 +0100 Subject: drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 From: Hans de Goede <j.w.r.degoede(a)gmail.com> commit f4359cedfb43b934f38c50d1604db21333abe57b upstream. assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(&dev_priv->pm.wakeref_count); pm_runtime_mark_last_busy(kdev); pm_runtime_put_autosuspend(kdev); And pm_runtime_put_autosuspend calls intel_runtime_suspend from a workqueue, so there is ample of time between the atomic_dec() and intel_runtime_suspend() unregistering the notifier. If the notifier gets called in this windowd assert_rpm_wakelock_held falsely triggers (at this point we're not runtime-suspended yet). This commit adds disable_rpm_wakeref_asserts and enable_rpm_wakeref_asserts calls around the intel_uncore_forcewake_get(FORCEWAKE_ALL) call in i915_pmic_bus_access_notifier fixing the false-positive WARN_ON. Changes in v2: -Reword comment explaining why disabling the wakeref asserts is ok and necessary Reported-by: FKr <bugs-freedesktop(a)ubermail.me> Reviewed-by: Imre Deak <imre.deak(a)intel.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoed… (cherry picked from commit ce30560c80dead91e98a03d90fb8791e57a9b69d) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_uncore.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1171,8 +1171,15 @@ static int i915_pmic_bus_access_notifier * bus, which will be busy after this notification, leading to: * "render: timed out waiting for forcewake ack request." * errors. + * + * The notifier is unregistered during intel_runtime_suspend(), + * so it's ok to access the HW here without holding a RPM + * wake reference -> disable wakeref asserts for the time of + * the access. */ + disable_rpm_wakeref_asserts(dev_priv); intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL); + enable_rpm_wakeref_asserts(dev_priv); break; case MBI_PMIC_BUS_ACCESS_END: intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); Patches currently in stable-queue which might be from j.w.r.degoede(a)gmail.com are queue-4.14/drm-i915-re-register-pmic-bus-access-notifier-on-runtime-resume.patch queue-4.14/drm-i915-fix-false-positive-assert_rpm_wakelock_held-in-i915_pmic_bus_access_notifier-v2.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915/fbdev: Serialise early hotplug events with async fbdev config" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915/fbdev: Serialise early hotplug events with async fbdev config to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-fbdev-serialise-early-hotplug-events-with-async-fbdev-config.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a45b30a6c5db631e2ba680304bd5edd0cd1f9643 Mon Sep 17 00:00:00 2001 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Sat, 25 Nov 2017 19:41:55 +0000 Subject: drm/i915/fbdev: Serialise early hotplug events with async fbdev config From: Chris Wilson <chris(a)chris-wilson.co.uk> commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643 upstream. As both the hotplug event and fbdev configuration run asynchronously, it is possible for them to run concurrently. If configuration fails, we were freeing the fbdev causing a use-after-free in the hotplug event. <7>[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration <7>[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77 <7>[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0 <7>[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800 <7>[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config <7>[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0) <7>[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one <4>[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP <0>[ 3069.977453] --------------------------------- <4>[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915] <4>[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G U 4.14.0-CI-CI_DRM_3388+ #1 <4>[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 <4>[ 3069.977508] Workqueue: events output_poll_execute <4>[ 3069.977512] task: ffff880177734e40 task.stack: ffffc90001fe4000 <4>[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60 <4>[ 3069.977523] RSP: 0018:ffffc90001fe7bb0 EFLAGS: 00010002 <4>[ 3069.977526] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000282 RCX: 0000000000000000 <4>[ 3069.977530] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880170d4efd0 <4>[ 3069.977534] RBP: ffffc90001fe7c70 R08: 0000000000000001 R09: 0000000000000000 <4>[ 3069.977538] R10: 0000000000000000 R11: ffffffff81899609 R12: ffff880170d4efd0 <4>[ 3069.977542] R13: ffff880177734e40 R14: 0000000000000001 R15: 0000000000000000 <4>[ 3069.977547] FS: 0000000000000000(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000 <4>[ 3069.977551] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 3069.977555] CR2: 00007f7e8b7bcf04 CR3: 0000000003e0f000 CR4: 00000000003406e0 <4>[ 3069.977559] Call Trace: <4>[ 3069.977565] ? mark_held_locks+0x64/0x90 <4>[ 3069.977571] ? _raw_spin_unlock_irq+0x24/0x50 <4>[ 3069.977575] ? _raw_spin_unlock_irq+0x24/0x50 <4>[ 3069.977579] ? trace_hardirqs_on_caller+0xde/0x1c0 <4>[ 3069.977583] ? _raw_spin_unlock_irq+0x2f/0x50 <4>[ 3069.977588] ? finish_task_switch+0xa5/0x210 <4>[ 3069.977592] ? lock_acquire+0xaf/0x200 <4>[ 3069.977596] lock_acquire+0xaf/0x200 <4>[ 3069.977600] ? __mutex_lock+0x5e9/0x9b0 <4>[ 3069.977604] _raw_spin_lock+0x2a/0x40 <4>[ 3069.977608] ? __mutex_lock+0x5e9/0x9b0 <4>[ 3069.977612] __mutex_lock+0x5e9/0x9b0 <4>[ 3069.977616] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0 <4>[ 3069.977621] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0 <4>[ 3069.977625] drm_fb_helper_hotplug_event.part.19+0x16/0xa0 <4>[ 3069.977630] output_poll_execute+0x8d/0x180 <4>[ 3069.977635] process_one_work+0x22e/0x660 <4>[ 3069.977640] worker_thread+0x48/0x3a0 <4>[ 3069.977644] ? _raw_spin_unlock_irqrestore+0x4c/0x60 <4>[ 3069.977649] kthread+0x102/0x140 <4>[ 3069.977653] ? process_one_work+0x660/0x660 <4>[ 3069.977657] ? kthread_create_on_node+0x40/0x40 <4>[ 3069.977662] ret_from_fork+0x27/0x40 <4>[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff <f0> ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85 <1>[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP: ffffc90001fe7bb0 <4>[ 3069.977712] ---[ end trace 4ad012eb3af62df7 ]--- In order to keep the dev_priv->ifbdev alive after failure, we have to avoid the free and leave it empty until we unload the module (which is less than ideal, but a necessary evil for simplicity). Then we can use intel_fbdev_sync() to serialise the hotplug event with the configuration. The serialisation between the two was removed in commit 934458c2c95d ("Revert "drm/i915: Fix races on fbdev""), but the use after free is much older, commit 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails") Fixes: 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails") Fixes: 934458c2c95d ("Revert "drm/i915: Fix races on fbdev"") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Reviewed-by: Lukas Wunner <lukas(a)wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@ch… (cherry picked from commit ad88d7fc6c032ddfb32b8d496a070ab71de3a64f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_fbdev.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -694,10 +694,8 @@ static void intel_fbdev_initial_config(v /* Due to peculiar init order wrt to hpd handling this is separate. */ if (drm_fb_helper_initial_config(&ifbdev->helper, - ifbdev->preferred_bpp)) { + ifbdev->preferred_bpp)) intel_fbdev_unregister(to_i915(ifbdev->helper.dev)); - intel_fbdev_fini(to_i915(ifbdev->helper.dev)); - } } void intel_fbdev_initial_config_async(struct drm_device *dev) @@ -797,7 +795,11 @@ void intel_fbdev_output_poll_changed(str { struct intel_fbdev *ifbdev = to_i915(dev)->fbdev; - if (ifbdev) + if (!ifbdev) + return; + + intel_fbdev_sync(ifbdev); + if (ifbdev->vma) drm_fb_helper_hotplug_event(&ifbdev->helper); } Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are queue-4.14/drm-i915-prevent-zero-length-index-write.patch queue-4.14/drm-i915-fbdev-serialise-early-hotplug-events-with-async-fbdev-config.patch queue-4.14/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/entry/64: Add missing irqflags tracing to native_load_gs_index() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-entry-64-add-missing-irqflags-tracing-to-native_load_gs_index.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ca37e57bbe0cf1455ea3e84eb89ed04a132d59e1 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Wed, 22 Nov 2017 20:39:16 -0800 Subject: x86/entry/64: Add missing irqflags tracing to native_load_gs_index() From: Andy Lutomirski <luto(a)kernel.org> commit ca37e57bbe0cf1455ea3e84eb89ed04a132d59e1 upstream. Running this code with IRQs enabled (where dummy_lock is a spinlock): static void check_load_gs_index(void) { /* This will fail. */ load_gs_index(0xffff); spin_lock(&dummy_lock); spin_unlock(&dummy_lock); } Will generate a lockdep warning. The issue is that the actual write to %gs would cause an exception with IRQs disabled, and the exception handler would, as an inadvertent side effect, update irqflag tracing to reflect the IRQs-off status. native_load_gs_index() would then turn IRQs back on and return with irqflag tracing still thinking that IRQs were off. The dummy lock-and-unlock causes lockdep to notice the error and warn. Fix it by adding the missing tracing. Apparently nothing did this in a context where it mattered. I haven't tried to find a code path that would actually exhibit the warning if appropriately nasty user code were running. I suspect that the security impact of this bug is very, very low -- production systems don't run with lockdep enabled, and the warning is mostly harmless anyway. Found during a quick audit of the entry code to try to track down an unrelated bug that Ingo found in some still-in-development code. Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bpetkov(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/e1aeb0e6ba8dd430ec36c8a35e63b429698b4132.151141191… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/entry/entry_64.S | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -54,15 +54,19 @@ ENTRY(native_usergs_sysret64) ENDPROC(native_usergs_sysret64) #endif /* CONFIG_PARAVIRT */ -.macro TRACE_IRQS_IRETQ +.macro TRACE_IRQS_FLAGS flags:req #ifdef CONFIG_TRACE_IRQFLAGS - bt $9, EFLAGS(%rsp) /* interrupts off? */ + bt $9, \flags /* interrupts off? */ jnc 1f TRACE_IRQS_ON 1: #endif .endm +.macro TRACE_IRQS_IRETQ + TRACE_IRQS_FLAGS EFLAGS(%rsp) +.endm + /* * When dynamic function tracer is enabled it will add a breakpoint * to all locations that it is about to modify, sync CPUs, update @@ -868,11 +872,13 @@ idtentry simd_coprocessor_error do_simd ENTRY(native_load_gs_index) pushfq DISABLE_INTERRUPTS(CLBR_ANY & ~CLBR_RDI) + TRACE_IRQS_OFF SWAPGS .Lgs_change: movl %edi, %gs 2: ALTERNATIVE "", "mfence", X86_BUG_SWAPGS_FENCE SWAPGS + TRACE_IRQS_FLAGS (%rsp) popfq ret END(native_load_gs_index) Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.9/x86-entry-64-add-missing-irqflags-tracing-to-native_load_gs_index.patch

7 years, 7 months

4
7
0 0

[Linux-stable-mirror] Patch "drm/i915: Don't try indexed reads to alternate slave addresses" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Don't try indexed reads to alternate slave addresses to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ae5c631e605a452a5a0e73205a92810c01ed954b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 23 Nov 2017 21:41:56 +0200 Subject: drm/i915: Don't try indexed reads to alternate slave addresses MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit ae5c631e605a452a5a0e73205a92810c01ed954b upstream. We can only specify the one slave address to indexed reads/writes. Make sure the messages we check are destined to the same slave address before deciding to do an indexed transfer. Cc: Daniel Kurtz <djkurtz(a)chromium.org> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sean Paul <seanpaul(a)chromium.org> Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.… Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> (cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_i2c.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -438,6 +438,7 @@ static bool gmbus_is_index_read(struct i2c_msg *msgs, int i, int num) { return (i + 1 < num && + msgs[i].addr == msgs[i + 1].addr && !(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 && (msgs[i + 1].flags & I2C_M_RD)); } Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.14/drm-i915-prevent-zero-length-index-write.patch queue-4.14/drm-edid-don-t-send-non-zero-yq-in-avi-infoframe-for-hdmi-1.x-sinks.patch queue-4.14/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch queue-4.14/drm-vblank-fix-flip-event-vblank-count.patch queue-4.14/drm-vblank-tune-drm_crtc_accurate_vblank_count-warn-down-to-a-debug.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Prevent zero length "index" write" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Prevent zero length "index" write to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-prevent-zero-length-index-write.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 56350fb8978bbf4aafe08f21234e161dd128b417 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 23 Nov 2017 21:41:57 +0200 Subject: drm/i915: Prevent zero length "index" write MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit 56350fb8978bbf4aafe08f21234e161dd128b417 upstream. The hardware always writes one or two bytes in the index portion of an indexed transfer. Make sure the message we send as the index doesn't have a zero length. Cc: Daniel Kurtz <djkurtz(a)chromium.org> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sean Paul <seanpaul(a)chromium.org> Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.… Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> (cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_i2c.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -395,7 +395,8 @@ gmbus_is_index_read(struct i2c_msg *msgs { return (i + 1 < num && msgs[i].addr == msgs[i + 1].addr && - !(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 && + !(msgs[i].flags & I2C_M_RD) && + (msgs[i].len == 1 || msgs[i].len == 2) && (msgs[i + 1].flags & I2C_M_RD)); } Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-3.18/drm-i915-prevent-zero-length-index-write.patch queue-3.18/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Don't try indexed reads to alternate slave addresses" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Don't try indexed reads to alternate slave addresses to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ae5c631e605a452a5a0e73205a92810c01ed954b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 23 Nov 2017 21:41:56 +0200 Subject: drm/i915: Don't try indexed reads to alternate slave addresses MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit ae5c631e605a452a5a0e73205a92810c01ed954b upstream. We can only specify the one slave address to indexed reads/writes. Make sure the messages we check are destined to the same slave address before deciding to do an indexed transfer. Cc: Daniel Kurtz <djkurtz(a)chromium.org> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sean Paul <seanpaul(a)chromium.org> Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.… Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> (cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_i2c.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -394,6 +394,7 @@ static bool gmbus_is_index_read(struct i2c_msg *msgs, int i, int num) { return (i + 1 < num && + msgs[i].addr == msgs[i + 1].addr && !(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 && (msgs[i + 1].flags & I2C_M_RD)); } Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-3.18/drm-i915-prevent-zero-length-index-write.patch queue-3.18/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] drm/i915: Flush pending GTT writes before unbinding

by Chris Wilson

>From the shrinker paths, we want to relinquish the GPU and GGTT access to the object, releasing the backing storage back to the system for swapout. As a part of that process we would unpin the pages, marking them for access by the CPU (for the swapout/swapin). However, if that process was interrupted after unbind the vma, we missed a flush of the inflight GGTT writes before we made that GTT space available again for reuse, with the prospect that we would redirect them to another page. The bug dates back to the introduction of multiple GGTT vma, but the code itself dates to commit 02bef8f98d26 ("drm/i915: Unbind closed vma for i915_gem_object_unbind()"). Fixes: 02bef8f98d26 ("drm/i915: Unbind closed vma for i915_gem_object_unbind()") Fixes: c5ad54cf7dd8 ("drm/i915: Use partial view in mmap fault handler") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/i915_gem.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index e083f242b8dc..80b78fb5daac 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -330,17 +330,10 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj) * must wait for all rendering to complete to the object (as unbinding * must anyway), and retire the requests. */ - ret = i915_gem_object_wait(obj, - I915_WAIT_INTERRUPTIBLE | - I915_WAIT_LOCKED | - I915_WAIT_ALL, - MAX_SCHEDULE_TIMEOUT, - NULL); + ret = i915_gem_object_set_to_cpu_domain(obj, false); if (ret) return ret; - i915_gem_retire_requests(to_i915(obj->base.dev)); - while ((vma = list_first_entry_or_null(&obj->vma_list, struct i915_vma, obj_link))) { -- 2.15.1

7 years, 7 months

2
2
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] drm/i915: Calculate ironlake intermediate watermarks" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 90c702b88e5b5bbe2be53848aa3aba7c2b64223f Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Date: Thu, 19 Oct 2017 17:13:41 +0200 Subject: [PATCH] drm/i915: Calculate ironlake intermediate watermarks correctly, v2. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The watermarks it should calculate against are the old optimal watermarks. The currently active crtc watermarks are pure fiction, and are invalid in case of a nonblocking modeset, page flip enabling/disabling planes or any other reason. When the crtc is disabled or during a modeset the intermediate watermarks don't need to be programmed separately, and could be directly assigned to the optimal watermarks. Changes since v1: - Use intel_atomic_get_old_crtc_state. (ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019151341.4579-2-maarten… [mlankhorst: Add cc stable and bugzilla link, since previous patch doesn't fix issue by itself] Cc: stable(a)vger.kernel.org #v4.8+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373 (cherry picked from commit b6b178a77210055b153dbc175e4468bd3c7122df) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index c42a65a93b3a..7d2ecabc5de5 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3133,7 +3133,11 @@ static int ilk_compute_intermediate_wm(struct drm_device *dev, struct intel_crtc_state *newstate) { struct intel_pipe_wm *a = &newstate->wm.ilk.intermediate; - struct intel_pipe_wm *b = &intel_crtc->wm.active.ilk; + struct intel_atomic_state *intel_state = + to_intel_atomic_state(newstate->base.state); + const struct intel_crtc_state *oldstate = + intel_atomic_get_old_crtc_state(intel_state, intel_crtc); + const struct intel_pipe_wm *b = &oldstate->wm.ilk.optimal; int level, max_level = ilk_wm_max_level(to_i915(dev)); /* @@ -3142,6 +3146,9 @@ static int ilk_compute_intermediate_wm(struct drm_device *dev, * and after the vblank. */ *a = newstate->wm.ilk.optimal; + if (!newstate->base.active || drm_atomic_crtc_needs_modeset(&newstate->base)) + return 0; + a->pipe_enabled |= b->pipe_enabled; a->sprites_enabled |= b->sprites_enabled; a->sprites_scaled |= b->sprites_scaled;

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] eeprom: at24: correctly set the size for at24mac402

by Bartosz Golaszewski

There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6, making it impossible to read it all. Fix it by manually adjusting the value in probe(). This patch contains a temporary fix that is suitable for stable branches. Eventually we'll probably remove the call to ilog2() while converting the magic values to actual structs. Cc: stable(a)vger.kernel.org Fixes: 0b813658c115 ("eeprom: at24: add support for at24mac series") Signed-off-by: Bartosz Golaszewski <brgl(a)bgdev.pl> --- drivers/misc/eeprom/at24.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c index e0b4b36ef010..783244b485cc 100644 --- a/drivers/misc/eeprom/at24.c +++ b/drivers/misc/eeprom/at24.c @@ -730,6 +730,16 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id) dev_warn(&client->dev, "page_size looks suspicious (no power of 2)!\n"); + /* + * REVISIT: the size of the EUI-48 byte array is 6 in at24mac402, while + * the call to ilog2() in AT24_DEVICE_MAGIC() rounds it down to 4. + * + * Eventually we'll get rid of the magic values altoghether in favor of + * real structs, but for now just manually set the right size. + */ + if (chip.flags & AT24_FLAG_MAC && chip.byte_len == 4) + chip.byte_len = 6; + /* Use I2C operations unless we're stuck with SMBus extensions. */ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) { if (chip.flags & AT24_FLAG_ADDR16) -- 2.15.0

7 years, 7 months

4
5
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] drm/i915: Move init_clock_gating() back to where it was" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 6ac43272768ca901daac4076a66c2c4e3c7b9321 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Wed, 8 Nov 2017 15:35:55 +0200 Subject: [PATCH] drm/i915: Move init_clock_gating() back to where it was MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Apparently setting up a bunch of GT registers before we've properly initialized the rest of the GT hardware leads to these setting being lost. So looks like I broke HSW with commit b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") by doing init_clock_gating() too early. This should actually affect other platforms as well, but apparently not to such a great degree. What I was ultimately after in that commit was to move the ilk_init_lp_watermarks() call earlier. So let's undo the damage and move init_clock_gating() back to where it was, and call ilk_init_lp_watermarks() just before the watermark state readout. This highlights how fragile and messed up our init order really is. I wonder why we even initialize the display before gem. The opposite order would make much more sense to me... v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must be done before all planes might get disabled. Cc: stable(a)vger.kernel.org Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Mark Janes <mark.a.janes(a)intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Oscar Mateo <oscar.mateo(a)intel.com> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Reported-by: Mark Janes <mark.a.janes(a)intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549 Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.… Tested-by: Chris Wilson <chris(a)chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> (cherry picked from commit f72b84c677d61f201b869223a8d6e389c7bb7d3d) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e2ac976844d8..f4a9a182868f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3676,6 +3676,7 @@ void intel_finish_reset(struct drm_i915_private *dev_priv) intel_pps_unlock_regs_wa(dev_priv); intel_modeset_init_hw(dev); + intel_init_clock_gating(dev_priv); spin_lock_irq(&dev_priv->irq_lock); if (dev_priv->display.hpd_irq_setup) @@ -14350,8 +14351,6 @@ void intel_modeset_init_hw(struct drm_device *dev) intel_update_cdclk(dev_priv); dev_priv->cdclk.logical = dev_priv->cdclk.actual = dev_priv->cdclk.hw; - - intel_init_clock_gating(dev_priv); } /* @@ -15063,6 +15062,15 @@ intel_modeset_setup_hw_state(struct drm_device *dev, struct intel_encoder *encoder; int i; + if (IS_HASWELL(dev_priv)) { + /* + * WaRsPkgCStateDisplayPMReq:hsw + * System hang if this isn't done before disabling all planes! + */ + I915_WRITE(CHICKEN_PAR1_1, + I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES); + } + intel_modeset_readout_hw_state(dev); /* HW state is read out, now we need to sanitize this mess. */ @@ -15160,6 +15168,8 @@ void intel_modeset_gem_init(struct drm_device *dev) intel_init_gt_powersave(dev_priv); + intel_init_clock_gating(dev_priv); + intel_setup_overlay(dev_priv); } diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 7d2ecabc5de5..aa12a44e9a76 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5762,12 +5762,30 @@ void vlv_wm_sanitize(struct drm_i915_private *dev_priv) mutex_unlock(&dev_priv->wm.wm_mutex); } +/* + * FIXME should probably kill this and improve + * the real watermark readout/sanitation instead + */ +static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv) +{ + I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN); + I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN); + I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN); + + /* + * Don't touch WM1S_LP_EN here. + * Doing so could cause underruns. + */ +} + void ilk_wm_get_hw_state(struct drm_device *dev) { struct drm_i915_private *dev_priv = to_i915(dev); struct ilk_wm_values *hw = &dev_priv->wm.hw; struct drm_crtc *crtc; + ilk_init_lp_watermarks(dev_priv); + for_each_crtc(dev, crtc) ilk_pipe_wm_get_hw_state(crtc); @@ -8214,18 +8232,6 @@ static void g4x_disable_trickle_feed(struct drm_i915_private *dev_priv) } } -static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv) -{ - I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN); - I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN); - I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN); - - /* - * Don't touch WM1S_LP_EN here. - * Doing so could cause underruns. - */ -} - static void ilk_init_clock_gating(struct drm_i915_private *dev_priv) { uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; @@ -8259,8 +8265,6 @@ static void ilk_init_clock_gating(struct drm_i915_private *dev_priv) (I915_READ(DISP_ARB_CTL) | DISP_FBC_WM_DIS)); - ilk_init_lp_watermarks(dev_priv); - /* * Based on the document from hardware guys the following bits * should be set unconditionally in order to enable FBC. @@ -8373,8 +8377,6 @@ static void gen6_init_clock_gating(struct drm_i915_private *dev_priv) I915_WRITE(GEN6_GT_MODE, _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4)); - ilk_init_lp_watermarks(dev_priv); - I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB)); @@ -8601,8 +8603,6 @@ static void bdw_init_clock_gating(struct drm_i915_private *dev_priv) I915_GTT_PAGE_SIZE_2M); enum pipe pipe; - ilk_init_lp_watermarks(dev_priv); - /* WaSwitchSolVfFArbitrationPriority:bdw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); @@ -8653,8 +8653,6 @@ static void bdw_init_clock_gating(struct drm_i915_private *dev_priv) static void hsw_init_clock_gating(struct drm_i915_private *dev_priv) { - ilk_init_lp_watermarks(dev_priv); - /* L3 caching of data atomics doesn't work -- disable it. */ I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE); I915_WRITE(HSW_ROW_CHICKEN3, @@ -8698,10 +8696,6 @@ static void hsw_init_clock_gating(struct drm_i915_private *dev_priv) /* WaSwitchSolVfFArbitrationPriority:hsw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); - /* WaRsPkgCStateDisplayPMReq:hsw */ - I915_WRITE(CHICKEN_PAR1_1, - I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES); - lpt_init_clock_gating(dev_priv); } @@ -8709,8 +8703,6 @@ static void ivb_init_clock_gating(struct drm_i915_private *dev_priv) { uint32_t snpcr; - ilk_init_lp_watermarks(dev_priv); - I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE); /* WaDisableEarlyCull:ivb */

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] drm/i915: Calculate ironlake intermediate watermarks" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 90c702b88e5b5bbe2be53848aa3aba7c2b64223f Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Date: Thu, 19 Oct 2017 17:13:41 +0200 Subject: [PATCH] drm/i915: Calculate ironlake intermediate watermarks correctly, v2. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The watermarks it should calculate against are the old optimal watermarks. The currently active crtc watermarks are pure fiction, and are invalid in case of a nonblocking modeset, page flip enabling/disabling planes or any other reason. When the crtc is disabled or during a modeset the intermediate watermarks don't need to be programmed separately, and could be directly assigned to the optimal watermarks. Changes since v1: - Use intel_atomic_get_old_crtc_state. (ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019151341.4579-2-maarten… [mlankhorst: Add cc stable and bugzilla link, since previous patch doesn't fix issue by itself] Cc: stable(a)vger.kernel.org #v4.8+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373 (cherry picked from commit b6b178a77210055b153dbc175e4468bd3c7122df) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index c42a65a93b3a..7d2ecabc5de5 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3133,7 +3133,11 @@ static int ilk_compute_intermediate_wm(struct drm_device *dev, struct intel_crtc_state *newstate) { struct intel_pipe_wm *a = &newstate->wm.ilk.intermediate; - struct intel_pipe_wm *b = &intel_crtc->wm.active.ilk; + struct intel_atomic_state *intel_state = + to_intel_atomic_state(newstate->base.state); + const struct intel_crtc_state *oldstate = + intel_atomic_get_old_crtc_state(intel_state, intel_crtc); + const struct intel_pipe_wm *b = &oldstate->wm.ilk.optimal; int level, max_level = ilk_wm_max_level(to_i915(dev)); /* @@ -3142,6 +3146,9 @@ static int ilk_compute_intermediate_wm(struct drm_device *dev, * and after the vblank. */ *a = newstate->wm.ilk.optimal; + if (!newstate->base.active || drm_atomic_crtc_needs_modeset(&newstate->base)) + return 0; + a->pipe_enabled |= b->pipe_enabled; a->sprites_enabled |= b->sprites_enabled; a->sprites_scaled |= b->sprites_scaled;

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "[PATCH] Revert "x86/entry/64: Add missing irqflags tracing to" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [PATCH] Revert "x86/entry/64: Add missing irqflags tracing to to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: revert-x86-entry-64-add-missing-irqflags-tracing-to.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0ed6c0c778e67f00978a778612862441e48cc529 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Mon, 4 Dec 2017 12:59:57 +0100 Subject: [PATCH] Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()" This reverts commit 0d794d0d018f23fb09c50f6ae26868bd6ae343d6 which is commit 0d794d0d018f23fb09c50f6ae26868bd6ae343d6 upstream. Andy writes: I think the thing to do is to revert the patch from -stable. The bug it fixes is very minor, and the regression is that it made a pre-existing bug in some nearly-undebuggable core resume code much easier to hit. I don't feel comfortable with a backport of the latter fix until it has a good long soak in Linus' tree. Reported-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bpetkov(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/entry/entry_64.S | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index be9df513141e..e7b0e7ff4c58 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -54,19 +54,15 @@ ENTRY(native_usergs_sysret64) ENDPROC(native_usergs_sysret64) #endif /* CONFIG_PARAVIRT */ -.macro TRACE_IRQS_FLAGS flags:req +.macro TRACE_IRQS_IRETQ #ifdef CONFIG_TRACE_IRQFLAGS - bt $9, \flags /* interrupts off? */ + bt $9, EFLAGS(%rsp) /* interrupts off? */ jnc 1f TRACE_IRQS_ON 1: #endif .endm -.macro TRACE_IRQS_IRETQ - TRACE_IRQS_FLAGS EFLAGS(%rsp) -.endm - /* * When dynamic function tracer is enabled it will add a breakpoint * to all locations that it is about to modify, sync CPUs, update @@ -872,13 +868,11 @@ idtentry simd_coprocessor_error do_simd_coprocessor_error has_error_code=0 ENTRY(native_load_gs_index) pushfq DISABLE_INTERRUPTS(CLBR_ANY & ~CLBR_RDI) - TRACE_IRQS_OFF SWAPGS .Lgs_change: movl %edi, %gs 2: ALTERNATIVE "", "mfence", X86_BUG_SWAPGS_FENCE SWAPGS - TRACE_IRQS_FLAGS (%rsp) popfq ret END(native_load_gs_index) -- 2.15.1 Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-4.9/nvme-pci-add-quirk-for-delay-before-chk-rdy-for-wdc-sn200.patch queue-4.9/mfd-twl4030-power-fix-pmic-for-boards-that-need-vmmc1-on-reboot.patch queue-4.9/i2c-i801-fix-failed-to-allocate-irq-2147483648-error.patch queue-4.9/drm-amd-pp-fix-typecast-error-in-powerplay.patch queue-4.9/drm-panel-simple-add-missing-panel_simple_unprepare-calls.patch queue-4.9/mm-hugetlbfs-introduce-split-to-vm_operations_struct.patch queue-4.9/mmc-core-do-not-leave-the-block-driver-in-a-suspended-state.patch queue-4.9/kvm-lapic-fixup-ldr-on-load-in-x2apic.patch queue-4.9/arm-omap2-fix-wl1283-bluetooth-baud-rate.patch queue-4.9/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch queue-4.9/drm-hisilicon-ensure-ldi-regs-are-properly-configured.patch queue-4.9/bcache-fix-building-error-on-mips.patch queue-4.9/nfsd-fix-stateid-races-between-open-and-close.patch queue-4.9/drm-ttm-once-more-fix-ttm_buffer_object_transfer.patch queue-4.9/revert-x86-entry-64-add-missing-irqflags-tracing-to.patch queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch queue-4.9/drm-radeon-fix-atombios-on-big-endian.patch queue-4.9/eeprom-at24-fix-reading-from-24mac402-24mac602.patch queue-4.9/hwmon-jc42-optionally-try-to-disable-the-smbus-timeout.patch queue-4.9/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch queue-4.9/eeprom-at24-check-at24_read-write-arguments.patch queue-4.9/kvm-lapic-split-out-x2apic-ldr-calculation.patch queue-4.9/mmc-core-prepend-0x-to-ocr-entry-in-sysfs.patch queue-4.9/nfs-revalidate-.-etc-correctly-on-open.patch queue-4.9/nfsd-fix-panic-in-posix_unblock_lock-called-from-nfs4_laundromat.patch queue-4.9/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch queue-4.9/nfsd-fix-another-open-stateid-race.patch queue-4.9/btrfs-clear-space-cache-inode-generation-always.patch queue-4.9/eeprom-at24-correctly-set-the-size-for-at24mac402.patch queue-4.9/arm-dts-omap3-logicpd-torpedo-37xx-devkit-fix-mmc1-cd-gpio.patch queue-4.9/mm-cma-fix-alloc_contig_range-ret-code-potential-leak.patch queue-4.9/mm-thp-do-not-make-page-table-dirty-unconditionally-in-touch_pd.patch queue-4.9/revert-drm-radeon-dont-switch-vt-on-suspend.patch queue-4.9/arm-dts-logicpd-torpedo-fix-camera-pin-mux.patch queue-4.9/mm-madvise.c-fix-madvise-infinite-loop-under-special-circumstances.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "Revert "drm/radeon: dont switch vt on suspend"" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "drm/radeon: dont switch vt on suspend" to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: revert-drm-radeon-dont-switch-vt-on-suspend.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 18c437caa5b18a235dd65cec224eab54bebcee65 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher(a)amd.com> Date: Tue, 14 Nov 2017 17:19:29 -0500 Subject: Revert "drm/radeon: dont switch vt on suspend" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Alex Deucher <alexander.deucher(a)amd.com> commit 18c437caa5b18a235dd65cec224eab54bebcee65 upstream. Fixes distorted colors on some cards on resume from suspend. This reverts commit b9729b17a414f99c61f4db9ac9f9ed987fa0cbfe. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98832 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99163 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=107001 Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/radeon_fb.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -252,7 +252,6 @@ static int radeonfb_create(struct drm_fb } info->par = rfbdev; - info->skip_vt_switch = true; ret = radeon_framebuffer_init(rdev->ddev, &rfbdev->rfb, &mode_cmd, gobj); if (ret) { Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are queue-4.9/drm-amd-pp-fix-typecast-error-in-powerplay.patch queue-4.9/drm-ttm-once-more-fix-ttm_buffer_object_transfer.patch queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch queue-4.9/drm-radeon-fix-atombios-on-big-endian.patch queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch queue-4.9/revert-drm-radeon-dont-switch-vt-on-suspend.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "NFS: revalidate "." etc correctly on "open"." has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFS: revalidate "." etc correctly on "open". to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfs-revalidate-.-etc-correctly-on-open.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b688741cb06695312f18b730653d6611e1bad28d Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Fri, 25 Aug 2017 17:34:41 +1000 Subject: NFS: revalidate "." etc correctly on "open". From: NeilBrown <neilb(a)suse.com> commit b688741cb06695312f18b730653d6611e1bad28d upstream. For correct close-to-open semantics, NFS must validate the change attribute of a directory (or file) on open. Since commit ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op"), open() of "." or a path ending ".." is not revalidated reliably (except when that direct is a mount point). Prior to that commit, "." was revalidated using nfs_lookup_revalidate() which checks the LOOKUP_OPEN flag and forces revalidation if the flag is set. Since that commit, nfs_weak_revalidate() is used for NFSv3 (which ignores the flags) and nothing is used for NFSv4. This is fixed by using nfs_lookup_verify_inode() in nfs_weak_revalidate(). This does the revalidation exactly when needed. Also, add a definition of .d_weak_revalidate for NFSv4. The incorrect behavior is easily demonstrated by running "echo *" in some non-mountpoint NFS directory while watching network traffic. Without this patch, "echo *" sometimes doesn't produce any traffic. With the patch it always does. Fixes: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op") cc: stable(a)vger.kernel.org (3.9+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs/dir.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1292,7 +1292,7 @@ static int nfs_weak_revalidate(struct de return 0; } - error = nfs_revalidate_inode(NFS_SERVER(inode), inode); + error = nfs_lookup_verify_inode(inode, flags); dfprintk(LOOKUPCACHE, "NFS: %s: inode %lu is %s\n", __func__, inode->i_ino, error ? "invalid" : "valid"); return !error; @@ -1443,6 +1443,7 @@ static int nfs4_lookup_revalidate(struct const struct dentry_operations nfs4_dentry_operations = { .d_revalidate = nfs4_lookup_revalidate, + .d_weak_revalidate = nfs_weak_revalidate, .d_delete = nfs_dentry_delete, .d_iput = nfs_dentry_iput, .d_automount = nfs_d_automount, Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.9/nfs-revalidate-.-etc-correctly-on-open.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "nvme-pci: add quirk for delay before CHK RDY for WDC SN200" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nvme-pci: add quirk for delay before CHK RDY for WDC SN200 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nvme-pci-add-quirk-for-delay-before-chk-rdy-for-wdc-sn200.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8c97eeccf0ad8783c057830119467b877bdfced7 Mon Sep 17 00:00:00 2001 From: Jeff Lien <jeff.lien(a)wdc.com> Date: Tue, 21 Nov 2017 10:44:37 -0600 Subject: nvme-pci: add quirk for delay before CHK RDY for WDC SN200 From: Jeff Lien <jeff.lien(a)wdc.com> commit 8c97eeccf0ad8783c057830119467b877bdfced7 upstream. And increase the existing delay to cover this device as well. Signed-off-by: Jeff Lien <jeff.lien(a)wdc.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/host/nvme.h | 2 +- drivers/nvme/host/pci.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) --- a/drivers/nvme/host/nvme.h +++ b/drivers/nvme/host/nvme.h @@ -84,7 +84,7 @@ enum nvme_quirks { * NVME_QUIRK_DELAY_BEFORE_CHK_RDY quirk enabled. The value (in ms) was * found empirically. */ -#define NVME_QUIRK_DELAY_AMOUNT 2000 +#define NVME_QUIRK_DELAY_AMOUNT 2300 enum nvme_ctrl_state { NVME_CTRL_NEW, --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -2109,6 +2109,8 @@ static const struct pci_device_id nvme_i .driver_data = NVME_QUIRK_IDENTIFY_CNS, }, { PCI_DEVICE(0x1c58, 0x0003), /* HGST adapter */ .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, }, + { PCI_DEVICE(0x1c58, 0x0023), /* WDC SN200 adapter */ + .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, }, { PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */ .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, }, { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xffffff) }, Patches currently in stable-queue which might be from jeff.lien(a)wdc.com are queue-4.9/nvme-pci-add-quirk-for-delay-before-chk-rdy-for-wdc-sn200.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "hwmon: (jc42) optionally try to disable the SMBUS timeout" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwmon: (jc42) optionally try to disable the SMBUS timeout to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hwmon-jc42-optionally-try-to-disable-the-smbus-timeout.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 68615eb01f82256c19e41967bfb3eef902f77033 Mon Sep 17 00:00:00 2001 From: Peter Rosin <peda(a)axentia.se> Date: Mon, 27 Nov 2017 17:31:00 +0100 Subject: hwmon: (jc42) optionally try to disable the SMBUS timeout From: Peter Rosin <peda(a)axentia.se> commit 68615eb01f82256c19e41967bfb3eef902f77033 upstream. With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver is not always capable of avoiding the 25-35 ms timeout as specified by the SMBUS protocol. This may cause silent corruption of the last bit of any transfer, e.g. a one is read instead of a zero if the sensor chip times out. This also affects the eeprom half of the nxp-se97 chip, where this silent corruption was originally noticed. Other I2C adapters probably suffer similar issues, e.g. bit-banging comes to mind as risky... The SMBUS register in the nxp chip is not a standard Jedec register, but it is not special to the nxp chips either, at least the atmel chips have the same mechanism. Therefore, do not special case this on the manufacturer, it is opt-in via the device property anyway. Signed-off-by: Peter Rosin <peda(a)axentia.se> Acked-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/devicetree/bindings/hwmon/jc42.txt | 4 ++++ drivers/hwmon/jc42.c | 21 +++++++++++++++++++++ 2 files changed, 25 insertions(+) --- a/Documentation/devicetree/bindings/hwmon/jc42.txt +++ b/Documentation/devicetree/bindings/hwmon/jc42.txt @@ -34,6 +34,10 @@ Required properties: - reg: I2C address +Optional properties: +- smbus-timeout-disable: When set, the smbus timeout function will be disabled. + This is not supported on all chips. + Example: temp-sensor@1a { --- a/drivers/hwmon/jc42.c +++ b/drivers/hwmon/jc42.c @@ -22,6 +22,7 @@ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include <linux/bitops.h> #include <linux/module.h> #include <linux/init.h> #include <linux/slab.h> @@ -45,6 +46,7 @@ static const unsigned short normal_i2c[] #define JC42_REG_TEMP 0x05 #define JC42_REG_MANID 0x06 #define JC42_REG_DEVICEID 0x07 +#define JC42_REG_SMBUS 0x22 /* NXP and Atmel, possibly others? */ /* Status bits in temperature register */ #define JC42_ALARM_CRIT_BIT 15 @@ -73,6 +75,9 @@ static const unsigned short normal_i2c[] #define ONS_MANID 0x1b09 /* ON Semiconductor */ #define STM_MANID 0x104a /* ST Microelectronics */ +/* SMBUS register */ +#define SMBUS_STMOUT BIT(7) /* SMBus time-out, active low */ + /* Supported chips */ /* Analog Devices */ @@ -476,6 +481,22 @@ static int jc42_probe(struct i2c_client data->extended = !!(cap & JC42_CAP_RANGE); + if (device_property_read_bool(dev, "smbus-timeout-disable")) { + int smbus; + + /* + * Not all chips support this register, but from a + * quick read of various datasheets no chip appears + * incompatible with the below attempt to disable + * the timeout. And the whole thing is opt-in... + */ + smbus = i2c_smbus_read_word_swapped(client, JC42_REG_SMBUS); + if (smbus < 0) + return smbus; + i2c_smbus_write_word_swapped(client, JC42_REG_SMBUS, + smbus | SMBUS_STMOUT); + } + config = i2c_smbus_read_word_swapped(client, JC42_REG_CONFIG); if (config < 0) return config; Patches currently in stable-queue which might be from peda(a)axentia.se are queue-4.9/hwmon-jc42-optionally-try-to-disable-the-smbus-timeout.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror