reservation.h: build error with lockdep disabled

[Russell King - ARM Linux]

As of 3c3b177a9369 ("reservation: add suppport for read-only access
using rcu") linux/reservation.h uses lockdep macros:

+#define reservation_object_held(obj) lockdep_is_held(&(obj)->lock.base)

This results in build errors when lockdep is disabled as lockdep_is_held()
is only available when lockdep is enabled.  This has been reported today
to break the etnaviv kernel driver, which we're hoping to submit for 4.5.

As this gets used with rcu_dereference_protected(), eg:

static inline struct reservation_object_list *
reservation_object_get_list(struct reservation_object *obj)
{
return rcu_dereference_protected(obj->fence,
 reservation_object_held(obj));
}

I'm guessing that it's not going to be a simple case of making it always
return true or always return false.

Any ideas how to solve this?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: reservation.h: build error with lockdep disabled

[Paul E. McKenney]

On Thu, Nov 26, 2015 at 01:43:40PM +, Russell King - ARM Linux wrote:
> As of 3c3b177a9369 ("reservation: add suppport for read-only access
> using rcu") linux/reservation.h uses lockdep macros:
> 
> +#define reservation_object_held(obj) lockdep_is_held(&(obj)->lock.base)
> 
> This results in build errors when lockdep is disabled as lockdep_is_held()
> is only available when lockdep is enabled.  This has been reported today
> to break the etnaviv kernel driver, which we're hoping to submit for 4.5.
> 
> As this gets used with rcu_dereference_protected(), eg:
> 
> static inline struct reservation_object_list *
> reservation_object_get_list(struct reservation_object *obj)
> {
> return rcu_dereference_protected(obj->fence,
>  reservation_object_held(obj));
> }
> 
> I'm guessing that it's not going to be a simple case of making it always
> return true or always return false.
> 
> Any ideas how to solve this?

The usual approach is something like this:

#ifdef CONFIG_PROVE_LOCKING
#define reservation_object_held(obj) lockdep_is_held(&(obj)->lock.base)
#else
#define reservation_object_held(obj) true
#endif

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Private Message!!

[linux-media-owner]

Good Day,

I am Mr. Lee Cheung from Hang Seng Bank, Hong Kong, there is the sum of 
$30,000,000.00 in my bank and i need you to work together with me to claim it, 
and we shall then share in the ratio of 60% for me, 40% for you. If interested 
please contact me as soon as possible for further details.

I will prefer you to reach me on my private Email address below:
Email: leecheun...@yahoo.com.hk

Kind Regards,
Mr. Lee Cheung.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] dib8000: Add support for Mygica/Geniatech S2870

[Nicolas Sugino]

MyGica/Geniatech S2870 is very similar to the S870 but with dual tuner. The 
card is recognised as Geniatech STK8096-PVR.

Signed-off-by: Nicolas Sugino 
---
 drivers/media/dvb-core/dvb-usb-ids.h|  1 +
 drivers/media/usb/dvb-usb/dib0700_devices.c | 77 -
 2 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index 0a46580..29eae14 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -118,6 +118,7 @@
 #define USB_PID_DIBCOM_STK807XP0x1f90
 #define USB_PID_DIBCOM_STK807XPVR  0x1f98
 #define USB_PID_DIBCOM_STK8096GP0x1fa0
+#define USB_PID_DIBCOM_STK8096PVR   0x1faa
 #define USB_PID_DIBCOM_NIM8096MD0x1fa8
 #define USB_PID_DIBCOM_TFE8096P0x1f9C
 #define USB_PID_DIBCOM_ANCHOR_2135_COLD0x2131
diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c 
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index 7ed4964..9e4e75e 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -1736,8 +1736,13 @@ static int dib809x_tuner_attach(struct dvb_usb_adapter 
*adap)
struct dib0700_adapter_state *st = adap->priv;
struct i2c_adapter *tun_i2c = 
st->dib8000_ops.get_i2c_master(adap->fe_adap[0].fe, 
DIBX000_I2C_INTERFACE_TUNER, 1);
 
-   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
-   return -ENODEV;
+   if(adap->id == 0) {
+   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
+   return -ENODEV;
+   } else {
+   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
+   return -ENODEV;
+   }
 
st->set_param_save = adap->fe_adap[0].fe->ops.tuner_ops.set_params;
adap->fe_adap[0].fe->ops.tuner_ops.set_params = 
dib8096_set_param_override;
@@ -1773,6 +1778,20 @@ static int stk809x_frontend_attach(struct 
dvb_usb_adapter *adap)
return adap->fe_adap[0].fe == NULL ?  -ENODEV : 0;
 }
 
+static int stk809x_frontend1_attach(struct dvb_usb_adapter *adap)
+{
+   struct dib0700_adapter_state *state = adap->priv;
+
+   if (!dvb_attach(dib8000_attach, >dib8000_ops))
+   return -ENODEV;
+
+   state->dib8000_ops.i2c_enumeration(>dev->i2c_adap, 1, 0x10, 0x82, 
0);
+
+   adap->fe_adap[0].fe = state->dib8000_ops.init(>dev->i2c_adap, 
0x82, _dib8000_config[1]);
+
+   return adap->fe_adap[0].fe == NULL ?  -ENODEV : 0;
+}
+
 static int nim8096md_tuner_attach(struct dvb_usb_adapter *adap)
 {
struct dib0700_adapter_state *st = adap->priv;
@@ -3794,6 +3813,7 @@ struct usb_device_id dib0700_usb_id_table[] = {
 /* 80 */{ USB_DEVICE(USB_VID_ELGATO,   USB_PID_ELGATO_EYETV_DTT_2) },
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_PCTV_2002E) },
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_PCTV_2002E_SE) },
+   { USB_DEVICE(USB_VID_PCTV,  USB_PID_DIBCOM_STK8096PVR) },
{ 0 }   /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -4959,6 +4979,59 @@ struct dvb_usb_device_properties dib0700_devices[] = {
RC_BIT_NEC,
.change_protocol  = dib0700_change_protocol,
},
+   }, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
+   .num_adapters = 2,
+   .adapter = {
+   {
+   .num_frontends = 1,
+   .fe = {{
+   .caps  = DVB_USB_ADAP_HAS_PID_FILTER |
+   
DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
+   .pid_filter_count = 32,
+   .pid_filter = stk80xx_pid_filter,
+   .pid_filter_ctrl = 
stk80xx_pid_filter_ctrl,
+   .frontend_attach  = 
stk809x_frontend_attach,
+   .tuner_attach = 
dib809x_tuner_attach,
+
+   DIB0700_DEFAULT_STREAMING_CONFIG(0x02),
+   }},
+   .size_of_priv =
+   sizeof(struct dib0700_adapter_state),
+   }, {
+   .num_frontends = 1,
+   .fe = {{
+   .caps  = DVB_USB_ADAP_HAS_PID_FILTER |
+   
DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
+   .pid_filter_count = 32,
+ 

Re: [media-workshop] [PATCH v8.4 81/83] [media] media-entity: init pads on entity init if was registered before

[Sakari Ailus]

Hi Mauro and Laurent,

On Tue, Nov 24, 2015 at 08:22:24AM -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 23 Nov 2015 17:21:22 -0300
> Javier Martinez Canillas  escreveu:
> 
> > Hello Laurent,
> > 
> > On 11/23/2015 01:20 PM, Laurent Pinchart wrote:
> > > Hi Javier,
> > > 
> > > (Replying to linux-media instead of media-workshop, I can't find this 
> > > patch in 
> > > my linux-media folder)
> > >
> > > Thank you for the patch.
> > >
> > 
> > Thanks for your feedback.
> >  
> > > On Monday 12 October 2015 13:44:10 Mauro Carvalho Chehab wrote:
> > >> From: Javier Martinez Canillas 
> > >>
> > >> If an entity is registered with a media device before is initialized
> > >> with media_device_register_entity(), the number of pads won't be set
> > >> so media_device_register_entity() won't create pad objects and add
> > >> it to the media device pads list.
> > >>
> > >> Do this at entity initialization time if the entity was registered
> > >> before so the graph is complete and correct regardless of the order
> > >> in which the entities are initialized and registered.
> > > 
> > > We now have two places where the pads graph objects are initialized and 
> > > that 
> > > looks like a bug to me as media_gobj_init() allocates IDs and, even 
> > > worse, 
> > > adds the entity to the media device entities list.
> > >
> 
> As Sakari commented on one of his reviews, media_gobj_init() should
> actually be renamed to media_gobj_create(), as it is the function that
> creates and registers a graph object on a given media device.
> 
> The hole idea is that any kind of graph object should be created at one
> single point: media_gobj_init - to be renamed to media_gobj_create(), as
> proposed by Sakari.

I think I proposed "register"; what I indeed wanted to underline with that
was that it was added to an external data structure, and cannot be released
without that reference being removed.

"init" or "create" lack that suggestion, well, with the exception of
possible memory allocation. But that's not relevant to the problem at
hand...

> 
> There's indeed bug on the existing subdev drivers: they want to create
> pads and links without even knowing to what media_device those will be
> associated! Every driver should be doing, instead:

This used to be at least allowed if not the preferred until recently. But I
agree we need to agree on the rules; earlier drivers just did what they
wanted to do. :-)

> 
> 1) create the media_device (or get a reference to an already created one);
> 2) create the entities associated with the mdev;
> 3) create the pads associated with the already created entity(ies);
> 4) register the entity;
> 5) create the links associated with two already created pads.
> 
> The above workflow is the correct one, as all graph objects should
> be added to the mdev graph object lists that will be used by the
> ioctl handler.
> 
> Also, please notice that, if all drivers follow the above procedure,
> we could also merge entity create and register functions into one,
> with is, IMHO, a good thing, as entity creation/registration will
> be atomic.
> 
> However, several subdevs do, instead:
> 
> 1) create entity(ies);
> 2) create pads;
> 3) get a reference for the media device;
> 4) register the entity;
> 5) create the links associated with two already created pads.
> 
> Changing such logic is not trivial, and require tests with devices
> that we don't have.
> 
> So, the approach we took is to allow the above workflow to keep
> working. That's what this patch does.
> 
> If you think it is worth to push for a change on those drivers, we
> could eventually add a printk_once() to warn that the driver is
> doing the wrong thing, and give some time for the drivers maintainers
> to fix their drivers, and remove the backward compat code after done.

Sounds good to me. Such warnings tend to be a lot more efficient than
changing the documentation, whether in code or elsewhere.

> > Yes but the idea of this patch was in fact to make it less error prone and
> > more robust since entities could either be initialized and later registered
> > or first be registered and then later initialized.
> >  
> > > We need to standardize on where graph objects are initialized across the 
> > > different kind of objects and document this clearly otherwise drivers 
> > > will get 
> > > it wrong.
> > >
> > 
> > I'm OK with having more strict rules of the order in which objects should
> > be initialized and registered and force all drivers to follow these docs.
> > 
> > >> Suggested-by: Mauro Carvalho Chehab 
> > 
> > This patch was suggested by Mauro so I'll also let him to comment what he
> > prefers or if he has another opinion on this.
> > 
> > >> Signed-off-by: Javier Martinez Canillas 
> > >> ---
> > >>  drivers/media/media-entity.c | 10 ++
> > >>  1 file changed, 10 insertions(+)
> > >>
> > >> diff --git a/drivers/media/media-entity.c 

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Fri Nov 27 04:00:18 CET 2015
git branch: test
git hash:   10897dacea26943dd80bd6629117f4620fc320ef
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3202-g618e15b
host hardware:  x86_64
host os:4.2.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: ERRORS
linux-2.6.33.7-i686: ERRORS
linux-2.6.34.7-i686: ERRORS
linux-2.6.35.9-i686: ERRORS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-rc1-i686: OK
linux-2.6.32.27-x86_64: ERRORS
linux-2.6.33.7-x86_64: ERRORS
linux-2.6.34.7-x86_64: ERRORS
linux-2.6.35.9-x86_64: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: ERRORS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] driver:dma bug_fix : access freed memory

[김정배]

From 8f6aeb362d9e44f29d46ae7694cdfee4408406ce Mon Sep 17 00:00:00 2001
From: "KIM JUGNBAE" 
Date: Thu, 26 Nov 2015 16:28:47 +0900
Subject: [PATCH] bug_fix : access freed memory

sync_fenc_free & fence_check_cb_func would be executed at
other cpu. fence_check_cb_func access freed fence memory after
kfree(fence) at sync_fence_free.
To escaped this issue, atomic_read(>status) need to be
protected by child_list_lock.

Signed-off-by: "kimjungbae\" " "
---
 drivers/dma-buf/fence.c  |   13 +
 drivers/staging/android/sync.c   |   10 +++---
 drivers/staging/android/sync_debug.c |2 ++
 include/linux/fence.h|1 +
 4 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 7bb9d65..d40211e 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -310,6 +310,19 @@ fence_remove_callback(struct fence *fence, struct fence_cb 
*cb)
 }
 EXPORT_SYMBOL(fence_remove_callback);
 
+bool
+fence_remove_callback_locked(struct fence *fence, struct fence_cb *cb)
+{
+   bool ret;
+
+   ret = !list_empty(>node);
+   if (ret)
+   list_del_init(>node);
+
+   return ret;
+}
+EXPORT_SYMBOL(fence_remove_callback_locked);
+
 struct default_wait_cb {
struct fence_cb base;
struct task_struct *task;
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 83f640f..9b60542 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -518,12 +518,16 @@ static const struct fence_ops android_fence_ops = {
 static void sync_fence_free(struct kref *kref)
 {
struct sync_fence *fence = container_of(kref, struct sync_fence, kref);
-   int i, status = atomic_read(>status);
+   int i;
+   unsigned long flags;
 
for (i = 0; i < fence->num_fences; ++i) {
-   if (status)
-   fence_remove_callback(fence->cbs[i].sync_pt,
+   spin_lock_irqsave(fence->cbs[i].sync_pt->lock, flags);
+   if (atomic_read(>status))
+   fence_remove_callback_locked(fence->cbs[i].sync_pt,
  >cbs[i].cb);
+   spin_unlock_irqrestore(fence->cbs[i].sync_pt->lock, flags);
+
fence_put(fence->cbs[i].sync_pt);
}
 
diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index 0153cd2..e854f35 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -155,7 +155,9 @@ static void sync_print_fence(struct seq_file *s, struct 
sync_fence *fence)
container_of(fence->cbs[i].sync_pt,
 struct sync_pt, base);
 
+   spin_lock_irqsave(pt->base.lock, flags);
sync_print_pt(s, pt, true);
+   spin_unlock_irqrestore(pt->base.lock, flags);
}
 
spin_lock_irqsave(>wq.lock, flags);
diff --git a/include/linux/fence.h b/include/linux/fence.h
index d174585..a5a3fd1 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -224,6 +224,7 @@ signed long fence_default_wait(struct fence *fence, bool 
intr, signed long timeo
 int fence_add_callback(struct fence *fence, struct fence_cb *cb,
   fence_func_t func);
 bool fence_remove_callback(struct fence *fence, struct fence_cb *cb);
+bool fence_remove_callback_locked(struct fence *fence, struct fence_cb *cb);
 void fence_enable_sw_signaling(struct fence *fence);
 
 /**
-- 
1.7.9.5

N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콡�bj)�끾�w*jgП�텎쉸듶줷/곴�z받뻿�2듷솳鈺�&�)傘첺뛴췍쳺�h��j:+v돣둾�녪

Re: [PATCH] driver:dma bug_fix : access freed memory

[Sudip Mukherjee]

On Fri, Nov 27, 2015 at 05:44:53AM +, 김정배 wrote:
> From 8f6aeb362d9e44f29d46ae7694cdfee4408406ce Mon Sep 17 00:00:00 2001
> From: "KIM JUGNBAE" 
> Date: Thu, 26 Nov 2015 16:28:47 +0900
> Subject: [PATCH] bug_fix : access freed memory

This part should not be present in the patch.

> 
> sync_fenc_free & fence_check_cb_func would be executed at
> other cpu. fence_check_cb_func access freed fence memory after
> kfree(fence) at sync_fence_free.
> To escaped this issue, atomic_read(>status) need to be
> protected by child_list_lock.
> 
> Signed-off-by: "kimjungbae\" " "

The From name and the Signed-off-by name shouls be same. Mayvbe you can
consider having Kim Jugnbae (or Jungbae) as both.

> ---
>  drivers/dma-buf/fence.c  |   13 +
>  drivers/staging/android/sync.c   |   10 +++---
>  drivers/staging/android/sync_debug.c |2 ++
>  include/linux/fence.h|1 +
>  4 files changed, 23 insertions(+), 3 deletions(-)

Usually staging patches can not touch anything outside staging.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html