OSDN Git Service
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:24 +0000 (00:54 +0900)]
ALSA: firewire-lib: tune the minimum available size of PCM period
In IEC 61883-1/6, one isoc packet can transfer events up to the value of
syt interval. This comes from the interval of isoc cycle. As 1394 OHCI
controller can generate hardware IRQ per isoc packet, the interval is
calculated as 125 usec.
In IEC 61883-1/6, two ways of transmission is described; blocking and
non-blocking methods. In blocking method, the sequence of packet includes
'empty' or 'NODATA' packets which include no events. In non-blocking
method, the number of events per packet is variable up to the syt
interval.
This commit uses double of the value of syt interval as minimum available
size of PCM period due to the above protocol design.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-13-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:23 +0000 (00:54 +0900)]
ALSA: firewire-lib: tune the maximum available size of PCM period
Linux driver for 1394 OHCI controller voluntarily flushes isoc context
when total size of accumulated context header reached PAGE_SIZE. This
kicks tasklet for the isoc context. This is inconvenient to process
runtime of PCM substream.
This commit adds a restriction of the maximum size of PCM period to
avoid this behaviour.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-12-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:22 +0000 (00:54 +0900)]
ALSA: firewire-lib: schedule hardware IRQ according to the size of PCM period
ALSA IEC 61883-1/6 packet streaming engine controls 1394 OHCI controller
to generate hardware IRQ for fixed number of isochronous packets (=16)
since its first commit.
This commit allow the engine to generate it for variable period according
to the number of event to handle. For outgoing stream, internal
calculator is used to check the accumulated events. For incoming stream,
the number of data block in the packet of stream is used to check the
accumulated events. When it's unavailable, fixed number of packet
roughly calculated in advance is used instead of event counting.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-11-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:21 +0000 (00:54 +0900)]
ALSA: fireface: share PCM buffer size for both direction
This commit allows ALSA fireface driver to share PCM buffer size for
both capture and playback PCM substream. When AMDTP domain starts for
one of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-10-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:20 +0000 (00:54 +0900)]
ALSA: firewire-motu: share PCM buffer size for both direction
This commit allows ALSA firewire-motu driver to share PCM buffer
size for both capture and playback PCM substream. When AMDTP domain
starts for one of the PCM substream, buffer size of the PCM substream
is stores to AMDTP domain structure. Some AMDTP streams have already
run with the buffer size when another PCM substream starts, therefore
the PCM substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:19 +0000 (00:54 +0900)]
ALSA: firewire-tascam: share PCM buffer size for both direction
This commit allows ALSA firewire-tascam driver to share PCM buffer
size for both capture and playback PCM substream. When AMDTP domain
starts for one of the PCM substream, buffer size of the PCM substream
is stores to AMDTP domain structure. Some AMDTP streams have already
run with the buffer size when another PCM substream starts, therefore
the PCM substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:18 +0000 (00:54 +0900)]
ALSA: firewire-digi00x: share PCM buffer size for both direction
This commit allows ALSA firewire-digi00x driver to share PCM buffer
size for both capture and playback PCM substream. When AMDTP domain
starts for one of the PCM substream, buffer size of the PCM substream
is stores to AMDTP domain structure. Some AMDTP streams have already
run with the buffer size when another PCM substream starts, therefore
the PCM substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:17 +0000 (00:54 +0900)]
ALSA: dice: share PCM buffer size for both direction
This commit allows ALSA dice driver to share PCM buffer size for both
capture and playback PCM substream. When AMDTP domain starts for one
of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:16 +0000 (00:54 +0900)]
ALSA: oxfw: share PCM buffer size for both direction
This commit allows ALSA oxfw driver to share PCM buffer size for both
capture and playback PCM substream. When AMDTP domain starts for one
of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:15 +0000 (00:54 +0900)]
ALSA: fireworks: share PCM buffer size for both direction
This commit allows ALSA fireworks driver to share PCM buffer size for
both capture and playback PCM substream. When AMDTP domain starts for
one of the PCM substream, buffer size of the PCM substream is stores
to AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:14 +0000 (00:54 +0900)]
ALSA: bebob: share PCM buffer size for both direction
This commit allows ALSA bebob driver to share PCM buffer size for both
capture and playback PCM substream. When AMDTP domain starts for one
of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Thu, 17 Oct 2019 15:54:13 +0000 (00:54 +0900)]
ALSA: firewire-lib: use variable size of queue for isoc packets instead of fixed size
The number of packets in packet buffer has been fixed number (=48) since
first commit of ALSA IEC 61883-1/6 packet streaming engine.
This commit allows the engine to use variable number of packets in the
buffer. The size is calculated by a parameter in AMDTP domain structure
surely to store the number of events in the packets of buffer. Although
the value of parameter is expected to come from 'period size' parameter
of PCM substream, at present 48 is still used.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:32 +0000 (20:05 +0900)]
ALSA: fireface: use the same size of period for PCM substreams in AMDTP streams
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams on AMDTP streams in domain is recorded in
own structure. Usage of this count is an alternative of the above check.
This is better because the count is incremented in pcm.hw_params earlier
than pcm.trigger.
This commit replaces the check with the substream count and the value for
the size of PCM period. Unlike the other drivers in ALSA firewire stack,
no MIDI substream is multiplexed into AMDTP stream.
I note that Fireface AMDTP protocol has a quirk that tx stream includes
blank isochronous cycle. The packet for blank cycle is equivalent to
empty or NODATA packet in IEC 61883-6, thus the protocol is similar to
blocking transmission method of IEC 61883-6. On the other hand, rx
stream adopts non-blocking transmission method. Although the difference
of transmission method between tx/rx streams precisely brings different
timing for a certain amount of events due to their different calculation
for data blocks per packet, it's possible to approximate enough amount
of events mostly has the same timing. Actually current ALSA IEC 61883-1/6
engine uses large amount of data blocks for each hardware IRQ
(=16 packets).
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-18-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:31 +0000 (20:05 +0900)]
ALSA: firewire-motu: use the same size of period for PCM substream in AMDTP streams
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-17-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:30 +0000 (20:05 +0900)]
ALSA: firewire-tascam: use the same size of period for PCM substream in AMDTP streams
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams on AMDTP streams in domain is recorded in
own structure. Usage of this count is an alternative of the above check.
This is better because the count is incremented in pcm.hw_params earlier
than pcm.trigger.
This commit replaces the check with the substream count and the value for
the size of PCM period. Unlike the other drivers in ALSA firewire stack,
no MIDI substream is multiplexed into AMDTP stream.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-16-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:29 +0000 (20:05 +0900)]
ALSA: firewire-digi00x: use the same size of period for PCM substream in AMDTP streams
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
I note that DOT AMDTP protocol has a quirk to use different transmission
method of IEC 61883-6 for tx/rx streams; non-blocking in tx stream and
blocking in rx stream. Although the difference of transmission method
between tx/rx streams precisely brings different timing for a certain
amount of events due to their different calculation for data blocks per
packet, it's possible to approximate enough amount of events mostly has
the same timing. Actually current ALSA IEC 61883-1/6 engine uses large
amount of data blocks for each hardware IRQ (=16 packets).
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-15-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:28 +0000 (20:05 +0900)]
ALSA: dice: use the same size of period for PCM substream in AMDTP streams
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Dice hardware has a quirk called as 'Dual Wire'. For a case of higher
sampling transmission frequency, this commit performs calculations between
the number of PCM frames and the number of events in AMDTP stream.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-14-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:27 +0000 (20:05 +0900)]
ALSA: oxfw: use the same size of period for PCM substream in AMDTP streams
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-13-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:26 +0000 (20:05 +0900)]
ALSA: fireworks: use the same size of period for PCM substream in AMDTP streams
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-12-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:25 +0000 (20:05 +0900)]
ALSA: bebob: use the same size of period for PCM substream in AMDTP streams
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-11-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:24 +0000 (20:05 +0900)]
ALSA: fireface: register the size of PCM period to AMDTP domain
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-10-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:23 +0000 (20:05 +0900)]
ALSA: firewire-motu: register the size of PCM period to AMDTP domain
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:22 +0000 (20:05 +0900)]
ALSA: firewire-tascam: register the size of PCM period to AMDTP domain
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:21 +0000 (20:05 +0900)]
ALSA: firewire-digi00x: register the size of PCM period to AMDTP domain
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:20 +0000 (20:05 +0900)]
ALSA: dice: register the size of PCM period to AMDTP domain
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:19 +0000 (20:05 +0900)]
ALSA: oxfw: register the size of PCM period to AMDTP domain
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:18 +0000 (20:05 +0900)]
ALSA: fireworks: register the size of PCM period to AMDTP domain
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:17 +0000 (20:05 +0900)]
ALSA: bebob: register the size of PCM period to AMDTP domain
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Oct 2019 11:05:16 +0000 (20:05 +0900)]
ALSA: firewire-lib: add a member into AMDTP domain for events per period
In IEC 61883-6, it's called as 'event' what has presentation time
represented by timestamp in CIP header. Although the ratio of the number
of event against the number of data block is different depending on
event data type represented by the specific field in CIP header, it's
just one in the most cases supported by ALSA IEC 61883-1/6 engine.
In 1394 OHCI specification, applications can schedule hardware IRQ
by configuring descriptor with IRQ flag for packet against each
isochronous cycle. For future commit, I use the hardware IRQ for
isoc IT context to acknowledge the elapse of PCM period for both
playback/capture directions on AMDTP streams in the same domain.
This commit is a preparation for the above idea. This commit adds
a member into AMDTP domain structure to record the number of PCM frames.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Krzysztof Kozlowski [Fri, 4 Oct 2019 14:49:31 +0000 (16:49 +0200)]
sound: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20191004144931.3851-1-krzk@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Linus Torvalds [Sun, 6 Oct 2019 21:27:30 +0000 (14:27 -0700)]
Linux 5.4-rc2
Linus Torvalds [Sun, 6 Oct 2019 20:53:27 +0000 (13:53 -0700)]
elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings
In commit
4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") we
changed elf to use MAP_FIXED_NOREPLACE instead of MAP_FIXED for the
executable mappings.
Then, people reported that it broke some binaries that had overlapping
segments from the same file, and commit
ad55eac74f20 ("elf: enforce
MAP_FIXED on overlaying elf segments") re-instated MAP_FIXED for some
overlaying elf segment cases. But only some - despite the summary line
of that commit, it only did it when it also does a temporary brk vma for
one obvious overlapping case.
Now Russell King reports another overlapping case with old 32-bit x86
binaries, which doesn't trigger that limited case. End result: we had
better just drop MAP_FIXED_NOREPLACE entirely, and go back to MAP_FIXED.
Yes, it's a sign of old binaries generated with old tool-chains, but we
do pride ourselves on not breaking existing setups.
This still leaves MAP_FIXED_NOREPLACE in place for the load_elf_interp()
and the old load_elf_library() use-cases, because nobody has reported
breakage for those. Yet.
Note that in all the cases seen so far, the overlapping elf sections
seem to be just re-mapping of the same executable with different section
attributes. We could possibly introduce a new MAP_FIXED_NOFILECHANGE
flag or similar, which acts like NOREPLACE, but allows just remapping
the same executable file using different protection flags.
It's not clear that would make a huge difference to anything, but if
people really hate that "elf remaps over previous maps" behavior, maybe
at least a more limited form of remapping would alleviate some concerns.
Alternatively, we should take a look at our elf_map() logic to see if we
end up not mapping things properly the first time.
In the meantime, this is the minimal "don't do that then" patch while
people hopefully think about it more.
Reported-by: Russell King <linux@armlinux.org.uk>
Fixes:
4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map")
Fixes:
ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments")
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sun, 6 Oct 2019 18:10:15 +0000 (11:10 -0700)]
Merge tag 'dma-mapping-5.4-1' of git://git.infradead.org/users/hch/dma-mapping
Pull dma-mapping regression fix from Christoph Hellwig:
"Revert an incorret hunk from a patch that caused problems on various
arm boards (Andrey Smirnov)"
* tag 'dma-mapping-5.4-1' of git://git.infradead.org/users/hch/dma-mapping:
dma-mapping: fix false positive warnings in dma_common_free_remap()
Linus Torvalds [Sun, 6 Oct 2019 00:18:43 +0000 (17:18 -0700)]
Merge tag 'armsoc-fixes' of git://git./linux/kernel/git/soc/soc
Pull ARM SoC fixes from Olof Johansson:
"A few fixes this time around:
- Fixup of some clock specifications for DRA7 (device-tree fix)
- Removal of some dead/legacy CPU OPP/PM code for OMAP that throws
warnings at boot
- A few more minor fixups for OMAPs, most around display
- Enable STM32 QSPI as =y since their rootfs sometimes comes from
there
- Switch CONFIG_REMOTEPROC to =y since it went from tristate to bool
- Fix of thermal zone definition for ux500 (5.4 regression)"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI support
ARM: dts: ux500: Fix up the CPU thermal zone
arm64/ARM: configs: Change CONFIG_REMOTEPROC from m to y
ARM: dts: am4372: Set memory bandwidth limit for DISPC
ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage()
ARM: OMAP2+: Add missing LCDC midlemode for am335x
ARM: OMAP2+: Fix missing reset done flag for am3 and am43
ARM: dts: Fix gpio0 flags for am335x-icev2
ARM: omap2plus_defconfig: Enable more droid4 devices as loadable modules
ARM: omap2plus_defconfig: Enable DRM_TI_TFP410
DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again
ARM: dts: Fix wrong clocks for dra7 mcasp
clk: ti: dra7: Fix mcasp8 clock bits
Linus Torvalds [Sat, 5 Oct 2019 19:56:59 +0000 (12:56 -0700)]
Merge tag 'kbuild-fixes-v5.4' of git://git./linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- remove unneeded ar-option and KBUILD_ARFLAGS
- remove long-deprecated SUBDIRS
- fix modpost to suppress false-positive warnings for UML builds
- fix namespace.pl to handle relative paths to ${objtree}, ${srctree}
- make setlocalversion work for /bin/sh
- make header archive reproducible
- fix some Makefiles and documents
* tag 'kbuild-fixes-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kheaders: make headers archive reproducible
kbuild: update compile-test header list for v5.4-rc2
kbuild: two minor updates for Documentation/kbuild/modules.rst
scripts/setlocalversion: clear local variable to make it work for sh
namespace: fix namespace.pl script to support relative paths
video/logo: do not generate unneeded logo C files
video/logo: remove unneeded *.o pattern from clean-files
integrity: remove pointless subdir-$(CONFIG_...)
integrity: remove unneeded, broken attempt to add -fshort-wchar
modpost: fix static EXPORT_SYMBOL warnings for UML build
kbuild: correct formatting of header in kbuild module docs
kbuild: remove SUBDIRS support
kbuild: remove ar-option and KBUILD_ARFLAGS
Linus Torvalds [Sat, 5 Oct 2019 19:53:27 +0000 (12:53 -0700)]
Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Twelve patches mostly small but obvious fixes or cosmetic but small
updates"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: qla2xxx: Fix Nport ID display value
scsi: qla2xxx: Fix N2N link up fail
scsi: qla2xxx: Fix N2N link reset
scsi: qla2xxx: Optimize NPIV tear down process
scsi: qla2xxx: Fix stale mem access on driver unload
scsi: qla2xxx: Fix unbound sleep in fcport delete path.
scsi: qla2xxx: Silence fwdump template message
scsi: hisi_sas: Make three functions static
scsi: megaraid: disable device when probe failed after enabled device
scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue
scsi: qedf: Remove always false 'tmp_prio < 0' statement
scsi: ufs: skip shutdown if hba is not powered
scsi: bnx2fc: Handle scope bits when array returns BUSY or TSF
Linus Torvalds [Sat, 5 Oct 2019 19:03:27 +0000 (12:03 -0700)]
Merge branch 'readdir' (readdir speedup and sanity checking)
This makes getdents() and getdents64() do sanity checking on the
pathname that it gives to user space. And to mitigate the performance
impact of that, it first cleans up the way it does the user copying, so
that the code avoids doing the SMAP/PAN updates between each part of the
dirent structure write.
I really wanted to do this during the merge window, but didn't have
time. The conversion of filldir to unsafe_put_user() is something I've
had around for years now in a private branch, but the extra pathname
checking finally made me clean it up to the point where it is mergable.
It's worth noting that the filename validity checking really should be a
bit smarter: it would be much better to delay the error reporting until
the end of the readdir, so that non-corrupted filenames are still
returned. But that involves bigger changes, so let's see if anybody
actually hits the corrupt directory entry case before worrying about it
further.
* branch 'readdir':
Make filldir[64]() verify the directory entry filename is valid
Convert filldir[64]() from __put_user() to unsafe_put_user()
Linus Torvalds [Sat, 5 Oct 2019 18:32:52 +0000 (11:32 -0700)]
Make filldir[64]() verify the directory entry filename is valid
This has been discussed several times, and now filesystem people are
talking about doing it individually at the filesystem layer, so head
that off at the pass and just do it in getdents{64}().
This is partially based on a patch by Jann Horn, but checks for NUL
bytes as well, and somewhat simplified.
There's also commentary about how it might be better if invalid names
due to filesystem corruption don't cause an immediate failure, but only
an error at the end of the readdir(), so that people can still see the
filenames that are ok.
There's also been discussion about just how much POSIX strictly speaking
requires this since it's about filesystem corruption. It's really more
"protect user space from bad behavior" as pointed out by Jann. But
since Eric Biederman looked up the POSIX wording, here it is for context:
"From readdir:
The readdir() function shall return a pointer to a structure
representing the directory entry at the current position in the
directory stream specified by the argument dirp, and position the
directory stream at the next entry. It shall return a null pointer
upon reaching the end of the directory stream. The structure dirent
defined in the <dirent.h> header describes a directory entry.
From definitions:
3.129 Directory Entry (or Link)
An object that associates a filename with a file. Several directory
entries can associate names with the same file.
...
3.169 Filename
A name consisting of 1 to {NAME_MAX} bytes used to name a file. The
characters composing the name may be selected from the set of all
character values excluding the slash character and the null byte. The
filenames dot and dot-dot have special meaning. A filename is
sometimes referred to as a 'pathname component'."
Note that I didn't bother adding the checks to any legacy interfaces
that nobody uses.
Also note that if this ends up being noticeable as a performance
regression, we can fix that to do a much more optimized model that
checks for both NUL and '/' at the same time one word at a time.
We haven't really tended to optimize 'memchr()', and it only checks for
one pattern at a time anyway, and we really _should_ check for NUL too
(but see the comment about "soft errors" in the code about why it
currently only checks for '/')
See the CONFIG_DCACHE_WORD_ACCESS case of hash_name() for how the name
lookup code looks for pathname terminating characters in parallel.
Link: https://lore.kernel.org/lkml/20190118161440.220134-2-jannh@google.com/
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Jann Horn <jannh@google.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sun, 22 May 2016 04:59:07 +0000 (21:59 -0700)]
Convert filldir[64]() from __put_user() to unsafe_put_user()
We really should avoid the "__{get,put}_user()" functions entirely,
because they can easily be mis-used and the original intent of being
used for simple direct user accesses no longer holds in a post-SMAP/PAN
world.
Manually optimizing away the user access range check makes no sense any
more, when the range check is generally much cheaper than the "enable
user accesses" code that the __{get,put}_user() functions still need.
So instead of __put_user(), use the unsafe_put_user() interface with
user_access_{begin,end}() that really does generate better code these
days, and which is generally a nicer interface. Under some loads, the
multiple user writes that filldir() does are actually quite noticeable.
This also makes the dirent name copy use unsafe_put_user() with a couple
of macros. We do not want to make function calls with SMAP/PAN
disabled, and the code this generates is quite good when the
architecture uses "asm goto" for unsafe_put_user() like x86 does.
Note that this doesn't bother with the legacy cases. Nobody should use
them anyway, so performance doesn't really matter there.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sat, 5 Oct 2019 15:50:15 +0000 (08:50 -0700)]
Merge git://git./linux/kernel/git/netdev/net
Pull networking fixes from David Miller:
1) Fix ieeeu02154 atusb driver use-after-free, from Johan Hovold.
2) Need to validate TCA_CBQ_WRROPT netlink attributes, from Eric
Dumazet.
3) txq null deref in mac80211, from Miaoqing Pan.
4) ionic driver needs to select NET_DEVLINK, from Arnd Bergmann.
5) Need to disable bh during nft_connlimit GC, from Pablo Neira Ayuso.
6) Avoid division by zero in taprio scheduler, from Vladimir Oltean.
7) Various xgmac fixes in stmmac driver from Jose Abreu.
8) Avoid 64-bit division in mlx5 leading to link errors on 32-bit from
Michal Kubecek.
9) Fix bad VLAN check in rtl8366 DSA driver, from Linus Walleij.
10) Fix sleep while atomic in sja1105, from Vladimir Oltean.
11) Suspend/resume deadlock in stmmac, from Thierry Reding.
12) Various UDP GSO fixes from Josh Hunt.
13) Fix slab out of bounds access in tcp_zerocopy_receive(), from Eric
Dumazet.
14) Fix OOPS in __ipv6_ifa_notify(), from David Ahern.
15) Memory leak in NFC's llcp_sock_bind, from Eric Dumazet.
* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (72 commits)
selftests/net: add nettest to .gitignore
net: qlogic: Fix memory leak in ql_alloc_large_buffers
nfc: fix memory leak in llcp_sock_bind()
sch_dsmark: fix potential NULL deref in dsmark_init()
net: phy: at803x: use operating parameters from PHY-specific status
net: phy: extract pause mode
net: phy: extract link partner advertisement reading
net: phy: fix write to mii-ctrl1000 register
ipv6: Handle missing host route in __ipv6_ifa_notify
net: phy: allow for reset line to be tied to a sleepy GPIO controller
net: ipv4: avoid mixed n_redirects and rate_tokens usage
r8152: Set macpassthru in reset_resume callback
cxgb4:Fix out-of-bounds MSI-X info array access
Revert "ipv6: Handle race in addrconf_dad_work"
net: make sock_prot_memory_pressure() return "const char *"
rxrpc: Fix rxrpc_recvmsg tracepoint
qmi_wwan: add support for Cinterion CLS8 devices
tcp: fix slab-out-of-bounds in tcp_zerocopy_receive()
lib: textsearch: fix escapes in example code
udp: only do GSO if # of segs > 1
...
Linus Torvalds [Sat, 5 Oct 2019 15:44:02 +0000 (08:44 -0700)]
Merge tag 's390-5.4-3' of git://git./linux/kernel/git/s390/linux
Pull s390 fixes from Vasily Gorbik:
- defconfig updates
- Fix build errors with CC_OPTIMIZE_FOR_SIZE due to usage of "i"
constraint for function arguments. Two kvm changes acked-by Christian
Borntraeger.
- Fix -Wunused-but-set-variable warnings in mm code.
- Avoid a constant misuse in qdio.
- Handle a case when cpumf is temporarily unavailable.
* tag 's390-5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
KVM: s390: mark __insn32_query() as __always_inline
KVM: s390: fix __insn32_query() inline assembly
s390: update defconfigs
s390/pci: mark function(s) __always_inline
s390/mm: mark function(s) __always_inline
s390/jump_label: mark function(s) __always_inline
s390/cpu_mf: mark function(s) __always_inline
s390/atomic,bitops: mark function(s) __always_inline
s390/mm: fix -Wunused-but-set-variable warnings
s390: mark __cpacf_query() as __always_inline
s390/qdio: clarify size of the QIB parm area
s390/cpumf: Fix indentation in sampling device driver
s390/cpumsf: Check for CPU Measurement sampling
s390/cpumf: Use consistant debug print format
Heiko Carstens [Wed, 2 Oct 2019 12:34:37 +0000 (14:34 +0200)]
KVM: s390: mark __insn32_query() as __always_inline
__insn32_query() will not compile if the compiler decides to not
inline it, since it contains an inline assembly with an "i" constraint
with variable contents.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Heiko Carstens [Wed, 2 Oct 2019 12:24:47 +0000 (14:24 +0200)]
KVM: s390: fix __insn32_query() inline assembly
The inline assembly constraints of __insn32_query() tell the compiler
that only the first byte of "query" is being written to. Intended was
probably that 32 bytes are written to.
Fix and simplify the code and just use a "memory" clobber.
Fixes:
d668139718a9 ("KVM: s390: provide query function for instructions returning 32 byte")
Cc: stable@vger.kernel.org # v5.2+
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Andrey Smirnov [Sat, 5 Oct 2019 08:23:30 +0000 (10:23 +0200)]
dma-mapping: fix false positivse warnings in dma_common_free_remap()
Commit
5cf4537975bb ("dma-mapping: introduce a dma_common_find_pages
helper") changed invalid input check in dma_common_free_remap() from:
if (!area || !area->flags != VM_DMA_COHERENT)
to
if (!area || !area->flags != VM_DMA_COHERENT || !area->pages)
which seem to produce false positives for memory obtained via
dma_common_contiguous_remap()
This triggers the following warning message when doing "reboot" on ZII
VF610 Dev Board Rev B:
WARNING: CPU: 0 PID: 1 at kernel/dma/remap.c:112 dma_common_free_remap+0x88/0x8c
trying to free invalid coherent area:
9ef82980
Modules linked in:
CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.3.0-rc6-next-
20190820 #119
Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
Backtrace:
[<
8010d1ec>] (dump_backtrace) from [<
8010d588>] (show_stack+0x20/0x24)
r7:
8015ed78 r6:
00000009 r5:
00000000 r4:
9f4d9b14
[<
8010d568>] (show_stack) from [<
8077e3f0>] (dump_stack+0x24/0x28)
[<
8077e3cc>] (dump_stack) from [<
801197a0>] (__warn.part.3+0xcc/0xe4)
[<
801196d4>] (__warn.part.3) from [<
80119830>] (warn_slowpath_fmt+0x78/0x94)
r6:
00000070 r5:
808e540c r4:
81c03048
[<
801197bc>] (warn_slowpath_fmt) from [<
8015ed78>] (dma_common_free_remap+0x88/0x8c)
r3:
9ef82980 r2:
808e53e0
r7:
00001000 r6:
a0b1e000 r5:
a0b1e000 r4:
00001000
[<
8015ecf0>] (dma_common_free_remap) from [<
8010fa9c>] (remap_allocator_free+0x60/0x68)
r5:
81c03048 r4:
9f4d9b78
[<
8010fa3c>] (remap_allocator_free) from [<
801100d0>] (__arm_dma_free.constprop.3+0xf8/0x148)
r5:
81c03048 r4:
9ef82900
[<
8010ffd8>] (__arm_dma_free.constprop.3) from [<
80110144>] (arm_dma_free+0x24/0x2c)
r5:
9f563410 r4:
80110120
[<
80110120>] (arm_dma_free) from [<
8015d80c>] (dma_free_attrs+0xa0/0xdc)
[<
8015d76c>] (dma_free_attrs) from [<
8020f3e4>] (dma_pool_destroy+0xc0/0x154)
r8:
9efa8860 r7:
808f02f0 r6:
808f02d0 r5:
9ef82880 r4:
9ef82780
[<
8020f324>] (dma_pool_destroy) from [<
805525d0>] (ehci_mem_cleanup+0x6c/0x150)
r7:
9f563410 r6:
9efa8810 r5:
00000000 r4:
9efd0148
[<
80552564>] (ehci_mem_cleanup) from [<
80558e0c>] (ehci_stop+0xac/0xc0)
r5:
9efd0148 r4:
9efd0000
[<
80558d60>] (ehci_stop) from [<
8053c4bc>] (usb_remove_hcd+0xf4/0x1b0)
r7:
9f563410 r6:
9efd0074 r5:
81c03048 r4:
9efd0000
[<
8053c3c8>] (usb_remove_hcd) from [<
8056361c>] (host_stop+0x48/0xb8)
r7:
9f563410 r6:
9efd0000 r5:
9f5f4040 r4:
9f5f5040
[<
805635d4>] (host_stop) from [<
80563d0c>] (ci_hdrc_host_destroy+0x34/0x38)
r7:
9f563410 r6:
9f5f5040 r5:
9efa8800 r4:
9f5f4040
[<
80563cd8>] (ci_hdrc_host_destroy) from [<
8055ef18>] (ci_hdrc_remove+0x50/0x10c)
[<
8055eec8>] (ci_hdrc_remove) from [<
804a2ed8>] (platform_drv_remove+0x34/0x4c)
r7:
9f563410 r6:
81c4f99c r5:
9efa8810 r4:
9efa8810
[<
804a2ea4>] (platform_drv_remove) from [<
804a18a8>] (device_release_driver_internal+0xec/0x19c)
r5:
00000000 r4:
9efa8810
[<
804a17bc>] (device_release_driver_internal) from [<
804a1978>] (device_release_driver+0x20/0x24)
r7:
9f563410 r6:
81c41ed0 r5:
9efa8810 r4:
9f4a1dac
[<
804a1958>] (device_release_driver) from [<
804a01b8>] (bus_remove_device+0xdc/0x108)
[<
804a00dc>] (bus_remove_device) from [<
8049c204>] (device_del+0x150/0x36c)
r7:
9f563410 r6:
81c03048 r5:
9efa8854 r4:
9efa8810
[<
8049c0b4>] (device_del) from [<
804a3368>] (platform_device_del.part.2+0x20/0x84)
r10:
9f563414 r9:
809177e0 r8:
81cb07dc r7:
81c78320 r6:
9f563454 r5:
9efa8800
r4:
9efa8800
[<
804a3348>] (platform_device_del.part.2) from [<
804a3420>] (platform_device_unregister+0x28/0x34)
r5:
9f563400 r4:
9efa8800
[<
804a33f8>] (platform_device_unregister) from [<
8055dce0>] (ci_hdrc_remove_device+0x1c/0x30)
r5:
9f563400 r4:
00000001
[<
8055dcc4>] (ci_hdrc_remove_device) from [<
805652ac>] (ci_hdrc_imx_remove+0x38/0x118)
r7:
81c78320 r6:
9f563454 r5:
9f563410 r4:
9f541010
[<
8056538c>] (ci_hdrc_imx_shutdown) from [<
804a2970>] (platform_drv_shutdown+0x2c/0x30)
[<
804a2944>] (platform_drv_shutdown) from [<
8049e4fc>] (device_shutdown+0x158/0x1f0)
[<
8049e3a4>] (device_shutdown) from [<
8013ac80>] (kernel_restart_prepare+0x44/0x48)
r10:
00000058 r9:
9f4d8000 r8:
fee1dead r7:
379ce700 r6:
81c0b280 r5:
81c03048
r4:
00000000
[<
8013ac3c>] (kernel_restart_prepare) from [<
8013ad14>] (kernel_restart+0x1c/0x60)
[<
8013acf8>] (kernel_restart) from [<
8013af84>] (__do_sys_reboot+0xe0/0x1d8)
r5:
81c03048 r4:
00000000
[<
8013aea4>] (__do_sys_reboot) from [<
8013b0ec>] (sys_reboot+0x18/0x1c)
r8:
80101204 r7:
00000058 r6:
00000000 r5:
00000000 r4:
00000000
[<
8013b0d4>] (sys_reboot) from [<
80101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0x9f4d9fa8 to 0x9f4d9ff0)
9fa0:
00000000 00000000 fee1dead 28121969 01234567 379ce700
9fc0:
00000000 00000000 00000000 00000058 00000000 00000000 00000000 00016d04
9fe0:
00028e0c 7ec87c64 000135ec 76c1f410
Restore original invalid input check in dma_common_free_remap() to
avoid this problem.
Fixes:
5cf4537975bb ("dma-mapping: introduce a dma_common_find_pages helper")
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
[hch: just revert the offending hunk instead of creating a new helper]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Dmitry Goldin [Fri, 4 Oct 2019 10:40:07 +0000 (10:40 +0000)]
kheaders: make headers archive reproducible
In commit
43d8ce9d65a5 ("Provide in-kernel headers to make
extending kernel easier") a new mechanism was introduced, for kernels
>=5.2, which embeds the kernel headers in the kernel image or a module
and exposes them in procfs for use by userland tools.
The archive containing the header files has nondeterminism caused by
header files metadata. This patch normalizes the metadata and utilizes
KBUILD_BUILD_TIMESTAMP if provided and otherwise falls back to the
default behaviour.
In commit
f7b101d33046 ("kheaders: Move from proc to sysfs") it was
modified to use sysfs and the script for generation of the archive was
renamed to what is being patched.
Signed-off-by: Dmitry Goldin <dgoldin+lkml@protonmail.ch>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Masahiro Yamada [Thu, 3 Oct 2019 02:36:29 +0000 (11:36 +0900)]
kbuild: update compile-test header list for v5.4-rc2
Commit
6dc280ebeed2 ("coda: remove uapi/linux/coda_psdev.h") removed
a header in question. Some more build errors were fixed. Add more
headers into the test coverage.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Masahiro Yamada [Thu, 3 Oct 2019 10:29:12 +0000 (19:29 +0900)]
kbuild: two minor updates for Documentation/kbuild/modules.rst
Capitalize the first word in the sentence.
Use obj-m instead of obj-y. obj-y still works, but we have no built-in
objects in external module builds. So, obj-m is better IMHO.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Masahiro Yamada [Tue, 1 Oct 2019 12:17:24 +0000 (21:17 +0900)]
scripts/setlocalversion: clear local variable to make it work for sh
Geert Uytterhoeven reports a strange side-effect of commit
858805b336be
("kbuild: add $(BASH) to run scripts with bash-extension"), which
inserts the contents of a localversion file in the build directory twice.
[Steps to Reproduce]
$ echo bar > localversion
$ mkdir build
$ cd build/
$ echo foo > localversion
$ make -s -f ../Makefile defconfig include/config/kernel.release
$ cat include/config/kernel.release
5.4.0-rc1foofoobar
This comes down to the behavior change of local variables.
The 'man sh' on my Ubuntu machine, where sh is an alias to dash,
explains as follows:
When a variable is made local, it inherits the initial value and
exported and readonly flags from the variable with the same name
in the surrounding scope, if there is one. Otherwise, the variable
is initially unset.
[Test Code]
foo ()
{
local res
echo "res: $res"
}
res=1
foo
[Result]
$ sh test.sh
res: 1
$ bash test.sh
res:
So, scripts/setlocalversion correctly works only for bash in spite of
its hashbang being #!/bin/sh. Nobody had noticed it before because
CONFIG_SHELL was previously set to bash almost all the time.
Now that CONFIG_SHELL is set to sh, we must write portable and correct
code. I gave the Fixes tag to the commit that uncovered the issue.
Clear the variable 'res' in collect_files() to make it work for sh
(and it also works on distributions where sh is an alias to bash).
Fixes:
858805b336be ("kbuild: add $(BASH) to run scripts with bash-extension")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Jacob Keller [Fri, 27 Sep 2019 23:30:27 +0000 (16:30 -0700)]
namespace: fix namespace.pl script to support relative paths
The namespace.pl script does not work properly if objtree is not set to
an absolute path. The do_nm function is run from within the find
function, which changes directories.
Because of this, appending objtree, $File::Find::dir, and $source, will
return a path which is not valid from the current directory.
This used to work when objtree was set to an absolute path when using
"make namespacecheck". It appears to have not worked when calling
./scripts/namespace.pl directly.
This behavior was changed in
7e1c04779efd ("kbuild: Use relative path
for $(objtree)", 2014-05-14)
Rather than fixing the Makefile to set objtree to an absolute path, just
fix namespace.pl to work when srctree and objtree are relative. Also fix
the script to use an absolute path for these by default.
Use the File::Spec module for this purpose. It's been part of perl
5 since 5.005.
The curdir() function is used to get the current directory when the
objtree and srctree aren't set in the environment.
rel2abs() is used to convert possibly relative objtree and srctree
environment variables to absolute paths.
Finally, the catfile() function is used instead of string appending
paths together, since this is more robust when joining paths together.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Masahiro Yamada [Wed, 21 Aug 2019 04:12:35 +0000 (13:12 +0900)]
video/logo: do not generate unneeded logo C files
Currently, all the logo C files are generated irrespective of the
CONFIG options. Adding them to extra-y is wrong. What we need to do
here is to add them to 'targets' so that if_changed works properly.
Files listed in 'targets' are cleaned, so clean-files is unneeded.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Masahiro Yamada [Wed, 21 Aug 2019 04:12:34 +0000 (13:12 +0900)]
video/logo: remove unneeded *.o pattern from clean-files
The pattern *.o is cleaned up globally by the top Makefile.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Masahiro Yamada [Fri, 26 Jul 2019 02:10:55 +0000 (11:10 +0900)]
integrity: remove pointless subdir-$(CONFIG_...)
The ima/ and evm/ sub-directories contain built-in objects, so
obj-$(CONFIG_...) is the correct way to descend into them.
subdir-$(CONFIG_...) is redundant.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Masahiro Yamada [Fri, 26 Jul 2019 02:10:54 +0000 (11:10 +0900)]
integrity: remove unneeded, broken attempt to add -fshort-wchar
I guess commit
15ea0e1e3e18 ("efi: Import certificates from UEFI Secure
Boot") attempted to add -fshort-wchar for building load_uefi.o, but it
has never worked as intended.
load_uefi.o is created in the platform_certs/ sub-directory. If you
really want to add -fshort-wchar, the correct code is:
$(obj)/platform_certs/load_uefi.o: KBUILD_CFLAGS += -fshort-wchar
But, you do not need to fix it.
Commit
8c97023cf051 ("Kbuild: use -fshort-wchar globally") had already
added -fshort-wchar globally. This code was unneeded in the first place.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Jakub Kicinski [Sat, 5 Oct 2019 00:36:50 +0000 (17:36 -0700)]
selftests/net: add nettest to .gitignore
nettest is missing from gitignore.
Fixes:
acda655fefae ("selftests: Add nettest")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Navid Emamdoost [Fri, 4 Oct 2019 20:24:39 +0000 (15:24 -0500)]
net: qlogic: Fix memory leak in ql_alloc_large_buffers
In ql_alloc_large_buffers, a new skb is allocated via netdev_alloc_skb.
This skb should be released if pci_dma_mapping_error fails.
Fixes:
0f8ab89e825f ("qla3xxx: Check return code from pci_map_single() in ql_release_to_lrg_buf_free_list(), ql_populate_free_queue(), ql_alloc_large_buffers(), and ql3xxx_send()")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Fri, 4 Oct 2019 18:08:34 +0000 (11:08 -0700)]
nfc: fix memory leak in llcp_sock_bind()
sysbot reported a memory leak after a bind() has failed.
While we are at it, abort the operation if kmemdup() has failed.
BUG: memory leak
unreferenced object 0xffff888105d83ec0 (size 32):
comm "syz-executor067", pid 7207, jiffies
4294956228 (age 19.430s)
hex dump (first 32 bytes):
00 69 6c 65 20 72 65 61 64 00 6e 65 74 3a 5b 34 .ile read.net:[4
30 32 36 35 33 33 30 39 37 5d 00 00 00 00 00 00
026533097]......
backtrace:
[<
0000000036bac473>] kmemleak_alloc_recursive /./include/linux/kmemleak.h:43 [inline]
[<
0000000036bac473>] slab_post_alloc_hook /mm/slab.h:522 [inline]
[<
0000000036bac473>] slab_alloc /mm/slab.c:3319 [inline]
[<
0000000036bac473>] __do_kmalloc /mm/slab.c:3653 [inline]
[<
0000000036bac473>] __kmalloc_track_caller+0x169/0x2d0 /mm/slab.c:3670
[<
000000000cd39d07>] kmemdup+0x27/0x60 /mm/util.c:120
[<
000000008e57e5fc>] kmemdup /./include/linux/string.h:432 [inline]
[<
000000008e57e5fc>] llcp_sock_bind+0x1b3/0x230 /net/nfc/llcp_sock.c:107
[<
000000009cb0b5d3>] __sys_bind+0x11c/0x140 /net/socket.c:1647
[<
00000000492c3bbc>] __do_sys_bind /net/socket.c:1658 [inline]
[<
00000000492c3bbc>] __se_sys_bind /net/socket.c:1656 [inline]
[<
00000000492c3bbc>] __x64_sys_bind+0x1e/0x30 /net/socket.c:1656
[<
0000000008704b2a>] do_syscall_64+0x76/0x1a0 /arch/x86/entry/common.c:296
[<
000000009f4c57a4>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
30cc4587659e ("NFC: Move LLCP code to the NFC top level diirectory")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Fri, 4 Oct 2019 17:34:45 +0000 (10:34 -0700)]
sch_dsmark: fix potential NULL deref in dsmark_init()
Make sure TCA_DSMARK_INDICES was provided by the user.
syzbot reported :
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8799 Comm: syz-executor235 Not tainted 5.3.0+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:nla_get_u16 include/net/netlink.h:1501 [inline]
RIP: 0010:dsmark_init net/sched/sch_dsmark.c:364 [inline]
RIP: 0010:dsmark_init+0x193/0x640 net/sched/sch_dsmark.c:339
Code: 85 db 58 0f 88 7d 03 00 00 e8 e9 1a ac fb 48 8b 9d 70 ff ff ff 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 ca
RSP: 0018:
ffff88809426f3b8 EFLAGS:
00010247
RAX:
dffffc0000000000 RBX:
0000000000000000 RCX:
ffffffff85c6eb09
RDX:
0000000000000000 RSI:
ffffffff85c6eb17 RDI:
0000000000000004
RBP:
ffff88809426f4b0 R08:
ffff88808c4085c0 R09:
ffffed1015d26159
R10:
ffffed1015d26158 R11:
ffff8880ae930ac7 R12:
ffff8880a7e96940
R13:
dffffc0000000000 R14:
ffff88809426f8c0 R15:
0000000000000000
FS:
0000000001292880(0000) GS:
ffff8880ae900000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000020000080 CR3:
000000008ca1b000 CR4:
00000000001406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
qdisc_create+0x4ee/0x1210 net/sched/sch_api.c:1237
tc_modify_qdisc+0x524/0x1c50 net/sched/sch_api.c:1653
rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5223
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5241
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
___sys_sendmsg+0x803/0x920 net/socket.c:2311
__sys_sendmsg+0x105/0x1d0 net/socket.c:2356
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440369
Fixes:
758cc43c6d73 ("[PKT_SCHED]: Fix dsmark to apply changes consistent")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 5 Oct 2019 01:11:08 +0000 (18:11 -0700)]
Merge branch 'Fix-regression-with-AR8035-speed-downgrade'
Russell King says:
====================
Fix regression with AR8035 speed downgrade
The following series attempts to address an issue spotted by tinywrkb
with the AR8035 on the Cubox-i2 in a situation where the PHY downgrades
the negotiated link.
This is version 2, not much has changed other than rebasing on the
current net tree. Changes have happend to patch 2 due to conflicts,
so I dropped Andrew's reviewed-by. Minor context changes to patch 4
which I don't consider important enough to warrant dropping the
reviewed-by.
Before commit
5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
genphy_read_status"), we would read not only the link partner's
advertisement, but also our own advertisement from the PHY registers,
and use both to derive the PHYs current link mode. This works when the
AR8035 downgrades the speed, because it appears that the AR8035 clears
link mode bits in the advertisement registers as part of the downgrade.
Commentary: what is not yet known is whether the AR8035 restores the
advertisement register when the link goes down to the
previous state.
However, since the above referenced commit, we no longer use the PHYs
advertisement registers, instead converting the link partner's
advertisement to the ethtool link mode array, and combine that with
phylib's cached version of our advertisement - which is not updated on
speed downgrade.
This results in phylib disagreeing with the actual operating mode of
the PHY.
Commentary: I wonder how many more PHY drivers are broken by this
commit, but have yet to be discovered.
The obvious way to address this would be to disable the downgrade
feature, and indeed this does fix the problem in tinywrkb's case - his
link partner instead downgrades the speed by reducing its
advertisement, resulting in phylib correctly evaluating a slower speed.
However, it has a serious drawback - the gigabit control register (MII
register 9) appears to become read only. It seems the only way to
update the register is to re-enable the downgrade feature, reset the
PHY, changing register 9, disable the downgrade feature, and reset the
PHY again.
This series attempts to address the problem using a different approach,
similar to the approach taken with Marvell PHYs. The AR8031, AR8033
and AR8035 have a PHY-Specific Status register which reports the
actual operating mode of the PHY - both speed and duplex. This
register correctly reports the operating mode irrespective of whether
autoneg is enabled or not. We use this register to fill in phylib's
speed and duplex parameters.
In detail:
Patch 1 fixes a bug where writing to register 9 does not update
phylib's advertisement mask in the same way that writing register 4
does; this looks like an omission from when gigabit PHY support came
into being.
Patch 2 seperates the generic phylib code which reads the link partners
advertisement from the PHY, so that we can re-use this in the Atheros
PHY driver.
Patch 3 seperates the generic phylib pause mode; phylib provides no
help for MAC drivers to ascertain the negotiated pause mode, it merely
copies the link partner's pause mode bits into its own variables.
Commentary: Both the aforementioned Atheros PHYs and Marvell PHYs
provide the resolved pause modes in terms of whether
we should transmit pause frames, or whether we should
allow reception of pause frames. Surely the resolution
of this should be in phylib?
Patch 4 provides the Atheros PHY driver with a private "read_status"
implementation that fills in phylib's speed and duplex settings
depending on the PHY-Specific status register. This ensures that
phylib and the MAC driver match the operating mode that the PHY has
decided to use. Since the register also gives us MDIX status, we
can trivially fill that status in as well.
Note that, although the bits mentioned in this patch for this register
match those in th Marvell PHY driver, and it is located at the same
address, the meaning of other register bits varies between the PHYs.
Therefore, I do not feel that it would be appropriate to make this some
kind of generic function.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King [Fri, 4 Oct 2019 16:06:14 +0000 (17:06 +0100)]
net: phy: at803x: use operating parameters from PHY-specific status
Read the PHY-specific status register for the current operating mode
(speed and duplex) of the PHY. This register reflects the actual
mode that the PHY has resolved depending on either the advertisements
of autoneg is enabled, or the forced mode if autoneg is disabled.
This ensures that phylib's software state always tracks the hardware
state.
It seems both AR8033 (which uses the AR8031 ID) and AR8035 support
this status register. AR8030 is not known at the present time.
This patch depends on "net: phy: extract pause mode" and "net: phy:
extract link partner advertisement reading".
Reported-by: tinywrkb <tinywrkb@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: tinywrkb <tinywrkb@gmail.com>
Fixes:
5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King [Fri, 4 Oct 2019 16:06:09 +0000 (17:06 +0100)]
net: phy: extract pause mode
Extract the update of phylib's software pause mode state from
genphy_read_status(), so that we can re-use this functionality with
PHYs that have alternative ways to read the negotiation results.
Tested-by: tinywrkb <tinywrkb@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King [Fri, 4 Oct 2019 16:06:04 +0000 (17:06 +0100)]
net: phy: extract link partner advertisement reading
Move reading the link partner advertisement out of genphy_read_status()
into its own separate function. This will allow re-use of this code by
PHY drivers that are able to read the resolved status from the PHY.
Tested-by: tinywrkb <tinywrkb@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King [Fri, 4 Oct 2019 16:05:58 +0000 (17:05 +0100)]
net: phy: fix write to mii-ctrl1000 register
When userspace writes to the MII_ADVERTISE register, we update phylib's
advertising mask and trigger a renegotiation. However, writing to the
MII_CTRL1000 register, which contains the gigabit advertisement, does
neither. This can lead to phylib's copy of the advertisement becoming
de-synced with the values in the PHY register set, which can result in
incorrect negotiation resolution.
Fixes:
5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
David Ahern [Fri, 4 Oct 2019 15:03:09 +0000 (08:03 -0700)]
ipv6: Handle missing host route in __ipv6_ifa_notify
Rajendra reported a kernel panic when a link was taken down:
[ 6870.263084] BUG: unable to handle kernel NULL pointer dereference at
00000000000000a8
[ 6870.271856] IP: [<
ffffffff8efc5764>] __ipv6_ifa_notify+0x154/0x290
<snip>
[ 6870.570501] Call Trace:
[ 6870.573238] [<
ffffffff8efc58c6>] ? ipv6_ifa_notify+0x26/0x40
[ 6870.579665] [<
ffffffff8efc98ec>] ? addrconf_dad_completed+0x4c/0x2c0
[ 6870.586869] [<
ffffffff8efe70c6>] ? ipv6_dev_mc_inc+0x196/0x260
[ 6870.593491] [<
ffffffff8efc9c6a>] ? addrconf_dad_work+0x10a/0x430
[ 6870.600305] [<
ffffffff8f01ade4>] ? __switch_to_asm+0x34/0x70
[ 6870.606732] [<
ffffffff8ea93a7a>] ? process_one_work+0x18a/0x430
[ 6870.613449] [<
ffffffff8ea93d6d>] ? worker_thread+0x4d/0x490
[ 6870.619778] [<
ffffffff8ea93d20>] ? process_one_work+0x430/0x430
[ 6870.626495] [<
ffffffff8ea99dd9>] ? kthread+0xd9/0xf0
[ 6870.632145] [<
ffffffff8f01ade4>] ? __switch_to_asm+0x34/0x70
[ 6870.638573] [<
ffffffff8ea99d00>] ? kthread_park+0x60/0x60
[ 6870.644707] [<
ffffffff8f01ae77>] ? ret_from_fork+0x57/0x70
[ 6870.650936] Code: 31 c0 31 d2 41 b9 20 00 08 02 b9 09 00 00 0
addrconf_dad_work is kicked to be scheduled when a device is brought
up. There is a race between addrcond_dad_work getting scheduled and
taking the rtnl lock and a process taking the link down (under rtnl).
The latter removes the host route from the inet6_addr as part of
addrconf_ifdown which is run for NETDEV_DOWN. The former attempts
to use the host route in __ipv6_ifa_notify. If the down event removes
the host route due to the race to the rtnl, then the BUG listed above
occurs.
Since the DAD sequence can not be aborted, add a check for the missing
host route in __ipv6_ifa_notify. The only way this should happen is due
to the previously mentioned race. The host route is created when the
address is added to an interface; it is only removed on a down event
where the address is kept. Add a warning if the host route is missing
AND the device is up; this is a situation that should never happen.
Fixes:
f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Reported-by: Rajendra Dendukuri <rajendra.dendukuri@broadcom.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Andrea Merello [Fri, 4 Oct 2019 13:53:32 +0000 (15:53 +0200)]
net: phy: allow for reset line to be tied to a sleepy GPIO controller
mdio_device_reset() makes use of the atomic-pretending API flavor for
handling the PHY reset GPIO line.
I found no hint that mdio_device_reset() is called from atomic context
and indeed it uses usleep_range() since long time, so I would assume that
it is OK to sleep there.
This patch switch to gpiod_set_value_cansleep() in mdio_device_reset().
This is relevant if e.g. the PHY reset line is tied to a I2C GPIO
controller.
This has been tested on a ZynqMP board running an upstream 4.19 kernel and
then hand-ported on current kernel tree.
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Paolo Abeni [Fri, 4 Oct 2019 13:11:17 +0000 (15:11 +0200)]
net: ipv4: avoid mixed n_redirects and rate_tokens usage
Since commit
c09551c6ff7f ("net: ipv4: use a dedicated counter
for icmp_v4 redirect packets") we use 'n_redirects' to account
for redirect packets, but we still use 'rate_tokens' to compute
the redirect packets exponential backoff.
If the device sent to the relevant peer any ICMP error packet
after sending a redirect, it will also update 'rate_token' according
to the leaking bucket schema; typically 'rate_token' will raise
above BITS_PER_LONG and the redirect packets backoff algorithm
will produce undefined behavior.
Fix the issue using 'n_redirects' to compute the exponential backoff
in ip_rt_send_redirect().
Note that we still clear rate_tokens after a redirect silence period,
to avoid changing an established behaviour.
The root cause predates git history; before the mentioned commit in
the critical scenario, the kernel stopped sending redirects, after
the mentioned commit the behavior more randomic.
Reported-by: Xiumei Mu <xmu@redhat.com>
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes:
c09551c6ff7f ("net: ipv4: use a dedicated counter for icmp_v4 redirect packets")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Kai-Heng Feng [Fri, 4 Oct 2019 12:51:04 +0000 (20:51 +0800)]
r8152: Set macpassthru in reset_resume callback
r8152 may fail to establish network connection after resume from system
suspend.
If the USB port connects to r8152 lost its power during system suspend,
the MAC address was written before is lost. The reason is that The MAC
address doesn't get written again in its reset_resume callback.
So let's set MAC address again in reset_resume callback. Also remove
unnecessary lock as no other locking attempt will happen during
reset_resume.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vishal Kulkarni [Thu, 3 Oct 2019 22:36:15 +0000 (04:06 +0530)]
cxgb4:Fix out-of-bounds MSI-X info array access
When fetching free MSI-X vectors for ULDs, check for the error code
before accessing MSI-X info array. Otherwise, an out-of-bounds access is
attempted, which results in kernel panic.
Fixes:
94cdb8bb993a ("cxgb4: Add support for dynamic allocation of resources for ULD")
Signed-off-by: Shahjada Abul Husain <shahjada@chelsio.com>
Signed-off-by: Vishal Kulkarni <vishal@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David Ahern [Thu, 3 Oct 2019 21:46:15 +0000 (14:46 -0700)]
Revert "ipv6: Handle race in addrconf_dad_work"
This reverts commit
a3ce2a21bb8969ae27917281244fa91bf5f286d7.
Eric reported tests failings with commit. After digging into it,
the bottom line is that the DAD sequence is not to be messed with.
There are too many cases that are expected to proceed regardless
of whether a device is up.
Revert the patch and I will send a different solution for the
problem Rajendra reported.
Signed-off-by: David Ahern <dsahern@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alexey Dobriyan [Thu, 3 Oct 2019 21:44:40 +0000 (00:44 +0300)]
net: make sock_prot_memory_pressure() return "const char *"
This function returns string literals which are "const char *".
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David Howells [Thu, 3 Oct 2019 16:44:44 +0000 (17:44 +0100)]
rxrpc: Fix rxrpc_recvmsg tracepoint
Fix the rxrpc_recvmsg tracepoint to handle being called with a NULL call
parameter.
Fixes:
a25e21f0bcd2 ("rxrpc, afs: Use debug_ids rather than pointers in traces")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reinhard Speyerer [Thu, 3 Oct 2019 16:34:39 +0000 (18:34 +0200)]
qmi_wwan: add support for Cinterion CLS8 devices
Add support for Cinterion CLS8 devices.
Use QMI_QUIRK_SET_DTR as required for Qualcomm MDM9x07 chipsets.
T: Bus=01 Lev=03 Prnt=05 Port=01 Cnt=02 Dev#= 25 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1e2d ProdID=00b0 Rev= 3.18
S: Manufacturer=GEMALTO
S: Product=USB Modem
C:* #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Reinhard Speyerer <rspmn@arcor.de>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Fri, 4 Oct 2019 20:31:56 +0000 (13:31 -0700)]
Merge tag 'mips_fixes_5.4_1' of git://git./linux/kernel/git/mips/linux
Pull MIPS fixes from Paul Burton:
- Build fixes for Cavium Octeon & PMC-Sierra MSP systems, as well as
all pre-MIPSr6 configurations built with binutils < 2.25.
- Boot fixes for 64-bit Loongson systems & SGI IP28 systems.
- Wire up the new clone3 syscall.
- Clean ups for a few build-time warnings.
* tag 'mips_fixes_5.4_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: fw/arc: Remove unused addr variable
MIPS: pmcs-msp71xx: Remove unused addr variable
MIPS: pmcs-msp71xx: Add missing MAX_PROM_MEM definition
mips: Loongson: Fix the link time qualifier of 'serial_exit()'
MIPS: init: Prevent adding memory before PHYS_OFFSET
MIPS: init: Fix reservation of memory between PHYS_OFFSET and mem start
MIPS: VDSO: Fix build for binutils < 2.25
MIPS: VDSO: Remove unused gettimeofday.c
MIPS: Wire up clone3 syscall
MIPS: octeon: Include required header; fix octeon ethernet build
MIPS: cpu-bugs64: Mark inline functions as __always_inline
MIPS: dts: ar9331: fix interrupt-controller size
MIPS: Loongson64: Fix boot failure after dropping boot_mem_map
Linus Torvalds [Fri, 4 Oct 2019 20:02:47 +0000 (13:02 -0700)]
Merge tag 'riscv/for-v5.4-rc2' of git://git./linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
- Ensure that exclusive-load reservations are terminated after system
call or exception handling. This primarily affects QEMU, which does
not expire load reservations.
- Fix an issue primarily affecting RV32 platforms that can cause the DT
header to be corrupted, causing boot failures.
* tag 'riscv/for-v5.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: Fix memblock reservation for device tree blob
RISC-V: Clear load reservations while restoring hart contexts
Linus Torvalds [Fri, 4 Oct 2019 19:57:45 +0000 (12:57 -0700)]
Merge tag 'devicetree-fixes-for-5.4' of git://git./linux/kernel/git/robh/linux
Pull DeviceTree fixes from Rob Herring:
"Fix several 'dt_binding_check' build failures"
* tag 'devicetree-fixes-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
dt-bindings: phy: lantiq: Fix Property Name
dt-bindings: iio: ad7192: Fix DTC warning in the example
dt-bindings: iio: ad7192: Fix Regulator Properties
dt-bindings: media: rc: Fix redundant string
dt-bindings: dsp: Fix fsl,dsp example
Paul Burton [Fri, 4 Oct 2019 17:41:02 +0000 (17:41 +0000)]
MIPS: fw/arc: Remove unused addr variable
The addr variable in prom_free_prom_memory() has been unused since
commit
0df1007677d5 ("MIPS: fw: Record prom memory"), leading to a
compiler warning:
arch/mips/fw/arc/memory.c:163:16:
warning: unused variable 'addr' [-Wunused-variable]
Fix this by removing the unused variable.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes:
0df1007677d5 ("MIPS: fw: Record prom memory")
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: linux-mips@vger.kernel.org
Linus Torvalds [Fri, 4 Oct 2019 18:17:51 +0000 (11:17 -0700)]
Merge tag 'for-linus' of git://git./virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"ARM and x86 bugfixes of all kinds.
The most visible one is that migrating a nested hypervisor has always
been busted on Broadwell and newer processors, and that has finally
been fixed"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (22 commits)
KVM: x86: omit "impossible" pmu MSRs from MSR list
KVM: nVMX: Fix consistency check on injected exception error code
KVM: x86: omit absent pmu MSRs from MSR list
selftests: kvm: Fix libkvm build error
kvm: vmx: Limit guest PMCs to those supported on the host
kvm: x86, powerpc: do not allow clearing largepages debugfs entry
KVM: selftests: x86: clarify what is reported on KVM_GET_MSRS failure
KVM: VMX: Set VMENTER_L1D_FLUSH_NOT_REQUIRED if !X86_BUG_L1TF
selftests: kvm: add test for dirty logging inside nested guests
KVM: x86: fix nested guest live migration with PML
KVM: x86: assign two bits to track SPTE kinds
KVM: x86: Expose XSAVEERPTR to the guest
kvm: x86: Enumerate support for CLZERO instruction
kvm: x86: Use AMD CPUID semantics for AMD vCPUs
kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH
KVM: X86: Fix userspace set invalid CR4
kvm: x86: Fix a spurious -E2BIG in __do_cpuid_func
KVM: LAPIC: Loosen filter for adaptive tuning of lapic_timer_advance_ns
KVM: arm/arm64: vgic: Use the appropriate TRACE_INCLUDE_PATH
arm64: KVM: Kill hyp_alternate_select()
...
Linus Torvalds [Fri, 4 Oct 2019 18:13:09 +0000 (11:13 -0700)]
Merge tag 'for-linus-5.4-rc2-tag' of git://git./linux/kernel/git/xen/tip
Pull xen fixes and cleanups from Juergen Gross:
- a fix in the Xen balloon driver avoiding hitting a BUG_ON() in some
cases, plus a follow-on cleanup series for that driver
- a patch for introducing non-blocking EFI callbacks in Xen's EFI
driver, plu a cleanup patch for Xen EFI handling merging the x86 and
ARM arch specific initialization into the Xen EFI driver
- a fix of the Xen xenbus driver avoiding a self-deadlock when cleaning
up after a user process has died
- a fix for Xen on ARM after removal of ZONE_DMA
- a cleanup patch for avoiding build warnings for Xen on ARM
* tag 'for-linus-5.4-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/xenbus: fix self-deadlock after killing user process
xen/efi: have a common runtime setup function
arm: xen: mm: use __GPF_DMA32 for arm64
xen/balloon: Clear PG_offline in balloon_retrieve()
xen/balloon: Mark pages PG_offline in balloon_append()
xen/balloon: Drop __balloon_append()
xen/balloon: Set pages PageOffline() in balloon_add_region()
ARM: xen: unexport HYPERVISOR_platform_op function
xen/efi: Set nonblocking callbacks
Linus Torvalds [Fri, 4 Oct 2019 17:36:31 +0000 (10:36 -0700)]
Merge tag 'copy-struct-from-user-v5.4-rc2' of git://git./linux/kernel/git/brauner/linux
Pull copy_struct_from_user() helper from Christian Brauner:
"This contains the copy_struct_from_user() helper which got split out
from the openat2() patchset. It is a generic interface designed to
copy a struct from userspace.
The helper will be especially useful for structs versioned by size of
which we have quite a few. This allows for backwards compatibility,
i.e. an extended struct can be passed to an older kernel, or a legacy
struct can be passed to a newer kernel. For the first case (extended
struct, older kernel) the new fields in an extended struct can be set
to zero and the struct safely passed to an older kernel.
The most obvious benefit is that this helper lets us get rid of
duplicate code present in at least sched_setattr(), perf_event_open(),
and clone3(). More importantly it will also help to ensure that users
implementing versioning-by-size end up with the same core semantics.
This point is especially crucial since we have at least one case where
versioning-by-size is used but with slighly different semantics:
sched_setattr(), perf_event_open(), and clone3() all do do similar
checks to copy_struct_from_user() while rt_sigprocmask(2) always
rejects differently-sized struct arguments.
With this pull request we also switch over sched_setattr(),
perf_event_open(), and clone3() to use the new helper"
* tag 'copy-struct-from-user-v5.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
usercopy: Add parentheses around assignment in test_copy_struct_from_user
perf_event_open: switch to copy_struct_from_user()
sched_setattr: switch to copy_struct_from_user()
clone3: switch to copy_struct_from_user()
lib: introduce copy_struct_from_user() helper
Linus Torvalds [Fri, 4 Oct 2019 17:18:56 +0000 (10:18 -0700)]
Merge tag 'for-linus-
20191003' of git://git./linux/kernel/git/brauner/linux
Pull clone3/pidfd fixes from Christian Brauner:
"This contains a couple of fixes:
- Fix pidfd selftest compilation (Shuah Kahn)
Due to a false linking instruction in the Makefile compilation for
the pidfd selftests would fail on some systems.
- Fix compilation for glibc on RISC-V systems (Seth Forshee)
In some scenarios linux/uapi/linux/sched.h is included where
__ASSEMBLY__ is defined causing a build failure because struct
clone_args was not guarded by an #ifndef __ASSEMBLY__.
- Add missing clone3() and struct clone_args kernel-doc (Christian Brauner)
clone3() and struct clone_args were missing kernel-docs. (The goal
is to use kernel-doc for any function or type where it's worth it.)
For struct clone_args this also contains a comment about the fact
that it's versioned by size"
* tag 'for-linus-
20191003' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
sched: add kernel-doc for struct clone_args
fork: add kernel-doc for clone3
selftests: pidfd: Fix undefined reference to pthread_create()
sched: Add __ASSEMBLY__ guards around struct clone_args
Patrice Chotard [Fri, 4 Oct 2019 12:40:25 +0000 (14:40 +0200)]
ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI support
SPI_STM32_QSPI must be set in buildin as rootfs can be
located on QSPI memory device.
Link: https://lore.kernel.org/r/20191004124025.17394-1-patrice.chotard@st.com
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Linus Torvalds [Fri, 4 Oct 2019 17:12:37 +0000 (10:12 -0700)]
Merge tag 'drm-fixes-2019-10-04' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Been offline for 3 days, got back and had some fixes queued up.
Nothing too major, the i915 dp-mst fix is important, and amdgpu has a
bulk move speedup fix and some regressions, but nothing too insane for
an rc2 pull. The intel fixes are also 2 weeks worth, they missed the
boat last week.
core:
- writeback fixes
i915:
- Fix DP-MST crtc_mask
- Fix dsc dpp calculations
- Fix g4x sprite scaling stride check with GTT remapping
- Fix concurrence on cases where requests where getting retired at
same time as resubmitted to HW
- Fix gen9 display resolutions by setting the right max plane width
- Fix GPU hang on preemption
- Mark contents as dirty on a write fault. This was breaking cursor
sprite with dumb buffers.
komeda:
- memory leak fix
tilcdc:
- include fix
amdgpu:
- Enable bulk moves
- Power metrics fixes for Navi
- Fix S4 regression
- Add query for tcc disabled mask
- Fix several leaks in error paths
- randconfig fixes
- clang fixes"
* tag 'drm-fixes-2019-10-04' of git://anongit.freedesktop.org/drm/drm: (21 commits)
Revert "drm/i915: Fix DP-MST crtc_mask"
drm/omap: fix max fclk divider for omap36xx
drm/i915: Fix g4x sprite scaling stride check with GTT remapping
drm/i915/dp: Fix dsc bpp calculations, v5.
drm/amd/display: fix dcn21 Makefile for clang
drm/amd/display: hide an unused variable
drm/amdgpu: display_mode_vba_21: remove uint typedef
drm/amdgpu: hide another #warning
drm/amdgpu: make pmu support optional, again
drm/amd/display: memory leak
drm/amdgpu: fix multiple memory leaks in acp_hw_init
drm/amdgpu: return tcc_disabled_mask to userspace
drm/amdgpu: don't increment vram lost if we are in hibernation
Revert "drm/amdgpu: disable stutter mode for renoir"
drm/amd/powerplay: add sensor lock support for smu
drm/amd/powerplay: change metrics update period from 1ms to 100ms
drm/amdgpu: revert "disable bulk moves for now"
drm/tilcdc: include linux/pinctrl/consumer.h again
drm/komeda: prevent memory leak in komeda_wb_connector_add
drm: Clear the fence pointer when writeback job signaled
...
Linus Torvalds [Fri, 4 Oct 2019 16:56:51 +0000 (09:56 -0700)]
Merge tag 'for-linus-2019-10-03' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
- Mandate timespec64 for the io_uring timeout ABI (Arnd)
- Set of NVMe changes via Sagi:
- controller removal race fix from Balbir
- quirk additions from Gabriel and Jian-Hong
- nvme-pci power state save fix from Mario
- Add 64bit user commands (for 64bit registers) from Marta
- nvme-rdma/nvme-tcp fixes from Max, Mark and Me
- Minor cleanups and nits from James, Dan and John
- Two s390 dasd fixes (Jan, Stefan)
- Have loop change block size in DIO mode (Martijn)
- paride pg header ifdef guard (Masahiro)
- Two blk-mq queue scheduler tweaks, fixing an ordering issue on zoned
devices and suboptimal performance on others (Ming)
* tag 'for-linus-2019-10-03' of git://git.kernel.dk/linux-block: (22 commits)
block: sed-opal: fix sparse warning: convert __be64 data
block: sed-opal: fix sparse warning: obsolete array init.
block: pg: add header include guard
Revert "s390/dasd: Add discard support for ESE volumes"
s390/dasd: Fix error handling during online processing
io_uring: use __kernel_timespec in timeout ABI
loop: change queue block size to match when using DIO
blk-mq: apply normal plugging for HDD
blk-mq: honor IO scheduler for multiqueue devices
nvme-rdma: fix possible use-after-free in connect timeout
nvme: Move ctrl sqsize to generic space
nvme: Add ctrl attributes for queue_count and sqsize
nvme: allow 64-bit results in passthru commands
nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T
nvmet-tcp: remove superflous check on request sgl
Added QUIRKs for ADATA XPG SX8200 Pro 512GB
nvme-rdma: Fix max_hw_sectors calculation
nvme: fix an error code in nvme_init_subsystem()
nvme-pci: Save PCI state before putting drive into deepest state
nvme-tcp: fix wrong stop condition in io_work
...
Heiko Carstens [Fri, 4 Oct 2019 13:05:03 +0000 (15:05 +0200)]
s390: update defconfigs
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Heiko Carstens [Fri, 4 Oct 2019 10:29:43 +0000 (12:29 +0200)]
s390/pci: mark function(s) __always_inline
Always inline asm inlines with variable operands for "i" constraints,
since they won't compile if the compiler would decide to not inline
them.
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Heiko Carstens [Fri, 4 Oct 2019 10:29:37 +0000 (12:29 +0200)]
s390/mm: mark function(s) __always_inline
Always inline asm inlines with variable operands for "i" constraints,
since they won't compile if the compiler would decide to not inline
them.
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Heiko Carstens [Fri, 4 Oct 2019 10:29:18 +0000 (12:29 +0200)]
s390/jump_label: mark function(s) __always_inline
Always inline asm inlines with variable operands for "i" constraints,
since they won't compile if the compiler would decide to not inline
them.
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Heiko Carstens [Fri, 4 Oct 2019 10:29:00 +0000 (12:29 +0200)]
s390/cpu_mf: mark function(s) __always_inline
Always inline asm inlines with variable operands for "i" constraints,
since they won't compile if the compiler would decide to not inline
them.
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Heiko Carstens [Fri, 4 Oct 2019 10:28:43 +0000 (12:28 +0200)]
s390/atomic,bitops: mark function(s) __always_inline
Always inline asm inlines with variable operands for "i" constraints,
since they won't compile if the compiler would decide to not inline
them.
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Qian Cai [Thu, 3 Oct 2019 21:36:36 +0000 (17:36 -0400)]
s390/mm: fix -Wunused-but-set-variable warnings
Convert two functions to static inline to get ride of W=1 GCC warnings
like,
mm/gup.c: In function 'gup_pte_range':
mm/gup.c:1816:16: warning: variable 'ptem' set but not used
[-Wunused-but-set-variable]
pte_t *ptep, *ptem;
^~~~
mm/mmap.c: In function 'acct_stack_growth':
mm/mmap.c:2322:16: warning: variable 'new_start' set but not used
[-Wunused-but-set-variable]
unsigned long new_start;
^~~~~~~~~
Signed-off-by: Qian Cai <cai@lca.pw>
Link: https://lore.kernel.org/lkml/1570138596-11913-1-git-send-email-cai@lca.pw/
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Jiri Kosina [Tue, 1 Oct 2019 20:08:01 +0000 (22:08 +0200)]
s390: mark __cpacf_query() as __always_inline
arch/s390/kvm/kvm-s390.c calls on several places __cpacf_query() directly,
which makes it impossible to meet the "i" constraint for the asm operands
(opcode in this case).
As we are now force-enabling CONFIG_OPTIMIZE_INLINING on all
architectures, this causes a build failure on s390:
In file included from arch/s390/kvm/kvm-s390.c:44:
./arch/s390/include/asm/cpacf.h: In function '__cpacf_query':
./arch/s390/include/asm/cpacf.h:179:2: warning: asm operand 3 probably doesn't match constraints
179 | asm volatile(
| ^~~
./arch/s390/include/asm/cpacf.h:179:2: error: impossible constraint in 'asm'
Mark __cpacf_query() as __always_inline in order to fix that, analogically
how we fixes __cpacf_check_opcode(), cpacf_query_func() and scpacf_query()
already.
Reported-and-tested-by: Michal Kubecek <mkubecek@suse.cz>
Fixes:
d83623c5eab2 ("s390: mark __cpacf_check_opcode() and cpacf_query_func() as __always_inline")
Fixes:
e60fb8bf68d4 ("s390/cpacf: mark scpacf_query() as __always_inline")
Fixes:
ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly")
Fixes:
9012d011660e ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Link: https://lore.kernel.org/lkml/nycvar.YFH.7.76.1910012203010.13160@cbobk.fhfr.pm
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Paolo Bonzini [Tue, 1 Oct 2019 13:33:07 +0000 (15:33 +0200)]
KVM: x86: omit "impossible" pmu MSRs from MSR list
INTEL_PMC_MAX_GENERIC is currently 32, which exceeds the 18
contiguous MSR indices reserved by Intel for event selectors.
Since some machines actually have MSRs past the reserved range,
filtering them against x86_pmu.num_counters_gp may have false
positives. Cut the list to 18 entries to avoid this.
Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Jim Mattson <jamttson@google.com>
Fixes:
e2ada66ec418 ("kvm: x86: Add Intel PMU MSRs to msrs_to_save[]", 2019-08-21)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Dave Airlie [Fri, 4 Oct 2019 06:31:03 +0000 (16:31 +1000)]
Merge tag 'drm-intel-fixes-2019-10-03-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
- Fix DP-MST crtc_mask
- Fix dsc dpp calculations
- Fix g4x sprite scaling stride check with GTT remapping
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003193051.GA26421@intel.com
Dave Airlie [Fri, 4 Oct 2019 06:30:35 +0000 (16:30 +1000)]
Merge tag 'drm-misc-fixes-2019-10-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
- One include fix for tilcdc
- A clock fix for OMAP
- A memory leak fix for Komeda
- Some fixes for resources cleanups with writeback
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003081031.oykms5fg4tijvdri@gilmour
Dave Airlie [Fri, 4 Oct 2019 06:27:51 +0000 (16:27 +1000)]
Merge tag 'drm-fixes-5.4-2019-10-02' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
drm-fixes-5.4-2019-10-02:
amdgpu:
- Enable bulk moves
- Power metrics fixes for Navi
- Fix S4 regression
- Add query for tcc disabled mask
- Fix several leaks in error paths
- randconfig fixes
- clang fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002204909.3519-1-alexander.deucher@amd.com
Paul Burton [Thu, 3 Oct 2019 22:46:36 +0000 (22:46 +0000)]
MIPS: pmcs-msp71xx: Remove unused addr variable
The addr variable in prom_free_prom_memory() has been unused since
commit
b3c948e2c00f ("MIPS: msp: Record prom memory"), causing a warning
& build failure due to -Werror. Remove the unused variable.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes:
b3c948e2c00f ("MIPS: msp: Record prom memory")
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: linux-mips@vger.kernel.org
Paul Burton [Thu, 3 Oct 2019 22:46:23 +0000 (22:46 +0000)]
MIPS: pmcs-msp71xx: Add missing MAX_PROM_MEM definition
Commit
b3c948e2c00f ("MIPS: msp: Record prom memory") introduced use of
a MAX_PROM_MEM value but didn't define it. A bounds check in
prom_meminit() suggests its value was supposed to be 5, so define it as
such & adjust the bounds check to use the macro rather than a magic
number.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes:
b3c948e2c00f ("MIPS: msp: Record prom memory")
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: linux-mips@vger.kernel.org
Eric Sandeen [Wed, 2 Oct 2019 21:17:54 +0000 (16:17 -0500)]
vfs: Fix EOVERFLOW testing in put_compat_statfs64
Today, put_compat_statfs64() disallows nearly any field value over
2^32 if f_bsize is only 32 bits, but that makes no sense.
compat_statfs64 is there for the explicit purpose of providing 64-bit
fields for f_files, f_ffree, etc. And f_bsize is always only 32 bits.
As a result, 32-bit userspace gets -EOVERFLOW for i.e. large file
counts even with -D_FILE_OFFSET_BITS=64 set.
In reality, only f_bsize and f_frsize can legitimately overflow
(fields like f_type and f_namelen should never be large), so test
only those fields.
This bug was discussed at length some time ago, and this is the proposal
Al suggested at https://lkml.org/lkml/2018/8/6/640. It seemed to get
dropped amid the discussion of other related changes, but this
part seems obviously correct on its own, so I've picked it up and
sent it, for expediency.
Fixes:
64d2ab32efe3 ("vfs: fix put_compat_statfs64() does not handle errors")
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Randy Dunlap [Thu, 3 Oct 2019 02:23:15 +0000 (19:23 -0700)]
block: sed-opal: fix sparse warning: convert __be64 data
sparse warns about incorrect type when using __be64 data.
It is not being converted to CPU-endian but it should be.
Fixes these sparse warnings:
../block/sed-opal.c:375:20: warning: incorrect type in assignment (different base types)
../block/sed-opal.c:375:20: expected unsigned long long [usertype] align
../block/sed-opal.c:375:20: got restricted __be64 const [usertype] alignment_granularity
../block/sed-opal.c:376:25: warning: incorrect type in assignment (different base types)
../block/sed-opal.c:376:25: expected unsigned long long [usertype] lowest_lba
../block/sed-opal.c:376:25: got restricted __be64 const [usertype] lowest_aligned_lba
Fixes:
455a7b238cd6 ("block: Add Sed-opal library")
Cc: Scott Bauer <scott.bauer@intel.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: linux-block@vger.kernel.org
Reviewed-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Randy Dunlap [Thu, 3 Oct 2019 02:23:05 +0000 (19:23 -0700)]
block: sed-opal: fix sparse warning: obsolete array init.
Fix sparse warning: (missing '=')
../block/sed-opal.c:133:17: warning: obsolete array initializer, use C99 syntax
Fixes:
ff91064ea37c ("block: sed-opal: check size of shadow mbr")
Cc: linux-block@vger.kernel.org
Cc: Jonas Rabenstein <jonas.rabenstein@studium.uni-erlangen.de>
Cc: David Kozub <zub@linux.fjfi.cvut.cz>
Reviewed-by: Scott Bauer <sbauer@plzdonthack.me>
Reviewed-by: Revanth Rajashekar <revanth.rajashekar@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Ville Syrjälä [Tue, 3 Sep 2019 15:40:18 +0000 (18:40 +0300)]
Revert "drm/i915: Fix DP-MST crtc_mask"
This reverts commit
4eaceea3a00f8e936a7f48dcd0c975a57f88930f.
Several userspace clients (modesetting ddx and mutter+wayland at least)
handle encoder.possible_crtcs incorrectly. What they essentially do is
the following:
possible_crtcs = ~0;
for_each_possible_encoder(connector)
possible_crtcs &= encoder->possible_crtcs;
Ie. they calculate the intersection of the possible_crtcs
for the connector when they really should be calculating the
union instead.
In our case each MST encoder now has just one unique bit set,
and so the intersection is always zero. The end result is that
MST connectors can't be lit up because no crtc can be found to
drive them.
I've submitted a fix for the modesetting ddx [1], and complained
on #wayland about mutter, so hopefully the situation will improve
in the future. In the meantime we have regression, and so must go
back to the old way of misconfiguring possible_crtcs in the kernel.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277
Cc: Jonas Ådahl <jadahl@gmail.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111507
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190903154018.26357-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit
e838bfa8e170415fa3cc8e83ecb171e809c0c422)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>