[PATCH v2] qnx4_match: do not over run the buffer
From: Tong Zhang
the di_fname may not terminated by '\0', use strnlen to prevent buffer
overrun
[ 513.248784] qnx4_readdir: bread failed (3718095557)
[ 513.250880]
==
[ 513.251109] BUG: KASAN: use-after-free in strlen+0x1f/0x40
[ 513.251268] Read of size 1 at addr 88800270 by task find/230
[ 513.251419]
[ 513.251677] CPU: 0 PID: 230 Comm: find Not tainted 5.10.0-rc4+ #64
[ 513.251805] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.13.0-48-gd84
[ 513.252069] Call Trace:
[ 513.252310] dump_stack+0x7d/0xa3
[ 513.252443] print_address_description.constprop.0+0x1e/0x220
[ 513.252572] ? _raw_spin_lock_irqsave+0x7b/0xd0
[ 513.252681] ? _raw_write_lock_irqsave+0xd0/0xd0
[ 513.252785] ? strlen+0x1f/0x40
[ 513.252869] ? strlen+0x1f/0x40
[ 513.252955] kasan_report.cold+0x37/0x7c
[ 513.253059] ? qnx4_block_map+0x130/0x1d0
[ 513.253152] ? strlen+0x1f/0x40
[ 513.253237] strlen+0x1f/0x40
[ 513.253329] qnx4_lookup+0xab/0x220
[ 513.253431] __lookup_slow+0x103/0x220
[ 513.253531] ? vfs_unlink+0x2e0/0x2e0
[ 513.253626] ? down_read+0xd8/0x190
[ 513.253721] ? down_write_killable+0x110/0x110
[ 513.253823] ? generic_permission+0x4c/0x240
[ 513.253929] walk_component+0x214/0x2c0
[ 513.254035] ? handle_dots.part.0+0x760/0x760
[ 513.254137] ? walk_component+0x2c0/0x2c0
[ 513.254233] ? path_init+0x546/0x6b0
[ 513.254327] ? __kernel_text_address+0x9/0x30
[ 513.254430] ? unwind_get_return_address+0x2a/0x40
[ 513.254538] ? create_prof_cpu_mask+0x20/0x20
[ 513.254637] ? arch_stack_walk+0x99/0xf0
[ 513.254736] path_lookupat.isra.0+0xb0/0x240
[ 513.254840] filename_lookup+0x128/0x250
[ 513.254939] ? may_linkat+0xb0/0xb0
[ 513.255033] ? __fput+0x199/0x3c0
[ 513.255127] ? kasan_save_stack+0x32/0x40
[ 513.255224] ? kasan_save_stack+0x1b/0x40
[ 513.255323] ? kasan_unpoison_shadow+0x33/0x40
[ 513.255426] ? __kasan_kmalloc.constprop.0+0xc2/0xd0
[ 513.255538] ? getname_flags+0x100/0x2a0
[ 513.255635] vfs_statx+0xd8/0x1d0
[ 513.255728] ? vfs_getattr+0x40/0x40
[ 513.255821] ? lockref_put_return+0xb2/0x120
[ 513.255922] __do_sys_newfstatat+0x7d/0xd0
[ 513.256022] ? __ia32_sys_newlstat+0x30/0x30
[ 513.256122] ? __kasan_slab_free+0x121/0x150
[ 513.256222] ? rcu_segcblist_enqueue+0x72/0x80
[ 513.256333] ? fpregs_assert_state_consistent+0x4d/0x60
[ 513.256446] ? exit_to_user_mode_prepare+0x2d/0xf0
[ 513.256551] ? __x64_sys_newfstatat+0x39/0x60
[ 513.256651] do_syscall_64+0x33/0x40
[ 513.256750] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Co-Developed-by: Anders Larsen
Signed-off-by: Tong Zhang
Signed-off-by: Anders Larsen
---
v2: The name can grow longer than QNX4_SHORT_NAME_MAX if de is a
QNX4_FILE_LINK type and de should points to a qnx4_link_info struct, so
this is safe. We also remove redundant checks in this version.
fs/qnx4/namei.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/qnx4/namei.c b/fs/qnx4/namei.c
index 8d72221735d7..2bcbbd7c772e 100644
--- a/fs/qnx4/namei.c
+++ b/fs/qnx4/namei.c
@@ -40,9 +40,7 @@ static int qnx4_match(int len, const char *name,
} else {
namelen = QNX4_SHORT_NAME_MAX;
}
- thislen = strlen( de->di_fname );
- if ( thislen > namelen )
- thislen = namelen;
+ thislen = strnlen( de->di_fname, namelen );
if (len != thislen) {
return 0;
}
--
2.29.2
Re: [PATCH v1] qnx4_match: do not over run the buffer
On Saturday, 2020-11-21 22:47 Tong Zhang wrote:
>
> > On Nov 21, 2020, at 4:40 PM, Anders Larsen wrote:
> >
> > On Friday, 2020-11-20 22:21 Tong Zhang wrote:
> >> the di_fname may not terminated by '\0', use strnlen to prevent buffer
> >> overrun
> >>
> >> ---
> >> fs/qnx4/namei.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/fs/qnx4/namei.c b/fs/qnx4/namei.c
> >> index 8d72221735d7..c0e79094f578 100644
> >> --- a/fs/qnx4/namei.c
> >> +++ b/fs/qnx4/namei.c
> >> @@ -40,7 +40,7 @@ static int qnx4_match(int len, const char *name,
> >>} else {
> >>namelen = QNX4_SHORT_NAME_MAX;
> >>}
> >> - thislen = strlen( de->di_fname );
> >> + thislen = strnlen( de->di_fname, QNX4_SHORT_NAME_MAX );
> >
> > that should be
> > + thislen = strnlen( de->di_fname, namelen );
> > otherwise the length of a filename would always be limited to
> > QNX4_SHORT_NAME_MAX (16) characters.
> >
> Why should we put something bigger here if the size of
> qnx4_inode_entry->di_fname is QNX4_SHORT_NAME_MAX.
> Won’t that be a problem?
If QNX4_FILE_LINK is set in de->di_status (see line 38), 'de' actually points
to a struct qnx4_link_info which can hold a longer name.
That's the reason for the namelen massage.
(Please don't ask why it is not a union)
Cheers
Anders
Re: [PATCH v1] qnx4_match: do not over run the buffer
On Friday, 2020-11-20 22:21 Tong Zhang wrote:
> the di_fname may not terminated by '\0', use strnlen to prevent buffer
> overrun
>
> ---
> fs/qnx4/namei.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/qnx4/namei.c b/fs/qnx4/namei.c
> index 8d72221735d7..c0e79094f578 100644
> --- a/fs/qnx4/namei.c
> +++ b/fs/qnx4/namei.c
> @@ -40,7 +40,7 @@ static int qnx4_match(int len, const char *name,
> } else {
> namelen = QNX4_SHORT_NAME_MAX;
> }
> - thislen = strlen( de->di_fname );
> + thislen = strnlen( de->di_fname, QNX4_SHORT_NAME_MAX );
that should be
+ thislen = strnlen( de->di_fname, namelen );
otherwise the length of a filename would always be limited to
QNX4_SHORT_NAME_MAX (16) characters.
> if ( thislen > namelen )
> thislen = namelen;
These two lines can be dropped now, as the result of strnlen() cannot exceed
namelen anyway.
Cheers
Anders
Re: [PATCH] qnx4: do not interpret -EIO as a correct address
On Friday, 2020-10-23 23:16 Tong Zhang wrote:
> qnx4_block_map() may return -EIO on funny qnx4 fs image, in this case do
> not interpret -EIO as a correct address
>
> Signed-off-by: Tong Zhang
> ---
> fs/qnx4/inode.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/qnx4/inode.c b/fs/qnx4/inode.c
> index e8da1cde87b9..d3a40c5b1a9a 100644
> --- a/fs/qnx4/inode.c
> +++ b/fs/qnx4/inode.c
> @@ -59,6 +59,8 @@ static int qnx4_get_block( struct inode *inode, sector_t
> iblock, struct buffer_h
> QNX4DEBUG((KERN_INFO "qnx4: qnx4_get_block inode=[%ld]
> iblock=[%ld]\n",inode->i_ino,iblock));
>
> phys = qnx4_block_map( inode, iblock );
> + if (phys == -EIO)
> + return -EIO;
> if ( phys ) {
> // logical block is before EOF
> map_bh(bh, inode->i_sb, phys);
The fix looks sane to me, but how about the two other callers of
qnx4_block_map(), are they not affected as well?
Cheers
Anders
Re: [PATCH v3 1/4] dt-bindings: vendor-prefixes: Add Shanghai Top Display Optolelectronics vendor prefix
On Tuesday, 2020-09-08 09:54 Neil Armstrong wrote: > Shanghai Top Display Optolelectronics Co., Ltd is a display manufacturer > from Shanghai. > Web site of the company: http://www.shtdo.com/ > > Signed-off-by: Neil Armstrong > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index a1e4356cf522..4e9dfb352c68 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -1078,6 +1078,8 @@ patternProperties: > description: TPK U.S.A. LLC >"^tplink,.*": > description: TP-LINK Technologies Co., Ltd. > + "^tdo,.*": > +description: Shangai Top Display Optoelectronics Co., Ltd Please keep the list sorted alphabetically as requested in line 25 of the file. >"^tpo,.*": > description: TPO >"^tq,.*": Cheers Anders
Re: [PATCH] Replace HTTP links with HTTPS ones: QNX4
On Monday, 2020-07-06 19:39 Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't contain `\bxmlns\b`: > For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > If both the HTTP and HTTPS versions > return 200 OK and serve the same content: > Replace HTTP with HTTPS. > > Signed-off-by: Alexander A. Klimov > --- > Continuing my work started at 93431e0607e5. > > If there are any URLs to be removed completely or at least not HTTPSified: > Just clearly say so and I'll *undo my change*. > See also https://lkml.org/lkml/2020/6/27/64 > > If there are any valid, but yet not changed URLs: > See https://lkml.org/lkml/2020/6/26/837 > > fs/qnx4/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/qnx4/Kconfig b/fs/qnx4/Kconfig > index 45b5b98376c4..6ba0e5a1303f 100644 > --- a/fs/qnx4/Kconfig > +++ b/fs/qnx4/Kconfig > @@ -5,7 +5,7 @@ config QNX4FS_FS > help > This is the file system used by the real-time operating systems > QNX 4 and QNX 6 (the latter is also called QNX RTP). > - Further information is available at <http://www.qnx.com/>. > + Further information is available at <https://www.qnx.com/>. > Say Y if you intend to mount QNX hard disks or floppies. > > To compile this file system support as a module, choose M here: the Acked-by: Anders Larsen
Re: [PATCH] fs/qnx: Delete unnecessary checks before brelse()
On Tuesday, 2019-09-03 19:20 Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 3 Sep 2019 19:15:09 +0200 > > The brelse() function tests whether its argument is NULL > and then returns immediately. > Thus the tests around the shown calls are not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > fs/qnx4/inode.c | 3 +-- > fs/qnx6/inode.c | 6 ++ > 2 files changed, 3 insertions(+), 6 deletions(-) > > diff --git a/fs/qnx4/inode.c b/fs/qnx4/inode.c > index e8da1cde87b9..018a4c657f7c 100644 > --- a/fs/qnx4/inode.c > +++ b/fs/qnx4/inode.c > @@ -118,8 +118,7 @@ unsigned long qnx4_block_map( struct inode *inode, long > iblock ) > bh = NULL; > } > } > - if ( bh ) > - brelse( bh ); > + brelse(bh); > } > > QNX4DEBUG((KERN_INFO "qnx4: mapping block %ld of inode %ld = > %ld\n",iblock,inode->i_ino,block)); > diff --git a/fs/qnx6/inode.c b/fs/qnx6/inode.c > index 345db56c98fd..083170541add 100644 > --- a/fs/qnx6/inode.c > +++ b/fs/qnx6/inode.c > @@ -472,10 +472,8 @@ static int qnx6_fill_super(struct super_block *s, void > *data, int silent) > out1: > iput(sbi->inodes); > out: > - if (bh1) > - brelse(bh1); > - if (bh2) > - brelse(bh2); > + brelse(bh1); > + brelse(bh2); > outnobh: > kfree(qs); > s->s_fs_info = NULL; Acked-by: Anders Larsen
Re: [PATCH] isofs: fix timestamps beyond 2027
On Thursday, 19 October 2017 12:51:05 CEST Al Viro wrote: > On Thu, Oct 19, 2017 at 11:50:18AM +0200, Arnd Bergmann wrote: > > isofs uses a 'char' variable to load the number of years since > > 1900 for an inode timestamp. On architectures that use a signed > > char type by default, this results in an invalid date for > > anything beyond 2027. > > > > This adds a cast to 'u8' for the year number, which should extend > > the shelf life of the file system until 2155. > > > > This should be backported to all kernels that might still be > > in use by that date. > > > > Cc: sta...@vger.kernel.org > > Signed-off-by: Arnd Bergmann > > --- > > > > fs/isofs/util.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/isofs/util.c b/fs/isofs/util.c > > index 005a15cfd30a..f40796c4c6c2 100644 > > --- a/fs/isofs/util.c > > +++ b/fs/isofs/util.c > > @@ -20,7 +20,7 @@ int iso_date(char * p, int flag) > > > > int year, month, day, hour, minute, second, tz; > > int crtime; > > > > - year = p[0]; > > + year = (int)(u8)p[0]; > > This is BS; just turn that > char time[7]; > in struct stamp into > unsigned char time[7]; > and adjust iso_date() accordingly. Or make that > sucker actually take struct stamp *, while we are at it. > > And I'd suggest going through the rest of on-disk structures in > rock.h and looking for other trouble of that sort. There are more candidates in include/uapi/linux/iso_fs.h - most of them seems to be unused (by us), but at the very least struct iso_directory_record contains a date-field of the same sort that is indeed used. Cheers Anders
Re: MAINTAINERS without commits in the last 3 years
On Wednesday, 2016-08-24 16:33 Joe Perches wrote: > Many email addresses in MAINTAINERS no longer work so many > sections in > MAINTAINERS could likely be considered either > obsolete or unmaintained. Whereas I agree it's helpful to purge dysfunctional adresses... > These M: entries in MAINTAINERS haven't authored or had any > -by: signature entries in git log for the last 3 years. ...IMHO just because there hasn't been any activity for does not automatically mean the subsystem in question has been abandoned. I'm using "my" subsystem (QNX4 FS) almost daily, so I don't believe anything would be gained if get_maintainers.pl would stop keeping me in the loop. Cheers Anders
Re: Linux device driver for USB WIFI needs integrating
On Monday, 27. April 2015 16:49:09 Anders Larsen wrote: > On 2015-04-27 16:23, Chris Ward wrote: > > What mainline kernel level will contain the patch ? > > Marek (CC'ed) added the USB ID some 4 weeks ago, so it's scheduled for > the upcoming 4.1 FYI yesterday Marek's patch was accepted into the stable queues (3.10.x, 3.14.x, 3.19.x and 4.0.x), so it will probably hit most distros in the next few weeks. Cheers Anders -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux device driver for USB WIFI needs integrating
On 2015-04-27 16:23, Chris Ward wrote: With the patch actually applied, the WiFi adapter is recognised and works, both on boot and if the adapter is plugged in later. So, all is well. glad to hear that - and thanks for testing! What mainline kernel level will contain the patch ? Marek (CC'ed) added the USB ID some 4 weeks ago, so it's scheduled for the upcoming 4.1 @Marek: can we get your commit 9374e7d2 added to the stable kernels, please? (the full discussion with Chris is archived here: https://lkml.org/lkml/2015/4/24/156) Cheers Anders -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux device driver for USB WIFI needs integrating
On 2015-04-27 10:38, Chris Ward wrote:
I have put the requested files in http://tjcw.freeshell.org/usbn10/ .
The
ones with 'after' in the name are with the device plugged in at boot.
well, .config contains
CONFIG_RTL8192CU=m
so the driver is built.
and dmesg contains
usb 3-2: new high-speed USB device number 2 using xhci_hcd
usb 3-2: New USB device found, idVendor=0b05, idProduct=17ba
usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-2: Product: 802.11n WLAN Adapter
usb 3-2: Manufacturer: Realtek
usb 3-2: SerialNumber: 00e04c01
so the device is recognised (at USB level).
The module 'rtl8192cu.ko' isn't loaded as expected, however.
Perhaps it wasn't installed correctly - the USB id should have an entry
in /lib/modules/3.16.7-21/modules.alias of the form 'alias
usb:v0B05p17BAd*dc*dsc*dp*ic*isc*ip*in* rtl8192cu'
('grep usb:v0B05p17BA /lib/modules/*/modules.alias' should show it)
If the entry is missing, it must appear after the alias file is
regenerated (with 'depmod -a').
If it's there, but the module is still not loaded when you plug the
device, please try to load it manually (with 'modprobe -v rtl8192cu
debug=5') and check dmesg again.
Cheers
Anders
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux device driver for USB WIFI needs integrating
On 2015-04-24 19:31, Chris Ward wrote: No, with the patch the device isn't recognised at boot time. Strange. Does the module 'rtl8192cu' get loaded automatically (check with 'lsmod')? What happens if you wait until the system is booted, then plug the device? Could you put your '.config' and the output from 'dmesg' and 'lsusb -v' (with the device plugged in) on a server somewhere and post a link here? (If not, send me the files in a private mail, then I'll post the relevant parts on the list) Cheers Anders -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux device driver for USB WIFI needs integrating
On 2015-04-24 14:25, Anders Larsen wrote: On 2015-04-24 13:59, Chris Ward wrote: lsusb shows Bus 003 Device 024: ID 0b05:17ba ASUSTek Computer, Inc. does the attached trivial patch help? (it should make the in-tree driver recognise your ASUS device) I just realised that the above USB id was already added to the in-tree driver - it should appear the next Kernel release. (commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 in Linus' tree) If my patch (which does exactly the same as the above) works for you we can ask for that commit to be added to the stable kernels, so please let us know how you proceed. Cheers Anders-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux device driver for USB WIFI needs integrating
On 2015-04-24 13:59, Chris Ward wrote:
lsusb shows
Bus 003 Device 024: ID 0b05:17ba ASUSTek Computer, Inc.
OK, thanks
I've just built the OpenSUSE kernel from source, it has that CONFIG=m
.
I think ASUS have changed the chip set.
only the USB id AFAICT - 0b05:17ab is supported
Do we have to wait for ASUS to debug their driver ? Supposedly it
worked
with an older kernel (up to 3.10 I think)
does the attached trivial patch help?
(it should make the in-tree driver recognise your ASUS device)
Cheers
Anders=46rom 2d7ede77347f9e2f00b248839961b3da311a27fa Mon Sep 17 00:00:00 2001
From: Anders Larsen
Date: Fri, 24 Apr 2015 14:17:33 +0200
Subject: [PATCH] rtlwifi/rtl8192cu: Add USB id for ASUS USB-N10 NANO
"ASUS USB-N10 NANO" wifi adapter USB id: 0b05:17ba
Signed-off-by: Anders Larsen
---
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index 1ac6383..77c4b62 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -364,6 +364,7 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
{RTL_USB_DEVICE(0x0846, 0x9021, rtl92cu_hal_cfg)}, /*Netgear-Sercomm*/
{RTL_USB_DEVICE(0x0846, 0xf001, rtl92cu_hal_cfg)}, /*On Netwrks N300MA*/
{RTL_USB_DEVICE(0x0b05, 0x17ab, rtl92cu_hal_cfg)}, /*ASUS-Edimax*/
+ {RTL_USB_DEVICE(0x0b05, 0x17ba, rtl92cu_hal_cfg)}, /*ASUS-Edimax N10 nano*/
{RTL_USB_DEVICE(0x0bda, 0x8186, rtl92cu_hal_cfg)}, /*Realtek 92CE-VAU*/
{RTL_USB_DEVICE(0x0df6, 0x0061, rtl92cu_hal_cfg)}, /*Sitecom-Edimax*/
{RTL_USB_DEVICE(0x0e66, 0x0019, rtl92cu_hal_cfg)}, /*Hawking-Edimax*/
--
2.3.6
Re: Linux device driver for USB WIFI needs integrating
On 2015-04-24 13:37, Chris Ward wrote: I just tried building the driver from ASUS with the current kernel from OpenSUSE (3.16.7-21), and got a trap when booting (in the insmod, I think) With an out-of-tree driver you are on your own, sorry. Did you enable the in-tree driver (CONFIG_RTL8192CU)? (That driver supports the chip used by the ASUS device AFAICT) What is the USB Id of the ASUS device (as shown by 'lsusb')? Cheers Anders-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux device driver for USB WIFI needs integrating
On 2015-04-24 12:37, Chris Ward wrote: There is a Linux driver here http://www.asus.com/Networking/USBN10_NANO/HelpDesk_download/ that needs integrating into the 'kernel.org' source. Isn't that device supported by the in-tree RTL8192CU/RTL8188CU driver? (CONFIG_RTL8192CU, drivers/net/wireless/rtlwifi/rtl8192cu/) If it isn't, it should only be a matter of adding the USB Id of the ASUS device. Do we need formal permission from ASUS, or do we just take it ? AFAICT the archive ASUS has made available contains a driver authored by RealTek, so that would be where to ask. The source files contains a statement that they are covered by GPLv2, so formally you would not have to ask - although I'd consider it in good taste to do so. Cheers Anders-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pch_gbe: ethtool cannot change parameters when link is down
When attempting to change e.g. the advertising mask when the link is down
ecmd->speed is -1 causing mii_ethtool_sset() to bail out.
This bug bit when connecting to a gigabit switch through a 4-pin (industrial)
cable, since link negotiation would not complete (both endpoints claimed to
be gigabit-capable, but this is not possible with only 4 pins).
Any attempt to fix this by setting autonegation to not offer 1000Mbps
failed as the setting would not be accepted while the link was still down...
Set ecmd->speed to SPEED_1000 to satisfy mii_ethtool_sset()
(the actual value of ecmd->speed doesn't matter as long as it is valid,
since a re-negotation is forced afterwards).
Signed-off-by: Anders Larsen
---
.../ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c|1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
index 1129db0..f0ceb89 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
@@ -118,6 +118,7 @@ static int pch_gbe_set_settings(struct net_device *netdev,
* filled by get_settings() on a down link, speed is -1: */
if (speed == UINT_MAX) {
speed = SPEED_1000;
+ ethtool_cmd_speed_set(ecmd, speed);
ecmd->duplex = DUPLEX_FULL;
}
ret = mii_ethtool_sset(&adapter->mii, ecmd);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel mailing list permalinks
On 2013-08-06 23:23, H. Peter Anvin wrote: On 08/06/2013 02:11 PM, Bjorn Helgaas wrote: >> >> The above link is also a good example of subtleness: + in a URL means a >> space character, it has to be escaped as %2B. Particularly a problem in >> gmail message-ids. the link in question works just fine without escaping the +; the + only has to be escaped in then query component of a URL, not in the path component where it is just another valid character - and the link in question did not contain any query component. (see RFC 3986 sections 3.3 and 3.4) A quoted Message-ID might be weird as heck, but one rarely if ever see them, I don't know if they are even legal. I don't think they are even possible, as the percent-sign is just another valid character in a Message-ID - but so is the '+' sign, so it seems you're trying to solve a non-existent problem... (see RFC 5322 section 3.2.3) Cheers Anders -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [trivial]treewide: Fix typo in various drivers
On 2012-12-28 16:49, Masanari Iida wrote:
Correct spelling typo in printk within various drivers.
---
diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
index ba9cfd4..8d0fe66 100644
--- a/net/caif/cfcnfg.c
+++ b/net/caif/cfcnfg.c
@@ -402,7 +402,7 @@ cfcnfg_linkup_rsp(struct cflayer *layer, u8
channel_id, enum cfctrl_srv serv,
phyinfo = cfcnfg_get_phyinfo_rcu(cnfg, phyid);
if (phyinfo == NULL) {
- pr_err("ERROR: Link Layer Device dissapeared"
+ pr_err("ERROR: Link Layer Device dissappeared"
that should rather be
+ pr_err("ERROR: Link Layer Device disappeared"
"while connecting\n");
goto unlock;
}
Cheers
Anders
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/25] userns: Convert the qnx4 filesystem to use kuid/kgid where appropriate
On 2012-09-20 13:42:02, Eric W. Biederman wrote: > From: "Eric W. Biederman" > > Cc: Anders Larsen > Acked-by: Serge Hallyn > Signed-off-by: Eric W. Biederman Acked-by: Anders Larsen > --- > fs/qnx4/inode.c |4 ++-- > init/Kconfig|1 - > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/fs/qnx4/inode.c b/fs/qnx4/inode.c > index 552e994..5c3c7b0 100644 > --- a/fs/qnx4/inode.c > +++ b/fs/qnx4/inode.c > @@ -312,8 +312,8 @@ struct inode *qnx4_iget(struct super_block *sb, unsigned > long ino) > (ino % QNX4_INODES_PER_BLOCK); > > inode->i_mode= le16_to_cpu(raw_inode->di_mode); > - inode->i_uid = (uid_t)le16_to_cpu(raw_inode->di_uid); > - inode->i_gid = (gid_t)le16_to_cpu(raw_inode->di_gid); > + i_uid_write(inode, (uid_t)le16_to_cpu(raw_inode->di_uid)); > + i_gid_write(inode, (gid_t)le16_to_cpu(raw_inode->di_gid)); > set_nlink(inode, le16_to_cpu(raw_inode->di_nlink)); > inode->i_size= le32_to_cpu(raw_inode->di_size); > inode->i_mtime.tv_sec = le32_to_cpu(raw_inode->di_mtime); > diff --git a/init/Kconfig b/init/Kconfig > index 390e629..b9d6be5 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -950,7 +950,6 @@ config UIDGID_CONVERTED > depends on NFSD = n > depends on NFS_FS = n > depends on OCFS2_FS = n > - depends on QNX4FS_FS = n > depends on QNX6FS_FS = n > depends on REISERFS_FS = n > depends on SQUASHFS = n > -- > 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [397/2many] MAINTAINERS - QNX4 FILESYSTEM
On 2007-08-13 08:34:35, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6a99fe5..ed3be09 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3799,6 +3799,8 @@ M: [EMAIL PROTECTED] > L: linux-kernel@vger.kernel.org > W: http://www.alarsen.net/linux/qnx4fs/ > S: Maintained > +F: fs/qnx4 > +F: include/linux/qnx4_fs.h include/linux/qnxtypes.h too Cheers Anders - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 2007-06-19 20:23:00, Alexandre Oliva wrote: > If you take the Wikipedia definition of Tivoization, you'll see it's > about copyleft software only, and no law mandates the use of copyleft > software. There's no end to bad laws, but a law that mandated the use > of copyleft (=> free) software and at the same time prohibited > modifications by the user would be a very contradictory one. You're absolutely right... Nobody forces us to use Linux in the credit-card terminals I'm currently working on; of course we could have selected a proprietary solution (and we would be forced to, were the Linux kernel and/or certain crucial libraries or utilities GPLv3 only). Only, your statement above seems to run counter to your previous claims that the "anti-tivoisation" provisions of GPLv3 would bring _more_ developers to copyleft software. So which one is it? Cheers Anders - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 2007-06-18 21:50:12, Alexandre Oliva wrote: > Given the ROM exception in GPLv3, I guess you could seal and > anti-tamper it as much as you want, and leave the ROM at such a place > in which it's easily replaceable but with signature checking and all > such that the user doesn't install ROM that is not authorized by you. Sorry, I didn't state the regulations requirement clearly enough: The manufacturer must be able to _remotely_ update the device firmware, so as I see it (IANAL), Tivoisation _is_ a requirement. Cheers Anders - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sat, 16 Jun 2007 22:54:56 -0300, Alexandre Oliva wrote: > I don't know any law that requires tivoization. Not exactly laws, but pretty close: Credit-card payment terminals are subject to strict security certification, where it has to be ensured that a) the user cannot tinker with the device without rendering it unusable for its original purpose (electronic payments), and b) the manufacturer is able to update the device _in_ _the_ _field_. Those are hard requirements imposed by the banks and credit-card companies. We _are_ allowed to disclose the source code (and we do, of course) so that it can be used for other purposes, and of course the user can modify it. But there's just no way she would be (legally) able to run the modified software in the same device for the original purpose. With the (current draft of) GPLv3 we could not legally use Linux on such devices. Cheers Anders - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)
On 2007-02-22 01:18:09, Greg KH wrote: > On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote: > > E.g. something calls the request_modle(), and if hotplug is using > > socket(PF_UNIX) and af_unix is module, it also calls request_modle()? > > > > Just my guess though... > > Ugh, why does anyone make af_unix a module these days. I thought only > Debian was that foolish... :) Then how about making CONFIG_UNIX bool instead of tristate? Cheers Anders diff --git a/net/unix/Kconfig b/net/unix/Kconfig index 5a69733..b589254 100644 --- a/net/unix/Kconfig +++ b/net/unix/Kconfig @@ -3,7 +3,7 @@ # config UNIX - tristate "Unix domain sockets" + bool "Unix domain sockets" ---help--- If you say Y here, you will include support for Unix domain sockets; sockets are the standard Unix mechanism for establishing and @@ -13,9 +13,5 @@ config UNIX an embedded system or something similar, you therefore definitely want to say Y here. - To compile this driver as a module, choose M here: the module will be - called unix. Note that several important services won't work - correctly if you say M here and then neglect to load the module. - Say Y unless you know what you are doing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
"Richard B. Johnson" wrote: > > On Fri, 22 Jun 2001, Anders Larsen wrote: > > > "Richard B. Johnson" wrote: > > > > > > QNX does not have any difference between user-space and kernel space. > > > It's not paged-virtual. It's just one big sheet of address space > > > with no memory protection (everything is shared). All procedures > > > to be executed are known at compile time. > > > > That's completely, utterly untrue. > > QNX does indeed sport paged-virtual memory with memory protection; > > (although QNX4 does not support swap). > > Then QNX is not the QNX that I have used. Or you haven't used it recently (= within the past 10 years) > > User-mode interrupts are standard procedure; the deadlock problems > > Alan has mentioned do not apply, since any running process is > > always resident in memory. > > Shared regions have to be explicitly created; access is *not* open > > to anybody. > > > > Nothing has to be known at "compile time"; QNX is a full-featured > > OS with dynamic loading. > > > > The QNX that I have used, advertised as QNX, and been around since > 32-bit ix86 was available, is EXACTLY as I stated. Dynamic loading of executables has been in QNX for as long as I know it (fifteen years). With the appearance of QNX version 4 some ten years ago came 32-bit address space, full memory management/protection etc. > > > Therefore, any piece of code can do anything it wants including > > > handling hardware directly. > > > > Again not true; only privileged processes can enter kernel mode > > to execute port I/O instructions directly. > > The QNX that I have used, again is EXACTLY as stated. It must have been an early QNX version 2, then. QNX 2 did not have any memory protection. > If you have used a different QNX, then QNX has either changed > radically, or is a different company/QNX than what I used. > And, I had a lot of good experiences with it since standard > I/O was provided, as was boot, but it was an open book otherwise > in which you were not prevented from doing anything you wanted > to do, at any instant you wanted to do it. Of course QNX has changes radically over the decades (it's been around for some twenty years now); what I frowned at was that you made your statements as if they would apply to the *current* state of affairs, which they certainly do not. cheers Anders -- "In theory there is no difference between theory and practice. In practice there is." - Yogi Berra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
"Richard B. Johnson" wrote: > > QNX does not have any difference between user-space and kernel space. > It's not paged-virtual. It's just one big sheet of address space > with no memory protection (everything is shared). All procedures > to be executed are known at compile time. That's completely, utterly untrue. QNX does indeed sport paged-virtual memory with memory protection; (although QNX4 does not support swap). User-mode interrupts are standard procedure; the deadlock problems Alan has mentioned do not apply, since any running process is always resident in memory. Shared regions have to be explicitly created; access is *not* open to anybody. Nothing has to be known at "compile time"; QNX is a full-featured OS with dynamic loading. > Therefore, any piece of code can do anything it wants including > handling hardware directly. Again not true; only privileged processes can enter kernel mode to execute port I/O instructions directly. cheers Anders -- "In theory there is no difference between theory and practice. In practice there is." - Yogi Berra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
UMSDOS symlink bug
Hi, last week I got bitten by the UMSDOS symlink bug (symlinks are created with the last character missing). After having found and fixed the problem, I located your address to report it and found that the problem (and the fix!) has been known for at least half a year. Although your patches for other problems with UMSDOS may or may not be ready for Linus yet, the one-liner symlink patch should IMHO be submitted asap, since it is an obvious fix for an obvious bug. Apart from the symlink bug, I haven't seen any of the other known problems (but now that I have seen your list, I'll try systematically). BTW, I create the UMSDOS fs on an ATA flash disk using a 2.4.5 box for use in an embedded system running 2.2.19 cheers Anders -- "In theory there is no difference between theory and practice. In practice there is." - Yogi Berra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
