kernel BUG at fs/erofs/inode.c:LINE!
Hello,
syzbot found the following issue on:
HEAD commit:d1d2220c Add linux-next specific files for 20200924
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=166cb7d990
kernel config: https://syzkaller.appspot.com/x/.config?x=254e028a642027c
dashboard link: https://syzkaller.appspot.com/bug?extid=8afc256dce324523609d
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=127762c390
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=124ccf3b90
The issue was bisected to:
commit 382329a9d8553a98418a6f6e3425f0c288837897
Author: Gao Xiang
Date: Wed Aug 14 10:37:04 2019 +
staging: erofs: differentiate unsupported on-disk format
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=149889e390
final oops: https://syzkaller.appspot.com/x/report.txt?x=169889e390
console output: https://syzkaller.appspot.com/x/log.txt?x=129889e390
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8afc256dce3245236...@syzkaller.appspotmail.com
Fixes: 382329a9d855 ("staging: erofs: differentiate unsupported on-disk format")
erofs: (device loop0): erofs_read_inode: bogus i_mode (0) @ nid 36
[ cut here ]
kernel BUG at fs/erofs/inode.c:182!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 6895 Comm: syz-executor894 Not tainted
5.9.0-rc6-next-20200924-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:erofs_read_inode fs/erofs/inode.c:182 [inline]
RIP: 0010:erofs_fill_inode fs/erofs/inode.c:235 [inline]
RIP: 0010:erofs_iget+0xfd8/0x2390 fs/erofs/inode.c:322
Code: 00 0f 85 aa 10 00 00 49 8b 7c 24 28 49 89 d8 44 89 e9 48 c7 c2 a0 9c ef
88 48 c7 c6 40 9f ef 88 e8 b5 df b0 04 e8 88 5a 07 fe <0f> 0b e8 81 5a 07 fe 4c
89 e7 4c 63 e3 e8 b6 61 5b fe e9 ed f0 ff
RSP: 0018:c90001017c10 EFLAGS: 00010293
RAX: RBX: 0024 RCX:
RDX: 8880a172e480 RSI: 836dd6e8 RDI: f52000202f72
RBP: 8880a8ca4480 R08: 0042 R09: 8880ae5319a7
R10: R11: R12: 8880854fd9b8
R13: R14: ea0002a32900 R15:
FS: 0108e880() GS:8880ae50() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0043eb80 CR3: a7edb000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
erofs_fc_fill_super+0xaa3/0x1010 fs/erofs/super.c:382
get_tree_bdev+0x421/0x740 fs/super.c:1342
vfs_get_tree+0x89/0x2f0 fs/super.c:1547
do_new_mount fs/namespace.c:2896 [inline]
path_mount+0x12ae/0x1e70 fs/namespace.c:3227
__do_sys_mount fs/namespace.c:3438 [inline]
__se_sys_mount fs/namespace.c:3411 [inline]
__x64_sys_mount+0x278/0x2f0 fs/namespace.c:3411
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446d6a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f
84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83
da ad fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:7fffa8ef9ef8 EFLAGS: 0297 ORIG_RAX: 00a5
RAX: ffda RBX: 7fffa8ef9f50 RCX: 00446d6a
RDX: 2000 RSI: 2100 RDI: 7fffa8ef9f10
RBP: 7fffa8ef9f10 R08: 7fffa8ef9f50 R09: 7fff0015
R10: R11: 0297 R12: 0001
R13: 0004 R14: 0003 R15: 0003
Modules linked in:
---[ end trace 66a5371a9bd8a3b2 ]---
RIP: 0010:erofs_read_inode fs/erofs/inode.c:182 [inline]
RIP: 0010:erofs_fill_inode fs/erofs/inode.c:235 [inline]
RIP: 0010:erofs_iget+0xfd8/0x2390 fs/erofs/inode.c:322
Code: 00 0f 85 aa 10 00 00 49 8b 7c 24 28 49 89 d8 44 89 e9 48 c7 c2 a0 9c ef
88 48 c7 c6 40 9f ef 88 e8 b5 df b0 04 e8 88 5a 07 fe <0f> 0b e8 81 5a 07 fe 4c
89 e7 4c 63 e3 e8 b6 61 5b fe e9 ed f0 ff
RSP: 0018:c90001017c10 EFLAGS: 00010293
RAX: RBX: 0024 RCX:
RDX: 8880a172e480 RSI: 836dd6e8 RDI: f52000202f72
RBP: 8880a8ca4480 R08: 0042 R09: 8880ae5319a7
R10: R11: R12: 8880854fd9b8
R13: R14: ea0002a32900 R15:
FS: 0108e880() GS:8880ae50() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0043eb80 CR3: a7edb000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot eng
Re: [PATCH] media: atomisp: Fixed error handling path
On Sun, Sep 27, 2020 at 08:38:04PM +0530, Souptick Joarder wrote:
> Inside alloc_user_pages() based on flag value either pin_user_pages()
> or get_user_pages_fast() will be called. However, these API might fail.
>
> But free_user_pages() called in error handling path doesn't bother
> about return value and will try to unpin bo->pgnr pages, which is
> incorrect.
>
> Fix this by passing the page_nr to free_user_pages(). If page_nr > 0
> pages will be unpinned based on bo->mem_type. This will also take care
> of non error handling path.
>
> Fixes: 14a638ab96c5 ("media: atomisp: use pin_user_pages() for memory
> allocation")
> Signed-off-by: Souptick Joarder
> Cc: John Hubbard
> Cc: Ira Weiny
> Cc: Dan Carpenter
> ---
> drivers/staging/media/atomisp/pci/hmm/hmm_bo.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> b/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> index f13af23..0168f98 100644
> --- a/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> +++ b/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> @@ -857,16 +857,17 @@ static void free_private_pages(struct hmm_buffer_object
> *bo,
> kfree(bo->page_obj);
> }
>
> -static void free_user_pages(struct hmm_buffer_object *bo)
> +static void free_user_pages(struct hmm_buffer_object *bo,
> + unsigned int page_nr)
> {
> int i;
>
> hmm_mem_stat.usr_size -= bo->pgnr;
^^^
This is still a problem. It needs to be hmm_mem_stat.usr_size -= page_nr.
regards,
dan carpenter
>
> if (bo->mem_type == HMM_BO_MEM_TYPE_PFN) {
> - unpin_user_pages(bo->pages, bo->pgnr);
> + unpin_user_pages(bo->pages, page_nr);
> } else {
> - for (i = 0; i < bo->pgnr; i++)
> + for (i = 0; i < page_nr; i++)
> put_page(bo->pages[i]);
> }
> kfree(bo->pages);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vchiq: Fix list_for_each exit tests
This code code here used to be list_for_each() and after the loop then
the "entry" pointer was non-NULL if we found the correct entry or NULL
if we couldn't find it. Then we changed the code to use list_for_each_entry()
and so now the "entry" pointer is always non-NULL when we exit the loop.
I have introduced a new "found" variable to say if we found the correct
enty or not. I fixed one test by making it an else statement because
that was more readable than testing "if (!found)".
Fixes: 46e4b9ec4fa4 ("staging: vchiq_arm: use list_for_each_entry when
accessing bulk_waiter_list")
Signed-off-by: Dan Carpenter
---
.../vc04_services/interface/vchiq_arm/vchiq_arm.c| 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index bb0cc9cb96e9..c25fc559cd36 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -430,6 +430,7 @@ vchiq_blocking_bulk_transfer(unsigned int handle, void
*data,
struct vchiq_service *service;
enum vchiq_status status;
struct bulk_waiter_node *waiter = NULL;
+ bool found = false;
service = find_service_by_handle(handle);
if (!service)
@@ -443,12 +444,13 @@ vchiq_blocking_bulk_transfer(unsigned int handle, void
*data,
list_for_each_entry(waiter, &instance->bulk_waiter_list, list) {
if (waiter->pid == current->pid) {
list_del(&waiter->list);
+ found = true;
break;
}
}
mutex_unlock(&instance->bulk_waiter_list_mutex);
- if (waiter) {
+ if (found) {
struct vchiq_bulk *bulk = waiter->bulk_waiter.bulk;
if (bulk) {
@@ -464,9 +466,7 @@ vchiq_blocking_bulk_transfer(unsigned int handle, void
*data,
spin_unlock(&bulk_waiter_spinlock);
}
}
- }
-
- if (!waiter) {
+ } else {
waiter = kzalloc(sizeof(struct bulk_waiter_node), GFP_KERNEL);
if (!waiter) {
vchiq_log_error(vchiq_core_log_level,
@@ -945,6 +945,7 @@ static int vchiq_irq_queue_bulk_tx_rx(struct vchiq_instance
*instance,
{
struct vchiq_service *service;
struct bulk_waiter_node *waiter = NULL;
+ bool found = false;
int status = 0;
int ret;
@@ -967,11 +968,12 @@ static int vchiq_irq_queue_bulk_tx_rx(struct
vchiq_instance *instance,
list) {
if (waiter->pid == current->pid) {
list_del(&waiter->list);
+ found = true;
break;
}
}
mutex_unlock(&instance->bulk_waiter_list_mutex);
- if (!waiter) {
+ if (!found) {
vchiq_log_error(vchiq_arm_log_level,
"no bulk_waiter found for pid %d",
current->pid);
--
2.28.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Initial driver submission for pureLiFi devices
> There's nothing in the "how to submit a driver/patch" documentation that > mentions that it has to go through staging first, does it? If so, that > needs to be changed... Thanks for the feedback Greg, Addressed your comments and resubmitted in /net/wireless Regards Srini ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Initial driver submission for pureLiFi devices
> It would be more common just to check for CONFIG_PURELIFI_AP in the source > file(s) instead of adding a synonym for it. Thanks for your comments Randy, Addressed your comments and resubmitted in /net/wireless Thanks Srini ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Initial driver submission for pureLiFi devices
> Anyway, those are some ideas. Thanks for your comments Dan, Addressed your comments and resubmitted in /net/wireless Thanks Srini ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: most: don't access hdm_ch before checking it valid
In try_start_dim_transfer(), pointer hdm_ch is accessed before checking.
This may lead to a potential null pointer dereference. Fix this by
dereferencing hdm_ch after calling BUG_ON().
Signed-off-by: Jing Xiangfeng
---
drivers/staging/most/dim2/dim2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/most/dim2/dim2.c b/drivers/staging/most/dim2/dim2.c
index 509c8012d20b..ccd7cc7545e4 100644
--- a/drivers/staging/most/dim2/dim2.c
+++ b/drivers/staging/most/dim2/dim2.c
@@ -148,7 +148,7 @@ void dimcb_on_error(u8 error_id, const char *error_message)
static int try_start_dim_transfer(struct hdm_channel *hdm_ch)
{
u16 buf_size;
- struct list_head *head = &hdm_ch->pending_list;
+ struct list_head *head;
struct mbo *mbo;
unsigned long flags;
struct dim_ch_state_t st;
@@ -156,6 +156,7 @@ static int try_start_dim_transfer(struct hdm_channel
*hdm_ch)
BUG_ON(!hdm_ch);
BUG_ON(!hdm_ch->is_initialized);
+ head = &hdm_ch->pending_list;
spin_lock_irqsave(&dim_lock, flags);
if (list_empty(head)) {
spin_unlock_irqrestore(&dim_lock, flags);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH] Add bridge driver to connect sensors to CIO2 device via software nodes on ACPI platforms
On 17/09/2020 11:33, Sakari Ailus wrote:
>> +sensor_props[3] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes",
>> + data_lanes,
>> +
>> (int)ssdb->lanes);
>> +sensor_props[4] = remote_endpoints[(bridge.n_sensors * 2) +
>> ENDPOINT_SENSOR];
>> +sensor_props[5] = PROPERTY_ENTRY_NULL;
>> +
>> +cio2_props[0] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes",
>> + data_lanes,
>> + (int)ssdb->lanes);
>> +cio2_props[1] = remote_endpoints[(bridge.n_sensors * 2) +
>> ENDPOINT_CIO2];
>> +cio2_props[2] = PROPERTY_ENTRY_NULL;
> I suppose the CSI-2 link frequency is generally encoded in drivers in this
> case. A lot of drivers already check for those, could you add the
> frequencies here as well (as they are known)?
This one caused me some consternation; I mentioned in a previous email
that I was overwriting the v4l2_subdev's fwnode directly because I
couldn't reprobe() the devices after changing their fwnode. Turns out
that's probably not ok, because as you point out there are some drivers
that check for properties in firmware as part of their .probe() call, so
they _have_ to be there for those to work (including ov5670, which is
the canonical ipu3 driver in the kernel docs). imx258 and ov13858 are
also affected, and I'm aware of at least one other driver in development
that would be affected.
The problem preventing the reprobe working is that i2c_device_match()
relies on a device's fwnode having acpi_device_fwnode_ops to perform
ACPI matching, so after giving the device our software nodes the
matching just fails. I thrashed out a way to make the reprobe work, but
I don't really like the solution so I wanted to talk about it. The long
story short is; clone the driver but add an i2c_device_id matching the
existing i2c_client's name, then use i2c_add_driver() to install it to
the bus before calling device_reprobe(). This does work; it makes the
devices reprobe cleanly at the end of cio2-bridge's init, but it feels a
little bit hacky. Any thoughts? Or if it makes it easier to discuss, I
can just post the v2 containing all the changes that people suggested
after the v1, and showing how this reprobe would work.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: most: don't access hdm_ch before checking it valid
On Mon, Sep 28, 2020 at 06:48:38PM +0800, Jing Xiangfeng wrote:
> In try_start_dim_transfer(), pointer hdm_ch is accessed before checking.
> This may lead to a potential null pointer dereference. Fix this by
> dereferencing hdm_ch after calling BUG_ON().
>
> Signed-off-by: Jing Xiangfeng
> ---
> drivers/staging/most/dim2/dim2.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/most/dim2/dim2.c
> b/drivers/staging/most/dim2/dim2.c
> index 509c8012d20b..ccd7cc7545e4 100644
> --- a/drivers/staging/most/dim2/dim2.c
> +++ b/drivers/staging/most/dim2/dim2.c
> @@ -148,7 +148,7 @@ void dimcb_on_error(u8 error_id, const char
> *error_message)
> static int try_start_dim_transfer(struct hdm_channel *hdm_ch)
> {
> u16 buf_size;
> - struct list_head *head = &hdm_ch->pending_list;
This is not a dereference, it's just pointer math. In other words:
struct list_head *head = hdm_ch + offsetof(struct hdm_channel,
pending_list);
So the commit message is wrong because this cannot lead to a NULL
dereference. It's better to just delete the BUG_ON(). We don't really
like BUG_ON(). Checkpatch will complain about them. An Oops gives
basically the same information as a BUG_ON() without completely killing
the kernel so just dereferencing a NULL is preferable. Finally, we can
see from the callers that "hdm_ch" is never NULL.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFT/RFC v2 00/47] staging: media: bring back zoran driver
Hi Corentin, On 25/09/2020 20:30, Corentin Labbe wrote: > Hello > > The zoran driver was removed in 5.3 > The main reason of the removing was lack of motivation to convert it to > VB2 > Since I need it, I worked on bringing it back. > > So the plan to achieve it was: > - clean up the coding style. > - convert old usage/API > - clean unused code > - convert to VB2 > > I have tried to split a bit the VB2 patch (by adding/removing code in > another patch), but the result is unfortunately still a big patch. > > The result of this serie is a working zoran driver. > Furthermore it is now compliant to v4l-compliance. > > In the process some old (useless) feature (fbuf, overlay) was removed > for simplifying maintenance. > > The zoran hardware support MJPEG decompression, but this feature is > temporarily disabled by this serie. > But basically, this feature was unusable, since the only tool which > permitted to use it was a mplayer option. > But this mplayer option no longer compile (probably since a long time) > and is such a hack (a copy of some private ffmpeg structure) that it is > unfixable. > Happily, when I started to work on zoran, a patch was posted on ffmpeg > ML which permit it to output non-raw video stream (and so MJPEG for > zoran case). > But the zoran hw does not like some part of JPEG header it receives, so > a filter need to be written. > Anyway, this disabling is not a regression, since this feature was not > usable since a long time. > > Since the driver was in staging, I targeted staging, but probably the > driver is in a sufficient good shape to target media and bypass staging. > > This driver is tested on a DC10+ (on x86). Tests on different hardware > are welcome. > > I would like to thanks all people that helped me to achieve this (mostly > #v4l) > > Regards > > PS: this serie is resent a bit soon since linux-media didnt get some patch > and cover letter Thank you very much for your hard work! I've just posted a PR for this driver since it is in good enough shape to resurrect in staging. This means that starting with 5.10 this driver will once again be available. There are some things that I would like to see fixed before moving it out of staging: 1) Check the driver with checkpatch --strict: I noticed various warnings that would be good to fix. Let's have this cleaned up before moving it out of staging. 2) I would like to see the output support fixed. 3) I want to test with my zoran hardware before moving it out of staging. That said, it will be a few months before I can do that since I don't have access to the HW at the moment. It depends on when I travel to the Netherlands, and with the COVID-19 situation I have no idea when that will be. I hope December, but there is no guarantee. Since 3) will take 1-2 kernel cycles anyway, that will hopefully allow for enough time to tackle 1 and 2 while it is still in staging. Regards, Hans > > Changes since RFC1 > - removed fallthough patch > - removed unsplit lines patch > - fixed line size in "Use DMA coherent for stat_com" patch > > Corentin Labbe (47): > staging: media: Revert "media: zoran: remove deprecated driver" > MAINTAINERS: change maintainer of the zoran driver > staging: media: zoran: datasheet is no longer available from zoran.com > staging: media: zoran: Documentation: fix typo > staging: media: zoran: fix checkpatch issue > staging: media: zoran: do not forward declare zr36057_init_vfe > staging: media: zoran: convert all error dprintk to pci_err/pr_err > staging: media: zoran: convert dprintk warn > staging: media: zoran: convert dprintk info to pci_info > staging: media: zoran: convert dprintk debug > staging: media: zoran: zoran_device.c: convert pr_x to pci_x > staging: media: zoran: remove proc_fs > staging: media: zoran: use VFL_TYPE_VIDEO > staging: media: zoran: use v4l2_buffer_set_timestamp > staging: media: zoran: do not print random guest 0 > staging: media: zoran: move buffer_size out of zoran_fh > staging: media: zoran: move v4l_settings out of zoran_fh > staging: media: zoran: move jpg_settings out of zoran_fh > staging: media: zoran: move overlay_settings out of zoran_fh > staging: media: zoran: Use video_drvdata to get struct zoran > staging: media: zoran: Change zoran_v4l_set_format parameter from > zoran_fh to zoran > staging: media: zoran: remove overlay > staging: media: zoran: Use DMA coherent for stat_com > staging: media: zoran: use ZR_NORM > staging: media: zoran: zoran does not support STD_ALL > staging: media: zoran: convert irq to pci irq > staging: media: zoran: convert zoran alloc to devm > staging: media: zoran: convert mdelay to udelay > staging: media: zoran: use devm for videocodec_master alloc > staging: media: zoran: use pci_request_regions > staging: media: zoran: use devm_ioremap > staging: media: zoran: add stat_com buffer > staging: media: zoran: constify struct tvnorm > staging: media: zor
Re: [PATCH RFT/RFC v2 00/47] staging: media: bring back zoran driver
Hi Hans, On Mon, Sep 28, 2020 at 03:45:03PM +0200, Hans Verkuil wrote: > On 25/09/2020 20:30, Corentin Labbe wrote: > > Hello > > > > The zoran driver was removed in 5.3 > > The main reason of the removing was lack of motivation to convert it to > > VB2 > > Since I need it, I worked on bringing it back. > > > > So the plan to achieve it was: > > - clean up the coding style. > > - convert old usage/API > > - clean unused code > > - convert to VB2 > > > > I have tried to split a bit the VB2 patch (by adding/removing code in > > another patch), but the result is unfortunately still a big patch. > > > > The result of this serie is a working zoran driver. > > Furthermore it is now compliant to v4l-compliance. > > > > In the process some old (useless) feature (fbuf, overlay) was removed > > for simplifying maintenance. > > > > The zoran hardware support MJPEG decompression, but this feature is > > temporarily disabled by this serie. > > But basically, this feature was unusable, since the only tool which > > permitted to use it was a mplayer option. > > But this mplayer option no longer compile (probably since a long time) > > and is such a hack (a copy of some private ffmpeg structure) that it is > > unfixable. > > Happily, when I started to work on zoran, a patch was posted on ffmpeg > > ML which permit it to output non-raw video stream (and so MJPEG for > > zoran case). > > But the zoran hw does not like some part of JPEG header it receives, so > > a filter need to be written. > > Anyway, this disabling is not a regression, since this feature was not > > usable since a long time. > > > > Since the driver was in staging, I targeted staging, but probably the > > driver is in a sufficient good shape to target media and bypass staging. > > > > This driver is tested on a DC10+ (on x86). Tests on different hardware > > are welcome. > > > > I would like to thanks all people that helped me to achieve this (mostly > > #v4l) > > > > Regards > > > > PS: this serie is resent a bit soon since linux-media didnt get some patch > > and cover letter > > Thank you very much for your hard work! > > I've just posted a PR for this driver since it is in good enough shape to > resurrect in staging. > > This means that starting with 5.10 this driver will once again be available. > > There are some things that I would like to see fixed before moving it out > of staging: > > 1) Check the driver with checkpatch --strict: I noticed various warnings > that would be good to fix. Let's have this cleaned up before moving it > out of staging. > > 2) I would like to see the output support fixed. As lots of time has elapsed since the very first driver for this card was merged, and the (Linux) world has changed quite a bit since then, would it make sense to expose this feature through DRM/KMS instead ? > 3) I want to test with my zoran hardware before moving it out of staging. > That said, it will be a few months before I can do that since I don't > have access to the HW at the moment. It depends on when I travel to the > Netherlands, and with the COVID-19 situation I have no idea when that > will be. I hope December, but there is no guarantee. > > Since 3) will take 1-2 kernel cycles anyway, that will hopefully allow > for enough time to tackle 1 and 2 while it is still in staging. > > > Changes since RFC1 > > - removed fallthough patch > > - removed unsplit lines patch > > - fixed line size in "Use DMA coherent for stat_com" patch > > > > Corentin Labbe (47): > > staging: media: Revert "media: zoran: remove deprecated driver" > > MAINTAINERS: change maintainer of the zoran driver > > staging: media: zoran: datasheet is no longer available from zoran.com > > staging: media: zoran: Documentation: fix typo > > staging: media: zoran: fix checkpatch issue > > staging: media: zoran: do not forward declare zr36057_init_vfe > > staging: media: zoran: convert all error dprintk to pci_err/pr_err > > staging: media: zoran: convert dprintk warn > > staging: media: zoran: convert dprintk info to pci_info > > staging: media: zoran: convert dprintk debug > > staging: media: zoran: zoran_device.c: convert pr_x to pci_x > > staging: media: zoran: remove proc_fs > > staging: media: zoran: use VFL_TYPE_VIDEO > > staging: media: zoran: use v4l2_buffer_set_timestamp > > staging: media: zoran: do not print random guest 0 > > staging: media: zoran: move buffer_size out of zoran_fh > > staging: media: zoran: move v4l_settings out of zoran_fh > > staging: media: zoran: move jpg_settings out of zoran_fh > > staging: media: zoran: move overlay_settings out of zoran_fh > > staging: media: zoran: Use video_drvdata to get struct zoran > > staging: media: zoran: Change zoran_v4l_set_format parameter from > > zoran_fh to zoran > > staging: media: zoran: remove overlay > > staging: media: zoran: Use DMA coherent for stat_com > > staging: media: zoran: use ZR_NORM > > staging: media: zoran: zoran does
Re: [PATCH RFT/RFC v2 00/47] staging: media: bring back zoran driver
On 28/09/2020 15:53, Laurent Pinchart wrote: > Hi Hans, > > On Mon, Sep 28, 2020 at 03:45:03PM +0200, Hans Verkuil wrote: >> On 25/09/2020 20:30, Corentin Labbe wrote: >>> Hello >>> >>> The zoran driver was removed in 5.3 >>> The main reason of the removing was lack of motivation to convert it to >>> VB2 >>> Since I need it, I worked on bringing it back. >>> >>> So the plan to achieve it was: >>> - clean up the coding style. >>> - convert old usage/API >>> - clean unused code >>> - convert to VB2 >>> >>> I have tried to split a bit the VB2 patch (by adding/removing code in >>> another patch), but the result is unfortunately still a big patch. >>> >>> The result of this serie is a working zoran driver. >>> Furthermore it is now compliant to v4l-compliance. >>> >>> In the process some old (useless) feature (fbuf, overlay) was removed >>> for simplifying maintenance. >>> >>> The zoran hardware support MJPEG decompression, but this feature is >>> temporarily disabled by this serie. >>> But basically, this feature was unusable, since the only tool which >>> permitted to use it was a mplayer option. >>> But this mplayer option no longer compile (probably since a long time) >>> and is such a hack (a copy of some private ffmpeg structure) that it is >>> unfixable. >>> Happily, when I started to work on zoran, a patch was posted on ffmpeg >>> ML which permit it to output non-raw video stream (and so MJPEG for >>> zoran case). >>> But the zoran hw does not like some part of JPEG header it receives, so >>> a filter need to be written. >>> Anyway, this disabling is not a regression, since this feature was not >>> usable since a long time. >>> >>> Since the driver was in staging, I targeted staging, but probably the >>> driver is in a sufficient good shape to target media and bypass staging. >>> >>> This driver is tested on a DC10+ (on x86). Tests on different hardware >>> are welcome. >>> >>> I would like to thanks all people that helped me to achieve this (mostly >>> #v4l) >>> >>> Regards >>> >>> PS: this serie is resent a bit soon since linux-media didnt get some patch >>> and cover letter >> >> Thank you very much for your hard work! >> >> I've just posted a PR for this driver since it is in good enough shape to >> resurrect in staging. >> >> This means that starting with 5.10 this driver will once again be available. >> >> There are some things that I would like to see fixed before moving it out >> of staging: >> >> 1) Check the driver with checkpatch --strict: I noticed various warnings >> that would be good to fix. Let's have this cleaned up before moving it >> out of staging. >> >> 2) I would like to see the output support fixed. > > As lots of time has elapsed since the very first driver for this card > was merged, and the (Linux) world has changed quite a bit since then, > would it make sense to expose this feature through DRM/KMS instead ? No, this is really a video output only, not something you would use as a desktop output. I'm sure you can probably shoehorn it into DRM/KMS, but it would not be a logical fit for this type of hardware. And besides, it makes no sense to put a lot of effort in that for such old hardware. Regards, Hans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Paul McCann
Good Day We are a registered Private Loan Investment Company in the United Kingdom, we also registered with the Turkish British Chamber of Commerce and Industry (TBCCI) we have operations in Europe and Asia. We are seeking for beneficiaries who source for fund to expand/relocating their business interest abroad. We are ready to fund projects outside Turkey and United Kingdom in the form of Soft Loan. We grant loans to both corporate and private entities at a low interest rate of 2% R.O.I per annul. We like to grant loan in the following sectors: oil/Gas, banking, real estate, stock speculation and mining, transportation, health sector and tobacco, Communication Services, Agriculture Forestry & Fishing, thus any sector. The terms are very flexible and interesting. Please contact us for more details; Kind regards, Paul McCann ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters
On Sun, Sep 27, 2020 at 07:35:26PM -0400, Joel Fernandes wrote: > On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: > > This patch series is a result of discussion at the refcount_t BOF > > the Linux Plumbers Conference. In this discussion, we identified > > a need for looking closely and investigating atomic_t usages in > > the kernel when it is used strictly as a counter without it > > controlling object lifetimes and state changes. > > > > There are a number of atomic_t usages in the kernel where atomic_t api > > is used strictly for counting and not for managing object lifetime. In > > some cases, atomic_t might not even be needed. > > > > The purpose of these counters is twofold: 1. clearly differentiate > > atomic_t counters from atomic_t usages that guard object lifetimes, > > hence prone to overflow and underflow errors. It allows tools that scan > > for underflow and overflow on atomic_t usages to detect overflow and > > underflows to scan just the cases that are prone to errors. 2. provides > > non-atomic counters for cases where atomic isn't necessary. > > Nice series :) > > It appears there is no user of counter_simple in this series other than the > selftest. Would you be planning to add any conversions in the series itself, > for illustration of use? Sorry if I missed a usage. > > Also how do we guard against atomicity of counter_simple RMW operations? Is > the implication that it should be guarded using other synchronization to > prevent lost-update problem? > > Some more comments: > > 1. atomic RMW operations that have a return value are fully ordered. Would > you be adding support to counter_simple for such ordering as well, for > consistency? No -- there is no atomicity guarantee for counter_simple. I would prefer counter_simple not exist at all, specifically for this reason. > 2. I felt counter_atomic and counter_atomic64 would be nice equivalents to >the atomic and atomic64 naming currently used (i.e. dropping the '32'). >However that is just my opinion and I am ok with either naming. I had asked that they be size-named to avoid any confusion (i.e. we're making a new API). -- Kees Cook ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: kernel BUG at fs/erofs/inode.c:LINE!
Hi,
On Mon, Sep 28, 2020 at 12:27:24AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:d1d2220c Add linux-next specific files for 20200924
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=166cb7d990
> kernel config: https://syzkaller.appspot.com/x/.config?x=254e028a642027c
> dashboard link: https://syzkaller.appspot.com/bug?extid=8afc256dce324523609d
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=127762c390
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=124ccf3b90
>
> The issue was bisected to:
>
> commit 382329a9d8553a98418a6f6e3425f0c288837897
> Author: Gao Xiang
> Date: Wed Aug 14 10:37:04 2019 +
>
> staging: erofs: differentiate unsupported on-disk format
if CONFIG_EROFS_DEBUG = y, the kernel will also BUG_ON on
currupted images in order to check potential mkfs fault.
So it's an expected behavior for now (if syzbot needs more
requirement, e.g. differ from runtime error vs corrupted error,
I can do it if needed.)
Thanks,
Gao Xiang
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=149889e390
> final oops: https://syzkaller.appspot.com/x/report.txt?x=169889e390
> console output: https://syzkaller.appspot.com/x/log.txt?x=129889e390
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+8afc256dce3245236...@syzkaller.appspotmail.com
> Fixes: 382329a9d855 ("staging: erofs: differentiate unsupported on-disk
> format")
>
> erofs: (device loop0): erofs_read_inode: bogus i_mode (0) @ nid 36
> [ cut here ]
> kernel BUG at fs/erofs/inode.c:182!
> invalid opcode: [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 6895 Comm: syz-executor894 Not tainted
> 5.9.0-rc6-next-20200924-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:erofs_read_inode fs/erofs/inode.c:182 [inline]
> RIP: 0010:erofs_fill_inode fs/erofs/inode.c:235 [inline]
> RIP: 0010:erofs_iget+0xfd8/0x2390 fs/erofs/inode.c:322
> Code: 00 0f 85 aa 10 00 00 49 8b 7c 24 28 49 89 d8 44 89 e9 48 c7 c2 a0 9c ef
> 88 48 c7 c6 40 9f ef 88 e8 b5 df b0 04 e8 88 5a 07 fe <0f> 0b e8 81 5a 07 fe
> 4c 89 e7 4c 63 e3 e8 b6 61 5b fe e9 ed f0 ff
> RSP: 0018:c90001017c10 EFLAGS: 00010293
> RAX: RBX: 0024 RCX:
> RDX: 8880a172e480 RSI: 836dd6e8 RDI: f52000202f72
> RBP: 8880a8ca4480 R08: 0042 R09: 8880ae5319a7
> R10: R11: R12: 8880854fd9b8
> R13: R14: ea0002a32900 R15:
> FS: 0108e880() GS:8880ae50() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 0043eb80 CR3: a7edb000 CR4: 001506e0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> Call Trace:
> erofs_fc_fill_super+0xaa3/0x1010 fs/erofs/super.c:382
> get_tree_bdev+0x421/0x740 fs/super.c:1342
> vfs_get_tree+0x89/0x2f0 fs/super.c:1547
> do_new_mount fs/namespace.c:2896 [inline]
> path_mount+0x12ae/0x1e70 fs/namespace.c:3227
> __do_sys_mount fs/namespace.c:3438 [inline]
> __se_sys_mount fs/namespace.c:3411 [inline]
> __x64_sys_mount+0x278/0x2f0 fs/namespace.c:3411
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x446d6a
> Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f
> 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f
> 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00
> RSP: 002b:7fffa8ef9ef8 EFLAGS: 0297 ORIG_RAX: 00a5
> RAX: ffda RBX: 7fffa8ef9f50 RCX: 00446d6a
> RDX: 2000 RSI: 2100 RDI: 7fffa8ef9f10
> RBP: 7fffa8ef9f10 R08: 7fffa8ef9f50 R09: 7fff0015
> R10: R11: 0297 R12: 0001
> R13: 0004 R14: 0003 R15: 0003
> Modules linked in:
> ---[ end trace 66a5371a9bd8a3b2 ]---
> RIP: 0010:erofs_read_inode fs/erofs/inode.c:182 [inline]
> RIP: 0010:erofs_fill_inode fs/erofs/inode.c:235 [inline]
> RIP: 0010:erofs_iget+0xfd8/0x2390 fs/erofs/inode.c:322
> Code: 00 0f 85 aa 10 00 00 49 8b 7c 24 28 49 89 d8 44 89 e9 48 c7 c2 a0 9c ef
> 88 48 c7 c6 40 9f ef 88 e8 b5 df b0 04 e8 88 5a 07 fe <0f> 0b e8 81 5a 07 fe
> 4c 89 e7 4c 63 e3 e8 b6 61 5b fe e9 ed f0 ff
> RSP: 0018:c90001017c10 EFLAGS: 00010293
> RAX: RBX: 0024 RCX:
> RDX: 8880a172e480 RSI: 836dd6e8 RDI: f52000202f72
> RBP: 8880a8ca4480 R08: 0042 R09: 8880ae5319a7
> R10: R11: R12: 8880854fd9b8
> R13: 000
Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters
On Mon, Sep 28, 2020 at 01:34:31PM -0700, Kees Cook wrote: > On Sun, Sep 27, 2020 at 07:35:26PM -0400, Joel Fernandes wrote: > > On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: > > > This patch series is a result of discussion at the refcount_t BOF > > > the Linux Plumbers Conference. In this discussion, we identified > > > a need for looking closely and investigating atomic_t usages in > > > the kernel when it is used strictly as a counter without it > > > controlling object lifetimes and state changes. > > > > > > There are a number of atomic_t usages in the kernel where atomic_t api > > > is used strictly for counting and not for managing object lifetime. In > > > some cases, atomic_t might not even be needed. > > > > > > The purpose of these counters is twofold: 1. clearly differentiate > > > atomic_t counters from atomic_t usages that guard object lifetimes, > > > hence prone to overflow and underflow errors. It allows tools that scan > > > for underflow and overflow on atomic_t usages to detect overflow and > > > underflows to scan just the cases that are prone to errors. 2. provides > > > non-atomic counters for cases where atomic isn't necessary. > > > > Nice series :) > > > > It appears there is no user of counter_simple in this series other than the > > selftest. Would you be planning to add any conversions in the series itself, > > for illustration of use? Sorry if I missed a usage. > > > > Also how do we guard against atomicity of counter_simple RMW operations? Is > > the implication that it should be guarded using other synchronization to > > prevent lost-update problem? > > > > Some more comments: > > > > 1. atomic RMW operations that have a return value are fully ordered. Would > > you be adding support to counter_simple for such ordering as well, for > > consistency? > > No -- there is no atomicity guarantee for counter_simple. I would prefer > counter_simple not exist at all, specifically for this reason. Yeah I am ok with it not existing, especially also as there are no examples of its conversion/usage in the series. > > 2. I felt counter_atomic and counter_atomic64 would be nice equivalents to > >the atomic and atomic64 naming currently used (i.e. dropping the '32'). > >However that is just my opinion and I am ok with either naming. > > I had asked that they be size-named to avoid any confusion (i.e. we're > making a new API). Works for me. Cheers, - Joel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters
On 9/26/20 10:29 AM, Kees Cook wrote: On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: 7. Verified that the test module compiles in kunit env. and test module can be loaded to run the test. I meant write it using KUnit interfaces (e.g. KUNIT_EXPECT*(), kunit_test_suite(), etc): https://www.kernel.org/doc/html/latest/dev-tools/kunit/ Though I see the docs are still not updated[1] to reflect the Kconfig (CONFIG_foo_KUNIT_TEST) and file naming conventions (foo_kunit.c). I would like to be able to run this test outside Kunit env., hence the choice to go with a module and kselftest script. It makes it easier to test as part of my workflow as opposed to doing a kunit and build and running it that way. I don't mind adding TEST_COUNTERS to kunit default configs though. thanks, -- Shuah ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters
On 9/26/20 10:22 AM, Kees Cook wrote: On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: This patch series is a result of discussion at the refcount_t BOF the Linux Plumbers Conference. In this discussion, we identified a need for looking closely and investigating atomic_t usages in the kernel when it is used strictly as a counter without it controlling object lifetimes and state changes. BTW, I realized the KSPP issue tracker hadn't broken this task out of the refcount_t conversion issue[1] into a separate issue, so I've created it now: https://github.com/KSPP/linux/issues/106 Cool. Thanks. -- Shuah ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters
On 9/26/20 10:33 AM, Kees Cook wrote: On Fri, Sep 25, 2020 at 06:13:37PM -0600, Shuah Khan wrote: On 9/25/20 5:52 PM, Kees Cook wrote: On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: -- Addressed Kees's comments: 1. Non-atomic counters renamed to counter_simple32 and counter_simple64 to clearly indicate size. 2. Added warning for counter_simple* usage and it should be used only when there is no need for atomicity. 3. Renamed counter_atomic to counter_atomic32 to clearly indicate size. 4. Renamed counter_atomic_long to counter_atomic64 and it now uses atomic64_t ops and indicates size. 5. Test updated for the API renames. 6. Added helper functions for test results printing 7. Verified that the test module compiles in kunit env. and test module can be loaded to run the test. Thanks for all of this! 8. Updated Documentation to reflect the intent to make the API restricted so it can never be used to guard object lifetimes and state management. I left _return ops for now, inc_return is necessary for now as per the discussion we had on this topic. I still *really* do not want dec_return() to exist. That is asking for trouble. I'd prefer inc_return() not exist either, but I can live with it. ;) I didn't read this correctly the first time around. Thanks. I am equally concerned about adding anything that can be used to guard object lifetimes. So I will make sure this set won't expand and plan to remove dec_return() if we don't find any usages. I would like it much stronger than "if". dec_return() needs to be just dec() and read(). It will not be less efficient (since they're both inlines), but it _will_ create a case where the atomicity cannot be used for ref counting. My point is that anything that _requires_ dec_return() (or, frankly, inc_return()) is _not_ "just" a statistical counter. It may not be a refcounter, but it relies on the inc/dec atomicity for some reason beyond counting in once place and reporting it in another. I am not thinking about efficiency rather two calls instead of one if an decrement needs to followed by return. In any case, I agree with you that there is no need to add dec_return now without any use-cases. I will update the patch series to remove it. thanks, -- Shuah ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters
On 9/28/20 3:17 PM, Joel Fernandes wrote: On Mon, Sep 28, 2020 at 01:34:31PM -0700, Kees Cook wrote: On Sun, Sep 27, 2020 at 07:35:26PM -0400, Joel Fernandes wrote: On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: This patch series is a result of discussion at the refcount_t BOF the Linux Plumbers Conference. In this discussion, we identified a need for looking closely and investigating atomic_t usages in the kernel when it is used strictly as a counter without it controlling object lifetimes and state changes. There are a number of atomic_t usages in the kernel where atomic_t api is used strictly for counting and not for managing object lifetime. In some cases, atomic_t might not even be needed. The purpose of these counters is twofold: 1. clearly differentiate atomic_t counters from atomic_t usages that guard object lifetimes, hence prone to overflow and underflow errors. It allows tools that scan for underflow and overflow on atomic_t usages to detect overflow and underflows to scan just the cases that are prone to errors. 2. provides non-atomic counters for cases where atomic isn't necessary. Nice series :) Thanks. It appears there is no user of counter_simple in this series other than the selftest. Would you be planning to add any conversions in the series itself, for illustration of use? Sorry if I missed a usage. Also how do we guard against atomicity of counter_simple RMW operations? Is the implication that it should be guarded using other synchronization to prevent lost-update problem? Some more comments: 1. atomic RMW operations that have a return value are fully ordered. Would you be adding support to counter_simple for such ordering as well, for consistency? No -- there is no atomicity guarantee for counter_simple. I would prefer counter_simple not exist at all, specifically for this reason. Yeah I am ok with it not existing, especially also as there are no examples of its conversion/usage in the series. No. counter_simple is just for counting when there is no need for atomicity with the premise that there might be some use-cases. You are right that this patch series doesn't use these. My hunch is though that atomic_t is overused and it isn't needed in all cases. I will do some research to look for any places that can use counter_simple before I spin v2. If I don't find any, I can drop them. thanks, -- Shuah ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters
On Mon, Sep 28, 2020 at 04:41:47PM -0600, Shuah Khan wrote: > On 9/26/20 10:29 AM, Kees Cook wrote: > > On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: > > > 7. Verified that the test module compiles in kunit env. and test > > >module can be loaded to run the test. > > > > I meant write it using KUnit interfaces (e.g. KUNIT_EXPECT*(), > > kunit_test_suite(), etc): > > https://www.kernel.org/doc/html/latest/dev-tools/kunit/ > > > > Though I see the docs are still not updated[1] to reflect the Kconfig > > (CONFIG_foo_KUNIT_TEST) and file naming conventions (foo_kunit.c). > > > > I would like to be able to run this test outside Kunit env., hence the > choice to go with a module and kselftest script. It makes it easier to > test as part of my workflow as opposed to doing a kunit and build and > running it that way. It does -- you just load it normally like before and it prints out everything just fine. This is how I use the lib/test_user_copy.c and lib/test_overflow.c before/after their conversions. -- Kees Cook ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: most: don't access hdm_ch before checking it valid
On 2020/9/28 19:48, Dan Carpenter wrote:
On Mon, Sep 28, 2020 at 06:48:38PM +0800, Jing Xiangfeng wrote:
In try_start_dim_transfer(), pointer hdm_ch is accessed before checking.
This may lead to a potential null pointer dereference. Fix this by
dereferencing hdm_ch after calling BUG_ON().
Signed-off-by: Jing Xiangfeng
---
drivers/staging/most/dim2/dim2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/most/dim2/dim2.c b/drivers/staging/most/dim2/dim2.c
index 509c8012d20b..ccd7cc7545e4 100644
--- a/drivers/staging/most/dim2/dim2.c
+++ b/drivers/staging/most/dim2/dim2.c
@@ -148,7 +148,7 @@ void dimcb_on_error(u8 error_id, const char *error_message)
static int try_start_dim_transfer(struct hdm_channel *hdm_ch)
{
u16 buf_size;
- struct list_head *head = &hdm_ch->pending_list;
This is not a dereference, it's just pointer math. In other words:
struct list_head *head = hdm_ch + offsetof(struct hdm_channel,
pending_list);
Thanks for correcting!
So the commit message is wrong because this cannot lead to a NULL
dereference. It's better to just delete the BUG_ON(). We don't really
like BUG_ON(). Checkpatch will complain about them. An Oops gives
basically the same information as a BUG_ON() without completely killing
the kernel so just dereferencing a NULL is preferable. Finally, we can
see from the callers that "hdm_ch" is never NULL.
regards,
dan carpenter
.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 -next] binder: simplify the return expression of binder_mmap
Simplify the return expression.
Signed-off-by: Liu Shixin
---
v3: Add the change description.
v2: Get rid of the "ret" and "failure string" variables.
v1: Simplify the return expression.
---
drivers/android/binder.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 37a505c41dec..49c0700816a5 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -5180,9 +5180,7 @@ static const struct vm_operations_struct binder_vm_ops = {
static int binder_mmap(struct file *filp, struct vm_area_struct *vma)
{
- int ret;
struct binder_proc *proc = filp->private_data;
- const char *failure_string;
if (proc->tsk != current->group_leader)
return -EINVAL;
@@ -5194,9 +5192,9 @@ static int binder_mmap(struct file *filp, struct
vm_area_struct *vma)
(unsigned long)pgprot_val(vma->vm_page_prot));
if (vma->vm_flags & FORBIDDEN_MMAP_FLAGS) {
- ret = -EPERM;
- failure_string = "bad vm_flags";
- goto err_bad_arg;
+ pr_err("%s: %d %lx-%lx %s failed %d\n", __func__,
+ proc->pid, vma->vm_start, vma->vm_end, "bad vm_flags",
-EPERM);
+ return -EPERM;
}
vma->vm_flags |= VM_DONTCOPY | VM_MIXEDMAP;
vma->vm_flags &= ~VM_MAYWRITE;
@@ -5204,15 +5202,7 @@ static int binder_mmap(struct file *filp, struct
vm_area_struct *vma)
vma->vm_ops = &binder_vm_ops;
vma->vm_private_data = proc;
- ret = binder_alloc_mmap_handler(&proc->alloc, vma);
- if (ret)
- return ret;
- return 0;
-
-err_bad_arg:
- pr_err("%s: %d %lx-%lx %s failed %d\n", __func__,
- proc->pid, vma->vm_start, vma->vm_end, failure_string, ret);
- return ret;
+ return binder_alloc_mmap_handler(&proc->alloc, vma);
}
static int binder_open(struct inode *nodp, struct file *filp)
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: kernel BUG at fs/erofs/inode.c:LINE!
Hi syzbot administrator,
CONFIG_EROFS_DEBUG was introduced for debug purpose during
development, this should not be enabled on release version.
Can you please turn off this config, and retest with erofs module?
Thanks,
On 2020/9/29 4:36, Gao Xiang wrote:
Hi,
On Mon, Sep 28, 2020 at 12:27:24AM -0700, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:d1d2220c Add linux-next specific files for 20200924
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=166cb7d990
kernel config: https://syzkaller.appspot.com/x/.config?x=254e028a642027c
dashboard link: https://syzkaller.appspot.com/bug?extid=8afc256dce324523609d
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=127762c390
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=124ccf3b90
The issue was bisected to:
commit 382329a9d8553a98418a6f6e3425f0c288837897
Author: Gao Xiang
Date: Wed Aug 14 10:37:04 2019 +
staging: erofs: differentiate unsupported on-disk format
if CONFIG_EROFS_DEBUG=y, the kernel will also BUG_ON on
currupted images in order to check potential mkfs fault.
So it's an expected behavior for now (if syzbot needs some more requirement,
e.g. differ from runtime error vs corrupted image error, I can do it if
needed.)
Thanks,
Gao Xiang
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=149889e390
final oops: https://syzkaller.appspot.com/x/report.txt?x=169889e390
console output: https://syzkaller.appspot.com/x/log.txt?x=129889e390
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8afc256dce3245236...@syzkaller.appspotmail.com
Fixes: 382329a9d855 ("staging: erofs: differentiate unsupported on-disk format")
erofs: (device loop0): erofs_read_inode: bogus i_mode (0) @ nid 36
[ cut here ]
kernel BUG at fs/erofs/inode.c:182!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 6895 Comm: syz-executor894 Not tainted
5.9.0-rc6-next-20200924-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:erofs_read_inode fs/erofs/inode.c:182 [inline]
RIP: 0010:erofs_fill_inode fs/erofs/inode.c:235 [inline]
RIP: 0010:erofs_iget+0xfd8/0x2390 fs/erofs/inode.c:322
Code: 00 0f 85 aa 10 00 00 49 8b 7c 24 28 49 89 d8 44 89 e9 48 c7 c2 a0 9c ef 88 48
c7 c6 40 9f ef 88 e8 b5 df b0 04 e8 88 5a 07 fe <0f> 0b e8 81 5a 07 fe 4c 89 e7
4c 63 e3 e8 b6 61 5b fe e9 ed f0 ff
RSP: 0018:c90001017c10 EFLAGS: 00010293
RAX: RBX: 0024 RCX:
RDX: 8880a172e480 RSI: 836dd6e8 RDI: f52000202f72
RBP: 8880a8ca4480 R08: 0042 R09: 8880ae5319a7
R10: R11: R12: 8880854fd9b8
R13: R14: ea0002a32900 R15:
FS: 0108e880() GS:8880ae50() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0043eb80 CR3: a7edb000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
erofs_fc_fill_super+0xaa3/0x1010 fs/erofs/super.c:382
get_tree_bdev+0x421/0x740 fs/super.c:1342
vfs_get_tree+0x89/0x2f0 fs/super.c:1547
do_new_mount fs/namespace.c:2896 [inline]
path_mount+0x12ae/0x1e70 fs/namespace.c:3227
__do_sys_mount fs/namespace.c:3438 [inline]
__se_sys_mount fs/namespace.c:3411 [inline]
__x64_sys_mount+0x278/0x2f0 fs/namespace.c:3411
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446d6a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00
00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad
fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:7fffa8ef9ef8 EFLAGS: 0297 ORIG_RAX: 00a5
RAX: ffda RBX: 7fffa8ef9f50 RCX: 00446d6a
RDX: 2000 RSI: 2100 RDI: 7fffa8ef9f10
RBP: 7fffa8ef9f10 R08: 7fffa8ef9f50 R09: 7fff0015
R10: R11: 0297 R12: 0001
R13: 0004 R14: 0003 R15: 0003
Modules linked in:
---[ end trace 66a5371a9bd8a3b2 ]---
RIP: 0010:erofs_read_inode fs/erofs/inode.c:182 [inline]
RIP: 0010:erofs_fill_inode fs/erofs/inode.c:235 [inline]
RIP: 0010:erofs_iget+0xfd8/0x2390 fs/erofs/inode.c:322
Code: 00 0f 85 aa 10 00 00 49 8b 7c 24 28 49 89 d8 44 89 e9 48 c7 c2 a0 9c ef 88 48
c7 c6 40 9f ef 88 e8 b5 df b0 04 e8 88 5a 07 fe <0f> 0b e8 81 5a 07 fe 4c 89 e7
4c 63 e3 e8 b6 61 5b fe e9 ed f0 ff
RSP: 0018:c90001017c10 EFLAGS: 00010293
RAX: RBX: 0024 RCX:
RDX: 8880a172e480 RSI: 836dd6e8 RDI: f52000202f72
RBP: 8880a8ca4480 R08: 00
Re: [PATCH] media: atomisp: Fixed error handling path
Hi Dan,
On Mon, Sep 28, 2020 at 2:08 PM Dan Carpenter wrote:
>
> On Sun, Sep 27, 2020 at 08:38:04PM +0530, Souptick Joarder wrote:
> > Inside alloc_user_pages() based on flag value either pin_user_pages()
> > or get_user_pages_fast() will be called. However, these API might fail.
> >
> > But free_user_pages() called in error handling path doesn't bother
> > about return value and will try to unpin bo->pgnr pages, which is
> > incorrect.
> >
> > Fix this by passing the page_nr to free_user_pages(). If page_nr > 0
> > pages will be unpinned based on bo->mem_type. This will also take care
> > of non error handling path.
> >
> > Fixes: 14a638ab96c5 ("media: atomisp: use pin_user_pages() for memory
> > allocation")
> > Signed-off-by: Souptick Joarder
> > Cc: John Hubbard
> > Cc: Ira Weiny
> > Cc: Dan Carpenter
> > ---
> > drivers/staging/media/atomisp/pci/hmm/hmm_bo.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> > b/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> > index f13af23..0168f98 100644
> > --- a/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> > +++ b/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> > @@ -857,16 +857,17 @@ static void free_private_pages(struct
> > hmm_buffer_object *bo,
> > kfree(bo->page_obj);
> > }
> >
> > -static void free_user_pages(struct hmm_buffer_object *bo)
> > +static void free_user_pages(struct hmm_buffer_object *bo,
> > + unsigned int page_nr)
> > {
> > int i;
> >
> > hmm_mem_stat.usr_size -= bo->pgnr;
> ^^^
> This is still a problem. It needs to be hmm_mem_stat.usr_size -= page_nr.
In failure path, it is hmm_mem_stat.usr_size += bo->pgnr.
I think, hmm_mem_stat.usr_size -= bo->pgnr is correct as per existing code.
Do you think that needs to be changed ?
>
> regards,
> dan carpenter
>
> >
> > if (bo->mem_type == HMM_BO_MEM_TYPE_PFN) {
> > - unpin_user_pages(bo->pages, bo->pgnr);
> > + unpin_user_pages(bo->pages, page_nr);
> > } else {
> > - for (i = 0; i < bo->pgnr; i++)
> > + for (i = 0; i < page_nr; i++)
> > put_page(bo->pages[i]);
> > }
> > kfree(bo->pages);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: atomisp: Fixed error handling path
On Tue, Sep 29, 2020 at 07:34:39AM +0530, Souptick Joarder wrote:
> Hi Dan,
>
>
> On Mon, Sep 28, 2020 at 2:08 PM Dan Carpenter
> wrote:
> >
> > On Sun, Sep 27, 2020 at 08:38:04PM +0530, Souptick Joarder wrote:
> > > Inside alloc_user_pages() based on flag value either pin_user_pages()
> > > or get_user_pages_fast() will be called. However, these API might fail.
> > >
> > > But free_user_pages() called in error handling path doesn't bother
> > > about return value and will try to unpin bo->pgnr pages, which is
> > > incorrect.
> > >
> > > Fix this by passing the page_nr to free_user_pages(). If page_nr > 0
> > > pages will be unpinned based on bo->mem_type. This will also take care
> > > of non error handling path.
> > >
> > > Fixes: 14a638ab96c5 ("media: atomisp: use pin_user_pages() for memory
> > > allocation")
> > > Signed-off-by: Souptick Joarder
> > > Cc: John Hubbard
> > > Cc: Ira Weiny
> > > Cc: Dan Carpenter
> > > ---
> > > drivers/staging/media/atomisp/pci/hmm/hmm_bo.c | 13 -
> > > 1 file changed, 8 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> > > b/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> > > index f13af23..0168f98 100644
> > > --- a/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> > > +++ b/drivers/staging/media/atomisp/pci/hmm/hmm_bo.c
> > > @@ -857,16 +857,17 @@ static void free_private_pages(struct
> > > hmm_buffer_object *bo,
> > > kfree(bo->page_obj);
> > > }
> > >
> > > -static void free_user_pages(struct hmm_buffer_object *bo)
> > > +static void free_user_pages(struct hmm_buffer_object *bo,
> > > + unsigned int page_nr)
> > > {
> > > int i;
> > >
> > > hmm_mem_stat.usr_size -= bo->pgnr;
> > ^^^
> > This is still a problem. It needs to be hmm_mem_stat.usr_size -= page_nr.
>
> In failure path, it is hmm_mem_stat.usr_size += bo->pgnr.
> I think, hmm_mem_stat.usr_size -= bo->pgnr is correct as per existing code.
> Do you think that needs to be changed ?
>
Yeah. Crud. I'm sorry. You had it right.
Reviewed-by: Dan Carpenter
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 8/8] staging: rtl8188eu: clean up indent style issue
Replace spaces with tab to clear checkpatch error. ERROR: code indent should use tabs where possible Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c b/drivers/staging/rtl8188eu/core/rtw_mlme.c index 668a24f25fce..14be5a703615 100644 --- a/drivers/staging/rtl8188eu/core/rtw_mlme.c +++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c @@ -1730,7 +1730,7 @@ int rtw_restruct_sec_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie, uint in_ (ndisauthmode == Ndis802_11AuthModeWPAPSK)) authmode = _WPA_IE_ID_; else if ((ndisauthmode == Ndis802_11AuthModeWPA2) || -(ndisauthmode == Ndis802_11AuthModeWPA2PSK)) +(ndisauthmode == Ndis802_11AuthModeWPA2PSK)) authmode = _WPA2_IE_ID_; else authmode = 0x0; -- 2.28.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/8] staging: rtl8188eu: use ETH_ALEN
Use ETH_ALEN instead of hard coded array size.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/include/rtw_security.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/include/rtw_security.h
b/drivers/staging/rtl8188eu/include/rtw_security.h
index bfa080d6a1a9..737f1da81f6b 100644
--- a/drivers/staging/rtl8188eu/include/rtw_security.h
+++ b/drivers/staging/rtl8188eu/include/rtw_security.h
@@ -82,7 +82,7 @@ union Keytype {
struct rt_pmkid_list {
u8 bUsed;
- u8 bssid[6];
+ u8 bssid[ETH_ALEN];
u8 PMKID[16];
u8 SsidBuf[33];
u8 *ssid_octet;
--
2.28.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/8] staging: rtl8188eu: clean up comparsions to NULL
Clean up remaining comparsions to NULL reported by checkpatch.
x == NULL -> !x
x != NULL -> x
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_security.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index b7a8c199de54..46ba55a8952a 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -142,7 +142,7 @@ void rtw_wep_encrypt(struct adapter *padapter, struct
xmit_frame *pxmitframe)
struct sk_buff *skb;
struct lib80211_crypto_ops *crypto_ops;
- if (pxmitframe->buf_addr == NULL)
+ if (!pxmitframe->buf_addr)
return;
if ((pattrib->encrypt != _WEP40_) && (pattrib->encrypt != _WEP104_))
@@ -589,7 +589,7 @@ u32 rtw_tkip_encrypt(struct adapter *padapter, struct
xmit_frame *pxmitframe)
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
u32 res = _SUCCESS;
- if (pxmitframe->buf_addr == NULL)
+ if (!pxmitframe->buf_addr)
return _FAIL;
hw_hdr_offset = TXDESC_SIZE +
@@ -602,7 +602,7 @@ u32 rtw_tkip_encrypt(struct adapter *padapter, struct
xmit_frame *pxmitframe)
else
stainfo = rtw_get_stainfo(&padapter->stapriv,
&pattrib->ra[0]);
- if (stainfo != NULL) {
+ if (stainfo) {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
stainfo!= NULL!!!\n", __func__));
if (is_multicast_ether_addr(pattrib->ra))
@@ -834,7 +834,7 @@ u32 rtw_aes_decrypt(struct adapter *padapter, struct
recv_frame *precvframe)
if (prxattrib->encrypt == _AES_) {
struct sta_info *stainfo = rtw_get_stainfo(&padapter->stapriv,
&prxattrib->ta[0]);
- if (stainfo != NULL) {
+ if (stainfo) {
int key_idx;
const int key_length = 16, iv_len = 8, icv_len = 8;
struct sk_buff *skb = precvframe->pkt;
--
2.28.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/8] staging: rtl8188eu: remove unused macros and definitions
Removep unused macros and definitions from rtw_security.h leftover
from previous cleanup patches.
Signed-off-by: Michael Straube
---
.../staging/rtl8188eu/include/rtw_security.h | 58 ---
1 file changed, 58 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/rtw_security.h
b/drivers/staging/rtl8188eu/include/rtw_security.h
index 8ba02a7cea60..5f418003647b 100644
--- a/drivers/staging/rtl8188eu/include/rtw_security.h
+++ b/drivers/staging/rtl8188eu/include/rtw_security.h
@@ -228,64 +228,6 @@ struct mic_data {
u32 nBytesInM; /* # bytes in M */
};
-extern const u32 Te0[256];
-extern const u32 Td0[256];
-extern const u32 Td1[256];
-extern const u32 Td2[256];
-extern const u32 Td3[256];
-extern const u32 Td4[256];
-extern const u32 rcon[10];
-extern const u8 Td4s[256];
-extern const u8 rcons[10];
-
-#define RCON(i) (rcons[(i)] << 24)
-
-static inline u32 rotr(u32 val, int bits)
-{
- return (val >> bits) | (val << (32 - bits));
-}
-
-#define TE0(i) Te0[((i) >> 24) & 0xff]
-#define TE1(i) rotr(Te0[((i) >> 16) & 0xff], 8)
-#define TE2(i) rotr(Te0[((i) >> 8) & 0xff], 16)
-#define TE3(i) rotr(Te0[(i) & 0xff], 24)
-
-/* = start - public domain SHA256 implementation = */
-
-/* This is based on SHA256 implementation in LibTomCrypt that was released into
- * public domain by Tom St Denis.
- */
-
-/* the K array */
-static const unsigned long K[64] = {
- 0x428a2f98UL, 0x71374491UL, 0xb5c0fbcfUL, 0xe9b5dba5UL, 0x3956c25bUL,
- 0x59f111f1UL, 0x923f82a4UL, 0xab1c5ed5UL, 0xd807aa98UL, 0x12835b01UL,
- 0x243185beUL, 0x550c7dc3UL, 0x72be5d74UL, 0x80deb1feUL, 0x9bdc06a7UL,
- 0xc19bf174UL, 0xe49b69c1UL, 0xefbe4786UL, 0x0fc19dc6UL, 0x240ca1ccUL,
- 0x2de92c6fUL, 0x4a7484aaUL, 0x5cb0a9dcUL, 0x76f988daUL, 0x983e5152UL,
- 0xa831c66dUL, 0xb00327c8UL, 0xbf597fc7UL, 0xc6e00bf3UL, 0xd5a79147UL,
- 0x06ca6351UL, 0x14292967UL, 0x27b70a85UL, 0x2e1b2138UL, 0x4d2c6dfcUL,
- 0x53380d13UL, 0x650a7354UL, 0x766a0abbUL, 0x81c2c92eUL, 0x92722c85UL,
- 0xa2bfe8a1UL, 0xa81a664bUL, 0xc24b8b70UL, 0xc76c51a3UL, 0xd192e819UL,
- 0xd6990624UL, 0xf40e3585UL, 0x106aa070UL, 0x19a4c116UL, 0x1e376c08UL,
- 0x2748774cUL, 0x34b0bcb5UL, 0x391c0cb3UL, 0x4ed8aa4aUL, 0x5b9cca4fUL,
- 0x682e6ff3UL, 0x748f82eeUL, 0x78a5636fUL, 0x84c87814UL, 0x8cc70208UL,
- 0x90befffaUL, 0xa4506cebUL, 0xbef9a3f7UL, 0xc67178f2UL
-};
-
-/* Various logical functions */
-#define RORc(x, y) \
- (unsigned long)(x) & 0xUL) >> (unsigned long)((y) & 31)) | \
-((unsigned long)(x) << (unsigned long)(32 - ((y) & 31 &
0xUL)
-#define Ch(x, y, z) (z ^ (x & (y ^ z)))
-#define Maj(x, y, z) (((x | y) & z) | (x & y))
-#define S(x, n) RORc((x), (n))
-#define R(x, n) (((x) & 0xUL) >> (n))
-#define Sigma0(x) (S(x, 2) ^ S(x, 13) ^ S(x, 22))
-#define Sigma1(x) (S(x, 6) ^ S(x, 11) ^ S(x, 25))
-#define Gamma0(x) (S(x, 7) ^ S(x, 18) ^ R(x, 3))
-#define Gamma1(x) (S(x, 17) ^ S(x, 19) ^ R(x, 10))
-
void rtw_secmicsetkey(struct mic_data *pmicdata, u8 *key);
void rtw_secmicappendbyte(struct mic_data *pmicdata, u8 b);
void rtw_secmicappend(struct mic_data *pmicdata, u8 *src, u32 nBytes);
--
2.28.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/8] staging: rtl8188eu: remove cckrates{only}_included()
In rtw_ieee80211.c there are rtw_is_cckrates_included() and
rtw_is_cckratesonly_included() which have the same functionality as
cckrates_included() and cckrates_only_included() defined in
rtw_wlan_util.c. Remove the functions from rtw_wlan_util.c and use
those from rtw_ieee80211.c.
Signed-off-by: Michael Straube
---
.../staging/rtl8188eu/core/rtw_wlan_util.c| 34 +++
.../staging/rtl8188eu/include/rtw_mlme_ext.h | 3 --
2 files changed, 4 insertions(+), 33 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index efe1f1ba7acf..bf7dd13dde03 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -53,32 +53,6 @@ static const u8 rtw_basic_rate_mix[7] = {
IEEE80211_OFDM_RATE_24MB | IEEE80211_BASIC_RATE_MASK
};
-bool cckrates_included(unsigned char *rate, int ratelen)
-{
- int i;
-
- for (i = 0; i < ratelen; i++) {
- u8 r = rate[i] & 0x7f;
-
- if (r == 2 || r == 4 || r == 11 || r == 22)
- return true;
- }
- return false;
-}
-
-bool cckratesonly_included(unsigned char *rate, int ratelen)
-{
- int i;
-
- for (i = 0; i < ratelen; i++) {
- u8 r = rate[i] & 0x7f;
-
- if (r != 2 && r != 4 && r != 11 && r != 22)
- return false;
- }
- return true;
-}
-
unsigned char networktype_to_raid(unsigned char network_type)
{
switch (network_type) {
@@ -111,9 +85,9 @@ u8 judge_network_type(struct adapter *padapter, unsigned
char *rate, int ratelen
if (pmlmeinfo->HT_enable)
network_type = WIRELESS_11_24N;
- if (cckratesonly_included(rate, ratelen))
+ if (rtw_is_cckratesonly_included(rate))
network_type |= WIRELESS_11B;
- else if (cckrates_included(rate, ratelen))
+ else if (rtw_is_cckrates_included(rate))
network_type |= WIRELESS_11BG;
else
network_type |= WIRELESS_11G;
@@ -1362,9 +1336,9 @@ void update_wireless_mode(struct adapter *padapter)
if (pmlmeinfo->HT_enable)
network_type = WIRELESS_11_24N;
- if (cckratesonly_included(rate, ratelen))
+ if (rtw_is_cckratesonly_included(rate))
network_type |= WIRELESS_11B;
- else if (cckrates_included(rate, ratelen))
+ else if (rtw_is_cckrates_included(rate))
network_type |= WIRELESS_11BG;
else
network_type |= WIRELESS_11G;
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
index 565bfe46256c..713e23229ef5 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
@@ -568,9 +568,6 @@ void addba_timer_hdl(struct timer_list *t);
mod_timer(&mlmeext->link_timer, jiffies + \
msecs_to_jiffies(ms))
-bool cckrates_included(unsigned char *rate, int ratelen);
-bool cckratesonly_included(unsigned char *rate, int ratelen);
-
void process_addba_req(struct adapter *padapter, u8 *paddba_req, u8 *addr);
void update_TSF(struct mlme_ext_priv *pmlmeext, u8 *pframe, uint len);
--
2.28.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/8] staging: rtl8188eu: rename struct field Bssid -> bssid
Rename field of struct rt_pmkid_list to avoid camel case.
Bssid -> bssid
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c| 2 +-
drivers/staging/rtl8188eu/include/rtw_security.h | 2 +-
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 8
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 5256817ee12a..d34d46506b50 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1673,7 +1673,7 @@ static int SecIsInPMKIDList(struct adapter *Adapter, u8
*bssid)
do {
if ((psecuritypriv->PMKIDList[i].bUsed) &&
- (!memcmp(psecuritypriv->PMKIDList[i].Bssid, bssid,
ETH_ALEN)))
+ (!memcmp(psecuritypriv->PMKIDList[i].bssid, bssid,
ETH_ALEN)))
break;
} while (++i < NUM_PMKID_CACHE);
diff --git a/drivers/staging/rtl8188eu/include/rtw_security.h
b/drivers/staging/rtl8188eu/include/rtw_security.h
index 5f418003647b..bfa080d6a1a9 100644
--- a/drivers/staging/rtl8188eu/include/rtw_security.h
+++ b/drivers/staging/rtl8188eu/include/rtw_security.h
@@ -82,7 +82,7 @@ union Keytype {
struct rt_pmkid_list {
u8 bUsed;
- u8 Bssid[6];
+ u8 bssid[6];
u8 PMKID[16];
u8 SsidBuf[33];
u8 *ssid_octet;
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 7fd8582ba353..9919413b6f7e 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -778,7 +778,7 @@ static int rtw_wx_set_pmkid(struct net_device *dev,
/* overwrite PMKID */
for (j = 0; j < NUM_PMKID_CACHE; j++) {
- if (!memcmp(psecuritypriv->PMKIDList[j].Bssid,
strIssueBssid, ETH_ALEN)) {
+ if (!memcmp(psecuritypriv->PMKIDList[j].bssid,
strIssueBssid, ETH_ALEN)) {
/* BSSID is matched, the same AP => rewrite
with new PMKID. */
DBG_88E("[%s] BSSID exists in the PMKList.\n",
__func__);
memcpy(psecuritypriv->PMKIDList[j].PMKID,
pPMK->pmkid, IW_PMKID_LEN);
@@ -794,7 +794,7 @@ static int rtw_wx_set_pmkid(struct net_device *dev,
DBG_88E("[%s] Use the new entry index = %d for this
PMKID.\n",
__func__, psecuritypriv->PMKIDIndex);
-
memcpy(psecuritypriv->PMKIDList[psecuritypriv->PMKIDIndex].Bssid,
strIssueBssid, ETH_ALEN);
+
memcpy(psecuritypriv->PMKIDList[psecuritypriv->PMKIDIndex].bssid,
strIssueBssid, ETH_ALEN);
memcpy(psecuritypriv->PMKIDList[psecuritypriv->PMKIDIndex].PMKID, pPMK->pmkid,
IW_PMKID_LEN);
psecuritypriv->PMKIDList[psecuritypriv->PMKIDIndex].bUsed = true;
@@ -806,9 +806,9 @@ static int rtw_wx_set_pmkid(struct net_device *dev,
DBG_88E("[%s] IW_PMKSA_REMOVE!\n", __func__);
ret = true;
for (j = 0; j < NUM_PMKID_CACHE; j++) {
- if (!memcmp(psecuritypriv->PMKIDList[j].Bssid,
strIssueBssid, ETH_ALEN)) {
+ if (!memcmp(psecuritypriv->PMKIDList[j].bssid,
strIssueBssid, ETH_ALEN)) {
/* BSSID is matched, the same AP => Remove
this PMKID information and reset it. */
-
eth_zero_addr(psecuritypriv->PMKIDList[j].Bssid);
+
eth_zero_addr(psecuritypriv->PMKIDList[j].bssid);
psecuritypriv->PMKIDList[j].bUsed = false;
break;
}
--
2.28.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/8] staging: rtl8188eu: rename struct field bUsed -> used
Rename field of struct rt_pmkid_list to avoid camel case.
bUsed -> used
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c| 2 +-
drivers/staging/rtl8188eu/include/rtw_security.h | 2 +-
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index d34d46506b50..668a24f25fce 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1672,7 +1672,7 @@ static int SecIsInPMKIDList(struct adapter *Adapter, u8
*bssid)
int i = 0;
do {
- if ((psecuritypriv->PMKIDList[i].bUsed) &&
+ if ((psecuritypriv->PMKIDList[i].used) &&
(!memcmp(psecuritypriv->PMKIDList[i].bssid, bssid,
ETH_ALEN)))
break;
} while (++i < NUM_PMKID_CACHE);
diff --git a/drivers/staging/rtl8188eu/include/rtw_security.h
b/drivers/staging/rtl8188eu/include/rtw_security.h
index 737f1da81f6b..d08a8d8adccf 100644
--- a/drivers/staging/rtl8188eu/include/rtw_security.h
+++ b/drivers/staging/rtl8188eu/include/rtw_security.h
@@ -81,7 +81,7 @@ union Keytype {
};
struct rt_pmkid_list {
- u8 bUsed;
+ u8 used;
u8 bssid[ETH_ALEN];
u8 PMKID[16];
u8 SsidBuf[33];
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 9919413b6f7e..8e10462f1fbe 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -782,7 +782,7 @@ static int rtw_wx_set_pmkid(struct net_device *dev,
/* BSSID is matched, the same AP => rewrite
with new PMKID. */
DBG_88E("[%s] BSSID exists in the PMKList.\n",
__func__);
memcpy(psecuritypriv->PMKIDList[j].PMKID,
pPMK->pmkid, IW_PMKID_LEN);
- psecuritypriv->PMKIDList[j].bUsed = true;
+ psecuritypriv->PMKIDList[j].used = true;
psecuritypriv->PMKIDIndex = j + 1;
blInserted = true;
break;
@@ -797,7 +797,7 @@ static int rtw_wx_set_pmkid(struct net_device *dev,
memcpy(psecuritypriv->PMKIDList[psecuritypriv->PMKIDIndex].bssid,
strIssueBssid, ETH_ALEN);
memcpy(psecuritypriv->PMKIDList[psecuritypriv->PMKIDIndex].PMKID, pPMK->pmkid,
IW_PMKID_LEN);
-
psecuritypriv->PMKIDList[psecuritypriv->PMKIDIndex].bUsed = true;
+
psecuritypriv->PMKIDList[psecuritypriv->PMKIDIndex].used = true;
psecuritypriv->PMKIDIndex++;
if (psecuritypriv->PMKIDIndex == 16)
psecuritypriv->PMKIDIndex = 0;
@@ -809,7 +809,7 @@ static int rtw_wx_set_pmkid(struct net_device *dev,
if (!memcmp(psecuritypriv->PMKIDList[j].bssid,
strIssueBssid, ETH_ALEN)) {
/* BSSID is matched, the same AP => Remove
this PMKID information and reset it. */
eth_zero_addr(psecuritypriv->PMKIDList[j].bssid);
- psecuritypriv->PMKIDList[j].bUsed = false;
+ psecuritypriv->PMKIDList[j].used = false;
break;
}
}
--
2.28.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/8] staging: rtl8188eu: remove unused variable ratelen
After the removal of cckrates_included() and cckrates_only_included()
from rtw_wlan_util.c the variable/parameter 'ratelen' is unused now.
Remove it from update_wireless_mode() and judge_network_type().
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 6 ++
drivers/staging/rtl8188eu/hal/usb_halinit.c | 4 ++--
drivers/staging/rtl8188eu/include/rtw_mlme_ext.h | 2 +-
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index bf7dd13dde03..8e8f1721b1a2 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -76,7 +76,7 @@ unsigned char networktype_to_raid(unsigned char network_type)
}
}
-u8 judge_network_type(struct adapter *padapter, unsigned char *rate, int
ratelen)
+u8 judge_network_type(struct adapter *padapter, unsigned char *rate)
{
u8 network_type = 0;
struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
@@ -1321,15 +1321,13 @@ void update_capinfo(struct adapter *Adapter, u16
updateCap)
void update_wireless_mode(struct adapter *padapter)
{
- int ratelen, network_type = 0;
+ int network_type = 0;
u32 SIFS_Timer;
struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
struct mlme_ext_info *pmlmeinfo = &pmlmeext->mlmext_info;
struct wlan_bssid_ex *cur_network = &pmlmeinfo->network;
unsigned char *rate = cur_network->SupportedRates;
- ratelen = rtw_get_rateset_len(cur_network->SupportedRates);
-
if (pmlmeinfo->HT_info_enable && pmlmeinfo->HT_caps_enable)
pmlmeinfo->HT_enable = 1;
diff --git a/drivers/staging/rtl8188eu/hal/usb_halinit.c
b/drivers/staging/rtl8188eu/hal/usb_halinit.c
index 5e7bb22d7d01..abe58cf2de16 100644
--- a/drivers/staging/rtl8188eu/hal/usb_halinit.c
+++ b/drivers/staging/rtl8188eu/hal/usb_halinit.c
@@ -1893,7 +1893,7 @@ void UpdateHalRAMask8188EUsb(struct adapter *adapt, u32
mac_id, u8 rssi_level)
switch (mac_id) {
case 0:/* for infra mode */
supportRateNum =
rtw_get_rateset_len(cur_network->SupportedRates);
- networkType = judge_network_type(adapt,
cur_network->SupportedRates, supportRateNum) & 0xf;
+ networkType = judge_network_type(adapt,
cur_network->SupportedRates) & 0xf;
raid = networktype_to_raid(networkType);
mask = update_supported_rate(cur_network->SupportedRates,
supportRateNum);
mask |= (pmlmeinfo->HT_enable) ?
update_MSC_rate(&pmlmeinfo->HT_caps) : 0;
@@ -1911,7 +1911,7 @@ void UpdateHalRAMask8188EUsb(struct adapter *adapt, u32
mac_id, u8 rssi_level)
break;
default: /* for each sta in IBSS */
supportRateNum =
rtw_get_rateset_len(pmlmeinfo->FW_sta_info[mac_id].SupportedRates);
- networkType = judge_network_type(adapt,
pmlmeinfo->FW_sta_info[mac_id].SupportedRates, supportRateNum) & 0xf;
+ networkType = judge_network_type(adapt,
pmlmeinfo->FW_sta_info[mac_id].SupportedRates) & 0xf;
raid = networktype_to_raid(networkType);
mask = update_supported_rate(cur_network->SupportedRates,
supportRateNum);
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
index 713e23229ef5..b11a6886a083 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
@@ -448,7 +448,7 @@ void init_addba_retry_timer(struct adapter *adapt, struct
sta_info *sta);
struct xmit_frame *alloc_mgtxmitframe(struct xmit_priv *pxmitpriv);
unsigned char networktype_to_raid(unsigned char network_type);
-u8 judge_network_type(struct adapter *padapter, unsigned char *rate, int len);
+u8 judge_network_type(struct adapter *padapter, unsigned char *rate);
void get_rate_set(struct adapter *padapter, unsigned char *pbssrate, int *len);
void UpdateBrateTbl(struct adapter *padapter, u8 *mBratesOS);
void UpdateBrateTblForSoftAP(u8 *bssrateset, u32 bssratelen);
--
2.28.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
