* Re: [PATCH v5 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer
From: Arnd Bergmann @ 2018-01-08 16:30 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Greentime Hu, Greentime, Rick Chen, Rick Chen,
Linux Kernel Mailing List, Linus Walleij, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
linux-serial, John Stultz
In-Reply-To: <78dc7813-524d-c108-0e3d-516f8f4dabfe@linaro.org>
On Mon, Jan 8, 2018 at 5:08 PM, Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
> On 08/01/2018 16:26, Arnd Bergmann wrote:
>> On Fri, Jan 5, 2018 at 10:31 AM, Daniel Lezcano
>> <daniel.lezcano@linaro.org> wrote:
>>>
>>> etc ...
>>
>> I'd actually prefer to not do it for ARM either: Most other subsystems
>> don't do that, and I don't see a strong reason why clocksource should
>> be special here.
>
> The majority doing the opposite does not mean it is right.
>
> Do you know which clock belongs to which board ? Who will unselect a
> clock ? I'm pretty sure nobody. Everyone relies on the platform Kconfig
> and expect it to select the right drivers.
The point is that there is no platform specific Kconfig that could select
it, as the concept doesn't make a lot of sense here.
If you require the driver to always be selected by the
architecture code, it adds a little bit of bloat on systems
that don't need it. This is possible, but I think it's preferable
to give users a way of tuning a kernel for a particular chip.
> We don't expect the hackers to have a deep knowledge of the hardware and
> the driver dependencies. It is very convenient to not care about that
> and let the platform's Kconfig to select the right drivers.
>
> And that is the behavior I would like to keep.
I'm not worried about the driver bloating the kernel here when it
isn't disabled, this is no different from enabling the USB controller
by default for a board that doesn't have a USB connector, or
enabling ten different pinctrl drivers for all members of a chip
family even though you know which particular chip you are
running on.
>> Selecting 'TIMER_OF' from the individual drivers that need it (as you
>> suggest) makes sense, but I think for ARM we treat SoC families
>> as a bit too special, in the end they are for the most part collections
>> of individual hardware blocks that may or may not be present on
>> some chip.
>>
>> In case of risc-v and nds32, I expect that the separation will be
>> even less visibile in the hardware, as a typical model here is
>> that one company designs SoCs for multiple customers that each
>> have different requirements. Some of them may have one
>> timer and some have another timer or multiple timers, but there
>> is no strict separation between SoC families as I understand.
>> Here we'd be better off not having a per-SoC Kconfig option at
>> all, just a generic defconfig that enables all the drivers that might
>> be used, and integrators can have a defconfig file that only
>> enables the stuff they actually use on a given chip.
>
> Yes, the result is the same, the option is not showed in the menu.
>
> However, I can understand it could be interesting to have the ability to
> unselect a driver for experts.
>
> I'm wondering if we can create a bool_expert which shows up only when
> CONFIG_EXPERT is set.
Having a dependency on CONFIG_EXPERT means that a more
users will end up having to set that for a shipping system. It's
something we can do (even without a special Kconfig keyword),
but it should be used carefully for stuff that 99% of the users want
to enable.
Why not just:
config CLKSRC_ATCPIT100
bool "Clocksource for AE3XX platform"
depends on NDS32 || COMPILE_TEST
depends on HAS_IOMEM
default NDS32
help
This option enables support for the Andestech AE3XX platform timers.
That way, it's simply enabled on NDS32 by default, but just as easy
to disable for systems that don't need it.
Arnd
^ permalink raw reply
* Re: [PATCH 02/18] Documentation: document nospec helpers
From: Jonathan Corbet @ 2018-01-08 16:29 UTC (permalink / raw)
To: Dan Williams
Cc: linux-kernel, Mark Rutland, linux-arch, peterz, netdev,
Will Deacon, gregkh, tglx, torvalds, alan
In-Reply-To: <151520100323.32271.8384226462583945132.stgit@dwillia2-desk3.amr.corp.intel.com>
On Fri, 05 Jan 2018 17:10:03 -0800
Dan Williams <dan.j.williams@intel.com> wrote:
> Document the rationale and usage of the new nospec*() helpers.
I have just a couple of overall comments.
- It would be nice if the document were done in RST and placed in the
core-API manual, perhaps using kerneldoc comments for the macros
themselves. It's already 99.9% RST now, so the changes required would
be minimal.
- More importantly: is there any way at all to give guidance to
developers wondering *when* they should use these primitives? I think
it would be easy to create a situation where they don't get used where
they are really needed; meanwhile, there may well be a flood of
"helpful" patches adding them where they make no sense at all.
Thanks,
jon
^ permalink raw reply
* Aw: Re: dvb usb issues since kernel 4.9
From: Josef Griebichler @ 2018-01-08 16:26 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Alan Stern, Greg Kroah-Hartman, linux-usb, Eric Dumazet,
Rik van Riel, Paolo Abeni, Hannes Frederic Sowa,
Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet,
LMML, Peter Zijlstra, David Miller, torvalds
In-Reply-To: <20180108074324.3c153189@vento.lan>
Hi Maro,
I tried your mentioned patch but unfortunately no real improvement for me.
dmesg http://ix.io/DOg
tvheadend service log http://ix.io/DOi
Errors during recording are still there.
Errors increase if there is additional tcp load on raspberry.
Unfortunately there's no usbmon or tshark on libreelec so I can't provide further logs.
Regards,
Josef
> On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote:
>
> > > > It seems that the original patch were designed to solve some IRQ issues
> > > > with network cards with causes data losses on high traffic. However,
> > > > it is also causing bad effects on sustained high bandwidth demands
> > > > required by DVB cards, at least on some USB host drivers.
> > > >
> > > > Alan/Greg/Eric/David:
> > > >
> > > > Any ideas about how to fix it without causing regressions to
> > > > network?
> > >
> > > It would be good to know what hardware was involved on the x86 system
> > > and to have some timing data. Can we see the output from lsusb and
> > > usbmon, running on a vanilla kernel that gets plenty of video glitches?
> >
> > From Josef's report, and from the BZ, the affected hardware seems
> > to be based on Montage Technology M88DS3103/M88TS2022 chipset.
>
> What type of USB host controller does the x86_64 system use? EHCI or
> xHCI?
I'll let Josef answer this.
>
> > The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c,
> > with shares a USB implementation that is used by a lot more drivers.
> > The URB handling code is at:
> >
> > drivers/media/usb/dvb-usb-v2/usb_urb.c
> >
> > This particular driver allocates 8 buffers with 4096 bytes each
> > for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP.
> >
> > This become a popular USB hardware nowadays. I have one S960c
> > myself, so I can send you the lsusb from it. You should notice, however,
> > that a DVB-C/DVB-S2 channel can easily provide very high sustained bit
> > rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps
> > of payload after removing URB headers.
>
> You mentioned earlier that the driver uses bulk transfers. In USB-2.0,
> the maximum possible payload data transfer rate using bulk transfers is
> 53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s). And
> even this is possible only if almost nothing else is using the bus at
> the same time.
No, I said 58 Mbits/s (not bytes).
On DVB-C and DVB-S2 specs, AFAIKT, there's no hard limit for the maximum
payload data rate, although industry seems to limit it to be around
60 Mbits/s. On those standards, the maximal bit rate is defined by the
modulation type and by the channel symbol rate.
To give you a practical example, my DVB-S2 provider modulates each
transponder with 8/PSK (3 bits/symbol), and define channels with a
symbol rate of 30 Mbauds/s. So, it could, theoretically, transport
a MPEG-TS stream up to 90 Mbits/s (minus headers and guard intervals).
In practice, the streams there are transmitted with 58,026.5 Kbits/s.
> > A 10 minutes record with the
> > entire data (with typically contains 5-10 channels) can easily go
> > above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if
> > a usbmon dump would be useful.
>
> It might not be helpful at all. However, I'm not interested in the
> payload data (which would be unintelligible to me anyway) but rather
> the timing of URB submissions and completions. A usbmon trace which
> didn't keep much of the payload data would only require on the order of
> 50 MB per minute -- and Josef said that glitches usually would show up
> within a minute or so.
Yeah, this could help.
Josef,
You can get it with wireshark/tshark or tcpdump. See:
https://technolinchpin.wordpress.com/2015/10/23/usb-bus-sniffers-for-linux-system/
https://wiki.wireshark.org/CaptureSetup/USB
> > I'm enclosing the lsusb from a S960C device, with is based on those
> > Montage chipsets:
>
> What I wanted to see was the output from "lsusb" on the affected
> system, not the output from "lsusb -v -s B:D" on your system.
>
> > > Overall, this may be a very difficult problem to solve. The
> > > 4cd13c21b207 commit was intended to improve throughput at the cost of
> > > increased latency. But then what do you do when the latency becomes
> > > too high for the video subsystem to handle?
> >
> > Latency can't be too high, otherwise frames will be dropped.
>
> Yes, that's the whole point.
>
> > Even if the Kernel itself doesn't drop, if the delay goes higher
> > than a certain threshold, userspace will need to drop, as it
> > should be presenting audio and video on real time. Yet, typically,
> > userspace will delay it by one or two seconds, with would mean
> > 1500-3500 buffers, with I suspect it is a lot more than the hardware
> > limits. So I suspect that the hardware starves free buffers a way
> > before userspace, as media hardware don't have unlimited buffers
> > inside them, as they assume that the Kernel/userspace will be fast
> > enough to sustain bit rates up to 66 Mbps of payload.
>
> The timing information would tell us how large the latency is.
>
> In any case, you might be able to attack the problem simply by using
> more than 8 buffers. With just eight 4096-byte buffers, the total
> pipeline capacity is only about 0.62 ms (at the maximum possible
> transfer rate). Increasing the number of buffers to 65 would give a
> capacity of 5 ms, which is probably a lot better suited for situations
> where completions are handled by the ksoftirqd thread.
Increasing it to 65 shouldn't be hard. Not sure, however, if the hardware
will actually fill the 65 buffers, but it is worth to try.
> > Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP,
> > in order to revert the kernel logic to prioritize latency instead of
> > throughput.
>
> It can't be done without pervasive changes to the USB subsystem, which
> I would greatly prefer to avoid. Besides, this wouldn't really solve
> the problem. Decreasing the latency for one device will cause it to be
> increased for others.
If there is a TV streaming traffic at a USB bus, it means that the
user wants to either watch and/or record a TV program. On such
usecase scenario, a low latency is highly desired for the TV capture
(and display, if the GPU is USB), even it means a higher latency for
other traffic.
Josef,
Could you please try the following patch on Kernel 4.14.10 (without
reverting any changesets), and see if it fixes the issue?
media: dvbsky: Increase the number of buffers
Right now, This driver expects a 0.62 ms delay with 8 buffers on an USB 2.0
high speed bus. Increase it to 65 buffers, in order to give more time for
the top half of the USB transfer handler to complete its task.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 131b6c08e199..d3f5ffc54b25 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -740,7 +740,7 @@ static struct dvb_usb_device_properties dvbsky_s960_props = {
.num_adapters = 1,
.adapter = {
{
- .stream = DVB_USB_STREAM_BULK(0x82, 8, 4096),
+ .stream = DVB_USB_STREAM_BULK(0x82, 65, 4096),
}
}
};
>
Thanks,
Mauro
^ permalink raw reply related
* [PATCH net-next] ibmvnic: Don't handle RX interrupts when not up.
From: Nathan Fontenot @ 2018-01-08 16:09 UTC (permalink / raw)
To: netdev; +Cc: jallen, tlfalcon
Initiating a kdump via the command line can cause a pending interrupt
to be handled by the ibmvnic driver when initializing the sub-CRQ
irqs during driver initialization.
NIP [d000000000ca34f0] ibmvnic_interrupt_rx+0x40/0xd0 [ibmvnic]
LR [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0
Call Trace:
[c000000047fcfde0] [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0
[c000000047fcfea0] [c00000000813317c] handle_irq_event_percpu+0x3c/0x90
[c000000047fcfee0] [c00000000813323c] handle_irq_event+0x6c/0xd0
[c000000047fcff10] [c0000000081385e0] handle_fasteoi_irq+0xf0/0x250
[c000000047fcff40] [c0000000081320a0] generic_handle_irq+0x50/0x80
[c000000047fcff60] [c000000008014984] __do_irq+0x84/0x1d0
[c000000047fcff90] [c000000008027564] call_do_irq+0x14/0x24
[c00000003c92af00] [c000000008014b70] do_IRQ+0xa0/0x120
[c00000003c92af50] [c000000008002594] hardware_interrupt_common+0x114/0x180
--- interrupt: 501 at arch_local_irq_restore+0x74/0x90
LR = arch_local_irq_restore+0x74/0x90
[c00000003c92b240] [c000000008138a20] irq_startup+0xa0/0xe0 (unreliable)
[c00000003c92b260] [c0000000087fc440] _raw_spin_unlock_irqrestore+0x40/0x70
[c00000003c92b280] [c0000000081361f4] __setup_irq+0x584/0x7a0
[c00000003c92b420] [c0000000081366a0] request_threaded_irq+0x140/0x290
[c00000003c92b480] [d000000000ca3754] init_sub_crq_irqs+0x1d4/0x370 [ibmvnic]
[c00000003c92b520] [d000000000ca6b50] ibmvnic_init+0x140/0x760 [ibmvnic]
[c00000003c92b5c0] [d000000000ca7308] ibmvnic_probe+0x198/0x330 [ibmvnic]
[c00000003c92b650] [c000000008037270] vio_bus_probe+0x1c0/0x480
[c00000003c92b6f0] [c00000000859a140] driver_probe_device+0x1f0/0x540
[c00000003c92b780] [c00000000859a59c] __driver_attach+0x10c/0x110
[c00000003c92b7c0] [c000000008596dac] bus_for_each_dev+0x8c/0xf0
[c00000003c92b810] [c000000008599798] driver_attach+0x38/0x50
[c00000003c92b830] [c000000008598f68] bus_add_driver+0x2b8/0x380
[c00000003c92b8c0] [c00000000859b660] driver_register+0xa0/0x180
[c00000003c92b930] [c000000008035c5c] __vio_register_driver+0x7c/0xc0
[c00000003c92b9b0] [d000000000caaf3c] ibmvnic_module_init+0x5c/0x70 [ibmvnic]
[c00000003c92ba10] [c00000000800b6cc] do_one_initcall+0x12c/0x280
[c00000003c92bae0] [c000000008805614] do_init_module+0x98/0x24c
[c00000003c92bb70] [c000000008181a80] load_module+0x1470/0x16c0
[c00000003c92bd40] [c000000008181fb0] SyS_finit_module+0xd0/0x120
[c00000003c92be30] [c000000008009204] system_call+0x38/0xb4
At this poibnt the driver is not prepared to handle traffic and
should not try to handle the interrupt. This patch adds a check to
ensure the driver is up when handling RX interrupots.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 6911b7cc06c5..46990b84cb2d 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2453,6 +2453,9 @@ static irqreturn_t ibmvnic_interrupt_rx(int irq, void *instance)
struct ibmvnic_sub_crq_queue *scrq = instance;
struct ibmvnic_adapter *adapter = scrq->adapter;
+ if (adapter->state != VNIC_OPEN)
+ return IRQ_NONE;
+
adapter->rx_stats_buffers[scrq->scrq_num].interrupts++;
if (napi_schedule_prep(&adapter->napi[scrq->scrq_num])) {
^ permalink raw reply related
* Re: dvb usb issues since kernel 4.9
From: Alan Stern @ 2018-01-08 16:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jesper Dangaard Brouer, Linus Torvalds, Ingo Molnar,
Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet,
Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel,
netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller
In-Reply-To: <20180108105331.758fc2f4@vento.lan>
On Mon, 8 Jan 2018, Mauro Carvalho Chehab wrote:
> > Let find the root-cause of this before reverting, as this will hurt the
> > networking use-case.
> >
> > I want to see if the increase buffer will solve the issue (the current
> > buffer of 0.63 ms seem too small).
>
> For TV, high latency has mainly two practical consequences:
>
> 1) it increases the time to switch channels. MPEG-TS based transmissions
> usually takes some time to start showing the channel contents. Adding
> more buffers make it worse;
>
> 2) specially when watching sports, a higher latency means that you'll know
> that your favorite team made a score when your neighbors start
> celebrating... seeing the actual event only after them.
>
> So, the lower, the merrier, but I think that 5 ms would be acceptable.
That value 65 for the number of buffers was calculated based on a
misunderstanding of the actual bandwidth requirement. Still increasing
the number of buffers shouldn't hurt, and it's worth trying.
But there is another misunderstanding here which needs to be cleared
up. Adding more buffers does _not_ increase latency; it increases
capacity. Making each buffer larger _would_ increase latency, but
that's not what I proposed.
Going through this more explicitly... Suppose you receive 8 KB of data
every ms, and suppose you have four 8-KB buffers. Then the latency is
1 ms, because that's how long you have to wait for the first buffer to
be filled up after you submit an I/O request. (The driver does _not_
need to wait for all four buffers to be filled before it can start
displaying the data in the first buffer.) The capacity would be 4 ms,
because that's how much data your buffers can store. If you end up
waiting longer than 4 ms before ksoftirqd gets around to processing any
of the data, then some data will inevitably get lost.
That's why the way to deal with the delays caused by deferring softirqs
to ksoftirqd is to add more buffers (and not make the buffers larger
than they already are).
> > I would also like to see experiments with adjusting adjust the sched
> > priority of the kthread's and/or the userspace prog. (e.g use command
> > like 'sudo chrt --fifo -p 10 $(pgrep udp_sink)' ).
>
> If this fixes the issue, we'll need to do something inside the Kernel
> to change the priority, as TV userspace apps should not run as root. Not
> sure where such change should be done (USB? media?).
It would be interesting to try this, but I agree that it's not likely
to be a practical solution. Anyway, shouldn't ksoftirqd already be
running with very high priority?
> > Are we really sure that the regression is cause by 4cd13c21b207
> > ("softirq: Let ksoftirqd do its job"), the forum thread also report
> > that the problem is almost gone after commit 34f41c0316ed ("timers: Fix
> > overflow in get_next_timer_interrupt")
> > https://git.kernel.org/torvalds/c/34f41c0316ed
That is a good point. It's hard to see how the issues in the two
commits could be related, but who knows?
> I'll see if I can mount a test scenario here in order to try reproduce
> the reported bug. I suspect that I won't be able to reproduce it on my
> "standard" i7core-based test machine, even with KPTI enabled.
If you're using the same sort of hardware as Josef, under similar
circumstances, the buggy bahavior should be the same. If not, there
must be something else going on that we're not aware of.
> > It makes me suspicious that this fix changes things...
> > After this fix, I suspect that changing the sched priorities, will fix
> > the remaining glitches.
> >
> >
> > > It is hard to foresee the consequences of the softirq changes for other
> > > devices, though.
> >
> > Yes, it is hard to foresee, I can only cover networking.
> >
> > For networking, if reverting this, we will (again) open the kernel for
> > an easy DDoS vector with UDP packets. As mentioned in the commit desc,
> > before you could easily cause softirq to take all the CPU time from the
> > application, resulting in very low "good-put" in the UDP-app. (That's why
> > it was so easy to DDoS DNS servers before...)
> >
> > With the softirqd patch in place, ksoftirqd is scheduled fairly between
> > other applications running on the same CPU. But in some cases this is
> > not what you want, so as the also commit mentions, the admin can now
> > more easily tune process scheduling parameters if needed, to adjust for
> > such use-cases (it was not really an admin choice before).
>
> Can't the ksoftirq patch be modified to only apply to the networking
> IRQ handling? That sounds less risky of affecting unrelated subsystems[1].
That might work. Or more generally, allow drivers to specify which
softirq sources should be deferred to ksoftirqd and which should not.
Alan Stern
> [1] Actually, DVB drivers can also implement networking for satellite
> based Internet, but, in this case, the top half is implemented inside
> the DVB core, as the IP traffic should be filtered out of an MPEG-TS
> stream. Not sure if the UDP DDoS attack you're mentioning would affect
> DVB net, but I guess not. AFAIKT, there aren't many users using DVB net
> nowadays. I don't have any easy way to test DVB net here.
>
> Thanks,
> Mauro
^ permalink raw reply
* [PATCH net] 9p: add missing module license for xen transport
From: Stephen Hemminger @ 2018-01-08 16:23 UTC (permalink / raw)
To: ericvh, rminnich, lucho, davem
Cc: v9fs-developer, netdev, Stephen Hemminger, Stephen Hemminger
The 9P of Xen module is missing required license and module information.
See https://bugzilla.kernel.org/show_bug.cgi?id=198109
Reported-by: Alan Bartlett <ajb@elrepo.org>
Fixes: 868eb122739a ("xen/9pfs: introduce Xen 9pfs transport driver")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
net/9p/trans_xen.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 325c56043007..086a4abdfa7c 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -543,3 +543,7 @@ static void p9_trans_xen_exit(void)
return xenbus_unregister_driver(&xen_9pfs_front_driver);
}
module_exit(p9_trans_xen_exit);
+
+MODULE_AUTHOR("Stefano Stabellini <stefano@aporeto.com>");
+MODULE_DESCRIPTION("Xen Transport for 9P");
+MODULE_LICENSE("GPL");
--
2.15.1
^ permalink raw reply related
* Re: b43: Replace mdelay with msleep in b43_radio_2057_init_post
From: Kalle Valo @ 2018-01-08 16:21 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: colin.king, johannes.berg, tiwai, kstewart, gregkh,
andrew.zaborowski, linux-wireless, b43-dev, netdev, linux-kernel,
Jia-Ju Bai
In-Reply-To: <1514632107-14698-1-git-send-email-baijiaju1990@gmail.com>
Jia-Ju Bai <baijiaju1990@gmail.com> wrote:
> b43_radio_2057_init_post is not called in an interrupt handler
> nor holding a spinlock.
> The function mdelay in it can be replaced with msleep, to reduce busy wait.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
You submitted an identical patch a week earlier:
https://patchwork.kernel.org/patch/10137671/
How is this different? Also always add version number to the patch so that the
maintainers can follow the changes easily:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#patch_version_missing
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing
--
https://patchwork.kernel.org/patch/10137671/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: b43: Replace mdelay with msleep in b43_radio_2057_init_post
From: Kalle Valo @ 2018-01-08 16:21 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: kstewart-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
johannes.berg-ral2JQCrhuEAvxtiuMwx3w, tiwai-l3A5Bk7waGM,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andrew.zaborowski-ral2JQCrhuEAvxtiuMwx3w, Jia-Ju Bai,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, colin.king-Z7WLFzj8eWMS+FvcfC7Uqw
In-Reply-To: <1514632107-14698-1-git-send-email-baijiaju1990-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Jia-Ju Bai <baijiaju1990-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> b43_radio_2057_init_post is not called in an interrupt handler
> nor holding a spinlock.
> The function mdelay in it can be replaced with msleep, to reduce busy wait.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
You submitted an identical patch a week earlier:
https://patchwork.kernel.org/patch/10137671/
How is this different? Also always add version number to the patch so that the
maintainers can follow the changes easily:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#patch_version_missing
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing
--
https://patchwork.kernel.org/patch/10137671/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
From: Bart Van Assche @ 2018-01-08 16:20 UTC (permalink / raw)
To: Dan Williams, Eric W. Biederman
Cc: Linux Kernel Mailing List, Mark Rutland, Peter Zijlstra, Alan Cox,
Srinivas Pandruvada, Will Deacon, Solomon Peachy, H. Peter Anvin,
Christian Lamparter, Elena Reshetova, linux-arch, Andi Kleen,
James E.J. Bottomley, linux-scsi, Jonathan Corbet, X86 ML,
Ingo Molnar, Alexey Kuznetsov, Zhang Rui,
"Linux-media@vger.ker
In-Reply-To: <CAPcyv4hVisGeXbTH985Hb6dkYKA9Sr8wwZHudNF-CtH0=ADFug@mail.gmail.com>
On 01/05/18 22:30, Dan Williams wrote:
> On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> Please expand this.
>>
>> It is not clear what the static analysis is looking for. Have a clear
>> description of what is being fixed is crucial for allowing any of these
>> changes.
>>
>> For the details given in the change description what I read is magic
>> changes because a magic process says this code is vulnerable.
>
> Yes, that was my first reaction to the patches as well, I try below to
> add some more background and guidance, but in the end these are static
> analysis reports across a wide swath of sub-systems. It's going to
> take some iteration with domain experts to improve the patch
> descriptions, and that's the point of this series, to get the better
> trained eyes from the actual sub-system owners to take a look at these
> reports.
More information about what the static analysis is looking for would
definitely be welcome.
Additionally, since the analysis tool is not publicly available, how are
authors of new kernel code assumed to verify whether or not their code
needs to use nospec_array_ptr()? How are reviewers of kernel code
assumed to verify whether or not nospec_array_ptr() is missing where it
should be used?
Since this patch series only modifies the upstream kernel, how will
out-of-tree drivers be fixed, e.g. the nVidia driver and the Android
drivers?
Thanks,
Bart.
^ permalink raw reply
* Re: dvb usb issues since kernel 4.9
From: Alan Stern @ 2018-01-08 16:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Josef Griebichler, Greg Kroah-Hartman, linux-usb, Eric Dumazet,
Rik van Riel, Paolo Abeni, Hannes Frederic Sowa,
Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet,
LMML, Peter Zijlstra, David Miller, torvalds
In-Reply-To: <20180108074324.3c153189@vento.lan>
On Mon, 8 Jan 2018, Mauro Carvalho Chehab wrote:
> Em Sun, 7 Jan 2018 10:41:37 -0500 (EST)
> Alan Stern <stern@rowland.harvard.edu> escreveu:
>
> > On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote:
> >
> > > > > It seems that the original patch were designed to solve some IRQ issues
> > > > > with network cards with causes data losses on high traffic. However,
> > > > > it is also causing bad effects on sustained high bandwidth demands
> > > > > required by DVB cards, at least on some USB host drivers.
> > > > >
> > > > > Alan/Greg/Eric/David:
> > > > >
> > > > > Any ideas about how to fix it without causing regressions to
> > > > > network?
> > > >
> > > > It would be good to know what hardware was involved on the x86 system
> > > > and to have some timing data. Can we see the output from lsusb and
> > > > usbmon, running on a vanilla kernel that gets plenty of video glitches?
> > >
> > > From Josef's report, and from the BZ, the affected hardware seems
> > > to be based on Montage Technology M88DS3103/M88TS2022 chipset.
> >
> > What type of USB host controller does the x86_64 system use? EHCI or
> > xHCI?
>
> I'll let Josef answer this.
>
> >
> > > The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c,
> > > with shares a USB implementation that is used by a lot more drivers.
> > > The URB handling code is at:
> > >
> > > drivers/media/usb/dvb-usb-v2/usb_urb.c
> > >
> > > This particular driver allocates 8 buffers with 4096 bytes each
> > > for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP.
> > >
> > > This become a popular USB hardware nowadays. I have one S960c
> > > myself, so I can send you the lsusb from it. You should notice, however,
> > > that a DVB-C/DVB-S2 channel can easily provide very high sustained bit
> > > rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps
> > > of payload after removing URB headers.
> >
> > You mentioned earlier that the driver uses bulk transfers. In USB-2.0,
> > the maximum possible payload data transfer rate using bulk transfers is
> > 53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s). And
> > even this is possible only if almost nothing else is using the bus at
> > the same time.
>
> No, I said 58 Mbits/s (not bytes).
Well, what you actually _wrote_ was "58 Mpps of payload" (see above),
and I couldn't tell how to interpret that. :-)
58 Mb/s is obviously almost 8 times less than the full USB bus
bandwidth.
> On DVB-C and DVB-S2 specs, AFAIKT, there's no hard limit for the maximum
> payload data rate, although industry seems to limit it to be around
> 60 Mbits/s. On those standards, the maximal bit rate is defined by the
> modulation type and by the channel symbol rate.
>
> To give you a practical example, my DVB-S2 provider modulates each
> transponder with 8/PSK (3 bits/symbol), and define channels with a
> symbol rate of 30 Mbauds/s. So, it could, theoretically, transport
> a MPEG-TS stream up to 90 Mbits/s (minus headers and guard intervals).
> In practice, the streams there are transmitted with 58,026.5 Kbits/s.
Okay. This is 58 Kb/ms or 7.25 KB/ms. So your scheme of eight 4-KB
buffers gives a latency of 0.57 ms with a total capacity of 4.5 ms,
which is a lot better than what I was thinking.
> > In any case, you might be able to attack the problem simply by using
> > more than 8 buffers. With just eight 4096-byte buffers, the total
> > pipeline capacity is only about 0.62 ms (at the maximum possible
> > transfer rate). Increasing the number of buffers to 65 would give a
> > capacity of 5 ms, which is probably a lot better suited for situations
> > where completions are handled by the ksoftirqd thread.
>
> Increasing it to 65 shouldn't be hard. Not sure, however, if the hardware
> will actually fill the 65 buffers, but it is worth to try.
Given the new information, 65 would be overkill. But going from 8 to
16 might help.
> > > Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP,
> > > in order to revert the kernel logic to prioritize latency instead of
> > > throughput.
> >
> > It can't be done without pervasive changes to the USB subsystem, which
> > I would greatly prefer to avoid. Besides, this wouldn't really solve
> > the problem. Decreasing the latency for one device will cause it to be
> > increased for others.
>
> If there is a TV streaming traffic at a USB bus, it means that the
> user wants to either watch and/or record a TV program. On such
> usecase scenario, a low latency is highly desired for the TV capture
> (and display, if the GPU is USB), even it means a higher latency for
> other traffic.
Not if the other traffic is also a TV capture. :-)
It might make sense to classify softirq sources as "high priority" or
"low priority", and only defer the "low priority" work to ksoftirqd.
Alan Stern
^ permalink raw reply
* Re: [PATCH v5 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer
From: Daniel Lezcano @ 2018-01-08 16:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime Hu, Greentime, Rick Chen, Rick Chen,
Linux Kernel Mailing List, Linus Walleij, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
linux-serial, John Stultz
In-Reply-To: <CAK8P3a2NVj_M5eHT92fJYNBG3x9juVnHW6uV32p3-ytfqjARxg@mail.gmail.com>
On 08/01/2018 16:26, Arnd Bergmann wrote:
> On Fri, Jan 5, 2018 at 10:31 AM, Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>>>> No. Can't you add in arch/ndis32/Kconfig ?
>>>>
>>>> +select TIMER_ATCPIT100
>>>>
>>>> Like:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Kconfig#n50
>>>
>>> IMHO, it might be a little bit wierd if we select TIMER_ATCPIT100 in
>>> arch/nds32/Kconfig because it is part of SoC instead of CPU.
>>> If we change to another SoC with another timer, we need to select
>>> another TIMER in arch/nds32/Kconfig and delete TIMER_ATCPIT100.
>>> It seems more flexible to be selected in driver layer.
>>>
>>> It seems to be the timer is part of the arch to be selected in arch's Kconfig.
>>> arch/arc/Kconfig: select ARC_TIMERS
>>> arch/arc/Kconfig: select ARC_TIMERS_64BIT
>>> arch/arm/Kconfig: select ARM_ARCH_TIMER
>>> arch/arm64/Kconfig: select ARM_ARCH_TIMER
>>> arch/blackfin/Kconfig: select BFIN_GPTIMERS
>>
>> No, the timer must be selected from the arch/soc's or whatever Kconfig.
>> Not in the clocksource's Kconfig.
>>
>> eg.
>>
>> on ARM:
>>
>> arch/arm/mach-vt8500/Kconfig: select VT8500_TIMER
>> arch/arm/mach-bcm/Kconfig: select BCM_KONA_TIMER
>> arch/arm/mach-actions/Kconfig: select OWL_TIMER
>> arch/arm/mach-digicolor/Kconfig: select DIGICOLOR_TIMER
>>
>> etc ...
>>
>> on ARM64:
>>
>> arch/arm64/Kconfig.platforms: select OWL_TIMER
>> arch/arm64/Kconfig.platforms: select ARM_TIMER_SP804
>> arch/arm64/Kconfig.platforms: select MTK_TIMER
>>
>> etc ...
>
> I'd actually prefer to not do it for ARM either: Most other subsystems
> don't do that, and I don't see a strong reason why clocksource should
> be special here.
The majority doing the opposite does not mean it is right.
Do you know which clock belongs to which board ? Who will unselect a
clock ? I'm pretty sure nobody. Everyone relies on the platform Kconfig
and expect it to select the right drivers.
We don't expect the hackers to have a deep knowledge of the hardware and
the driver dependencies. It is very convenient to not care about that
and let the platform's Kconfig to select the right drivers.
And that is the behavior I would like to keep.
> Selecting 'TIMER_OF' from the individual drivers that need it (as you
> suggest) makes sense, but I think for ARM we treat SoC families
> as a bit too special, in the end they are for the most part collections
> of individual hardware blocks that may or may not be present on
> some chip.
>
> In case of risc-v and nds32, I expect that the separation will be
> even less visibile in the hardware, as a typical model here is
> that one company designs SoCs for multiple customers that each
> have different requirements. Some of them may have one
> timer and some have another timer or multiple timers, but there
> is no strict separation between SoC families as I understand.
> Here we'd be better off not having a per-SoC Kconfig option at
> all, just a generic defconfig that enables all the drivers that might
> be used, and integrators can have a defconfig file that only
> enables the stuff they actually use on a given chip.
Yes, the result is the same, the option is not showed in the menu.
However, I can understand it could be interesting to have the ability to
unselect a driver for experts.
I'm wondering if we can create a bool_expert which shows up only when
CONFIG_EXPERT is set.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH 2/2] Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find."
From: Nicolas Dichtel @ 2018-01-08 16:06 UTC (permalink / raw)
To: David Miller; +Cc: steffen.klassert, herbert, robsonde, netdev
In-Reply-To: <20180105.121713.1854987792723191976.davem@davemloft.net>
Le 05/01/2018 à 18:17, David Miller a écrit :
[snip]
> I will in my next batch of stable submissions.
>
Thank you!
^ permalink raw reply
* [PATCH bpf-next] bpf: fix verifier GPF in kmalloc failure path
From: Alexei Starovoitov @ 2018-01-08 15:51 UTC (permalink / raw)
To: davem; +Cc: daniel, netdev, kernel-team
From: Alexei Starovoitov <ast@fb.com>
syzbot reported the following panic in the verifier triggered
by kmalloc error injection:
kasan: GPF could be caused by NULL-ptr deref or user memory access
RIP: 0010:copy_func_state kernel/bpf/verifier.c:403 [inline]
RIP: 0010:copy_verifier_state+0x364/0x590 kernel/bpf/verifier.c:431
Call Trace:
pop_stack+0x8c/0x270 kernel/bpf/verifier.c:449
push_stack kernel/bpf/verifier.c:491 [inline]
check_cond_jmp_op kernel/bpf/verifier.c:3598 [inline]
do_check+0x4b60/0xa050 kernel/bpf/verifier.c:4731
bpf_check+0x3296/0x58c0 kernel/bpf/verifier.c:5489
bpf_prog_load+0xa2a/0x1b00 kernel/bpf/syscall.c:1198
SYSC_bpf kernel/bpf/syscall.c:1807 [inline]
SyS_bpf+0x1044/0x4420 kernel/bpf/syscall.c:1769
when copy_verifier_state() aborts in the middle due to kmalloc failure
some of the frames could have been partially copied while
current free_verifier_state() loop
for (i = 0; i <= state->curframe; i++)
assumed that all frames are non-null.
Simply fix it by adding 'if (!state)' to free_func_state().
Also avoid stressing copy frame logic more if kzalloc fails
in push_stack() free env->cur_state right away.
Reported-by: syzbot+32ac5a3e473f2e01cfc7@syzkaller.appspotmail.com
Reported-by: syzbot+fa99e24f3c29d269a7d5@syzkaller.appspotmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/verifier.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index a2b211262c25..d921ab387b0b 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -375,6 +375,8 @@ static int realloc_func_state(struct bpf_func_state *state, int size,
static void free_func_state(struct bpf_func_state *state)
{
+ if (!state)
+ return;
kfree(state->stack);
kfree(state);
}
@@ -487,6 +489,8 @@ static struct bpf_verifier_state *push_stack(struct bpf_verifier_env *env,
}
return &elem->st;
err:
+ free_verifier_state(env->cur_state, true);
+ env->cur_state = NULL;
/* pop all elements and return */
while (!pop_stack(env, NULL, NULL));
return NULL;
--
2.9.5
^ permalink raw reply related
* Re: general protection fault in free_verifier_state (2)
From: Alexei Starovoitov @ 2018-01-08 15:48 UTC (permalink / raw)
To: syzbot
Cc: Alexei Starovoitov, Daniel Borkmann, LKML, Network Development,
syzkaller-bugs
In-Reply-To: <001a1141a5240137fb056241ac63@google.com>
On Mon, Jan 8, 2018 at 2:58 AM, syzbot
<syzbot+fa99e24f3c29d269a7d5@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzkaller hit the following crash on
> 895c0dde398510a5b5ded60e5064c11b94bd30ca
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+fa99e24f3c29d269a7d5@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> RBP: 0000000000000006 R08: 0000000000000002 R09: 00007ffd20003032
> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
> R13: ffffffffffffffff R14: 656c6c616b7a7973 R15: 0000000000000004
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 3468 Comm: syzkaller619543 Not tainted 4.15.0-rc6-next-20180108+
> #90
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:free_func_state kernel/bpf/verifier.c:378 [inline]
> RIP: 0010:free_verifier_state+0x6d/0x130 kernel/bpf/verifier.c:388
> RSP: 0018:ffff8801d48f77b8 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff1003b6384a0
> RDX: 0000000000000000 RSI: 0000000000000071 RDI: 0000000000000388
> RBP: ffff8801d48f7800 R08: ffff8801db427d00 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801db1c2500
> R13: dffffc0000000000 R14: ffff8801db1c2500 R15: ffff8801db1c2500
> FS: 000000000254e880(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020386000 CR3: 00000001cb32e002 CR4: 00000000001606f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> is_state_visited kernel/bpf/verifier.c:4414 [inline]
> do_check+0x2442/0x9760 kernel/bpf/verifier.c:4488
> bpf_check+0x3087/0x5580 kernel/bpf/verifier.c:5483
> bpf_prog_load+0xbb2/0x1260 kernel/bpf/syscall.c:1205
> SYSC_bpf kernel/bpf/syscall.c:1820 [inline]
> SyS_bpf+0x861/0x32e0 kernel/bpf/syscall.c:1782
> entry_SYSCALL_64_fastpath+0x23/0x9a
hmm. my patch with the fix got lost somehow.
Will resend.
^ permalink raw reply
* Re: [PATCHv3 0/2] capability controlled user-namespaces
From: Serge E. Hallyn @ 2018-01-08 15:47 UTC (permalink / raw)
To: James Morris
Cc: Serge E. Hallyn,
Mahesh Bandewar (महेश बंडेवार),
LKML, Netdev, Kernel-hardening, Linux API, Kees Cook,
Eric W . Biederman, Eric Dumazet, David Miller, Mahesh Bandewar
In-Reply-To: <alpine.LFD.2.20.1801082040180.12014@localhost>
Quoting James Morris (james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org):
> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
>
> > > Also, why do we need the concept of a controlled user-ns at all, if the
> > > default whitelist maintains existing behavior?
> >
> > In past discussions two uses have been brought up:
> >
> > 1. if an 0-day is discovered which is exacerbated by a specific
> > privilege in user namespaces, that privilege could be turned off until a
> > reboot with a fixed kernel is scheduled, without fully disabling all
> > containers.
> >
> > 2. some systems may be specifically designed to run software which
> > only requires a few capabilities in a userns. In that case all others
> > could be disabled.
> >
>
> I meant in terms of "marking" a user ns as "controlled" type -- it's
> unnecessary jargon from an end user point of view.
Ah, yes, that was my point in
http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html
and
http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html
> This may happen internally but don't make it a special case with a
> different name and don't bother users with internal concepts: simply
> implement capability whitelists with the default having equivalent
> behavior of everything allowed. Then, document the semantics of the
> whitelist in terms of inheritance etc., as a feature of user namespaces,
> not as a "type" of user namespace.
The problem with making them inheritable is that an adversarial user
can just create a user namespace at boot that sits and waits for an
0day to be published, then log in and attach to that namespace later,
since it has already inherited the open whitelist.
It feels like there must be some other approach that doesn't feel as...
band-aid-y as this does, but I'm not sure what.
^ permalink raw reply
* Re: rt2x00: Delete an error message for a failed memory allocation in rt2x00queue_allocate()
From: Kalle Valo @ 2018-01-08 15:46 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-wireless, netdev, Helmut Schaa, Stanislaw Gruszka, LKML,
kernel-janitors
In-Reply-To: <cdeaa8a2-06bb-10e9-05d7-f531c00eef5d@users.sourceforge.net>
SF Markus Elfring <elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 29 Dec 2017 22:11:42 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
cd7c0cdab7ff rt2x00: Delete an error message for a failed memory allocation in rt2x00queue_allocate()
--
https://patchwork.kernel.org/patch/10137399/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Andrew Lunn @ 2018-01-08 15:42 UTC (permalink / raw)
To: Graeme Gregory
Cc: Marcin Wojtas, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <20180108151453.GB31502@xora-haswell>
w> I am not familiar with MDIO, but if its similar or a specific
> implementation of a serial bus that does sound sane!
It is a two wire serial bus. A good overview can be found here:
https://www.totalphase.com/support/articles/200349206-MDIO-Background
Andrew
^ permalink raw reply
* Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share filter block instances
From: Jiri Pirko @ 2018-01-08 15:42 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: netdev, davem, jhs, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, saeedm, matanb, leonro,
idosch, jakub.kicinski, simon.horman, pieter.jansenvanvuuren,
john.hurley, alexander.h.duyck, ogerlitz, john.fastabend, daniel,
dsahern
In-Reply-To: <20180108152306.GJ725@localhost.localdomain>
Mon, Jan 08, 2018 at 04:23:06PM CET, marcelo.leitner@gmail.com wrote:
>On Sat, Jan 06, 2018 at 12:09:18AM +0100, Jiri Pirko wrote:
>...
>> Note we cannot use the qdisc for filter manipulations for shared blocks:
>>
>> $ tc filter add dev ens8 ingress protocol ip pref 1 flower dst_ip 192.168.100.2 action drop
>> Error: Cannot work with shared block, please use block index.
>>
>>
>> We will see the same output if we list filters for ingress qdisc of
>> ens7 and ens8, also for the block 22:
>>
>> $ tc filter show block 22
>> filter block 22 protocol ip pref 25 flower chain 0
>> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
>> ...
>>
>> $ tc filter show dev ens7 ingress
>> filter block 22 protocol ip pref 25 flower chain 0
>> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
>> ...
>>
>> $ tc filter show dev ens8 ingress
>> filter block 22 protocol ip pref 25 flower chain 0
>> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
>> ...
>
>If changing a rule on an interface and reflecting it on the other
>is considered confusing, what about getting the stats including the
>stats from the other interface? AFAICT that's what would happen in the
>3 show commands above, they would show the same values.
Yes. Same block, same values.
>
>Seems it can get confusing to the user: to check an interface, see
>some hits on it, but they actually happened on the other interface.
Okay, what do you suggest?
Note that "filter show" uses dumpit.
Also note that each filter listed under qdisc ens7 ingress and
dev ens8 ingress is very clearly marked with "block 22".
Why is it confusing?
^ permalink raw reply
* [nf-next:master 54/54] net//netfilter/nf_flow_table.c:196:6: error: void value not ignored as it ought to be
From: kbuild test robot @ 2018-01-08 15:40 UTC (permalink / raw)
To: David S. Miller
Cc: kbuild-all, netfilter-devel, coreteam, netdev, Pablo Neira Ayuso
[-- Attachment #1: Type: text/plain, Size: 4052 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
head: 7844629488fd1489d19a08ce25a51e03e69834a7
commit: 7844629488fd1489d19a08ce25a51e03e69834a7 [54/54] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 7844629488fd1489d19a08ce25a51e03e69834a7
# save the attached .config to linux build tree
make.cross ARCH=ia64
All errors (new ones prefixed by >>):
net//netfilter/nf_flow_table.c: In function 'nf_flow_table_iterate':
>> net//netfilter/nf_flow_table.c:196:6: error: void value not ignored as it ought to be
err = rhashtable_walk_start(&hti);
^
net//netfilter/nf_flow_table.c: In function 'nf_flow_offload_work_gc':
net//netfilter/nf_flow_table.c:244:6: error: void value not ignored as it ought to be
err = rhashtable_walk_start(&hti);
^
vim +196 net//netfilter/nf_flow_table.c
43aa1d78 Pablo Neira Ayuso 2018-01-07 185
43aa1d78 Pablo Neira Ayuso 2018-01-07 186 int nf_flow_table_iterate(struct nf_flowtable *flow_table,
43aa1d78 Pablo Neira Ayuso 2018-01-07 187 void (*iter)(struct flow_offload *flow, void *data),
43aa1d78 Pablo Neira Ayuso 2018-01-07 188 void *data)
43aa1d78 Pablo Neira Ayuso 2018-01-07 189 {
43aa1d78 Pablo Neira Ayuso 2018-01-07 190 struct flow_offload_tuple_rhash *tuplehash;
43aa1d78 Pablo Neira Ayuso 2018-01-07 191 struct rhashtable_iter hti;
43aa1d78 Pablo Neira Ayuso 2018-01-07 192 struct flow_offload *flow;
43aa1d78 Pablo Neira Ayuso 2018-01-07 193 int err;
43aa1d78 Pablo Neira Ayuso 2018-01-07 194
43aa1d78 Pablo Neira Ayuso 2018-01-07 195 rhashtable_walk_init(&flow_table->rhashtable, &hti, GFP_KERNEL);
43aa1d78 Pablo Neira Ayuso 2018-01-07 @196 err = rhashtable_walk_start(&hti);
43aa1d78 Pablo Neira Ayuso 2018-01-07 197 if (err && err != -EAGAIN)
43aa1d78 Pablo Neira Ayuso 2018-01-07 198 goto out;
43aa1d78 Pablo Neira Ayuso 2018-01-07 199
43aa1d78 Pablo Neira Ayuso 2018-01-07 200 while ((tuplehash = rhashtable_walk_next(&hti))) {
43aa1d78 Pablo Neira Ayuso 2018-01-07 201 if (IS_ERR(tuplehash)) {
43aa1d78 Pablo Neira Ayuso 2018-01-07 202 err = PTR_ERR(tuplehash);
43aa1d78 Pablo Neira Ayuso 2018-01-07 203 if (err != -EAGAIN)
43aa1d78 Pablo Neira Ayuso 2018-01-07 204 goto out;
43aa1d78 Pablo Neira Ayuso 2018-01-07 205
43aa1d78 Pablo Neira Ayuso 2018-01-07 206 continue;
43aa1d78 Pablo Neira Ayuso 2018-01-07 207 }
43aa1d78 Pablo Neira Ayuso 2018-01-07 208 if (tuplehash->tuple.dir)
43aa1d78 Pablo Neira Ayuso 2018-01-07 209 continue;
43aa1d78 Pablo Neira Ayuso 2018-01-07 210
43aa1d78 Pablo Neira Ayuso 2018-01-07 211 flow = container_of(tuplehash, struct flow_offload, tuplehash[0]);
43aa1d78 Pablo Neira Ayuso 2018-01-07 212
43aa1d78 Pablo Neira Ayuso 2018-01-07 213 iter(flow, data);
43aa1d78 Pablo Neira Ayuso 2018-01-07 214 }
43aa1d78 Pablo Neira Ayuso 2018-01-07 215 out:
43aa1d78 Pablo Neira Ayuso 2018-01-07 216 rhashtable_walk_stop(&hti);
43aa1d78 Pablo Neira Ayuso 2018-01-07 217 rhashtable_walk_exit(&hti);
43aa1d78 Pablo Neira Ayuso 2018-01-07 218
43aa1d78 Pablo Neira Ayuso 2018-01-07 219 return err;
43aa1d78 Pablo Neira Ayuso 2018-01-07 220 }
43aa1d78 Pablo Neira Ayuso 2018-01-07 221 EXPORT_SYMBOL_GPL(nf_flow_table_iterate);
43aa1d78 Pablo Neira Ayuso 2018-01-07 222
:::::: The code at line 196 was first introduced by commit
:::::: 43aa1d78410180a6354231a04bfb643a634bcfbd netfilter: add generic flow table infrastructure
:::::: TO: Pablo Neira Ayuso <pablo@netfilter.org>
:::::: CC: Pablo Neira Ayuso <pablo@netfilter.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49872 bytes --]
^ permalink raw reply
* Re: [patch iproute2 v6 0/3] tc: Add -bs option to batch mode
From: Stephen Hemminger @ 2018-01-08 15:40 UTC (permalink / raw)
To: Chris Mi
Cc: David Ahern, Phil Sutter, marcelo.leitner@gmail.com,
netdev@vger.kernel.org, gerlitz.or@gmail.com
In-Reply-To: <VI1PR0501MB2143606CB34C5486C3632881AB130@VI1PR0501MB2143.eurprd05.prod.outlook.com>
On Mon, 8 Jan 2018 08:00:00 +0000
Chris Mi <chrism@mellanox.com> wrote:
> > >> I wonder whether specifying the batch size is necessary at all.
> > >> Couldn't batch mode just collect messages until either EOF or an
> > >> incompatible command is encountered which then triggers a commit to
> > >> kernel? This might simplify code quite a bit.
> > > That's a good suggestion.
> >
> > Thanks for your time on this, Chris.
> After testing, I find that the message passed to kernel should not be too big.
> If it is bigger than about 64K, sendmsg returns -1, errno is 90 (EMSGSIZE).
> That is about 400 commands. So how about set batch size to 128 which is big enough?
Use sendmmsg?
^ permalink raw reply
* RE: [PATCH] hyperv/netvsc: Delete two error messages for a failed memory allocation in netvsc_init_buf()
From: Haiyang Zhang @ 2018-01-08 15:37 UTC (permalink / raw)
To: SF Markus Elfring, devel@linuxdriverproject.org,
netdev@vger.kernel.org, KY Srinivasan, Stephen Hemminger
Cc: LKML, kernel-janitors@vger.kernel.org
In-Reply-To: <bb8fac96-9ba6-e54f-2321-72a8fba90085@users.sourceforge.net>
> -----Original Message-----
> From: SF Markus Elfring [mailto:elfring@users.sourceforge.net]
> Sent: Sunday, January 7, 2018 3:10 PM
> To: devel@linuxdriverproject.org; netdev@vger.kernel.org; Haiyang Zhang
> <haiyangz@microsoft.com>; KY Srinivasan <kys@microsoft.com>; Stephen
> Hemminger <sthemmin@microsoft.com>
> Cc: LKML <linux-kernel@vger.kernel.org>; kernel-janitors@vger.kernel.org
> Subject: [PATCH] hyperv/netvsc: Delete two error messages for a failed
> memory allocation in netvsc_init_buf()
>
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 7 Jan 2018 21:03:26 +0100
>
> Omit extra messages for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/net/hyperv/netvsc.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c index
> 17e529af79dc..c1ec02f801f6 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -275,9 +275,6 @@ static int netvsc_init_buf(struct hv_device *device,
>
> net_device->recv_buf = vzalloc(buf_size);
> if (!net_device->recv_buf) {
> - netdev_err(ndev,
> - "unable to allocate receive buffer of size %u\n",
> - buf_size);
> ret = -ENOMEM;
> goto cleanup;
> }
> @@ -357,8 +354,6 @@ static int netvsc_init_buf(struct hv_device *device,
>
> net_device->send_buf = vzalloc(buf_size);
> if (!net_device->send_buf) {
> - netdev_err(ndev, "unable to allocate send buffer of
> size %u\n",
> - buf_size);
> ret = -ENOMEM;
> goto cleanup;
> }
These messages are not displayed anywhere else:
"unable to allocate receive buffer of size %u\n"
"unable to allocate send buffer of size %u\n",
After set ret = -ENOMEM; and cleanup, we won't know which buffer allocation failed without the error message.
So please do not remove these messages.
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH v5 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer
From: Arnd Bergmann @ 2018-01-08 15:26 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Greentime Hu, Greentime, Rick Chen, Rick Chen,
Linux Kernel Mailing List, Linus Walleij, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
linux-serial
In-Reply-To: <1e75edb3-8f7b-796c-6871-1612b027050e@linaro.org>
On Fri, Jan 5, 2018 at 10:31 AM, Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>>> No. Can't you add in arch/ndis32/Kconfig ?
>>>
>>> +select TIMER_ATCPIT100
>>>
>>> Like:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Kconfig#n50
>>
>> IMHO, it might be a little bit wierd if we select TIMER_ATCPIT100 in
>> arch/nds32/Kconfig because it is part of SoC instead of CPU.
>> If we change to another SoC with another timer, we need to select
>> another TIMER in arch/nds32/Kconfig and delete TIMER_ATCPIT100.
>> It seems more flexible to be selected in driver layer.
>>
>> It seems to be the timer is part of the arch to be selected in arch's Kconfig.
>> arch/arc/Kconfig: select ARC_TIMERS
>> arch/arc/Kconfig: select ARC_TIMERS_64BIT
>> arch/arm/Kconfig: select ARM_ARCH_TIMER
>> arch/arm64/Kconfig: select ARM_ARCH_TIMER
>> arch/blackfin/Kconfig: select BFIN_GPTIMERS
>
> No, the timer must be selected from the arch/soc's or whatever Kconfig.
> Not in the clocksource's Kconfig.
>
> eg.
>
> on ARM:
>
> arch/arm/mach-vt8500/Kconfig: select VT8500_TIMER
> arch/arm/mach-bcm/Kconfig: select BCM_KONA_TIMER
> arch/arm/mach-actions/Kconfig: select OWL_TIMER
> arch/arm/mach-digicolor/Kconfig: select DIGICOLOR_TIMER
>
> etc ...
>
> on ARM64:
>
> arch/arm64/Kconfig.platforms: select OWL_TIMER
> arch/arm64/Kconfig.platforms: select ARM_TIMER_SP804
> arch/arm64/Kconfig.platforms: select MTK_TIMER
>
> etc ...
I'd actually prefer to not do it for ARM either: Most other subsystems
don't do that, and I don't see a strong reason why clocksource should
be special here.
Selecting 'TIMER_OF' from the individual drivers that need it (as you
suggest) makes sense, but I think for ARM we treat SoC families
as a bit too special, in the end they are for the most part collections
of individual hardware blocks that may or may not be present on
some chip.
In case of risc-v and nds32, I expect that the separation will be
even less visibile in the hardware, as a typical model here is
that one company designs SoCs for multiple customers that each
have different requirements. Some of them may have one
timer and some have another timer or multiple timers, but there
is no strict separation between SoC families as I understand.
Here we'd be better off not having a per-SoC Kconfig option at
all, just a generic defconfig that enables all the drivers that might
be used, and integrators can have a defconfig file that only
enables the stuff they actually use on a given chip.
Arnd
^ permalink raw reply
* Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share filter block instances
From: Marcelo Ricardo Leitner @ 2018-01-08 15:23 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, saeedm, matanb, leonro,
idosch, jakub.kicinski, simon.horman, pieter.jansenvanvuuren,
john.hurley, alexander.h.duyck, ogerlitz, john.fastabend, daniel,
dsahern
In-Reply-To: <20180105230929.5645-1-jiri@resnulli.us>
On Sat, Jan 06, 2018 at 12:09:18AM +0100, Jiri Pirko wrote:
...
> Note we cannot use the qdisc for filter manipulations for shared blocks:
>
> $ tc filter add dev ens8 ingress protocol ip pref 1 flower dst_ip 192.168.100.2 action drop
> Error: Cannot work with shared block, please use block index.
>
>
> We will see the same output if we list filters for ingress qdisc of
> ens7 and ens8, also for the block 22:
>
> $ tc filter show block 22
> filter block 22 protocol ip pref 25 flower chain 0
> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
> ...
>
> $ tc filter show dev ens7 ingress
> filter block 22 protocol ip pref 25 flower chain 0
> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
> ...
>
> $ tc filter show dev ens8 ingress
> filter block 22 protocol ip pref 25 flower chain 0
> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
> ...
If changing a rule on an interface and reflecting it on the other
is considered confusing, what about getting the stats including the
stats from the other interface? AFAICT that's what would happen in the
3 show commands above, they would show the same values.
Seems it can get confusing to the user: to check an interface, see
some hits on it, but they actually happened on the other interface.
Marcelo
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Graeme Gregory @ 2018-01-08 15:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: Marcin Wojtas, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <20180108145312.GH10940@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]
On Mon, Jan 08, 2018 at 03:53:12PM +0100, Andrew Lunn wrote:
> On Mon, Jan 08, 2018 at 02:45:48PM +0000, Graeme Gregory wrote:
> > On Thu, Jan 04, 2018 at 05:20:36PM +0100, Andrew Lunn wrote:
> > > > > I already agreed with 'reg' being awkward in the later emails.
> > > > > Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
> > > > >
> > > > Ah it is an actual address, then yes _ADR is probably more appropriate.
> > >
> > > Newbie ACPI question. What is the definition of an address?
> > >
> > > In this cause, we are talking about an address of a device on an MDIO
> > > bus. It takes a value between 0 and 31.
> > >
> > > How are IC2 device addresses represented in ACPI? MDIO devices and I2C
> > > devices are pretty similar. So it would make sense to use the same as
> > > what I2C uses.
> > >
> > Too big (and has table) to sensibly quote, but defined in ACPI spec
> >
> > 6.1.1 _ADR (Address)
> >
> > Ive never though been quite sure if that is just an example list of
> > address types or its supposed to be canonical (in which case some ECRs
> > are needed to the spec).
>
> Hi Graeme
>
> I took a quick look at version 6.2, and noticed i2c devices use
> _ADR(). So using it for MDIO seems O.K.
>
> However, i2c, spi and uart devices all seem to be described using
> GenericSerialBus. Maybe the correct way to describe MDIO devices is to
> also use GenericSerialBus?
>
I am not familiar with MDIO, but if its similar or a specific
implementation of a serial bus that does sound sane!
Graeme
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
From: Stefano Brivio @ 2018-01-08 15:11 UTC (permalink / raw)
To: Nicolai Stange
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Mohamed Ghannam, Michal Kubecek, Miroslav Benes, netdev,
linux-kernel
In-Reply-To: <20180108145444.19457-1-nstange@suse.de>
On Mon, 8 Jan 2018 15:54:44 +0100
Nicolai Stange <nstange@suse.de> wrote:
> Commit 8f659a03a0ba ("net: ipv4: fix for a race condition in
> raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling
> due to concurrent updates by reading this bit-field member into a local
> variable and using the thus stabilized value in subsequent tests.
>
> However, aforementioned commit also adds the (correct) comment that
>
> /* hdrincl should be READ_ONCE(inet->hdrincl)
> * but READ_ONCE() doesn't work with bit fields
> */
>
> because as it stands, the compiler is free to shortcut or even eliminate
> the local variable at its will.
>
> Note that I have not seen anything like this happening in reality and thus,
> the concern is a theoretical one.
>
> However, in order to be on the safe side, emulate a READ_ONCE() on the
> bit-field by doing it on the local 'hdrincl' variable itself:
>
> int hdrincl = inet->hdrincl;
> hdrincl = READ_ONCE(hdrincl);
>
> This breaks the chain in the sense that the compiler is not allowed
> to replace subsequent reads from hdrincl with reloads from inet->hdrincl.
>
> Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg")
> Signed-off-by: Nicolai Stange <nstange@suse.de>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
--
Stefano
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox