[PATCH v1] clk: tegra20: Add 216 MHz entry for PLL_X
The cpufreq driver uses 216 MHz as the lowest CPU clock frequency, but
clock driver doesn't provide that rate, so the requested clock is rounded
up to 312 MHz. Let's add entry for 216 MHz to match with cpufreq.
Signed-off-by: Dmitry Osipenko
---
drivers/clk/tegra/clk-tegra20.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index cbd5a2e5c569..e33d7548a4e9 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -269,6 +269,11 @@ static struct tegra_clk_pll_freq_table pll_x_freq_table[]
= {
{ 1300, 31200, 312, 13, 1, 12 },
{ 1920, 31200, 260, 16, 1, 8 },
{ 2600, 31200, 312, 26, 1, 12 },
+ /* 216 MHz */
+ { 1200, 21600, 216, 12, 1, 12 },
+ { 1300, 21600, 216, 13, 1, 12 },
+ { 1920, 21600, 180, 16, 1, 8 },
+ { 2600, 21600, 216, 26, 1, 12 },
{0, 0,0, 0, 0, 0 },
};
--
2.15.1
[PATCH v1 2/2] clk: tegra20: Correct PLL_C_OUT1 setup
PLL_C_OUT_1 can't produce 216 MHz defined in the init_table. Let's
set it to 240 MHz and explicitly specify HCLK rate for consistency.
Signed-off-by: Dmitry Osipenko
---
drivers/clk/tegra/clk-tegra20.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 32763dfbfaba..c39e7e2446d8 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -1026,9 +1026,9 @@ static struct tegra_clk_init_table init_table[]
__initdata = {
{ TEGRA20_CLK_PLL_P_OUT3, TEGRA20_CLK_CLK_MAX, 7200, 0 },
{ TEGRA20_CLK_PLL_P_OUT4, TEGRA20_CLK_CLK_MAX, 2400, 0 },
{ TEGRA20_CLK_PLL_C, TEGRA20_CLK_CLK_MAX, 6, 0 },
- { TEGRA20_CLK_PLL_C_OUT1, TEGRA20_CLK_CLK_MAX, 21600, 0 },
- { TEGRA20_CLK_SCLK, TEGRA20_CLK_PLL_C_OUT1, 0, 0 },
- { TEGRA20_CLK_HCLK, TEGRA20_CLK_CLK_MAX, 0, 0 },
+ { TEGRA20_CLK_PLL_C_OUT1, TEGRA20_CLK_CLK_MAX, 24000, 0 },
+ { TEGRA20_CLK_SCLK, TEGRA20_CLK_PLL_C_OUT1, 24000, 0 },
+ { TEGRA20_CLK_HCLK, TEGRA20_CLK_CLK_MAX, 24000, 0 },
{ TEGRA20_CLK_PCLK, TEGRA20_CLK_CLK_MAX, 6000, 0 },
{ TEGRA20_CLK_CSITE, TEGRA20_CLK_CLK_MAX, 0, 1 },
{ TEGRA20_CLK_CCLK, TEGRA20_CLK_CLK_MAX, 0, 1 },
--
2.15.1
Re: general protection fault in strcmp
On Thu, Nov 30, 2017 at 12:44:01PM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup: exact-subject-of-another-report > If it's a one-off invalid bug report, please reply with: > #syz invalid > Note: if the crash happens again, it will cause creation of a new > bug report. > Note: all commands must start from beginning of the line in the email body. > #syz fix: KEYS: reject NULL restriction string when type is specified
Re: Linux 4.15-rc3 (uml + bpf_perf_event.h)
On 12/11/2017 10:49 AM, Richard Weinberger wrote: > Am Montag, 11. Dezember 2017, 11:19:54 CET schrieb Daniel Borkmann: >> Hi Randy, hi Richard, [ +Hendrik for c895f6f703ad7dd2f ] >> >> On 12/11/2017 09:32 AM, Richard Weinberger wrote: >>> Randy, >>> >>> Am Montag, 11. Dezember 2017, 03:42:12 CET schrieb Randy Dunlap: On 12/10/2017 06:08 PM, Linus Torvalds wrote: > Another week, another rc. um (uml) won't build on i386 or x86_64: CC init/main.o In file included from ../include/linux/perf_event.h:18:0, from ../include/linux/trace_events.h:10, from ../include/trace/syscall.h:7, from ../include/linux/syscalls.h:82, from ../init/main.c:20: ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error: asm/bpf_perf_event.h: No such file or directory #include ^ compilation terminated. ../scripts/Makefile.build:310: recipe for target 'init/main.o' failed >>> >>> How do you trigger that build failure? >>> Can you share your .config? >> >> Hmm, too bad kbuild bot doesn't catch issues on uml. I'm not too familiar >> with uml, but looks like it's the only special case where there's no >> arch/um/include/uapi/asm/. What is the usual convention to pull in such >> headers in this case? Something like the below, would that fix it for you? >> >> Thanks for your help, >> Daniel >> >> arch/um/include/asm/bpf_perf_event.h | 1 + >> include/asm-generic/bpf_perf_event.h | 1 + >> 2 files changed, 2 insertions(+) >> create mode 100644 arch/um/include/asm/bpf_perf_event.h >> create mode 100644 include/asm-generic/bpf_perf_event.h >> >> diff --git a/arch/um/include/asm/bpf_perf_event.h >> b/arch/um/include/asm/bpf_perf_event.h new file mode 100644 >> index 000..3097758 >> --- /dev/null >> +++ b/arch/um/include/asm/bpf_perf_event.h >> @@ -0,0 +1 @@ >> +#include >> diff --git a/include/asm-generic/bpf_perf_event.h >> b/include/asm-generic/bpf_perf_event.h new file mode 100644 >> index 000..67112e5 >> --- /dev/null >> +++ b/include/asm-generic/bpf_perf_event.h >> @@ -0,0 +1 @@ >> +#include > > Hmm, what about this? > > diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild > index 50a32c33d729..fb35ec000433 100644 > --- a/arch/um/include/asm/Kbuild > +++ b/arch/um/include/asm/Kbuild > @@ -27,3 +27,4 @@ generic-y += trace_clock.h > generic-y += word-at-a-time.h > generic-y += xor.h > generic-y += kprobes.h > +generic-y += bpf_perf_event.h > That also works for arch/um. thanks, -- ~Randy
RE: [PATCH v2] Enable SR-IOV instantiation through /sys file
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Monday, December 11, 2017 1:13 PM
> To: Wang, Liang-min
> Cc: Alexander Duyck ; Kirsher, Jeffrey T
> ; k...@vger.kernel.org; linux-
> p...@vger.kernel.org; linux-kernel@vger.kernel.org; Bjorn Helgaas
> ; Duyck, Alexander H
> Subject: Re: [PATCH v2] Enable SR-IOV instantiation through /sys file
>
> On Mon, 11 Dec 2017 14:22:30 +
> "Wang, Liang-min" wrote:
>
> > > -Original Message-
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Friday, December 08, 2017 6:35 PM
> > > To: Alexander Duyck
> > > Cc: Kirsher, Jeffrey T ; Wang, Liang-min
> > > min.w...@intel.com>; k...@vger.kernel.org; linux-...@vger.kernel.org;
> linux-
> > > ker...@vger.kernel.org; Bjorn Helgaas ; Duyck,
> > > Alexander H
> > > Subject: Re: [PATCH v2] Enable SR-IOV instantiation through /sys file
> > >
> > > On Fri, 8 Dec 2017 15:19:18 -0800
> > > Alexander Duyck wrote:
> > >
> > > > On Fri, Dec 8, 2017 at 2:58 PM, Alex Williamson
> > > > wrote:
> > > > > On Fri, 8 Dec 2017 13:47:58 -0800
> > > > > Jeff Kirsher wrote:
> > > > >
> > > > >> From: Liang-Min Wang
> > > > >>
> > > > >> When a SR-IOV capable device is bound with vfio-pci, the
> > > > >> device loses capability of creating SR-IOV instances through /sy/bus/
> > > > >> pci/devices/.../sriov_numvfs. This patch re-activates this capability
> > > > >> for a PCIe device that is SR-IOV capable and is bound with
> > > > >> vfio-pci.ko.
> > > > >> This patch also disables drivers_autoprobe attribute of SR-IOV
> > > > >> devices
> > > > >> created from vfio-pci bound device by default, so user-space PF
> > > > >> device
> > > > >> can coordinate the bring-up of SR-IOV devices
> > > > >>
> > > > >> Signed-off-by: Liang-Min Wang
> > > > >> ---
> > > > >> drivers/pci/pci-driver.c| 12
> > > > >> drivers/vfio/pci/vfio_pci.c | 22 ++
> > > > >> include/linux/pci.h | 1 +
> > > > >> 3 files changed, 35 insertions(+)
> > > > >>
> > > > >> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> > > > >> index 7f47bb7..19522fe 100644
> > > > >> --- a/drivers/pci/pci-driver.c
> > > > >> +++ b/drivers/pci/pci-driver.c
> > > > >> @@ -1467,6 +1467,18 @@ void pci_dev_put(struct pci_dev *dev)
> > > > >> }
> > > > >> EXPORT_SYMBOL(pci_dev_put);
> > > > >>
> > > > >> +/**
> > > > >> + * pci_dev_sriov_autoprobe_set - set device sriov driver autoprobe
> > > > >> + * @dev: device with which sriov autoprobe will be set
> > > > >> + *
> > > > >> + */
> > > > >> +void pci_dev_sriov_autoprobe_set(struct pci_dev *dev, bool
> autoprobe)
> > > > >> +{
> > > > >> + if (dev && dev->sriov)
> > > > >> + dev->sriov->drivers_autoprobe = autoprobe;
> > > > >> +}
> > > > >> +EXPORT_SYMBOL(pci_dev_sriov_autoprobe_set);
> > > > >
> > > > > _GPL?
> > > > >
> > > > > It'd also be best to separate the pci and vfio changes into different
> > > > > patches. Bjorn would need to at least ack this PCI interface.
> > > > >
> > > > >> +
> > > > >> static int pci_uevent(struct device *dev, struct kobj_uevent_env
> > > > >> *env)
> > > > >> {
> > > > >> struct pci_dev *pdev;
> > > > >> diff --git a/drivers/vfio/pci/vfio_pci.c
> > > > >> b/drivers/vfio/pci/vfio_pci.c
> > > > >> index f041b1a..004836c 100644
> > > > >> --- a/drivers/vfio/pci/vfio_pci.c
> > > > >> +++ b/drivers/vfio/pci/vfio_pci.c
> > > > >> @@ -1213,6 +1213,8 @@ static int vfio_pci_probe(struct pci_dev
> *pdev,
> > > const struct pci_device_id *id)
> > > > >> return -ENOMEM;
> > > > >> }
> > > > >>
> > > > >> + /* disable sriov automatic driver attachment */
> > > > >> + pci_dev_sriov_autoprobe_set(pdev, false);
> > > > >
> > > > > This looks stateful, VF autoprobe is not restored on release. Also,
> > > > > how would we know the initial state to restore it to?
> > > >
> > > > The initial state is whatever the user set it to. It is something that
> > > > can be toggled on and off via sysfs, and it defaults to true at
> > > > initialization. In this case we are opting to toggle it off when VFIO
> > > > is attached to the device. Restoring it after unloading the driver
> > > > might be even more confusing since it is something the user could
> > > > toggle at any time so a restore would end up overwriting that.
> > >
> > > I'm not really willing to sign up for the inevitable bug reports when
> > > users can't figure out how to make their VFs work again in the host
> > > after they've used the PF for userspace drivers with vfio-pci. I
> > > agree, both options are confusing, how do we make it not confusing?
> > > Can PCI core reset the autoprobe attribute to the default at some
> > > obvious point? Thanks,
> > >
> >
> > I would like to confirm the scenario discussed here is to unload PF driver,
> right?
> > Since users need to release all SR-IOV from PF driver first before PF
> > driver is
> > released, does
Re: [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
Hi gengdongjiu Sorry for the late response. I have a similar patch to add the support for "FHM", which I was about to post it this week. On 11/12/17 13:29, Dave Martin wrote: On Mon, Dec 11, 2017 at 08:47:00PM +0800, gengdongjiu wrote: On 2017/12/11 19:59, Dave P Martin wrote: On Sat, Dec 09, 2017 at 03:28:42PM +, Dongjiu Geng wrote: ARM v8.4 extensions include support for new floating point multiplication variant instructions to the AArch64 SIMD Do we have any human-readable description of what the new instructions do? Since the v8.4 spec itself only describes these as "New Floating Point Multiplication Variant", I wonder what "FHM" actually stands for. Thanks for the point out. In fact, this feature only adds two instructions: FP16 * FP16 + FP32 FP16 * FP16 - FP32 The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it will call "FHM", I think call it "FMLXL" may be better, which can stand for FMLAL/FMLSL instructions. Although "FHM" is cryptic, I think it makes sense to keep this as "FHM" to match the ISAR0 field name -- we've tended to follow this policy for other extension names unless there's a much better or more obvious name available. For "FMLXL", new instructions might be added in the future that match the same pattern, and then "FMLXL" could become ambiguous. So maybe this is not the best choice. I think the FHM stands for "FP Half precision Multiplication instructions". I vote for keeping the feature bit in sync with the register bit definition. i.e, FHM. However, my version of the patch names the HWCAP bit "asimdfml", following the compiler name for the feature option "fp16fml", which is not perfect either. I think FHM is the safe option here. Maybe something like "widening half-precision floating-point multiply accumulate" is acceptable wording consistent with the existing architecture, but I just made that up, so it's not official ;) how about something like "performing a multiplication of each FP16 element of one vector with the corresponding FP16 element of a second vector, and to add or subtract this without an intermediate rounding to the corresponding FP32 element in a third vector."? We could have that, I guess. I agree, and that matches the feature description.
[PATCH 3/4] ASoC: codecs: tas5720: add TAS5722 specific volume control
From: Andreas Dannenberg
The TAS5722 supports modifying volume in 0.25dB steps (as opposed to 0.5dB
steps on the TAS5720). Introduce a custom mixer control that allows taking
advantage of this finer output volume granularity.
Signed-off-by: Andreas Dannenberg
Signed-off-by: Andrew F. Davis
---
sound/soc/codecs/tas5720.c | 88 +++---
1 file changed, 83 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/tas5720.c b/sound/soc/codecs/tas5720.c
index f3006f301fe8..042068964afb 100644
--- a/sound/soc/codecs/tas5720.c
+++ b/sound/soc/codecs/tas5720.c
@@ -491,11 +491,59 @@ static const DECLARE_TLV_DB_RANGE(dac_analog_tlv,
* setting the gain below -100 dB (register value <0x7) is effectively a MUTE
* as per device datasheet.
*/
-static DECLARE_TLV_DB_SCALE(dac_tlv, -10350, 50, 0);
+static DECLARE_TLV_DB_SCALE(tas5720_dac_tlv, -10350, 50, 0);
+
static const struct snd_kcontrol_new tas5720_snd_controls[] = {
SOC_SINGLE_TLV("Speaker Driver Playback Volume",
- TAS5720_VOLUME_CTRL_REG, 0, 0xff, 0, dac_tlv),
+ TAS5720_VOLUME_CTRL_REG, 0, 0xff, 0, tas5720_dac_tlv),
+ SOC_SINGLE_TLV("Speaker Driver Analog Gain", TAS5720_ANALOG_CTRL_REG,
+ TAS5720_ANALOG_GAIN_SHIFT, 3, 0, dac_analog_tlv),
+};
+
+/*
+ * DAC digital volumes. From -103.5 to 24 dB in 0.25 dB steps. Note that
+ * setting the gain below -100 dB (register value <0x8) is effectively a MUTE
+ * as per device datasheet.
+ *
+ * Note that for the TAS5722 the digital volume controls are actually split
+ * over two registers, so we need custom getters/setters for access.
+ */
+static DECLARE_TLV_DB_SCALE(tas5722_dac_tlv, -10350, 25, 0);
+
+static int tas5722_volume_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
+ unsigned int val;
+
+ val = snd_soc_read(codec, TAS5720_VOLUME_CTRL_REG);
+ ucontrol->value.integer.value[0] = val << 1;
+
+ val = snd_soc_read(codec, TAS5722_DIGITAL_CTRL2_REG);
+ ucontrol->value.integer.value[0] |= val & TAS5722_VOL_CONTROL_LSB;
+
+ return 0;
+}
+
+static int tas5722_volume_set(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
+ unsigned int sel = ucontrol->value.integer.value[0];
+
+ snd_soc_write(codec, TAS5720_VOLUME_CTRL_REG, sel >> 1);
+ snd_soc_update_bits(codec, TAS5722_DIGITAL_CTRL2_REG,
+ TAS5722_VOL_CONTROL_LSB, sel);
+
+ return 0;
+}
+
+static const struct snd_kcontrol_new tas5722_snd_controls[] = {
+ SOC_SINGLE_EXT_TLV("Speaker Driver Playback Volume",
+ 0, 0, 511, 0,
+ tas5722_volume_get, tas5722_volume_set,
+ tas5722_dac_tlv),
SOC_SINGLE_TLV("Speaker Driver Analog Gain", TAS5720_ANALOG_CTRL_REG,
TAS5720_ANALOG_GAIN_SHIFT, 3, 0, dac_analog_tlv),
};
@@ -528,6 +576,22 @@ static const struct snd_soc_codec_driver
soc_codec_dev_tas5720 = {
},
};
+static struct snd_soc_codec_driver soc_codec_dev_tas5722 = {
+ .probe = tas5720_codec_probe,
+ .remove = tas5720_codec_remove,
+ .suspend = tas5720_suspend,
+ .resume = tas5720_resume,
+
+ .component_driver = {
+ .controls = tas5722_snd_controls,
+ .num_controls = ARRAY_SIZE(tas5722_snd_controls),
+ .dapm_widgets = tas5720_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(tas5720_dapm_widgets),
+ .dapm_routes = tas5720_audio_map,
+ .num_dapm_routes = ARRAY_SIZE(tas5720_audio_map),
+ }
+};
+
/* PCM rates supported by the TAS5720 driver */
#define TAS5720_RATES (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |\
SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000)
@@ -614,9 +678,23 @@ static int tas5720_probe(struct i2c_client *client,
dev_set_drvdata(dev, data);
- ret = snd_soc_register_codec(&client->dev,
-&soc_codec_dev_tas5720,
-tas5720_dai, ARRAY_SIZE(tas5720_dai));
+ switch (id->driver_data) {
+ case TAS5720:
+ ret = snd_soc_register_codec(&client->dev,
+&soc_codec_dev_tas5720,
+tas5720_dai,
+ARRAY_SIZE(tas5720_dai));
+ break;
+ case TAS5722:
+ ret = snd_soc_register_codec(&client->dev,
+&soc_codec_dev_tas5722,
+tas5720_dai,
+ARRAY_SIZE(tas5720_dai));
+
[PATCH 4/4] ASoC: codecs: tas5720: add TAS5722 TDM slot width setting support
From: Andreas Dannenberg
Unlike the TAS5720, the TAS5722 can be configured to utilize 16-bit wide
slots in TDM mode. This can help easing audio clocking/frequency
requirements.
Signed-off-by: Andreas Dannenberg
Signed-off-by: Andrew F. Davis
---
sound/soc/codecs/tas5720.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/soc/codecs/tas5720.c b/sound/soc/codecs/tas5720.c
index 042068964afb..08e0bfc9390c 100644
--- a/sound/soc/codecs/tas5720.c
+++ b/sound/soc/codecs/tas5720.c
@@ -152,6 +152,7 @@ static int tas5720_set_dai_tdm_slot(struct snd_soc_dai *dai,
int slots, int slot_width)
{
struct snd_soc_codec *codec = dai->codec;
+ struct tas5720_data *tas5720 = snd_soc_codec_get_drvdata(codec);
unsigned int first_slot;
int ret;
@@ -185,6 +186,16 @@ static int tas5720_set_dai_tdm_slot(struct snd_soc_dai
*dai,
if (ret < 0)
goto error_snd_soc_update_bits;
+ /* Configure TDM slot width. This is only applicable to TAS5722. */
+ if (tas5720->devtype == TAS5722) {
+ ret = snd_soc_update_bits(codec, TAS5722_DIGITAL_CTRL2_REG,
+ TAS5722_TDM_SLOT_16B,
+ slot_width == 16 ?
+ TAS5722_TDM_SLOT_16B : 0);
+ if (ret < 0)
+ goto error_snd_soc_update_bits;
+ }
+
return 0;
error_snd_soc_update_bits:
--
2.15.0
[PATCH 1/4] ASoC: codecs: tas5720: add basic support for TAS5722 devices
From: Andreas Dannenberg
The TI TAS5722 digital amplifier is very similar to the TAS5720 from an
overall and register map perspective. Therefore the existing driver can be
extended easily to support this additional device. This commit allows
TAS5722 devices to be used in a "subset" type of fashion, without exposing
any of the additional features they offer.
Signed-off-by: Andreas Dannenberg
Signed-off-by: Andrew F. Davis
---
.../devicetree/bindings/sound/tas5720.txt | 4 ++-
sound/soc/codecs/tas5720.c | 38 ++
sound/soc/codecs/tas5720.h | 1 +
3 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/tas5720.txt
b/Documentation/devicetree/bindings/sound/tas5720.txt
index 40d94f82beb3..7481653fe8e3 100644
--- a/Documentation/devicetree/bindings/sound/tas5720.txt
+++ b/Documentation/devicetree/bindings/sound/tas5720.txt
@@ -6,10 +6,12 @@ audio playback. For more product information please see the
links below:
http://www.ti.com/product/TAS5720L
http://www.ti.com/product/TAS5720M
+http://www.ti.com/product/TAS5722L
Required properties:
-- compatible : "ti,tas5720"
+- compatible : "ti,tas5720",
+ "ti,tas5722"
- reg : I2C slave address
- dvdd-supply : phandle to a 3.3-V supply for the digital circuitry
- pvdd-supply : phandle to a supply used for the Class-D amp and the analog
diff --git a/sound/soc/codecs/tas5720.c b/sound/soc/codecs/tas5720.c
index a736a2a6976c..5def54d1336d 100644
--- a/sound/soc/codecs/tas5720.c
+++ b/sound/soc/codecs/tas5720.c
@@ -36,6 +36,11 @@
/* Define how often to check (and clear) the fault status register (in ms) */
#define TAS5720_FAULT_CHECK_INTERVAL 200
+enum tas572x_type {
+ TAS5720,
+ TAS5722,
+};
+
static const char * const tas5720_supply_names[] = {
"dvdd", /* Digital power supply. Connect to 3.3-V supply. */
"pvdd", /* Class-D amp and analog power supply (connected). */
@@ -47,6 +52,7 @@ struct tas5720_data {
struct snd_soc_codec *codec;
struct regmap *regmap;
struct i2c_client *tas5720_client;
+ enum tas572x_type devtype;
struct regulator_bulk_data supplies[TAS5720_NUM_SUPPLIES];
struct delayed_work fault_check_work;
unsigned int last_fault;
@@ -264,7 +270,7 @@ static void tas5720_fault_check_work(struct work_struct
*work)
static int tas5720_codec_probe(struct snd_soc_codec *codec)
{
struct tas5720_data *tas5720 = snd_soc_codec_get_drvdata(codec);
- unsigned int device_id;
+ unsigned int device_id, expected_device_id;
int ret;
tas5720->codec = codec;
@@ -276,6 +282,11 @@ static int tas5720_codec_probe(struct snd_soc_codec *codec)
return ret;
}
+ /*
+* Take a liberal approach to checking the device ID to allow the
+* driver to be used even if the device ID does not match, however
+* issue a warning if there is a mismatch.
+*/
ret = regmap_read(tas5720->regmap, TAS5720_DEVICE_ID_REG, &device_id);
if (ret < 0) {
dev_err(codec->dev, "failed to read device ID register: %d\n",
@@ -283,13 +294,22 @@ static int tas5720_codec_probe(struct snd_soc_codec
*codec)
goto probe_fail;
}
- if (device_id != TAS5720_DEVICE_ID) {
- dev_err(codec->dev, "wrong device ID. expected: %u read: %u\n",
- TAS5720_DEVICE_ID, device_id);
- ret = -ENODEV;
- goto probe_fail;
+ switch (tas5720->devtype) {
+ case TAS5720:
+ expected_device_id = TAS5720_DEVICE_ID;
+ break;
+ case TAS5722:
+ expected_device_id = TAS5722_DEVICE_ID;
+ break;
+ default:
+ dev_err(codec->dev, "unexpected private driver data\n");
+ return -EINVAL;
}
+ if (device_id != expected_device_id)
+ dev_warn(codec->dev, "wrong device ID. expected: %u read: %u\n",
+expected_device_id, device_id);
+
/* Set device to mute */
ret = snd_soc_update_bits(codec, TAS5720_DIGITAL_CTRL2_REG,
TAS5720_MUTE, TAS5720_MUTE);
@@ -552,6 +572,8 @@ static int tas5720_probe(struct i2c_client *client,
return -ENOMEM;
data->tas5720_client = client;
+ data->devtype = id->driver_data;
+
data->regmap = devm_regmap_init_i2c(client, &tas5720_regmap_config);
if (IS_ERR(data->regmap)) {
ret = PTR_ERR(data->regmap);
@@ -592,7 +614,8 @@ static int tas5720_remove(struct i2c_client *client)
}
static const struct i2c_device_id tas5720_id[] = {
- { "tas5720", 0 },
+ { "tas5720", TAS5720 },
+ { "tas5722", TAS5722 },
{ }
};
MODULE_DEVICE_TABLE(i2c, tas5720_id);
@@ -600,6 +623,7 @@ MO
[PATCH] ASoC: nau8825: fix issue that pop noise when start capture
From: Abhijeet Kumar
In skylake platform, we hear a loud pop noise(0 dB) at start of
audio capture power up sequence. This patch removes the pop noise
from the recording by adding a delay before enabling ADC.
Signed-off-by: Abhijeet Kumar
---
sound/soc/codecs/nau8825.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/nau8825.c b/sound/soc/codecs/nau8825.c
index 714ce17da717..e853a6dfd33b 100644
--- a/sound/soc/codecs/nau8825.c
+++ b/sound/soc/codecs/nau8825.c
@@ -905,6 +905,7 @@ static int nau8825_adc_event(struct snd_soc_dapm_widget *w,
switch (event) {
case SND_SOC_DAPM_POST_PMU:
+ msleep(125);
regmap_update_bits(nau8825->regmap, NAU8825_REG_ENA_CTRL,
NAU8825_ENABLE_ADC, NAU8825_ENABLE_ADC);
break;
--
1.9.1
[PATCH 2/4] ASoC: codecs: tas5720: add TAS5722 register support
From: Andreas Dannenberg
Introduce a custom super-set register map and associated bit definitions
to allow driver access to all TAS5722 device functionality.
Signed-off-by: Andreas Dannenberg
Signed-off-by: Andrew F. Davis
---
sound/soc/codecs/tas5720.c | 23 ++-
sound/soc/codecs/tas5720.h | 30 ++
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/tas5720.c b/sound/soc/codecs/tas5720.c
index 5def54d1336d..f3006f301fe8 100644
--- a/sound/soc/codecs/tas5720.c
+++ b/sound/soc/codecs/tas5720.c
@@ -466,6 +466,15 @@ static const struct regmap_config tas5720_regmap_config = {
.volatile_reg = tas5720_is_volatile_reg,
};
+static const struct regmap_config tas5722_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = TAS5722_MAX_REG,
+ .cache_type = REGCACHE_RBTREE,
+ .volatile_reg = tas5720_is_volatile_reg,
+};
+
/*
* DAC analog gain. There are four discrete values to select from, ranging
* from 19.2 dB to 26.3dB.
@@ -564,6 +573,7 @@ static int tas5720_probe(struct i2c_client *client,
{
struct device *dev = &client->dev;
struct tas5720_data *data;
+ const struct regmap_config *regmap_config;
int ret;
int i;
@@ -574,7 +584,18 @@ static int tas5720_probe(struct i2c_client *client,
data->tas5720_client = client;
data->devtype = id->driver_data;
- data->regmap = devm_regmap_init_i2c(client, &tas5720_regmap_config);
+ switch (id->driver_data) {
+ case TAS5720:
+ regmap_config = &tas5720_regmap_config;
+ break;
+ case TAS5722:
+ regmap_config = &tas5722_regmap_config;
+ break;
+ default:
+ dev_err(dev, "unexpected private driver data\n");
+ return -EINVAL;
+ }
+ data->regmap = devm_regmap_init_i2c(client, regmap_config);
if (IS_ERR(data->regmap)) {
ret = PTR_ERR(data->regmap);
dev_err(dev, "failed to allocate register map: %d\n", ret);
diff --git a/sound/soc/codecs/tas5720.h b/sound/soc/codecs/tas5720.h
index bef802afcc69..1dda3095961d 100644
--- a/sound/soc/codecs/tas5720.h
+++ b/sound/soc/codecs/tas5720.h
@@ -30,6 +30,11 @@
#define TAS5720_DIGITAL_CLIP1_REG 0x11
#define TAS5720_MAX_REGTAS5720_DIGITAL_CLIP1_REG
+/* Additional TAS5722-specific Registers */
+#define TAS5722_DIGITAL_CTRL2_REG 0x13
+#define TAS5722_ANALOG_CTRL2_REG 0x14
+#define TAS5722_MAX_REGTAS5722_ANALOG_CTRL2_REG
+
/* TAS5720_DEVICE_ID_REG */
#define TAS5720_DEVICE_ID 0x01
#define TAS5722_DEVICE_ID 0x12
@@ -52,6 +57,7 @@
#define TAS5720_SAIF_FORMAT_MASK GENMASK(2, 0)
/* TAS5720_DIGITAL_CTRL2_REG */
+#define TAS5722_VOL_RAMP_RATE BIT(6)
#define TAS5720_MUTE BIT(4)
#define TAS5720_TDM_SLOT_SEL_MASK GENMASK(2, 0)
@@ -88,4 +94,28 @@
#define TAS5720_CLIP1_MASK GENMASK(7, 2)
#define TAS5720_CLIP1_SHIFT(0x2)
+/* TAS5722_DIGITAL_CTRL2_REG */
+#define TAS5722_HPF_3_7HZ (0x0 << 5)
+#define TAS5722_HPF_7_4HZ (0x1 << 5)
+#define TAS5722_HPF_14_9HZ (0x2 << 5)
+#define TAS5722_HPF_29_7HZ (0x3 << 5)
+#define TAS5722_HPF_59_4HZ (0x4 << 5)
+#define TAS5722_HPF_118_4HZ(0x5 << 5)
+#define TAS5722_HPF_235_0HZ(0x6 << 5)
+#define TAS5722_HPF_463_2HZ(0x7 << 5)
+#define TAS5722_HPF_MASK GENMASK(7, 5)
+#define TAS5722_AUTO_SLEEP_OFF (0x0 << 3)
+#define TAS5722_AUTO_SLEEP_1024LR (0x1 << 3)
+#define TAS5722_AUTO_SLEEP_65536LR (0x2 << 3)
+#define TAS5722_AUTO_SLEEP_262144LR(0x3 << 3)
+#define TAS5722_AUTO_SLEEP_MASKGENMASK(4, 3)
+#define TAS5722_TDM_SLOT_16B BIT(2)
+#define TAS5722_MCLK_PIN_CFG BIT(1)
+#define TAS5722_VOL_CONTROL_LSBBIT(0)
+
+/* TAS5722_ANALOG_CTRL2_REG */
+#define TAS5722_FAULTZ_PU BIT(3)
+#define TAS5722_VREG_LVL BIT(2)
+#define TAS5722_PWR_TUNE BIT(0)
+
#endif /* __TAS5720_H__ */
--
2.15.0
Re: KASAN: use-after-free Write in aead_recvmsg
On Mon, Dec 04, 2017 at 07:57:01AM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > If you want to test a patch for this bug, please reply with: > #syz test: git://repo/address.git branch > and provide the patch inline or as an attachment. > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup: exact-subject-of-another-report > If it's a one-off invalid bug report, please reply with: > #syz invalid > Note: if the crash happens again, it will cause creation of a new > bug report. > Note: all commands must start from beginning of the line in the email body. > #syz fix: crypto: af_alg - fix race accessing cipher request
Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)
On 12/11/2017 09:01 AM, David Miller wrote: > From: Jiri Pirko > Date: Mon, 11 Dec 2017 17:32:46 +0100 > >> I think that it does not make sense to convert ethtool->netlink_ethtool >> 1:1 feature wise. Now we have devlink, ritch switch representation >> model, tc offload and many others. Lot of things that are in >> ethtool, should be done in devlink. Also, there are couple of things >> that should just die - nice example is ethtool --config-ntuple - we >> should use tc for that. > > Whilst I do agree that devlink is probably a good place for this stuff > (we want to be able to do ethetool things on objects that lack a netdev) > I do not agree with the tc angle. > > It is entirely appropriate to set the ntuple settings of a driver > without being required to use TC or similar. > > All you are going to do with your suggestion is make people keep using > the existing ethtool ioctl, because they'll say "screw this, I'm not > using TC I have something which works just fine already". And that's > not the goal of putting this stuff into netlink, we want people to > use the new facilities and move off of the ioctl. I agree, we can't walk away from that feature today, there are many more drivers implementing ethtool::ntuple (counting 22) than there are implementing cls_flower (counting 6), also they are not strictly equivalent feature wise, one thing critically missing in cls_flower (last I looked) is the ability to either auto-place (RX_CLS_LOC_ANY) a matching rule, or select a particular location. For specifying what to match in a packet and how, cls_flower is superior. We can probably advise people not to use that feature and request their driver provider to switch over to cls_flower, but considering how many more LOCs are needed in the driver to implement that (as opposed to ethtool ntuple), I just don't see it being something people will be thrilled to do. Writing a shim that converts from ethtool ntuple to the equivalent in kernel space representation of the same call through cls_flower would be reasonably easy, but same thing, that still requires migrating your kernel driver over to the cls_flower interface, which is the harder part. That being said, we should probably discourage implementing both for new drivers, since they are likely to use the same centralized HW resources towards the same goals: match + actions, with no visibility into one another (can't see rules set-up in ethtool via cls_flower and vice versa) and that just sucks. -- Florian
Re: [ANNOUNCE] 4.1.46-rt52
On 11/29/2017 05:13 PM, Julia Cartwright wrote:
Hello RT Folks!
I'm pleased to announce the 4.1.46-rt52 stable release.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v4.1-rt
Head SHA1: 6e737a91c1ce923d4e10db831e14cfef9a2459cc
Or to build 4.1.46-rt52 directly, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.1.tar.xz
http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.1.46.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/4.1/patch-4.1.46-rt52.patch.xz
You can also build from 4.1.46-rt51 by applying the incremental patch:
http://www.kernel.org/pub/linux/kernel/projects/rt/4.1/incr/patch-4.1.46-rt51-rt52.patch.xz
Enjoy!
Julia
Changes from v4.1.46-rt51:
---
Julia Cartwright (2):
workqueue: fixup rcu check for RT
Linux 4.1.46-rt52
Sebastian Andrzej Siewior (2):
PM / CPU: replace raw_notifier with atomic_notifier (fixup)
This change breaks the compile of 4.1 on ARM (and other things using
kernel/cpu_pm.c).
rcu_irq_enter_irqson() and friends doesn't exist in 4.1. In fact,
rcu_irq_enter() doesn't even exist.
Sorry I didn't get to testing this earlier, I've been focused on other things.
-corey
kernel/hrtimer: migrate deferred timer on CPU down
---
kernel/cpu_pm.c | 7 +++
kernel/time/hrtimer.c | 5 +
kernel/workqueue.c| 2 +-
localversion-rt | 2 +-
4 files changed, 14 insertions(+), 2 deletions(-)
---
diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c
index 9da42f83ee03..d1d1c3961553 100644
--- a/kernel/cpu_pm.c
+++ b/kernel/cpu_pm.c
@@ -28,8 +28,15 @@ static int cpu_pm_notify(enum cpu_pm_event event, int
nr_to_call, int *nr_calls)
{
int ret;
+ /*
+* __atomic_notifier_call_chain has a RCU read critical section, which
+* could be disfunctional in cpu idle. Copy RCU_NONIDLE code to let
+* RCU know this.
+*/
+ rcu_irq_enter_irqson();
ret = __atomic_notifier_call_chain(&cpu_pm_notifier_chain, event, NULL,
nr_to_call, nr_calls);
+ rcu_irq_exit_irqson();
return notifier_to_errno(ret);
}
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 2c6be169bdc7..75c990b00525 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1951,6 +1951,11 @@ static void migrate_hrtimer_list(struct
hrtimer_clock_base *old_base,
/* Clear the migration state bit */
timer->state &= ~HRTIMER_STATE_MIGRATE;
}
+#ifdef CONFIG_PREEMPT_RT_BASE
+ list_splice_tail(&old_base->expired, &new_base->expired);
+ if (!list_empty(&new_base->expired))
+ raise_softirq_irqoff(HRTIMER_SOFTIRQ);
+#endif
}
static void migrate_hrtimers(int scpu)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 6bdcab98501c..90e261c8811e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -363,7 +363,7 @@ static void workqueue_sysfs_unregister(struct
workqueue_struct *wq);
"RCU or wq->mutex should be held")
#define assert_rcu_or_wq_mutex_or_pool_mutex(wq) \
- rcu_lockdep_assert(rcu_read_lock_sched_held() ||\
+ rcu_lockdep_assert(rcu_read_lock_held() || \
lockdep_is_held(&wq->mutex) ||\
lockdep_is_held(&wq_pool_mutex), \
"sched RCU, wq->mutex or wq_pool_mutex should be
held")
diff --git a/localversion-rt b/localversion-rt
index 75493460c41f..66a5ed8bf3d7 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt51
+-rt52
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 27/45] net: remove duplicate includes
On Mon, Dec 11, 2017 at 10:09:46PM +0530, Pravin Shedge wrote: > These duplicate includes have been found with scripts/checkincludes.pl but > they have been removed manually to avoid removing false positives. > > Signed-off-by: Pravin Shedge For the Netfilter chunk. Acked-by: Pablo Neira Ayuso Thanks.
Re: [PATCH v10 3/4] [media] platform: Add Synopsys DesignWare HDMI RX PHY e405 Driver
On Mon, Dec 11, 2017 at 6:41 PM, Jose Abreu wrote: > This adds support for the Synopsys DesignWare HDMI RX PHY e405. This > phy receives and decodes HDMI video that is delivered to a controller. > > Main features included in this driver are: > - Equalizer algorithm that chooses the phy best settings > according to the detected HDMI cable characteristics. > - Support for scrambling > - Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz). > > The driver was implemented as a standalone V4L2 subdevice and the > phy interface with the controller was implemented using V4L2 ioctls. I > do not know if this is the best option but it is not possible to use the > existing API functions directly as we need specific functions that will > be called by the controller at specific configuration stages. > > There is also a bidirectional communication between controller and phy: > The phy must provide functions that the controller will call (i.e. > configuration functions) and the controller must provide read/write > callbacks, as well as other specific functions. > > Signed-off-by: Jose Abreu > Cc: Joao Pinto > Cc: Mauro Carvalho Chehab > Cc: Hans Verkuil > Cc: Sylwester Nawrocki > Cc: Philippe Ombredanne > --- > Changes from v9: > - Use SPDX License ID (Philippe) Acked-by: Philippe Ombredanne Thanks! -- Cordially Philippe Ombredanne
Re: general protection fault in crypto_chacha20_crypt
On Wed, Nov 29, 2017 at 01:24:38AM -0800, Eric Biggers wrote: > > The bug is that the skcipher_walk API doesn't set the IV for zero-length > inputs, > while some algorithms (e.g. ChaCha20) access the IV even if the input is > zero-length. So it was dereferencing a pointer which came from uninitialized > stack memory. I've sent out a fix: > > "crypto: skcipher - set walk.iv for zero-length inputs" > #syz fix: crypto: skcipher - set walk.iv for zero-length inputs
Re: [PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver
On Mon, Dec 11, 2017 at 6:41 PM, Jose Abreu wrote: > This is an initial submission for the Synopsys DesignWare HDMI RX > Controller Driver. This driver interacts with a phy driver so that > a communication between them is created and a video pipeline is > configured. > > The controller + phy pipeline can then be integrated into a fully > featured system that can be able to receive video up to 4k@60Hz > with deep color 48bit RGB, depending on the platform. Although, > this initial version does not yet handle deep color modes. > > This driver was implemented as a standard V4L2 subdevice and its > main features are: > - Internal state machine that reconfigures phy until the > video is not stable > - JTAG communication with phy > - Inter-module communication with phy driver > - Debug write/read ioctls > > Some notes: > - RX sense controller (cable connection/disconnection) must > be handled by the platform wrapper as this is not integrated > into the controller RTL > - The same goes for EDID ROM's > - ZCAL calibration is needed only in FPGA platforms, in ASIC > this is not needed > - The state machine is not an ideal solution as it creates a > kthread but it is needed because some sources might not be > very stable at sending the video (i.e. we must react > accordingly). > > Signed-off-by: Jose Abreu > Cc: Joao Pinto > Cc: Mauro Carvalho Chehab > Cc: Hans Verkuil > Cc: Sylwester Nawrocki > Cc: Sakari Ailus > Cc: Philippe Ombredanne > --- > Changes from v9: > - Use SPDX License ID (Philippe) Acked-by: Philippe Ombredanne
Re: general protection fault in blkcipher_walk_done
On Mon, Nov 27, 2017 at 10:56:47AM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > If you want to test a patch for this bug, please reply with: > #syz test: git://repo/address.git branch > and provide the patch inline or as an attachment. > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup: exact-subject-of-another-report > If it's a one-off invalid bug report, please reply with: > #syz invalid > Note: if the crash happens again, it will cause creation of a new > bug report. > Note: all commands must start from beginning of the line in the email body. #syz fix: crypto: af_alg - wait for data at beginning of recvmsg
Re: [PATCH] Fix resume on x86-32 machines
On Mon, Dec 11, 2017 at 10:41 AM, Andy Lutomirski wrote: > > I'll try to get to this in a day or so -- is that okay? Or should we > do some trivial fix/revert and fix it for real next time around? I don't think we want some trivial fix/revert just to keep it working. This code is too fragile as-is, and I think that "make it work" is more than reverting. You did fix real issues on x86-64 with odd segment use, for example. Linus
[PATCH] net: igmp: Use correct source address on IGMPv3 reports
Closing a multicast socket after the final IPv4 address is deleted
from an interface can generate a membership report that uses the
source IP from a different interface. The following test script, run
from an isolated netns, reproduces the issue:
#!/bin/bash
ip link add dummy0 type dummy
ip link add dummy1 type dummy
ip link set dummy0 up
ip link set dummy1 up
ip addr add 10.1.1.1/24 dev dummy0
ip addr add 192.168.99.99/24 dev dummy1
tcpdump -U -i dummy0 &
socat EXEC:"sleep 2" \
UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1 &
sleep 1
ip addr del 10.1.1.1/24 dev dummy0
sleep 5
kill %tcpdump
RFC 3376 specifies that the report must be sent with a valid IP source
address from the destination subnet, or from address 0.0.0.0. Add an
extra check to make sure this is the case.
Signed-off-by: Kevin Cernekee
---
net/ipv4/igmp.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index d1f8f302dbf3..0672264c9d93 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -89,6 +89,7 @@
#include
#include
#include
+#include
#include
#include
@@ -321,6 +322,23 @@ igmp_scount(struct ip_mc_list *pmc, int type, int
gdeleted, int sdeleted)
return scount;
}
+/* source address selection per RFC 3376 section 4.2.13 */
+static __be32 igmpv3_get_srcaddr(struct net_device *dev,
+const struct flowi4 *fl4)
+{
+ struct in_device *in_dev = __in_dev_get_rcu(dev);
+
+ if (!in_dev)
+ return htonl(INADDR_ANY);
+
+ for_ifa(in_dev) {
+ if (inet_ifa_match(fl4->saddr, ifa))
+ return fl4->saddr;
+ } endfor_ifa(in_dev);
+
+ return htonl(INADDR_ANY);
+}
+
static struct sk_buff *igmpv3_newpack(struct net_device *dev, unsigned int mtu)
{
struct sk_buff *skb;
@@ -368,7 +386,7 @@ static struct sk_buff *igmpv3_newpack(struct net_device
*dev, unsigned int mtu)
pip->frag_off = htons(IP_DF);
pip->ttl = 1;
pip->daddr= fl4.daddr;
- pip->saddr= fl4.saddr;
+ pip->saddr= igmpv3_get_srcaddr(dev, &fl4);
pip->protocol = IPPROTO_IGMP;
pip->tot_len = 0; /* filled in later */
ip_select_ident(net, skb, NULL);
--
2.15.1.424.g9478a66081-goog
RE: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()
From: Logan Gunthorpe > mw_get_align doesn't communicate the fact that the buffer has to be > aligned by its size. Is that not the purpose of the addr_align out parameter of ntb_mw_get_align()? > It may also be that all hardware does not have this > restriction (ie. if the hardware adds to the base address instead of > just replacing the lower bits). > > There is definitely a need to print this error somewhere as I hit this > case and it caused very weird behavior. It was a huge pain to debug. > Also, it's a security issue and huge bug if we end up mapping the memory > we didn't think we were mapping. Of course the driver should validate its parameters not allow bad mappings. I was only commenting on the dev_err() message to the console. What makes best sense for client drivers with regards to ntb api changes is a fair argument. Let's see what others say. > I don't think it's a good idea for us > to require clients to check this as that requires a number of checks and > a client author may forget to add it to their driver. I'd maybe go with > a check in ntb_mw_set_trans before calling the driver, but that only > makes sense if all hardware has the same requirement. > > Logan
Re: [kernel-hardening][PATCH] arm: hw_breakpoint: Mark variables as __ro_after_init
On Mon, Dec 11, 2017 at 4:50 AM, Jinbum Park wrote: > core_num_brps, core_num_wrps, debug_arch, has_ossr, > max_watchpoint_len are setup once while init stage, > and never changed after that. > so it is good candidate for __ro_after_init. > > Signed-off-by: Jinbum Park Reviewed-by: Kees Cook (Probably good to toss this into the ARM patch tracker.) -Kees > --- > arch/arm/kernel/hw_breakpoint.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c > index af2a7f1..629e251 100644 > --- a/arch/arm/kernel/hw_breakpoint.c > +++ b/arch/arm/kernel/hw_breakpoint.c > @@ -44,17 +44,17 @@ > static DEFINE_PER_CPU(struct perf_event *, wp_on_reg[ARM_MAX_WRP]); > > /* Number of BRP/WRP registers on this CPU. */ > -static int core_num_brps; > -static int core_num_wrps; > +static int core_num_brps __ro_after_init; > +static int core_num_wrps __ro_after_init; > > /* Debug architecture version. */ > -static u8 debug_arch; > +static u8 debug_arch __ro_after_init; > > /* Does debug architecture support OS Save and Restore? */ > -static bool has_ossr; > +static bool has_ossr __ro_after_init; > > /* Maximum supported watchpoint length. */ > -static u8 max_watchpoint_len; > +static u8 max_watchpoint_len __ro_after_init; > > #define READ_WB_REG_CASE(OP2, M, VAL) \ > case ((OP2 << 4) + M): \ > -- > 1.9.1 > -- Kees Cook Pixel Security
Re: [PATCH 16/20] ARM: dts: aspeed: Add Witherspoon BMC machine
On Sun, Dec 10, 2017 at 11:07 PM, Joel Stanley wrote:
> The Witherspoon BMC is an ASPEED ast2500 based BMC that is part of an
> OpenPower Power9 server.
>
> This adds the device tree description for most upstream components. It
> is a squashed commit from the OpenBMC kernel tree.
>
> Signed-off-by: Brandon Wyman
> Signed-off-by: Matt Spinler
> Signed-off-by: Brad Bishop
> Signed-off-by: Edward A. James
> Signed-off-by: Cédric Le Goater
> Signed-off-by: Andrew Jeffery
> Signed-off-by: Joel Stanley
> ---
> arch/arm/boot/dts/Makefile | 4 +-
> arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 547
> +++
> 2 files changed, 550 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5d1e9d37bf3a..15a9207319c1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1104,5 +1104,7 @@ dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
> dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-ast2500-evb.dtb \
> aspeed-bmc-opp-palmetto.dtb \
> - aspeed-bmc-opp-romulus.dtb
> + aspeed-bmc-opp-romulus.dtb \
> + aspeed-bmc-opp-witherspoon.dtb
> +
> endif
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
> new file mode 100644
> index ..9a0937512e5b
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
> @@ -0,0 +1,547 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +#include "aspeed-g5.dtsi"
> +#include
> +
> +/ {
> + model = "Witherspoon BMC";
> + compatible = "ibm,witherspoon-bmc", "aspeed,ast2500";
> +
> + chosen {
> + stdout-path = &uart5;
> + bootargs = "console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory {
> + reg = <0x8000 0x2000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <1000>;
> +
> + fan0-presence {
> + label = "fan0-presence";
> + gpios = <&pca0 4 GPIO_ACTIVE_LOW>;
> + linux,code = <4>;
> + };
> +
> + fan1-presence {
> + label = "fan1-presence";
> + gpios = <&pca0 5 GPIO_ACTIVE_LOW>;
> + linux,code = <5>;
> + };
> +
> + fan2-presence {
> + label = "fan2-presence";
> + gpios = <&pca0 6 GPIO_ACTIVE_LOW>;
> + linux,code = <6>;
> + };
> +
> + fan3-presence {
> + label = "fan3-presence";
> + gpios = <&pca0 7 GPIO_ACTIVE_LOW>;
> + linux,code = <7>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fan0 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan1 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 1 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan2 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan3 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + front-fault {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + front-power {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 14 GPIO_ACTIVE_LOW>;
> + };
> +
> + front-id {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca0 15 GPIO_ACTIVE_LOW>;
> + };
> +
> + rear-fault {
> + gpio
Re: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()
On 11/12/17 12:17 PM, Allen Hubbe wrote: From: Logan Gunthorpe mw_get_align doesn't communicate the fact that the buffer has to be aligned by its size. Is that not the purpose of the addr_align out parameter of ntb_mw_get_align()? addr_align provides the minimum alignment required by the device but it has no idea how big a buffer the caller is trying to create so it can't express that it needs to be aligned by its size. To be clear, the minimum alignment the Switchtec device requires is 4KB so it will return 4k in addr_align. Thus, if you have a 4KB buffer it may be aligned to 4KB. But if you have a 1MB buffer it must be aligned to the nearest 1M. It may also be that all hardware does not have this restriction (ie. if the hardware adds to the base address instead of just replacing the lower bits). There is definitely a need to print this error somewhere as I hit this case and it caused very weird behavior. It was a huge pain to debug. Also, it's a security issue and huge bug if we end up mapping the memory we didn't think we were mapping. Of course the driver should validate its parameters not allow bad mappings. I was only commenting on the dev_err() message to the console. Ok. I still feel like it would be difficult to debug if ntb_transport simply was unable to establish a connection without some message in dmesg telling the user why. Also, keep in mind this is a somewhat unusual occurrence. In most cases dma_alloc_coherent() always provides a buffer that is aligned to it's size. It's just that the CMA (if used) provides a tunable config option which allows for larger buffers to not be aligned to their size. Logan
Re: Oops on 4.15-rc[123] on shutdown/reboot
On 11/12/17 17:24, Sinan Kaya wrote: > On 12/11/2017 12:06 PM, Chris Clayton wrote: >> Here's the output of dmesg for 4.15.0-rc3. I'll open a bugzilla later and >> add this and the lspci output that I sent with >> my original repoart. > > This was helpful. I don't see any AER/DPC in your log. It looks like the only > PCIe > portdrv service you have is PME. > > Can we do a quick hack and return immediately from > > static int pcie_pme_probe(struct pcie_device *srv) > > by putting return 0; at the top. > > Same thing in > > static void pcie_pme_remove(struct pcie_device *srv) > > just place a return at the top. > I made those changes (to drivers/pci/pcie/pme.c) and built and installed the kernel. Sorry, but I still get the oops when I reboot. > I'm hoping your problem will go away after this. Then, we can start peeling > the onion. >
Re: [RFC][PATCH] ipc: mqueue: wq_add priority changed to dynamic priority
On Mon, 11 Dec 2017 17:12:05 +
Jonathan Haws wrote:
> Adding linux-rt-users group to thread.
>
> From: Jonathan Haws
> Sent: Monday, December 11, 2017 08:37
> To: mi...@kernel.org; v...@zeniv.linux.org.uk; a...@arndb.de;
> a...@linux-foundation.org; deepa.ker...@gmail.com
> Cc: linux-kernel@vger.kernel.org; t...@linutronix.de; bige...@linutronix.de;
> rost...@goodmis.org; Jonathan Haws
> Subject: [RFC][PATCH] ipc: mqueue: wq_add priority changed to dynamic priority
>
> Previous behavior added tasks to the work queue using the static_prio value
> instead of the dynamic priority value in prio. This caused RT tasks to be
> added to the work queue in a FIFO manner rather than by priority. Normal
> tasks were handled by priority.
>
> This fix utilizes the dynamic priority of the task to ensure that both RT
> and normal tasks are added to the work queue in priority order. Utilizing
> the dynamic priority (prio) rather than the base priority (normal_prio) was
> chosen to ensure that if a task had a boosted priority when it was added to
> the work queue, it would be woken sooner to to ensure that it releases any
> other locks it may be holding in a more timely manner. It is understood that
> the task could have a lower priority when it wakes than when it was added to
> the queue in this (unlikely) case.
Probably a better subject would be:
ipc: mqueue: Have RT tasks queue in by priority in wq_add()
Other than that (and that this doesn't handle DL tasks),
Reviewed-by: Steven Rostedt (VMware)
-- Steve
>
> Signed-off-by: Jonathan Haws
> ---
> ipc/mqueue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> index 9649ecd..cb96db9 100644
> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -546,7 +546,7 @@ static void wq_add(struct mqueue_inode_info *info, int sr,
> ewp->task = current;
>
> list_for_each_entry(walk, &info->e_wait_q[sr].list, list) {
> - if (walk->task->static_prio <= current->static_prio) {
> + if (walk->task->prio <= current->prio) {
> list_add_tail(&ewp->list, &walk->list);
> return;
> }
> --
> 2.7.4
>
Re: [PATCH PTI v2 6/6] x86/pti: Put the LDT in its own PGD if PTI is on
On 12/11/2017 10:40 AM, Andy Lutomirski wrote: >> Also, from a high level, this does increase the overhead of KPTI in a >> non-trivial way, right? It costs us three more page table pages per >> process allocated at fork() and freed at exit() and a new TLB flush. > Yeah, but no one will care. modify_ldt() is used for DOSEMU, Wine, > and really old 32-bit programs. The heavyweight part of map_ldt_struct() (and unmap) looks to run whenever we have KPTI enabled. I'm missing how it gets avoided for the non-DOSEMU cases. I thought there would be a "fast path" where we just use the normal clear_LDT() LDT from the cpu_entry_area and don't have to do any of this, but I'm missing where that happens. Do we need a check in (un)map_ldt_struct() for !mm->context.ldt? Just to make sure I understand this: We now have two places that LDTs live in virtual space: 1. The "plain" one that we get from clear_LDT() which lives in the cpu_entry_area. (No additional overhead when doing this) 2. The new one under the special PGD that's only used for modify_ldt() and is fairly slow. (plenty of overhead, but nobody cares).
Re: [PATCH] sched/rt: Do not pull from current CPU if only one cpu to pull
On Mon, 11 Dec 2017 17:47:32 +0100
Ingo Molnar wrote:
> > Link:
> > http://lkml.kernel.org/r/8c913cc2-b2e3-8c2e-e503-aff1428f8...@monom.org
> > Fixes: 4bdced5c9 ("sched/rt: Simplify the IPI based RT balancing logic")
> > Cc: sta...@vger.kernel.org
> > Reported-by: Daniel Wagner
>
> I've added:
>
> Signed-off-by: Steven Rostedt (VMware)
>
> Which I suspect you just forgot to add?
Ug, not sure how that happened, but yes, I simply forgot to add that
(probably did it using quilt and expected to use git commit -s)
Thanks Ingo!
-- Steve
Re: [PATCH] tuners: tda8290: reduce stack usage with kasan
On Mon, 2017-12-11 at 13:06 +0100, Arnd Bergmann wrote:
> With CONFIG_KASAN enabled, we get a relatively large stack frame in one
> function
>
> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
> drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes
> is larger than 1024 bytes [-Wframe-larger-than=]
>
> With CONFIG_KASAN_EXTRA this goes up to
>
> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
> drivers/media/tuners/tda8290.c:310:1: error: the frame size of 3200 bytes is
> larger than 3072 bytes [-Werror=frame-larger-than=]
>
> We can significantly reduce this by marking local arrays as 'static const',
> and
> this should result in better compiled code for everyone.
[]
> diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
[]
> @@ -63,8 +63,8 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe, int
> close)
> {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> - unsigned char enable[2] = { 0x21, 0xC0 };
> - unsigned char disable[2] = { 0x21, 0x00 };
> + static unsigned char enable[2] = { 0x21, 0xC0 };
> + static unsigned char disable[2] = { 0x21, 0x00 };
Doesn't match commit message.
static const or just static?
> @@ -84,9 +84,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int
> close)
> {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> - unsigned char enable[2] = { 0x45, 0xc1 };
> - unsigned char disable[2] = { 0x46, 0x00 };
> - unsigned char buf[3] = { 0x45, 0x01, 0x00 };
> + static unsigned char enable[2] = { 0x45, 0xc1 };
> + static unsigned char disable[2] = { 0x46, 0x00 };
etc.
Re: [PATCH 0/4] Sunxi: Add SMP support on A83T
On Mon, Dec 11, 2017 at 08:49:57AM +0100, Mylène Josserand wrote: > Hello everyone, > > This series adds SMP support for Allwinner Sun8i-a83t > with MCPM (Multi-Cluster Power Management). > Series information: > - Based on last linux-next (next-20171211) > - Had dependencies on Chen Yu's patch that add MCPM > support: > https://patchwork.kernel.org/patch/6402801/ > > Patch 01: Convert the mcpm driver (initially for A80) to be able > to use it for A83T. This SoC has a bit flip that needs to be handled. > Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg) needed > for MCPM. > Patch 03: Add CCI-400 node for a83t. > Patch 04: Fix the use of virtual timers that hangs the kernel in > case of SMP support. > > If you have any remarks/questions, let me know. > Thank you in advance, > Mylène > Hello As we discussed in private, Chen Yu's patch should be added in your series. Furthermore, MCPM is not automaticaly selected via imply. With all patchs I hit a bug: [0.898668] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238 [0.911162] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0 [0.917776] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73 [0.925418] Hardware name: Allwinner sun8i Family [0.930118] Backtrace: [0.932596] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [0.940158] r7:c0b261e4 r6:6013 r5: r4:c0b51958 [0.945820] [] (show_stack) from [] (dump_stack+0x8c/0xa0) [0.953045] [] (dump_stack) from [] (___might_sleep+0x150/0x170) [0.960779] r7:c0b261e4 r6: r5:00ee r4:ee844000 [0.966437] [] (___might_sleep) from [] (__might_sleep+0x68/0xa0) [0.974253] r4:c0861690 [0.976796] [] (__might_sleep) from [] (mutex_lock+0x24/0x68) [0.984269] r6:c0892f6c r5: r4:c0b1bb24 [0.988891] [] (mutex_lock) from [] (perf_pmu_register+0x24/0x3e4) [0.996795] r5: r4:ee98b014 [1.000375] [] (perf_pmu_register) from [] (cci_pmu_probe+0x340/0x484) [1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4 r6:c0b26240 r5:eea19000 [1.016447] r4:ee98b010 [1.018989] [] (cci_pmu_probe) from [] (platform_drv_probe+0x58/0xb8) [1.027158] r10: r9:c0b2610c r8: r7:fdfb r6:c0b2610c r5:ffed [1.034974] r4:eea19010 [1.037511] [] (platform_drv_probe) from [] (driver_probe_device+0x254/0x330) [1.046371] r7: r6:c0bff498 r5:c0bff494 r4:eea19010 [1.052026] [] (driver_probe_device) from [] (__device_attach_driver+0xa0/0xd4) [1.061062] r10: r9:c0bff470 r8: r7:0001 r6:eea19010 r5:ee845ac0 [1.068879] r4:c0b2610c r3: [1.072454] [] (__device_attach_driver) from [] (bus_for_each_drv+0x68/0x9c) [1.081228] r7:0001 r6:c045cb24 r5:ee845ac0 r4: [1.086883] [] (bus_for_each_drv) from [] (__device_attach+0xb8/0x11c) [1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010 [1.099750] [] (__device_attach) from [] (device_initial_probe+0x14/0x18) [1.108263] r7:c0b0a4c8 r6:c0b3e848 r5:eea19010 r4:eea19018 [1.113919] [] (device_initial_probe) from [] (bus_probe_device+0x8c/0x94) [1.122523] [] (bus_probe_device) from [] (device_add+0x40c/0x5a0) [1.130429] r7:c0b0a4c8 r6:eea19010 r5:eea18a10 r4:eea19018 [1.136089] [] (device_add) from [] (of_device_add+0x3c/0x44) [1.143564] r10: r9: r8: r7:eedf21a4 r6:eea18a10 r5: [1.151380] r4:eea19000 [1.153915] [] (of_device_add) from [] (of_platform_device_create_pdata+0x7c/0xac) [1.163210] [] (of_platform_device_create_pdata) from [] (of_platform_bus_create+0xf4/0x1f0) [1.173372] r9: r8: r7:0001 r6: r5:eedf2154 r4: [1.181107] [] (of_platform_bus_create) from [] (of_platform_populate+0x74/0xd4) [1.190229] r10:0001 r9:eea18a10 r8: r7: r6: r5:eedf1d04 [1.198045] r4:eedf2154 [1.200580] [] (of_platform_populate) from [] (cci_platform_probe+0x3c/0x54) [1.209356] r10: r9:c0b26168 r8: r7:fdfb r6:c0b26168 r5:ffed [1.217172] r4:eea18a00 [1.219708] [] (cci_platform_probe) from [] (platform_drv_probe+0x58/0xb8) [1.228306] r5:ffed r4:eea18a10 [1.231881] [] (platform_drv_probe) from [] (driver_probe_device+0x254/0x330) [1.240742] r7: r6:c0bff498 r5:c0bff494 r4:eea18a10 [1.246397] [] (driver_probe_device) from [] (__device_attach_driver+0xa0/0xd4) [1.255433] r10: r9:c0bff470 r8: r7:0001 r6:eea18a10 r5:ee845ce8 [1.263250] r4:c0b26168 r3: [1.266825] [] (__device_attach_driver) from [] (bus_for_each_drv+0x68/0x9c) [1.275598] r7:0001 r6:c045cb24 r5:ee845ce8 r4: [1.281253] [] (bus_for_each_drv) from [] (__device_attach+0
Re: RFC(v2): Audit Kernel Container IDs
On Monday, December 11, 2017 11:30:57 AM EST Eric Paris wrote: > > Because a container doesn't have to use namespaces to be a container > > you still need a mechanism for a process to declare that it is in > > fact > > in a container, and to identify the container. > > I like the idea but I'm still tossing it around in my head (and > thinking about Casey's statement too). Lets say we have a 'docker-like' > container with pid=100 netns=X,userns=Y,mountns=Z. If I'm on the host > in all init namespaces and I run > nsenter -t 100 -n ip link set eth0 promisc on > How should this be logged? If it is a normal process, then everything would match the init name space and you wouldn't have entered a container. If it were a container, any generated event should have the container ID from registration attached to it. > Did this command run in it's own 'container' unrelated to the 'docker-like' > container? That should be determined by what's in the task struct. -Steve
[BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system
Hello, [First: Apologies if cross-posting from Kernel.org BZ is bad form; my distro BZ advised I post this to your mailing list as well.] Situation: enabling TPM on a Clevo W510LU with an Intel N3160 CPU breaks PS/2 keyboard and mouse. They just don't respond until after a suspend/resume cycle, and after that they later stop after a while. I have confirmed this by blacklisting tpm modules. I noticed this first with kernel 4.13, and have bisected it down to: 5e572cab92f0bb56ca1e6e5ee4d807663a7ccbad is the first bad commit commit 5e572cab92f0bb56ca1e6e5ee4d807663a7ccbad Author: Azhar Shaikh Date: Sun Jun 18 19:17:59 2017 -0700 tpm: Enable CLKRUN protocol for Braswell systems To overcome a hardware limitation on Intel Braswell systems, disable CLKRUN protocol during TPM transactions and re-enable once the transaction is completed. Signed-off-by: Azhar Shaikh Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: James Morris :04 04 5437c91886cb62c497255f2c60dbedd7268ab50d 1863a1738ded35a817aad52f9f2b451bd43623d7 M drivers Currently in Kernel.org bugzilla 197287. Please let me know if you need any further info. Many thanks, James.
Re: [PATCH PTI v2 6/6] x86/pti: Put the LDT in its own PGD if PTI is on
On Mon, Dec 11, 2017 at 11:32 AM, Dave Hansen wrote:
> On 12/11/2017 10:40 AM, Andy Lutomirski wrote:
>>> Also, from a high level, this does increase the overhead of KPTI in a
>>> non-trivial way, right? It costs us three more page table pages per
>>> process allocated at fork() and freed at exit() and a new TLB flush.
>> Yeah, but no one will care. modify_ldt() is used for DOSEMU, Wine,
>> and really old 32-bit programs.
>
> The heavyweight part of map_ldt_struct() (and unmap) looks to run
> whenever we have KPTI enabled. I'm missing how it gets avoided for the
> non-DOSEMU cases.
It doesn't get called unless modify_ldt() is used.
>
> I thought there would be a "fast path" where we just use the normal
> clear_LDT() LDT from the cpu_entry_area and don't have to do any of
> this, but I'm missing where that happens. Do we need a check in
> (un)map_ldt_struct() for !mm->context.ldt?
I'm confused.
if (unlikely(ldt)) {
do something slowish;
} else {
clear_LD();
}
>
> Just to make sure I understand this: We now have two places that LDTs
> live in virtual space:
>
> 1. The "plain" one that we get from clear_LDT() which lives in the
>cpu_entry_area. (No additional overhead when doing this)
> 2. The new one under the special PGD that's only used for modify_ldt()
>and is fairly slow. (plenty of overhead, but nobody cares).
Yes.
Re: [PATCH PTI v2 6/6] x86/pti: Put the LDT in its own PGD if PTI is on
On 12/11/2017 11:39 AM, Andy Lutomirski wrote:
>> I thought there would be a "fast path" where we just use the normal
>> clear_LDT() LDT from the cpu_entry_area and don't have to do any of
>> this, but I'm missing where that happens. Do we need a check in
>> (un)map_ldt_struct() for !mm->context.ldt?
> I'm confused.
>
> if (unlikely(ldt)) {
> do something slowish;
> } else {
> clear_LD();
> }
I was looking at the map/unmap paths. It looks to me like the cases
where there is map/unmap overhead, we *are* doing checking against
mm->context.ldt. It just wasn't visible from the patch context.
In any case, it would be really nice to call that out if you revise
these in the patch description: none of these LDT acrobatics are used in
the common case. Virtually every process uses the !ldt paths which
don't do any of this.
[PATCH] writeback: synchronize sync(2) against cgroup writeback membership switches
sync_inodes_sb() can race against cgwb (cgroup writeback) membership
switches and fail to writeback some inodes. For example, if an inode
switches to another wb while sync_inodes_sb() is in progress, the new
wb might not be visible to bdi_split_work_to_wbs() at all or the inode
might jump from a wb which hasn't issued writebacks yet to one which
already has.
This patch adds backing_dev_info->wb_switch_rwsem to synchronize cgwb
switch path against sync_inodes_sb() so that sync_inodes_sb() is
guaranteed to see all the target wbs and inodes can't jump wbs to
escape syncing.
Signed-off-by: Tejun Heo
Reported-by: Jiufei Xue
Link: http://lkml.kernel.org/r/dc694ae2-f07f-61e1-7097-7c8411cee...@gmail.com
---
fs/fs-writeback.c| 50 +--
include/linux/backing-dev-defs.h |1
mm/backing-dev.c |3 ++
3 files changed, 52 insertions(+), 2 deletions(-)
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -331,11 +331,22 @@ struct inode_switch_wbs_context {
struct work_struct work;
};
+static void bdi_down_write_wb_switch_rwsem(struct backing_dev_info *bdi)
+{
+ down_write(&bdi->wb_switch_rwsem);
+}
+
+static void bdi_up_write_wb_switch_rwsem(struct backing_dev_info *bdi)
+{
+ up_write(&bdi->wb_switch_rwsem);
+}
+
static void inode_switch_wbs_work_fn(struct work_struct *work)
{
struct inode_switch_wbs_context *isw =
container_of(work, struct inode_switch_wbs_context, work);
struct inode *inode = isw->inode;
+ struct backing_dev_info *bdi = inode_to_bdi(inode);
struct address_space *mapping = inode->i_mapping;
struct bdi_writeback *old_wb = inode->i_wb;
struct bdi_writeback *new_wb = isw->new_wb;
@@ -344,6 +355,12 @@ static void inode_switch_wbs_work_fn(str
void **slot;
/*
+* If @inode switches cgwb membership while sync_inodes_sb() is
+* being issued, sync_inodes_sb() might miss it. Synchronize.
+*/
+ down_read(&bdi->wb_switch_rwsem);
+
+ /*
* By the time control reaches here, RCU grace period has passed
* since I_WB_SWITCH assertion and all wb stat update transactions
* between unlocked_inode_to_wb_begin/end() are guaranteed to be
@@ -435,6 +452,8 @@ skip_switch:
spin_unlock(&new_wb->list_lock);
spin_unlock(&old_wb->list_lock);
+ up_read(&bdi->wb_switch_rwsem);
+
if (switched) {
wb_wakeup(new_wb);
wb_put(old_wb);
@@ -475,9 +494,18 @@ static void inode_switch_wbs(struct inod
if (inode->i_state & I_WB_SWITCH)
return;
+ /*
+* Avoid starting new switches while sync_inodes_sb() is in
+* progress. Otherwise, if the down_write protected issue path
+* blocks heavily, we might end up starting a large number of
+* switches which will block on the rwsem.
+*/
+ if (!down_read_trylock(&bdi->wb_switch_rwsem))
+ return;
+
isw = kzalloc(sizeof(*isw), GFP_ATOMIC);
if (!isw)
- return;
+ goto out_unlock;
/* find and pin the new wb */
rcu_read_lock();
@@ -511,12 +539,14 @@ static void inode_switch_wbs(struct inod
* Let's continue after I_WB_SWITCH is guaranteed to be visible.
*/
call_rcu(&isw->rcu_head, inode_switch_wbs_rcu_fn);
- return;
+ goto out_unlock;
out_free:
if (isw->new_wb)
wb_put(isw->new_wb);
kfree(isw);
+out_unlock:
+ up_read(&bdi->wb_switch_rwsem);
}
/**
@@ -893,6 +923,9 @@ fs_initcall(cgroup_writeback_init);
#else /* CONFIG_CGROUP_WRITEBACK */
+static void bdi_down_write_wb_switch_rwsem(struct backing_dev_info *bdi) { }
+static void bdi_up_write_wb_switch_rwsem(struct backing_dev_info *bdi) { }
+
static struct bdi_writeback *
locked_inode_to_wb_and_lock_list(struct inode *inode)
__releases(&inode->i_lock)
@@ -2422,8 +2455,21 @@ void sync_inodes_sb(struct super_block *
return;
WARN_ON(!rwsem_is_locked(&sb->s_umount));
+ /*
+* Protect against inode wb switch in inode_switch_wbs_work_fn().
+* We want to synchronize syncs against switches. Synchronizing
+* among syncs isn't necessary but it shouldn't matter especially
+* as we're only protecting the issuing.
+*
+* Once we grab the rwsem, bdi_split_work_to_wbs() is guaranteed to
+* see all the target wbs. If the wb membership hasn't changed,
+* through the ordering visible to the caller; otherwise, through
+* the transitive ordering via the rwsem.
+*/
+ bdi_down_write_wb_switch_rwsem(bdi);
bdi_split_work_to_wbs(bdi, &work, false);
wb_wait_for_completion(bdi, &done);
+ bdi_up_write_wb_switch_rwsem(bdi);
wait_sb_inodes(sb);
}
--- a/include/linux/backing-dev-defs.h
+++ b/
Re: [RFC][PATCH] ipc: mqueue: wq_add priority changed to dynamic priority
On Mon, 2017-12-11 at 14:32 -0500, Steven Rostedt wrote:
> On Mon, 11 Dec 2017 17:12:05 +
> Jonathan Haws wrote:
>
> >
> > Adding linux-rt-users group to thread.
> >
> > From: Jonathan Haws
> > Sent: Monday, December 11, 2017 08:37
> > To: mi...@kernel.org; v...@zeniv.linux.org.uk; a...@arndb.de; akpm@
> > linux-foundation.org; deepa.ker...@gmail.com
> > Cc: linux-kernel@vger.kernel.org; t...@linutronix.de; bigeasy@linut
> > ronix.de; rost...@goodmis.org; Jonathan Haws
> > Subject: [RFC][PATCH] ipc: mqueue: wq_add priority changed to
> > dynamic priority
> >
> > Previous behavior added tasks to the work queue using the
> > static_prio value
> > instead of the dynamic priority value in prio. This caused RT tasks
> > to be
> > added to the work queue in a FIFO manner rather than by priority.
> > Normal
> > tasks were handled by priority.
> >
> > This fix utilizes the dynamic priority of the task to ensure that
> > both RT
> > and normal tasks are added to the work queue in priority order.
> > Utilizing
> > the dynamic priority (prio) rather than the base priority
> > (normal_prio) was
> > chosen to ensure that if a task had a boosted priority when it was
> > added to
> > the work queue, it would be woken sooner to to ensure that it
> > releases any
> > other locks it may be holding in a more timely manner. It is
> > understood that
> > the task could have a lower priority when it wakes than when it was
> > added to
> > the queue in this (unlikely) case.
> Probably a better subject would be:
>
> ipc: mqueue: Have RT tasks queue in by priority in wq_add()
Is the best way to change that just to change it in the email thread or
resubmit the patch as v2?
>
> Other than that (and that this doesn't handle DL tasks),
>
> Reviewed-by: Steven Rostedt (VMware)
>
> -- Steve
>
I'm still new to kernel scheduling details - can you elaborate on what
a DL task is? I'm happy to update the patch to handle DL tasks as well
if it makes sense to do so.
Thanks!
Jon
> >
> >
> > Signed-off-by: Jonathan Haws
> > ---
> > ipc/mqueue.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> > index 9649ecd..cb96db9 100644
> > --- a/ipc/mqueue.c
> > +++ b/ipc/mqueue.c
> > @@ -546,7 +546,7 @@ static void wq_add(struct mqueue_inode_info
> > *info, int sr,
> > ewp->task = current;
> >
> > list_for_each_entry(walk, &info->e_wait_q[sr].list, list) {
> > - if (walk->task->static_prio <= current-
> > >static_prio) {
> > + if (walk->task->prio <= current->prio) {
> > list_add_tail(&ewp->list, &walk->list);
> > return;
> > }
> > --
> > 2.7.4
> >
[PATCH v5] ASoC: TSCS42xx: Add support for Tempo Semiconductor's TSCS42xx audio CODEC
Currently there is no support for the TSCS42xx audio CODEC.
Add support for it.
v5 attempts to address all issues raised in the previous reviews.
Thank you to everyone who has invested their time reviewing these
patches.
Acked-by: Philippe Ombredanne
Signed-off-by: Steven Eckhoff
---
.../devicetree/bindings/sound/tscs42xx.txt | 15 +
.../devicetree/bindings/vendor-prefixes.txt|1 +
MAINTAINERS|5 +
sound/soc/codecs/Kconfig |8 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tscs42xx.c| 1550 +++
sound/soc/codecs/tscs42xx.h| 2693
7 files changed, 4274 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tscs42xx.txt
create mode 100644 sound/soc/codecs/tscs42xx.c
create mode 100644 sound/soc/codecs/tscs42xx.h
diff --git a/Documentation/devicetree/bindings/sound/tscs42xx.txt
b/Documentation/devicetree/bindings/sound/tscs42xx.txt
new file mode 100644
index ..da8ea96f4cf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tscs42xx.txt
@@ -0,0 +1,15 @@
+TSCS42XX Audio CODEC
+
+Required Properties:
+
+ - compatible : "tscs:tscs42xx"
+
+ - reg : The I2C address of the device
+
+Example:
+
+codec: tscs42xx@69 {
+ compatible = "tscs,tscs42xx";
+ reg = <0x69>;
+ status = "okay";
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0994bdd82cd3..6ee98ba258ca 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -363,6 +363,7 @@ tpo TPO
tronfy Tronfy
tronsmart Tronsmart
truly Truly Semiconductors Limited
+tscs Tempo Semiconductor
tsdTheobroma Systems Design und Consulting GmbH
tyan Tyan Computer Corporation
ucrobotics uCRobotics
diff --git a/MAINTAINERS b/MAINTAINERS
index 82ad0eabce4f..03b31e465fa3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13850,6 +13850,11 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git
S: Maintained
K: ^Subject:.*(?i)trivial
+TEMPO SEMICONDUCTOR DRIVERS
+M: Steven Eckhoff
+S: Maintained
+F: sound/soc/codecs/tscs42xx.*
+
TTY LAYER
M: Greg Kroah-Hartman
M: Jiri Slaby
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index a42ddbc93f3d..d2f65c37464a 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -158,6 +158,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
select SND_SOC_TLV320DAC33 if I2C
+ select SND_SOC_TSCS42XX if I2C
select SND_SOC_TS3A227E if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
@@ -929,6 +930,13 @@ config SND_SOC_TLV320AIC3X
config SND_SOC_TLV320DAC33
tristate
+config SND_SOC_TSCS42XX
+ tristate "Tempo Semiconductor TSCS42xx CODEC"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Add support for Tempo Semiconductor's TSCS42xx audio CODEC.
+
config SND_SOC_TS3A227E
tristate "TI Headset/Mic detect and keypress chip"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 0001069ce2a7..ded86bceca37 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -167,6 +167,7 @@ snd-soc-tlv320aic32x4-i2c-objs := tlv320aic32x4-i2c.o
snd-soc-tlv320aic32x4-spi-objs := tlv320aic32x4-spi.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
snd-soc-tlv320dac33-objs := tlv320dac33.o
+snd-soc-tscs42xx-objs := tscs42xx.o
snd-soc-ts3a227e-objs := ts3a227e.o
snd-soc-twl4030-objs := twl4030.o
snd-soc-twl6040-objs := twl6040.o
@@ -406,6 +407,7 @@ obj-$(CONFIG_SND_SOC_TLV320AIC32X4_I2C) +=
snd-soc-tlv320aic32x4-i2c.o
obj-$(CONFIG_SND_SOC_TLV320AIC32X4_SPI)+= snd-soc-tlv320aic32x4-spi.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
obj-$(CONFIG_SND_SOC_TLV320DAC33) += snd-soc-tlv320dac33.o
+obj-$(CONFIG_SND_SOC_TSCS42XX) += snd-soc-tscs42xx.o
obj-$(CONFIG_SND_SOC_TS3A227E) += snd-soc-ts3a227e.o
obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
obj-$(CONFIG_SND_SOC_TWL6040) += snd-soc-twl6040.o
diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c
new file mode 100644
index ..2eaf142785ad
--- /dev/null
+++ b/sound/soc/codecs/tscs42xx.c
@@ -0,0 +1,1550 @@
+// SPDX-License-Identifier: GPL-2.0
+// tscs42xx.c -- TSCS42xx ALSA SoC Audio driver
+// Copyright 2017 Tempo Semiconductor, Inc.
+// Author: Steven Eckhoff
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tscs42xx.h"
+
+#define COEFF_SIZE 3
+#define BIQUAD_COEFF_COUNT 5
+#define BIQUAD_SIZE (COEFF_SIZE * BIQUAD_COEFF_COUNT)
+
+#define COEFF_RAM_MA
Re: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shift from %p to %pK
On Sun, Dec 10, 2017 at 1:47 PM, Paul E. McKenney wrote: > On Sun, Dec 10, 2017 at 12:39:11PM -0800, Linus Torvalds wrote: >> I'd rather make %pK act more like %p than have gratuitous differences. The feature that paranoid folks currently depend on is getting a value entirely zeroed out with %pK (which is the least possible info leak risk). The hashed %p is almost just as good except that identical hashes are still usable to confirm matching values (but the cases where this would be useful to an attacker are hopefully approaching zero). > So it looks like I should drop the three patches in my tree that convert > %p to %pK. > > Any objections? Sounds good. If they're still useful when hashed, keep the %p. If you want to remove them because they're sensitive, just remove them instead of adding new %pK users. -Kees -- Kees Cook Pixel Security
Re: [PATCH v3 5/5] perf-probe: Support escaped character in parser
Em Sat, Dec 09, 2017 at 01:28:41AM +0900, Masami Hiramatsu escreveu:
> Support the special characters escaped by '\' in parser.
> This allows user to specify versions directly like below.
>
> =
> # ./perf probe -x /lib64/libc-2.25.so malloc_get_state\\@GLIBC_2.2.5
> Added new event:
> probe_libc:malloc_get_state (on malloc_get_state@GLIBC_2.2.5 in
> /usr/lib64/libc-2.25.so)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe_libc:malloc_get_state -aR sleep 1
>
> =
>
> Or, you can use separators in source filename, e.g.
>
> =
> # ./perf probe -x /opt/test/a.out foo+bar.c:3
> Semantic error :There is non-digit character in offset.
> Error: Command Parse Error.
> =
>
> Usually "+" in source file cause parser error, but
>
> =
> # ./perf probe -x /opt/test/a.out foo\\+bar.c:4
> Added new event:
> probe_a:main (on @foo+bar.c:4 in /opt/test/a.out)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe_a:main -aR sleep 1
> =
>
> escaped "\+" allows you to specify that.
>
> Signed-off-by: Masami Hiramatsu
> Reviewed-by: Thomas Richter
> Acked-by: Ravi Bangoria
> ---
> Changes in v2:
> - Add a description and samples in Documentation/perf-probe.txt
> Changes in v3:
> - Update for new series.
> ---
> tools/perf/Documentation/perf-probe.txt | 16 +
> tools/perf/util/probe-event.c | 57
> ++-
> tools/perf/util/string.c| 46 +
> tools/perf/util/string2.h |2 +
> 4 files changed, 98 insertions(+), 23 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-probe.txt
> b/tools/perf/Documentation/perf-probe.txt
> index f96382692f42..b6866a05edd2 100644
> --- a/tools/perf/Documentation/perf-probe.txt
> +++ b/tools/perf/Documentation/perf-probe.txt
> @@ -182,6 +182,14 @@ Note that before using the SDT event, the target binary
> (on which SDT events are
> For details of the SDT, see below.
> https://sourceware.org/gdb/onlinedocs/gdb/Static-Probe-Points.html
>
> +ESCAPED CHARACTER
> +-
> +
> +In the probe syntax, '=', '@', '+', ':' and ';' are treated as a special
> character. You can use a backslash ('\') to escape the special characters.
> +This is useful if you need to probe on a specific versioned symbols, like
> @GLIBC_... suffixes, or also you need to specify a source file which includes
> the special characters.
> +Note that usually single backslash is consumed by shell, so you might need
> to pass double backslash (\\) or wrapping with single quotes (\'AAA\@BBB').
> +See EXAMPLES how it is used.
> +
> PROBE ARGUMENT
> --
> Each probe argument follows below syntax.
> @@ -277,6 +285,14 @@ Add a USDT probe to a target process running in a
> different mount namespace
>
> ./perf probe --target-ns -x
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64/jre/lib/amd64/server/libjvm.so
> %sdt_hotspot:thread__sleep__end
>
> +Add a probe on specific versioned symbol by backslash escape
> +
> + ./perf probe -x /lib64/libc-2.25.so 'malloc_get_state\@GLIBC_2.2.5'
> +
> +Add a probe in a source file using special characters by backslash escape
> +
> + ./perf probe -x /opt/test/a.out 'foo\+bar.c:4'
> +
>
> SEE ALSO
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 0d6c66d51939..735972e7bc6b 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -1325,27 +1325,30 @@ static int parse_perf_probe_event_name(char **arg,
> struct perf_probe_event *pev)
> {
> char *ptr;
>
> - ptr = strchr(*arg, ':');
> + ptr = strpbrk_esc(*arg, ":");
> if (ptr) {
> *ptr = '\0';
> if (!pev->sdt && !is_c_func_name(*arg))
> goto ng_name;
> - pev->group = strdup(*arg);
> + pev->group = strdup_esc(*arg);
> if (!pev->group)
> return -ENOMEM;
> *arg = ptr + 1;
> } else
> pev->group = NULL;
> - if (!pev->sdt && !is_c_func_name(*arg)) {
> +
> + pev->event = strdup_esc(*arg);
> + if (pev->event == NULL)
> + return -ENOMEM;
> +
> + if (!pev->sdt && !is_c_func_name(pev->event)) {
> + zfree(&pev->event);
> ng_name:
> + zfree(&pev->group);
> semantic_error("%s is bad for event name -it must "
> "follow C symbol-naming rule.\n", *arg);
> return -EINVAL;
> }
> - pev->event = strdup(*arg);
> - if (pev->event == NULL)
> - return -ENOMEM;
> -
> return 0;
> }
>
> @@ -1373,7 +1376,7 @@ static int parse_perf_probe_point(char *arg, struct
> perf_probe_event *pev)
> arg++;
> }
>
> - ptr = strpbrk(arg, ";=@+%");
> + ptr = strpbrk_
Re: Oops on 4.15-rc[123] on shutdown/reboot
On 11/12/17 17:17, Bjorn Helgaas wrote: > [+cc linux-pci] > > On Mon, Dec 11, 2017 at 11:29:50AM -0500, Sinan Kaya wrote: >> Hi Chris, >> >>> >>> I'm more than happy to provide additional diagnostics and test proposed >>> fixes. As a starter for ten, I've attached the >>> output from 'lspci -v'. If, however, you need to see the backtrace, I'll >>> need some advice on how to capture that. >>> >> >> Can you open a bugzilla and also share the boot log? >> >> There must be something unique about your system. > > Can you attach "lspci -vv" output (as root) to the bugzilla, too? > I've opened the bugzilla report (Bug 198141) and attached the dmesg and lspci -vv outputs to it.
RE: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()
From: Logan Gunthorpe > On 11/12/17 12:17 PM, Allen Hubbe wrote: > >> mw_get_align doesn't communicate the fact that the buffer has to be > >> aligned by its size. > > > > Is that not the purpose of the addr_align out parameter of > > ntb_mw_get_align()? > > addr_align provides the minimum alignment required by the device but it > has no idea how big a buffer the caller is trying to create so it can't > express that it needs to be aligned by its size. > > To be clear, the minimum alignment the Switchtec device requires is 4KB > so it will return 4k in addr_align. Thus, if you have a 4KB buffer it > may be aligned to 4KB. But if you have a 1MB buffer it must be aligned > to the nearest 1M. In switchtec_ntb_mw_get_align, for the lut case it seems to require alignment the same as Intel, aligned to mw size, but for the non-lut case you are saying that SZ_4K is not necessarily correct. The SZ_4K is the minimum, but the actual alignment restriction depends on the size of the buffer actually translated. Right? Also, for the lut case, it looks like the size also has to be the same size as the mw. So, a client can't allocate a smaller buffer, assume we can get one that is aligned, point the start of the mw at it, and limit the size of the mw? For the non-lut case I wonder, with the restriction that addr needs to be aligned to the size of the buffer, does the size of the buffer also need to be some power of two? That would make sense, if it determines the alignment. If so, SZ_4K wouldn't be correct for size_align, either. Do you need the intended buffer size passed in as another parameter to ntb_mw_get_align? The point of ntb_mw_get_align is to figure out all the alignment restrictions before allocating memory. > >> It may also be that all hardware does not have this > >> restriction (ie. if the hardware adds to the base address instead of > >> just replacing the lower bits). > >> > >> There is definitely a need to print this error somewhere as I hit this > >> case and it caused very weird behavior. It was a huge pain to debug. > >> Also, it's a security issue and huge bug if we end up mapping the memory > >> we didn't think we were mapping. > > > > Of course the driver should validate its parameters not allow bad mappings. > > I was only commenting > on the dev_err() message to the console. > > Ok. I still feel like it would be difficult to debug if ntb_transport > simply was unable to establish a connection without some message in > dmesg telling the user why. > > Also, keep in mind this is a somewhat unusual occurrence. In most cases > dma_alloc_coherent() always provides a buffer that is aligned to it's > size. It's just that the CMA (if used) provides a tunable config option > which allows for larger buffers to not be aligned to their size. > > Logan
Re: [PATCH PTI v2 6/6] x86/pti: Put the LDT in its own PGD if PTI is on
On Mon, Dec 11, 2017 at 11:47 AM, Dave Hansen wrote:
> On 12/11/2017 11:39 AM, Andy Lutomirski wrote:
>>> I thought there would be a "fast path" where we just use the normal
>>> clear_LDT() LDT from the cpu_entry_area and don't have to do any of
>>> this, but I'm missing where that happens. Do we need a check in
>>> (un)map_ldt_struct() for !mm->context.ldt?
>> I'm confused.
>>
>> if (unlikely(ldt)) {
>> do something slowish;
>> } else {
>> clear_LD();
>> }
>
> I was looking at the map/unmap paths. It looks to me like the cases
> where there is map/unmap overhead, we *are* doing checking against
> mm->context.ldt. It just wasn't visible from the patch context.
>
> In any case, it would be really nice to call that out if you revise
> these in the patch description: none of these LDT acrobatics are used in
> the common case. Virtually every process uses the !ldt paths which
> don't do any of this.
Will do.
I'm currently fighting with the 5 level case. I need to reorganize
the memory map a bit, but it's blowing up, and I'm not sure why yet.
Re: [PATCH] perf tools: Fix swap for samples with raw data
Em Wed, Nov 29, 2017 at 07:43:46PM +0100, Jiri Olsa escreveu:
> When we detect different endianity we swap event before
> processing. It's tricky for samples because we have no
> idea what's inside. We treat it as an array of u64s,
> swap them and later on we swap back parts which are
> different.
Thanks, applied to perf/core, now at:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/core&id=26ea2ece7802f8fdaaacf321dbfb22de3271ab82
- Arnaldo
> We mangle this way also the tracepoint raw data, which
> ends up in report showing wrong data:
>
> 1.95% comm=Q^B pid=29285 prio=16777216 target_cpu=000
> 1.67% comm=l^B pid=0 prio=16777216 target_cpu=000
>
> Luckily the traceevent library handles the endianity by
> itself (thank you Steven!), so we can pass the RAW data
> directly in the other endianity.
>
> 2.51% comm=beah-rhts-task pid=1175 prio=120 target_cpu=002
> 2.23% comm=kworker/0:0 pid=11566 prio=120 target_cpu=000
>
> The fix is basically to swap back the raw data if different
> endianity is detected.
>
> Cc: David Ahern
> Cc: Steven Rostedt (VMware)
> Link: http://lkml.kernel.org/n/tip-0zcnwqf2k4pq854huwxc1...@git.kernel.org
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/util/evsel.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index 95853c51c0ca..09c68cf2d9d2 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -36,6 +36,7 @@
> #include "debug.h"
> #include "trace-event.h"
> #include "stat.h"
> +#include "memswap.h"
> #include "util/parse-branch-options.h"
>
> #include "sane_ctype.h"
> @@ -2131,14 +2132,27 @@ int perf_evsel__parse_sample(struct perf_evsel
> *evsel, union perf_event *event,
> if (type & PERF_SAMPLE_RAW) {
> OVERFLOW_CHECK_u64(array);
> u.val64 = *array;
> - if (WARN_ONCE(swapped,
> - "Endianness of raw data not corrected!\n")) {
> - /* undo swap of u64, then swap on individual u32s */
> +
> + /*
> + * Undo swap of u64, then swap on individual u32s,
> + * get the size of the raw area and undo all of the
> + * swap. The pevent interface handles endianity by
> + * itself.
> + */
> + if (swapped) {
> u.val64 = bswap_64(u.val64);
> u.val32[0] = bswap_32(u.val32[0]);
> u.val32[1] = bswap_32(u.val32[1]);
> }
> data->raw_size = u.val32[0];
> +
> + /*
> + * The raw data is aligned on 64bits including the
> + * u32 size, so it's safe to use mem_bswap_64.
> + */
> + if (swapped)
> + mem_bswap_64((void *) array, data->raw_size);
> +
> array = (void *)array + sizeof(u32);
>
> OVERFLOW_CHECK(array, data->raw_size, max_size);
> --
> 2.13.6
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel-fixes tree
On Mon, Dec 11, 2017 at 12:31:06PM +0200, Joonas Lahtinen wrote:
> + GVT folks.
>
> On Fri, 2017-12-08 at 09:15 +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Commit
> >
> > 365ad5df9caa ("drm/i915/gvt: Export
> > intel_gvt_render_mmio_to_ring_id()")
> >
> > is missing a Signed-off-by from its committer.
We also patched our pull processing script to check for this in the
future.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH net,stable] net: qmi_wwan: add Quectel BG96 2c7c:0296
From: Sebastian Sjoholm
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel development
board (EVB). The USB id is added to qmi_wwan.c to allow QMI
communication with the BG96.
Signed-off-by: Sebastian Sjoholm
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 720a3a248070..c750cf7c042b 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1239,6 +1239,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0125, 4)}, /* Quectel EC25, EC20 R2.0
Mini PCIe */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
+ {QMI_FIXED_INTF(0x2c7c, 0x0296, 4)},/* Quectel BG96 */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
--
2.11.0 (Apple Git-81)
[PATCH net,stable] net: qmi_wwan: add Sierra EM7565 1199:9091
From: Sebastian Sjoholm
From: Sebastian Sjoholm
Sierra Wireless EM7565 is an Qualcomm MDM9x50 based M.2 modem.
The USB id is added to qmi_wwan.c to allow QMI communication with the EM7565.
Signed-off-by: Sebastian Sjoholm
---
[The corresponding qcserial patch will be submitted by Reinhard Speyerer.]
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 304ec6555cd8..3cebd6683938 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1204,6 +1204,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9079, 10)}, /* Sierra Wireless EM74xx */
{QMI_FIXED_INTF(0x1199, 0x907b, 8)},/* Sierra Wireless EM74xx */
{QMI_FIXED_INTF(0x1199, 0x907b, 10)}, /* Sierra Wireless EM74xx */
+ {QMI_FIXED_INTF(0x1199, 0x9091, 8)},/* Sierra Wireless EM7565 */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
--
2.14.1
Re: [PATCH net,stable] net: qmi_wwan: add Quectel BG96 2c7c:0296
Hi,
Sorry for the re-email of the patch below, clearly a beginners mistake of me
not to clear my tmp/ folder.
Please disregard this.
Regards,
Sebastian
> On Dec 11, 2017, at 21:12 , ssjoh...@mac.com wrote:
>
> From: Sebastian Sjoholm
>
> Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
> CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel development
> board (EVB). The USB id is added to qmi_wwan.c to allow QMI
> communication with the BG96.
>
> Signed-off-by: Sebastian Sjoholm
>
> ---
> drivers/net/usb/qmi_wwan.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 720a3a248070..c750cf7c042b 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -1239,6 +1239,7 @@ static const struct usb_device_id products[] = {
> {QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
> {QMI_QUIRK_SET_DTR(0x2c7c, 0x0125, 4)}, /* Quectel EC25, EC20 R2.0
> Mini PCIe */
> {QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
> + {QMI_FIXED_INTF(0x2c7c, 0x0296, 4)},/* Quectel BG96 */
>
> /* 4. Gobi 1000 devices */
> {QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
> --
> 2.11.0 (Apple Git-81)
>
Re: [RFC][PATCH] ipc: mqueue: wq_add priority changed to dynamic priority
On Mon, 11 Dec 2017 19:54:33 + Jonathan Haws wrote: > > Probably a better subject would be: > > > > ipc: mqueue: Have RT tasks queue in by priority in wq_add() > > Is the best way to change that just to change it in the email thread or > resubmit the patch as v2? That, or whoever takes it could change it before they pull it into git. > > > > > Other than that (and that this doesn't handle DL tasks), > > > > Reviewed-by: Steven Rostedt (VMware) > > > > -- Steve > > > > I'm still new to kernel scheduling details - can you elaborate on what > a DL task is? I'm happy to update the patch to handle DL tasks as well > if it makes sense to do so. DL is a SCHED_DEADLINE task that has a dynamic priority that changes over time. It's not a trivial task to compare them in these situations, and they are currently not used much, and having DL tasks use this queue is probably even more rare of an occurrence. -- Steve
[PATCH] crypto: chacha20poly1305 - validate the digest size
From: Eric Biggers
If the rfc7539 template was instantiated with a hash algorithm with
digest size larger than 16 bytes (POLY1305_DIGEST_SIZE), then the digest
overran the 'tag' buffer in 'struct chachapoly_req_ctx', corrupting the
subsequent memory, including 'cryptlen'. This caused a crash during
crypto_skcipher_decrypt().
Fix it by, when instantiating the template, requiring that the
underlying hash algorithm has the digest size expected for Poly1305.
Reproducer:
#include
#include
#include
int main()
{
int algfd, reqfd;
struct sockaddr_alg addr = {
.salg_type = "aead",
.salg_name = "rfc7539(chacha20,sha256)",
};
unsigned char buf[32] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (void *)&addr, sizeof(addr));
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, buf, sizeof(buf));
reqfd = accept(algfd, 0, 0);
write(reqfd, buf, 16);
read(reqfd, buf, 16);
}
Reported-by: syzbot
Fixes: 71ebc4d1b27d ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD
construction, RFC7539")
Cc: # v4.2+
Signed-off-by: Eric Biggers
---
crypto/chacha20poly1305.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/crypto/chacha20poly1305.c b/crypto/chacha20poly1305.c
index db1bc3147bc4..600afa99941f 100644
--- a/crypto/chacha20poly1305.c
+++ b/crypto/chacha20poly1305.c
@@ -610,6 +610,11 @@ static int chachapoly_create(struct crypto_template *tmpl,
struct rtattr **tb,
algt->mask));
if (IS_ERR(poly))
return PTR_ERR(poly);
+ poly_hash = __crypto_hash_alg_common(poly);
+
+ err = -EINVAL;
+ if (poly_hash->digestsize != POLY1305_DIGEST_SIZE)
+ goto out_put_poly;
err = -ENOMEM;
inst = kzalloc(sizeof(*inst) + sizeof(*ctx), GFP_KERNEL);
@@ -618,7 +623,6 @@ static int chachapoly_create(struct crypto_template *tmpl,
struct rtattr **tb,
ctx = aead_instance_ctx(inst);
ctx->saltlen = CHACHAPOLY_IV_SIZE - ivsize;
- poly_hash = __crypto_hash_alg_common(poly);
err = crypto_init_ahash_spawn(&ctx->poly, poly_hash,
aead_crypto_instance(inst));
if (err)
--
2.15.1.424.g9478a66081-goog
Re: [ANNOUNCE] 4.1.46-rt52
On Mon, Dec 11, 2017 at 01:04:58PM -0600, Corey Minyard wrote:
> On 11/29/2017 05:13 PM, Julia Cartwright wrote:
> > Hello RT Folks!
> >
> > I'm pleased to announce the 4.1.46-rt52 stable release.
> >
> > You can get this release via the git tree at:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
> >
> >branch: v4.1-rt
> >Head SHA1: 6e737a91c1ce923d4e10db831e14cfef9a2459cc
> >
> > Or to build 4.1.46-rt52 directly, the following patches should be applied:
> >
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_pub_linux_kernel_v4.x_linux-2D4.1.tar.xz&d=DwICaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=cAXq_8W9Othb2h8ZcWv8Vw&m=a5KTpX9A0-pHwmQkOOLr5_xeWPavI-lgN7Z0Goes2So&s=tGmSNpZKEKvhTpeVu_ktmD4I5PIXfIJhZ79DxwbCjtQ&e=
> >
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_pub_linux_kernel_v4.x_patch-2D4.1.46.xz&d=DwICaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=cAXq_8W9Othb2h8ZcWv8Vw&m=a5KTpX9A0-pHwmQkOOLr5_xeWPavI-lgN7Z0Goes2So&s=hx9pHgRy7tWhUeeiJhPOH0T8qdDrhtZvWxOWuIBZZgs&e=
> >
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_pub_linux_kernel_projects_rt_4.1_patch-2D4.1.46-2Drt52.patch.xz&d=DwICaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=cAXq_8W9Othb2h8ZcWv8Vw&m=a5KTpX9A0-pHwmQkOOLr5_xeWPavI-lgN7Z0Goes2So&s=Pm8ed_xvW1drpPxNkt035bj6ILvSImuN9vvgEAt8IiM&e=
> >
> >
> > You can also build from 4.1.46-rt51 by applying the incremental patch:
> >
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_pub_linux_kernel_projects_rt_4.1_incr_patch-2D4.1.46-2Drt51-2Drt52.patch.xz&d=DwICaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=cAXq_8W9Othb2h8ZcWv8Vw&m=a5KTpX9A0-pHwmQkOOLr5_xeWPavI-lgN7Z0Goes2So&s=ZM64-JCd0WNFQgFlB3wbCfn8Jtf9rq5QyCO2-GJsC2Q&e=
> >
> > Enjoy!
> > Julia
> >
> > Changes from v4.1.46-rt51:
> > ---
> > Julia Cartwright (2):
> >workqueue: fixup rcu check for RT
> >Linux 4.1.46-rt52
> >
> > Sebastian Andrzej Siewior (2):
> >PM / CPU: replace raw_notifier with atomic_notifier (fixup)
>
> This change breaks the compile of 4.1 on ARM (and other things using
> kernel/cpu_pm.c).
>
> rcu_irq_enter_irqson() and friends doesn't exist in 4.1. In fact,
> rcu_irq_enter() doesn't even exist.
>
> Sorry I didn't get to testing this earlier, I've been focused on other things.
Thanks! My current builds apparently don't currently cover CPU_PM
builds, so I didn't see this :(. Thanks for the report.
v4.1 does contain rcu_irq_enter(), and it looks like what we should be
using in 4.1 instead.
I'm thinking the below should be okay; I'll be standing up a proper cpu
hotplugging test to give it some runtime.
Thanks,
Julia
-- 8< --
Subject: [PATCH] PM / CPU: replace usage of rcu_irq_{enter,exit}_irqson()
Commit c50243950f97e ("PM / CPU: replace raw_notifier with
atomic_notifier (fixup)") intended to fix up RCU usage in idle, by
telling RCU to pay attention.
However, the cherry-pick back from rt-devel included the invocation of
the _irqson() variants of rcu_irq_{enter,exit}() API which doesn't exist
in 4.1.
For 4.1, just simply drop the _irqson() variant, and instead use
rcu_irq_{enter,exit}() directly instead. This is safe, because in 4.1,
these functions internally disable interrupts.
Reported-by: Corey Minyard
Signed-off-by: Julia Cartwright
[PATCH 45/45] arch/sparc: remove duplicate includes
These duplicate includes have been found with scripts/checkincludes.pl but they have been removed manually to avoid removing false positives. Signed-off-by: Pravin Shedge --- arch/sparc/kernel/uprobes.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/sparc/kernel/uprobes.c b/arch/sparc/kernel/uprobes.c index d852ae5..c44bf5b 100644 --- a/arch/sparc/kernel/uprobes.c +++ b/arch/sparc/kernel/uprobes.c @@ -29,7 +29,6 @@ #include #include -#include /* Compute the address of the breakpoint instruction and return it. * -- 2.7.4
[REGRESSION][4.13.y][4.14.y][v4.15.y] net: reduce skb_warn_bad_offload() noise
Hi Eric, A kernel bug report was opened against Ubuntu [0]. It was found that reverting the following commit resolved this bug: commit b2504a5dbef3305ef41988ad270b0e8ec289331c Author: Eric Dumazet Date: Tue Jan 31 10:20:32 2017 -0800 net: reduce skb_warn_bad_offload() noise The regression was introduced as of v4.11-rc1 and still exists in current mainline. I was hoping to get your feedback, since you are the patch author. Do you think gathering any additional data will help diagnose this issue, or would it be best to submit a revert request? This commit did in fact resolve another bug[1], but in the process introduced this regression. Thanks, Joe [0] http://pad.lv/1715609 [1] http://pad.lv/1705447
Re: [PATCH net,stable] net: qmi_wwan: add Sierra EM7565 1199:9091
ssjoh...@mac.com writes:
> From: Sebastian Sjoholm
>
> From: Sebastian Sjoholm
>
> Sierra Wireless EM7565 is an Qualcomm MDM9x50 based M.2 modem.
> The USB id is added to qmi_wwan.c to allow QMI communication with the EM7565.
>
> Signed-off-by: Sebastian Sjoholm
> ---
> [The corresponding qcserial patch will be submitted by Reinhard Speyerer.]
>
> ---
> drivers/net/usb/qmi_wwan.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 304ec6555cd8..3cebd6683938 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -1204,6 +1204,7 @@ static const struct usb_device_id products[] = {
> {QMI_FIXED_INTF(0x1199, 0x9079, 10)}, /* Sierra Wireless EM74xx */
> {QMI_FIXED_INTF(0x1199, 0x907b, 8)},/* Sierra Wireless EM74xx */
> {QMI_FIXED_INTF(0x1199, 0x907b, 10)}, /* Sierra Wireless EM74xx */
> + {QMI_FIXED_INTF(0x1199, 0x9091, 8)},/* Sierra Wireless EM7565 */
> {QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II
> (Alcatel One Touch L100V LTE) */
> {QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
> {QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
Looks good except for the duplicate 'From' line. Drop that and you can
add
Acked-by: Bjørn Mork
Re: [PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()
On 11/12/17 01:06 PM, Allen Hubbe wrote: In switchtec_ntb_mw_get_align, for the lut case it seems to require alignment the same as Intel, aligned to mw size, but for the non-lut case you are saying that SZ_4K is not necessarily correct. The SZ_4K is the minimum, but the actual alignment restriction depends on the size of the buffer actually translated. Right? Yes, that is correct. Also, for the lut case, it looks like the size also has to be the same size as the mw. So, a client can't allocate a smaller buffer, assume we can get one that is aligned, point the start of the mw at it, and limit the size of the mw? The LUT case is much simpler. The size must be exactly 64K (as chosen by the driver... it may be a module parameter later) and therefore the alignment must also be exactly 64k. For the non-lut case I wonder, with the restriction that addr needs to be aligned to the size of the buffer, does the size of the buffer also need to be some power of two? That would make sense, if it determines the alignment. If so, SZ_4K wouldn't be correct for size_align, either. It would be weird not to make the size a power of two but this is not a requirement of the hardware. The alignment must be the next highest power of two after the size. For example, you could have a 768KB buffer but it would need to be aligned to 1M. This is how dma_alloc_coherent() behaves as well. Think of it this way: in the hardware we program the number of translation bits (xlate_pos in the code). That number of low bits in the destination address are replaced with the same bits in the source address. So if any of the translated bits in the destination address were not zero, they will be after the replacement. Do you know if Intel hardware does something similar? Do you need the intended buffer size passed in as another parameter to ntb_mw_get_align? The point of ntb_mw_get_align is to figure out all the alignment restrictions before allocating memory. We could, but I don't really see the point of doing that. There's really nothing the client would/could do differently if we added that. Remember this restriction is already (mostly) satisfied by dma_alloc_coherent and if that wasn't the case then all the tricks that the client currently does to try and obey ntb_mw_get_align would not work. Actually, if we were going to change anything, I'd suggest creating an API that's something like: void *ntb_mw_alloc(struct ntb_dev *ntb, int pidx, int widx, size_t buf_size, dma_addr_t *dma_addr, int flags); This would do the DMA allocation and adjust the size as necessary to satisfy the alignment requirements. Then there would be a common place that enforces the alignment issues instead of expecting every client to get that right. Takes a lot of the boiler plate out of the clients as well. Logan
RE: [PATCH 1/2] vmbus: unregister device_obj->channels_kset
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> Behalf Of Stephen Hemminger
> Sent: Tuesday, November 28, 2017 9:30 AM
> To: Greg KH
> Cc: o...@aepfle.de; Stephen Hemminger ;
> jasow...@redhat.com; linux-kernel@vger.kernel.org; sta...@vger.kernel.org;
> a...@canonical.com; marcelo.ce...@canonical.com;
> de...@linuxdriverproject.org; vkuzn...@redhat.com;
> leann.ogasaw...@canonical.com
> Subject: Re: [PATCH 1/2] vmbus: unregister device_obj->channels_kset
>
> On Tue, 28 Nov 2017 16:56:05 +0100
> Greg KH wrote:
>
> > On Tue, Nov 14, 2017 at 06:53:32AM -0700, k...@exchange.microsoft.com
> wrote:
> > > From: Dexuan Cui
> > >
> > > Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info")
> > >
> > > Without the patch, a device can't be thoroughly destroyed, because
> > > vmbus_device_register() -> kset_create_and_add() still holds a reference
> > > to the hv_device's device.kobj.
> > >
> > > Signed-off-by: Dexuan Cui
> > > Cc: Stephen Hemminger
> > > Cc: sta...@vger.kernel.org
> >
> > Why is this marked for stable when the patch it "fixes" is in 4.15-rc1?
>
> It doesn't need to go to stable.
Hi Greg,
May I know the status of the patch?
Thanks,
-- Dexuan
[PATCH 41/45] arch/x86: remove duplicate includes
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge
---
arch/x86/kernel/itmt.c | 1 -
arch/x86/kernel/process.c | 1 -
arch/x86/kernel/setup.c| 1 -
arch/x86/kernel/smpboot.c | 1 -
arch/x86/platform/efi/efi_64.c | 1 -
arch/x86/xen/spinlock.c| 2 --
6 files changed, 7 deletions(-)
diff --git a/arch/x86/kernel/itmt.c b/arch/x86/kernel/itmt.c
index f73f475..d177940 100644
--- a/arch/x86/kernel/itmt.c
+++ b/arch/x86/kernel/itmt.c
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 97fb3e5..9824553 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -21,7 +21,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 8af2e8d..c8e0447 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -114,7 +114,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 3d01df7..8dd0f51 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -75,7 +75,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 6a151ce..1e5184d 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 02f3445..cd97a62 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -23,8 +23,6 @@ static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
static DEFINE_PER_CPU(char *, irq_name);
static bool xen_pvspin = true;
-#include
-
static void xen_qlock_kick(int cpu)
{
int irq = per_cpu(lock_kicker_irq, cpu);
--
2.7.4
Re: [PATCH RESEND] KVM: X86: Fix load bad host fpu state
On 10.12.2017 22:44, Wanpeng Li wrote:
> From: Wanpeng Li
>
> [ cut here ]
> Bad FPU state detected at kvm_put_guest_fpu+0xd8/0x2d0 [kvm], reinitializing
> FPU registers.
> WARNING: CPU: 1 PID: 4594 at arch/x86/mm/extable.c:103
> ex_handler_fprestore+0x88/0x90
> CPU: 1 PID: 4594 Comm: qemu-system-x86 Tainted: GB OE
> 4.15.0-rc2+ #10
> RIP: 0010:ex_handler_fprestore+0x88/0x90
> Call Trace:
> fixup_exception+0x4e/0x60
> do_general_protection+0xff/0x270
> general_protection+0x22/0x30
> RIP: 0010:kvm_put_guest_fpu+0xd8/0x2d0 [kvm]
> RSP: 0018:8803d5627810 EFLAGS: 00010246
> kvm_vcpu_reset+0x3b4/0x3c0 [kvm]
> kvm_apic_accept_events+0x1c0/0x240 [kvm]
> kvm_arch_vcpu_ioctl_run+0x1658/0x2fb0 [kvm]
> kvm_vcpu_ioctl+0x479/0x880 [kvm]
> do_vfs_ioctl+0x142/0x9a0
> SyS_ioctl+0x74/0x80
> do_syscall_64+0x15f/0x600
>
> This can be reproduced by running any testcase in kvm-unit-tests since
> the qemu userspace FPU context is not initialized, which results in the
> init path from kvm_apic_accept_events() will load/put qemu userspace
> FPU context w/o initialized. In addition, w/o this splatting we still
> should initialize vcpu->arch.user_fpu instead of current->thread.fpu.
> This patch fixes it by initializing qemu user FPU context if it is
> uninitialized before KVM_RUN.
>
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Rik van Riel
> Cc: sta...@vger.kernel.org
> Fixes: f775b13eedee (x86,kvm: move qemu/guest FPU switching out to vcpu_run)
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/x86.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index a92b22f..063a643 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7273,10 +7273,13 @@ static int complete_emulated_mmio(struct kvm_vcpu
> *vcpu)
>
> int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
> {
> - struct fpu *fpu = ¤t->thread.fpu;
> + struct fpu *fpu = &vcpu->arch.user_fpu;
> int r;
>
> - fpu__initialize(fpu);
> + if (!fpu->initialized) {
> + fpstate_init(&fpu->state);
> + fpu->initialized = 1;
> + }
Is there a chance of keeping using fpu__initialize() ? Duplicating the
code is ugly.
E.g. can't we simply initialize that in kvm_load_guest_fpu?
>
> kvm_sigset_activate(vcpu);
>
>
--
Thanks,
David / dhildenb
Re: [PATCH] KVM: X86: Fix host dr6 miss restore
On 10.12.2017 01:44, Wanpeng Li wrote: > 2017-12-08 20:39 GMT+08:00 David Hildenbrand : >> On 08.12.2017 10:12, Wanpeng Li wrote: >>> From: Wanpeng Li >>> >>> Reported by syzkaller: >>> >>>WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 >>> do_debug+0x222/0x250 >>>CPU: 0 PID: 12927 Comm: syz-executor Tainted: G OE >>> 4.15.0-rc2+ #16 >>>RIP: 0010:do_debug+0x222/0x250 >>>Call Trace: >>> <#DB> >>> debug+0x3e/0x70 >>>RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20 >>> >>> _copy_from_user+0x5b/0x90 >>> SyS_timer_create+0x33/0x80 >>> entry_SYSCALL_64_fastpath+0x23/0x9a >>> >>> The syzkaller will mmap a buffer which is also the struct sigevent >>> parameter of >>> timer_create(), it will also call perf_event_open() to set a BP for the >>> buffer, >>> so when the implementation of timer_create() in kernel tries to get the >>> struct >>> sigevent parameter by copy_from_user(), rep movsb triggers the BP. The >>> syzkaller >>> testcase also sets the debug registers for the guest, however, the kvm just >>> restores host debug registers when we have active breakpoints. I can observe >>> the dr6 single step bit is set and !hw_breakpoint_active() sporadically by >>> print >>> when running the testcase heavy multithreading. The do_debug() which is >>> triggered >>> by rep movsb will splash when (dr6 & DR_STEP && !user_mode(regs)). >>> >>> This patch fixes it by restoring host dr6 unconditionally before preempt/irq >>> enable. >>> >>> Reported-by: Dmitry Vyukov >>> Cc: Paolo Bonzini >>> Cc: Radim Krčmář >>> Cc: David Hildenbrand >>> Cc: Dmitry Vyukov >>> Signed-off-by: Wanpeng Li >>> --- >>> arch/x86/kvm/x86.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>> index 0c5d55c..a6370fd 100644 >>> --- a/arch/x86/kvm/x86.c >>> +++ b/arch/x86/kvm/x86.c >>> @@ -7065,6 +7065,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) >>>*/ >>> if (hw_breakpoint_active()) >>> hw_breakpoint_restore(); >>> + else >>> + set_debugreg(current->thread.debugreg6, 6); >>> >>> vcpu->arch.last_guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()); >>> >>> >> >> If you haven't seen it, I analyzed this in >> https://lkml.org/lkml/2017/11/7/638 but nobody would respond for now to >> my suggestion/question. > > I think it's fine to restore dr6 before preempt/irq enable. That make sense, as I assume this is the first time that a trap would be delivered. Reviewed-by: David Hildenbrand And certainly stable material? > > Regards, > Wanpeng Li > -- Thanks, David / dhildenb
linux-next: Signed-off-by missing for commit in the nand tree
Hi Boris,
Commit
b8267c7ef4f1 ("mtd: nand: add ->exec_op() implementation")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
[PATCH net,stable] net: qmi_wwan: add Sierra EM7565 1199:9091
From: Sebastian Sjoholm
Sierra Wireless EM7565 is an Qualcomm MDM9x50 based M.2 modem.
The USB id is added to qmi_wwan.c to allow QMI communication
with the EM7565.
Signed-off-by: Sebastian Sjoholm
Acked-by: Bjørn Mork
---
[The corresponding qcserial patch will be submitted by Reinhard Speyerer.]
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 304ec6555cd8..3cebd6683938 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1204,6 +1204,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9079, 10)}, /* Sierra Wireless EM74xx */
{QMI_FIXED_INTF(0x1199, 0x907b, 8)},/* Sierra Wireless EM74xx */
{QMI_FIXED_INTF(0x1199, 0x907b, 10)}, /* Sierra Wireless EM74xx */
+ {QMI_FIXED_INTF(0x1199, 0x9091, 8)},/* Sierra Wireless EM7565 */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
--
2.14.1
Re: [PATCH] sched/fair: Prevent a division by 0 in scale_rt_capacity()
Hi Filippo, On 12/09/2017 12:03 AM, Filippo Sironi wrote: ... since total = sched_avg_period() + delta can yield 0x1, which results in a division by 0, given that div_u64() takes a u32 divisor. Use div64_u64() instead. divide error: [#1] SMP CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.58 #1 Hardware name: ... task: 8800a24e2800 task.stack: c974c000 RIP: 0010:[] [] update_group_capacity+0x16e/0x1c0 RSP: 0018:8800a74e3c18 EFLAGS: 00010246 RAX: 00445ced RBX: 0007 RCX: 024d RDX: RSI: RDI: 000160c0 RBP: 8800a74e3c38 R08: 8800a17d5ac0 R09: 8800a74e R10: R11: R12: 8800a297e400 R13: 8800a17d5ac0 R14: R15: 8800a17d5ac0 FS: () GS:8800a74e() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 006f3580 CR3: 01607000 CR4: 007426e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Stack: 8800a17d5180 8800a74e3e00 8800a17d5a01 8800a74e3c68 8800a74e3d90 810d37e6 fff8 002300010c40 0040 8800a17d5ad8 Call Trace: [162553.008569] [] find_busiest_group+0xe6/0x950 [] load_balance+0x188/0xa70 [] ? update_rq_clock.part.88+0x13/0x30 [] rebalance_domains+0x210/0x290 [] run_rebalance_domains+0x1b0/0x1d0 [] __do_softirq+0x89/0x2b0 [] irq_exit+0xab/0xb0 [] smp_reschedule_interrupt+0x2e/0x30 [] reschedule_interrupt+0x84/0x90 [162553.008603] [] ? cpuidle_enter_state+0x12f/0x2c0 [] cpuidle_enter+0x12/0x20 [] cpu_startup_entry+0x1a2/0x1f0 [] start_secondary+0x12d/0x140 Code: 0f 00 4c 8b 96 48 09 00 00 48 8b 86 40 09 00 00 48 8b b6 b0 08 00 00 48 d1 ea 4c 29 d6 41 ba 00 00 00 00 49 0f 48 f2 01 d6 31 d2 <48> f7 f6 ba 00 04 00 00 48 29 c2 48 3d ff 03 00 00 b8 01 00 00 RIP [] update_group_capacity+0x16e/0x1c0 RSP Cc: Ingo Molnar Cc: Peter Zijlstra Cc: linux-kernel@vger.kernel.org Signed-off-by: Filippo Sironi Reviewed by: Rohit Jain --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 4037e19bbca2..04b6f847a241 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7517,7 +7517,7 @@ static unsigned long scale_rt_capacity(int cpu) total = sched_avg_period() + delta; - used = div_u64(avg, total); + used = div64_u64(avg, total); if (likely(used < SCHED_CAPACITY_SCALE)) return SCHED_CAPACITY_SCALE - used;
Re: [PATCH 1/2] vmbus: unregister device_obj->channels_kset
On Mon, Dec 11, 2017 at 08:41:44PM +, Dexuan Cui wrote:
> > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> > Behalf Of Stephen Hemminger
> > Sent: Tuesday, November 28, 2017 9:30 AM
> > To: Greg KH
> > Cc: o...@aepfle.de; Stephen Hemminger ;
> > jasow...@redhat.com; linux-kernel@vger.kernel.org; sta...@vger.kernel.org;
> > a...@canonical.com; marcelo.ce...@canonical.com;
> > de...@linuxdriverproject.org; vkuzn...@redhat.com;
> > leann.ogasaw...@canonical.com
> > Subject: Re: [PATCH 1/2] vmbus: unregister device_obj->channels_kset
> >
> > On Tue, 28 Nov 2017 16:56:05 +0100
> > Greg KH wrote:
> >
> > > On Tue, Nov 14, 2017 at 06:53:32AM -0700, k...@exchange.microsoft.com
> > wrote:
> > > > From: Dexuan Cui
> > > >
> > > > Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info")
> > > >
> > > > Without the patch, a device can't be thoroughly destroyed, because
> > > > vmbus_device_register() -> kset_create_and_add() still holds a reference
> > > > to the hv_device's device.kobj.
> > > >
> > > > Signed-off-by: Dexuan Cui
> > > > Cc: Stephen Hemminger
> > > > Cc: sta...@vger.kernel.org
> > >
> > > Why is this marked for stable when the patch it "fixes" is in 4.15-rc1?
> >
> > It doesn't need to go to stable.
>
> Hi Greg,
> May I know the status of the patch?
It's still in my "to-apply" queue. As it's only a 4.15-final thing,
don't worry, it will get there...
thanks,
greg k-h
Re: [ANNOUNCE] 4.1.46-rt52
On 12/11/2017 02:20 PM, Julia Cartwright wrote:
On Mon, Dec 11, 2017 at 01:04:58PM -0600, Corey Minyard wrote:
On 11/29/2017 05:13 PM, Julia Cartwright wrote:
Hello RT Folks!
I'm pleased to announce the 4.1.46-rt52 stable release.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v4.1-rt
Head SHA1: 6e737a91c1ce923d4e10db831e14cfef9a2459cc
Or to build 4.1.46-rt52 directly, the following patches should be applied:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_pub_linux_kernel_v4.x_linux-2D4.1.tar.xz&d=DwICaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=cAXq_8W9Othb2h8ZcWv8Vw&m=a5KTpX9A0-pHwmQkOOLr5_xeWPavI-lgN7Z0Goes2So&s=tGmSNpZKEKvhTpeVu_ktmD4I5PIXfIJhZ79DxwbCjtQ&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_pub_linux_kernel_v4.x_patch-2D4.1.46.xz&d=DwICaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=cAXq_8W9Othb2h8ZcWv8Vw&m=a5KTpX9A0-pHwmQkOOLr5_xeWPavI-lgN7Z0Goes2So&s=hx9pHgRy7tWhUeeiJhPOH0T8qdDrhtZvWxOWuIBZZgs&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_pub_linux_kernel_projects_rt_4.1_patch-2D4.1.46-2Drt52.patch.xz&d=DwICaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=cAXq_8W9Othb2h8ZcWv8Vw&m=a5KTpX9A0-pHwmQkOOLr5_xeWPavI-lgN7Z0Goes2So&s=Pm8ed_xvW1drpPxNkt035bj6ILvSImuN9vvgEAt8IiM&e=
You can also build from 4.1.46-rt51 by applying the incremental patch:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_pub_linux_kernel_projects_rt_4.1_incr_patch-2D4.1.46-2Drt51-2Drt52.patch.xz&d=DwICaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=cAXq_8W9Othb2h8ZcWv8Vw&m=a5KTpX9A0-pHwmQkOOLr5_xeWPavI-lgN7Z0Goes2So&s=ZM64-JCd0WNFQgFlB3wbCfn8Jtf9rq5QyCO2-GJsC2Q&e=
Enjoy!
Julia
Changes from v4.1.46-rt51:
---
Julia Cartwright (2):
workqueue: fixup rcu check for RT
Linux 4.1.46-rt52
Sebastian Andrzej Siewior (2):
PM / CPU: replace raw_notifier with atomic_notifier (fixup)
This change breaks the compile of 4.1 on ARM (and other things using
kernel/cpu_pm.c).
rcu_irq_enter_irqson() and friends doesn't exist in 4.1. In fact,
rcu_irq_enter() doesn't even exist.
Sorry I didn't get to testing this earlier, I've been focused on other things.
Thanks! My current builds apparently don't currently cover CPU_PM
builds, so I didn't see this :(. Thanks for the report.
v4.1 does contain rcu_irq_enter(), and it looks like what we should be
using in 4.1 instead.
Ah, it does, I looked in the wrong place.
I'm thinking the below should be okay; I'll be standing up a proper cpu
hotplugging test to give it some runtime.
The below should work. You'll need an ARM64, ARM or MIPS system with
the proper
config settings to exercise this code, though.
-corey
Thanks,
Julia
-- 8< --
Subject: [PATCH] PM / CPU: replace usage of rcu_irq_{enter,exit}_irqson()
Commit c50243950f97e ("PM / CPU: replace raw_notifier with
atomic_notifier (fixup)") intended to fix up RCU usage in idle, by
telling RCU to pay attention.
However, the cherry-pick back from rt-devel included the invocation of
the _irqson() variants of rcu_irq_{enter,exit}() API which doesn't exist
in 4.1.
For 4.1, just simply drop the _irqson() variant, and instead use
rcu_irq_{enter,exit}() directly instead. This is safe, because in 4.1,
these functions internally disable interrupts.
Reported-by: Corey Minyard
Signed-off-by: Julia Cartwright
return notifier_to_errno(ret);
}
Re: linux-next: Signed-off-by missing for commit in the nand tree
On Tue, 12 Dec 2017 07:50:34 +1100
Stephen Rothwell wrote:
> Hi Boris,
>
> Commit
>
> b8267c7ef4f1 ("mtd: nand: add ->exec_op() implementation")
>
> is missing a Signed-off-by from its committer.
>
Just fixed it.
Thanks,
Boris
RE: [PATCH 1/2] vmbus: unregister device_obj->channels_kset
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, December 11, 2017 12:59 PM
> To: Dexuan Cui
> Cc: Stephen Hemminger ; o...@aepfle.de;
> Stephen Hemminger ; jasow...@redhat.com;
> linux-kernel@vger.kernel.org; sta...@vger.kernel.org; a...@canonical.com;
> marcelo.ce...@canonical.com; de...@linuxdriverproject.org;
> vkuzn...@redhat.com; leann.ogasaw...@canonical.com
> Subject: Re: [PATCH 1/2] vmbus: unregister device_obj->channels_kset
>
> On Mon, Dec 11, 2017 at 08:41:44PM +, Dexuan Cui wrote:
> > > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> > > Behalf Of Stephen Hemminger
> > > Sent: Tuesday, November 28, 2017 9:30 AM
> > > To: Greg KH
> > > Cc: o...@aepfle.de; Stephen Hemminger ;
> > > jasow...@redhat.com; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org;
> > > a...@canonical.com; marcelo.ce...@canonical.com;
> > > de...@linuxdriverproject.org; vkuzn...@redhat.com;
> > > leann.ogasaw...@canonical.com
> > > Subject: Re: [PATCH 1/2] vmbus: unregister device_obj->channels_kset
> > >
> > > On Tue, 28 Nov 2017 16:56:05 +0100
> > > Greg KH wrote:
> > >
> > > > On Tue, Nov 14, 2017 at 06:53:32AM -0700,
> k...@exchange.microsoft.com
> > > wrote:
> > > > > From: Dexuan Cui
> > > > >
> > > > > Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info")
> > > > >
> > > > > Without the patch, a device can't be thoroughly destroyed, because
> > > > > vmbus_device_register() -> kset_create_and_add() still holds a
> > > > > reference
> > > > > to the hv_device's device.kobj.
> > > > >
> > > > > Signed-off-by: Dexuan Cui
> > > > > Cc: Stephen Hemminger
> > > > > Cc: sta...@vger.kernel.org
> > > >
> > > > Why is this marked for stable when the patch it "fixes" is in 4.15-rc1?
> > >
> > > It doesn't need to go to stable.
> >
> > Hi Greg,
> > May I know the status of the patch?
>
> It's still in my "to-apply" queue. As it's only a 4.15-final thing,
> don't worry, it will get there...
>
> thanks,
>
> greg k-h
Thanks a lot, Greg!
-- Dexuan
Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending
On Sat, Dec 9, 2017 at 12:08 AM, Tetsuo Handa wrote: > Suren Baghdasaryan wrote: >> On Fri, Dec 8, 2017 at 6:03 AM, Tetsuo Handa >> wrote: >> >> > >> This change checks for pending >> >> > >> fatal signals inside shrink_slab loop and if one is detected >> >> > >> terminates this loop early. >> >> > > >> >> > > This changelog doesn't really address my previous review feedback, I >> >> > > am >> >> > > afraid. You should mention more details about problems you are seeing >> >> > > and what causes them. >> >> The problem I'm facing is that a SIGKILL sent from user space to kill >> the least important process is delayed enough for OOM-killer to get a >> chance to kill something else, possibly a more important process. Here >> "important" is from user's point of view. So the delay in SIGKILL >> delivery effectively causes extra kills. Traces indicate that this >> delay happens when process being killed is in direct reclaim and >> shrinkers (before I fixed them) were the biggest cause for the delay. > > Sending SIGKILL from userspace is not releasing memory fast enough to prevent > the OOM killer from invoking? Yes, under memory pressure, even an attempt to > send SIGKILL from userspace could be delayed due to e.g. page fault. > I understand that there will be cases when OOM is unavoidable. I'm trying to minimize the cases when SIGKILL processing is delayed. > Unless it is memcg OOM, you could try OOM notifier callback for checking > whether there are SIGKILL pending processes and wait for timeout if any. > This situation resembles timeout-based OOM killing discussion, where the OOM > killer is enabled again (based on an assumption that the OOM victim got stuck > due to OOM lockup) after some timeout from previous OOM-killing. And since > we did not merge timeout-based approach, there is no timestamp field for > remembering when the SIGKILL was delivered. Therefore, an attempt to wait for > timeout would become messy. > > Regardless of whether you try OOM notifier callback, I think that adding > __GFP_KILLABLE and allow bailing out without calling out_of_memory() and > warn_alloc() will help terminating killed processes faster. I think that > majority of memory allocation requests can give up upon SIGKILL. Important > allocation requests which should not give up upon SIGKILL (e.g. committing > to filesystem metadata and storage) can be offloaded to kernel threads. > >> >> >> > > If we have a shrinker which takes considerable >> >> > > amount of time them we should be addressing that. If that is not >> >> > > possible then it should be documented at least. >> >> I already submitted patches for couple shrinkers. Problem became less >> pronounced and less frequent but the retry loop Tetsuo mentioned still >> visibly delays the delivery. The worst case I've seen after fixing >> shrinkers is 43ms. > > You meant "delays the termination (of the killed process)" rather than > "delays the delivery (of SIGKILL)", didn't you? > To be more precise, I'm talking about the delay between send_signal() and get_signal() or in other words the delay between the moment when we send the SIGKILL and the moment we handle it. >> > I agree that making waits/loops killable is generally good. But be sure to >> > be >> > prepared for the worst case. For example, start __GFP_KILLABLE from "best >> > effort" >> > basis (i.e. no guarantee that the allocating thread will leave the page >> > allocator >> > slowpath immediately) and check for fatal_signal_pending() only if >> > __GFP_KILLABLE is set. That is, >> > >> > + /* >> > +* We are about to die and free our memory. >> > +* Stop shrinking which might delay signal handling. >> > +*/ >> > + if (unlikely((gfp_mask & __GFP_KILLABLE) && >> > fatal_signal_pending(current))) >> > + break; >> > >> > at shrink_slab() etc. and >> > >> > + if ((gfp_mask & __GFP_KILLABLE) && >> > fatal_signal_pending(current)) >> > + goto nopage; >> > >> > at __alloc_pages_slowpath(). >> >> I was thinking about something similar and will experiment to see if >> this solves the problem and if it has any side effects. Anyone sees >> any obvious problems with this approach? >> > > It is Michal who thinks that "killability for a particular allocation request > sounds > like a hack" ( > http://lkml.kernel.org/r/201606112335.hbg09891.olfjoftvmoq...@i-love.sakura.ne.jp > ). > I'm willing to give up memory allocations from functions which are called by > system calls if SIGKILL is pending. Thus, it should be time to try > __GFP_KILLABLE.
Re: [PATCH] media: pxa_camera: disable and unprepare the clock source on error
Hi Laurent, > Hi Flavio, > > Thank you for the patch. > > On Wednesday, 6 December 2017 18:38:50 EET Flavio Ceolin wrote: >> pxa_camera_probe() was not calling pxa_camera_deactivate(), >> responsible to call clk_disable_unprepare(), on the failure path. This >> was leading to unbalancing source clock. >> >> Found by Linux Driver Verification project (linuxtesting.org). > > Any chance I could sign you up for more work on this driver ? :-) Definetely, this would be great :) > >> Signed-off-by: Flavio Ceolin > > Reviewed-by: Laurent Pinchart > > I expect Hans Verkuil to pick up the patch. > >> --- >> drivers/media/platform/pxa_camera.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/media/platform/pxa_camera.c >> b/drivers/media/platform/pxa_camera.c index 9d3f0cb..7877037 100644 >> --- a/drivers/media/platform/pxa_camera.c >> +++ b/drivers/media/platform/pxa_camera.c >> @@ -2489,7 +2489,7 @@ static int pxa_camera_probe(struct platform_device >> *pdev) dev_set_drvdata(&pdev->dev, pcdev); >> err = v4l2_device_register(&pdev->dev, &pcdev->v4l2_dev); >> if (err) >> -goto exit_free_dma; >> +goto exit_deactivate; >> >> pcdev->asds[0] = &pcdev->asd; >> pcdev->notifier.subdevs = pcdev->asds; >> @@ -2525,6 +2525,8 @@ static int pxa_camera_probe(struct platform_device >> *pdev) v4l2_clk_unregister(pcdev->mclk_clk); >> exit_free_v4l2dev: >> v4l2_device_unregister(&pcdev->v4l2_dev); >> +exit_deactivate: >> +pxa_camera_deactivate(pcdev); >> exit_free_dma: >> dma_release_channel(pcdev->dma_chans[2]); >> exit_free_dma_u: > > -- > Regards, > > Laurent Pinchart Regards, Flavio Ceolin
[PATCH v2] mm: Release a semaphore in 'get_vaddr_frames()'
A semaphore is acquired before this check, so we must release it before
leaving.
Fixes: b7f0554a56f2 ("mm: fail get_vaddr_frames() for filesystem-dax mappings")
Signed-off-by: Christophe JAILLET
---
-- Untested --
v1 -> v2: 'goto out' instead of duplicating code
---
mm/frame_vector.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/frame_vector.c b/mm/frame_vector.c
index 297c7238f7d4..c64dca6e27c2 100644
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -62,8 +62,10 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
* get_user_pages_longterm() and disallow it for filesystem-dax
* mappings.
*/
- if (vma_is_fsdax(vma))
- return -EOPNOTSUPP;
+ if (vma_is_fsdax(vma)) {
+ ret = -EOPNOTSUPP;
+ goto out;
+ }
if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
vec->got_ref = true;
--
2.14.1
Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending
On Sun, Dec 10, 2017 at 2:13 AM, Michal Hocko wrote: > On Fri 08-12-17 10:06:26, Suren Baghdasaryan wrote: >> On Fri, Dec 8, 2017 at 6:03 AM, Tetsuo Handa >> wrote: >> > Michal Hocko wrote: >> >> On Fri 08-12-17 20:36:16, Tetsuo Handa wrote: >> >> > On 2017/12/08 17:22, Michal Hocko wrote: >> >> > > On Thu 07-12-17 17:23:05, Suren Baghdasaryan wrote: >> >> > >> Slab shrinkers can be quite time consuming and when signal >> >> > >> is pending they can delay handling of the signal. If fatal >> >> > >> signal is pending there is no point in shrinking that process >> >> > >> since it will be killed anyway. >> >> > > >> >> > > The thing is that we are _not_ shrinking _that_ process. We are >> >> > > shrinking globally shared objects and the fact that the memory >> >> > > pressure >> >> > > is so large that the kswapd doesn't keep pace with it means that we >> >> > > have >> >> > > to throttle all allocation sites by doing this direct reclaim. I agree >> >> > > that expediting killed task is a good thing in general because such a >> >> > > process should free at least some memory. >> >> Agree, wording here is inaccurate. My original intent was to have a >> safeguard against slow shrinkers but I understand your concern that >> this can mask a real problem in a shrinker. In essence expediting the >> killing is the ultimate goal here but as you mentioned it's not as >> simple as this change. > > Moreover it doesn't work if the SIGKILL can be delivered asynchronously > (which is your case AFAICU). You can be already running the slow > shrinker at that time... That is true but at least my change would not allow more than one shrinker to run while SIGKILL is pending. And that's why this change is not a fix for slow shrinkers, they have to be properly fixed with or without this change. > > [...] >> > I agree that making waits/loops killable is generally good. But be sure to >> > be >> > prepared for the worst case. For example, start __GFP_KILLABLE from "best >> > effort" >> > basis (i.e. no guarantee that the allocating thread will leave the page >> > allocator >> > slowpath immediately) and check for fatal_signal_pending() only if >> > __GFP_KILLABLE is set. That is, >> > >> > + /* >> > +* We are about to die and free our memory. >> > +* Stop shrinking which might delay signal handling. >> > +*/ >> > + if (unlikely((gfp_mask & __GFP_KILLABLE) && >> > fatal_signal_pending(current))) >> > + break; >> > >> > at shrink_slab() etc. and >> > >> > + if ((gfp_mask & __GFP_KILLABLE) && >> > fatal_signal_pending(current)) >> > + goto nopage; >> > >> > at __alloc_pages_slowpath(). >> >> I was thinking about something similar and will experiment to see if >> this solves the problem and if it has any side effects. Anyone sees >> any obvious problems with this approach? > > Tetsuo has been proposing this flag in the past and I've had objections > why this is not a great idea. I do not have any link handy but the core > objection was that the semantic would be too fuzzy. All the allocations > in the same context would have to be killable for this flag to have any > effect. Spreading it all over the kernel is simply not feasible. Sounds like I'll have to do much more reading before touching this code :) > > -- > Michal Hocko > SUSE Labs
Re: [PATCH] tuners: tda8290: reduce stack usage with kasan
On Mon, Dec 11, 2017 at 2:34 PM, Joe Perches wrote:
> On Mon, 2017-12-11 at 13:06 +0100, Arnd Bergmann wrote:
>> With CONFIG_KASAN enabled, we get a relatively large stack frame in one
>> function
>>
>> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
>> drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes
>> is larger than 1024 bytes [-Wframe-larger-than=]
>>
>> With CONFIG_KASAN_EXTRA this goes up to
>>
>> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
>> drivers/media/tuners/tda8290.c:310:1: error: the frame size of 3200 bytes is
>> larger than 3072 bytes [-Werror=frame-larger-than=]
>>
>> We can significantly reduce this by marking local arrays as 'static const',
>> and
>> this should result in better compiled code for everyone.
> []
>> diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
> []
>> @@ -63,8 +63,8 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe, int
>> close)
>> {
>> struct tda8290_priv *priv = fe->analog_demod_priv;
>>
>> - unsigned char enable[2] = { 0x21, 0xC0 };
>> - unsigned char disable[2] = { 0x21, 0x00 };
>> + static unsigned char enable[2] = { 0x21, 0xC0 };
>> + static unsigned char disable[2] = { 0x21, 0x00 };
>
> Doesn't match commit message.
>
> static const or just static?
>
>> @@ -84,9 +84,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int
>> close)
>> {
>> struct tda8290_priv *priv = fe->analog_demod_priv;
>>
>> - unsigned char enable[2] = { 0x45, 0xc1 };
>> - unsigned char disable[2] = { 0x46, 0x00 };
>> - unsigned char buf[3] = { 0x45, 0x01, 0x00 };
>> + static unsigned char enable[2] = { 0x45, 0xc1 };
>> + static unsigned char disable[2] = { 0x46, 0x00 };
>
> etc.
>
>
Joe is correct - they can be CONSTified. My bad -- a lot of the code I
wrote many years ago has this problem -- I wasn't so stack-conscious
back then.
The bytes in `enable` / `disable` don't get changed, but they may be
copied to another byte array that does get changed. If would be best
to make these `static const`
Best regards,
Michael Ira Krufky
Re: [PATCH] Documentation: mono: Update links and s/CVS/Git/
On Sat, 9 Dec 2017 17:21:04 +0100 Jonathan Neuschäfer wrote: > The URLs in mono.rst redirect to pages on www.mono-project.com, so let's > update them. I took the liberty to update the compilation instructions > to the Linux-specific version, because readers of the kernel > documentation will most likely use Linux. Applied to the docs tree, thanks. I do wonder if anybody actually does this, though... jon
Re: [PATCH v2 2/2] drm/tinydrm: add driver for ST7735R panels
Den 10.12.2017 23.10, skrev David Lechner:
This adds a new driver for Sitronix ST7735R display panels.
This has been tested using an Adafruit 1.8" TFT.
Signed-off-by: David Lechner
---
+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state)
+{
+ struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+ struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+ struct device *dev = tdev->drm->dev;
+ int ret;
+ u8 addr_mode;
+
+ DRM_DEBUG_KMS("\n");
+
+ mipi_dbi_hw_reset(mipi);
+
+ ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+ return;
+ }
+
+ msleep(150);
+
+ mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+ msleep(500);
+
+ mipi_dbi_command(mipi, ST7735R_FRMCTR1, 0x01, 0x2c, 0x2d);
+ mipi_dbi_command(mipi, ST7735R_FRMCTR2, 0x01, 0x2c, 0x2d);
+ mipi_dbi_command(mipi, ST7735R_FRMCTR3, 0x01, 0x2c, 0x2d, 0x01, 0x2c,
+0x2d);
+ mipi_dbi_command(mipi, ST7735R_INVCTR, 0x07);
+ mipi_dbi_command(mipi, ST7735R_PWCTR1, 0xa2, 0x02, 0x84);
+ mipi_dbi_command(mipi, ST7735R_PWCTR2, 0xc5);
+ mipi_dbi_command(mipi, ST7735R_PWCTR3, 0x0a, 0x00);
+ mipi_dbi_command(mipi, ST7735R_PWCTR4, 0x8a, 0x2a);
+ mipi_dbi_command(mipi, ST7735R_PWCTR5, 0x8a, 0xee);
+ mipi_dbi_command(mipi, ST7735R_VMCTR1, 0x0e);
+ mipi_dbi_command(mipi, MIPI_DCS_EXIT_INVERT_MODE);
+ switch (mipi->rotation) {
+ default:
+ addr_mode = ST7735R_MX | ST7735R_MY;
+ break;
+ case 90:
+ addr_mode = ST7735R_MX | ST7735R_MV;
+ break;
+ case 180:
+ addr_mode = 0;
+ break;
+ case 270:
+ addr_mode = ST7735R_MY | ST7735R_MV;
+ break;
+ }
+ mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+ mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT,
+MIPI_DCS_PIXEL_FMT_16BIT);
+ mipi_dbi_command(mipi, ST7735R_GAMCTRP1, 0x0f, 0x1a, 0x0f, 0x18, 0x2f,
+0x28, 0x20, 0x22, 0x1f, 0x1b, 0x23, 0x37, 0x00, 0x07,
+0x02, 0x10);
+ mipi_dbi_command(mipi, ST7735R_GAMCTRN1, 0x0f, 0x1b, 0x0f, 0x17, 0x33,
+0x2c, 0x29, 0x2e, 0x30, 0x30, 0x39, 0x3f, 0x00, 0x07,
+0x03, 0x10);
+ mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+
+ msleep(100);
+
+ mipi_dbi_command(mipi, MIPI_DCS_ENTER_NORMAL_MODE);
+
+ msleep(20);
+
+ mipi_dbi_pipe_enable(pipe, crtc_state);
+}
+
+static const struct drm_simple_display_pipe_funcs st7735r_pipe_funcs = {
+ .enable = st7735r_pipe_enable,
+ .disable= mipi_dbi_pipe_disable,
+ .update = tinydrm_display_pipe_update,
+ .prepare_fb = tinydrm_display_pipe_prepare_fb,
+};
+
+static const struct drm_display_mode st7735r_mode = {
+ TINYDRM_MODE(128, 160, 28, 35),
+};
This naming talk has made me realise that these should be named after
the panel since they're not generic controller functions.
Maybe the mode can be generic, not sure if the physical size can/will
differ, the resolution is very likely to be the same for all.
What's your view on my descision to split the MIPI DBI compatible
controllers into per controller drivers instead of having one driver
that supports them all?
I've been afraid that it will be a very big file with macro definitions
per controller and enable functions per panel.
This driver has 15 macros and ~80 panel specific lines.
With one panel supported, half the driver is boilerplate.
The mi0283qt panel (MIPI DBI compatible) is in the same ballpark.
Adding helpers for panel reset/exit_sleep, for MIPI_DCS_SET_ADDRESS_MODE
and for display_on/enter_normal/flush could cut it down some more if we
made one driver to rule them all. Maybe the enable function per panel
could be cut in half that way.
I'm starting to wonder if one driver isn't such a bad solution after all...
Noralf.
Re: [PATCH] Documentation: kernel-hacking: corrected a typo
On Fri, 8 Dec 2017 19:10:54 +0100 Marco Donato Torsello wrote: > Corrected a typo. > > Signed-off-by: Marco Donato Torsello > --- > Documentation/kernel-hacking/hacking.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to the docs tree, thanks. jon
Re: [PATCH v3] binder: fix proc->files use-after-free
Greg- when this is in, we'll want it in 4.14 as well.
On Mon, Nov 27, 2017 at 9:32 AM, Todd Kjos wrote:
> proc->files cleanup is initiated by binder_vma_close. Therefore
> a reference on the binder_proc is not enough to prevent the
> files_struct from being released while the binder_proc still has
> a reference. This can lead to an attempt to dereference the
> stale pointer obtained from proc->files prior to proc->files
> cleanup. This has been seen once in task_get_unused_fd_flags()
> when __alloc_fd() is called with a stale "files".
>
> The fix is to protect proc->files with a mutex to prevent cleanup
> while in use.
>
> Signed-off-by: Todd Kjos
> ---
> v2: declare binder_get_files_struct as static
> v3: rework to protect proc->files with a mutex instead of using
> get_files_struct
>
> Also needed in 4.14
>
> drivers/android/binder.c | 44 +++-
> 1 file changed, 31 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index a73596a4f804..7c027ee61375 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -482,7 +482,8 @@ enum binder_deferred_state {
> * @tsk task_struct for group_leader of process
> *(invariant after initialized)
> * @files files_struct for process
> - *(invariant after initialized)
> + *(protected by @files_lock)
> + * @files_lockmutex to protect @files
> * @deferred_work_node: element for binder_deferred_list
> *(protected by binder_deferred_lock)
> * @deferred_work:bitmap of deferred work to perform
> @@ -530,6 +531,7 @@ struct binder_proc {
> int pid;
> struct task_struct *tsk;
> struct files_struct *files;
> + struct mutex files_lock;
> struct hlist_node deferred_work_node;
> int deferred_work;
> bool is_dead;
> @@ -877,20 +879,26 @@ static void binder_inc_node_tmpref_ilocked(struct
> binder_node *node);
>
> static int task_get_unused_fd_flags(struct binder_proc *proc, int flags)
> {
> - struct files_struct *files = proc->files;
> unsigned long rlim_cur;
> unsigned long irqs;
> + int ret;
>
> - if (files == NULL)
> - return -ESRCH;
> -
> - if (!lock_task_sighand(proc->tsk, &irqs))
> - return -EMFILE;
> -
> + mutex_lock(&proc->files_lock);
> + if (proc->files == NULL) {
> + ret = -ESRCH;
> + goto err;
> + }
> + if (!lock_task_sighand(proc->tsk, &irqs)) {
> + ret = -EMFILE;
> + goto err;
> + }
> rlim_cur = task_rlimit(proc->tsk, RLIMIT_NOFILE);
> unlock_task_sighand(proc->tsk, &irqs);
>
> - return __alloc_fd(files, 0, rlim_cur, flags);
> + ret = __alloc_fd(proc->files, 0, rlim_cur, flags);
> +err:
> + mutex_unlock(&proc->files_lock);
> + return ret;
> }
>
> /*
> @@ -899,8 +907,10 @@ static int task_get_unused_fd_flags(struct binder_proc
> *proc, int flags)
> static void task_fd_install(
> struct binder_proc *proc, unsigned int fd, struct file *file)
> {
> + mutex_lock(&proc->files_lock);
> if (proc->files)
> __fd_install(proc->files, fd, file);
> + mutex_unlock(&proc->files_lock);
> }
>
> /*
> @@ -910,9 +920,11 @@ static long task_close_fd(struct binder_proc *proc,
> unsigned int fd)
> {
> int retval;
>
> - if (proc->files == NULL)
> - return -ESRCH;
> -
> + mutex_lock(&proc->files_lock);
> + if (proc->files == NULL) {
> + retval = -ESRCH;
> + goto err;
> + }
> retval = __close_fd(proc->files, fd);
> /* can't restart close syscall because file table entry was cleared */
> if (unlikely(retval == -ERESTARTSYS ||
> @@ -920,7 +932,8 @@ static long task_close_fd(struct binder_proc *proc,
> unsigned int fd)
> retval == -ERESTARTNOHAND ||
> retval == -ERESTART_RESTARTBLOCK))
> retval = -EINTR;
> -
> +err:
> + mutex_unlock(&proc->files_lock);
> return retval;
> }
>
> @@ -4605,7 +4618,9 @@ static int binder_mmap(struct file *filp, struct
> vm_area_struct *vma)
> ret = binder_alloc_mmap_handler(&proc->alloc, vma);
> if (ret)
> return ret;
> + mutex_lock(&proc->files_lock);
> proc->files = get_files_struct(current);
> + mutex_unlock(&proc->files_lock);
> return 0;
>
> err_bad_arg:
> @@ -4629,6 +4644,7 @@ static int binder_open(struct inode *nodp, struct file
> *filp)
> spin_lock_init(&proc->outer_lock);
> get_task_struct(current->group_leader);
> proc->tsk = current->group_leader;
> + mutex_init(&proc->files_lock);
> INIT_LIST_HEAD(&proc->todo);
>
Re: [ANNOUNCE] 4.1.46-rt52
On Mon, Dec 11, 2017 at 03:01:39PM -0600, Corey Minyard wrote: > On 12/11/2017 02:20 PM, Julia Cartwright wrote: > > On Mon, Dec 11, 2017 at 01:04:58PM -0600, Corey Minyard wrote: [..] > > > > > > > > Sebastian Andrzej Siewior (2): > > > > PM / CPU: replace raw_notifier with atomic_notifier (fixup) > > > This change breaks the compile of 4.1 on ARM (and other things using > > > kernel/cpu_pm.c). > > > > > > rcu_irq_enter_irqson() and friends doesn't exist in 4.1. In fact, > > > rcu_irq_enter() doesn't even exist. > > > > > > Sorry I didn't get to testing this earlier, I've been focused on other > > > things. > > Thanks! My current builds apparently don't currently cover CPU_PM > > builds, so I didn't see this :(. Thanks for the report. > > > > v4.1 does contain rcu_irq_enter(), and it looks like what we should be > > using in 4.1 instead. > > Ah, it does, I looked in the wrong place. > > > I'm thinking the below should be okay; I'll be standing up a proper cpu > > hotplugging test to give it some runtime. > > The below should work. You'll need an ARM64, ARM or MIPS system with > the proper config settings to exercise this code, though. Shouldn't be a problem, I've got an ARM64 board that I've been meaning to integrate into my testing anyway. Thanks, Julia
Re: [REGRESSION][4.13.y][4.14.y][v4.15.y] net: reduce skb_warn_bad_offload() noise
On Mon, Dec 11, 2017 at 3:35 PM, Joseph Salisbury
wrote:
> Hi Eric,
>
> A kernel bug report was opened against Ubuntu [0]. It was found that
> reverting the following commit resolved this bug:
The recorded trace in that bug is against 4.10.0 with some backports.
Given that commit b2504a5dbef3 ("net: reduce skb_warn_bad_offload()
noise") is implicated, I guess that that was backported from 4.11-rc1.
The WARN shows
e1000e: caps=(0x0030002149a9, 0x)
len=1701 data_len=1659 gso_size=1480 gso_type=2 ip_summed=0
The numbering changed in 4.14, but for this kernel
SKB_GSO_UDP = 1 << 1,
so this is a UFO packet with CHECKSUM_NONE. The stack shows
kernel: [570943.494549] skb_warn_bad_offload+0xd1/0x120
kernel: [570943.494550] __skb_gso_segment+0x17d/0x190
kernel: [570943.494564] validate_xmit_skb+0x14f/0x2a0
kernel: [570943.494565] validate_xmit_skb_list+0x43/0x70
so if that patch has been backported, then this must trigger in
__skb_gso_segment on the return path from skb_mac_gso_segment.
Did you backport
commit 8d63bee643f1fb53e472f0e135cae4eb99d62d19
Author: Willem de Bruijn
Date: Tue Aug 8 14:22:55 2017 -0400
net: avoid skb_warn_bad_offload false positives on UFO
skb_warn_bad_offload triggers a warning when an skb enters the GSO
stack at __skb_gso_segment that does not have CHECKSUM_PARTIAL
checksum offload set.
Commit b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
observed that SKB_GSO_DODGY producers can trigger the check and
that passing those packets through the GSO handlers will fix it
up. But, the software UFO handler will set ip_summed to
CHECKSUM_NONE.
When __skb_gso_segment is called from the receive path, this
triggers the warning again.
Make UFO set CHECKSUM_UNNECESSARY instead of CHECKSUM_NONE. On
Tx these two are equivalent. On Rx, this better matches the
skb state (checksum computed), as CHECKSUM_NONE here means no
checksum computed.
See also this thread for context:
http://patchwork.ozlabs.org/patch/799015/
Fixes: b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
Signed-off-by: Willem de Bruijn
Signed-off-by: David S. Miller
Note that UFO was removed in 4.14 and that skb_warn_bad_offload
can happen for various types of packets, so there may be multiple
independent bug reports. I'm investigating two other non-UFO reports
just now.
[PATCH] arch: define weak abort
gcc was generating abort due to 'divide by zero' and if it is not
defined in the toolchain the build fails.
Currently 'frv' and 'arc' are failing. Previously other arch was also
broken like m32r was fixed by d22e3d69ee1a ("m32r: fix build failure").
Lets define this weak function which is common for all arch and fix the
problem permanently. We can even remove the arch specific 'abort' after
this is done.
Cc: Alexey Brodkin
Signed-off-by: Sudip Mukherjee
---
kernel/exit.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/exit.c b/kernel/exit.c
index af6c245..90c6869 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1759,3 +1759,11 @@ long kernel_wait4(pid_t upid, int __user *stat_addr, int
options,
return -EFAULT;
}
#endif
+
+__weak void abort(void)
+{
+ BUG();
+
+ /* if that doesn't kill us, halt */
+ panic("Oops failed to kill thread");
+}
--
1.9.1
Re: [REGRESSION][4.13.y][4.14.y][v4.15.y] net: reduce skb_warn_bad_offload() noise
From: Joseph Salisbury Date: Mon, 11 Dec 2017 15:35:34 -0500 > A kernel bug report was opened against Ubuntu [0]. It was found that > reverting the following commit resolved this bug: > > commit b2504a5dbef3305ef41988ad270b0e8ec289331c > Author: Eric Dumazet > Date: Tue Jan 31 10:20:32 2017 -0800 > > net: reduce skb_warn_bad_offload() noise > > > The regression was introduced as of v4.11-rc1 and still exists in > current mainline. > > I was hoping to get your feedback, since you are the patch author. Do > you think gathering any additional data will help diagnose this issue, > or would it be best to submit a revert request? > > This commit did in fact resolve another bug[1], but in the process > introduced this regression. It helps if you can consolidate the information obtained in your bug tracking here in the email so that people on this list can get an idea of what the problem scope might be without having to go to your special bug tracking site. This is really not about us being snobs about this mailing list, it's about you wanting to get a result. And you'll get a better result faster if you post the details here on the lsit because most developers are not going to go to your bug tracking site to read the bug comments. Also, this isn't a functional regression, it is just that we are generating warnings that we didn't before. It doesn't mean that Eric's patch is wrong, it could just be that his new check is triggering for a bug that has always been there. Scanning the bug myself it seems that the critical required component is IPSEC, and IPSEC has it's own way of doing segmentation offload. Thanks.
[PATCH v3 0/2] hwmon (pmbus): cffps: Add debugfs entries
From: "Edward A. James" This series enables debugfs entries in the IBM common form factor power supply driver. In order to avoid multiple debugfs directories for the same driver, the first patch in the series allows a pmbus client driver to query pmbus core for it's debugfs directory. The second patch in the series adds debugfs files for a number of attributes of the power supply, including FRU (field replaceable unit) number, firmware version, part number, serial number, and CCIN. There is also an entry for the psu "input history" in binary format. This data represents previous 10 minutes of power supply data. Changes since v2: - CCIN is big-endian and has to be swapped. Changes since v1: - Check for debugfs directory before allocating memory. - Add cffps1 sub-directory for the debugfs entries. - Always set last_update to jiffies - HZ. - Add EXPORT_SYMBOL_GPL for pmbus_get_debugfs_dir(). Edward A. James (2): hwmon (pmbus): Export pmbus device debugfs directory entry hwmon (pmbus): cffps: Add debugfs entries drivers/hwmon/pmbus/ibm-cffps.c | 202 ++- drivers/hwmon/pmbus/pmbus.h | 2 + drivers/hwmon/pmbus/pmbus_core.c | 8 ++ 3 files changed, 211 insertions(+), 1 deletion(-) -- 1.8.3.1
[PATCH v3 2/2] hwmon (pmbus): cffps: Add debugfs entries
From: "Edward A. James"
Add debugfs entries for additional power supply data, including part
number, serial number, FRU number, firmware revision, ccin, and the
input history of the power supply. The input history is 10 minutes of
input power data in the form of twenty 30-second packets. Each packet
contains average and maximum power for that 30 second period.
Signed-off-by: Edward A. James
---
drivers/hwmon/pmbus/ibm-cffps.c | 202 +++-
1 file changed, 201 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pmbus/ibm-cffps.c b/drivers/hwmon/pmbus/ibm-cffps.c
index cb56da6..5376f04 100644
--- a/drivers/hwmon/pmbus/ibm-cffps.c
+++ b/drivers/hwmon/pmbus/ibm-cffps.c
@@ -8,12 +8,26 @@
*/
#include
+#include
#include
+#include
#include
+#include
#include
+#include
#include "pmbus.h"
+#define CFFPS_FRU_CMD 0x9A
+#define CFFPS_PN_CMD 0x9B
+#define CFFPS_SN_CMD 0x9E
+#define CFFPS_CCIN_CMD 0xBD
+#define CFFPS_FW_CMD_START 0xFA
+#define CFFPS_FW_NUM_BYTES 4
+
+#define CFFPS_INPUT_HISTORY_CMD0xD6
+#define CFFPS_INPUT_HISTORY_SIZE 100
+
/* STATUS_MFR_SPECIFIC bits */
#define CFFPS_MFR_FAN_FAULTBIT(0)
#define CFFPS_MFR_THERMAL_FAULTBIT(1)
@@ -24,6 +38,144 @@
#define CFFPS_MFR_VAUX_FAULT BIT(6)
#define CFFPS_MFR_CURRENT_SHARE_WARNINGBIT(7)
+enum {
+ CFFPS_DEBUGFS_INPUT_HISTORY = 0,
+ CFFPS_DEBUGFS_FRU,
+ CFFPS_DEBUGFS_PN,
+ CFFPS_DEBUGFS_SN,
+ CFFPS_DEBUGFS_CCIN,
+ CFFPS_DEBUGFS_FW,
+ CFFPS_DEBUGFS_NUM_ENTRIES
+};
+
+struct ibm_cffps_input_history {
+ struct mutex update_lock;
+ unsigned long last_update;
+
+ u8 byte_count;
+ u8 data[CFFPS_INPUT_HISTORY_SIZE];
+};
+
+struct ibm_cffps {
+ struct i2c_client *client;
+
+ struct ibm_cffps_input_history input_history;
+
+ int debugfs_entries[CFFPS_DEBUGFS_NUM_ENTRIES];
+};
+
+#define to_psu(x, y) container_of((x), struct ibm_cffps, debugfs_entries[(y)])
+
+static ssize_t ibm_cffps_read_input_history(struct ibm_cffps *psu,
+ char __user *buf, size_t count,
+ loff_t *ppos)
+{
+ int rc;
+ u8 msgbuf0[1] = { CFFPS_INPUT_HISTORY_CMD };
+ u8 msgbuf1[CFFPS_INPUT_HISTORY_SIZE + 1] = { 0 };
+ struct i2c_msg msg[2] = {
+ {
+ .addr = psu->client->addr,
+ .flags = psu->client->flags,
+ .len = 1,
+ .buf = msgbuf0,
+ }, {
+ .addr = psu->client->addr,
+ .flags = psu->client->flags | I2C_M_RD,
+ .len = CFFPS_INPUT_HISTORY_SIZE + 1,
+ .buf = msgbuf1,
+ },
+ };
+
+ if (!*ppos) {
+ mutex_lock(&psu->input_history.update_lock);
+ if (time_after(jiffies, psu->input_history.last_update + HZ)) {
+ /*
+* Use a raw i2c transfer, since we need more bytes
+* than Linux I2C supports through smbus xfr (only 32).
+*/
+ rc = i2c_transfer(psu->client->adapter, msg, 2);
+ if (rc < 0) {
+ mutex_unlock(&psu->input_history.update_lock);
+ return rc;
+ }
+
+ psu->input_history.byte_count = msgbuf1[0];
+ memcpy(psu->input_history.data, &msgbuf1[1],
+ CFFPS_INPUT_HISTORY_SIZE);
+ psu->input_history.last_update = jiffies;
+ }
+
+ mutex_unlock(&psu->input_history.update_lock);
+ }
+
+ return simple_read_from_buffer(buf, count, ppos,
+ psu->input_history.data,
+ psu->input_history.byte_count);
+}
+
+static ssize_t ibm_cffps_debugfs_op(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ u8 cmd;
+ int i, rc;
+ int *idxp = file->private_data;
+ int idx = *idxp;
+ struct ibm_cffps *psu = to_psu(idxp, idx);
+ char data[I2C_SMBUS_BLOCK_MAX] = { 0 };
+
+ switch (idx) {
+ case CFFPS_DEBUGFS_INPUT_HISTORY:
+ return ibm_cffps_read_input_history(psu, buf, count, ppos);
+ case CFFPS_DEBUGFS_FRU:
+ cmd = CFFPS_FRU_CMD;
+ break;
+ case CFFPS_DEBUGFS_PN:
+ cmd = CFFPS_PN_CMD;
+ break;
+ case CFFPS_DEBUGFS_SN:
+ cmd = CFFPS_SN_CMD;
+
[PATCH v3 1/2] hwmon (pmbus): Export pmbus device debugfs directory entry
From: "Edward A. James"
Pmbus client drivers, if they want to use debugfs, should use the same
root directory as the pmbus debugfs entries are using. Therefore, export
the device dentry for the pmbus client.
Signed-off-by: Edward A. James
---
drivers/hwmon/pmbus/pmbus.h | 2 ++
drivers/hwmon/pmbus/pmbus_core.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index d39d506..1d24397 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -461,4 +461,6 @@ int pmbus_get_fan_rate_cached(struct i2c_client *client,
int page, int id,
enum pmbus_fan_mode mode);
int pmbus_update_fan(struct i2c_client *client, int page, int id,
u8 config, u8 mask, u16 command);
+struct dentry *pmbus_get_debugfs_dir(struct i2c_client *client);
+
#endif /* PMBUS_H */
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 99ab39f..f7c47d7 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -2381,6 +2381,14 @@ int pmbus_do_remove(struct i2c_client *client)
}
EXPORT_SYMBOL_GPL(pmbus_do_remove);
+struct dentry *pmbus_get_debugfs_dir(struct i2c_client *client)
+{
+ struct pmbus_data *data = i2c_get_clientdata(client);
+
+ return data->debugfs;
+}
+EXPORT_SYMBOL_GPL(pmbus_get_debugfs_dir);
+
static int __init pmbus_core_init(void)
{
pmbus_debugfs_dir = debugfs_create_dir("pmbus", NULL);
--
1.8.3.1
Re: [PATCH v4 5/5] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
Hi Hartley,
> On Thursday, November 30, 2017 4:52 PM, Lukasz Majewski wrote:
> >
> > The BK3 board is a derivative of the ts72xx reference design.
>
> Lukasz,
>
> I was just reviewing the other TS-72xx boards and noticed this:
>
>
>
> > +/* BK3 specific defines */
> > +#define BK3_CPLDVER_PHYS_BASE 0x2340
> > +#define BK3_CPLDVER_VIRT_BASE 0xfebfd000
> > +#define BK3_CPLDVER_SIZE 0x1000
> > +
>
>
>
> > +static struct map_desc bk3_io_desc[] __initdata = {
> > + {
> > + .virtual= BK3_CPLDVER_VIRT_BASE,
> > + .pfn=
> > __phys_to_pfn(BK3_CPLDVER_PHYS_BASE),
> > + .length = BK3_CPLDVER_SIZE,
> > + .type = MT_DEVICE,
> > + }
> > +};
> > +
>
> This register appears to be common to all the TS-72xx boards.
The CPLD was used on the reference ts-72xx boards, but support for it
seems to not be present in the mainline kernel.
Do you have a ts72xx board with CPLD embedded? Is any of your design
using it?
My another concern - is it safe to perform IO mapping on memory regions
which are not used / specified? When I do a single ts72xx mapping - for
all boards - then we may end up with some mappings which are not needed.
With the code as it is - I only map regions which are already used on
relevant boards.
>
> I don't think Arnd has pulled the series yet. Would you mind renaming
> the defines and rebasing this patch?
If needed I can resend the patch series, or prepare a single fix patch.
No problem.
> The BK3 board and other TS-72xx
> boards can then have a common .map_io.
>
> Thanks,
> Hartley
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
pgpc4g3ZF32Fi.pgp
Description: OpenPGP digital signature
Re: [PATCH v9 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver
Dan,
On 12/11/2017 07:26 PM, Dan Murphy wrote:
> This adds the devicetree bindings for the LM3692x
> I2C LED string driver.
>
> Acked-by: Pavel Machek
> Signed-off-by: Dan Murphy
> ---
>
> v9 - Moved 2 nodes to Optional Child and renamed node names to device type
> https://patchwork.kernel.org/patch/10093757/
>
> v8 - Added address-cells and size-cells as well as child node reg -
> https://patchwork.kernel.org/patch/10091259/
> v7 - No changes - https://patchwork.kernel.org/patch/10087475/
> v6 - No changes -https://patchwork.kernel.org/patch/10085567/
> v5 - No Changes - https://patchwork.kernel.org/patch/10081071/
> v4 - Fix example node, added trigger entry, removed ambiguous x for
> compatible and
> added common.txt pointer for label -
> https://patchwork.kernel.org/patch/10060107
> v3 - No changes
> v2 - No changes - https://patchwork.kernel.org/patch/10056677/
>
> .../devicetree/bindings/leds/leds-lm3692x.txt | 49
> ++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3692x.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
> b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
> new file mode 100644
> index ..a93e19edfb42
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
> @@ -0,0 +1,49 @@
> +* Texas Instruments - LM3692x Highly Efficient White LED Driver
> +
> +The LM3692x is an ultra-compact, highly efficient,
> +white-LED driver designed for LCD display backlighting.
> +
> +The main difference between the LM36922 and LM36923 is the number of
> +LED strings it supports. The LM36922 supports two strings while the LM36923
> +supports three strings.
> +
> +Required properties:
> + - compatible:
> + "ti,lm36922"
> + "ti,lm36923"
> + - reg : I2C slave address
> + - #address-cells : 1
> + - #size-cells : 0
> +
> +Optional properties:
> + - enable-gpios : gpio pin to enable/disable the device.
> + - vled-supply : LED supply
> +
> +Required child properties:
> + - reg : 0
> +
> +Optional child properties:
> + - label : see Documentation/devicetree/bindings/leds/common.txt
> + - linux,default-trigger :
> +see Documentation/devicetree/bindings/leds/common.txt
> +
> +Example:
> +
> +led-controller@36 {
> + compatible = "ti,lm3692x";
> + reg = <0x36>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> + vled-supply = <&vbatt>;
> +
> + led@0 {
> + reg = <0>;
> + label = "backlight_cluster";
We need to consequently adhere to LED class device naming
convention, so:
label = "white:backlight_cluster";
> + linux,default-trigger = "backlight";
> + };
> +}
> +
> +For more product information please see the link below:
> +http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH] docs: refcount_t documentation
On Tue, 5 Dec 2017 12:46:35 +0200 Elena Reshetova wrote: > Some functions from refcount_t API provide different > memory ordering guarantees that their atomic counterparts. > This adds a document outlining these differences ( > Documentation/core-api/refcount-vs-atomic.rst) as well as > some other minor improvements. I've applied this, thanks, it looks good. One thing I noticed, though, is that this landed in the core-api manual, while the refcount_t documentation is in the driver-api manual. The cross-references work just fine and such, but this still doesn't seem quite right. Probably what should be done is to have all the refcount_t material in core-api; I may do that if I get a moment. Thanks, jon
Re: [PATCH] media: pxa_camera: disable and unprepare the clock source on error
Hi Flavio, On Monday, 11 December 2017 23:05:46 EET Flavio Ceolin wrote: > > On Wednesday, 6 December 2017 18:38:50 EET Flavio Ceolin wrote: > >> pxa_camera_probe() was not calling pxa_camera_deactivate(), > >> responsible to call clk_disable_unprepare(), on the failure path. This > >> was leading to unbalancing source clock. > >> > >> Found by Linux Driver Verification project (linuxtesting.org). > > > > Any chance I could sign you up for more work on this driver ? :-) > > Definetely, this would be great :) Actually it looks like the work I thought was needed has already been performed. The pxa-camera driver used to make use of the soc-camera framework, which we are trying to remove, and occurrences of soc_camera in the code gave me the wrong idea that the driver was still based on that framework. It seems this isn't the case. Thank you for making me happy :-) > >> Signed-off-by: Flavio Ceolin > > > > Reviewed-by: Laurent Pinchart > > > > I expect Hans Verkuil to pick up the patch. > > > >> --- > >> > >> drivers/media/platform/pxa_camera.c | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/media/platform/pxa_camera.c > >> b/drivers/media/platform/pxa_camera.c index 9d3f0cb..7877037 100644 > >> --- a/drivers/media/platform/pxa_camera.c > >> +++ b/drivers/media/platform/pxa_camera.c > >> @@ -2489,7 +2489,7 @@ static int pxa_camera_probe(struct platform_device > >> *pdev) > >>dev_set_drvdata(&pdev->dev, pcdev); > >>err = v4l2_device_register(&pdev->dev, &pcdev->v4l2_dev); > >>if (err) > >> - goto exit_free_dma; > >> + goto exit_deactivate; > >> > >>pcdev->asds[0] = &pcdev->asd; > >>pcdev->notifier.subdevs = pcdev->asds; > >> @@ -2525,6 +2525,8 @@ static int pxa_camera_probe(struct platform_device > >> *pdev) > >>v4l2_clk_unregister(pcdev->mclk_clk); > >> exit_free_v4l2dev: > >>v4l2_device_unregister(&pcdev->v4l2_dev); > >> +exit_deactivate: > >> + pxa_camera_deactivate(pcdev); > >> exit_free_dma: > >>dma_release_channel(pcdev->dma_chans[2]); > >> exit_free_dma_u: -- Regards, Laurent Pinchart
Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray
On Sat, Dec 09, 2017 at 09:00:18AM -0800, Joe Perches wrote: > On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote: > > 1. Using lockdep_set_novalidate_class() for anything other > > than device->mutex will throw checkpatch warnings. Nice. (*) > [] > > (*) checkpatch.pl is considered mostly harmful round here, too, > > but that's another rant > > How so? Short story is that it barfs all over the slightly non-standard coding style used in XFS. It generates enough noise on incidental things we aren't important that it complicates simple things. e.g. I just moved a block of defines from one header to another, and checkpatch throws about 10 warnings on that because of whitespace. I'm just moving code - I don't want to change it and it doesn't need to be modified because it is neat and easy to read and is obviously correct. A bunch of prototypes I added another parameter to gets warnings because it uses "unsigned" for an existing parameter that I'm not changing. And so on. This sort of stuff is just lowest-common-denominator noise - great for new code and/or inexperienced developers, but not for working with large bodies of existing code with slightly non-standard conventions. Churning *lots* of code we otherwise wouldn't touch just to shut up checkpatch warnings takes time, risks regressions and makes it harder to trace the history of the code when we are trying to track down bugs. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH v5] kernel: make groups_sort calling a responsibility group_info allocators
On Mon, Dec 11 2017, Thiago Rafael Becker wrote:
> In testing, we found that nfsd threads may call set_groups in parallel for
> the same entry cached in auth.unix.gid, racing in the call of groups_sort,
> corrupting the groups for that entry and leading to permission denials for
> the client.
>
> This patch:
> - Make groups_sort globally visible.
> - Move the call to groups_sort to the modifiers of group_info
> - Remove the call to groups_sort from set_groups
>
> Signed-off-by: Thiago Rafael Becker
Reviewed-by: NeilBrown
Thanks. I like this better as a single patch.
I'd probably suggest "Cc: sta...@vger.kernel.org".
Less important bugfixes have gone to stable...
It might be nice to enhance
Documentation/security/credentials.rst
to explain that the groups list is always sorted, and must be sorted
before set_groups() or set_current_groups() is called, but
as the document doesn't mention any of this at all, this is purely
an extra enhancement and doesn't need to be included in the same patch.
David: do you agree that this sort of content would be appropriate in
that file (which you apparently authored). Would you like to update it,
or shall I?
Thanks,
NeilBrown
> ---
> arch/s390/kernel/compat_linux.c | 1 +
> fs/nfsd/auth.c| 3 +++
> include/linux/cred.h | 1 +
> kernel/groups.c | 5 +++--
> kernel/uid16.c| 1 +
> net/sunrpc/auth_gss/gss_rpc_xdr.c | 1 +
> net/sunrpc/auth_gss/svcauth_gss.c | 1 +
> net/sunrpc/svcauth_unix.c | 2 ++
> 8 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/s390/kernel/compat_linux.c b/arch/s390/kernel/compat_linux.c
> index f04db37..59eea9c 100644
> --- a/arch/s390/kernel/compat_linux.c
> +++ b/arch/s390/kernel/compat_linux.c
> @@ -263,6 +263,7 @@ COMPAT_SYSCALL_DEFINE2(s390_setgroups16, int, gidsetsize,
> u16 __user *, grouplis
> return retval;
> }
>
> + groups_sort(group_info);
> retval = set_current_groups(group_info);
> put_group_info(group_info);
>
> diff --git a/fs/nfsd/auth.c b/fs/nfsd/auth.c
> index 697f8ae..f650e47 100644
> --- a/fs/nfsd/auth.c
> +++ b/fs/nfsd/auth.c
> @@ -60,6 +60,9 @@ int nfsd_setuser(struct svc_rqst *rqstp, struct svc_export
> *exp)
> gi->gid[i] = exp->ex_anon_gid;
> else
> gi->gid[i] = rqgi->gid[i];
> +
> + /* Each thread allocates its own gi, no race */
> + groups_sort(gi);
> }
> } else {
> gi = get_group_info(rqgi);
> diff --git a/include/linux/cred.h b/include/linux/cred.h
> index 099058e..6312865 100644
> --- a/include/linux/cred.h
> +++ b/include/linux/cred.h
> @@ -83,6 +83,7 @@ extern int set_current_groups(struct group_info *);
> extern void set_groups(struct cred *, struct group_info *);
> extern int groups_search(const struct group_info *, kgid_t);
> extern bool may_setgroups(void);
> +extern void groups_sort(struct group_info *);
>
> /*
> * The security context of a task
> diff --git a/kernel/groups.c b/kernel/groups.c
> index e357bc8..daae2f2 100644
> --- a/kernel/groups.c
> +++ b/kernel/groups.c
> @@ -86,11 +86,12 @@ static int gid_cmp(const void *_a, const void *_b)
> return gid_gt(a, b) - gid_lt(a, b);
> }
>
> -static void groups_sort(struct group_info *group_info)
> +void groups_sort(struct group_info *group_info)
> {
> sort(group_info->gid, group_info->ngroups, sizeof(*group_info->gid),
>gid_cmp, NULL);
> }
> +EXPORT_SYMBOL(groups_sort);
>
> /* a simple bsearch */
> int groups_search(const struct group_info *group_info, kgid_t grp)
> @@ -122,7 +123,6 @@ int groups_search(const struct group_info *group_info,
> kgid_t grp)
> void set_groups(struct cred *new, struct group_info *group_info)
> {
> put_group_info(new->group_info);
> - groups_sort(group_info);
> get_group_info(group_info);
> new->group_info = group_info;
> }
> @@ -206,6 +206,7 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user
> *, grouplist)
> return retval;
> }
>
> + groups_sort(group_info);
> retval = set_current_groups(group_info);
> put_group_info(group_info);
>
> diff --git a/kernel/uid16.c b/kernel/uid16.c
> index ce74a49..ef1da2a 100644
> --- a/kernel/uid16.c
> +++ b/kernel/uid16.c
> @@ -192,6 +192,7 @@ SYSCALL_DEFINE2(setgroups16, int, gidsetsize, old_gid_t
> __user *, grouplist)
> return retval;
> }
>
> + groups_sort(group_info);
> retval = set_current_groups(group_info);
> put_group_info(group_info);
>
> diff --git a/net/sunrpc/auth_gss/gss_rpc_xdr.c
> b/net/sunrpc/auth_gss/gss_rpc_xdr.c
> index c4778ca..444380f 100644
> --- a/net/sunrpc/auth_gss/gss_rpc_xdr.c
> +++ b/net/sunrpc/auth_gss/gss_rpc_xdr.c
> @@ -231,6 +231,7 @@ static int gssx_dec_linux_creds(struct xdr_stream *xdr,
>
Re: [REGRESSION][4.13.y][4.14.y][v4.15.y] net: reduce skb_warn_bad_offload() noise
On Mon, Dec 11, 2017 at 04:25:26PM -0500, Willem de Bruijn wrote: > Note that UFO was removed in 4.14 and that skb_warn_bad_offload > can happen for various types of packets, so there may be multiple > independent bug reports. I'm investigating two other non-UFO reports > just now. Meta-comment, now that UFO is gone from mainline, I'm wondering if I should just delete it from 4.4 and 4.9 as well. Any objections for that? I'd like to make it easy to maintain these kernels for a while, and having them diverge like this, with all of the issues around UFO, seems like it will just make life harder for myself if I leave it in. Any opinions? thanks, greg k-h
Re: [PATCH v3] binder: fix proc->files use-after-free
On Mon, Dec 11, 2017 at 01:23:28PM -0800, Todd Kjos wrote: > Greg- when this is in, we'll want it in 4.14 as well. Ugh, missed that, I'll be sure to mark it for stable, thanks for letting me know. greg k-h
[PATCH] phy: rockchip-typec: Try to turn the PHY on several times
Bind / unbind stress testing of the USB controller on rk3399 found
that we'd often end up with lots of failures that looked like this:
phy phy-ff80.phy.9: phy poweron failed --> -110
dwc3 fe90.dwc3: failed to initialize core
dwc3: probe of fe90.dwc3 failed with error -110
Those errors were sometimes seen at bootup too, in which case USB
peripherals wouldn't work until unplugged and re-plugged in.
I spent some time trying to figure out why the PHY was failing to
power on but I wasn't able to. Possibly this has to do with the fact
that the PHY docs say that the USB controller "needs to be held in
reset to hold pipe power state in P2 before initializing the Type C
PHY" but that doesn't appear to be easy to do with the dwc3 driver
today. Messing around with the ordering of the reset vs. the PHY
initialization in the dwc3 driver didn't seem to fix things.
I did, however, find that if I simply retry the power on it seems to
have a good chance of working. So let's add some retries. I ran a
pretty tight bind/unbind loop overnight. When I did so, I found that
I need to retry between 1% and 2% of the time. Overnight I found only
a small handful of times where I needed 2 retries. I never found a
case where I needed 3 retries.
I'm completely aware of the fact that this is quite an ugly hack and I
wish I didn't have to resort to it, but I have no other real idea how
to make this hardware reliable. If Rockchip in the future can come up
with a solution we can always revert this hack. Until then, let's at
least have something that works.
This patch is tested atop Enric's latest dwc3 patch series ending at:
https://patchwork.kernel.org/patch/10095527/
...but it could be applied independently of that series without any
bad effects.
For some more details on this bug, you can refer to:
https://bugs.chromium.org/p/chromium/issues/detail?id=783464
Signed-off-by: Douglas Anderson
---
drivers/phy/rockchip/phy-rockchip-typec.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c
b/drivers/phy/rockchip/phy-rockchip-typec.c
index ee85fa0ca4b0..5c2157156ce1 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -349,6 +349,8 @@
#define MODE_DFP_USB BIT(1)
#define MODE_DFP_DPBIT(2)
+#define POWER_ON_TRIES 5
+
struct usb3phy_reg {
u32 offset;
u32 enable_bit;
@@ -818,9 +820,8 @@ static int tcphy_get_mode(struct rockchip_typec_phy *tcphy)
return mode;
}
-static int rockchip_usb3_phy_power_on(struct phy *phy)
+static int _rockchip_usb3_phy_power_on(struct rockchip_typec_phy *tcphy)
{
- struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
struct rockchip_usb3phy_port_cfg *cfg = &tcphy->port_cfgs;
const struct usb3phy_reg *reg = &cfg->pipe_status;
int timeout, new_mode, ret = 0;
@@ -867,6 +868,25 @@ static int rockchip_usb3_phy_power_on(struct phy *phy)
return ret;
}
+static int rockchip_usb3_phy_power_on(struct phy *phy)
+{
+ struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
+ int ret;
+ int tries;
+
+ for (tries = 0; tries < POWER_ON_TRIES; tries++) {
+ ret = _rockchip_usb3_phy_power_on(tcphy);
+ if (!ret)
+ break;
+ }
+
+ if (tries && !ret)
+ dev_info(tcphy->dev, "Needed %d loops to turn on\n", tries);
+
+ return ret;
+}
+
+
static int rockchip_usb3_phy_power_off(struct phy *phy)
{
struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
--
2.15.1.424.g9478a66081-goog
[GIT PULL] workqueue fixes for v4.15-rc1
Hello, * Lai's hotplug simplifications inadvertently fix a possible deadlock involving cpuset and workqueue. * CPU isolation fix which was reverted due to the changes in the housekeeping code resurrected. * A trivial unused include removal. Thanks. The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-4.15-fixes for you to fetch changes up to 01dfee9582d9b4403c4902df096ed8b43d55181c: workqueue: remove unneeded kallsyms include (2017-12-11 07:15:43 -0800) Lai Jiangshan (2): workqueue/hotplug: simplify workqueue_offline_cpu() workqueue/hotplug: remove the workaround in rebind_workers() Sergey Senozhatsky (1): workqueue: remove unneeded kallsyms include Tal Shorer (2): main: kernel_start: move housekeeping_init() before workqueue_init_early() workqueue: respect isolated cpus when queueing an unbound work init/main.c| 7 ++- kernel/workqueue.c | 33 - 2 files changed, 18 insertions(+), 22 deletions(-) -- tejun
Re: [PATCH] Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops
On Thu, Nov 16, 2017 at 10:07 PM, Marcel Holtmann wrote:
> Hi Lukas,
>
>> John Stultz reports a boot time crash with the HiKey board (which uses
>> hci_serdev) occurring in hci_uart_tx_wakeup(). That function is
>> contained in hci_ldisc.c, but also called from the newer hci_serdev.c.
>> It acquires the proto_lock in struct hci_uart and it turns out that we
>> forgot to init the lock in the serdev code path, thus causing the crash.
>>
>> John bisected the crash to commit 67d2f8781b9f ("Bluetooth: hci_ldisc:
>> Allow sleeping while proto locks are held"), but the issue was present
>> before and the commit merely exposed it. (Perhaps by luck, the crash
>> did not occur with rwlocks.)
>>
>> Init the proto_lock in the serdev code path to avoid the oops.
>>
[snip]
> patch has been applied to bluetooth-next tree.
Sorry to be a nuisance if its just a timing thing, but I wanted to
follow up on this just to make sure it didn't fall through the cracks,
as I noticed w/ -rc3 it hasn't landed yet.
thanks
-john
Re: [PATCH RESEND] KVM: X86: Fix load bad host fpu state
2017-12-12 4:48 GMT+08:00 David Hildenbrand :
> On 10.12.2017 22:44, Wanpeng Li wrote:
>> From: Wanpeng Li
>>
>> [ cut here ]
>> Bad FPU state detected at kvm_put_guest_fpu+0xd8/0x2d0 [kvm],
>> reinitializing FPU registers.
>> WARNING: CPU: 1 PID: 4594 at arch/x86/mm/extable.c:103
>> ex_handler_fprestore+0x88/0x90
>> CPU: 1 PID: 4594 Comm: qemu-system-x86 Tainted: GB OE
>> 4.15.0-rc2+ #10
>> RIP: 0010:ex_handler_fprestore+0x88/0x90
>> Call Trace:
>> fixup_exception+0x4e/0x60
>> do_general_protection+0xff/0x270
>> general_protection+0x22/0x30
>> RIP: 0010:kvm_put_guest_fpu+0xd8/0x2d0 [kvm]
>> RSP: 0018:8803d5627810 EFLAGS: 00010246
>> kvm_vcpu_reset+0x3b4/0x3c0 [kvm]
>> kvm_apic_accept_events+0x1c0/0x240 [kvm]
>> kvm_arch_vcpu_ioctl_run+0x1658/0x2fb0 [kvm]
>> kvm_vcpu_ioctl+0x479/0x880 [kvm]
>> do_vfs_ioctl+0x142/0x9a0
>> SyS_ioctl+0x74/0x80
>> do_syscall_64+0x15f/0x600
>>
>> This can be reproduced by running any testcase in kvm-unit-tests since
>> the qemu userspace FPU context is not initialized, which results in the
>> init path from kvm_apic_accept_events() will load/put qemu userspace
>> FPU context w/o initialized. In addition, w/o this splatting we still
>> should initialize vcpu->arch.user_fpu instead of current->thread.fpu.
>> This patch fixes it by initializing qemu user FPU context if it is
>> uninitialized before KVM_RUN.
>>
>> Cc: Paolo Bonzini
>> Cc: Radim Krčmář
>> Cc: Rik van Riel
>> Cc: sta...@vger.kernel.org
>> Fixes: f775b13eedee (x86,kvm: move qemu/guest FPU switching out to vcpu_run)
>> Signed-off-by: Wanpeng Li
>> ---
>> arch/x86/kvm/x86.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index a92b22f..063a643 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -7273,10 +7273,13 @@ static int complete_emulated_mmio(struct kvm_vcpu
>> *vcpu)
>>
>> int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>> {
>> - struct fpu *fpu = ¤t->thread.fpu;
>> + struct fpu *fpu = &vcpu->arch.user_fpu;
>> int r;
>>
>> - fpu__initialize(fpu);
>> + if (!fpu->initialized) {
>> + fpstate_init(&fpu->state);
>> + fpu->initialized = 1;
>> + }
>
> Is there a chance of keeping using fpu__initialize() ? Duplicating the
> code is ugly.
There is a warning in fpu__initialize() which results in just
current->thread.fpu can take advantage of.
>
> E.g. can't we simply initialize that in kvm_load_guest_fpu?
We still miss to initialize qemu user FPU context for the above calltrace.
Regards,
Wanpeng Li
[GIT PULL] libata fixes for v4.15-rc3
Hello, Linus. Nothing too interesting. David Milburn improved a corner case misbehavior during hotplug. Other than that, minor driver-specific fixes. Thanks. The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.15-fixes for you to fetch changes up to 2dc0b46b5ea30f169b0b272253ea846a5a281731: libata: sata_down_spd_limit should return if driver has not recorded sstatus speed (2017-12-04 13:57:03 -0800) Albert Pool (1): ata: mediatek: Fix typo in module description Arvind Yadav (2): pata_pdc2027x: Remove unnecessary error check pata_pdc2027x : make pdc2027x_*_timing structures const David Milburn (1): libata: sata_down_spd_limit should return if driver has not recorded sstatus speed Matthias Brugger (1): ahci: mtk: Change driver name to ahci-mtk Yuantian Tang (1): ahci: qoriq: refine port register configuration drivers/ata/ahci_mtk.c | 6 +++--- drivers/ata/ahci_qoriq.c| 12 drivers/ata/libata-core.c | 12 +--- drivers/ata/pata_pdc2027x.c | 16 ++-- 4 files changed, 30 insertions(+), 16 deletions(-) -- tejun
Re: [GIT PULL] workqueue fixes for v4.15-rc1
Oops, $SUBJ should have been "workqueue fixes for v4.15-rc3", not rc1. Thanks. -- tejun
Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles.
On Mon, Dec 11 2017, Amir Goldstein wrote: > On Mon, Dec 11, 2017 at 8:04 AM, NeilBrown wrote: >> If a filesystem does not set sb->s_export_op, then it >> does not support filehandles and export_fs_encode_fh() >> and exportfs_encode_inode_fh() should not be called. >> They will use export_encode_fh() is which is a default >> that uses inode number generation number, but in general >> they may not be stable. >> >> So change exportfs_encode_inode_fh() to return FILEID_INVALID >> if called on an unsupported Filesystem. Currently only >> notify/fdinfo can do that. >> > > I wish you would leave this check to the caller, maybe add a helper > exportfs_can_decode_fh() for callers to use. > > Although there are no current uses for it in-tree, there is value in > being able to encode a unique file handle even when it cannot be > decoded back to an open file. > > I am using this property in my fanotify super block watch patches, > where the object identifier on the event is an encoded file handle > of the object, which delegates tracking filesystem objects to > userspace and prevents fanotify from keeping elevated refcounts > on inodes and dentries. > > There are quite a few userspace tools out there that are checking > that st_ino hasn't changed on a file between non atomic operations. > Those tools (or others) could benefit from a unique file handle if > we ever decide to provide a relaxed version of name_to_handle_at(). If the filesystem doesn't define ->s_export_op, then you really cannot trust anything beyond the inode number (and maybe not even that), and the inode number is already easily available. What actual value do you think you get from this pretend-file-handle on filesystems that don't support file handles? If there is a demonstrated need for some sort of identifier that is stronger than an inode number, but not strong enough for open_by_handle_at(), then you should explain that need and propose a well defined interface. You shouldn't use a back-door and hope no-one notices. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH 0/2] mux: add overview and add to driver-api docs
On Mon, 11 Dec 2017 09:29:41 +0100 Peter Rosin wrote: > Don't know if this is worth adding, but it might answer at least a few > questions. > > It looks ok when I view the htmldocs output, but I'm not all that certain > this is good to go? Almost, but I have one request: the new mux.rst file is rather unenlightening for somebody who reads it directly in the docs tree. If you want to keep the bulk of the text in the source I can live with that, but can mux.rst at least get an introductory paragraph saying what it covers (what *is* the mux subsystem?) and why readers might want to go find the rest? Thanks, jon
Re: [PATCH v5] leds: trigger: Introduce a NETDEV trigger
Hi Ben, Thanks for the update. On 12/10/2017 10:17 PM, Ben Whitten wrote: > This commit introduces a NETDEV trigger for named device > activity. Available triggers are link, rx, and tx. > > Signed-off-by: Ben Whitten > > --- > Changes in v5: > Adjust header comment style to be consistent > Changes in v4: > Adopt SPDX licence header > Changes in v3: > Cancel the software blink prior to a oneshot re-queue > Changes in v2: > Sort includes and redate documentation > Correct licence > Remove macro and replace with generic function using enums > Convert blink logic in stats work to use led_blink_oneshot > Uses configured brightness instead of FULL > --- > .../ABI/testing/sysfs-class-led-trigger-netdev | 45 ++ > drivers/leds/trigger/Kconfig | 7 + > drivers/leds/trigger/Makefile | 1 + > drivers/leds/trigger/ledtrig-netdev.c | 496 > + > 4 files changed, 549 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-netdev > create mode 100644 drivers/leds/trigger/ledtrig-netdev.c > > diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev > b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev > new file mode 100644 > index 000..451af6d > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev > @@ -0,0 +1,45 @@ > +What:/sys/class/leds//device_name > +Date:Dec 2017 > +KernelVersion: 4.16 > +Contact: linux-l...@vger.kernel.org > +Description: > + Specifies the network device name to monitor. > + > +What:/sys/class/leds//interval > +Date:Dec 2017 > +KernelVersion: 4.16 > +Contact: linux-l...@vger.kernel.org > +Description: > + Specifies the duration of the LED blink in milliseconds. > + Defaults to 50 ms. > + > +What:/sys/class/leds//link > +Date:Dec 2017 > +KernelVersion: 4.16 > +Contact: linux-l...@vger.kernel.org > +Description: > + Signal the link state of the named network device. > + If set to 0 (default), the LED's normal state is off. > + If set to 1, the LED's normal state reflects the link state > + of the named network device. > + Setting this value also immediately changes the LED state. > + > +What:/sys/class/leds//tx > +Date:Dec 2017 > +KernelVersion: 4.16 > +Contact: linux-l...@vger.kernel.org > +Description: > + Signal transmission of data on the named network device. > + If set to 0 (default), the LED will not blink on transmission. > + If set to 1, the LED will blink for the milliseconds specified > + in interval to signal transmission. > + > +What:/sys/class/leds//rx > +Date:Dec 2017 > +KernelVersion: 4.16 > +Contact: linux-l...@vger.kernel.org > +Description: > + Signal reception of data on the named network device. > + If set to 0 (default), the LED will not blink on reception. > + If set to 1, the LED will blink for the milliseconds specified > + in interval to signal reception. > diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig > index 3f9ddb9..4ec1853 100644 > --- a/drivers/leds/trigger/Kconfig > +++ b/drivers/leds/trigger/Kconfig > @@ -126,4 +126,11 @@ config LEDS_TRIGGER_PANIC > a different trigger. > If unsure, say Y. > > +config LEDS_TRIGGER_NETDEV > + tristate "LED Netdev Trigger" > + depends on NET && LEDS_TRIGGERS > + help > + This allows LEDs to be controlled by network device activity. > + If unsure, say Y. > + > endif # LEDS_TRIGGERS > diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile > index 9f2e868..59e163d 100644 > --- a/drivers/leds/trigger/Makefile > +++ b/drivers/leds/trigger/Makefile > @@ -11,3 +11,4 @@ obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += > ledtrig-default-on.o > obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o > obj-$(CONFIG_LEDS_TRIGGER_CAMERA)+= ledtrig-camera.o > obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o > +obj-$(CONFIG_LEDS_TRIGGER_NETDEV)+= ledtrig-netdev.o > diff --git a/drivers/leds/trigger/ledtrig-netdev.c > b/drivers/leds/trigger/ledtrig-netdev.c > new file mode 100644 > index 000..6df4781 > --- /dev/null > +++ b/drivers/leds/trigger/ledtrig-netdev.c > @@ -0,0 +1,496 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright 2017 Ben Whitten > +// Copyright 2007 Oliver Jowett > +// > +// LED Kernel Netdev Trigger > +// > +// Toggles the LED to reflect the link and traffic state of a named net > device > +// > +// Derived from ledtrig-timer.c which is: > +// Copyright 2005-2006 Openedhand Ltd. > +// Author: Richard Purdie > + > +#include > +#include > +#in
Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray
On Sun, Dec 10, 2017 at 08:23:15PM -0800, Matthew Wilcox wrote:
> On Mon, Dec 11, 2017 at 10:57:45AM +1100, Dave Chinner wrote:
> > i.e. the fact the cmpxchg failed may not have anything to do with a
> > race condtion - it failed because the slot wasn't empty like we
> > expected it to be. There can be any number of reasons the slot isn't
> > empty - the API should not "document" that the reason the insert
> > failed was a race condition. It should document the case that we
> > "couldn't insert because there was an existing entry in the slot".
> > Let the surrounding code document the reason why that might have
> > happened - it's not for the API to assume reasons for failure.
> >
> > i.e. this API and potential internal implementation makes much
> > more sense:
> >
> > int
> > xa_store_iff_empty(...)
> > {
> > curr = xa_cmpxchg(&pag->pag_ici_xa, agino, NULL, ip, GFP_NOFS);
> > if (!curr)
> > return 0; /* success! */
> > if (!IS_ERR(curr))
> > return -EEXIST; /* failed - slot not empty */
> > return PTR_ERR(curr); /* failed - XA internal issue */
> > }
> >
> > as it replaces the existing preload and insert code in the XFS code
> > paths whilst letting us handle and document the "insert failed
> > because slot not empty" case however we want. It implies nothing
> > about *why* the slot wasn't empty, just that we couldn't do the
> > insert because it wasn't empty.
>
> Yeah, OK. So, over the top of the recent changes I'm looking at this:
>
> I'm not in love with xa_store_empty() as a name. I almost want
> xa_store_weak(), but after my MAP_FIXED_WEAK proposed name got shot
> down, I'm leery of it. "empty" is at least a concept we already have
> in the API with the comment for xa_init() talking about an empty array
> and xa_empty(). I also considered xa_store_null and xa_overwrite_null
> and xa_replace_null(). Naming remains hard.
>
> diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c
> index 941f38bb94a4..586b43836905 100644
> --- a/fs/xfs/xfs_icache.c
> +++ b/fs/xfs/xfs_icache.c
> @@ -451,7 +451,7 @@ xfs_iget_cache_miss(
> int flags,
> int lock_flags)
> {
> - struct xfs_inode*ip, *curr;
> + struct xfs_inode*ip;
> int error;
> xfs_agino_t agino = XFS_INO_TO_AGINO(mp, ino);
> int iflags;
> @@ -498,8 +498,7 @@ xfs_iget_cache_miss(
> xfs_iflags_set(ip, iflags);
>
> /* insert the new inode */
> - curr = xa_cmpxchg(&pag->pag_ici_xa, agino, NULL, ip, GFP_NOFS);
> - error = __xa_race(curr, -EAGAIN);
> + error = xa_store_empty(&pag->pag_ici_xa, agino, ip, GFP_NOFS, -EAGAIN);
> if (error)
> goto out_unlock;
Can we avoid encoding the error to be returned into the function
call? No other generic/library API does this, so this seems like a
highly unusual special snowflake approach. I just don't see how
creating a whole new error specification convention is justified
for the case where it *might* save a line or two of error checking
code in a caller?
I'd much prefer that the API defines the error on failure, and let
the caller handle that specific error however they need to like
every other library interface we have...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
