Re: [PATCH 0/6] Intel Secure Guard Extensions
On Mon, May 09, 2016 at 08:38:25AM +0300, Jarkko Sakkinen wrote: > On Fri, May 06, 2016 at 01:54:14PM +0200, Thomas Gleixner wrote: > > On Fri, 6 May 2016, Jarkko Sakkinen wrote: > > > > > On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote: > > > > It would be helpful and instructive for anyone involved in this debate > > > > to review the following URL which details Intel's SGX licening > > > > program: > > > > > > > > https://software.intel.com/en-us/articles/intel-sgx-product-licensing > > > > > > I think it would be good to note that the licensing process is available > > > only for Windows. For Linux you can only use debug enclaves at the > > > moment. The default LE has "allow-all" policy for debug enclaves. > > > > Which makes the feature pretty useless. > > > > > > I think the only way forward to make all of this palatable is to > > > > embrace something similar to what has been done with Secure Boot. The > > > > Root Enclave Key will need to be something which can be reconfigured > > > > by the Platform Owner through BIOS/EFI. That model would take Intel > > > > off the hook from a security perspective and establish the notion of > > > > platform trust to be a bilateral relationship between a service > > > > provider and client. > > > > > > This concern has been raised many times now. Sadly this did not make > > > into Skyle but in future we will have one shot MSRs (can be set only > > > once per boot cycle) for defining your own root of trust. > > > > We'll wait for that to happen. > > I fully understand if you (and others) want to keep this standpoint but > what if we could get it to staging after I've revised it with suggested > changes and internal changes in my TODO? Then it would not pollute the > mainline kernel but still would be easily available for experimentation. No, staging is not a "dumping ground", it's for code that is not ready to be merged, and has some work left to do on it and it shows forward progress on that goal. I don't put things in there that the maintainers of the subsystems it affects do not want merged. See the many previous examples of code that has been rejected for staging as examples of this. sorry, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/6] intel_sgx: driver for Intel Secure Guard eXtensions
On Mon, May 09, 2016 at 08:29:17AM +0300, Jarkko Sakkinen wrote: > On Fri, Apr 29, 2016 at 03:22:19PM -0700, Jethro Beekman wrote: > > On 29-04-16 13:04, Jarkko Sakkinen wrote: > > >>> Why would you want to do that? > > >> > > >> ... > > > > > > Do you see this as a performance issue or why do you think that this > > > would hurt that much? > > > > I don't think it's a performance issue at all. I'm just giving an example > > of why > > you'd want to do this. I'm sure people who want to use this instruction set > > can > > come up with other uses, so I think the driver should support it. Other > > drivers > > on different platform might support this, in which case we should be > > compatible > > (to achieve the same enclave measurement). Other Linux drivers support it > > [1]. I > > would ask: why would you not want to do this? It seems trivial to expand the > > current flag into 16 separate flags; one for each 256-byte chunk in the > > page. > > I'm fine with adding a 16-bit bitmask. I did some experiementation and since this doesn't make the API more complicated it is probably ok. Field that I declared was: __u16 mrmask; Measure one page: add_page.mrmask = ~0; Skip the measurement: add_page.mrmask = 0: /Jarkko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 4/5] treewide: replace dev->trans_start update with helper
On 05/03/2016 04:33 PM, Florian Westphal wrote:
> Replace all trans_start updates with netif_trans_update helper.
> change was done via spatch:
>
> struct net_device *d;
> @@
> - d->trans_start = jiffies
> + netif_trans_update(d)
>
> Compile tested only.
>
> Cc: user-mode-linux-de...@lists.sourceforge.net
> Cc: linux-xte...@linux-xtensa.org
> Cc: linux1394-de...@lists.sourceforge.net
> Cc: linux-r...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: mpt-fusionlinux@broadcom.com
> Cc: linux-s...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-h...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-wirel...@vger.kernel.org
> Cc: linux-s...@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Cc: b.a.t.m@lists.open-mesh.org
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Florian Westphal
> ---
> Checkpatch complains about whitespace damage, but
> this extra whitespace already exists before this patch.
>
> drivers/net/can/mscan/mscan.c | 4 ++--
> drivers/net/can/usb/ems_usb.c | 4 ++--
> drivers/net/can/usb/esd_usb2.c | 4 ++--
> drivers/net/can/usb/peak_usb/pcan_usb_core.c | 4 ++--
> diff --git a/drivers/net/can/mscan/mscan.c b/drivers/net/can/mscan/mscan.c
> index e36b740..acb708f 100644
> --- a/drivers/net/can/mscan/mscan.c
> +++ b/drivers/net/can/mscan/mscan.c
> @@ -276,7 +276,7 @@ static netdev_tx_t mscan_start_xmit(struct sk_buff *skb,
> struct net_device *dev)
> out_8(®s->cantflg, 1 << buf_id);
>
> if (!test_bit(F_TX_PROGRESS, &priv->flags))
> - dev->trans_start = jiffies;
> + netif_trans_update(dev);
>
> list_add_tail(&priv->tx_queue[buf_id].list, &priv->tx_head);
>
> @@ -469,7 +469,7 @@ static irqreturn_t mscan_isr(int irq, void *dev_id)
> clear_bit(F_TX_PROGRESS, &priv->flags);
> priv->cur_pri = 0;
> } else {
> - dev->trans_start = jiffies;
> + netif_trans_update(dev);
> }
>
> if (!test_bit(F_TX_WAIT_ALL, &priv->flags))
> diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
> index 3400fd1..71f0e79 100644
> --- a/drivers/net/can/usb/ems_usb.c
> +++ b/drivers/net/can/usb/ems_usb.c
> @@ -521,7 +521,7 @@ static void ems_usb_write_bulk_callback(struct urb *urb)
> if (urb->status)
> netdev_info(netdev, "Tx URB aborted (%d)\n", urb->status);
>
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /* transmission complete interrupt */
> netdev->stats.tx_packets++;
> @@ -835,7 +835,7 @@ static netdev_tx_t ems_usb_start_xmit(struct sk_buff
> *skb, struct net_device *ne
> stats->tx_dropped++;
> }
> } else {
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /* Slow down tx path */
> if (atomic_read(&dev->active_tx_urbs) >= MAX_TX_URBS ||
> diff --git a/drivers/net/can/usb/esd_usb2.c b/drivers/net/can/usb/esd_usb2.c
> index 113e64f..784a900 100644
> --- a/drivers/net/can/usb/esd_usb2.c
> +++ b/drivers/net/can/usb/esd_usb2.c
> @@ -480,7 +480,7 @@ static void esd_usb2_write_bulk_callback(struct urb *urb)
> if (urb->status)
> netdev_info(netdev, "Tx URB aborted (%d)\n", urb->status);
>
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
> }
>
> static ssize_t show_firmware(struct device *d,
> @@ -820,7 +820,7 @@ static netdev_tx_t esd_usb2_start_xmit(struct sk_buff
> *skb,
> goto releasebuf;
> }
>
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /*
>* Release our reference to this URB, the USB core will eventually free
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> index 5a2e341..bfb91d8 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> @@ -274,7 +274,7 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
> netdev->stats.tx_bytes += context->data_len;
>
> /* prevent tx timeout */
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
> break;
>
> default:
> @@ -373,7 +373,7 @@ static netdev_tx_t peak_usb_ndo_start_xmit(struct sk_buff
> *skb,
> stats->tx_dropped++;
> }
> } else {
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /* slow down tx path */
> if (atomic_read(&dev->active_tx_urbs) >= PCAN_USB_MAX_TX_URBS)
For the drivers/can part:
Acked-by: Marc Kleine-Budde
regards,
Marc
--
Pengutro
[RESEND PATCH] ION: Sys_heap: Add cached pool to spead up cached buffer alloc
Add ion cached pool in system heap.
Signed-off-by: Chen Feng
Signed-off-by: Xia Qing
Reviewed-by: Fu Jun
---
drivers/staging/android/ion/ion_system_heap.c | 145 +-
1 file changed, 95 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index b69dfc7..c633252 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -49,7 +49,8 @@ static inline unsigned int order_to_size(int order)
struct ion_system_heap {
struct ion_heap heap;
- struct ion_page_pool *pools[0];
+ struct ion_page_pool *uncached_pools[0];
+ struct ion_page_pool *cached_pools[0];
};
static struct page *alloc_buffer_page(struct ion_system_heap *heap,
@@ -57,39 +58,36 @@ static struct page *alloc_buffer_page(struct
ion_system_heap *heap,
unsigned long order)
{
bool cached = ion_buffer_cached(buffer);
- struct ion_page_pool *pool = heap->pools[order_to_index(order)];
+ struct ion_page_pool *pool;
struct page *page;
- if (!cached) {
- page = ion_page_pool_alloc(pool);
- } else {
- gfp_t gfp_flags = low_order_gfp_flags;
-
- if (order > 4)
- gfp_flags = high_order_gfp_flags;
- page = alloc_pages(gfp_flags | __GFP_COMP, order);
- if (!page)
- return NULL;
- ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
- DMA_BIDIRECTIONAL);
- }
+ if (!cached)
+ pool = heap->uncached_pools[order_to_index(order)];
+ else
+ pool = heap->cached_pools[order_to_index(order)];
+ page = ion_page_pool_alloc(pool);
return page;
}
static void free_buffer_page(struct ion_system_heap *heap,
struct ion_buffer *buffer, struct page *page)
{
+ struct ion_page_pool *pool;
unsigned int order = compound_order(page);
bool cached = ion_buffer_cached(buffer);
- if (!cached && !(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE)) {
- struct ion_page_pool *pool = heap->pools[order_to_index(order)];
-
- ion_page_pool_free(pool, page);
- } else {
+ if (buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE) {
__free_pages(page, order);
+ return;
}
+
+ if (!cached)
+ pool = heap->uncached_pools[order_to_index(order)];
+ else
+ pool = heap->cached_pools[order_to_index(order)];
+
+ ion_page_pool_free(pool, page);
}
@@ -186,11 +184,10 @@ static void ion_system_heap_free(struct ion_buffer
*buffer)
int i;
/*
-* uncached pages come from the page pools, zero them before returning
-* for security purposes (other allocations are zerod at
-* alloc time
+* zero the buffer before returning for security purposes
+* (other allocations are zerod at alloc time)
*/
- if (!cached && !(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE))
+ if (!(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE))
ion_heap_buffer_zero(buffer);
for_each_sg(table->sgl, sg, table->nents, i)
@@ -224,19 +221,29 @@ static int ion_system_heap_shrink(struct ion_heap *heap,
gfp_t gfp_mask,
only_scan = 1;
for (i = 0; i < num_orders; i++) {
- struct ion_page_pool *pool = sys_heap->pools[i];
-
- nr_freed = ion_page_pool_shrink(pool, gfp_mask, nr_to_scan);
- nr_total += nr_freed;
+ struct ion_page_pool *pool = sys_heap->uncached_pools[i];
if (!only_scan) {
+ nr_freed = ion_page_pool_shrink(pool, gfp_mask,
+ nr_to_scan);
+ nr_to_scan -= nr_freed;
+ nr_total += nr_freed;
+ pool = sys_heap->cached_pools[i];
+ nr_freed = ion_page_pool_shrink(pool, gfp_mask,
+ nr_to_scan);
nr_to_scan -= nr_freed;
- /* shrink completed */
+ nr_total += nr_freed;
if (nr_to_scan <= 0)
break;
+ } else {
+ nr_freed = ion_page_pool_shrink(pool, gfp_mask,
+ nr_to_scan);
+ nr_total += nr_freed;
+ nr_freed = ion_page_pool_shrink(pool, gfp_mask,
+ nr_to_scan);
+ nr_total += nr_freed;
}
Re: [RESEND PATCH] ION: Sys_heap: Add cached pool to spead up cached buffer alloc
On Mon, May 09, 2016 at 04:37:34PM +0800, Chen Feng wrote: > Add ion cached pool in system heap. > > Signed-off-by: Chen Feng > Signed-off-by: Xia Qing > Reviewed-by: Fu Jun > --- > drivers/staging/android/ion/ion_system_heap.c | 145 > +- > 1 file changed, 95 insertions(+), 50 deletions(-) You didn't list what changed here. Please do so, otherwise we think it's identical to the previous patch you sent :( thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/6] Intel Secure Guard Extensions
On Mon, May 09, 2016 at 09:04:09AM +0200, Greg KH wrote: > On Mon, May 09, 2016 at 08:38:25AM +0300, Jarkko Sakkinen wrote: > > On Fri, May 06, 2016 at 01:54:14PM +0200, Thomas Gleixner wrote: > > > On Fri, 6 May 2016, Jarkko Sakkinen wrote: > > > > > > > On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote: > > > > > It would be helpful and instructive for anyone involved in this debate > > > > > to review the following URL which details Intel's SGX licening > > > > > program: > > > > > > > > > > https://software.intel.com/en-us/articles/intel-sgx-product-licensing > > > > > > > > I think it would be good to note that the licensing process is > > > > available > > > > only for Windows. For Linux you can only use debug enclaves at the > > > > moment. The default LE has "allow-all" policy for debug enclaves. > > > > > > Which makes the feature pretty useless. > > > > > > > > I think the only way forward to make all of this palatable is to > > > > > embrace something similar to what has been done with Secure Boot. The > > > > > Root Enclave Key will need to be something which can be reconfigured > > > > > by the Platform Owner through BIOS/EFI. That model would take Intel > > > > > off the hook from a security perspective and establish the notion of > > > > > platform trust to be a bilateral relationship between a service > > > > > provider and client. > > > > > > > > This concern has been raised many times now. Sadly this did not make > > > > into Skyle but in future we will have one shot MSRs (can be set only > > > > once per boot cycle) for defining your own root of trust. > > > > > > We'll wait for that to happen. > > > > I fully understand if you (and others) want to keep this standpoint but > > what if we could get it to staging after I've revised it with suggested > > changes and internal changes in my TODO? Then it would not pollute the > > mainline kernel but still would be easily available for experimentation. > > No, staging is not a "dumping ground", it's for code that is not ready > to be merged, and has some work left to do on it and it shows forward > progress on that goal. I don't put things in there that the maintainers > of the subsystems it affects do not want merged. See the many previous > examples of code that has been rejected for staging as examples of this. > > sorry, NP, point taken. > greg k-h /Jarkko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/6] Intel Secure Guard Extensions
On Mon, May 09, 2016 at 08:27:04AM +0200, Thomas Gleixner wrote: > On Mon, 9 May 2016, Jarkko Sakkinen wrote: > > On Fri, May 06, 2016 at 01:54:14PM +0200, Thomas Gleixner wrote: > > > On Fri, 6 May 2016, Jarkko Sakkinen wrote: > > > > > > > On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote: > > > > > It would be helpful and instructive for anyone involved in this debate > > > > > to review the following URL which details Intel's SGX licening > > > > > program: > > > > > > > > > > https://software.intel.com/en-us/articles/intel-sgx-product-licensing > > > > > > > > I think it would be good to note that the licensing process is > > > > available > > > > only for Windows. For Linux you can only use debug enclaves at the > > > > moment. The default LE has "allow-all" policy for debug enclaves. > > > > > > Which makes the feature pretty useless. > > > > > > > > I think the only way forward to make all of this palatable is to > > > > > embrace something similar to what has been done with Secure Boot. The > > > > > Root Enclave Key will need to be something which can be reconfigured > > > > > by the Platform Owner through BIOS/EFI. That model would take Intel > > > > > off the hook from a security perspective and establish the notion of > > > > > platform trust to be a bilateral relationship between a service > > > > > provider and client. > > > > > > > > This concern has been raised many times now. Sadly this did not make > > > > into Skyle but in future we will have one shot MSRs (can be set only > > > > once per boot cycle) for defining your own root of trust. > > > > > > We'll wait for that to happen. > > > > I fully understand if you (and others) want to keep this standpoint but > > what if we could get it to staging after I've revised it with suggested > > This should not go to staging at all. Either this is going to be a real useful > driver or we just keep it out of tree. > > > changes and internal changes in my TODO? Then it would not pollute the > > mainline kernel but still would be easily available for experimentation. > > How are we supposed to experiment with that if there is no launch enclave for > Linux available? Understood. I appreciate all the feedback that I've received and come back later when the time is better with a refined patch set (especially Andys feedback showed that the documentation needs alot of rework). > Thanks, > > tglx /Jarkko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1] ION: Sys_heap: Add cached pool to spead up cached buffer alloc
Add ion cached pool in system heap. This patch add a cached pool
in system heap. It has a great improvement of alloc for cached
buffer.
v1: Makes the cached buffer zeroed before going to pool
Signed-off-by: Chen Feng
Signed-off-by: Xia Qing
Reviewed-by: Fu Jun
---
drivers/staging/android/ion/ion_system_heap.c | 155 +-
1 file changed, 103 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index b69dfc7..4b14a0b 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -49,47 +49,55 @@ static inline unsigned int order_to_size(int order)
struct ion_system_heap {
struct ion_heap heap;
- struct ion_page_pool *pools[0];
+ struct ion_page_pool *uncached_pools[0];
+ struct ion_page_pool *cached_pools[0];
};
+/**
+ * The page from page-pool are all zeroed before. We need do cache
+ * clean for cached buffer. The uncached buffer are always non-cached
+ * since it's allocated. So no need for non-cached pages.
+ */
static struct page *alloc_buffer_page(struct ion_system_heap *heap,
struct ion_buffer *buffer,
unsigned long order)
{
bool cached = ion_buffer_cached(buffer);
- struct ion_page_pool *pool = heap->pools[order_to_index(order)];
+ struct ion_page_pool *pool;
struct page *page;
- if (!cached) {
- page = ion_page_pool_alloc(pool);
- } else {
- gfp_t gfp_flags = low_order_gfp_flags;
+ if (!cached)
+ pool = heap->uncached_pools[order_to_index(order)];
+ else
+ pool = heap->cached_pools[order_to_index(order)];
- if (order > 4)
- gfp_flags = high_order_gfp_flags;
- page = alloc_pages(gfp_flags | __GFP_COMP, order);
- if (!page)
- return NULL;
- ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
- DMA_BIDIRECTIONAL);
- }
+ page = ion_page_pool_alloc(pool);
+ if (cached)
+ ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
+ DMA_BIDIRECTIONAL);
return page;
}
static void free_buffer_page(struct ion_system_heap *heap,
struct ion_buffer *buffer, struct page *page)
{
+ struct ion_page_pool *pool;
unsigned int order = compound_order(page);
bool cached = ion_buffer_cached(buffer);
- if (!cached && !(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE)) {
- struct ion_page_pool *pool = heap->pools[order_to_index(order)];
-
- ion_page_pool_free(pool, page);
- } else {
+ /* go to system */
+ if (buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE) {
__free_pages(page, order);
+ return;
}
+
+ if (!cached)
+ pool = heap->uncached_pools[order_to_index(order)];
+ else
+ pool = heap->cached_pools[order_to_index(order)];
+
+ ion_page_pool_free(pool, page);
}
@@ -181,16 +189,11 @@ static void ion_system_heap_free(struct ion_buffer
*buffer)
struct ion_system_heap,
heap);
struct sg_table *table = buffer->sg_table;
- bool cached = ion_buffer_cached(buffer);
struct scatterlist *sg;
int i;
- /*
-* uncached pages come from the page pools, zero them before returning
-* for security purposes (other allocations are zerod at
-* alloc time
-*/
- if (!cached && !(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE))
+ /* zero the buffer before goto page pool */
+ if (!(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE))
ion_heap_buffer_zero(buffer);
for_each_sg(table->sgl, sg, table->nents, i)
@@ -224,19 +227,29 @@ static int ion_system_heap_shrink(struct ion_heap *heap,
gfp_t gfp_mask,
only_scan = 1;
for (i = 0; i < num_orders; i++) {
- struct ion_page_pool *pool = sys_heap->pools[i];
-
- nr_freed = ion_page_pool_shrink(pool, gfp_mask, nr_to_scan);
- nr_total += nr_freed;
+ struct ion_page_pool *pool = sys_heap->uncached_pools[i];
if (!only_scan) {
+ nr_freed = ion_page_pool_shrink(pool, gfp_mask,
+ nr_to_scan);
nr_to_scan -= nr_freed;
- /* shrink completed */
+ nr_total += nr_freed;
+ pool = sys_heap->cached_pools[i];
+
Re: [PATCH v2 1/1] Staging: android: uapi: ion: Fixes indentation
On Sun, May 08, 2016 at 01:41:47PM +0200, Thimo Braker wrote:
> Fixes the indentation before variable names.
>
> Signed-off-by: Thimo Braker
> ---
> drivers/staging/android/uapi/ion.h | 20 ++--
> drivers/staging/android/uapi/ion_test.h | 10 +-
> 2 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/staging/android/uapi/ion.h
> b/drivers/staging/android/uapi/ion.h
> index 0a8e40f..6dda8d5 100644
> --- a/drivers/staging/android/uapi/ion.h
> +++ b/drivers/staging/android/uapi/ion.h
> @@ -91,11 +91,11 @@ enum ion_heap_type {
> * Provided by userspace as an argument to the ioctl
> */
> struct ion_allocation_data {
> - size_t len;
> - size_t align;
> - unsigned int heap_id_mask;
> - unsigned int flags;
> - ion_user_handle_t handle;
> + size_t len;
> + size_t align;
> + unsigned intheap_id_mask;
> + unsigned intflags;
> + ion_user_handle_t handle;
Hm, that's not really a "fix" anywhere. There's no kernel rule that you
have to align the fields in a structure.
What "tool" told you this was necessary?
So this patch isn't needed, sorry.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] staging: dgnc: remove redundant NULL check in
On Wed, May 04, 2016 at 02:13:04PM +0900, Daeseok Youn wrote: > tty and ch are already checked for NULL > before calling dgnc_block_til_ready(). > > Signed-off-by: Daeseok Youn Your subject line doesn't make sense, please fix it up and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] staging: dgnc: remove useless assigned error value in
On Wed, May 04, 2016 at 02:13:26PM +0900, Daeseok Youn wrote: > the result in dgnc_get_mstat() was initialized with -EIO but > there are no use of EIO as a result in this function. > > Signed-off-by: Daeseok Youn > --- > drivers/staging/dgnc/dgnc_tty.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Same Subject: problem here too, it doesn't make sense. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/gdm724x: Use tty_alloc_driver instead of alloc_tty_driver
On Sat, May 07, 2016 at 11:29:14PM -0400, Bruno Carvalho wrote:
> - alloc_tty_driver() is deprecated. So it is replaced by tty_alloc_driver()
>
> Signed-off-by: Bruno Carvalho
> ---
> drivers/staging/gdm724x/gdm_tty.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/gdm724x/gdm_tty.c
> b/drivers/staging/gdm724x/gdm_tty.c
> index eb7e252..c0888f5 100644
> --- a/drivers/staging/gdm724x/gdm_tty.c
> +++ b/drivers/staging/gdm724x/gdm_tty.c
> @@ -306,7 +306,9 @@ int register_lte_tty_driver(void)
> int ret;
>
> for (i = 0; i < TTY_MAX_COUNT; i++) {
> - tty_driver = alloc_tty_driver(GDM_TTY_MINOR);
> + tty_driver = tty_alloc_driver(GDM_TTY_MINOR,
> + TTY_DRIVER_REAL_RAW |
> + TTY_DRIVER_DYNAMIC_DEV);
You just changed the logic here, previously we were passing in 0 for the
flags, now you are setting some to a different value, why?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: wlan-ng: fix comments style
On Sun, May 08, 2016 at 10:45:16AM -0400, YU Bo wrote: > The patch fixed warning reported by checkpatch.pl: Block comments use a > trailing */ on a separate line. > > Signed-off-by: YU Bo > --- > drivers/staging/wlan-ng/prism2mgmt.h |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Patch doesn't apply to my tree, what branch did you make this against? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH] ION: Sys_heap: Add cached pool to spead up cached buffer alloc
Hi Greg, Please see my v1 version for detail. Thank you. On 2016年05月09日 17:02, Greg KH wrote: > On Mon, May 09, 2016 at 04:37:34PM +0800, Chen Feng wrote: >> Add ion cached pool in system heap. >> >> Signed-off-by: Chen Feng >> Signed-off-by: Xia Qing >> Reviewed-by: Fu Jun >> --- >> drivers/staging/android/ion/ion_system_heap.c | 145 >> +- >> 1 file changed, 95 insertions(+), 50 deletions(-) > > You didn't list what changed here. Please do so, otherwise we think > it's identical to the previous patch you sent :( > > thanks, > > greg k-h > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] staging: lustre: o2iblnd: make rdma_create_id() support containers
From: Li Dongyang Add support for lustre's ko2iblnd driver to work with containers which was requested by Sebastien Buisson. Signed-off-by: Li Dongyang Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6215 Reviewed-on: http://review.whamcloud.com/18759 Reviewed-by: James Simmons Reviewed-by: Sebastien Buisson Reviewed-by: Oleg Drokin Signed-off-by: James Simmons --- .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h|2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h index b22984f..45bbe93 100644 --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h @@ -109,7 +109,7 @@ extern kib_tunables_t kiblnd_tunables; IBLND_CREDIT_HIGHWATER_V1 : \ t->lnd_peercredits_hiw) -#define kiblnd_rdma_create_id(cb, dev, ps, qpt) rdma_create_id(&init_net, \ +#define kiblnd_rdma_create_id(cb, dev, ps, qpt) rdma_create_id(current->nsproxy->net_ns, \ cb, dev, \ ps, qpt) -- 1.7.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] staging: lustre: small recent fixes for LNet/libcfs
Here are various fixes and improvements for the libcfs and LNet layer. Two memory leaks fixed as well as adding container support for the ko2iblnd driver. Lastly handle the lower limit of the mlx5 driver for cap.max_send_wr. Dmitry Eremin (1): staging: lustre: o2iblnd: limit cap.max_send_wr for MLX5 James Simmons (2): staging: lustre: libcfs: fix memort leak in libcfs crypto layer staging: lustre: ko2iblnd: fix memory corruption with fragments Li Dongyang (1): staging: lustre: o2iblnd: make rdma_create_id() support containers .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c| 20 +++- .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h|2 +- .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c |8 .../lustre/lnet/libcfs/linux/linux-crypto.c|1 + 4 files changed, 25 insertions(+), 6 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: lustre: o2iblnd: limit cap.max_send_wr for MLX5
From: Dmitry Eremin
Decrease cap.max_send_wr until it is accepted by rdma_create_qp()
Signed-off-by: Dmitry Eremin
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7124
Reviewed-on: http://review.whamcloud.com/18347
Reviewed-by: Olaf Weber
Reviewed-by: Doug Oucharek
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c| 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index d99b4fa..bc179a2 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -768,7 +768,12 @@ kib_conn_t *kiblnd_create_conn(kib_peer_t *peer, struct
rdma_cm_id *cmid,
conn->ibc_sched = sched;
- rc = rdma_create_qp(cmid, conn->ibc_hdev->ibh_pd, init_qp_attr);
+ do {
+ rc = rdma_create_qp(cmid, conn->ibc_hdev->ibh_pd, init_qp_attr);
+ if (!rc || init_qp_attr->cap.max_send_wr < 16)
+ break;
+ } while (rc);
+
if (rc) {
CERROR("Can't create QP: %d, send_wr: %d, recv_wr: %d\n",
rc, init_qp_attr->cap.max_send_wr,
@@ -776,6 +781,10 @@ kib_conn_t *kiblnd_create_conn(kib_peer_t *peer, struct
rdma_cm_id *cmid,
goto failed_2;
}
+ if (init_qp_attr->cap.max_send_wr != IBLND_SEND_WRS(conn))
+ CDEBUG(D_NET, "original send wr %d, created with %d\n",
+ IBLND_SEND_WRS(conn), init_qp_attr->cap.max_send_wr);
+
LIBCFS_FREE(init_qp_attr, sizeof(*init_qp_attr));
/* 1 ref for caller and each rxmsg */
--
1.7.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: lustre: ko2iblnd: fix memory corruption with fragments
In my test of the upstream client this change exposed a long
standing issues where we have a offset that is not page algined
would causes us to access memory beyond the scatter gather list
which was causing memory corruption when all 256 fragments were
in use.
Signed-off-by: James Simmons
---
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|9 +
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c |8
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index bc179a2..8a18384 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -2020,8 +2020,8 @@ static void kiblnd_destroy_tx_pool(kib_pool_t *pool)
sizeof(*tx->tx_pages));
if (tx->tx_frags)
LIBCFS_FREE(tx->tx_frags,
- IBLND_MAX_RDMA_FRAGS *
- sizeof(*tx->tx_frags));
+ (1 + IBLND_MAX_RDMA_FRAGS) *
+sizeof(*tx->tx_frags));
if (tx->tx_wrq)
LIBCFS_FREE(tx->tx_wrq,
(1 + IBLND_MAX_RDMA_FRAGS) *
@@ -2099,11 +2099,12 @@ static int kiblnd_create_tx_pool(kib_poolset_t *ps, int
size,
}
LIBCFS_CPT_ALLOC(tx->tx_frags, lnet_cpt_table(), ps->ps_cpt,
-IBLND_MAX_RDMA_FRAGS * sizeof(*tx->tx_frags));
+(1 + IBLND_MAX_RDMA_FRAGS) *
+sizeof(*tx->tx_frags));
if (!tx->tx_frags)
break;
- sg_init_table(tx->tx_frags, IBLND_MAX_RDMA_FRAGS);
+ sg_init_table(tx->tx_frags, IBLND_MAX_RDMA_FRAGS + 1);
LIBCFS_CPT_ALLOC(tx->tx_wrq, lnet_cpt_table(), ps->ps_cpt,
(1 + IBLND_MAX_RDMA_FRAGS) *
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index bbfee53..0f7e3a1 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -689,6 +689,10 @@ kiblnd_setup_rd_iov(lnet_ni_t *ni, kib_tx_t *tx,
kib_rdma_desc_t *rd,
sg_set_page(sg, page, fragnob, page_offset);
sg = sg_next(sg);
+ if (!sg) {
+ CERROR("lacking enough sg entries to map tx\n");
+ return -EFAULT;
+ }
if (offset + fragnob < iov->iov_len) {
offset += fragnob;
@@ -733,6 +737,10 @@ kiblnd_setup_rd_kiov(lnet_ni_t *ni, kib_tx_t *tx,
kib_rdma_desc_t *rd,
sg_set_page(sg, kiov->kiov_page, fragnob,
kiov->kiov_offset + offset);
sg = sg_next(sg);
+ if (!sg) {
+ CERROR("lacking enough sg entries to map tx\n");
+ return -EFAULT;
+ }
offset = 0;
kiov++;
--
1.7.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: lustre: libcfs: fix memort leak in libcfs crypto layer
During code review Boyko discovered a memory leak. This
patch fixes that leak.
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4423
Reviewed-on: http://review.whamcloud.com/19716
Reviewed-by: Alexander Boyko
Reviewed-by: Frank Zago
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
.../lustre/lnet/libcfs/linux/linux-crypto.c|1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-crypto.c
b/drivers/staging/lustre/lnet/libcfs/linux/linux-crypto.c
index 84f9b7b..5c0116a 100644
--- a/drivers/staging/lustre/lnet/libcfs/linux/linux-crypto.c
+++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-crypto.c
@@ -99,6 +99,7 @@ static int cfs_crypto_hash_alloc(enum cfs_crypto_hash_alg
hash_alg,
(*type)->cht_size);
if (err != 0) {
+ ahash_request_free(*req);
crypto_free_ahash(tfm);
return err;
}
--
1.7.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v9 net-next 1/2] hv_sock: introduce Hyper-V Sockets
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Monday, May 9, 2016 1:45
> To: Dexuan Cui
> Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; cav...@redhat.com; KY
> Srinivasan ; Haiyang Zhang ;
> j...@perches.com; vkuzn...@redhat.com
> Subject: Re: [PATCH v9 net-next 1/2] hv_sock: introduce Hyper-V Sockets
>
> From: Dexuan Cui
> Date: Sun, 8 May 2016 06:11:04 +
>
> > Thanks for pointing this out!
> > I understand, so I think I should add a module parameter, e.g.,
> > "hv_sock.max_socket_number" with a default value, say, 1024?
>
> No, you should get rid of the huge multi-page buffers.
Hi David,
Ok, how do you like the below proof-of-concept patch snippet?
I use 1 page for the recv buf and another page for send buf. They should be
allocated by kmalloc(sizeof(struct hvsock_send/recv_buf), GFP_KERNEL).
And, by default, I use 2 pages for VMBUS send/recv ringbuffers respectively.
(Note: 2 is the minimal ringbuffer size because actually 1 page of the two is
used
as the shared read/write index etc, rather than data)
A module parameter will be added to allow the user to use a big ringbuffer
size, if the user cares too much about the performance.
Another parameter will be added to limit how many hvsock sockets can be
created at most. The default value can be 1024, meaning at most
1024 * (2+2+1+1) * 4KB = 24MB memory is used.
-#define VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV (5 * PAGE_SIZE)
-#define VMBUS_RINGBUFFER_SIZE_HVSOCK_SEND (5 * PAGE_SIZE)
+#define VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV (2 * PAGE_SIZE)
+#define VMBUS_RINGBUFFER_SIZE_HVSOCK_SEND (2 * PAGE_SIZE)
-#define HVSOCK_RCV_BUF_SZ VMBUS_RINGBUFFER_SIZE_HVSOCK_RECV
+#define HVSOCK_RCV_BUF_SZ PAGE_SIZE
#define HVSOCK_SND_BUF_SZ PAGE_SIZE
+struct hvsock_send_buf {
+ struct vmpipe_proto_header hdr;
+ u8 buf[HVSOCK_SND_BUF_SZ];
+};
+
+struct hvsock_recv_buf {
+ struct vmpipe_proto_header hdr;
+ u8 buf[HVSOCK_RCV_BUF_SZ];
+
+ unsigned int data_len;
+ unsigned int data_offset;
+};
+
@@ -35,21 +48,8 @@ struct hvsock_sock {
struct vmbus_channel *channel;
- struct {
- struct vmpipe_proto_header hdr;
- u8 buf[HVSOCK_SND_BUF_SZ];
- } send;
-
- struct {
- struct vmpipe_proto_header hdr;
- u8 buf[HVSOCK_RCV_BUF_SZ];
-
- unsigned int data_len;
- unsigned int data_offset;
- } recv;
+ struct hvsock_send_buf *send_buf;
+ struct hvsock_recv_buf *recv_buf;
};
Thanks,
-- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
URGENT
Greetings, I am Mrs.Katherine Pascal. an aging widow suffering from Cancer illness .I have some funds Which I have inherited from my late husband, the sum of ($10.9 Million Dollars) And I needed a very honest and sincere Individual or co-operate organization that will use the fund for work of humanity, I found your email address from the Human resources data base and decided to contact you. Please if you would be able to use the funds for the work of humanity as I have stated here in order to fulfill my late husband wishes please, kindly reply me back immediately. Thanks. Regards, Mrs.Katherine Pascal. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: speakup: ensure we do not overrun synths array
From: Colin Ian King synth_add allows one to add MAXSYNTHS synths to the synths array; however it always NULLifies the next synth in the array which means that on the MAXSYNTHS synth we get an out-of-bounds write of the NULL to the synths array. Make the synths array MAXSYNTHS + 1 elements in size to allow for the final NULL sentinal to avoid the out-of-bounds write. Issue found wit CoverityScan, CID#744671 Signed-off-by: Colin Ian King --- drivers/staging/speakup/synth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/speakup/synth.c b/drivers/staging/speakup/synth.c index 4f462c3..810a214 100644 --- a/drivers/staging/speakup/synth.c +++ b/drivers/staging/speakup/synth.c @@ -18,7 +18,7 @@ #include "serialio.h" #define MAXSYNTHS 16 /* Max number of synths in array. */ -static struct spk_synth *synths[MAXSYNTHS]; +static struct spk_synth *synths[MAXSYNTHS + 1]; struct spk_synth *synth; char spk_pitch_buff[32] = ""; static int module_status; -- 2.8.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: ensure we do not overrun synths array
Colin King, on Mon 09 May 2016 23:22:14 +0100, wrote: > From: Colin Ian King > > synth_add allows one to add MAXSYNTHS synths to the synths array; > however it always NULLifies the next synth in the array which > means that on the MAXSYNTHS synth we get an out-of-bounds write of > the NULL to the synths array. Make the synths array MAXSYNTHS + 1 > elements in size to allow for the final NULL sentinal to avoid the > out-of-bounds write. > > Issue found wit CoverityScan, CID#744671 > > Signed-off-by: Colin Ian King Reviewed-by: Samuel Thibault > --- > drivers/staging/speakup/synth.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/speakup/synth.c b/drivers/staging/speakup/synth.c > index 4f462c3..810a214 100644 > --- a/drivers/staging/speakup/synth.c > +++ b/drivers/staging/speakup/synth.c > @@ -18,7 +18,7 @@ > #include "serialio.h" > > #define MAXSYNTHS 16 /* Max number of synths in array. */ > -static struct spk_synth *synths[MAXSYNTHS]; > +static struct spk_synth *synths[MAXSYNTHS + 1]; > struct spk_synth *synth; > char spk_pitch_buff[32] = ""; > static int module_status; > -- > 2.8.1 > -- Samuel Actually, typing random strings in the Finder does the equivalent of filename completion. (Discussion in comp.os.linux.misc on the intuitiveness of commands: file completion vs. the Mac Finder.) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH] ION: Sys_heap: Add cached pool to spead up cached buffer alloc
On 05/09/2016 01:37 AM, Chen Feng wrote:
Add ion cached pool in system heap.
Signed-off-by: Chen Feng
Signed-off-by: Xia Qing
Reviewed-by: Fu Jun
---
drivers/staging/android/ion/ion_system_heap.c | 145 +-
1 file changed, 95 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index b69dfc7..c633252 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -49,7 +49,8 @@ static inline unsigned int order_to_size(int order)
struct ion_system_heap {
struct ion_heap heap;
- struct ion_page_pool *pools[0];
+ struct ion_page_pool *uncached_pools[0];
+ struct ion_page_pool *cached_pools[0];
};
static struct page *alloc_buffer_page(struct ion_system_heap *heap,
@@ -57,39 +58,36 @@ static struct page *alloc_buffer_page(struct
ion_system_heap *heap,
unsigned long order)
{
bool cached = ion_buffer_cached(buffer);
- struct ion_page_pool *pool = heap->pools[order_to_index(order)];
+ struct ion_page_pool *pool;
struct page *page;
- if (!cached) {
- page = ion_page_pool_alloc(pool);
- } else {
- gfp_t gfp_flags = low_order_gfp_flags;
-
- if (order > 4)
- gfp_flags = high_order_gfp_flags;
- page = alloc_pages(gfp_flags | __GFP_COMP, order);
- if (!page)
- return NULL;
- ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
- DMA_BIDIRECTIONAL);
- }
+ if (!cached)
+ pool = heap->uncached_pools[order_to_index(order)];
+ else
+ pool = heap->cached_pools[order_to_index(order)];
+ page = ion_page_pool_alloc(pool);
return page;
}
This is a change in behavior. The page is no longer guaranteed to be synced
in the cache. If the page came from the pool (not just freshly allocated)
the cache state is unknown. Do you have a good explanation why we no longer
need to do the cache flush here on every allocation?
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH] ION: Sys_heap: Add cached pool to spead up cached buffer alloc
Hi Laura,
On 2016/5/10 7:50, Laura Abbott wrote:
> On 05/09/2016 01:37 AM, Chen Feng wrote:
>> Add ion cached pool in system heap.
>>
>> Signed-off-by: Chen Feng
>> Signed-off-by: Xia Qing
>> Reviewed-by: Fu Jun
>> ---
>> drivers/staging/android/ion/ion_system_heap.c | 145
>> +-
>> 1 file changed, 95 insertions(+), 50 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion_system_heap.c
>> b/drivers/staging/android/ion/ion_system_heap.c
>> index b69dfc7..c633252 100644
>> --- a/drivers/staging/android/ion/ion_system_heap.c
>> +++ b/drivers/staging/android/ion/ion_system_heap.c
>> @@ -49,7 +49,8 @@ static inline unsigned int order_to_size(int order)
>>
>> struct ion_system_heap {
>> struct ion_heap heap;
>> -struct ion_page_pool *pools[0];
>> +struct ion_page_pool *uncached_pools[0];
>> +struct ion_page_pool *cached_pools[0];
>> };
>>
>> static struct page *alloc_buffer_page(struct ion_system_heap *heap,
>> @@ -57,39 +58,36 @@ static struct page *alloc_buffer_page(struct
>> ion_system_heap *heap,
>>unsigned long order)
>> {
>> bool cached = ion_buffer_cached(buffer);
>> -struct ion_page_pool *pool = heap->pools[order_to_index(order)];
>> +struct ion_page_pool *pool;
>> struct page *page;
>>
>> -if (!cached) {
>> -page = ion_page_pool_alloc(pool);
>> -} else {
>> -gfp_t gfp_flags = low_order_gfp_flags;
>> -
>> -if (order > 4)
>> -gfp_flags = high_order_gfp_flags;
>> -page = alloc_pages(gfp_flags | __GFP_COMP, order);
>> -if (!page)
>> -return NULL;
>> -ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
>> -DMA_BIDIRECTIONAL);
>> -}
>> +if (!cached)
>> +pool = heap->uncached_pools[order_to_index(order)];
>> +else
>> +pool = heap->cached_pools[order_to_index(order)];
>>
>> +page = ion_page_pool_alloc(pool);
>> return page;
>> }
>>
>
> This is a change in behavior. The page is no longer guaranteed to be synced
> in the cache. If the page came from the pool (not just freshly allocated)
> the cache state is unknown. Do you have a good explanation why we no longer
> need to do the cache flush here on every allocation?
>
Yes, no more explanation here.
Please see my v1[1] version.
Thanks for review!
[1] http://thread.gmane.org/gmane.linux.kernel/2217505
> Thanks,
> Laura
>
> .
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] staging: dgnc: remove redundant NULL check in
2016-05-09 21:08 GMT+09:00 Greg KH : > On Wed, May 04, 2016 at 02:13:04PM +0900, Daeseok Youn wrote: >> tty and ch are already checked for NULL >> before calling dgnc_block_til_ready(). >> >> Signed-off-by: Daeseok Youn > > Your subject line doesn't make sense, please fix it up and resend. OK. I will resend this. thanks regards, Daeseok. > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] staging: dgnc: remove useless assigned error value in
2016-05-09 21:09 GMT+09:00 Greg KH : > On Wed, May 04, 2016 at 02:13:26PM +0900, Daeseok Youn wrote: >> the result in dgnc_get_mstat() was initialized with -EIO but >> there are no use of EIO as a result in this function. >> >> Signed-off-by: Daeseok Youn >> --- >> drivers/staging/dgnc/dgnc_tty.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) > > Same Subject: problem here too, it doesn't make sense. OK. I will resend this. thanks regards, Daeseok. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2 RESEND] staging: dgnc: remove redundant NULL checks in
The dgnc_block_til_ready() is only used in dgnc_tty_open().
The unit data(struct un_t) was stored into tty->driver_data in dgnc_tty_open().
And also tty and un were tested about NULL so these variables doesn't
need to check for NULL in dgnc_block_til_ready().
Signed-off-by: Daeseok Youn
---
RESEND: more explanation about this patch.
origin patch : https://lkml.org/lkml/2016/5/4/12
drivers/staging/dgnc/dgnc_tty.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index a505775..cff34d4 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -1172,17 +1172,12 @@ static int dgnc_block_til_ready(struct tty_struct *tty,
struct channel_t *ch)
{
int retval = 0;
- struct un_t *un = NULL;
+ struct un_t *un = tty->driver_data;
unsigned long flags;
uintold_flags = 0;
int sleep_on_un_flags = 0;
- if (!tty || tty->magic != TTY_MAGIC || !file || !ch ||
- ch->magic != DGNC_CHANNEL_MAGIC)
- return -ENXIO;
-
- un = tty->driver_data;
- if (!un || un->magic != DGNC_UNIT_MAGIC)
+ if (!file)
return -ENXIO;
spin_lock_irqsave(&ch->ch_lock, flags);
--
2.8.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2 RESEND] staging: dgnc: remove useless error value assignment
The "result" variable in dgnc_get_mstat() was initialized with
"-EIO". But if the "ch" is not null, "result" will be set to zero
and if the "ch" is null, dgnc_get_mstat() will return "-ENXIO" as
an error. So "-EIO" error value was useless in dgnc_get_mstat().
Signed-off-by: Daeseok Youn
---
RESEND: update subject and change log
origin patch : https://lkml.org/lkml/2016/5/4/13
drivers/staging/dgnc/dgnc_tty.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index cff34d4..30db091 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -1979,7 +1979,7 @@ static void dgnc_tty_send_xchar(struct tty_struct *tty,
char c)
static inline int dgnc_get_mstat(struct channel_t *ch)
{
unsigned char mstat;
- int result = -EIO;
+ int result = 0;
unsigned long flags;
if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
@@ -1991,8 +1991,6 @@ static inline int dgnc_get_mstat(struct channel_t *ch)
spin_unlock_irqrestore(&ch->ch_lock, flags);
- result = 0;
-
if (mstat & UART_MCR_DTR)
result |= TIOCM_DTR;
if (mstat & UART_MCR_RTS)
--
2.8.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
