Aleksa Sarai <asarai(a)suse.de> writes:
> On 11/05/2017 01:56 PM, Aleksa Sarai wrote:
>> Previously, the only capability effectively required to operate on the
>> /proc/scsi interface was CAP_DAC_OVERRIDE (or for some other files,
>> having an fsuid of GLOBAL_ROOT_UID was enough). This means that
>> semi-privileged processes could interfere with core components of a
>> system (such as causing a DoS by removing the underlying SCSI device of
>> the host's / mount).
>
> An alternative to this patch would be to make the open(2) call fail, if you try
> to open it write-only or read-write. Not sure which would be preferred (should
> it be possible to pass /proc/scsi/scsi to a semi-privileged process to write
> to?).
Making open fail is very much the preferred solution.
Testing for permission on write can be avoided by finding a suid root
application whose error output acts like a suid cat.
The best current practice for adding this kind of permission check is to
add the check in open. For some older use cases where we made this
mistake we had to maintian a check during write to avoid breaking
userspace. But as this check is new there is no reason to add a check
anywhere except in open.
Eric
On Thu, Nov 09, 2017 at 04:59:58PM +0000, Ben Hutchings wrote:
> On Thu, 2017-11-09 at 08:03 -0800, Guenter Roeck wrote:
> > On Thu, Nov 09, 2017 at 12:40:36PM +0000, Ben Hutchings wrote:
> > > On Thu, 2017-11-09 at 13:21 +0100, Arnd Bergmann wrote:
> > > > On Thu, Nov 9, 2017 at 1:08 PM, Greg KH <greg(a)kroah.com> wrote:
> > > > > On Thu, Nov 09, 2017 at 12:55:30PM +0100, Arnd Bergmann wrote:
> > >
> > > [...]
> > > > > > I think if you upload the branch to the stable-rc git, that should produce
> > > > > > the automated build and boot results via email or via the
> > > > > > https://kernelci.org/job/ interface. Once there are some results
> > > > > > there, I'll go through the list once more to see what warnings
> > > > > > and failures remain.
> > > > >
> > > > > I don't know of a way to have others push to that tree/branch at the
> > > > > moment :(
> > > > >
> > > > > I'll go update that branch now...
> > > >
> > > > Thanks!
> > > >
> > > > With the arm-soc tree, we simply have a shared group-id on
> > > > gitolite.kernel.org and everyone in that group can push to it.
> > > >
> > > > If that is the only thing you need, it should be trivial to let Ben
> > > > and Sasha push to /pub/scm/linux/kernel/git/stable/*.git as well,
> > > > I'm sure helpdesk(a)kernel.org can arrange that. Of course if you are
> > > > worried about having multiple accounts with write access to all the
> > > > branches, then that wouldn't be enough.
> > >
> > > I think I'd rather send a pull request to Greg at the start of the
> > > review period.
> > >
> >
> > If you change the trees I am supposed to pull from for my builders,
> > please let me know.
>
> If you're happy to keep supporting quilt-in-git then there's no change.
> I check your builders page and try to fix up build failures before even
> making a release candidate.
>
Ah yes, kernelci won't pick that up. No problem to keep kerneltests going
as long as it adds value.
Guenter
Hi Simon,
On 08.11.17 18:17, Simon Guinot wrote:
> Hi Sven and Andreas,
>
> Please, can you try with this patch ?
Today we, my son and I, repeated the failing scenario and we were able
to show that our scenario behaves stable after you patch being applied.
Thanks for taking care of this issue. If you need further testing let me
know.
Regards,
Andreas
> On Wed, Nov 08, 2017 at 05:58:35PM +0100, Simon Guinot wrote:
>> The mvneta controller provides a 8-bit register to update the pending
>> Tx descriptor counter. Then, a maximum of 255 Tx descriptors can be
>> added at once. In the current code the mvneta_txq_pend_desc_add function
>> assumes the caller takes care of this limit. But it is not the case. In
>> some situations (xmit_more flag), more than 255 descriptors are added.
>> When this happens, the Tx descriptor counter register is updated with a
>> wrong value, which breaks the whole Tx queue management.
>>
>> This patch fixes the issue by allowing the mvneta_txq_pend_desc_add
>> function to process more than 255 Tx descriptors.
>>
>> Fixes: 2a90f7e1d5d0 ("net: mvneta: add xmit_more support")
>> Cc: stable(a)vger.kernel.org # 4.11+
>> Signed-off-by: Simon Guinot <simon.guinot(a)sequanux.org>
>> ---
>> drivers/net/ethernet/marvell/mvneta.c | 16 +++++++++-------
>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
>> index 64a04975bcf8..027c08ce4e5d 100644
>> --- a/drivers/net/ethernet/marvell/mvneta.c
>> +++ b/drivers/net/ethernet/marvell/mvneta.c
>> @@ -816,11 +816,14 @@ static void mvneta_txq_pend_desc_add(struct mvneta_port *pp,
>> {
>> u32 val;
>>
>> - /* Only 255 descriptors can be added at once ; Assume caller
>> - * process TX desriptors in quanta less than 256
>> - */
>> - val = pend_desc + txq->pending;
>> - mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val);
>> + pend_desc += txq->pending;
>> +
>> + /* Only 255 Tx descriptors can be added at once */
>> + while (pend_desc > 0) {
>> + val = min(pend_desc, 255);
>> + mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val);
>> + pend_desc -= val;
>> + }
>> txq->pending = 0;
>> }
>>
>> @@ -2413,8 +2416,7 @@ static int mvneta_tx(struct sk_buff *skb, struct net_device *dev)
>> if (txq->count >= txq->tx_stop_threshold)
>> netif_tx_stop_queue(nq);
>>
>> - if (!skb->xmit_more || netif_xmit_stopped(nq) ||
>> - txq->pending + frags > MVNETA_TXQ_DEC_SENT_MASK)
>> + if (!skb->xmit_more || netif_xmit_stopped(nq))
>> mvneta_txq_pend_desc_add(pp, txq, frags);
>> else
>> txq->pending += frags;
>> --
>> 2.9.3
On Mon, 2017-10-16 at 18:11 +0200, gregkh(a)linuxfoundation.org wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
>
> commit 28585a832602747cbfa88ad8934013177a3aae38 upstream.
>
> A number of architecture invoke rcu_irq_enter() on exception entry in
> order to allow RCU read-side critical sections in the exception handler
> when the exception is from an idle or nohz_full CPU. This works, at
> least unless the exception happens in an NMI handler. In that case,
> rcu_nmi_enter() would already have exited the extended quiescent state,
> which would mean that rcu_irq_enter() would (incorrectly) cause RCU
> to think that it is again in an extended quiescent state. This will
> in turn result in lockdep splats in response to later RCU read-side
> critical sections.
>
> This commit therefore causes rcu_irq_enter() and rcu_irq_exit() to
> take no action if there is an rcu_nmi_enter() in effect, thus avoiding
> the unscheduled return to RCU quiescent state. This in turn should
> make the kernel safe for on-demand RCU voyeurism.
>
> Link: http://lkml.kernel.org/r/20170922211022.GA18084@linux.vnet.ibm.com
>
> Cc: stable(a)vger.kernel.org
> Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
> > Reported-by: Steven Rostedt <rostedt(a)goodmis.org>
> > Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
> > Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> ---
> kernel/rcu/tree.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -759,6 +759,12 @@ void rcu_irq_exit(void)
>
> local_irq_save(flags);
> rdtp = this_cpu_ptr(&rcu_dynticks);
> +
> + /* Page faults can happen in NMI handlers, so check... */
> + if (READ_ONCE(rdtp->dynticks_nmi_nesting))
> + return;
Shouldn't there be a local_irq_restore() on this return path? Or does
this condition imply that IRQs were already disabled?
> + RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_irq_exit() invoked with irqs enabled!!!");
I don't see why you added RCU_LOCKDEP_WARN() here. Prior to 4.5 it's
not an error to call this function with IRQs disabled. And after
calling local_irq_save(), it's redundant to assert that IRQs are
disabled.
> oldval = rdtp->dynticks_nesting;
> rdtp->dynticks_nesting--;
> WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> @@ -887,6 +893,12 @@ void rcu_irq_enter(void)
>
> local_irq_save(flags);
> rdtp = this_cpu_ptr(&rcu_dynticks);
> +
> + /* Page faults can happen in NMI handlers, so check... */
> + if (READ_ONCE(rdtp->dynticks_nmi_nesting))
> + return;
> +
> + RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_irq_enter() invoked with irqs enabled!!!");
Same problems here.
Ben.
> oldval = rdtp->dynticks_nesting;
> rdtp->dynticks_nesting++;
> WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
--
Ben Hutchings
Software Developer, Codethink Ltd.
This is a note to let you know that I've just added the patch titled
video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
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:
video-fbdev-pmag-ba-fb-remove-bad-__init-annotation.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 foo@baz Thu Nov 9 18:22:51 CET 2017
From: "Maciej W. Rozycki" <macro(a)linux-mips.org>
Date: Mon, 30 Jan 2017 17:39:48 +0100
Subject: video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
From: "Maciej W. Rozycki" <macro(a)linux-mips.org>
[ Upstream commit 879e5a0df626f39cbb3c61bb90373e56d67012c4 ]
Fix:
WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor()
The function pmagbafb_probe()
references the function __init pmagbafb_erase_cursor().
This is often because pmagbafb_probe lacks a __init
annotation or the annotation of pmagbafb_erase_cursor is wrong.
-- a fallout from a missed update from commit 9625b51350cc ("VIDEO:
PMAG-BA: Fix section mismatch") and then commit 48c68c4f1b54 ("Drivers:
video: remove __dev* attributes.")
Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/pmag-ba-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/video/fbdev/pmag-ba-fb.c
+++ b/drivers/video/fbdev/pmag-ba-fb.c
@@ -129,7 +129,7 @@ static struct fb_ops pmagbafb_ops = {
/*
* Turn the hardware cursor off.
*/
-static void __init pmagbafb_erase_cursor(struct fb_info *info)
+static void pmagbafb_erase_cursor(struct fb_info *info)
{
struct pmagbafb_par *par = info->par;
Patches currently in stable-queue which might be from macro(a)linux-mips.org are
queue-4.4/video-fbdev-pmag-ba-fb-remove-bad-__init-annotation.patch
This is a note to let you know that I've just added the patch titled
xen/netback: set default upper limit of tx/rx queues to 8
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:
xen-netback-set-default-upper-limit-of-tx-rx-queues-to-8.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 foo@baz Thu Nov 9 18:22:51 CET 2017
From: Juergen Gross <jgross(a)suse.com>
Date: Tue, 10 Jan 2017 14:32:52 +0100
Subject: xen/netback: set default upper limit of tx/rx queues to 8
From: Juergen Gross <jgross(a)suse.com>
[ Upstream commit 56dd5af9bc23d0d5d23bb207c477715b4c2216c5 ]
The default for the maximum number of tx/rx queues of one interface is
the number of cpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a module parameter if required.
Signed-off-by: Juergen Gross <jgross(a)suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netback/netback.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -67,6 +67,7 @@ module_param(rx_drain_timeout_msecs, uin
unsigned int rx_stall_timeout_msecs = 60000;
module_param(rx_stall_timeout_msecs, uint, 0444);
+#define MAX_QUEUES_DEFAULT 8
unsigned int xenvif_max_queues;
module_param_named(max_queues, xenvif_max_queues, uint, 0644);
MODULE_PARM_DESC(max_queues,
@@ -2157,11 +2158,12 @@ static int __init netback_init(void)
if (!xen_domain())
return -ENODEV;
- /* Allow as many queues as there are CPUs if user has not
+ /* Allow as many queues as there are CPUs but max. 8 if user has not
* specified a value.
*/
if (xenvif_max_queues == 0)
- xenvif_max_queues = num_online_cpus();
+ xenvif_max_queues = min_t(unsigned int, MAX_QUEUES_DEFAULT,
+ num_online_cpus());
if (fatal_skb_slots < XEN_NETBK_LEGACY_SLOTS_MAX) {
pr_info("fatal_skb_slots too small (%d), bump it to XEN_NETBK_LEGACY_SLOTS_MAX (%d)\n",
Patches currently in stable-queue which might be from jgross(a)suse.com are
queue-4.4/xen-netback-set-default-upper-limit-of-tx-rx-queues-to-8.patch
This is a note to let you know that I've just added the patch titled
usb: hcd: initialize hcd->flags to 0 when rm hcd
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:
usb-hcd-initialize-hcd-flags-to-0-when-rm-hcd.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 foo@baz Thu Nov 9 18:22:51 CET 2017
From: William wu <wulf(a)rock-chips.com>
Date: Fri, 13 Jan 2017 11:04:22 +0800
Subject: usb: hcd: initialize hcd->flags to 0 when rm hcd
From: William wu <wulf(a)rock-chips.com>
[ Upstream commit 76b8db0d480e8045e1a1902fc9ab143b3b9ef115 ]
On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between,
so hcd->flags can be stale.
If the HC dies due to whatever reason then without this patch we get
the below error on next hcd_add.
[173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6
[173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
[173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003
[173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[173.297222] usb usb6: Product: xHCI Host Controller
[173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd
[173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto
[173.298680] hub 6-0:1.0: USB hub found
[173.298749] hub 6-0:1.0: 1 port detected
[173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected
[173.395418] hub 5-0:1.0: activate --> -19
[173.603447] irq 228: nobody cared (try booting with the "irqpoll" option)
[173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9
[173.603513] Hardware name: Google Kevin (DT)
[173.603531] Call trace:
[173.603568] [<ffffffc0002087dc>] dump_backtrace+0x0/0x160
[173.603596] [<ffffffc00020895c>] show_stack+0x20/0x28
[173.603623] [<ffffffc0004b28a8>] dump_stack+0x90/0xb0
[173.603650] [<ffffffc00027347c>] __report_bad_irq+0x48/0xe8
[173.603674] [<ffffffc0002737cc>] note_interrupt+0x1e8/0x28c
[173.603698] [<ffffffc000270a38>] handle_irq_event_percpu+0x1d4/0x25c
[173.603722] [<ffffffc000270b0c>] handle_irq_event+0x4c/0x7c
[173.603748] [<ffffffc00027456c>] handle_fasteoi_irq+0xb4/0x124
[173.603777] [<ffffffc00026fe3c>] generic_handle_irq+0x30/0x44
[173.603804] [<ffffffc0002701a8>] __handle_domain_irq+0x90/0xbc
[173.603827] [<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188
...
[173.604500] [<ffffffc000203700>] el1_irq+0x80/0xf8
[173.604530] [<ffffffc000261388>] cpu_startup_entry+0x38/0x3cc
[173.604558] [<ffffffc00090f7d8>] rest_init+0x8c/0x94
[173.604585] [<ffffffc000e009ac>] start_kernel+0x3d0/0x3fc
[173.604607] [<0000000000b16000>] 0xb16000
[173.604622] handlers:
[173.604648] [<ffffffc000642084>] usb_hcd_irq
[173.604673] Disabling IRQ #228
Signed-off-by: William wu <wulf(a)rock-chips.com>
Acked-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/hcd.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2997,6 +2997,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
}
usb_put_invalidate_rhdev(hcd);
+ hcd->flags = 0;
}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
Patches currently in stable-queue which might be from wulf(a)rock-chips.com are
queue-4.4/usb-hcd-initialize-hcd-flags-to-0-when-rm-hcd.patch
This is a note to let you know that I've just added the patch titled
powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
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:
powerpc-corenet-explicitly-disable-the-sdhc-controller-on-kmcoge4.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 foo@baz Thu Nov 9 18:22:51 CET 2017
From: Valentin Longchamp <valentin.longchamp(a)keymile.com>
Date: Thu, 15 Dec 2016 14:22:26 +0100
Subject: powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
From: Valentin Longchamp <valentin.longchamp(a)keymile.com>
[ Upstream commit a674c7d470bb47e82f4eb1fa944eadeac2f6bbaf ]
It is not implemented on the kmcoge4 hardware and if not disabled it
leads to error messages with the corenet32_smp_defconfig.
Signed-off-by: Valentin Longchamp <valentin.longchamp(a)keymile.com>
Signed-off-by: Scott Wood <oss(a)buserror.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/boot/dts/fsl/kmcoge4.dts | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
@@ -83,6 +83,10 @@
};
};
+ sdhc@114000 {
+ status = "disabled";
+ };
+
i2c@119000 {
status = "disabled";
};
Patches currently in stable-queue which might be from valentin.longchamp(a)keymile.com are
queue-4.4/powerpc-corenet-explicitly-disable-the-sdhc-controller-on-kmcoge4.patch