On Mon, Mar 6, 2017 at 12:16 PM, Arnd Bergmann wrote:
> On Mon, Mar 6, 2017 at 12:02 PM, Arend Van Spriel
> wrote:
>> On 6-3-2017 11:38, Arnd Bergmann wrote:
>>> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel
>>> wrote:
>> Given the amount of local variables maybe just tag the functions with
On Mon, Mar 6, 2017 at 12:02 PM, Arend Van Spriel
wrote:
> On 6-3-2017 11:38, Arnd Bergmann wrote:
>> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel
>> wrote:
>>> On 2-3-2017 17:38, Arnd Bergmann wrote:
The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put
an obj
On 6-3-2017 11:38, Arnd Bergmann wrote:
> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel
> wrote:
>> On 2-3-2017 17:38, Arnd Bergmann wrote:
>>> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put
>>> an object
>>> on the stack, which will each require a redzone with KASA
On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel
wrote:
> On 2-3-2017 17:38, Arnd Bergmann wrote:
>> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an
>> object
>> on the stack, which will each require a redzone with KASAN and lead to
>> possible
>> stack overflow:
>>
On 2-3-2017 17:38, Arnd Bergmann wrote:
> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an
> object
> on the stack, which will each require a redzone with KASAN and lead to
> possible
> stack overflow:
>
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:
The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an
object
on the stack, which will each require a redzone with KASAN and lead to possible
stack overflow:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function
'wlc_phy_workarounds_nphy':
drivers/net/wi
