Re: [PATCH v2] staging: rtlwifi: convert to DEFINE_SHOW_ATTRIBUTE

2018-12-21 Thread Frank Lee
Sorry!!!Please ignore this.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] dt-bindings: net: dsa: ksz9477: fix indentation for switch spi bindings

2018-12-21 Thread Sergio Paracuellos
Switch bindings for spi managed mode are using spaces instead of tabs.
Fix them to get a file with a proper kernel indentation style.

Signed-off-by: Sergio Paracuellos 
---
 .../devicetree/bindings/net/dsa/ksz.txt   | 110 +-
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt 
b/Documentation/devicetree/bindings/net/dsa/ksz.txt
index 2f276aa42f0b..e8d33d008355 100644
--- a/Documentation/devicetree/bindings/net/dsa/ksz.txt
+++ b/Documentation/devicetree/bindings/net/dsa/ksz.txt
@@ -19,61 +19,61 @@ Examples:
 
 Ethernet switch connected via SPI to the host, CPU port wired to eth0:
 
- eth0: ethernet@10001000 {
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
- spi1: spi@f8008000 {
- pinctrl-0 = <_spi_ksz>;
- cs-gpios = < 25 0>;
- id = <1>;
-
- ksz9477: ksz9477@0 {
- compatible = 
"microchip,ksz9477";
- reg = <0>;
-
- spi-max-frequency 
= <4400>;
- spi-cpha;
- spi-cpol;
-
- ports {
- 
#address-cells = <1>;
- 
#size-cells = <0>;
- 
port@0 {
-   
  reg = <0>;
-   
  label = "lan1";
- };
- 
port@1 {
-   
  reg = <1>;
-   
  label = "lan2";
- };
- 
port@2 {
-   
  reg = <2>;
-   
  label = "lan3";
- };
- 
port@3 {
-   
  reg = <3>;
-   
  label = "lan4";
- };
- 
port@4 {
-   
  reg = <4>;
-   
  label = "lan5";
- };
- 
port@5 {
-   
  reg = <5>;
-   
  label = "cpu";
-   
  ethernet = <>;
-   
  fixed-link {
-   
  speed = <1000>;
-   
  full-duplex;
-   
  };
- };
- };
- 

Re: [PATCH v2] staging: rtlwifi: convert to DEFINE_SHOW_ATTRIBUTE

2018-12-21 Thread kbuild test robot
Hi Yangtao,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.20-rc7 next-20181221]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Yangtao-Li/staging-rtlwifi-convert-to-DEFINE_SHOW_ATTRIBUTE/20181222-085444
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/staging/rtlwifi/debug.c: In function 'rtl_debug_add_one':
   drivers/staging/rtlwifi/debug.c:515:10: error: 'fopname_fops' undeclared 
(first use in this function); did you mean 'replace_fops'?
_ ##fops); \
 ^
>> drivers/staging/rtlwifi/debug.c:519:3: note: in expansion of macro 
>> 'RTL_DEBUGFS_ADD_CORE'
  RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common)
  ^~~~
   drivers/staging/rtlwifi/debug.c:545:2: note: in expansion of macro 
'RTL_DEBUGFS_ADD'
 RTL_DEBUGFS_ADD(mac_0);
 ^~~
   drivers/staging/rtlwifi/debug.c:515:10: note: each undeclared identifier is 
reported only once for each function it appears in
_ ##fops); \
 ^
>> drivers/staging/rtlwifi/debug.c:519:3: note: in expansion of macro 
>> 'RTL_DEBUGFS_ADD_CORE'
  RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common)
  ^~~~
   drivers/staging/rtlwifi/debug.c:545:2: note: in expansion of macro 
'RTL_DEBUGFS_ADD'
 RTL_DEBUGFS_ADD(mac_0);
 ^~~

vim +/RTL_DEBUGFS_ADD_CORE +519 drivers/staging/rtlwifi/debug.c

56bde846 Ping-Ke Shih   2017-08-17  509  
56bde846 Ping-Ke Shih   2017-08-17  510  #define RTL_DEBUGFS_ADD_CORE(name, 
mode, fopname) \
56bde846 Ping-Ke Shih   2017-08-17  511 do {
   \
56bde846 Ping-Ke Shih   2017-08-17  512 rtl_debug_priv_ 
##name.rtlpriv = rtlpriv;  \
e206a0d4 Greg Kroah-Hartman 2018-05-29  513 
debugfs_create_file(#name, mode, parent,   \
e206a0d4 Greg Kroah-Hartman 2018-05-29  514 
_debug_priv_ ##name,   \
e8b4e2be Yangtao Li 2018-12-21 @515 
_ ##fops); \
56bde846 Ping-Ke Shih   2017-08-17  516 } while (0)
56bde846 Ping-Ke Shih   2017-08-17  517  
56bde846 Ping-Ke Shih   2017-08-17  518  #define RTL_DEBUGFS_ADD(name)  
   \
56bde846 Ping-Ke Shih   2017-08-17 @519 
RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common)
56bde846 Ping-Ke Shih   2017-08-17  520  #define RTL_DEBUGFS_ADD_W(name)
   \
b55ade19 Larry Finger   2017-08-24  521 
RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0222, common_write)
56bde846 Ping-Ke Shih   2017-08-17  522  #define RTL_DEBUGFS_ADD_RW(name)   
   \
b55ade19 Larry Finger   2017-08-24  523 
RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0666, common_rw)
56bde846 Ping-Ke Shih   2017-08-17  524  

:: The code at line 519 was first introduced by commit
:: 56bde846304ea05d5f8c8de0e3a42627a7a92be6 staging: r8822be: Add existing 
rtlwifi and rtl_pci parts for new driver

:: TO: Ping-Ke Shih 
:: CC: Greg Kroah-Hartman 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 1/1] x86/hyper-v: Fix 'set but not used' warnings

2018-12-21 Thread Michael Kelley
In these two cases, a value returned by rdmsr() or rdmsrl()
is ignored. Indicate that ignoring the value is intentional, so
that with the W=1 compilation option no warning is generated.

Signed-off-by: Michael Kelley 
---
 arch/x86/hyperv/hv_apic.c | 2 +-
 arch/x86/hyperv/hv_spinlock.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 8eb6fbee..66a0f53 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -55,7 +55,7 @@ static void hv_apic_icr_write(u32 low, u32 id)
 
 static u32 hv_apic_read(u32 reg)
 {
-   u32 reg_val, hi;
+   u32 reg_val, __maybe_unused hi;
 
switch (reg) {
case APIC_EOI:
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index a861b04..e18c63d5 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -25,7 +25,7 @@ static void hv_qlock_kick(int cpu)
 
 static void hv_qlock_wait(u8 *byte, u8 val)
 {
-   unsigned long msr_val;
+   unsigned long __maybe_unused msr_val;
unsigned long flags;
 
if (in_nmi())
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH net-next] staging: octeon: fix build failure with XFRM enabled

2018-12-21 Thread Guenter Roeck
On Fri, Dec 21, 2018 at 09:57:26PM +0100, Florian Westphal wrote:
> skb->sp doesn't exist anymore in the next-next tree, so mips defconfig
> no longer builds.  Use helper instead to reset the secpath.
> 
> Not even compile tested.
> 
It does fix the build error.

Tested-by: Guenter Roeck 

> Cc: Greg Kroah-Hartman 
> Reported-by: Guenter Roeck 
> Fixes: 4165079ba328d ("net: switch secpath to use skb extension 
> infrastructure")
> Signed-off-by: Florian Westphal 
> ---
>  Greg, David:
> 
>  The patch will not break build for a tree that lacks the 'Fixes'
>  commit, so this can also go in via staging tree.
>  OTOH, net-next build is broken for mips/octeon, so I think in
>  this case net-next might make more sense?
> 
> diff --git a/drivers/staging/octeon/ethernet-tx.c 
> b/drivers/staging/octeon/ethernet-tx.c
> index df3441b815bb..317c9720467c 100644
> --- a/drivers/staging/octeon/ethernet-tx.c
> +++ b/drivers/staging/octeon/ethernet-tx.c
> @@ -359,8 +359,7 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device 
> *dev)
>   dst_release(skb_dst(skb));
>   skb_dst_set(skb, NULL);
>  #ifdef CONFIG_XFRM
> - secpath_put(skb->sp);
> - skb->sp = NULL;
> + secpath_reset(skb);
>  #endif
>   nf_reset(skb);
>  
> -- 
> 2.19.2
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] Staging: iio: ad7192: replaced bool in struct

2018-12-21 Thread Amir Mahdi Ghorbanian
Replaced bool in struct with unsigned int bitfield to conserve space and
more clearly define size of varibales

Signed-off-by: Amir Mahdi Ghorbanian 
---
 drivers/staging/iio/adc/ad7192.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7192.h b/drivers/staging/iio/adc/ad7192.h
index 7433a43..7d3e62f 100644
--- a/drivers/staging/iio/adc/ad7192.h
+++ b/drivers/staging/iio/adc/ad7192.h
@@ -35,13 +35,13 @@ struct ad7192_platform_data {
u16 vref_mv;
u8  clock_source_sel;
u32 ext_clk_hz;
-   boolrefin2_en;
-   boolrej60_en;
-   boolsinc3_en;
-   boolchop_en;
-   boolbuf_en;
-   boolunipolar_en;
-   boolburnout_curr_en;
+   unsigned intrefin2_en : 1;
+   unsigned intrej60_en : 1;
+   unsigned intsinc3_en : 1;
+   unsigned intchop_en : 1;
+   unsigned intbuf_en : 1;
+   unsigned intunipolar_en : 1;
+   unsigned intburnout_curr_en : 1;
 };
 
 #endif /* IIO_ADC_AD7192_H_ */
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH net-next] staging: octeon: fix build failure with XFRM enabled

2018-12-21 Thread Florian Westphal
skb->sp doesn't exist anymore in the next-next tree, so mips defconfig
no longer builds.  Use helper instead to reset the secpath.

Not even compile tested.

Cc: Greg Kroah-Hartman 
Reported-by: Guenter Roeck 
Fixes: 4165079ba328d ("net: switch secpath to use skb extension infrastructure")
Signed-off-by: Florian Westphal 
---
 Greg, David:

 The patch will not break build for a tree that lacks the 'Fixes'
 commit, so this can also go in via staging tree.
 OTOH, net-next build is broken for mips/octeon, so I think in
 this case net-next might make more sense?

diff --git a/drivers/staging/octeon/ethernet-tx.c 
b/drivers/staging/octeon/ethernet-tx.c
index df3441b815bb..317c9720467c 100644
--- a/drivers/staging/octeon/ethernet-tx.c
+++ b/drivers/staging/octeon/ethernet-tx.c
@@ -359,8 +359,7 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device 
*dev)
dst_release(skb_dst(skb));
skb_dst_set(skb, NULL);
 #ifdef CONFIG_XFRM
-   secpath_put(skb->sp);
-   skb->sp = NULL;
+   secpath_reset(skb);
 #endif
nf_reset(skb);
 
-- 
2.19.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] binderfs: implement sysctls

2018-12-21 Thread Christian Brauner
On Fri, Dec 21, 2018 at 05:33:16PM +0100, Greg KH wrote:
> On Fri, Dec 21, 2018 at 04:59:19PM +0100, Christian Brauner wrote:
> > On Fri, Dec 21, 2018 at 04:37:58PM +0100, Greg KH wrote:
> > > On Fri, Dec 21, 2018 at 03:12:42PM +0100, Christian Brauner wrote:
> > > > On Fri, Dec 21, 2018 at 02:55:09PM +0100, Greg KH wrote:
> > > > > On Fri, Dec 21, 2018 at 02:39:09PM +0100, Christian Brauner wrote:
> > > > > > This implements three sysctls that have very specific goals:
> > > > > 
> > > > > Ick, why?
> > > > > 
> > > > > What are these going to be used for?  Who will "control" them?  As you
> > > > 
> > > > Only global root in the initial user namespace. See the reasons below. 
> > > > :)
> > > > 
> > > > > are putting them in the "global" namespace, that feels like something
> > > > > that binderfs was trying to avoid in the first place.
> > > > 
> > > > There are a couple of reason imho:
> > > > - Global root needs a way to restrict how many binder devices can be
> > > >   allocated across all user + ipc namespace pairs.
> > > >   One obvious reason is that otherwise userns root in a non-initial user
> > > >   namespace can allocate a huge number of binder devices (pick a random
> > > >   number say 10.000) and use up a lot of kernel memory.
> > > 
> > > Root can do tons of other bad things too, why are you picking on
> > 
> > That's global root not userns root though. :) These sysctls are about
> > global root gaining the ability to proactively restrict binder device
> > delegation.
> > 
> > > binderfs here?  :)
> > > 
> > > >   In addition they can pound on the binder.c code causing a lot of
> > > >   contention for the remaining global lock in there.
> > > 
> > > That's the problem of that container, don't let it do that.  Or remove
> > > the global lock :)
> > > 
> > > >   We should let global root explicitly restrict non-initial namespaces
> > > >   in this respect. Imho, that's just good security design. :)
> > > 
> > > If you do not trust your container enough to have it properly allocate
> > > the correct binder resources, then perhaps you shouldn't be allowing it
> > > to allocate any resources at all?
> > 
> > Containers just like VMs get delegated and you might not have control
> > over what is running in there. That's AWS in a nutshell. :) Restricting
> > it by saying "just don't do that" seems not something that is
> > appropriate given the workloads out there in the wild.
> > In general, I do *understand* the reasoning but I think the premise is
> > flawed if we can somewhat trivially make this safe.
> > 
> > > 
> > > > - The reason for having a number of reserved devices is when the initial
> > > >   binderfs mount needs to bump the number of binder devices after the
> > > >   initial allocation done during say boot (e.g. it could've removed
> > > >   devices and wants to reallocate new ones but all binder minor numbers
> > > >   have been given out or just needs additional devices). By reserving an
> > > >   initial pool of binder devices this can be easily accounted for and
> > > >   future proofs userspace. This is to say: global root in the initial
> > > >   userns + ipcns gets dibs on however many devices it wants. :)
> > > 
> > > binder devices do not "come and go" at runtime, you need to set them up
> > > initially and then all is fine.  So there should never be a need for the
> > > "global" instance to need "more" binder devices once it is up and
> > > running.  So I don't see what you are really trying to solve here.
> > 
> > That's dismissing a whole range of use-cases where you might allocate
> > and deallocate devices on the fly which this is somewhat designed for.
> > But I guess ok for now.
> > 
> > > 
> > > You seem to be trying to protect the system from the container you just
> > > gave root to and trusted it with creating its own binder instances.
> > > If you do not trust it to create binder instances then do not allow it
> > > to create binder instances!  :)
> > 
> > Again, I get the reasoning but think that this dismisses major
> > real-world use-cases not just for binderfs but for all instances where
> > untrusted workloads are run which both containers and VMs aim to make
> > sure are possible.
> > Note, I mean untrusted not in the sense of necessarily being malicious
> > but just "can't guarantee that things don't blow up in your face".
> > 
> > > 
> > > > - The fact that we have a single shared pool of binder device minor
> > > >   numbers for all namespaces imho makes it necessary for the global root
> > > >   user in the initial ipc + user namespace to manage device allocation
> > > >   and delegation.
> > > 
> > > You are managing the allocation, you are giving who ever asks for one a
> > > device.  If you run out of devices, oops, you run out of devices, that's
> > > it.  Are you really ever going to run out of a major's number of binder
> > > devices?
> > 
> > The point is more about someone intentionally trying to do that.
> > 
> > > 
> > > > The binderfs 

[PATCH] media: sunxi: cedrus: Fix missing error message context

2018-12-21 Thread megous
From: Ondrej Jirman 

When cedrus_hw_probe is called, v4l2_dev is not yet initialized.
Use dev_err instead.

Signed-off-by: Ondrej Jirman 
---
 .../staging/media/sunxi/cedrus/cedrus_hw.c| 28 +--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
index 300339fee1bc..0acf219a8c91 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
@@ -157,14 +157,14 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
 
irq_dec = platform_get_irq(dev->pdev, 0);
if (irq_dec <= 0) {
-   v4l2_err(>v4l2_dev, "Failed to get IRQ\n");
+   dev_err(dev->dev, "Failed to get IRQ\n");
 
return irq_dec;
}
ret = devm_request_irq(dev->dev, irq_dec, cedrus_irq,
   0, dev_name(dev->dev), dev);
if (ret) {
-   v4l2_err(>v4l2_dev, "Failed to request IRQ\n");
+   dev_err(dev->dev, "Failed to request IRQ\n");
 
return ret;
}
@@ -182,21 +182,21 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
 
ret = of_reserved_mem_device_init(dev->dev);
if (ret && ret != -ENODEV) {
-   v4l2_err(>v4l2_dev, "Failed to reserve memory\n");
+   dev_err(dev->dev, "Failed to reserve memory\n");
 
return ret;
}
 
ret = sunxi_sram_claim(dev->dev);
if (ret) {
-   v4l2_err(>v4l2_dev, "Failed to claim SRAM\n");
+   dev_err(dev->dev, "Failed to claim SRAM\n");
 
goto err_mem;
}
 
dev->ahb_clk = devm_clk_get(dev->dev, "ahb");
if (IS_ERR(dev->ahb_clk)) {
-   v4l2_err(>v4l2_dev, "Failed to get AHB clock\n");
+   dev_err(dev->dev, "Failed to get AHB clock\n");
 
ret = PTR_ERR(dev->ahb_clk);
goto err_sram;
@@ -204,7 +204,7 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
 
dev->mod_clk = devm_clk_get(dev->dev, "mod");
if (IS_ERR(dev->mod_clk)) {
-   v4l2_err(>v4l2_dev, "Failed to get MOD clock\n");
+   dev_err(dev->dev, "Failed to get MOD clock\n");
 
ret = PTR_ERR(dev->mod_clk);
goto err_sram;
@@ -212,7 +212,7 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
 
dev->ram_clk = devm_clk_get(dev->dev, "ram");
if (IS_ERR(dev->ram_clk)) {
-   v4l2_err(>v4l2_dev, "Failed to get RAM clock\n");
+   dev_err(dev->dev, "Failed to get RAM clock\n");
 
ret = PTR_ERR(dev->ram_clk);
goto err_sram;
@@ -220,7 +220,7 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
 
dev->rstc = devm_reset_control_get(dev->dev, NULL);
if (IS_ERR(dev->rstc)) {
-   v4l2_err(>v4l2_dev, "Failed to get reset control\n");
+   dev_err(dev->dev, "Failed to get reset control\n");
 
ret = PTR_ERR(dev->rstc);
goto err_sram;
@@ -229,7 +229,7 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
res = platform_get_resource(dev->pdev, IORESOURCE_MEM, 0);
dev->base = devm_ioremap_resource(dev->dev, res);
if (IS_ERR(dev->base)) {
-   v4l2_err(>v4l2_dev, "Failed to map registers\n");
+   dev_err(dev->dev, "Failed to map registers\n");
 
ret = PTR_ERR(dev->base);
goto err_sram;
@@ -237,35 +237,35 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
 
ret = clk_set_rate(dev->mod_clk, CEDRUS_CLOCK_RATE_DEFAULT);
if (ret) {
-   v4l2_err(>v4l2_dev, "Failed to set clock rate\n");
+   dev_err(dev->dev, "Failed to set clock rate\n");
 
goto err_sram;
}
 
ret = clk_prepare_enable(dev->ahb_clk);
if (ret) {
-   v4l2_err(>v4l2_dev, "Failed to enable AHB clock\n");
+   dev_err(dev->dev, "Failed to enable AHB clock\n");
 
goto err_sram;
}
 
ret = clk_prepare_enable(dev->mod_clk);
if (ret) {
-   v4l2_err(>v4l2_dev, "Failed to enable MOD clock\n");
+   dev_err(dev->dev, "Failed to enable MOD clock\n");
 
goto err_ahb_clk;
}
 
ret = clk_prepare_enable(dev->ram_clk);
if (ret) {
-   v4l2_err(>v4l2_dev, "Failed to enable RAM clock\n");
+   dev_err(dev->dev, "Failed to enable RAM clock\n");
 
goto err_mod_clk;
}
 
ret = reset_control_reset(dev->rstc);
if (ret) {
-   v4l2_err(>v4l2_dev, "Failed to apply reset\n");
+   dev_err(dev->dev, "Failed to apply reset\n");
 
goto err_ram_clk;
}
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org

Re: [PATCH] binderfs: implement sysctls

2018-12-21 Thread Greg KH
On Fri, Dec 21, 2018 at 04:59:19PM +0100, Christian Brauner wrote:
> On Fri, Dec 21, 2018 at 04:37:58PM +0100, Greg KH wrote:
> > On Fri, Dec 21, 2018 at 03:12:42PM +0100, Christian Brauner wrote:
> > > On Fri, Dec 21, 2018 at 02:55:09PM +0100, Greg KH wrote:
> > > > On Fri, Dec 21, 2018 at 02:39:09PM +0100, Christian Brauner wrote:
> > > > > This implements three sysctls that have very specific goals:
> > > > 
> > > > Ick, why?
> > > > 
> > > > What are these going to be used for?  Who will "control" them?  As you
> > > 
> > > Only global root in the initial user namespace. See the reasons below. :)
> > > 
> > > > are putting them in the "global" namespace, that feels like something
> > > > that binderfs was trying to avoid in the first place.
> > > 
> > > There are a couple of reason imho:
> > > - Global root needs a way to restrict how many binder devices can be
> > >   allocated across all user + ipc namespace pairs.
> > >   One obvious reason is that otherwise userns root in a non-initial user
> > >   namespace can allocate a huge number of binder devices (pick a random
> > >   number say 10.000) and use up a lot of kernel memory.
> > 
> > Root can do tons of other bad things too, why are you picking on
> 
> That's global root not userns root though. :) These sysctls are about
> global root gaining the ability to proactively restrict binder device
> delegation.
> 
> > binderfs here?  :)
> > 
> > >   In addition they can pound on the binder.c code causing a lot of
> > >   contention for the remaining global lock in there.
> > 
> > That's the problem of that container, don't let it do that.  Or remove
> > the global lock :)
> > 
> > >   We should let global root explicitly restrict non-initial namespaces
> > >   in this respect. Imho, that's just good security design. :)
> > 
> > If you do not trust your container enough to have it properly allocate
> > the correct binder resources, then perhaps you shouldn't be allowing it
> > to allocate any resources at all?
> 
> Containers just like VMs get delegated and you might not have control
> over what is running in there. That's AWS in a nutshell. :) Restricting
> it by saying "just don't do that" seems not something that is
> appropriate given the workloads out there in the wild.
> In general, I do *understand* the reasoning but I think the premise is
> flawed if we can somewhat trivially make this safe.
> 
> > 
> > > - The reason for having a number of reserved devices is when the initial
> > >   binderfs mount needs to bump the number of binder devices after the
> > >   initial allocation done during say boot (e.g. it could've removed
> > >   devices and wants to reallocate new ones but all binder minor numbers
> > >   have been given out or just needs additional devices). By reserving an
> > >   initial pool of binder devices this can be easily accounted for and
> > >   future proofs userspace. This is to say: global root in the initial
> > >   userns + ipcns gets dibs on however many devices it wants. :)
> > 
> > binder devices do not "come and go" at runtime, you need to set them up
> > initially and then all is fine.  So there should never be a need for the
> > "global" instance to need "more" binder devices once it is up and
> > running.  So I don't see what you are really trying to solve here.
> 
> That's dismissing a whole range of use-cases where you might allocate
> and deallocate devices on the fly which this is somewhat designed for.
> But I guess ok for now.
> 
> > 
> > You seem to be trying to protect the system from the container you just
> > gave root to and trusted it with creating its own binder instances.
> > If you do not trust it to create binder instances then do not allow it
> > to create binder instances!  :)
> 
> Again, I get the reasoning but think that this dismisses major
> real-world use-cases not just for binderfs but for all instances where
> untrusted workloads are run which both containers and VMs aim to make
> sure are possible.
> Note, I mean untrusted not in the sense of necessarily being malicious
> but just "can't guarantee that things don't blow up in your face".
> 
> > 
> > > - The fact that we have a single shared pool of binder device minor
> > >   numbers for all namespaces imho makes it necessary for the global root
> > >   user in the initial ipc + user namespace to manage device allocation
> > >   and delegation.
> > 
> > You are managing the allocation, you are giving who ever asks for one a
> > device.  If you run out of devices, oops, you run out of devices, that's
> > it.  Are you really ever going to run out of a major's number of binder
> > devices?
> 
> The point is more about someone intentionally trying to do that.
> 
> > 
> > > The binderfs sysctl stuff is really small code-wise and adds a lot of
> > > security without any performance impact on the code itself. So we
> > > actually very strictly adhere to the requirement to not blindly
> > > sacrifice performance for security. :)
> > 
> > But you are 

Re: [PATCH] binderfs: implement sysctls

2018-12-21 Thread Christian Brauner
On Fri, Dec 21, 2018 at 04:37:58PM +0100, Greg KH wrote:
> On Fri, Dec 21, 2018 at 03:12:42PM +0100, Christian Brauner wrote:
> > On Fri, Dec 21, 2018 at 02:55:09PM +0100, Greg KH wrote:
> > > On Fri, Dec 21, 2018 at 02:39:09PM +0100, Christian Brauner wrote:
> > > > This implements three sysctls that have very specific goals:
> > > 
> > > Ick, why?
> > > 
> > > What are these going to be used for?  Who will "control" them?  As you
> > 
> > Only global root in the initial user namespace. See the reasons below. :)
> > 
> > > are putting them in the "global" namespace, that feels like something
> > > that binderfs was trying to avoid in the first place.
> > 
> > There are a couple of reason imho:
> > - Global root needs a way to restrict how many binder devices can be
> >   allocated across all user + ipc namespace pairs.
> >   One obvious reason is that otherwise userns root in a non-initial user
> >   namespace can allocate a huge number of binder devices (pick a random
> >   number say 10.000) and use up a lot of kernel memory.
> 
> Root can do tons of other bad things too, why are you picking on

That's global root not userns root though. :) These sysctls are about
global root gaining the ability to proactively restrict binder device
delegation.

> binderfs here?  :)
> 
> >   In addition they can pound on the binder.c code causing a lot of
> >   contention for the remaining global lock in there.
> 
> That's the problem of that container, don't let it do that.  Or remove
> the global lock :)
> 
> >   We should let global root explicitly restrict non-initial namespaces
> >   in this respect. Imho, that's just good security design. :)
> 
> If you do not trust your container enough to have it properly allocate
> the correct binder resources, then perhaps you shouldn't be allowing it
> to allocate any resources at all?

Containers just like VMs get delegated and you might not have control
over what is running in there. That's AWS in a nutshell. :) Restricting
it by saying "just don't do that" seems not something that is
appropriate given the workloads out there in the wild.
In general, I do *understand* the reasoning but I think the premise is
flawed if we can somewhat trivially make this safe.

> 
> > - The reason for having a number of reserved devices is when the initial
> >   binderfs mount needs to bump the number of binder devices after the
> >   initial allocation done during say boot (e.g. it could've removed
> >   devices and wants to reallocate new ones but all binder minor numbers
> >   have been given out or just needs additional devices). By reserving an
> >   initial pool of binder devices this can be easily accounted for and
> >   future proofs userspace. This is to say: global root in the initial
> >   userns + ipcns gets dibs on however many devices it wants. :)
> 
> binder devices do not "come and go" at runtime, you need to set them up
> initially and then all is fine.  So there should never be a need for the
> "global" instance to need "more" binder devices once it is up and
> running.  So I don't see what you are really trying to solve here.

That's dismissing a whole range of use-cases where you might allocate
and deallocate devices on the fly which this is somewhat designed for.
But I guess ok for now.

> 
> You seem to be trying to protect the system from the container you just
> gave root to and trusted it with creating its own binder instances.
> If you do not trust it to create binder instances then do not allow it
> to create binder instances!  :)

Again, I get the reasoning but think that this dismisses major
real-world use-cases not just for binderfs but for all instances where
untrusted workloads are run which both containers and VMs aim to make
sure are possible.
Note, I mean untrusted not in the sense of necessarily being malicious
but just "can't guarantee that things don't blow up in your face".

> 
> > - The fact that we have a single shared pool of binder device minor
> >   numbers for all namespaces imho makes it necessary for the global root
> >   user in the initial ipc + user namespace to manage device allocation
> >   and delegation.
> 
> You are managing the allocation, you are giving who ever asks for one a
> device.  If you run out of devices, oops, you run out of devices, that's
> it.  Are you really ever going to run out of a major's number of binder
> devices?

The point is more about someone intentionally trying to do that.

> 
> > The binderfs sysctl stuff is really small code-wise and adds a lot of
> > security without any performance impact on the code itself. So we
> > actually very strictly adhere to the requirement to not blindly
> > sacrifice performance for security. :)
> 
> But you are adding a brand new user/kernel api by emulating one that is
> very old and not the best at all, to try to protect from something that
> seems like you can't really "protect" from in the first place.

Of course we can protect from that. It's about init root never running

[PATCH v2] staging: rtlwifi: convert to DEFINE_SHOW_ATTRIBUTE

2018-12-21 Thread Yangtao Li
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Yangtao Li 
---
v2:
-modify RTL_DEBUGFS_ADD_CORE macro
---
 drivers/staging/rtlwifi/debug.c | 23 ++-
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/rtlwifi/debug.c b/drivers/staging/rtlwifi/debug.c
index 8999feda29b4..dd1cc27e9544 100644
--- a/drivers/staging/rtlwifi/debug.c
+++ b/drivers/staging/rtlwifi/debug.c
@@ -79,24 +79,13 @@ struct rtl_debugfs_priv {
 
 static struct dentry *debugfs_topdir;
 
-static int rtl_debug_get_common(struct seq_file *m, void *v)
+static int common_show(struct seq_file *m, void *v)
 {
struct rtl_debugfs_priv *debugfs_priv = m->private;
 
return debugfs_priv->cb_read(m, v);
 }
-
-static int dl_debug_open_common(struct inode *inode, struct file *file)
-{
-   return single_open(file, rtl_debug_get_common, inode->i_private);
-}
-
-static const struct file_operations file_ops_common = {
-   .open = dl_debug_open_common,
-   .read = seq_read,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(common);
 
 static int rtl_debug_get_mac_page(struct seq_file *m, void *v)
 {
@@ -439,7 +428,7 @@ static ssize_t rtl_debugfs_common_write(struct file *filp,
return debugfs_priv->cb_write(filp, buffer, count, loff);
 }
 
-static const struct file_operations file_ops_common_write = {
+static const struct file_operations common_write_fops = {
.owner = THIS_MODULE,
.write = rtl_debugfs_common_write,
.open = simple_open,
@@ -488,7 +477,7 @@ static int rtl_debugfs_open_rw(struct inode *inode, struct 
file *filp)
int ret = 0;
 
if (filp->f_mode & FMODE_READ)
-   ret = single_open(filp, rtl_debug_get_common, inode->i_private);
+   ret = single_open(filp, common_show, inode->i_private);
else
filp->private_data = inode->i_private;
 
@@ -509,7 +498,7 @@ static struct rtl_debugfs_priv rtl_debug_priv_phydm_cmd = {
.cb_data = 0,
 };
 
-static const struct file_operations file_ops_common_rw = {
+static const struct file_operations common_rw_fops = {
.owner = THIS_MODULE,
.open = rtl_debugfs_open_rw,
.release = rtl_debugfs_close_rw,
@@ -523,7 +512,7 @@ static const struct file_operations file_ops_common_rw = {
rtl_debug_priv_ ##name.rtlpriv = rtlpriv;  \
debugfs_create_file(#name, mode, parent,   \
_debug_priv_ ##name,   \
-   _ops_ ##fopname); \
+   _ ##fops); \
} while (0)
 
 #define RTL_DEBUGFS_ADD(name) \
-- 
2.17.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] binderfs: implement sysctls

2018-12-21 Thread Greg KH
On Fri, Dec 21, 2018 at 03:12:42PM +0100, Christian Brauner wrote:
> On Fri, Dec 21, 2018 at 02:55:09PM +0100, Greg KH wrote:
> > On Fri, Dec 21, 2018 at 02:39:09PM +0100, Christian Brauner wrote:
> > > This implements three sysctls that have very specific goals:
> > 
> > Ick, why?
> > 
> > What are these going to be used for?  Who will "control" them?  As you
> 
> Only global root in the initial user namespace. See the reasons below. :)
> 
> > are putting them in the "global" namespace, that feels like something
> > that binderfs was trying to avoid in the first place.
> 
> There are a couple of reason imho:
> - Global root needs a way to restrict how many binder devices can be
>   allocated across all user + ipc namespace pairs.
>   One obvious reason is that otherwise userns root in a non-initial user
>   namespace can allocate a huge number of binder devices (pick a random
>   number say 10.000) and use up a lot of kernel memory.

Root can do tons of other bad things too, why are you picking on
binderfs here?  :)

>   In addition they can pound on the binder.c code causing a lot of
>   contention for the remaining global lock in there.

That's the problem of that container, don't let it do that.  Or remove
the global lock :)

>   We should let global root explicitly restrict non-initial namespaces
>   in this respect. Imho, that's just good security design. :)

If you do not trust your container enough to have it properly allocate
the correct binder resources, then perhaps you shouldn't be allowing it
to allocate any resources at all?

> - The reason for having a number of reserved devices is when the initial
>   binderfs mount needs to bump the number of binder devices after the
>   initial allocation done during say boot (e.g. it could've removed
>   devices and wants to reallocate new ones but all binder minor numbers
>   have been given out or just needs additional devices). By reserving an
>   initial pool of binder devices this can be easily accounted for and
>   future proofs userspace. This is to say: global root in the initial
>   userns + ipcns gets dibs on however many devices it wants. :)

binder devices do not "come and go" at runtime, you need to set them up
initially and then all is fine.  So there should never be a need for the
"global" instance to need "more" binder devices once it is up and
running.  So I don't see what you are really trying to solve here.

You seem to be trying to protect the system from the container you just
gave root to and trusted it with creating its own binder instances.
If you do not trust it to create binder instances then do not allow it
to create binder instances!  :)

> - The fact that we have a single shared pool of binder device minor
>   numbers for all namespaces imho makes it necessary for the global root
>   user in the initial ipc + user namespace to manage device allocation
>   and delegation.

You are managing the allocation, you are giving who ever asks for one a
device.  If you run out of devices, oops, you run out of devices, that's
it.  Are you really ever going to run out of a major's number of binder
devices?

> The binderfs sysctl stuff is really small code-wise and adds a lot of
> security without any performance impact on the code itself. So we
> actually very strictly adhere to the requirement to not blindly
> sacrifice performance for security. :)

But you are adding a brand new user/kernel api by emulating one that is
very old and not the best at all, to try to protect from something that
seems like you can't really "protect" from in the first place.

You now have a mis-match of sysctls, ioctls and file operations all
working on the same logical thing.  And all interacting in different and
uncertian ways.  Are you sure that's wise?

If the binderfs code as-is isn't "safe enough" to use without this, then
we need to revisit it before someone starts to use it...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] binderfs: implement sysctls

2018-12-21 Thread Christian Brauner
On Fri, Dec 21, 2018 at 02:55:09PM +0100, Greg KH wrote:
> On Fri, Dec 21, 2018 at 02:39:09PM +0100, Christian Brauner wrote:
> > This implements three sysctls that have very specific goals:
> 
> Ick, why?
> 
> What are these going to be used for?  Who will "control" them?  As you

Only global root in the initial user namespace. See the reasons below. :)

> are putting them in the "global" namespace, that feels like something
> that binderfs was trying to avoid in the first place.

There are a couple of reason imho:
- Global root needs a way to restrict how many binder devices can be
  allocated across all user + ipc namespace pairs.
  One obvious reason is that otherwise userns root in a non-initial user
  namespace can allocate a huge number of binder devices (pick a random
  number say 10.000) and use up a lot of kernel memory.
  In addition they can pound on the binder.c code causing a lot of
  contention for the remaining global lock in there.
  We should let global root explicitly restrict non-initial namespaces
  in this respect. Imho, that's just good security design. :)
- The reason for having a number of reserved devices is when the initial
  binderfs mount needs to bump the number of binder devices after the
  initial allocation done during say boot (e.g. it could've removed
  devices and wants to reallocate new ones but all binder minor numbers
  have been given out or just needs additional devices). By reserving an
  initial pool of binder devices this can be easily accounted for and
  future proofs userspace. This is to say: global root in the initial
  userns + ipcns gets dibs on however many devices it wants. :)
- The fact that we have a single shared pool of binder device minor
  numbers for all namespaces imho makes it necessary for the global root
  user in the initial ipc + user namespace to manage device allocation
  and delegation.

The binderfs sysctl stuff is really small code-wise and adds a lot of
security without any performance impact on the code itself. So we
actually very strictly adhere to the requirement to not blindly
sacrifice performance for security. :)

> 
> > 1. /proc/sys/fs/binder/max:
> >Allow global root to globally limit the number of allocatable binder
> >devices.
> 
> Why?  Who cares?  Memory should be your only limit here, and when you
> run into that limit, you will start failing :)
> 
> > 2. /proc/sys/fs/binder/nr:
> >Allow global root to easily detect how many binder devices are currently
> >in use across all binderfs mounts.
> 
> Why?  Again, who cares?
> 
> > 3. /proc/sys/fs/binder/reserved:
> >Ensure that global root can reserve binder devices for the initial
> >binderfs mount in the initial ipc namespace to prevent DOS attacks.
> 
> Huh?  Can't you just create your "global root" devices first?  Doesn't
> the code do that already anyway?
> 
> And what kind of DoS attack could this ever prevent from anyway?
> 
> > This is equivalent to sysctls of devpts.
> 
> devpts isn't exactly the best thing to emulate :)

It's one of its saner design choices though. :)

> 
> > 
> > Signed-off-by: Christian Brauner 
> > ---
> >  drivers/android/binderfs.c | 81 +-
> >  1 file changed, 79 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> > index 7496b10532aa..5ff015f82314 100644
> > --- a/drivers/android/binderfs.c
> > +++ b/drivers/android/binderfs.c
> > @@ -64,6 +64,71 @@ struct binderfs_info {
> >  
> >  };
> >  
> > +/* Global default limit on the number of binder devices. */
> > +static int device_limit = 4096;
> > +
> > +/*
> > + * Number of binder devices reserved for the initial binderfs mount in the
> > + * initial ipc namespace.
> > + */
> > +static int device_reserve = 1024;
> > +
> > +/* Dummy sysctl minimum. */
> > +static int device_limit_min;
> > +
> > +/* Cap sysctl at BINDERFS_MAX_MINOR. */
> > +static int device_limit_max = BINDERFS_MAX_MINOR;
> > +
> > +/* Current number of allocated binder devices. */
> > +static atomic_t device_count = ATOMIC_INIT(0);
> 
> You have a lock you are using, just rely on that, don't create
> yet-another-type-of-unneeded-lock with an atomic here.
> 
> Anyway, I really don't see the need for any of this just yet, so I
> didn't read beyond this point in the code :)
> 
> thanks,
> 
> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] binderfs: implement sysctls

2018-12-21 Thread Greg KH
On Fri, Dec 21, 2018 at 02:39:09PM +0100, Christian Brauner wrote:
> This implements three sysctls that have very specific goals:

Ick, why?

What are these going to be used for?  Who will "control" them?  As you
are putting them in the "global" namespace, that feels like something
that binderfs was trying to avoid in the first place.

> 1. /proc/sys/fs/binder/max:
>Allow global root to globally limit the number of allocatable binder
>devices.

Why?  Who cares?  Memory should be your only limit here, and when you
run into that limit, you will start failing :)

> 2. /proc/sys/fs/binder/nr:
>Allow global root to easily detect how many binder devices are currently
>in use across all binderfs mounts.

Why?  Again, who cares?

> 3. /proc/sys/fs/binder/reserved:
>Ensure that global root can reserve binder devices for the initial
>binderfs mount in the initial ipc namespace to prevent DOS attacks.

Huh?  Can't you just create your "global root" devices first?  Doesn't
the code do that already anyway?

And what kind of DoS attack could this ever prevent from anyway?

> This is equivalent to sysctls of devpts.

devpts isn't exactly the best thing to emulate :)

> 
> Signed-off-by: Christian Brauner 
> ---
>  drivers/android/binderfs.c | 81 +-
>  1 file changed, 79 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 7496b10532aa..5ff015f82314 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -64,6 +64,71 @@ struct binderfs_info {
>  
>  };
>  
> +/* Global default limit on the number of binder devices. */
> +static int device_limit = 4096;
> +
> +/*
> + * Number of binder devices reserved for the initial binderfs mount in the
> + * initial ipc namespace.
> + */
> +static int device_reserve = 1024;
> +
> +/* Dummy sysctl minimum. */
> +static int device_limit_min;
> +
> +/* Cap sysctl at BINDERFS_MAX_MINOR. */
> +static int device_limit_max = BINDERFS_MAX_MINOR;
> +
> +/* Current number of allocated binder devices. */
> +static atomic_t device_count = ATOMIC_INIT(0);

You have a lock you are using, just rely on that, don't create
yet-another-type-of-unneeded-lock with an atomic here.

Anyway, I really don't see the need for any of this just yet, so I
didn't read beyond this point in the code :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] binderfs: implement sysctls

2018-12-21 Thread Christian Brauner
This implements three sysctls that have very specific goals:

1. /proc/sys/fs/binder/max:
   Allow global root to globally limit the number of allocatable binder
   devices.
2. /proc/sys/fs/binder/nr:
   Allow global root to easily detect how many binder devices are currently
   in use across all binderfs mounts.
3. /proc/sys/fs/binder/reserved:
   Ensure that global root can reserve binder devices for the initial
   binderfs mount in the initial ipc namespace to prevent DOS attacks.

This is equivalent to sysctls of devpts.

Signed-off-by: Christian Brauner 
---
 drivers/android/binderfs.c | 81 +-
 1 file changed, 79 insertions(+), 2 deletions(-)

diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index 7496b10532aa..5ff015f82314 100644
--- a/drivers/android/binderfs.c
+++ b/drivers/android/binderfs.c
@@ -64,6 +64,71 @@ struct binderfs_info {
 
 };
 
+/* Global default limit on the number of binder devices. */
+static int device_limit = 4096;
+
+/*
+ * Number of binder devices reserved for the initial binderfs mount in the
+ * initial ipc namespace.
+ */
+static int device_reserve = 1024;
+
+/* Dummy sysctl minimum. */
+static int device_limit_min;
+
+/* Cap sysctl at BINDERFS_MAX_MINOR. */
+static int device_limit_max = BINDERFS_MAX_MINOR;
+
+/* Current number of allocated binder devices. */
+static atomic_t device_count = ATOMIC_INIT(0);
+
+static struct ctl_table binderfs_table[] = {
+   {
+   .procname   = "max",
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .data   = _limit,
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = _limit_min,
+   .extra2 = _limit_max,
+   },
+   {
+   .procname   = "reserve",
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .data   = _reserve,
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = _limit_min,
+   .extra2 = _limit_max,
+   },
+   {
+   .procname   = "nr",
+   .maxlen = sizeof(int),
+   .mode   = 0444,
+   .data   = _count,
+   .proc_handler   = proc_dointvec,
+   },
+   {}
+};
+
+static struct ctl_table binderfs_fs_table[] = {
+   {
+   .procname   = "binder",
+   .mode   = 0555,
+   .child  = binderfs_table,
+   },
+   {}
+};
+
+static struct ctl_table binderfs_root_table[] = {
+   {
+   .procname   = "fs",
+   .mode   = 0555,
+   .child  = binderfs_fs_table,
+   },
+   {}
+};
+
 static inline struct binderfs_info *BINDERFS_I(const struct inode *inode)
 {
return inode->i_sb->s_fs_info;
@@ -107,13 +172,21 @@ static int binderfs_binder_device_create(struct inode 
*ref_inode,
struct inode *inode = NULL;
struct super_block *sb = ref_inode->i_sb;
struct binderfs_info *info = sb->s_fs_info;
+   bool use_reserved = (info->ipc_ns == _ipc_ns);
 
/* Reserve new minor number for the new device. */
mutex_lock(_minors_mutex);
-   minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
+   if (atomic_inc_return(_count) <
+   (device_limit - (use_reserved ? 0 : device_reserve)))
+   minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR,
+ GFP_KERNEL);
+   else
+   minor = -ENOSPC;
mutex_unlock(_minors_mutex);
-   if (minor < 0)
+   if (minor < 0) {
+   atomic_dec(_count);
return minor;
+   }
 
ret = -ENOMEM;
device = kzalloc(sizeof(*device), GFP_KERNEL);
@@ -187,6 +260,7 @@ static int binderfs_binder_device_create(struct inode 
*ref_inode,
kfree(name);
kfree(device);
mutex_lock(_minors_mutex);
+   atomic_dec(_count);
ida_free(_minors, minor);
mutex_unlock(_minors_mutex);
iput(inode);
@@ -239,6 +313,7 @@ static void binderfs_evict_inode(struct inode *inode)
return;
 
mutex_lock(_minors_mutex);
+   atomic_dec(_count);
ida_free(_minors, device->miscdev.minor);
mutex_unlock(_minors_mutex);
 
@@ -536,6 +611,8 @@ static int __init init_binderfs(void)
binderfs_mnt = NULL;
unregister_filesystem(_fs_type);
unregister_chrdev_region(binderfs_dev, BINDERFS_MAX_MINOR);
+   } else {
+   register_sysctl_table(binderfs_root_table);
}
 
return ret;
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [Resend PATCH V5 2/10] x86/hyper-v: Add HvFlushGuestAddressList hypercall support

2018-12-21 Thread Paolo Bonzini
On 06/12/18 14:21, lantianyu1...@gmail.com wrote:
>  static inline int hyperv_flush_guest_mapping(u64 as) { return -1; }
> +static inline int hyperv_flush_guest_mapping_range(u64 as,
> + hyperv_fill_flush_list_func fill_func, void *data);
> +{
> + return -1;

This part for !IS_ENABLED(CONFIG_HYPERV) does not compile.

No big deal, but please add that to your testing procedures.

Paolo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [Resend PATCH V5 0/10] x86/KVM/Hyper-v: Add HV ept tlb range flush hypercall support in KVM

2018-12-21 Thread Paolo Bonzini
On 06/12/18 14:21, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu 
> 
> For nested memory virtualization, Hyper-v doesn't set write-protect
> L1 hypervisor EPT page directory and page table node to track changes 
> while it relies on guest to tell it changes via HvFlushGuestAddressLlist
> hypercall. HvFlushGuestAddressLlist hypercall provides a way to flush
> EPT page table with ranges which are specified by L1 hypervisor.
> 
> If L1 hypervisor uses INVEPT or HvFlushGuestAddressSpace hypercall to
> flush EPT tlb, Hyper-V will invalidate associated EPT shadow page table
> and sync L1's EPT table when next EPT page fault is triggered.
> HvFlushGuestAddressLlist hypercall helps to avoid such redundant EPT
> page fault and synchronization of shadow page table.
> 
> This patchset is based on the Patch "KVM/VMX: Check ept_pointer before
> flushing ept tlb"(https://marc.info/?l=kvm=154408169705686=2).
> 
> Change since v4:
>1) Split flush address and flush list patches. This patchset only 
> contains
>flush address patches. Will post flush list patches later.
>2) Expose function hyperv_fill_flush_guest_mapping_list()
>out of hyperv file
>3) Adjust parameter of hyperv_flush_guest_mapping_range()
>4) Reorder patchset and move Hyper-V and VMX changes ahead.
> 
> Change since v3:
> 1) Remove code of updating "tlbs_dirty" in 
> kvm_flush_remote_tlbs_with_range()
> 2) Remove directly tlb flush in the kvm_handle_hva_range()
> 3) Move tlb flush in kvm_set_pte_rmapp() to 
> kvm_mmu_notifier_change_pte()
> 4) Combine Vitaly's "don't pass EPT configuration info to
> vmx_hv_remote_flush_tlb()" fix
> 
> Change since v2:
>1) Fix comment in the kvm_flush_remote_tlbs_with_range()
>2) Move HV_MAX_FLUSH_PAGES and HV_MAX_FLUSH_REP_COUNT to
> hyperv-tlfs.h.
>3) Calculate HV_MAX_FLUSH_REP_COUNT in the macro definition
>4) Use HV_MAX_FLUSH_REP_COUNT to define length of gpa_list in
> struct hv_guest_mapping_flush_list.
> 
> Change since v1:
>1) Convert "end_gfn" of struct kvm_tlb_range to "pages" in order
>   to avoid confusion as to whether "end_gfn" is inclusive or exlusive.
>2) Add hyperv tlb range struct and replace kvm tlb range struct
>   with new struct in order to avoid using kvm struct in the hyperv
>   code directly.
> 
> 
> 
> Lan Tianyu (10):
>   KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops
>   x86/hyper-v: Add HvFlushGuestAddressList hypercall support
>   x86/Hyper-v: Add trace in the
> hyperv_nested_flush_guest_mapping_range()
>   KVM/VMX: Add hv tlb range flush support
>   KVM/MMU: Add tlb flush with range helper function
>   KVM: Replace old tlb flush function with new one to flush a specified
> range.
>   KVM: Make kvm_set_spte_hva() return int
>   KVM/MMU: Move tlb flush in kvm_set_pte_rmapp() to
> kvm_mmu_notifier_change_pte()
>   KVM/MMU: Flush tlb directly in the kvm_set_pte_rmapp()
>   KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()
> 
>  arch/arm/include/asm/kvm_host.h |  2 +-
>  arch/arm64/include/asm/kvm_host.h   |  2 +-
>  arch/mips/include/asm/kvm_host.h|  2 +-
>  arch/mips/kvm/mmu.c |  3 +-
>  arch/powerpc/include/asm/kvm_host.h |  2 +-
>  arch/powerpc/kvm/book3s.c   |  3 +-
>  arch/powerpc/kvm/e500_mmu_host.c|  3 +-
>  arch/x86/hyperv/nested.c| 80 +++
>  arch/x86/include/asm/hyperv-tlfs.h  | 32 +
>  arch/x86/include/asm/kvm_host.h |  9 +++-
>  arch/x86/include/asm/mshyperv.h | 15 ++
>  arch/x86/include/asm/trace/hyperv.h | 14 ++
>  arch/x86/kvm/mmu.c  | 96 
> +
>  arch/x86/kvm/paging_tmpl.h  |  3 +-
>  arch/x86/kvm/vmx.c  | 63 +---
>  virt/kvm/arm/mmu.c  |  6 ++-
>  virt/kvm/kvm_main.c |  5 +-
>  17 files changed, 292 insertions(+), 48 deletions(-)
> 

Queued, thanks.

Paolo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] Staging: wilc1000: unlock on error in init_chip()

2018-12-21 Thread Dan Carpenter
When there is an error in init_bus() then we need to call release_bus()
before we return.

Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver")
Signed-off-by: Dan Carpenter 
---
 drivers/staging/wilc1000/wilc_wlan.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 3c5e9e030cad..489e5a5038f8 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -1252,21 +1252,22 @@ static u32 init_chip(struct net_device *dev)
ret = wilc->hif_func->hif_read_reg(wilc, 0x1118, );
if (!ret) {
netdev_err(dev, "fail read reg 0x1118\n");
-   return ret;
+   goto release;
}
reg |= BIT(0);
ret = wilc->hif_func->hif_write_reg(wilc, 0x1118, reg);
if (!ret) {
netdev_err(dev, "fail write reg 0x1118\n");
-   return ret;
+   goto release;
}
ret = wilc->hif_func->hif_write_reg(wilc, 0xc, 0x71);
if (!ret) {
netdev_err(dev, "fail write reg 0xc\n");
-   return ret;
+   goto release;
}
}
 
+release:
release_bus(wilc, WILC_BUS_RELEASE_ONLY);
 
return ret;
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel